Re: [Mesa-dev] [PATCH] nv50/ir: implement global atomics and handle it for nir
On Thu, Dec 5, 2019 at 11:57 AM Karol Herbst wrote:
>
> TGSI doesn't have any concept of global memory right now.
>
> Signed-off-by: Karol Herbst
> ---
> .../nouveau/codegen/nv50_ir_from_nir.cpp | 43 +--
> .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +
> 2 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
> index 08365988069..31f764d63d4 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
> @@ -582,40 +582,47 @@ Converter::getSubOp(nir_intrinsic_op op)
> {
> switch (op) {
> case nir_intrinsic_bindless_image_atomic_add:
> + case nir_intrinsic_global_atomic_add:
> case nir_intrinsic_image_atomic_add:
> case nir_intrinsic_image_deref_atomic_add:
> case nir_intrinsic_shared_atomic_add:
> case nir_intrinsic_ssbo_atomic_add:
>return NV50_IR_SUBOP_ATOM_ADD;
> case nir_intrinsic_bindless_image_atomic_and:
> + case nir_intrinsic_global_atomic_and:
> case nir_intrinsic_image_atomic_and:
> case nir_intrinsic_image_deref_atomic_and:
> case nir_intrinsic_shared_atomic_and:
> case nir_intrinsic_ssbo_atomic_and:
>return NV50_IR_SUBOP_ATOM_AND;
> case nir_intrinsic_bindless_image_atomic_comp_swap:
> + case nir_intrinsic_global_atomic_comp_swap:
> case nir_intrinsic_image_atomic_comp_swap:
> case nir_intrinsic_image_deref_atomic_comp_swap:
> case nir_intrinsic_shared_atomic_comp_swap:
> case nir_intrinsic_ssbo_atomic_comp_swap:
>return NV50_IR_SUBOP_ATOM_CAS;
> case nir_intrinsic_bindless_image_atomic_exchange:
> + case nir_intrinsic_global_atomic_exchange:
> case nir_intrinsic_image_atomic_exchange:
> case nir_intrinsic_image_deref_atomic_exchange:
> case nir_intrinsic_shared_atomic_exchange:
> case nir_intrinsic_ssbo_atomic_exchange:
>return NV50_IR_SUBOP_ATOM_EXCH;
> case nir_intrinsic_bindless_image_atomic_or:
> + case nir_intrinsic_global_atomic_or:
> case nir_intrinsic_image_atomic_or:
> case nir_intrinsic_image_deref_atomic_or:
> case nir_intrinsic_shared_atomic_or:
> case nir_intrinsic_ssbo_atomic_or:
>return NV50_IR_SUBOP_ATOM_OR;
> case nir_intrinsic_bindless_image_atomic_imax:
> - case nir_intrinsic_image_atomic_imax:
> - case nir_intrinsic_image_deref_atomic_imax:
> case nir_intrinsic_bindless_image_atomic_umax:
> + case nir_intrinsic_global_atomic_imax:
> + case nir_intrinsic_global_atomic_umax:
> + case nir_intrinsic_image_atomic_imax:
> case nir_intrinsic_image_atomic_umax:
> + case nir_intrinsic_image_deref_atomic_imax:
> case nir_intrinsic_image_deref_atomic_umax:
> case nir_intrinsic_shared_atomic_imax:
> case nir_intrinsic_shared_atomic_umax:
> @@ -623,10 +630,12 @@ Converter::getSubOp(nir_intrinsic_op op)
> case nir_intrinsic_ssbo_atomic_umax:
>return NV50_IR_SUBOP_ATOM_MAX;
> case nir_intrinsic_bindless_image_atomic_imin:
> - case nir_intrinsic_image_atomic_imin:
> - case nir_intrinsic_image_deref_atomic_imin:
> case nir_intrinsic_bindless_image_atomic_umin:
> + case nir_intrinsic_global_atomic_imin:
> + case nir_intrinsic_global_atomic_umin:
> + case nir_intrinsic_image_atomic_imin:
> case nir_intrinsic_image_atomic_umin:
> + case nir_intrinsic_image_deref_atomic_imin:
> case nir_intrinsic_image_deref_atomic_umin:
> case nir_intrinsic_shared_atomic_imin:
> case nir_intrinsic_shared_atomic_umin:
> @@ -634,6 +643,7 @@ Converter::getSubOp(nir_intrinsic_op op)
> case nir_intrinsic_ssbo_atomic_umin:
>return NV50_IR_SUBOP_ATOM_MIN;
> case nir_intrinsic_bindless_image_atomic_xor:
> + case nir_intrinsic_global_atomic_xor:
> case nir_intrinsic_image_atomic_xor:
> case nir_intrinsic_image_deref_atomic_xor:
> case nir_intrinsic_shared_atomic_xor:
> @@ -2379,6 +2389,30 @@ Converter::visit(nir_intrinsic_instr *insn)
>info->io.globalAccess |= 0x2;
>break;
> }
> + case nir_intrinsic_global_atomic_add:
> + case nir_intrinsic_global_atomic_and:
> + case nir_intrinsic_global_atomic_comp_swap:
> + case nir_intrinsic_global_atomic_exchange:
> + case nir_intrinsic_global_atomic_or:
> + case nir_intrinsic_global_atomic_imax:
> + case nir_intrinsic_global_atomic_imin:
> + case nir_intrinsic_global_atomic_umax:
> + case nir_intrinsic_global_atomic_umin:
> + case nir_intrinsic_global_atomic_xor: {
> + const DataType dType = getDType(insn);
> + LValues = convert(>dest);
> + Value *address;
> + uint32_t offset = getIndirect(>src[0], 0, address);
> +
> + Symbol *sym = mkSymbol(FILE_MEMORY_GLOBAL, 0, dType, offset);
> + Instruction *atom =
> + mkOp2(OP_ATOM, dType, newDefs[0], sym, getSrc(>src[1], 0));
> + atom->setIndirect(0, 0,
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On Wed, Dec 4, 2019 at 11:58 PM Kenneth Graunke wrote: > > On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote: > > Hi, > > > > Here are 2 proposals to simplify and better optimize the GL->Gallium > > translation. > > > > 1) Move classic drivers to a fork of Mesa, and remove them from master. > > Classic drivers won't share any code with master. glvnd will load them, but > > glvnd is not ready for this yet. > > > > 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, > > mesa/vbo, mesa/program, and drivers/dri/common need to be forked and > > mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target > > location. > > > > Option 2 is more acceptable to people who want to keep classic drivers in > > the tree and it can be done right now. > > > > Opinions? > > > > Thanks, > > Marek > > FWIW, I am not in favor of either plan for the time being. > > - I agree with Eric that we're finally starting to clean up and > de-duplicate things, and pay off technical debt we've put off for > a long time. I think forking everything in-tree would just be a > giant mess. > > - I agree with Dave that this seems to be a giant hassle for our > downstreams with little benefit for them in the short term. > > - Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems > like a fine plan. They're ancient hardware that can't (or barely > can) do GL 2.x. Nothing much has happened with them in years, > and I'm not sure all of them even really have maintainers. > > The main blocker here I think would be ironing out all the glvnd > issues and making sure that is working solidly for everyone. > (FWIW, glvnd is not even enabled by default in our build system!) > > - Shuffling i965 off to legacy is really premature I think. Iris > isn't even shipping in distros yet (hopefully soon!), and even > then, we have a _ton_ of Haswell users. Check the Phoronix > comments if you want to see how pissed off people are about even > bringing up this topic. (Or better yet, don't...basic human > decency toward others seems to be lacking. Hooray, internet...) > > - Writing a Gallium driver for Intel Gen4-7.5 would be interesting. > > I've been thinking about this some, and it might be possible to > retain some of the niceties of the iris memory model even on older > hardware, by relying on a modern kernel and possibly making some > (hopefully minor) improvements. Even if we didn't, going back to > the i965 model wouldn't be the worst thing. The new driver would > almost certainly be faster than i965, if not as good as iris. > > ajax and I were planning to call it crocus, if I wrote one. I don't > think it would take nearly as long. But it's still a bunch of time > that I don't think I can justify spending. The new hardware can do > so much more, and is so much faster, and much lower power. I think > it would be better for me to spend my time on Gen11+. > > - Vulkan has really taken off, and OpenGL feels increasingly like a > dead end. DXVK has brought more games than we had with native ports. > Feral is even reworking some native OpenGL ports to use Vulkan. New > graphics features are happening in the Vulkan space. > > So, I kind of wonder whether it's worth our time to go through and > massively clean up and rearchitecture the OpenGL drivers at this > point. By the time we're finished, will anyone care? maybe years in the future, when zink is the only remaining gallium driver, we have v2 of this discussion (ie. forking the other gallium drivers into an LTS branch) :-P BR, -R > > - Are there concrete things that are prohibitively expensive with > classic around? Otherwise, Eric's suggestion of "so go do that!" > sounds like a good idea. We've started finally merging a bunch > of code and I think this is a positive direction. > > I'd say let's shelve this for now and think about it again later. > I suspect in a year or so the calculus will look fairly different. > > --Ken > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/atomic: Add p_atomic_add_return for the unlocked path
Pushed. Thanks for catching this! On Thu, Dec 5, 2019 at 11:52 AM Ilia Mirkin wrote: > Reviewed-by: Ilia Mirkin > > On Thu, Dec 5, 2019 at 12:51 PM Jason Ekstrand > wrote: > > > > Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" > > --- > > src/util/u_atomic.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h > > index 45e8e2e0188..9cbc6dd1eaa 100644 > > --- a/src/util/u_atomic.h > > +++ b/src/util/u_atomic.h > > @@ -92,7 +92,7 @@ > > #define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) > > #define p_atomic_inc_return(_v) (++(*(_v))) > > #define p_atomic_dec_return(_v) (--(*(_v))) > > -#define p_atomic_add(_v, _i) (*(_v) = *(_v) + (_i)) > > +#define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) > > #define p_atomic_cmpxchg(_v, _old, _new) (*(_v) == (_old) ? (*(_v) = > (_new), (_old)) : *(_v)) > > > > #endif > > -- > > 2.23.0 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util/atomic: Add p_atomic_add_return for the unlocked path
Reviewed-by: Ilia Mirkin On Thu, Dec 5, 2019 at 12:51 PM Jason Ekstrand wrote: > > Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" > --- > src/util/u_atomic.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h > index 45e8e2e0188..9cbc6dd1eaa 100644 > --- a/src/util/u_atomic.h > +++ b/src/util/u_atomic.h > @@ -92,7 +92,7 @@ > #define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) > #define p_atomic_inc_return(_v) (++(*(_v))) > #define p_atomic_dec_return(_v) (--(*(_v))) > -#define p_atomic_add(_v, _i) (*(_v) = *(_v) + (_i)) > +#define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) > #define p_atomic_cmpxchg(_v, _old, _new) (*(_v) == (_old) ? (*(_v) = (_new), > (_old)) : *(_v)) > > #endif > -- > 2.23.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util/atomic: Add p_atomic_add_return for the unlocked path
Fixes: 385d13f26d2 "util/atomic: Add a _return variant of p_atomic_add" --- src/util/u_atomic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/u_atomic.h b/src/util/u_atomic.h index 45e8e2e0188..9cbc6dd1eaa 100644 --- a/src/util/u_atomic.h +++ b/src/util/u_atomic.h @@ -92,7 +92,7 @@ #define p_atomic_add(_v, _i) ((void) p_atomic_add_return((_v), (_i)) #define p_atomic_inc_return(_v) (++(*(_v))) #define p_atomic_dec_return(_v) (--(*(_v))) -#define p_atomic_add(_v, _i) (*(_v) = *(_v) + (_i)) +#define p_atomic_add_return(_v, _i) (*(_v) = *(_v) + (_i)) #define p_atomic_cmpxchg(_v, _old, _new) (*(_v) == (_old) ? (*(_v) = (_new), (_old)) : *(_v)) #endif -- 2.23.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nouveau: limit reported compute max memory and allocation size
Otherwise applications (like the OpenCL CTS) will try to allocate more memory
than what the GPU is actually able to provide.
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 7 +--
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index ad35bd8cd42..5942458b0b2 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -472,6 +472,7 @@ nv50_screen_get_compute_param(struct pipe_screen *pscreen,
enum pipe_compute_cap param, void *data)
{
struct nv50_screen *screen = nv50_screen(pscreen);
+ struct nouveau_device *dev = screen->base.device;
#define RET(x) do { \
if (data) \
@@ -489,7 +490,8 @@ nv50_screen_get_compute_param(struct pipe_screen *pscreen,
case PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK:
RET((uint64_t []) { 512 });
case PIPE_COMPUTE_CAP_MAX_GLOBAL_SIZE: /* g0-15[] */
- RET((uint64_t []) { 1ULL << 32 });
+ // TODO what to do if vram_size is 0?
+ RET((uint64_t []) { MIN2(1ULL << 32, dev->vram_size) });
case PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE: /* s[] */
RET((uint64_t []) { 16 << 10 });
case PIPE_COMPUTE_CAP_MAX_PRIVATE_SIZE: /* l[] */
@@ -499,7 +501,8 @@ nv50_screen_get_compute_param(struct pipe_screen *pscreen,
case PIPE_COMPUTE_CAP_SUBGROUP_SIZE:
RET((uint32_t []) { 32 });
case PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE:
- RET((uint64_t []) { 1ULL << 40 });
+ // TODO what to do if vram_size is 0?
+ RET((uint64_t []) { dev->vram_size });
case PIPE_COMPUTE_CAP_IMAGES_SUPPORTED:
RET((uint32_t []) { 0 });
case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index f5e1373a37e..57b1c70f7b3 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -533,6 +533,7 @@ nvc0_screen_get_compute_param(struct pipe_screen *pscreen,
{
struct nvc0_screen *screen = nvc0_screen(pscreen);
const uint16_t obj_class = screen->compute->oclass;
+ struct nouveau_device *dev = screen->base.device;
#define RET(x) do { \
if (data) \
@@ -560,7 +561,8 @@ nvc0_screen_get_compute_param(struct pipe_screen *pscreen,
RET((uint64_t []) { 512 });
}
case PIPE_COMPUTE_CAP_MAX_GLOBAL_SIZE: /* g[] */
- RET((uint64_t []) { 1ULL << 40 });
+ // TODO what to do when vram_size is 0?
+ RET((uint64_t []) { dev->vram_size });
case PIPE_COMPUTE_CAP_MAX_LOCAL_SIZE: /* s[] */
switch (obj_class) {
case GM200_COMPUTE_CLASS:
@@ -580,7 +582,8 @@ nvc0_screen_get_compute_param(struct pipe_screen *pscreen,
case PIPE_COMPUTE_CAP_SUBGROUP_SIZE:
RET((uint32_t []) { 32 });
case PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE:
- RET((uint64_t []) { 1ULL << 40 });
+ // TODO what to do when vram_size is 0?
+ RET((uint64_t []) { dev->vram_size });
case PIPE_COMPUTE_CAP_IMAGES_SUPPORTED:
RET((uint32_t []) { 0 });
case PIPE_COMPUTE_CAP_MAX_COMPUTE_UNITS:
--
2.23.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/4] util/os_misc: os_get_available_system_memory() for OpenBSD
Return the smallest value of available non-kernel physical memory and
the static per process data size limit as the amount of available
system memory on OpenBSD.
Signed-off-by: Jonathan Gray
---
src/util/os_misc.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/util/os_misc.c b/src/util/os_misc.c
index 581e15f3934..9b13dcdb9f8 100644
--- a/src/util/os_misc.c
+++ b/src/util/os_misc.c
@@ -28,6 +28,7 @@
#include "os_misc.h"
#include "os_file.h"
+#include "macros.h"
#include
@@ -57,6 +58,9 @@
# include
#elif DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS ||
DETECT_OS_HURD
# include
+#elif DETECT_OS_OPENBSD
+# include
+# include
#elif DETECT_OS_APPLE || DETECT_OS_BSD
# include
#elif DETECT_OS_HAIKU
@@ -209,6 +213,22 @@ os_get_available_system_memory(uint64_t *size)
free(meminfo);
return false;
+#elif DETECT_OS_OPENBSD
+ struct rlimit rl;
+ int mib[] = { CTL_HW, HW_USERMEM64 };
+ int64_t mem_available;
+ size_t len = sizeof(mem_available);
+
+ /* physmem - wired */
+ if (sysctl(mib, 2, _available, , NULL, 0) == -1)
+ return false;
+
+ /* static login.conf limit */
+ if (getrlimit(RLIMIT_DATA, ) == -1)
+ return false;
+
+ *size = MIN2(mem_available, rl.rlim_cur);
+ return true;
#else
return false;
#endif
--
2.24.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] util/os_misc: add os_get_available_system_memory()
Add os_get_available_system_memory() derived from
src/intel/vulkan/anv_device.c get_available_system_memory()
Signed-off-by: Jonathan Gray
---
src/util/os_misc.c | 31 +++
src/util/os_misc.h | 6 ++
2 files changed, 37 insertions(+)
diff --git a/src/util/os_misc.c b/src/util/os_misc.c
index e6894731b63..581e15f3934 100644
--- a/src/util/os_misc.c
+++ b/src/util/os_misc.c
@@ -27,6 +27,7 @@
#include "os_misc.h"
+#include "os_file.h"
#include
@@ -44,6 +45,8 @@
#include
#include
+#include
+#include
#endif
@@ -182,3 +185,31 @@ os_get_total_physical_memory(uint64_t *size)
return false;
#endif
}
+
+bool
+os_get_available_system_memory(uint64_t *size)
+{
+#if DETECT_OS_LINUX
+ char *meminfo = os_read_file("/proc/meminfo");
+ if (!meminfo)
+ return false;
+
+ char *str = strstr(meminfo, "MemAvailable:");
+ if (!str) {
+ free(meminfo);
+ return false;
+ }
+
+ uint64_t kb_mem_available;
+ if (sscanf(str, "MemAvailable: %" PRIx64, _mem_available) == 1) {
+ free(meminfo);
+ *size = kb_mem_available << 10;
+ return true;
+ }
+
+ free(meminfo);
+ return false;
+#else
+ return false;
+#endif
+}
diff --git a/src/util/os_misc.h b/src/util/os_misc.h
index 19c8962d5d8..60811faf5a4 100644
--- a/src/util/os_misc.h
+++ b/src/util/os_misc.h
@@ -95,6 +95,12 @@ os_get_option(const char *name);
bool
os_get_total_physical_memory(uint64_t *size);
+/*
+ * Amount of physical memory available to a process
+ */
+bool
+os_get_available_system_memory(uint64_t *size);
+
#ifdef __cplusplus
}
--
2.24.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] anv: use os_get_available_system_memory()
Replace local get_available_system_memory() function with
os_get_available_system_memory().
Signed-off-by: Jonathan Gray
---
src/intel/vulkan/anv_device.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index b9429ff611a..eec37bb8399 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -356,29 +356,6 @@ anv_physical_device_free_disk_cache(struct
anv_physical_device *device)
#endif
}
-static uint64_t
-get_available_system_memory()
-{
- char *meminfo = os_read_file("/proc/meminfo");
- if (!meminfo)
- return 0;
-
- char *str = strstr(meminfo, "MemAvailable:");
- if (!str) {
- free(meminfo);
- return 0;
- }
-
- uint64_t kb_mem_available;
- if (sscanf(str, "MemAvailable: %" PRIx64, _mem_available) == 1) {
- free(meminfo);
- return kb_mem_available << 10;
- }
-
- free(meminfo);
- return 0;
-}
-
static VkResult
anv_physical_device_init(struct anv_physical_device *device,
struct anv_instance *instance,
@@ -510,7 +487,8 @@ anv_physical_device_init(struct anv_physical_device *device,
*/
device->has_bindless_samplers = device->info.gen >= 8;
- device->has_mem_available = get_available_system_memory() != 0;
+ uint64_t avail_mem;
+ device->has_mem_available = os_get_available_system_memory(_mem);
device->always_flush_cache =
driQueryOptionb(>dri_options, "always_flush_cache");
@@ -1918,8 +1896,8 @@ anv_get_memory_budget(VkPhysicalDevice physicalDevice,
VkPhysicalDeviceMemoryBudgetPropertiesEXT *memoryBudget)
{
ANV_FROM_HANDLE(anv_physical_device, device, physicalDevice);
- uint64_t sys_available = get_available_system_memory();
- assert(sys_available > 0);
+ uint64_t sys_available;
+ assert(os_get_available_system_memory(_available));
VkDeviceSize total_heaps_size = 0;
for (size_t i = 0; i < device->memory.heap_count; i++)
--
2.24.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] anv: use os_get_total_physical_memory()
Replace non-portable sysinfo() use with Mesa's
os_get_total_physical_memory()
Signed-off-by: Jonathan Gray
---
src/intel/vulkan/anv_device.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0993a505075..b9429ff611a 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -37,6 +36,7 @@
#include "util/disk_cache.h"
#include "util/mesa-sha1.h"
#include "util/os_file.h"
+#include "util/os_misc.h"
#include "util/u_atomic.h"
#include "util/u_string.h"
#include "util/xmlpool.h"
@@ -101,10 +101,9 @@ static uint64_t
anv_compute_heap_size(int fd, uint64_t gtt_size)
{
/* Query the total ram from the system */
- struct sysinfo info;
- sysinfo();
-
- uint64_t total_ram = (uint64_t)info.totalram * (uint64_t)info.mem_unit;
+ uint64_t total_ram;
+ if (!os_get_total_physical_memory(_ram))
+ return 0;
/* We don't want to burn too much ram with the GPU. If the user has 4GiB
* or less, we use at most half. If they have more than 4GiB, we use 3/4.
--
2.24.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: remove second prototype of brw_batch_reloc
I am. Reading code too late at night, apparently. Sorry! On Thu, Dec 5, 2019 at 4:15 AM Lionel Landwerlin wrote: > > Hmm... I don't see it. > > Are you not confused by brw_batch_reloc/brw_state_reloc? > > -Lionel > > On 05/12/2019 06:56, Ilia Mirkin wrote: > > Signed-off-by: Ilia Mirkin > > --- > > src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 - > > 1 file changed, 5 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h > > b/src/mesa/drivers/dri/i965/intel_batchbuffer.h > > index 91720dad5b4..137158f168a 100644 > > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h > > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h > > @@ -67,11 +67,6 @@ uint64_t brw_batch_reloc(struct intel_batchbuffer *batch, > >struct brw_bo *target, > >uint32_t target_offset, > >unsigned flags); > > -uint64_t brw_state_reloc(struct intel_batchbuffer *batch, > > - uint32_t batch_offset, > > - struct brw_bo *target, > > - uint32_t target_offset, > > - unsigned flags); > > > > #define USED_BATCH(_batch) \ > > ((uintptr_t)((_batch).map_next - (_batch).batch.map)) > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nv50/ir: implement global atomics and handle it for nir
TGSI doesn't have any concept of global memory right now.
Signed-off-by: Karol Herbst
---
.../nouveau/codegen/nv50_ir_from_nir.cpp | 43 +--
.../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 08365988069..31f764d63d4 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
@@ -582,40 +582,47 @@ Converter::getSubOp(nir_intrinsic_op op)
{
switch (op) {
case nir_intrinsic_bindless_image_atomic_add:
+ case nir_intrinsic_global_atomic_add:
case nir_intrinsic_image_atomic_add:
case nir_intrinsic_image_deref_atomic_add:
case nir_intrinsic_shared_atomic_add:
case nir_intrinsic_ssbo_atomic_add:
return NV50_IR_SUBOP_ATOM_ADD;
case nir_intrinsic_bindless_image_atomic_and:
+ case nir_intrinsic_global_atomic_and:
case nir_intrinsic_image_atomic_and:
case nir_intrinsic_image_deref_atomic_and:
case nir_intrinsic_shared_atomic_and:
case nir_intrinsic_ssbo_atomic_and:
return NV50_IR_SUBOP_ATOM_AND;
case nir_intrinsic_bindless_image_atomic_comp_swap:
+ case nir_intrinsic_global_atomic_comp_swap:
case nir_intrinsic_image_atomic_comp_swap:
case nir_intrinsic_image_deref_atomic_comp_swap:
case nir_intrinsic_shared_atomic_comp_swap:
case nir_intrinsic_ssbo_atomic_comp_swap:
return NV50_IR_SUBOP_ATOM_CAS;
case nir_intrinsic_bindless_image_atomic_exchange:
+ case nir_intrinsic_global_atomic_exchange:
case nir_intrinsic_image_atomic_exchange:
case nir_intrinsic_image_deref_atomic_exchange:
case nir_intrinsic_shared_atomic_exchange:
case nir_intrinsic_ssbo_atomic_exchange:
return NV50_IR_SUBOP_ATOM_EXCH;
case nir_intrinsic_bindless_image_atomic_or:
+ case nir_intrinsic_global_atomic_or:
case nir_intrinsic_image_atomic_or:
case nir_intrinsic_image_deref_atomic_or:
case nir_intrinsic_shared_atomic_or:
case nir_intrinsic_ssbo_atomic_or:
return NV50_IR_SUBOP_ATOM_OR;
case nir_intrinsic_bindless_image_atomic_imax:
- case nir_intrinsic_image_atomic_imax:
- case nir_intrinsic_image_deref_atomic_imax:
case nir_intrinsic_bindless_image_atomic_umax:
+ case nir_intrinsic_global_atomic_imax:
+ case nir_intrinsic_global_atomic_umax:
+ case nir_intrinsic_image_atomic_imax:
case nir_intrinsic_image_atomic_umax:
+ case nir_intrinsic_image_deref_atomic_imax:
case nir_intrinsic_image_deref_atomic_umax:
case nir_intrinsic_shared_atomic_imax:
case nir_intrinsic_shared_atomic_umax:
@@ -623,10 +630,12 @@ Converter::getSubOp(nir_intrinsic_op op)
case nir_intrinsic_ssbo_atomic_umax:
return NV50_IR_SUBOP_ATOM_MAX;
case nir_intrinsic_bindless_image_atomic_imin:
- case nir_intrinsic_image_atomic_imin:
- case nir_intrinsic_image_deref_atomic_imin:
case nir_intrinsic_bindless_image_atomic_umin:
+ case nir_intrinsic_global_atomic_imin:
+ case nir_intrinsic_global_atomic_umin:
+ case nir_intrinsic_image_atomic_imin:
case nir_intrinsic_image_atomic_umin:
+ case nir_intrinsic_image_deref_atomic_imin:
case nir_intrinsic_image_deref_atomic_umin:
case nir_intrinsic_shared_atomic_imin:
case nir_intrinsic_shared_atomic_umin:
@@ -634,6 +643,7 @@ Converter::getSubOp(nir_intrinsic_op op)
case nir_intrinsic_ssbo_atomic_umin:
return NV50_IR_SUBOP_ATOM_MIN;
case nir_intrinsic_bindless_image_atomic_xor:
+ case nir_intrinsic_global_atomic_xor:
case nir_intrinsic_image_atomic_xor:
case nir_intrinsic_image_deref_atomic_xor:
case nir_intrinsic_shared_atomic_xor:
@@ -2379,6 +2389,30 @@ Converter::visit(nir_intrinsic_instr *insn)
info->io.globalAccess |= 0x2;
break;
}
+ case nir_intrinsic_global_atomic_add:
+ case nir_intrinsic_global_atomic_and:
+ case nir_intrinsic_global_atomic_comp_swap:
+ case nir_intrinsic_global_atomic_exchange:
+ case nir_intrinsic_global_atomic_or:
+ case nir_intrinsic_global_atomic_imax:
+ case nir_intrinsic_global_atomic_imin:
+ case nir_intrinsic_global_atomic_umax:
+ case nir_intrinsic_global_atomic_umin:
+ case nir_intrinsic_global_atomic_xor: {
+ const DataType dType = getDType(insn);
+ LValues = convert(>dest);
+ Value *address;
+ uint32_t offset = getIndirect(>src[0], 0, address);
+
+ Symbol *sym = mkSymbol(FILE_MEMORY_GLOBAL, 0, dType, offset);
+ Instruction *atom =
+ mkOp2(OP_ATOM, dType, newDefs[0], sym, getSrc(>src[1], 0));
+ atom->setIndirect(0, 0, address);
+ atom->subOp = getSubOp(op);
+
+ info->io.globalAccess |= 0x2;
+ break;
+ }
case nir_intrinsic_bindless_image_atomic_add:
case nir_intrinsic_bindless_image_atomic_and:
case nir_intrinsic_bindless_image_atomic_comp_swap:
@@ -2860,6
Re: [Mesa-dev] Remove classic drivers or fork src/mesa for gallium?
On 5/12/19 8:48, Kenneth Graunke wrote: On Tuesday, December 3, 2019 4:39:15 PM PST Marek Olšák wrote: Hi, Here are 2 proposals to simplify and better optimize the GL->Gallium translation. 1) Move classic drivers to a fork of Mesa, and remove them from master. Classic drivers won't share any code with master. glvnd will load them, but glvnd is not ready for this yet. 2) Keep classic drivers. Fork src/mesa for Gallium. I think only mesa/main, mesa/vbo, mesa/program, and drivers/dri/common need to be forked and mesa/state_tracker moved. src/gallium/state-trackers/gl/ can be the target location. Option 2 is more acceptable to people who want to keep classic drivers in the tree and it can be done right now. Opinions? Thanks, Marek FWIW, I am not in favor of either plan for the time being. - I agree with Eric that we're finally starting to clean up and de-duplicate things, and pay off technical debt we've put off for a long time. I think forking everything in-tree would just be a giant mess. - I agree with Dave that this seems to be a giant hassle for our downstreams with little benefit for them in the short term. - Shuffling r100/r200/i915/nouveau_vieux off to a legacy fork seems like a fine plan. They're ancient hardware that can't (or barely can) do GL 2.x. Nothing much has happened with them in years, and I'm not sure all of them even really have maintainers. The main blocker here I think would be ironing out all the glvnd issues and making sure that is working solidly for everyone. (FWIW, glvnd is not even enabled by default in our build system!) - Shuffling i965 off to legacy is really premature I think. Iris isn't even shipping in distros yet (hopefully soon!), and even then, we have a _ton_ of Haswell users. Check the Phoronix comments if you want to see how pissed off people are about even bringing up this topic. (Or better yet, don't...basic human decency toward others seems to be lacking. Hooray, internet...) - Writing a Gallium driver for Intel Gen4-7.5 would be interesting. I've been thinking about this some, and it might be possible to retain some of the niceties of the iris memory model even on older hardware, by relying on a modern kernel and possibly making some (hopefully minor) improvements. Even if we didn't, going back to the i965 model wouldn't be the worst thing. The new driver would almost certainly be faster than i965, if not as good as iris. ajax and I were planning to call it crocus, if I wrote one. I don't think it would take nearly as long. But it's still a bunch of time that I don't think I can justify spending. The new hardware can do so much more, and is so much faster, and much lower power. I think it would be better for me to spend my time on Gen11+. - Vulkan has really taken off, and OpenGL feels increasingly like a dead end. DXVK has brought more games than we had with native ports. Feral is even reworking some native OpenGL ports to use Vulkan. New graphics features are happening in the Vulkan space. So, I kind of wonder whether it's worth our time to go through and massively clean up and rearchitecture the OpenGL drivers at this point. By the time we're finished, will anyone care? - Are there concrete things that are prohibitively expensive with classic around? Otherwise, Eric's suggestion of "so go do that!" sounds like a good idea. We've started finally merging a bunch of code and I think this is a positive direction. I'd say let's shelve this for now and think about it again later. I suspect in a year or so the calculus will look fairly different. Although I think that it is somewhat early to think that OpenGL is nearly a dead end, FWIW, I agree in general with Kenneth analysis and suggestions here. BR ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: remove second prototype of brw_batch_reloc
Hmm... I don't see it. Are you not confused by brw_batch_reloc/brw_state_reloc? -Lionel On 05/12/2019 06:56, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin --- src/mesa/drivers/dri/i965/intel_batchbuffer.h | 5 - 1 file changed, 5 deletions(-) diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h b/src/mesa/drivers/dri/i965/intel_batchbuffer.h index 91720dad5b4..137158f168a 100644 --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h @@ -67,11 +67,6 @@ uint64_t brw_batch_reloc(struct intel_batchbuffer *batch, struct brw_bo *target, uint32_t target_offset, unsigned flags); -uint64_t brw_state_reloc(struct intel_batchbuffer *batch, - uint32_t batch_offset, - struct brw_bo *target, - uint32_t target_offset, - unsigned flags); #define USED_BATCH(_batch) \ ((uintptr_t)((_batch).map_next - (_batch).batch.map)) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] vc4: use intmax_t for formatted output of timespec members
32bit architectures which have 64bit time_t does not fit the assumption of time_t being same as system long int Fixes error: format specifies type 'long' but the argument has type 'time_t' (aka 'long long') [-Werror,-Wformat] time.tv_sec); ^~~ Upstream-Status: Pending Signed-off-by: Khem Raj --- src/gallium/drivers/v3d/v3d_bufmgr.c | 4 ++-- src/gallium/drivers/vc4/vc4_bufmgr.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/v3d/v3d_bufmgr.c b/src/gallium/drivers/v3d/v3d_bufmgr.c index b3e4d053cc0..c514bf00bf0 100644 --- a/src/gallium/drivers/v3d/v3d_bufmgr.c +++ b/src/gallium/drivers/v3d/v3d_bufmgr.c @@ -80,8 +80,8 @@ v3d_bo_dump_stats(struct v3d_screen *screen) struct timespec time; clock_gettime(CLOCK_MONOTONIC, ); -fprintf(stderr, " now: %ld\n", -time.tv_sec); +fprintf(stderr, " now: %jd\n", +(intmax_t)time.tv_sec); } } diff --git a/src/gallium/drivers/vc4/vc4_bufmgr.c b/src/gallium/drivers/vc4/vc4_bufmgr.c index 5ec360934c0..bf05f6cadd6 100644 --- a/src/gallium/drivers/vc4/vc4_bufmgr.c +++ b/src/gallium/drivers/vc4/vc4_bufmgr.c @@ -107,8 +107,8 @@ vc4_bo_dump_stats(struct vc4_screen *screen) struct timespec time; clock_gettime(CLOCK_MONOTONIC, ); -fprintf(stderr, " now: %ld\n", -time.tv_sec); +fprintf(stderr, " now: %jd\n", +(intmax_t)time.tv_sec); } } -- 2.24.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
