[Mesa-dev] [MR] anv/pipeline: Constant fold after apply_pipeline_layout

[Jason Ekstrand]

Thanks to the new NIR load_descriptor intrinsic added by the UBO/SSBO
lowering series, we weren't getting UBO pushing because the UBO range
detection pass couldn't see the constants it needed.  This fixes that
problem with a quick round of constant folding.  Because we're folding
we no longer need to go out of our way to generate constants when we
lower the vulkan_resource_index intrinsic and we can make it a bit
simpler.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/82
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir_to_llvm: fix interpolateAt* for arrays

[Timothy Arceri]

This builds on the recent interpolate fix by Rhys ee8488ea3b99.

This doesn't handle arrays of structs but I've got a feeling those
might be broken even for radeonsi tgsi (we currently have no tests).

This fixes the arb_gpu_shader5 interpolateAt* tests that contain
arrays.

Fixes: ee8488ea3b99 ("ac/nir,radv,radeonsi/nir: use correct indices for 
interpolation intrinsics")
---
 src/amd/common/ac_nir_to_llvm.c | 80 +
 1 file changed, 61 insertions(+), 19 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 5023b96f92..00011a439d 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2830,15 +2830,16 @@ static LLVMValueRef visit_interp(struct ac_nir_context 
*ctx,
 const nir_intrinsic_instr *instr)
 {
LLVMValueRef result[4];
-   LLVMValueRef interp_param, attr_number;
+   LLVMValueRef interp_param;
unsigned location;
unsigned chan;
LLVMValueRef src_c0 = NULL;
LLVMValueRef src_c1 = NULL;
LLVMValueRef src0 = NULL;
 
-   nir_variable *var = 
nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr));
-   int input_index = ctx->abi->fs_input_attr_indices[var->data.location - 
VARYING_SLOT_VAR0];
+   nir_deref_instr *deref_instr = 
nir_instr_as_deref(instr->src[0].ssa->parent_instr);
+   nir_variable *var = nir_deref_instr_get_variable(deref_instr);
+   int input_base = ctx->abi->fs_input_attr_indices[var->data.location - 
VARYING_SLOT_VAR0];
switch (instr->intrinsic) {
case nir_intrinsic_interp_deref_at_centroid:
location = INTERP_CENTROID;
@@ -2868,7 +2869,6 @@ static LLVMValueRef visit_interp(struct ac_nir_context 
*ctx,
src_c1 = LLVMBuildFSub(ctx->ac.builder, src_c1, halfval, "");
}
interp_param = ctx->abi->lookup_interp_param(ctx->abi, 
var->data.interpolation, location);
-   attr_number = LLVMConstInt(ctx->ac.i32, input_index, false);
 
if (location == INTERP_CENTER) {
LLVMValueRef ij_out[2];
@@ -2906,26 +2906,68 @@ static LLVMValueRef visit_interp(struct ac_nir_context 
*ctx,
 
}
 
+   LLVMValueRef array_idx = ctx->ac.i32_0;
+   while(deref_instr->deref_type != nir_deref_type_var) {
+   if (deref_instr->deref_type == nir_deref_type_array) {
+   unsigned array_size = 
glsl_get_aoa_size(deref_instr->type);
+   if (!array_size)
+   array_size = 1;
+
+   LLVMValueRef offset;
+   nir_const_value *const_value = 
nir_src_as_const_value(deref_instr->arr.index);
+   if (const_value) {
+   offset = LLVMConstInt(ctx->ac.i32, array_size * 
const_value->u32[0], false);
+   } else {
+   LLVMValueRef indirect = get_src(ctx, 
deref_instr->arr.index);
+
+   offset = LLVMBuildMul(ctx->ac.builder, indirect,
+ LLVMConstInt(ctx->ac.i32, 
array_size, false), "");
+   }
+
+   array_idx = LLVMBuildAdd(ctx->ac.builder, array_idx, 
offset, "");
+   deref_instr = nir_src_as_deref(deref_instr->parent);
+   } else if (deref_instr->deref_type == nir_deref_type_struct) {
+   /* TODO: Probably need to do more here to support 
arrays of structs etc */
+   deref_instr = nir_src_as_deref(deref_instr->parent);
+   } else {
+   unreachable("Unsupported deref type");
+   }
+
+   }
+
+   unsigned input_array_size = glsl_get_aoa_size(var->type);
+   if (!input_array_size)
+   input_array_size = 1;
+
for (chan = 0; chan < 4; chan++) {
+   LLVMValueRef gather = LLVMGetUndef(LLVMVectorType(ctx->ac.f32, 
input_array_size));
LLVMValueRef llvm_chan = LLVMConstInt(ctx->ac.i32, chan, false);
 
-   if (interp_param) {
-   interp_param = LLVMBuildBitCast(ctx->ac.builder,
+   for (unsigned idx = 0; idx < input_array_size; ++idx) {
+   LLVMValueRef v, attr_number;
+
+   attr_number = LLVMConstInt(ctx->ac.i32, input_base + 
idx, false);
+   if (interp_param) {
+   interp_param = LLVMBuildBitCast(ctx->ac.builder,
interp_param, 
ctx->ac.v2f32, "");
-   LLVMValueRef i = LLVMBuildExtractElement(
-   ctx->ac.builder, interp_param, ctx->ac.i32_0, 
"");
-   LLVMValueRef j = LLVMBuildExtractElement(
-   ctx->ac.builder, interp_param, 

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Tomasz Figa]

Hi Roland,

On Thu, Jan 10, 2019 at 1:36 AM Roland Scheidegger  wrote:
>
> Sorry but I had to revert this, as we've seen lots of assertion failures
> (src/gallium/drivers/llvmpipe/lp_fence.c:120: lp_fence_wait: Assertion
> `f->issued' failed.). For instance with libgl_xlib state tracker and piglit.
> I'm not entirely sure if it's really safe to just remove the assert or

Understood. Sorry for not spotting this in my testing. Would you be
able to help with more details on how to reproduce these failures?

> if it needs some more work, and I don't have time right now for a
> thorough investigation, but I'll happily take new patches...

Perhaps we could make these dummy fences "issued". I'll check how this
works in the code.

Best regards,
Tomasz

>
> Roland
>
>
> Am 09.01.19 um 02:09 schrieb Roland Scheidegger:
> > Am 07.01.19 um 09:54 schrieb Tomasz Figa:
> >> On Sun, Dec 23, 2018 at 12:55 AM Roland Scheidegger  
> >> wrote:
> >>>
> >>> Alright, I guess it should work...
> >>>
> >>> Reviewed-by: Roland Scheidegger 
> >>>
> >>
> >> Thanks!
> >>
> >> Would we have anyone who could help to commit it?
> >
> > Pushed (albeit I forgot the R-b on it, ah well...)
> >
> > Roland
> >
> >>
> >> (I know that I was supposed to apply for commit rights, but I expect
> >> my contribution rate to be relatively low, due to a shift to different
> >> areas, so I don't think I'm a good candidate for a committer anymore.)
> >>
> >> Best regards,
> >> Tomasz
> >>
> >>>
> >>> Am 14.12.18 um 09:17 schrieb Tomasz Figa:
>  If there is no last fence, due to no rendering happening yet, just
>  create a new signaled fence and return it, to match the expectations of
>  the EGL sync fence API.
> 
>  Fixes random "Could not create sync fence 0x3003" assertion failures from
>  Skia on Android, coming from the following code:
> 
>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Flibs%2Fhwui%2Fpipeline%2Fskia%2FSkiaOpenGLPipeline.cpp%23427data=02%7C01%7Csroland%40vmware.com%7Ccb06f4e1c9164a7871cb08d675cf20c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636825929820495738sdata=6hmZk%2BXWaQk%2B5XAKjxFSybOSpCVwzvKemYgZQ1rtpvg%3Dreserved=0
> 
>  Reproducible especially with thread count >= 4.
> 
>  One could make the driver always keep the reference to the last fence,
>  but:
> 
>   - the driver seems to explicitly destroy the fence whenever a rendering
> pass completes and changing that would require a significant 
>  functional
> change to the code. (Specifically, in lp_scene_end_rasterization().)
> 
>   - it still wouldn't solve the problem of an EGL sync fence being created
> and waited on without any rendering happening at all, which is
> also likely to happen with Android code pointed to in the commit.
> 
>  Therefore, the simple approach of always creating a fence is taken,
>  similarly to other drivers, such as radeonsi.
> 
>  Tested with piglit llvmpipe suite with no regressions and following
>  tests fixed:
> 
>  egl_khr_fence_sync
>   conformance
>    eglclientwaitsynckhr_flag_sync_flush
>    eglclientwaitsynckhr_nonzero_timeout
>    eglclientwaitsynckhr_zero_timeout
>    eglcreatesynckhr_default_attributes
>    eglgetsyncattribkhr_invalid_attrib
>    eglgetsyncattribkhr_sync_status
> 
>  v2:
>   - remove the useless lp_fence_reference() dance (Nicolai),
>   - explain why creating the dummy fence is the right approach.
> 
>  Signed-off-by: Tomasz Figa 
>  ---
>   src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
>  diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
>  b/src/gallium/drivers/llvmpipe/lp_setup.c
>  index b087369473..e72e119c8a 100644
>  --- a/src/gallium/drivers/llvmpipe/lp_setup.c
>  +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
>  @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,
> 
>  if (fence) {
> lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
>  +  if (!*fence)
>  + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
>  }
>   }
> 
> 
> >>>
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Csroland%40vmware.com%7Ccb06f4e1c9164a7871cb08d675cf20c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636825929820495738sdata=FeFqwQi9AUVDWaUw7lLMtAci6wWjE44vqwwjVwysY3o%3Dreserved=0
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] nir: rename global/local to private/function memory

[Ian Romanick]

On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
>> the naming is a bit confusing no matter how you look at it. Within SPIR-V
>> "global" memory is memory accessible from all threads. glsl "global" memory
>> normally refers to shader thread private memory declared at global scope. As
>> we already use "shared" for memory shared across all thrads of a work group
>> the solution where everybody could be happy with is to rename "global" to
>> "private" and use "global" later for memory usually stored within system
>> accessible memory (be it VRAM or system RAM if keeping SVM in mind).
>> glsl "local" memory is memory only accessible within a function, while SPIR-V
>> "local" memory is memory accessible within the same workgroup.
>>
>> v2: rename local to function as well
>>
>> Signed-off-by: Karol Herbst 
> 
> I strongly dislike this patch, and I think we ought to revert it.
> 
> This probably makes sense from an OpenCL memory-model view of the world,
> but it's really confusing from a compiler or general programming point
> of view.
> 
> /Everybody/ knows what a local variable is.  It's one of the most used
> concepts in programming.  Calling it nir_var_function is very confusing.
> The variable is a...function?  Maybe it's a function pointer?  Neither
> of those things even exist in GLSL, so...what the heck is it?
> 
> Renaming global scope variables to "private" is also confusing IMO.
> They're certainly not private to a function.  They're globally
> accessible by anything in the whole shader.  I'll admit "global" isn't
> a great name either.

It seems like the concepts we're after a function local and thread
local, so why not nir_var_thread_local (for old nir_var_global) and
nir_var_function_local (for old nir_var_local).  When "global" is
reintroduced to mean thread global, we could add it as
nir_var_thread_global.  That seems to match at least one reasonable view
of a storage hierarchy.

> I think we need to discuss this more.  There are people with large
> series of outstanding work that now have to rebase on this flag day
> rename, and I don't think two people is enough consensus for renaming
> a core IR concept.  Can we find names we're all happy with?
> 
> --Ken



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: don't leak pipe_surface if pipe_context is not current

[Marek Olšák]

On Wed, Jan 9, 2019 at 11:58 AM Roland Scheidegger 
wrote:

> Am 08.01.19 um 21:03 schrieb Marek Olšák:
> > On Tue, Jan 8, 2019 at 12:54 PM Roland Scheidegger  > > wrote:
> >
> > Am 08.01.19 um 17:17 schrieb Marek Olšák:
> > > From: Marek Olšák mailto:marek.ol...@amd.com
> >>
> > >
> > > We have found some pipe_surface leaks internally.
> > >
> > > This is the same code as surface_destroy in radeonsi.
> > > Ideally, surface_destroy would be in pipe_screen.
> > > No, pipe_surfaces are not context objects.
> > Well they are supposed to be...
> > But yes mesa/st doesn't play by the rules there, so I guess that's
> > better than a leak...
> >
> >
> > If it was possible, I would change the rules. create_surface could stay
> > in pipe_context, but I would move surface_destroy into pipe_screen.
>
> I think st/mesa would still use (not just delete) the pipe_surface in
> other contexts? If so I don't like the proposal, because it's still a
> lie that pipe_surface is a context-based object.
>

>From the perspective of u_threaded_context, it's already a screen object.
(create_surface can be called from any thread and isn't allowed to interact
with the context)

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Fix with_gallium_icd to with_opencl_icd

[Dylan Baker]

Quoting Pierre Moreau (2019-01-09 14:03:45)
> `with_gallium_icd` is never used throughout the different Meson build
> files, whereas `with_opencl_icd` tracks whether or not `gallium-opencl`
> was set to "icd".
> 
> Signed-off-by: Pierre Moreau 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 601085e0552..e759bbf96a5 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -668,7 +668,7 @@ if _opencl != 'disabled'
>  else
>dep_clc = null_dep
>with_gallium_opencl = false
> -  with_gallium_icd = false
> +  with_opencl_icd = false
>  endif
>  
>  gl_pkgconfig_c_flags = []
> -- 
> 2.20.1
> 

please add:

Fixes: 42ea0631f108d82554339530d6c88aa1b448af1e
   ("meson: build clover")
Reviewed-by: Dylan Baker 

I'll add these and push this later unless anyone else objects or beats me to
it :)

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106595

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #20 from Timothy Arceri  ---
Should be fixed by:

commit ee8488ea3b99ad0632e5eac6defcef0264d8782c
Author: Rhys Perry 
Date:   Wed Jan 9 11:09:33 2019 +

ac/nir,radv,radeonsi/nir: use correct indices for interpolation intrinsics

Fixes artifacts in World of Warcraft when Multi-sample Alpha-Test is
enabled with DXVK.
It also fixes artifacts with Fallout 4's god rays with DXVK.
Various piglit interpolateAt*() tests under NIR are also fixed.

v2: formatting fix
update commit message to include Fallout 4 and the Fixes tag

Fixes: f4e499ec791 ('radv: add initial non-conformant radv vulkan driver')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106595
Signed-off-by: Rhys Perry 

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: Fix with_gallium_icd to with_opencl_icd

[Pierre Moreau]

`with_gallium_icd` is never used throughout the different Meson build
files, whereas `with_opencl_icd` tracks whether or not `gallium-opencl`
was set to "icd".

Signed-off-by: Pierre Moreau 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 601085e0552..e759bbf96a5 100644
--- a/meson.build
+++ b/meson.build
@@ -668,7 +668,7 @@ if _opencl != 'disabled'
 else
   dep_clc = null_dep
   with_gallium_opencl = false
-  with_gallium_icd = false
+  with_opencl_icd = false
 endif
 
 gl_pkgconfig_c_flags = []
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v10 12/20] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv

[Dylan Baker]

Quoting Pierre Moreau (2019-01-09 11:24:12)
> > thanks! Just FYI, our meson build uses - in option names, not _. And, I'd 
> > prefer
> > just "opencl-spirv".
> 
> Err right, I meant with '-' in the option name.  I am fine with 
> "opencl-spirv";
> I was initially going with "gallium-opencl-spirv" since the other
> clover-related command was named "gallium-opencl".
> 
> 
> > When I make the command line "gallium-opencl", we (Intel)
> > were still firmly in the not gallium world, now that we have iris and are 
> > moving
> > toward gallium I'm not sure I made the right decision :/
> 
> Easy: Intel can just drop all of its OpenCL drivers and embrace clover as the
> true one, that way everything is in the gallium word and there aren’t any
> confusions. :-D

Clover is at least much easier to build, and uses upstream LLVM :)

Unfortunately it seems like everyone is doing their own thing for OpenCL, since
we have our two different OpenCL drivers, there's the AMD ROCm one, and
obviously nvidia just does what they want.

> By the way, you made me spot an error in the root meson.build file:
> ```with_opencl_icd = _opencl == 'icd'```
> and a bit further down
> ```with_gallium_icd = false```
> I guess you were still hesitating on how to name it? ;-)
> I’ll send a separate patch to fix this.

oops! Although that looks more like copy-n-pasta too me :)

> 
> Pierre


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v10 12/20] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv

[Pierre Moreau]

> thanks! Just FYI, our meson build uses - in option names, not _. And, I'd 
> prefer
> just "opencl-spirv".

Err right, I meant with '-' in the option name.  I am fine with "opencl-spirv";
I was initially going with "gallium-opencl-spirv" since the other
clover-related command was named "gallium-opencl".


> When I make the command line "gallium-opencl", we (Intel)
> were still firmly in the not gallium world, now that we have iris and are 
> moving
> toward gallium I'm not sure I made the right decision :/

Easy: Intel can just drop all of its OpenCL drivers and embrace clover as the
true one, that way everything is in the gallium word and there aren’t any
confusions. :-D


By the way, you made me spot an error in the root meson.build file:
```with_opencl_icd = _opencl == 'icd'```
and a bit further down
```with_gallium_icd = false```
I guess you were still hesitating on how to name it? ;-)
I’ll send a separate patch to fix this.

Pierre


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v10 12/20] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv

[Dylan Baker]

Quoting Pierre Moreau (2019-01-09 10:54:52)
> On 2019-01-08 — 15:18, Dylan Baker wrote:
> [snip]
> > >dep_clc = dependency('libclc')
> > > +  dep_spirv_tools = dependency('SPIRV-Tools', required : false, version 
> > > : '>= 2018.0')
> > > +  # LLVMSPIRVLib is available at 
> > > https://github.com/KhronosGroup/SPIRV-LLVM-Translator
> > > +  dep_llvmspirvlib = dependency('LLVMSPIRVLib', required : false, 
> > > version : '>= 0.2.1')
> > > +  if dep_spirv_tools.found() and dep_llvmspirvlib.found()
> > > +pre_args += '-DCLOVER_ALLOW_SPIRV'
> > > +  endif
> > 
> > As-is this is what distros call "automagical", and they don't like it :). 
> > There
> > is a case like this is for xlib-lease as well, I'd really like this to have 
> > an
> > option to control it, something similar to the way that xlib-lease works.
> > 
> > Dylan
> [snip]
> 
> Absolutely! I can’t remember why I didn’t went that way. I’ll prepare a v11
> that only looks for the dependencies if an enable flag (I’m thinking
> `gallium_opencl_spirv` for Meson and `enable-opencl-spirv` for autotools) is
> specified, and the dependencies would now be mandatory.
> 
> Pierre

thanks! Just FYI, our meson build uses - in option names, not _. And, I'd prefer
just "opencl-spirv". When I make the command line "gallium-opencl", we (Intel)
were still firmly in the not gallium world, now that we have iris and are moving
toward gallium I'm not sure I made the right decision :/

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v10 12/20] configure.ac, meson: Check for SPIRV-Tools and llvm-spirv

[Pierre Moreau]

On 2019-01-08 — 15:18, Dylan Baker wrote:
[snip]
> >dep_clc = dependency('libclc')
> > +  dep_spirv_tools = dependency('SPIRV-Tools', required : false, version : 
> > '>= 2018.0')
> > +  # LLVMSPIRVLib is available at 
> > https://github.com/KhronosGroup/SPIRV-LLVM-Translator
> > +  dep_llvmspirvlib = dependency('LLVMSPIRVLib', required : false, version 
> > : '>= 0.2.1')
> > +  if dep_spirv_tools.found() and dep_llvmspirvlib.found()
> > +pre_args += '-DCLOVER_ALLOW_SPIRV'
> > +  endif
> 
> As-is this is what distros call "automagical", and they don't like it :). 
> There
> is a case like this is for xlib-lease as well, I'd really like this to have an
> option to control it, something similar to the way that xlib-lease works.
> 
> Dylan
[snip]

Absolutely! I can’t remember why I didn’t went that way. I’ll prepare a v11
that only looks for the dependencies if an enable flag (I’m thinking
`gallium_opencl_spirv` for Meson and `enable-opencl-spirv` for autotools) is
specified, and the dependencies would now be mandatory.

Pierre


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109259] Mesa compiled with LLVM/clang-7.0 segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109259

--- Comment #3 from Dylan Baker  ---
I'm confused, you're targeting generic x86_64, but compiling with -mavx and
-mavx2?

Additionally, there's a bug with SWR (I can't find it right now), due to global
constructors that mean that if you build SWR you have to have the special
instructions it relies on.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #25 from Roman Elshin  ---
But it definitely works here (just tested several other places with fights - no
hangs any more), are there any side effects expected?

I  think must be a way to add applying this patch in PKGBUILD (I am not
familiar with arch)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109201

--- Comment #11 from Alexander  ---
Created attachment 143041
  --> https://bugs.freedesktop.org/attachment.cgi?id=143041=edit
Comment 10

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #24 from Dmitry  ---
Mesa-git I can take from AUR. But I still don't understand how to use hook.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: use dithered alpha-to-coverage

[Rhys Perry]

Seems I sent the wrong commit message.

It was meant to be:
This matches the behaviour of AMDVLK and hides banding.
It is also seems to be allowed by the Vulkan spec.

Signed-off-by: Rhys Perry 

On Wed, 9 Jan 2019 at 14:40, Rhys Perry  wrote:
>
> This matches the behaviour of AMDVLK and hides banding
>
> TODO: run tests
> ---
>  src/amd/vulkan/radv_pipeline.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 3561d17aaba..26ee59f11dd 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -681,10 +681,11 @@ radv_pipeline_init_blend_state(struct radv_pipeline 
> *pipeline,
> else
> blend.cb_color_control |= S_028808_ROP3(V_028808_ROP3_COPY);
>
> -   blend.db_alpha_to_mask = S_028B70_ALPHA_TO_MASK_OFFSET0(2) |
> -   S_028B70_ALPHA_TO_MASK_OFFSET1(2) |
> -   S_028B70_ALPHA_TO_MASK_OFFSET2(2) |
> -   S_028B70_ALPHA_TO_MASK_OFFSET3(2);
> +   blend.db_alpha_to_mask = S_028B70_ALPHA_TO_MASK_OFFSET0(3) |
> +   S_028B70_ALPHA_TO_MASK_OFFSET1(1) |
> +   S_028B70_ALPHA_TO_MASK_OFFSET2(0) |
> +   S_028B70_ALPHA_TO_MASK_OFFSET3(2) |
> +   S_028B70_OFFSET_ROUND(1);
>
> if (vkms && vkms->alphaToCoverageEnable) {
> blend.db_alpha_to_mask |= S_028B70_ALPHA_TO_MASK_ENABLE(1);
> --
> 2.20.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: don't leak pipe_surface if pipe_context is not current

[Roland Scheidegger]

Am 08.01.19 um 21:03 schrieb Marek Olšák:
> On Tue, Jan 8, 2019 at 12:54 PM Roland Scheidegger  > wrote:
> 
> Am 08.01.19 um 17:17 schrieb Marek Olšák:
> > From: Marek Olšák mailto:marek.ol...@amd.com>>
> >
> > We have found some pipe_surface leaks internally.
> >
> > This is the same code as surface_destroy in radeonsi.
> > Ideally, surface_destroy would be in pipe_screen.
> > No, pipe_surfaces are not context objects.
> Well they are supposed to be...
> But yes mesa/st doesn't play by the rules there, so I guess that's
> better than a leak...
> 
> 
> If it was possible, I would change the rules. create_surface could stay
> in pipe_context, but I would move surface_destroy into pipe_screen.

I think st/mesa would still use (not just delete) the pipe_surface in
other contexts? If so I don't like the proposal, because it's still a
lie that pipe_surface is a context-based object.

Roland


> 
> Marek

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] llvmpipe: Always return some fence in flush (v2)

[Roland Scheidegger]

Sorry but I had to revert this, as we've seen lots of assertion failures
(src/gallium/drivers/llvmpipe/lp_fence.c:120: lp_fence_wait: Assertion
`f->issued' failed.). For instance with libgl_xlib state tracker and piglit.
I'm not entirely sure if it's really safe to just remove the assert or
if it needs some more work, and I don't have time right now for a
thorough investigation, but I'll happily take new patches...

Roland


Am 09.01.19 um 02:09 schrieb Roland Scheidegger:
> Am 07.01.19 um 09:54 schrieb Tomasz Figa:
>> On Sun, Dec 23, 2018 at 12:55 AM Roland Scheidegger  
>> wrote:
>>>
>>> Alright, I guess it should work...
>>>
>>> Reviewed-by: Roland Scheidegger 
>>>
>>
>> Thanks!
>>
>> Would we have anyone who could help to commit it?
> 
> Pushed (albeit I forgot the R-b on it, ah well...)
> 
> Roland
> 
>>
>> (I know that I was supposed to apply for commit rights, but I expect
>> my contribution rate to be relatively low, due to a shift to different
>> areas, so I don't think I'm a good candidate for a committer anymore.)
>>
>> Best regards,
>> Tomasz
>>
>>>
>>> Am 14.12.18 um 09:17 schrieb Tomasz Figa:
 If there is no last fence, due to no rendering happening yet, just
 create a new signaled fence and return it, to match the expectations of
 the EGL sync fence API.

 Fixes random "Could not create sync fence 0x3003" assertion failures from
 Skia on Android, coming from the following code:

 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Flibs%2Fhwui%2Fpipeline%2Fskia%2FSkiaOpenGLPipeline.cpp%23427data=02%7C01%7Csroland%40vmware.com%7Ccb06f4e1c9164a7871cb08d675cf20c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636825929820495738sdata=6hmZk%2BXWaQk%2B5XAKjxFSybOSpCVwzvKemYgZQ1rtpvg%3Dreserved=0

 Reproducible especially with thread count >= 4.

 One could make the driver always keep the reference to the last fence,
 but:

  - the driver seems to explicitly destroy the fence whenever a rendering
pass completes and changing that would require a significant functional
change to the code. (Specifically, in lp_scene_end_rasterization().)

  - it still wouldn't solve the problem of an EGL sync fence being created
and waited on without any rendering happening at all, which is
also likely to happen with Android code pointed to in the commit.

 Therefore, the simple approach of always creating a fence is taken,
 similarly to other drivers, such as radeonsi.

 Tested with piglit llvmpipe suite with no regressions and following
 tests fixed:

 egl_khr_fence_sync
  conformance
   eglclientwaitsynckhr_flag_sync_flush
   eglclientwaitsynckhr_nonzero_timeout
   eglclientwaitsynckhr_zero_timeout
   eglcreatesynckhr_default_attributes
   eglgetsyncattribkhr_invalid_attrib
   eglgetsyncattribkhr_sync_status

 v2:
  - remove the useless lp_fence_reference() dance (Nicolai),
  - explain why creating the dummy fence is the right approach.

 Signed-off-by: Tomasz Figa 
 ---
  src/gallium/drivers/llvmpipe/lp_setup.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
 b/src/gallium/drivers/llvmpipe/lp_setup.c
 index b087369473..e72e119c8a 100644
 --- a/src/gallium/drivers/llvmpipe/lp_setup.c
 +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
 @@ -361,6 +361,8 @@ lp_setup_flush( struct lp_setup_context *setup,

 if (fence) {
lp_fence_reference((struct lp_fence **)fence, setup->last_fence);
 +  if (!*fence)
 + *fence = (struct pipe_fence_handle *)lp_fence_create(0);
 }
  }


>>>
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Csroland%40vmware.com%7Ccb06f4e1c9164a7871cb08d675cf20c7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636825929820495738sdata=FeFqwQi9AUVDWaUw7lLMtAci6wWjE44vqwwjVwysY3o%3Dreserved=0
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109201

--- Comment #10 from Samuel Pitoiset  ---
Can you attach the output of "R600_DEBUG=info glxgears" please?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109201

--- Comment #9 from Alexander  ---
(In reply to Samuel Pitoiset from comment #7)
> I have the game but I don't know to reproduce, can you give more
> explanations please?


First you accept a mission with the crosshair symbol . Then you free a target
from the egg and if you try to keep distance on the target, he will try to
shoot a fireball at you and the driver crashes

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109201

--- Comment #8 from Alexander  ---
(In reply to Alexander from comment #6)
> Note 2: Does not happen if i set the texture quality to low.

This is invalid

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #23 from Samuel Pitoiset  ---
(In reply to Dmitry from comment #22)
> I don't know how to use it.

You need to build mesa from git [1]

https://www.mesa3d.org/install.html

That said, it's actually unexpected that this hack fixes the problem.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #22 from Dmitry  ---
I don't know how to use it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #21 from Roman Elshin  ---
It looks like it fixes problem, thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: use dithered alpha-to-coverage

[Rhys Perry]

This matches the behaviour of AMDVLK and hides banding

TODO: run tests
---
 src/amd/vulkan/radv_pipeline.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 3561d17aaba..26ee59f11dd 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -681,10 +681,11 @@ radv_pipeline_init_blend_state(struct radv_pipeline 
*pipeline,
else
blend.cb_color_control |= S_028808_ROP3(V_028808_ROP3_COPY);
 
-   blend.db_alpha_to_mask = S_028B70_ALPHA_TO_MASK_OFFSET0(2) |
-   S_028B70_ALPHA_TO_MASK_OFFSET1(2) |
-   S_028B70_ALPHA_TO_MASK_OFFSET2(2) |
-   S_028B70_ALPHA_TO_MASK_OFFSET3(2);
+   blend.db_alpha_to_mask = S_028B70_ALPHA_TO_MASK_OFFSET0(3) |
+   S_028B70_ALPHA_TO_MASK_OFFSET1(1) |
+   S_028B70_ALPHA_TO_MASK_OFFSET2(0) |
+   S_028B70_ALPHA_TO_MASK_OFFSET3(2) |
+   S_028B70_OFFSET_ROUND(1);
 
if (vkms && vkms->alphaToCoverageEnable) {
blend.db_alpha_to_mask |= S_028B70_ALPHA_TO_MASK_ENABLE(1);
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] nir: rename global/local to private/function memory

[Jason Ekstrand]

On Tue, Jan 8, 2019 at 11:57 PM Kenneth Graunke 
wrote:

> On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> > the naming is a bit confusing no matter how you look at it. Within SPIR-V
> > "global" memory is memory accessible from all threads. glsl "global"
> memory
> > normally refers to shader thread private memory declared at global
> scope. As
> > we already use "shared" for memory shared across all thrads of a work
> group
> > the solution where everybody could be happy with is to rename "global" to
> > "private" and use "global" later for memory usually stored within system
> > accessible memory (be it VRAM or system RAM if keeping SVM in mind).
> > glsl "local" memory is memory only accessible within a function, while
> SPIR-V
> > "local" memory is memory accessible within the same workgroup.
> >
> > v2: rename local to function as well
> >
> > Signed-off-by: Karol Herbst 
>
> I strongly dislike this patch, and I think we ought to revert it.
>

I'm fine with reverting it so that Matt can land stuff without the rebase
pain.  I thought it was just going to be one place and I tried to warn him
about it but we probably should have held off a bit longer.


> This probably makes sense from an OpenCL memory-model view of the world,
> but it's really confusing from a compiler or general programming point
> of view.
>
> /Everybody/ knows what a local variable is.  It's one of the most used
> concepts in programming.  Calling it nir_var_function is very confusing.
> The variable is a...function?  Maybe it's a function pointer?  Neither
> of those things even exist in GLSL, so...what the heck is it?
>

Do they? Is it? I'm going to try to convince you that the suggested rename
is at least not terrible and better than what we have today.  We'll see if
you buy it. :-)

The old names made perfect sense in a OpenGL 3.0 world when you look at a
single invocation of a shader.  You have global variables and local
variables just like you do in C.  Then you have inputs, outputs, and
uniforms which are magic globals which get pre-populated with data and/or
data is read from them at the end of the execution; a bit weird, but okay.
Since I/O is really just special globals, you really only have two scopes,
local and global, and local < global in terms of who can access it.

Ok, now step forward into 2019 with OpenGL 4.6, Vulkan, and compute.  We
now have "shared" variables and SSBOs which I'm going to, for the sake of
momentary sanity, call "universal" because they are accessible from all
threads in all stages in all workgroups.  Now we have four scopes and they
go universal > shared > global > local.  Wait, shared > global?  How does
that make sense?  It doesn't, really.  If you take a step back and stop
looking at your shader as if a single invocation is an entire program and
instead look at is as a single invocation of a massively multi-threaded
program, things start to make more sense.  Things that we used to call
"global" are no longer global in the C sense; they're now more of a
thread-local storage.  Compute shared variables aren't global either,
they're a sort of storage that's somewhere between thread-local and
universal which you could call workgroup-local.  Hopefully, you can start
to see where the new names come from.  So what about function-local
variables?  Now that we've got three *-local things, local is getting a bit
overloaded so we drop the "local" and call it "function".  What about what
we used to call "global" but which isn't really global anymore in the C
sense?  We could call it thread but that's a bit overloaded with SIMD since
a thread may contain many invocations.  We could call it "invocation" but
that's a bit long and clumsy so we went with "private" because it's private
in the sense that it's never touched by any other invocations.  I'll grant
that the name "private" is a bit weak but it's what SPIR-V used so we
decided to not be too creative.

If it helps, I hated the rename at first too but I've come to be ok with
it.  I'm not a huge fan of "function" and "private" but I don't really have
anything better and I am firmly convinced that "global" doesn't make sense
anymore.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] ac/nir, radv, radeonsi/nir: use correct indices for interpolation intrinsics

[Samuel Pitoiset]

On 1/9/19 3:22 PM, Rhys Perry wrote:

Fixes artifacts in World of Warcraft when Multi-sample Alpha-Test is
enabled.
It also fixes various piglit interpolateAt*() tests with NIR.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106595
Signed-off-by: Rhys Perry 
---
  src/amd/common/ac_nir_to_llvm.c  | 2 +-
  src/amd/common/ac_shader_abi.h   | 2 ++
  src/amd/vulkan/radv_nir_to_llvm.c| 2 ++
  src/gallium/drivers/radeonsi/si_shader_nir.c | 3 +++
  4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 6d97212b805..8fd8580087f 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2829,7 +2829,7 @@ static LLVMValueRef visit_interp(struct ac_nir_context 
*ctx,
LLVMValueRef src0 = NULL;
  
  	nir_variable *var = nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr));

-   int input_index = var->data.location - VARYING_SLOT_VAR0;
+   int input_index = ctx->abi->fs_input_attr_indices[var->data.location - 
VARYING_SLOT_VAR0];
switch (instr->intrinsic) {
case nir_intrinsic_interp_deref_at_centroid:
location = INTERP_CENTROID;
diff --git a/src/amd/common/ac_shader_abi.h b/src/amd/common/ac_shader_abi.h
index 6b9a91c92a9..4f51aa9b0c0 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -76,6 +76,8 @@ struct ac_shader_abi {
 * driver_location.
 */
LLVMValueRef *inputs;


newline

Also, missing Fixes tag?

Other than that, patch is:

Reviewed-by: Samuel Pitoiset 


+   /* Varying -> attribute number mapping. Also NIR-only */
+   unsigned fs_input_attr_indices[MAX_VARYING];
  
  	void (*emit_outputs)(struct ac_shader_abi *abi,

 unsigned max_outputs,
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 322b10b67a0..cd58167b766 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2239,6 +2239,8 @@ handle_fs_inputs(struct radv_shader_context *ctx,
  
  			if (LLVMIsUndef(interp_param))

ctx->shader_info->fs.flat_shaded_mask |= 1u << 
index;
+   if (i >= VARYING_SLOT_VAR0)
+   ctx->abi.fs_input_attr_indices[i - 
VARYING_SLOT_VAR0] = index;
++index;
} else if (i == VARYING_SLOT_CLIP_DIST0) {
int length = 
ctx->shader_info->info.ps.num_input_clips_culls;
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 0a692277f64..d5b8a8416d9 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -1019,6 +1019,9 @@ bool si_nir_build_llvm(struct si_shader_context *ctx, 
struct nir_shader *nir)
LLVMValueRef data[4];
unsigned loc = variable->data.location;
  
+			if (loc >= VARYING_SLOT_VAR0 && nir->info.stage == MESA_SHADER_FRAGMENT)

+   ctx->abi.fs_input_attr_indices[loc - 
VARYING_SLOT_VAR0] = input_idx / 4;
+
for (unsigned i = 0; i < attrib_count; i++) {
/* Packed components share the same location so 
skip
 * them if we have already processed the 
location.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir, radv, radeonsi/nir: use correct indices for interpolation intrinsics

[Rhys Perry]

Fixes artifacts in World of Warcraft when Multi-sample Alpha-Test is
enabled.
It also fixes various piglit interpolateAt*() tests with NIR.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106595
Signed-off-by: Rhys Perry 
---
 src/amd/common/ac_nir_to_llvm.c  | 2 +-
 src/amd/common/ac_shader_abi.h   | 2 ++
 src/amd/vulkan/radv_nir_to_llvm.c| 2 ++
 src/gallium/drivers/radeonsi/si_shader_nir.c | 3 +++
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 6d97212b805..8fd8580087f 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2829,7 +2829,7 @@ static LLVMValueRef visit_interp(struct ac_nir_context 
*ctx,
LLVMValueRef src0 = NULL;
 
nir_variable *var = 
nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr));
-   int input_index = var->data.location - VARYING_SLOT_VAR0;
+   int input_index = ctx->abi->fs_input_attr_indices[var->data.location - 
VARYING_SLOT_VAR0];
switch (instr->intrinsic) {
case nir_intrinsic_interp_deref_at_centroid:
location = INTERP_CENTROID;
diff --git a/src/amd/common/ac_shader_abi.h b/src/amd/common/ac_shader_abi.h
index 6b9a91c92a9..4f51aa9b0c0 100644
--- a/src/amd/common/ac_shader_abi.h
+++ b/src/amd/common/ac_shader_abi.h
@@ -76,6 +76,8 @@ struct ac_shader_abi {
 * driver_location.
 */
LLVMValueRef *inputs;
+   /* Varying -> attribute number mapping. Also NIR-only */
+   unsigned fs_input_attr_indices[MAX_VARYING];
 
void (*emit_outputs)(struct ac_shader_abi *abi,
 unsigned max_outputs,
diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index 322b10b67a0..cd58167b766 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -2239,6 +2239,8 @@ handle_fs_inputs(struct radv_shader_context *ctx,
 
if (LLVMIsUndef(interp_param))
ctx->shader_info->fs.flat_shaded_mask |= 1u << 
index;
+   if (i >= VARYING_SLOT_VAR0)
+   ctx->abi.fs_input_attr_indices[i - 
VARYING_SLOT_VAR0] = index;
++index;
} else if (i == VARYING_SLOT_CLIP_DIST0) {
int length = 
ctx->shader_info->info.ps.num_input_clips_culls;
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 0a692277f64..d5b8a8416d9 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -1019,6 +1019,9 @@ bool si_nir_build_llvm(struct si_shader_context *ctx, 
struct nir_shader *nir)
LLVMValueRef data[4];
unsigned loc = variable->data.location;
 
+   if (loc >= VARYING_SLOT_VAR0 && nir->info.stage == 
MESA_SHADER_FRAGMENT)
+   ctx->abi.fs_input_attr_indices[loc - 
VARYING_SLOT_VAR0] = input_idx / 4;
+
for (unsigned i = 0; i < attrib_count; i++) {
/* Packed components share the same location so 
skip
 * them if we have already processed the 
location.
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/3] radv: add support for VK_EXT_memory_budget

[Alex Smith]

Reviewed-by: Alex Smith 

for the series.

On Wed, 9 Jan 2019 at 13:37, Samuel Pitoiset 
wrote:

> A simple Vulkan extension that allows apps to query size and
> usage of all exposed memory heaps.
>
> The different usage values are not really accurate because
> they are per drm-fd, but they should be close enough.
>
> v3: - use atomic operations in the winsys
> v2: - add software counters for the different heaps in the winsys
> - improve budget/usage computations based on these counters
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c  | 72 +++
>  src/amd/vulkan/radv_extensions.py |  1 +
>  src/amd/vulkan/radv_radeon_winsys.h   |  4 ++
>  src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 38 +-
>  .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.c |  6 ++
>  .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.h |  4 ++
>  6 files changed, 124 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 279917f3e0c..4bf36f9f384 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1350,12 +1350,84 @@ void radv_GetPhysicalDeviceMemoryProperties(
> *pMemoryProperties = physical_device->memory_properties;
>  }
>
> +static void
> +radv_get_memory_budget_properties(VkPhysicalDevice physicalDevice,
> +
>  VkPhysicalDeviceMemoryBudgetPropertiesEXT *memoryBudget)
> +{
> +   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
> +   VkPhysicalDeviceMemoryProperties *memory_properties =
> >memory_properties;
> +   uint64_t visible_vram_size = radv_get_visible_vram_size(device);
> +   uint64_t vram_size = radv_get_vram_size(device);
> +   uint64_t gtt_size = device->rad_info.gart_size;
> +   uint64_t heap_budget, heap_usage;
> +
> +   /* For all memory heaps, the computation of budget is as follow:
> +*  heap_budget = heap_size - global_heap_usage +
> app_heap_usage
> +*
> +* The Vulkan spec 1.1.97 says that the budget should include any
> +* currently allocated device memory.
> +*
> +* Note that the application heap usages are not really accurate
> (eg.
> +* in presence of shared buffers).
> +*/
> +   if (vram_size) {
> +   heap_usage = device->ws->query_value(device->ws,
> +
> RADEON_ALLOCATED_VRAM);
> +
> +   heap_budget = vram_size -
> +   device->ws->query_value(device->ws,
> RADEON_VRAM_USAGE) +
> +   heap_usage;
> +
> +   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
> +   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
> +   }
> +
> +   if (visible_vram_size) {
> +   heap_usage = device->ws->query_value(device->ws,
> +
> RADEON_ALLOCATED_VRAM_VIS);
> +
> +   heap_budget = visible_vram_size -
> +   device->ws->query_value(device->ws,
> RADEON_VRAM_VIS_USAGE) +
> +   heap_usage;
> +
> +   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
> heap_budget;
> +   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] =
> heap_usage;
> +   }
> +
> +   if (gtt_size) {
> +   heap_usage = device->ws->query_value(device->ws,
> +RADEON_ALLOCATED_GTT);
> +
> +   heap_budget = gtt_size -
> +   device->ws->query_value(device->ws,
> RADEON_GTT_USAGE) +
> +   heap_usage;
> +
> +   memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
> +   memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
> +   }
> +
> +   /* The heapBudget and heapUsage values must be zero for array
> elements
> +* greater than or equal to
> +* VkPhysicalDeviceMemoryProperties::memoryHeapCount.
> +*/
> +   for (uint32_t i = memory_properties->memoryHeapCount; i <
> VK_MAX_MEMORY_HEAPS; i++) {
> +   memoryBudget->heapBudget[i] = 0;
> +   memoryBudget->heapUsage[i] = 0;
> +   }
> +}
> +
>  void radv_GetPhysicalDeviceMemoryProperties2(
> VkPhysicalDevicephysicalDevice,
> VkPhysicalDeviceMemoryProperties2  *pMemoryProperties)
>  {
> radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
>
>  >memoryProperties);
> +
> +   VkPhysicalDeviceMemoryBudgetPropertiesEXT *memory_budget =
> +   vk_find_struct(pMemoryProperties->pNext,
> +
> PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT);
> +   if (memory_budget)
> +   radv_get_memory_budget_properties(physicalDevice,
> memory_budget);
>  }
>
>  VkResult radv_GetMemoryHostPointerPropertiesEXT(
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index 9952bb9c1c6..491ed9d94c3 100644
> --- 

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #20 from Samuel Pitoiset  ---
Created attachment 143035
  --> https://bugs.freedesktop.org/attachment.cgi?id=143035=edit
VGT param hack

Can you try the attached patch? I really doubt it will fix the problem but it's
worth trying.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/3] radv: remove unnecessary returns in GetPhysicalDevice*Properties()

[Samuel Pitoiset]

These functions return nothing.

v2: - do it for GetPhysicalDeviceQueueFamilyProperties too

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 5581fe74e40..9acec30d4bd 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1299,7 +1299,7 @@ void radv_GetPhysicalDeviceQueueFamilyProperties(
 {
RADV_FROM_HANDLE(radv_physical_device, pdevice, physicalDevice);
if (!pQueueFamilyProperties) {
-   return 
radv_get_physical_device_queue_family_properties(pdevice, pCount, NULL);
+   radv_get_physical_device_queue_family_properties(pdevice, 
pCount, NULL);
return;
}
VkQueueFamilyProperties *properties[] = {
@@ -1318,7 +1318,7 @@ void radv_GetPhysicalDeviceQueueFamilyProperties2(
 {
RADV_FROM_HANDLE(radv_physical_device, pdevice, physicalDevice);
if (!pQueueFamilyProperties) {
-   return 
radv_get_physical_device_queue_family_properties(pdevice, pCount, NULL);
+   radv_get_physical_device_queue_family_properties(pdevice, 
pCount, NULL);
return;
}
VkQueueFamilyProperties *properties[] = {
@@ -1343,8 +1343,8 @@ void radv_GetPhysicalDeviceMemoryProperties2(
VkPhysicalDevicephysicalDevice,
VkPhysicalDeviceMemoryProperties2  *pMemoryProperties)
 {
-   return radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
- 
>memoryProperties);
+   radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
+  
>memoryProperties);
 }
 
 VkResult radv_GetMemoryHostPointerPropertiesEXT(
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 3/3] radv: add support for VK_EXT_memory_budget

[Samuel Pitoiset]

A simple Vulkan extension that allows apps to query size and
usage of all exposed memory heaps.

The different usage values are not really accurate because
they are per drm-fd, but they should be close enough.

v3: - use atomic operations in the winsys
v2: - add software counters for the different heaps in the winsys
- improve budget/usage computations based on these counters

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c  | 72 +++
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_radeon_winsys.h   |  4 ++
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 38 +-
 .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.c |  6 ++
 .../vulkan/winsys/amdgpu/radv_amdgpu_winsys.h |  4 ++
 6 files changed, 124 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 279917f3e0c..4bf36f9f384 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1350,12 +1350,84 @@ void radv_GetPhysicalDeviceMemoryProperties(
*pMemoryProperties = physical_device->memory_properties;
 }
 
+static void
+radv_get_memory_budget_properties(VkPhysicalDevice physicalDevice,
+ VkPhysicalDeviceMemoryBudgetPropertiesEXT 
*memoryBudget)
+{
+   RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
+   VkPhysicalDeviceMemoryProperties *memory_properties = 
>memory_properties;
+   uint64_t visible_vram_size = radv_get_visible_vram_size(device);
+   uint64_t vram_size = radv_get_vram_size(device);
+   uint64_t gtt_size = device->rad_info.gart_size;
+   uint64_t heap_budget, heap_usage;
+
+   /* For all memory heaps, the computation of budget is as follow:
+*  heap_budget = heap_size - global_heap_usage + app_heap_usage
+*
+* The Vulkan spec 1.1.97 says that the budget should include any
+* currently allocated device memory.
+*
+* Note that the application heap usages are not really accurate (eg.
+* in presence of shared buffers).
+*/
+   if (vram_size) {
+   heap_usage = device->ws->query_value(device->ws,
+RADEON_ALLOCATED_VRAM);
+
+   heap_budget = vram_size -
+   device->ws->query_value(device->ws, RADEON_VRAM_USAGE) +
+   heap_usage;
+
+   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
+   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
+   }
+
+   if (visible_vram_size) {
+   heap_usage = device->ws->query_value(device->ws,
+RADEON_ALLOCATED_VRAM_VIS);
+
+   heap_budget = visible_vram_size -
+   device->ws->query_value(device->ws, 
RADEON_VRAM_VIS_USAGE) +
+   heap_usage;
+
+   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
heap_budget;
+   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
heap_usage;
+   }
+
+   if (gtt_size) {
+   heap_usage = device->ws->query_value(device->ws,
+RADEON_ALLOCATED_GTT);
+
+   heap_budget = gtt_size -
+   device->ws->query_value(device->ws, RADEON_GTT_USAGE) +
+   heap_usage;
+
+   memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
+   memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
+   }
+
+   /* The heapBudget and heapUsage values must be zero for array elements
+* greater than or equal to
+* VkPhysicalDeviceMemoryProperties::memoryHeapCount.
+*/
+   for (uint32_t i = memory_properties->memoryHeapCount; i < 
VK_MAX_MEMORY_HEAPS; i++) {
+   memoryBudget->heapBudget[i] = 0;
+   memoryBudget->heapUsage[i] = 0;
+   }
+}
+
 void radv_GetPhysicalDeviceMemoryProperties2(
VkPhysicalDevicephysicalDevice,
VkPhysicalDeviceMemoryProperties2  *pMemoryProperties)
 {
radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
   
>memoryProperties);
+
+   VkPhysicalDeviceMemoryBudgetPropertiesEXT *memory_budget =
+   vk_find_struct(pMemoryProperties->pNext,
+  PHYSICAL_DEVICE_MEMORY_BUDGET_PROPERTIES_EXT);
+   if (memory_budget)
+   radv_get_memory_budget_properties(physicalDevice, 
memory_budget);
 }
 
 VkResult radv_GetMemoryHostPointerPropertiesEXT(
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 9952bb9c1c6..491ed9d94c3 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -105,6 +105,7 @@ EXTENSIONS = [
 

[Mesa-dev] [Bug 109259] Mesa compiled with LLVM/clang-7.0 segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109259

--- Comment #2 from Tomasz Paweł Gajc  ---
When building mesa with clang these flags are used
-pthread -mavx2 -mfma -mbmi2 -mf16c -DKNOB_ARCH=KNOB_ARCH_AVX2 
 with gcc
[-pthread -mavx -DKNOB_ARCH=KNOB_ARCH_AVX

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109259] Mesa compiled with LLVM/clang-7.0 segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109259

--- Comment #1 from Tomasz Paweł Gajc  ---
Build logs for mesa compiled with LLVM/clang-7.0.1 can be found here
https://abf.openmandriva.org/build_lists/351189

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109259] Mesa compiled with LLVM/clang-7.0 segfaults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109259

Bug ID: 109259
   Summary: Mesa compiled with LLVM/clang-7.0 segfaults
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: tpg...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Hi,

we have noticed that mesa-18.3.x segfault when it is compiled with
LLVM/clang-7.0.x and run on older hardware.

After some deep digging we noticed this may be related to missing AVX
instructions on these machines, even if we build for generic x86_64, i686
targets.

Fast workaround for eliminating segfaults was to build Mesa with gcc :(
https://github.com/OpenMandrivaAssociation/mesa/commit/4d330587a4d80012c5888e1a33a01a7a979b84e8

Rebuilding Mesa with LLVM/clang-7.0.1 still segfaults. 

Our users have reported this occurs on:
r600 driver
nvidia gfx card
AMD Athlon II X4 620
AMD Phenom II x4 N930
Intel Quad 9650
Intel i3 530

Links to bug reports:
https://issues.openmandriva.org/show_bug.cgi?id=2381
https://issues.openmandriva.org/show_bug.cgi?id=2393

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #19 from Dmitry  ---
C AMDVLK hangs only the game client, and with RADV the whole system. But it is
possible and the system hangs for seconds, have not checked Alt + Tab.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #18 from Samuel Pitoiset  ---
In your first comment you said "There is no such problem with AMDVLK."... So,
it also hangs with AMDVLK but recovery happens while with RADV the whole
machine freezes and you need a hard reboot?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] radv: skip draws with instance_count == 0

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Wed, Jan 9, 2019 at 10:03 AM Samuel Pitoiset
 wrote:
>
> Loosely based on RadeonSI.
>
> v2: - do not check for indexed draws
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index d1b8b3dee6a..7bde5e68089 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -3696,6 +3696,19 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
> radeon_check_space(cmd_buffer->device->ws,
>cmd_buffer->cs, 4096);
>
> +   if (likely(!info->indirect)) {
> +   /* SI-CI treat instance_count==0 as instance_count==1. There 
> is
> +* no workaround for indirect draws, but we can at least skip
> +* direct draws.
> +*/
> +   if (unlikely(!info->instance_count))
> +   return;
> +
> +   /* Handle count == 0. */
> +   if (unlikely(!info->count && !info->strmout_buffer))
> +   return;
> +   }
> +
> /* Use optimal packet order based on whether we need to sync the
>  * pipeline.
>  */
> --
> 2.20.1
>
> ___
> 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 1/3] radv: remove unnecessary return in GetPhysicalDeviceMemoryProperties2()

[andrey simiklit]

Hello,

Looks like the same fix could be done in the following functions:
radv_GetPhysicalDeviceQueueFamilyProperties
radv_GetPhysicalDeviceQueueFamilyProperties2
just for case if you want to fix all these issues:)

Regards,
Andrii.

On Mon, Jan 7, 2019 at 6:35 PM Samuel Pitoiset 
wrote:

> This function returns nothing.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 53aed1a15db..39bd47348a9 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1345,8 +1345,8 @@ void radv_GetPhysicalDeviceMemoryProperties2(
> VkPhysicalDevicephysicalDevice,
> VkPhysicalDeviceMemoryProperties2KHR   *pMemoryProperties)
>  {
> -   return radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
> -
>  >memoryProperties);
> +   radv_GetPhysicalDeviceMemoryProperties(physicalDevice,
> +
> >memoryProperties);
>  }
>
>  VkResult radv_GetMemoryHostPointerPropertiesEXT(
> --
> 2.20.1
>
> ___
> 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] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #17 from Dmitry  ---
Yes, always.
On AMDVLK hangs too, but then returns to normal operation.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109258

Bug ID: 109258
   Summary: Weston drm-backend.so seems to fail with Mesa master
and LIBGL_ALWAYS_SOFTWARE=1
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: EGL
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: bluescreen_aven...@verizon.net
QA Contact: mesa-dev@lists.freedesktop.org

Hi

I first noticed this on UDL/Displaylink, but now I see this on QXL too
Weston's gl-backend fails to initialize EGL, 0x3001 , and quits. 

I noticed it selects a (null) driver. I am not sure how long this issue has
been happening, it's not an immediate regression that I noticed, but I know it
used to work a few years ago IIRC. I tried to include everything relevant...

I reported this to the Wayland project as well, but it appears that they
suggested to report it here
https://gitlab.freedesktop.org/wayland/weston/issues/183

I tried different GALLIUM_DRIVERs as well

relevant variables:
COGL_RENDERER=egl_wayland
LIBGL_ALWAYS_SOFTWARE=1


Weston log output:
Date: 2019-01-09 UTC
[03:45:43.647] weston 5.0.90
   https://wayland.freedesktop.org
   Bug reports to:
https://gitlab.freedesktop.org/wayland/weston/issues/
   Build: 5.0.0-110-g13dda10f+
[03:45:43.649] Command line: weston
[03:45:43.650] OS: Linux, 4.19.0-1-686-pae, #1 SMP Debian 4.19.12-1
(2018-12-22), i686
[03:45:43.652] Using config file '/home/beccaholic/.config/weston.ini'
[03:45:43.653] Output repaint window is 7 ms maximum.
[03:45:43.654] Loading module
'/opt/lib/i386-linux-gnu/libweston-5/drm-backend.so'
[03:45:43.660] initializing drm backend
[03:45:43.671] logind: session control granted
[03:45:43.676] using /dev/dri/card0
[03:45:43.678] DRM: supports universal planes
[03:45:43.678] DRM: does not support atomic modesetting
[03:45:43.679] DRM: supports picture aspect ratio
[03:45:43.680] Loading module
'/opt/lib/i386-linux-gnu/libweston-5/gl-renderer.so'
pci id for fd 14: 1234:, driver (null)
[03:45:43.717] EGL client extensions: EGL_EXT_client_extensions
   EGL_EXT_device_base EGL_EXT_device_enumeration
   EGL_EXT_device_query EGL_EXT_platform_base
   EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug
   EGL_EXT_platform_wayland EGL_EXT_platform_x11
   EGL_MESA_platform_gbm
[03:45:43.718] failed to initialize display
[03:45:43.718] EGL error state: EGL_NOT_INITIALIZED (0x3001)
[03:45:43.719] failed to initialize egl
[03:45:43.720] fatal: failed to create compositor backend
[03:45:43.720] Internal warning: debug scope 'drm-backend' has not been
destroyed.

This is what I compiled Mesa with
meson --buildtype=plain --prefix=$INSTALLDIR
--libdir=$INSTALLDIR/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH) -Dgles1=true
-Dgles2=true -Dplatforms=x11,wayland,drm
-Dgallium-drivers=nouveau,svga,r300,r600,swrast,radeonsi,virgl
-Ddri-drivers=r200,nouveau,i915,i965 -Dosmesa=gallium -Dgallium-xa=true
-Dgbm=true -Dshared-glapi=true -Dshared-llvm=true -Dvulkan-drivers=intel,amd
-Dllvm=true build 

Could I possibly be missing an option?

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108878] OpenGL CTS KHR-GL31.transform_feedback.api_errors_test failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108878

--- Comment #5 from Ilia Mirkin  ---
(In reply to Hai from comment #4)
> Since ARB_geometry_shader4 is from OpenGL 3.2, this issue is a test case bug
> rather than mesa bug. Will close it.

Note that ARB_geometry_shader4 is actually a separate extension, with
functionality that's slightly different than what's included in GL 3.2 core.
Mesa has no current plans to implement that extension.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #16 from Samuel Pitoiset  ---
Is the GPU hang 100% reproducible for you guys? Maybe, it only affects
Polaris11 and Polaris12. (I only have Polaris10)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #15 from Dmitry  ---
Created attachment 143033
  --> https://bugs.freedesktop.org/attachment.cgi?id=143033=edit
r600_debug_info

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #14 from Samuel Pitoiset  ---
Can you attach the output of "R600_DEBUG=info glxgears" ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #13 from Dmitry  ---
Medium preset, 1080p, HairWorks off

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #12 from Samuel Pitoiset  ---
I tried multiple times, no hangs so far. What graphics settings are you using?

I tested on my RX480 with LLVM 7.0.1 and Mesa 18.3.1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #11 from Roman Elshin  ---
Yes, usually  hangs happens after just the first strike to it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109242] [RADV] The Witcher 3 system freeze

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109242

--- Comment #10 from Samuel Pitoiset  ---
Just installed your savegame, when do you have a GPU hang? When fighting with
that creature?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109201] Deep Rock Galactic: GPU Hang (Steam Play) (DXVK)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109201

--- Comment #7 from Samuel Pitoiset  ---
I have the game but I don't know to reproduce, can you give more explanations
please?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] radv: skip draws with instance_count == 0

[Samuel Pitoiset]

Loosely based on RadeonSI.

v2: - do not check for indexed draws

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index d1b8b3dee6a..7bde5e68089 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3696,6 +3696,19 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
radeon_check_space(cmd_buffer->device->ws,
   cmd_buffer->cs, 4096);
 
+   if (likely(!info->indirect)) {
+   /* SI-CI treat instance_count==0 as instance_count==1. There is
+* no workaround for indirect draws, but we can at least skip
+* direct draws.
+*/
+   if (unlikely(!info->instance_count))
+   return;
+
+   /* Handle count == 0. */
+   if (unlikely(!info->count && !info->strmout_buffer))
+   return;
+   }
+
/* Use optimal packet order based on whether we need to sync the
 * pipeline.
 */
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/12] nir: rename global/local to private/function memory

[Karol Herbst]

On Wed, Jan 9, 2019 at 6:57 AM Kenneth Graunke  wrote:
>
> On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> > the naming is a bit confusing no matter how you look at it. Within SPIR-V
> > "global" memory is memory accessible from all threads. glsl "global" memory
> > normally refers to shader thread private memory declared at global scope. As
> > we already use "shared" for memory shared across all thrads of a work group
> > the solution where everybody could be happy with is to rename "global" to
> > "private" and use "global" later for memory usually stored within system
> > accessible memory (be it VRAM or system RAM if keeping SVM in mind).
> > glsl "local" memory is memory only accessible within a function, while 
> > SPIR-V
> > "local" memory is memory accessible within the same workgroup.
> >
> > v2: rename local to function as well
> >
> > Signed-off-by: Karol Herbst 
>
> I strongly dislike this patch, and I think we ought to revert it.
>
> This probably makes sense from an OpenCL memory-model view of the world,
> but it's really confusing from a compiler or general programming point
> of view.
>
> /Everybody/ knows what a local variable is.  It's one of the most used
> concepts in programming.  Calling it nir_var_function is very confusing.
> The variable is a...function?  Maybe it's a function pointer?  Neither
> of those things even exist in GLSL, so...what the heck is it?
>
> Renaming global scope variables to "private" is also confusing IMO.
> They're certainly not private to a function.  They're globally
> accessible by anything in the whole shader.  I'll admit "global" isn't
> a great name either.
>
> I think we need to discuss this more.  There are people with large
> series of outstanding work that now have to rebase on this flag day
> rename, and I don't think two people is enough consensus for renaming
> a core IR concept.  Can we find names we're all happy with?
>
> --Ken

okay. I wouldn't mind that it gets reverted, the main idea behind it
was, that I have another patch pending reintroducing "global" for
global memory, which we need for kernels anyway and we wanted to run
into those rebase issues exactly because of that. The main conflict
here is that the current naming scheme is based on what the code sees,
but that doesn't help us if we want to express what a thread sees.
What is "global" in the former concept?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/5] ac/nir_to_llvm: fix type handling in image code

[Timothy Arceri]

The current code only strips off arrays and cannot find the type
for images that are struct members.

Instead of trying to get the image type from the variable, we just
get it directly from the deref instruction.
---
 src/amd/common/ac_nir_to_llvm.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 89c7617529..633cc0aa06 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2212,10 +2212,10 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
return sample_index;
 }
 
-static nir_variable *get_image_variable(const nir_intrinsic_instr *instr)
+static nir_deref_instr *get_image_deref(const nir_intrinsic_instr *instr)
 {
assert(instr->src[0].is_ssa);
-   return 
nir_deref_instr_get_variable(nir_instr_as_deref(instr->src[0].ssa->parent_instr));
+   return nir_instr_as_deref(instr->src[0].ssa->parent_instr);
 }
 
 static LLVMValueRef get_image_descriptor(struct ac_nir_context *ctx,
@@ -2230,7 +2230,7 @@ static void get_image_coords(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr,
 struct ac_image_args *args)
 {
-   const struct glsl_type *type = 
glsl_without_array(get_image_variable(instr)->type);
+   const struct glsl_type *type = get_image_deref(instr)->type;
 
LLVMValueRef src0 = get_src(ctx, instr->src[1]);
LLVMValueRef masks[] = {
@@ -2339,10 +2339,9 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
 const nir_intrinsic_instr *instr)
 {
LLVMValueRef res;
-   const nir_variable *var = get_image_variable(instr);
-   const struct glsl_type *type = var->type;
-
-   type = glsl_without_array(type);
+   const nir_deref_instr *image_deref = get_image_deref(instr);
+   const struct glsl_type *type = image_deref->type;
+   const nir_variable *var = nir_deref_instr_get_variable(image_deref);
 
const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
if (dim == GLSL_SAMPLER_DIM_BUF) {
@@ -2383,8 +2382,9 @@ static void visit_image_store(struct ac_nir_context *ctx,
  nir_intrinsic_instr *instr)
 {
LLVMValueRef params[8];
-   const nir_variable *var = get_image_variable(instr);
-   const struct glsl_type *type = glsl_without_array(var->type);
+   const nir_deref_instr *image_deref = get_image_deref(instr);
+   const struct glsl_type *type = image_deref->type;
+   const nir_variable *var = nir_deref_instr_get_variable(image_deref);
const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
LLVMValueRef glc = ctx->ac.i1false;
bool force_glc = ctx->ac.chip_class == SI;
@@ -2441,13 +2441,12 @@ static LLVMValueRef visit_image_atomic(struct 
ac_nir_context *ctx,
 {
LLVMValueRef params[7];
int param_count = 0;
-   const nir_variable *var = get_image_variable(instr);
+   const struct glsl_type *type = get_image_deref(instr)->type;
 
bool cmpswap = instr->intrinsic == 
nir_intrinsic_image_deref_atomic_comp_swap;
const char *atomic_name;
char intrinsic_name[64];
enum ac_atomic_op atomic_subop;
-   const struct glsl_type *type = glsl_without_array(var->type);
MAYBE_UNUSED int length;
 
bool is_unsigned = glsl_get_sampler_result_type(type) == GLSL_TYPE_UINT;
@@ -2533,8 +2532,7 @@ static LLVMValueRef visit_image_atomic(struct 
ac_nir_context *ctx,
 static LLVMValueRef visit_image_samples(struct ac_nir_context *ctx,
const nir_intrinsic_instr *instr)
 {
-   const nir_variable *var = get_image_variable(instr);
-   const struct glsl_type *type = glsl_without_array(var->type);
+   const struct glsl_type *type = get_image_deref(instr)->type;
 
struct ac_image_args args = { 0 };
args.dim = get_ac_sampler_dim(>ac, glsl_get_sampler_dim(type),
@@ -2552,8 +2550,7 @@ static LLVMValueRef visit_image_size(struct 
ac_nir_context *ctx,
 const nir_intrinsic_instr *instr)
 {
LLVMValueRef res;
-   const nir_variable *var = get_image_variable(instr);
-   const struct glsl_type *type = glsl_without_array(var->type);
+   const struct glsl_type *type = get_image_deref(instr)->type;
 
if (glsl_get_sampler_dim(type) == GLSL_SAMPLER_DIM_BUF)
return get_buffer_size(ctx, get_image_descriptor(ctx, instr, 
AC_DESC_BUFFER, false), true);
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/5] ac/nir_to_llvm: fix regression in bindless support

[Timothy Arceri]

This wasn't ported over when deref support was implemented.
---
 src/amd/common/ac_nir_to_llvm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 633cc0aa06..4f7b2e4dc2 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3284,7 +3284,12 @@ static LLVMValueRef get_sampler_desc(struct 
ac_nir_context *ctx,
deref_instr = nir_src_as_deref(deref_instr->parent);
}
descriptor_set = deref_instr->var->data.descriptor_set;
-   base_index = deref_instr->var->data.binding;
+
+   if (deref_instr->var->data.bindless) {
+   base_index = deref_instr->var->data.driver_location;
+   bindless = true;
+   } else
+   base_index = deref_instr->var->data.binding;
}
 
return ctx->abi->load_sampler_desc(ctx->abi,
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/5] radeonsi/nir: add missing pieces for bindless image/sampler support

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 33 +++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 2c95c62d99..256ef28bb1 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -912,6 +912,28 @@ si_nir_lookup_interp_param(struct ac_shader_abi *abi,
LLVMGetParam(ctx->main_fn, interp_param_idx) : NULL;
 }
 
+static LLVMValueRef
+get_bindless_index(struct ac_shader_abi *abi,
+  struct si_shader_context *ctx, unsigned base_index,
+  unsigned constant_index, LLVMValueRef dynamic_index)
+{
+   LLVMValueRef offset = LLVMConstInt(ctx->i32, base_index * 4, 0);
+   LLVMValueRef index = LLVMBuildAdd(ctx->ac.builder, dynamic_index,
+ LLVMConstInt(ctx->ac.i32, 
constant_index, 0), "");
+
+   /* Bindless uniforms are 64bit so multiple index by 8 */
+   index = LLVMBuildMul(ctx->ac.builder, index, LLVMConstInt(ctx->i32, 8, 
0), "");
+   offset = LLVMBuildAdd(ctx->ac.builder, offset, index, "");
+
+   LLVMValueRef ubo_index = abi->load_ubo(abi, ctx->ac.i32_0);
+
+   LLVMValueRef ret = ac_build_buffer_load(>ac, ubo_index, 1, NULL, 
offset,
+   NULL, 0, false, false, true, 
true);
+
+   return LLVMBuildBitCast(ctx->ac.builder, ret, ctx->i32, "");
+}
+
+
 static LLVMValueRef
 si_nir_load_sampler_desc(struct ac_shader_abi *abi,
 unsigned descriptor_set, unsigned base_index,
@@ -937,8 +959,17 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
LLVMValueRef list =
LLVMGetParam(ctx->main_fn, 
ctx->param_bindless_samplers_and_images);
 
-   /* dynamic_index is the bindless handle */
+   dynamic_index = dynamic_index ? dynamic_index : ctx->ac.i32_0;
+   dynamic_index = get_bindless_index(abi, ctx, base_index,
+  constant_index, 
dynamic_index);
+
if (image) {
+   /* For simplicity, bindless image descriptors use fixed
+* 16-dword slots for now.
+*/
+   dynamic_index = LLVMBuildMul(ctx->ac.builder, 
dynamic_index,
+LLVMConstInt(ctx->i32, 2, 0), "");
+
return si_load_image_desc(ctx, list, dynamic_index, 
desc_type,
  dcc_off, true);
}
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Partial bindless support for radeonsi NIR

[Timothy Arceri]

We still need core NIR support for various features such as
image/sampler in/outs etc. But this gets us a step closer.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/5] radeonsi/nir: get correct type for images inside structs

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 64acf41679..2c95c62d99 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -163,11 +163,12 @@ static void scan_instruction(struct tgsi_shader_info 
*info,
break;
}
case nir_intrinsic_image_deref_store: {
+   const nir_deref_instr *image_deref = 
nir_instr_as_deref(intr->src[0].ssa->parent_instr);
nir_variable *var = intrinsic_get_var(intr);
if (var->data.bindless) {
info->uses_bindless_images = true;
 
-   if (glsl_get_sampler_dim(var->type) == 
GLSL_SAMPLER_DIM_BUF)
+   if (glsl_get_sampler_dim(image_deref->type) == 
GLSL_SAMPLER_DIM_BUF)
info->uses_bindless_buffer_store = true;
else
info->uses_bindless_image_store = true;
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/5] ac/nir_to_llvm: add support for structs to get_sampler_desc()

[Timothy Arceri]

---
 src/amd/common/ac_nir_to_llvm.c | 45 +++--
 1 file changed, 26 insertions(+), 19 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 4f7b2e4dc2..99eb6fb573 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3261,27 +3261,34 @@ static LLVMValueRef get_sampler_desc(struct 
ac_nir_context *ctx,
base_index = tex_instr->sampler_index;
} else {
while(deref_instr->deref_type != nir_deref_type_var) {
-   unsigned array_size = 
glsl_get_aoa_size(deref_instr->type);
-   if (!array_size)
-   array_size = 1;
-
-   assert(deref_instr->deref_type == nir_deref_type_array);
-   nir_const_value *const_value = 
nir_src_as_const_value(deref_instr->arr.index);
-   if (const_value) {
-   constant_index += array_size * 
const_value->u32[0];
-   } else {
-   LLVMValueRef indirect = get_src(ctx, 
deref_instr->arr.index);
-
-   indirect = LLVMBuildMul(ctx->ac.builder, 
indirect,
-   LLVMConstInt(ctx->ac.i32, array_size, 
false), "");
+   if (deref_instr->deref_type == nir_deref_type_array) {
+   unsigned array_size = 
glsl_get_aoa_size(deref_instr->type);
+   if (!array_size)
+   array_size = 1;
+
+   nir_const_value *const_value = 
nir_src_as_const_value(deref_instr->arr.index);
+   if (const_value) {
+   constant_index += array_size * 
const_value->u32[0];
+   } else {
+   LLVMValueRef indirect = get_src(ctx, 
deref_instr->arr.index);
+
+   indirect = 
LLVMBuildMul(ctx->ac.builder, indirect,
+   LLVMConstInt(ctx->ac.i32, 
array_size, false), "");
+
+   if (!index)
+   index = indirect;
+   else
+   index = 
LLVMBuildAdd(ctx->ac.builder, index, indirect, "");
+   }
 
-if (!index)
-   index = indirect;
-   else
-   index = LLVMBuildAdd(ctx->ac.builder, 
index, indirect, "");
+   deref_instr = 
nir_src_as_deref(deref_instr->parent);
+   } else if (deref_instr->deref_type == 
nir_deref_type_struct) {
+   unsigned sidx = deref_instr->strct.index;
+   deref_instr = 
nir_src_as_deref(deref_instr->parent);
+   constant_index += 
glsl_get_record_location_offset(deref_instr->type, sidx);
+   } else {
+   unreachable("Unsupported deref type");
}
-
-   deref_instr = nir_src_as_deref(deref_instr->parent);
}
descriptor_set = deref_instr->var->data.descriptor_set;
 
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev