Re: [Mesa-dev] [Mesa-stable] [PATCH] radeonsi: add a workaround for bitfield_extract when count is 0
On 09/27/2018 10:01 PM, Timothy Arceri wrote:
> On 28/9/18 2:53 am, Tom Stellard wrote:
>> On 09/24/2018 11:51 PM, Samuel Pitoiset wrote:
>>>
>>>
>>> On 9/25/18 6:46 AM, Timothy Arceri wrote:
On 25/9/18 10:35 am, Marek Olšák wrote:
> Do you know what's broken in LLVM? Or is it a problem with the ISA?
I haven't actually dug any further. Adding Samuel to see if he remembers
more.
However according to the original bug report this is a regression when
going from LLVM 6 to LLVM 7. I see the issue on both polaris and vega.
>>>
>>> I didn't investigate either, it was just simpler to add a workaround in
>>> mesa than fixing LLVM.
>>
>> If you have a test case, I can take a look. There is still a lot of time
>> before 7.0.1 is released.
>
> Hi Tom,
>
> There is a renderdoc capture [1] attached to a RADV bug and an apitrace [2]
> attached to a seemingly unrelated radeonsi (VEGA) bug.
>
> In the apitrace from Civ VI there is incorrect rendering behind the chinese
> emperor on the loading screen.
>
> I've bisected the problem, reverting the following llvm commit fixes the
> issue.
>
> commit ae2a6132b3b998b91943e4ef74fda37313f3145b
> Author: Roman Lebedev
> Date: Fri Jun 15 09:56:52 2018 +
>
I believe the issue here is that the bfe intrinsic lowering in
InstCombineCalls.cpp
introduces poison values when size == 0, because it ends up generating:
'shl i32 %x, i32 32' instructions which results in a poison value, because
the shift value is >= the number of bits. This commit just uncovered the
problem by introducing a new sequence of instructions.
-Tom
> [InstCombine] Recommit: Fold (x << y) >> y -> x & (-1 >> y)
>
> Summary:
> We already do it for splat constants, but not just values.
> Also, undef cases are mostly non-functional.
>
> The original commit was reverted because
> it broke tests for amdgpu backend, which i didn't check.
> Now, the backed was updated to recognize these new
> patterns, so we are good.
>
> https://bugs.llvm.org/show_bug.cgi?id=37603
> https://rise4fun.com/Alive/cplX
>
> Reviewers: spatel, craig.topper, mareko, bogner, rampitec, nhaehnle,
> arsenm
>
> Reviewed By: spatel, rampitec, nhaehnle
>
> Subscribers: wdng, nhaehnle, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D47980
>
> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@334818
> 91177308-0d34-0410-b5e6-96231b3b80d8
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=107276
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=104602
>
>>
>> -Tom
>>
>>>
>
> Marek
>
> On Fri, Sep 21, 2018 at 10:38 PM, Timothy Arceri
> wrote:
>> This ports the fix from 3d41757788ac. Both LLVM 7 & 8 continue
>> to have this problem.
>>
>> It fixes rendering issues in some menu and loading screens of
>> Civ VI which can be seen in the trace from bug 104602.
>>
>> Note: This does not fix the black triangles on Vega for bug
>> 104602.
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104602
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107276
>> ---
>>.../drivers/radeonsi/si_shader_tgsi_alu.c | 41 ++-
>>1 file changed, 30 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
>> b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
>> index f54d025aec0..814362bc963 100644
>> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
>> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
>> @@ -494,18 +494,37 @@ static void emit_bfe(const struct
>> lp_build_tgsi_action *action,
>>struct lp_build_emit_data *emit_data)
>>{
>> struct si_shader_context *ctx = si_shader_context(bld_base);
>> - LLVMValueRef bfe_sm5;
>> - LLVMValueRef cond;
>> -
>> - bfe_sm5 = ac_build_bfe(>ac, emit_data->args[0],
>> - emit_data->args[1], emit_data->args[2],
>> - emit_data->info->opcode ==
>> TGSI_OPCODE_IBFE);
>>
>> - /* Correct for GLSL semantics. */
>> - cond = LLVMBuildICmp(ctx->ac.builder, LLVMIntUGE,
>> emit_data->args[2],
>> -LLVMConstInt(ctx->i32, 32, 0), "");
>> - emit_data->output[emit_data->chan] =
>> - LLVMBuildSelect(ctx->ac.builder, cond,
>> emit_data->args[0], bfe_sm5, "");
>> + if (HAVE_LLVM < 0x0700) {
>> + LLVMValueRef bfe_sm5 =
>> + ac_build_bfe(>ac, emit_data->args[0],
>> +emit_data->args[1],
>> emit_data->args[2],
>> +emit_data->info->opcode ==
>> TGSI_OPCODE_IBFE);
Re: [Mesa-dev] [PATCH] meson: Don't allow building EGL on on KMS systems or Haiku
Shouldn't it be possible to use the x11 platform (+drisw)?
On Mon, Oct 1, 2018 at 3:43 PM Dylan Baker wrote:
>
> Currently mesa only supports EGL for KMS (Linux, *BSD) systems and
> Haiku, we should actually enforce this. This fixes the default build on
> MacOS.
> ---
>
> meson.build | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 97693b91ecf..202f9d740d7 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -306,7 +306,10 @@ endif
>
> _egl = get_option('egl')
> if _egl == 'auto'
> - with_egl = with_dri and with_shared_glapi and with_platforms
> + with_egl = (
> +(system_has_kms_drm or with_platform_haiku) and
> +with_dri and with_shared_glapi and with_platforms
> + )
> elif _egl == 'true'
>if not with_dri
> error('EGL requires dri')
> @@ -316,6 +319,8 @@ elif _egl == 'true'
> error('No platforms specified, consider -Dplatforms=drm,x11,surfaceless
> at least')
>elif not ['disabled', 'dri'].contains(with_glx)
> error('EGL requires dri, but a GLX is being built without dri')
> + elif not (system_has_kms_drm or with_platform_haiku)
> +error('EGL is not valid on systems that don\'t use KMS except Haiku.')
>endif
>with_egl = true
> else
> --
> 2.19.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] st/va:Aligned image width and height to 16.
I haven't checked in detail, but vlVaGetImage appears to ignore the passed-in x/y/width/height parameters. What happens if e.g. you have a 1000x1000 surface, and I call vlVaGetImage(x=10,y=10,width=1,height=1)? Shouldn't it just return me one pixel? If this is legal, then these limits need to be taken account in vlVaGetImage. -ilia On Mon, Oct 1, 2018 at 10:57 PM Guttula, Suresh wrote: > > While calling ucopy* functions to copy data to image ,it passes box.width > which is calculated from surface . If the image buffer created for image > dimensions width=40 and u copy use surface width=48. Which is giving a wrong > stride for dst buffer. > > Thanks, > Suresh G > > Get Outlook for Android > > > From: Ilia Mirkin > Sent: Tuesday, October 2, 2018 7:53:09 AM > To: Sharma, Deepak > Cc: ML Mesa-dev; Guttula, Suresh > Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. > > Looking at vlVaGetImage, it looks like it just copies data into the > texture -- I don't see how UVD is implicated in this. Perhaps the > transfer's stride is being set wrong? Or maybe either > u_copy_nv12_to_yv12 or util_copy_rect (or one of the functions they > call) is having trouble? > On Mon, Oct 1, 2018 at 10:17 PM Sharma, Deepak wrote: > > > > 16 was considering UVD. > > > > in vlVagetImage, the width,height passed to function is not used but rather > > the surface width/height and that causes issue in this case,not sure how > > driver will handle that ? > > > > > > From: Ilia Mirkin > > Sent: Monday, October 1, 2018 6:49 PM > > To: Sharma, Deepak > > Cc: ML Mesa-dev; Guttula, Suresh > > Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. > > > > On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote: > > > > > > From: suresh guttula > > > > > > In case of decoding of resolution like 40x24, while allocating surface > > > video buffer is always aligned with macroblock width/height which is 16. > > > But when application tries to get data after decoding through > > > vaCreateImage > > > /vaGetImage, image width/height aligned with 2 and result a smaller image > > > buffer which causes the memory stomping issue. > > > > Shouldn't the driver be allocating a larger backing texture instead? > > Why 16 and not 8 or 32 or 4096? > > > > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
On Mon, 2018-10-01 at 21:54 -0400, Marek Olšák wrote:
> The patch I attached was written for 18.2. It won't apply on master.
> It looks the same, but the change is in a different function.
>
Ouch! The patch looks almost the same indeed :)
Thanks for it. I'll add to 18.2
J.A.
> Marek
>
> On Mon, Oct 1, 2018 at 6:25 PM Juan A. Suarez Romero
> wrote:
> >
> > On Mon, 2018-10-01 at 14:29 -0400, Marek Olšák wrote:
> > > The attached patch is for 18.2.
> > >
> >
> >
> > Not sure if I've explained myself correctly
> >
> >
> > The patch you're attaching is the same as 0d495bec25b ("radeonsi: NaN should
> > pass kill_if"), which is already in master and CCed to stable.
> >
> > But in order to apply this patch to 18.2, I need to cherry-pick too
> > 98f777f9d9c
> > ("radeonsi: remove fetch_args callbacks for ALU instructions"), which was
> > not
> > CCed to stable.
> >
> > So either I've apply both patches, or I apply none. It seems 0d495bec25b is
> > like
> > a fix for 98f777f9d9c, and as 98f777f9d9c is not CCed as stable, it seems
> > more
> > logical just to ignore 0d495bec25b. But I'd like to know what's your
> > preferrence.
> >
> > J.A.
> >
> >
> > > Thanks,
> > > Marek
> > > On Mon, Oct 1, 2018 at 4:14 AM Juan A. Suarez Romero
> > > wrote:
> > > >
> > > > On Mon, 2018-09-24 at 20:21 -0400, Marek Olšák wrote:
> > > > > Looks good to me.
> > > > >
> > > > > Marek
> > > >
> > > > This patch was nominated to stable, but I can't apply it on 18.2
> > > > because this
> > > > patch requires 98f777f9d9c ("radeonsi: remove fetch_args callbacks for
> > > > ALU
> > > > instructions"), which was not nominated.
> > > >
> > > > WDYT? Should both patches added to the 18.2 release, or just get them
> > > > out of the
> > > > release?
> > > >
> > > > J.A.
> > > >
> > > > >
> > > > > On Mon, Sep 24, 2018 at 2:29 AM, Axel Davy
> > > > > wrote:
> > > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
> > > > > > Fixes: https://github.com/iXit/Mesa-3D/issues/314
> > > > > >
> > > > > > For this application, NaN is passed to KILL_IF and is expected to
> > > > > > pass.
> > > > > >
> > > > > > v2: Explain in the code why UGE is used.
> > > > > >
> > > > > > Signed-off-by: Axel Davy
> > > > > > Reviewed-by: Marek Olšák
> > > > > >
> > > > > > CC:
> > > > > > ---
> > > > > > src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
> > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > > b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > > index f54d025aec0..a768b449047 100644
> > > > > > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > > @@ -60,7 +60,8 @@ static void kil_emit(const struct
> > > > > > lp_build_tgsi_action *action,
> > > > > >
> > > > > > for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> > > > > > LLVMValueRef value =
> > > > > > lp_build_emit_fetch(bld_base, inst, 0, i);
> > > > > > - conds[i] = LLVMBuildFCmp(builder,
> > > > > > LLVMRealOGE, value,
> > > > > > + /* UGE because NaN shouldn't get killed */
> > > > > > + conds[i] = LLVMBuildFCmp(builder,
> > > > > > LLVMRealUGE, value,
> > > > > > ctx->ac.f32_0, "");
> > > > > > }
> > > > > >
> > > > > > --
> > > > > > 2.18.0
> > > > > >
> > > > > > ___
> > > > > > mesa-stable mailing list
> > > > > > mesa-sta...@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> > > > >
> > > > > ___
> > > > > mesa-stable mailing list
> > > > > mesa-sta...@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel/fs: Fix a typo in need_matching_subreg_offset
On Mon, Oct 01, 2018 at 08:23:56PM -0500, Jason Ekstrand wrote: > This fixes a bunch of Vulkan subgroup tests on little core platforms. > > Fixes: 4150920b95 "intel/fs: Add a helper for emitting scan operations" > --- > src/intel/compiler/brw_fs_builder.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Caio Marcelo de Oliveira Filho ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
Looking at vlVaGetImage, it looks like it just copies data into the texture -- I don't see how UVD is implicated in this. Perhaps the transfer's stride is being set wrong? Or maybe either u_copy_nv12_to_yv12 or util_copy_rect (or one of the functions they call) is having trouble? On Mon, Oct 1, 2018 at 10:17 PM Sharma, Deepak wrote: > > 16 was considering UVD. > > in vlVagetImage, the width,height passed to function is not used but rather > the surface width/height and that causes issue in this case,not sure how > driver will handle that ? > > > From: Ilia Mirkin > Sent: Monday, October 1, 2018 6:49 PM > To: Sharma, Deepak > Cc: ML Mesa-dev; Guttula, Suresh > Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. > > On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote: > > > > From: suresh guttula > > > > In case of decoding of resolution like 40x24, while allocating surface > > video buffer is always aligned with macroblock width/height which is 16. > > But when application tries to get data after decoding through vaCreateImage > > /vaGetImage, image width/height aligned with 2 and result a smaller image > > buffer which causes the memory stomping issue. > > Shouldn't the driver be allocating a larger backing texture instead? > Why 16 and not 8 or 32 or 4096? > > -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
16 was considering UVD. in vlVagetImage, the width,height passed to function is not used but rather the surface width/height and that causes issue in this case,not sure how driver will handle that ? From: Ilia Mirkin Sent: Monday, October 1, 2018 6:49 PM To: Sharma, Deepak Cc: ML Mesa-dev; Guttula, Suresh Subject: Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16. On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote: > > From: suresh guttula > > In case of decoding of resolution like 40x24, while allocating surface > video buffer is always aligned with macroblock width/height which is 16. > But when application tries to get data after decoding through vaCreateImage > /vaGetImage, image width/height aligned with 2 and result a smaller image > buffer which causes the memory stomping issue. Shouldn't the driver be allocating a larger backing texture instead? Why 16 and not 8 or 32 or 4096? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
The patch I attached was written for 18.2. It won't apply on master.
It looks the same, but the change is in a different function.
Marek
On Mon, Oct 1, 2018 at 6:25 PM Juan A. Suarez Romero
wrote:
>
> On Mon, 2018-10-01 at 14:29 -0400, Marek Olšák wrote:
> > The attached patch is for 18.2.
> >
>
>
> Not sure if I've explained myself correctly
>
>
> The patch you're attaching is the same as 0d495bec25b ("radeonsi: NaN should
> pass kill_if"), which is already in master and CCed to stable.
>
> But in order to apply this patch to 18.2, I need to cherry-pick too
> 98f777f9d9c
> ("radeonsi: remove fetch_args callbacks for ALU instructions"), which was not
> CCed to stable.
>
> So either I've apply both patches, or I apply none. It seems 0d495bec25b is
> like
> a fix for 98f777f9d9c, and as 98f777f9d9c is not CCed as stable, it seems more
> logical just to ignore 0d495bec25b. But I'd like to know what's your
> preferrence.
>
> J.A.
>
>
> > Thanks,
> > Marek
> > On Mon, Oct 1, 2018 at 4:14 AM Juan A. Suarez Romero
> > wrote:
> > >
> > > On Mon, 2018-09-24 at 20:21 -0400, Marek Olšák wrote:
> > > > Looks good to me.
> > > >
> > > > Marek
> > >
> > > This patch was nominated to stable, but I can't apply it on 18.2 because
> > > this
> > > patch requires 98f777f9d9c ("radeonsi: remove fetch_args callbacks for ALU
> > > instructions"), which was not nominated.
> > >
> > > WDYT? Should both patches added to the 18.2 release, or just get them out
> > > of the
> > > release?
> > >
> > > J.A.
> > >
> > > >
> > > > On Mon, Sep 24, 2018 at 2:29 AM, Axel Davy wrote:
> > > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
> > > > > Fixes: https://github.com/iXit/Mesa-3D/issues/314
> > > > >
> > > > > For this application, NaN is passed to KILL_IF and is expected to
> > > > > pass.
> > > > >
> > > > > v2: Explain in the code why UGE is used.
> > > > >
> > > > > Signed-off-by: Axel Davy
> > > > > Reviewed-by: Marek Olšák
> > > > >
> > > > > CC:
> > > > > ---
> > > > > src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
> > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > index f54d025aec0..a768b449047 100644
> > > > > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > > @@ -60,7 +60,8 @@ static void kil_emit(const struct
> > > > > lp_build_tgsi_action *action,
> > > > >
> > > > > for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> > > > > LLVMValueRef value =
> > > > > lp_build_emit_fetch(bld_base, inst, 0, i);
> > > > > - conds[i] = LLVMBuildFCmp(builder,
> > > > > LLVMRealOGE, value,
> > > > > + /* UGE because NaN shouldn't get killed */
> > > > > + conds[i] = LLVMBuildFCmp(builder,
> > > > > LLVMRealUGE, value,
> > > > > ctx->ac.f32_0, "");
> > > > > }
> > > > >
> > > > > --
> > > > > 2.18.0
> > > > >
> > > > > ___
> > > > > mesa-stable mailing list
> > > > > mesa-sta...@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> > > >
> > > > ___
> > > > mesa-stable mailing list
> > > > mesa-sta...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
On Mon, Oct 1, 2018 at 9:47 PM Sharma, Deepak wrote: > > From: suresh guttula > > In case of decoding of resolution like 40x24, while allocating surface > video buffer is always aligned with macroblock width/height which is 16. > But when application tries to get data after decoding through vaCreateImage > /vaGetImage, image width/height aligned with 2 and result a smaller image > buffer which causes the memory stomping issue. Shouldn't the driver be allocating a larger backing texture instead? Why 16 and not 8 or 32 or 4096? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/va:Aligned image width and height to 16.
From: suresh guttula
In case of decoding of resolution like 40x24, while allocating surface
video buffer is always aligned with macroblock width/height which is 16.
But when application tries to get data after decoding through vaCreateImage
/vaGetImage, image width/height aligned with 2 and result a smaller image
buffer which causes the memory stomping issue.
Signed-off-by: suresh guttula
---
src/gallium/state_trackers/va/image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index 3f892c9..2fc47b7 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -123,8 +123,8 @@ vlVaCreateImage(VADriverContextP ctx, VAImageFormat
*format, int width, int heig
img->format = *format;
img->width = width;
img->height = height;
- w = align(width, 2);
- h = align(height, 2);
+ w = align(width, 16);
+ h = align(height, 16);
switch (format->fourcc) {
case VA_FOURCC('N','V','1','2'):
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel/fs: Fix a typo in need_matching_subreg_offset
This fixes a bunch of Vulkan subgroup tests on little core platforms.
Fixes: 4150920b95 "intel/fs: Add a helper for emitting scan operations"
---
src/intel/compiler/brw_fs_builder.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs_builder.h
b/src/intel/compiler/brw_fs_builder.h
index 7bee2aa0b9b..0cafaf50e56 100644
--- a/src/intel/compiler/brw_fs_builder.h
+++ b/src/intel/compiler/brw_fs_builder.h
@@ -795,7 +795,7 @@ namespace brw {
!gen_device_info_is_9lp(shader->devinfo))
return false;
- if (type_sz(type > 4))
+ if (type_sz(type) > 4)
return true;
if (opcode == BRW_OPCODE_MUL &&
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=107991 --- Comment #12 from Rob Stolarz --- I added a smaller apitrace that reproduces the issue under OpenGL; I wasn't able to use vktrace to capture the Vulkan GPU crash. vktrace seems to produce traces that only segfault when my GPU crashes (even on version 1.1.82.0 of vulkantools). To that end, I've added a Dolphin savestate that anyone with a copy of the NTSC GC version of The Legend of Zelda: Twilight Princess can use to replicate the issue in either the Vulkan or OpenGL renderers. Thanks for the detailed capture instructions, Kyle. -- 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 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=107991 --- Comment #11 from Rob Stolarz --- Created attachment 141829 --> https://bugs.freedesktop.org/attachment.cgi?id=141829=edit twilight princess savestate this is a savestate of gc twilight princess running on dolphin 5.0-8775 that reproduces the crash using both the vulkan and opengl renderers -- 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 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=107991 --- Comment #10 from Rob Stolarz --- Created attachment 141828 --> https://bugs.freedesktop.org/attachment.cgi?id=141828=edit apitrace using twilight princess -- 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] anv: Restrict some fast-clear values gen7-8
The Vulkan API was recently clarified to allow image views of different
formats to be used for rendering to the same image. Due to certain
incompatible clear-color encodings on gen7-8, we must be more careful
about which fast-clear values we allow.
Makes the following crucible test pass pre-SKL:
func.renderpass.clear.color-view-one
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105826
Cc:
---
The crucible test currently only exists in a merge request:
https://gitlab.freedesktop.org/mesa/crucible/merge_requests/11
src/intel/vulkan/anv_image.c | 36 ++
src/intel/vulkan/anv_private.h | 6 +
src/intel/vulkan/genX_cmd_buffer.c | 19 +---
3 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index b0d8c560adb..4eb06501f8d 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -156,6 +156,40 @@ add_surface(struct anv_image *image, struct anv_surface
*surf, uint32_t plane)
surf->isl.alignment_B);
}
+static bool
+all_formats_flt_xor_int(const struct gen_device_info *devinfo,
+ const struct VkImageCreateInfo *vk_info)
+{
+ if (!(vk_info->flags & VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT))
+ return true;
+
+ const VkImageFormatListCreateInfoKHR *fmt_list =
+ vk_find_struct_const(vk_info->pNext, IMAGE_FORMAT_LIST_CREATE_INFO_KHR);
+
+ if (!fmt_list || fmt_list->viewFormatCount == 0)
+ return false;
+
+ enum isl_format format =
+ anv_get_isl_format(devinfo, vk_info->format,
+ VK_IMAGE_ASPECT_COLOR_BIT, vk_info->tiling);
+
+ const bool is_int = isl_format_has_int_channel(format) ||
+ isl_format_has_uint_channel(format);
+
+ for (uint32_t i = 0; i < fmt_list->viewFormatCount; i++) {
+ enum isl_format view_format =
+ anv_get_isl_format(devinfo, fmt_list->pViewFormats[i],
+VK_IMAGE_ASPECT_COLOR_BIT, vk_info->tiling);
+
+ const bool view_is_int = isl_format_has_int_channel(view_format) ||
+ isl_format_has_uint_channel(view_format);
+
+ if (is_int != view_is_int)
+ return false;
+ }
+
+ return true;
+}
static bool
all_formats_ccs_e_compatible(const struct gen_device_info *devinfo,
@@ -593,6 +627,8 @@ anv_image_create(VkDevice _device,
image->usage = pCreateInfo->usage;
image->tiling = pCreateInfo->tiling;
image->disjoint = pCreateInfo->flags & VK_IMAGE_CREATE_DISJOINT_BIT;
+ image->fmts_flt_xor_int =
+ all_formats_flt_xor_int(>info, pCreateInfo);
image->needs_set_tiling = wsi_info && wsi_info->scanout;
image->drm_format_mod = isl_mod_info ? isl_mod_info->modifier :
DRM_FORMAT_MOD_INVALID;
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 60f40c7e2ae..07dcc9f9b37 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2641,6 +2641,12 @@ struct anv_image {
VkImageUsageFlags usage; /**< Superset of VkImageCreateInfo::usage. */
VkImageTiling tiling; /** VkImageCreateInfo::tiling */
+ /**
+* True if this image may be used with integer or float formats, but not
+* both.
+*/
+ bool fmts_flt_xor_int;
+
/** True if this is needs to be bound to an appropriately tiled BO.
*
* When not using modifiers, consumers such as X11, Wayland, and KMS need
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 099c30f3d66..da01795db10 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -322,9 +322,22 @@ color_attachment_compute_aux_usage(struct anv_device *
device,
render_area.extent.height != iview->extent.height)
att_state->fast_clear = false;
- /* On Broadwell and earlier, we can only handle 0/1 clear colors */
- if (GEN_GEN <= 8 && !att_state->clear_color_is_zero_one)
- att_state->fast_clear = false;
+ /* Broadwell and earlier have restrictions due to integer and float
+ * texture clears being viewed incorrectly for certain values. Float
+ * texture clears to 1.0 (0x3F80_) are encoded as 1 in the surface
+ * state. Integer texture clears to 1 (0x1) share the same encoding. To
+ * avoid this conflict, only allow clearing with ones if the image format
+ * type is immutable.
+ */
+ if (GEN_GEN <= 8) {
+ if (!iview->image->fmts_flt_xor_int &&
+ !att_state->clear_color_is_zero) {
+att_state->fast_clear = false;
+ } else if (iview->image->fmts_flt_xor_int &&
+!att_state->clear_color_is_zero_one) {
+att_state->fast_clear = false;
+ }
+ }
/* We only allow fast clears to the first slice of an image (level 0,
* layer 0) and
Re: [Mesa-dev] [Mesa-stable] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
On Mon, 2018-10-01 at 14:29 -0400, Marek Olšák wrote:
> The attached patch is for 18.2.
>
Not sure if I've explained myself correctly
The patch you're attaching is the same as 0d495bec25b ("radeonsi: NaN should
pass kill_if"), which is already in master and CCed to stable.
But in order to apply this patch to 18.2, I need to cherry-pick too 98f777f9d9c
("radeonsi: remove fetch_args callbacks for ALU instructions"), which was not
CCed to stable.
So either I've apply both patches, or I apply none. It seems 0d495bec25b is like
a fix for 98f777f9d9c, and as 98f777f9d9c is not CCed as stable, it seems more
logical just to ignore 0d495bec25b. But I'd like to know what's your
preferrence.
J.A.
> Thanks,
> Marek
> On Mon, Oct 1, 2018 at 4:14 AM Juan A. Suarez Romero
> wrote:
> >
> > On Mon, 2018-09-24 at 20:21 -0400, Marek Olšák wrote:
> > > Looks good to me.
> > >
> > > Marek
> >
> > This patch was nominated to stable, but I can't apply it on 18.2 because
> > this
> > patch requires 98f777f9d9c ("radeonsi: remove fetch_args callbacks for ALU
> > instructions"), which was not nominated.
> >
> > WDYT? Should both patches added to the 18.2 release, or just get them out
> > of the
> > release?
> >
> > J.A.
> >
> > >
> > > On Mon, Sep 24, 2018 at 2:29 AM, Axel Davy wrote:
> > > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
> > > > Fixes: https://github.com/iXit/Mesa-3D/issues/314
> > > >
> > > > For this application, NaN is passed to KILL_IF and is expected to
> > > > pass.
> > > >
> > > > v2: Explain in the code why UGE is used.
> > > >
> > > > Signed-off-by: Axel Davy
> > > > Reviewed-by: Marek Olšák
> > > >
> > > > CC:
> > > > ---
> > > > src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > index f54d025aec0..a768b449047 100644
> > > > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > > @@ -60,7 +60,8 @@ static void kil_emit(const struct
> > > > lp_build_tgsi_action *action,
> > > >
> > > > for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> > > > LLVMValueRef value =
> > > > lp_build_emit_fetch(bld_base, inst, 0, i);
> > > > - conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE,
> > > > value,
> > > > + /* UGE because NaN shouldn't get killed */
> > > > + conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE,
> > > > value,
> > > > ctx->ac.f32_0, "");
> > > > }
> > > >
> > > > --
> > > > 2.18.0
> > > >
> > > > ___
> > > > mesa-stable mailing list
> > > > mesa-sta...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> > >
> > > ___
> > > mesa-stable mailing list
> > > mesa-sta...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] vulkan: Disable randr lease for libxcb < 1.13
Just a follow-up to make sure this makes it into mesa-stable. I know the release window for 18.2.2 is coming up. On Thu, 27 Sep 2018 at 16:32, Dave Airlie wrote: > On Thu, 27 Sep 2018 at 15:40, Stuart Young wrote: > > > > Hi All, > > > > Can we get some feedback on this patch please? > > > > At the moment, we can't compile vulkan using libxcb < 1.13 due to the > use of the RandR lease mechanism. Dave Airlie (cc'd) did some work > previously to allow things to be compiled with libxcb 1.11/1.12, mainly by > ifdef'ing certain code with HAVE_DRI3_MODIFIERS so that it would compile, > but without the extra features that xcb 1.13+ provides. See commit > 7aeef2d4efdc809a698e "dri3: allow building against older xcb (v3)" for that. > > > > The patch (originally provided by Maxime) appears to solve the new build > issue, and in much the same way as Dave Airlie did with his previous patch. > > > > Note: If we "must have" xcb 1.13, then that's fine. But if that is the > case, then we need to update mesa's build deps so that this is explicit > (ie: effectively reverting Dave Airlie's commits on the issue). > > > > Pushed it, was building on old Ubuntu yesterday and forgot to actually > push it back out. > > Dave. > -- Stuart Young (aka Cefiar) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Replace checks for rb->Name with FlipY (v2)
On Mon, Sep 17, 2018 at 1:51 PM Fritz Koenig wrote:
>
> In the GL_MESA_framebuffer_flip_y implementation
> _mesa_is_winsys_fbo checks were replaced with
> FlipY checks. rb->Name is also used to determine
> if a buffer is winsys.
>
> v2: Fixes annotation [for emil]
>
> Fixes: ab05dd183cc ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
> ---
> src/mesa/drivers/dri/i965/brw_blorp.c| 20 +---
> src/mesa/drivers/dri/i965/intel_pixel_read.c | 4 ++--
> 2 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index ad747e0766..ad3a47ef03 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -1224,12 +1224,12 @@ do_single_blorp_clear(struct brw_context *brw, struct
> gl_framebuffer *fb,
>
> x0 = fb->_Xmin;
> x1 = fb->_Xmax;
> - if (rb->Name != 0) {
> - y0 = fb->_Ymin;
> - y1 = fb->_Ymax;
> - } else {
> + if (fb->FlipY) {
>y0 = rb->Height - fb->_Ymax;
>y1 = rb->Height - fb->_Ymin;
> + } else {
> + y0 = fb->_Ymin;
> + y1 = fb->_Ymax;
> }
>
> /* If the clear region is empty, just return. */
> @@ -1415,9 +1415,8 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
> if (!(mask & (BUFFER_BITS_DEPTH_STENCIL)))
>return;
>
> - uint32_t x0, x1, y0, y1, rb_name, rb_height;
> + uint32_t x0, x1, y0, y1, rb_height;
> if (depth_rb) {
> - rb_name = depth_rb->Name;
>rb_height = depth_rb->Height;
>if (stencil_rb) {
> assert(depth_rb->Width == stencil_rb->Width);
> @@ -1425,18 +1424,17 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
>}
> } else {
>assert(stencil_rb);
> - rb_name = stencil_rb->Name;
>rb_height = stencil_rb->Height;
> }
>
> x0 = fb->_Xmin;
> x1 = fb->_Xmax;
> - if (rb_name != 0) {
> - y0 = fb->_Ymin;
> - y1 = fb->_Ymax;
> - } else {
> + if (fb->FlipY) {
>y0 = rb_height - fb->_Ymax;
>y1 = rb_height - fb->_Ymin;
> + } else {
> + y0 = fb->_Ymin;
> + y1 = fb->_Ymax;
> }
>
> /* If the clear region is empty, just return. */
> diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
> b/src/mesa/drivers/dri/i965/intel_pixel_read.c
> index 6ed7895bc7..8a90b207ad 100644
> --- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
> +++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
> @@ -181,7 +181,7 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
> * tiled_to_linear a negative pitch so that it walks through the
> * client's data backwards as it walks through the renderbufer forwards.
> */
> - if (rb->Name == 0) {
> + if (ctx->ReadBuffer->FlipY) {
>yoffset = rb->Height - yoffset - height;
>pixels += (ptrdiff_t) (height - 1) * dst_pitch;
>dst_pitch = -dst_pitch;
> @@ -249,7 +249,7 @@ intel_readpixels_blorp(struct gl_context *ctx,
> return brw_blorp_download_miptree(brw, irb->mt, rb->Format, swizzle,
> irb->mt_level, x, y, irb->mt_layer,
> w, h, 1, GL_TEXTURE_2D, format, type,
> - rb->Name == 0, pixels, packing);
> + ctx->ReadBuffer->FlipY, pixels,
> packing);
> }
>
> void
> --
> 2.19.0.397.gdd90340f6a-goog
>
Any other comments? Or can this go in?
The relevant piglit test are:
https://lists.freedesktop.org/archives/piglit/2018-September/025060.html
https://lists.freedesktop.org/archives/piglit/2018-September/025090.html
I spoke with Jason offline about testing this better by using the fbo
option in piglit, but no progress on that yet.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] vulkan/wsi: Filter modifiers with ImageFormatProperties
Just because a modifier is returned for the given format, that doesn't
mean it works with all usages and flags. We need to filter the list by
calling vkGetPhysicalDeviceImageFormatProperties2.
---
src/vulkan/wsi/wsi_common.c | 32 +++-
src/vulkan/wsi/wsi_common.h | 1 +
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 52a91ad9450..6401f136849 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -76,6 +76,7 @@ wsi_device_init(struct wsi_device *wsi,
WSI_GET_CB(GetMemoryFdKHR);
WSI_GET_CB(GetPhysicalDeviceFormatProperties);
WSI_GET_CB(GetPhysicalDeviceFormatProperties2KHR);
+ WSI_GET_CB(GetPhysicalDeviceImageFormatProperties2);
WSI_GET_CB(ResetFences);
WSI_GET_CB(QueueSubmit);
WSI_GET_CB(WaitForFences);
@@ -289,7 +290,36 @@ wsi_create_native_image(const struct wsi_swapchain *chain,
wsi->GetPhysicalDeviceFormatProperties2KHR(wsi->pdevice,
pCreateInfo->imageFormat,
_props);
- modifier_prop_count = modifier_props_list.drmFormatModifierCount;
+
+ /* Call GetImageFormatProperties with every modifier and filter the list
+ * down to those that we know work.
+ */
+ modifier_prop_count = 0;
+ for (uint32_t i = 0; i < modifier_props_list.drmFormatModifierCount;
i++) {
+ VkPhysicalDeviceImageDrmFormatModifierInfoEXT mod_info = {
+.sType =
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT,
+.pNext = NULL,
+.drmFormatModifier = modifier_props[i].drmFormatModifier,
+ };
+ VkPhysicalDeviceImageFormatInfo2 format_info = {
+.sType = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_FORMAT_INFO_2,
+.pNext = _info,
+.format = pCreateInfo->imageFormat,
+.type = VK_IMAGE_TYPE_2D,
+.tiling = VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT,
+.usage = pCreateInfo->imageUsage,
+.flags = 0,
+ };
+ VkImageFormatProperties2 format_props = {
+.sType = VK_STRUCTURE_TYPE_IMAGE_FORMAT_PROPERTIES_2,
+.pNext = NULL,
+ };
+ result = wsi->GetPhysicalDeviceImageFormatProperties2(wsi->pdevice,
+ _info,
+ _props);
+ if (result == VK_SUCCESS)
+modifier_props[modifier_prop_count++] = modifier_props[i];
+ }
uint32_t max_modifier_count = 0;
for (uint32_t l = 0; l < num_modifier_lists; l++)
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index 69f0a52c3e8..c0c3eb3b873 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -103,6 +103,7 @@ struct wsi_device {
WSI_CB(GetMemoryFdKHR);
WSI_CB(GetPhysicalDeviceFormatProperties);
WSI_CB(GetPhysicalDeviceFormatProperties2KHR);
+ WSI_CB(GetPhysicalDeviceImageFormatProperties2);
WSI_CB(ResetFences);
WSI_CB(QueueSubmit);
WSI_CB(WaitForFences);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/5] anv, wsi: Move over to the real modifiers interface
Now that the DRM format modifiers extension has been released, we can move the WSI code over to use it instead of the pseudo-extension we were using before. There are a few small differences we have to account for but it's not bad. This probably shouldn't land until the extension is officially enabled (it's currently disabled) but now that things are public, I figure we can at least start reviewing the patches. Cc: Chad Versace Jason Ekstrand (5): vulkan: Enable the DRM modifiers extesion anv: Drop some VK_IMAGE_TILING_OPTIMAL checks vulkan/wsi: Move the ImageCreateInfo higher up vulkan/wsi: Use the interface from the real modifiers extension vulkan/wsi: Filter modifiers with ImageFormatProperties include/vulkan/vulkan_core.h | 68 src/intel/vulkan/anv_extensions.py | 1 + src/intel/vulkan/anv_formats.c | 15 ++-- src/intel/vulkan/anv_image.c | 35 +--- src/intel/vulkan/anv_wsi.c | 8 -- src/intel/vulkan/genX_cmd_buffer.c | 2 +- src/vulkan/registry/vk.xml | 2 +- src/vulkan/wsi/wsi_common.c| 124 - src/vulkan/wsi/wsi_common.h| 21 + 9 files changed, 194 insertions(+), 82 deletions(-) -- 2.17.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] vulkan/wsi: Use the interface from the real modifiers extension
The anv implementation still isn't quite complete, but we can at least
start using the structs from the real extension.
---
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_formats.c | 13 ---
src/intel/vulkan/anv_image.c | 29 +++---
src/intel/vulkan/anv_wsi.c | 8
src/vulkan/wsi/wsi_common.c| 61 --
src/vulkan/wsi/wsi_common.h| 20 +-
6 files changed, 72 insertions(+), 60 deletions(-)
diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan/anv_extensions.py
index d4915c95013..e8d2150e641 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -121,6 +121,7 @@ EXTENSIONS = [
Extension('VK_EXT_external_memory_dma_buf', 1, True),
Extension('VK_EXT_global_priority', 1,
'device->has_context_priority'),
+Extension('VK_EXT_image_drm_format_modifier', 1, False),
Extension('VK_EXT_shader_viewport_index_layer', 1, True),
Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen
>= 9'),
Extension('VK_EXT_vertex_attribute_divisor', 3, True),
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index d44aae1c127..89ec4965f9f 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -661,11 +661,12 @@ get_buffer_format_features(const struct gen_device_info
*devinfo,
static void
get_wsi_format_modifier_properties_list(const struct anv_physical_device
*physical_device,
VkFormat vk_format,
-struct
wsi_format_modifier_properties_list *list)
+struct
VkDrmFormatModifierPropertiesListEXT *list)
{
const struct anv_format *anv_format = anv_get_format(vk_format);
- VK_OUTARRAY_MAKE(out, list->modifier_properties, >modifier_count);
+ VK_OUTARRAY_MAKE(out, list->pDrmFormatModifierProperties,
+>drmFormatModifierCount);
/* This is a simplified list where all the modifiers are available */
assert(vk_format == VK_FORMAT_B8G8R8_SRGB ||
@@ -690,11 +691,11 @@ get_wsi_format_modifier_properties_list(const struct
anv_physical_device *physic
continue;
vk_outarray_append(, mod_props) {
- mod_props->modifier = modifiers[i];
+ mod_props->drmFormatModifier = modifiers[i];
if (isl_drm_modifier_has_aux(modifiers[i]))
-mod_props->modifier_plane_count = 2;
+mod_props->drmFormatModifierPlaneCount = 2;
else
-mod_props->modifier_plane_count = anv_format->n_planes;
+mod_props->drmFormatModifierPlaneCount = anv_format->n_planes;
}
}
}
@@ -732,7 +733,7 @@ void anv_GetPhysicalDeviceFormatProperties2(
vk_foreach_struct(ext, pFormatProperties->pNext) {
/* Use unsigned since some cases are not in the VkStructureType enum. */
switch ((unsigned)ext->sType) {
- case VK_STRUCTURE_TYPE_WSI_FORMAT_MODIFIER_PROPERTIES_LIST_MESA:
+ case VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT:
get_wsi_format_modifier_properties_list(physical_device, format,
(void *)ext);
break;
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 70594d6c053..2850349a619 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -109,6 +109,8 @@ choose_isl_tiling_flags(const struct anv_image_create_info
*anv_info,
case VK_IMAGE_TILING_LINEAR:
flags = ISL_TILING_LINEAR_BIT;
break;
+ case VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT:
+ flags = 1 << isl_mod_info->tiling;
}
if (anv_info->isl_tiling_flags)
@@ -117,9 +119,6 @@ choose_isl_tiling_flags(const struct anv_image_create_info
*anv_info,
if (legacy_scanout)
flags &= ISL_TILING_LINEAR_BIT | ISL_TILING_X_BIT;
- if (isl_mod_info)
- flags &= 1 << isl_mod_info->tiling;
-
assert(flags);
return flags;
@@ -563,10 +562,13 @@ anv_image_create(VkDevice _device,
const struct wsi_image_create_info *wsi_info =
vk_find_struct_const(pCreateInfo->pNext, WSI_IMAGE_CREATE_INFO_MESA);
- if (wsi_info && wsi_info->modifier_count > 0) {
+
+ if (pCreateInfo->tiling == VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT) {
+ const VkImageDrmFormatModifierListCreateInfoEXT *mod_info =
+ vk_find_struct_const(pCreateInfo->pNext,
IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT);
isl_mod_info = choose_drm_format_mod(>instance->physicalDevice,
- wsi_info->modifier_count,
- wsi_info->modifiers);
+ mod_info->drmFormatModifierCount,
+ mod_info->pDrmFormatModifiers);
[Mesa-dev] [PATCH 3/5] vulkan/wsi: Move the ImageCreateInfo higher up
Future changes will be easier if we can modify it based on whether or
not we're using modifiers.
---
src/vulkan/wsi/wsi_common.c | 43 +++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 3416fef3076..00d6b5dcaa7 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -228,6 +228,28 @@ wsi_create_native_image(const struct wsi_swapchain *chain,
.pNext = NULL,
};
+ const VkImageCreateInfo image_info = {
+ .sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO,
+ .pNext = _wsi_info,
+ .flags = 0,
+ .imageType = VK_IMAGE_TYPE_2D,
+ .format = pCreateInfo->imageFormat,
+ .extent = {
+ .width = pCreateInfo->imageExtent.width,
+ .height = pCreateInfo->imageExtent.height,
+ .depth = 1,
+ },
+ .mipLevels = 1,
+ .arrayLayers = 1,
+ .samples = VK_SAMPLE_COUNT_1_BIT,
+ .tiling = VK_IMAGE_TILING_OPTIMAL,
+ .usage = pCreateInfo->imageUsage,
+ .sharingMode = pCreateInfo->imageSharingMode,
+ .queueFamilyIndexCount = pCreateInfo->queueFamilyIndexCount,
+ .pQueueFamilyIndices = pCreateInfo->pQueueFamilyIndices,
+ .initialLayout = VK_IMAGE_LAYOUT_UNDEFINED,
+ };
+
uint32_t image_modifier_count = 0, modifier_prop_count = 0;
struct wsi_format_modifier_properties *modifier_props = NULL;
uint64_t *image_modifiers = NULL;
@@ -308,27 +330,6 @@ wsi_create_native_image(const struct wsi_swapchain *chain,
}
}
- const VkImageCreateInfo image_info = {
- .sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO,
- .pNext = _wsi_info,
- .flags = 0,
- .imageType = VK_IMAGE_TYPE_2D,
- .format = pCreateInfo->imageFormat,
- .extent = {
- .width = pCreateInfo->imageExtent.width,
- .height = pCreateInfo->imageExtent.height,
- .depth = 1,
- },
- .mipLevels = 1,
- .arrayLayers = 1,
- .samples = VK_SAMPLE_COUNT_1_BIT,
- .tiling = VK_IMAGE_TILING_OPTIMAL,
- .usage = pCreateInfo->imageUsage,
- .sharingMode = pCreateInfo->imageSharingMode,
- .queueFamilyIndexCount = pCreateInfo->queueFamilyIndexCount,
- .pQueueFamilyIndices = pCreateInfo->pQueueFamilyIndices,
- .initialLayout = VK_IMAGE_LAYOUT_UNDEFINED,
- };
result = wsi->CreateImage(chain->device, _info,
>alloc, >image);
if (result != VK_SUCCESS)
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] vulkan: Enable the DRM modifiers extesion
This commit changes one line in the XML to enable the DRM modifiers
extension and adds the resulting Vulkan header changes.
---
include/vulkan/vulkan_core.h | 68
src/vulkan/registry/vk.xml | 2 +-
2 files changed, 69 insertions(+), 1 deletion(-)
diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index 39f4dc6f05d..352a50d3834 100644
--- a/include/vulkan/vulkan_core.h
+++ b/include/vulkan/vulkan_core.h
@@ -147,6 +147,7 @@ typedef enum VkResult {
VK_ERROR_INCOMPATIBLE_DISPLAY_KHR = -103001,
VK_ERROR_VALIDATION_FAILED_EXT = -111001,
VK_ERROR_INVALID_SHADER_NV = -112000,
+VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT = -1000158000,
VK_ERROR_FRAGMENTATION_EXT = -1000161000,
VK_ERROR_NOT_PERMITTED_EXT = -1000174001,
VK_ERROR_OUT_OF_POOL_MEMORY_KHR = VK_ERROR_OUT_OF_POOL_MEMORY,
@@ -398,6 +399,12 @@ typedef enum VkStructureType {
VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_ADVANCED_STATE_CREATE_INFO_EXT =
1000148002,
VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_TO_COLOR_STATE_CREATE_INFO_NV =
1000149000,
VK_STRUCTURE_TYPE_PIPELINE_COVERAGE_MODULATION_STATE_CREATE_INFO_NV =
1000152000,
+VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_LIST_EXT = 1000158000,
+VK_STRUCTURE_TYPE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT = 1000158001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_IMAGE_DRM_FORMAT_MODIFIER_INFO_EXT =
1000158002,
+VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_LIST_CREATE_INFO_EXT =
1000158003,
+VK_STRUCTURE_TYPE_IMAGE_EXCPLICIT_DRM_FORMAT_MODIFIER_CREATE_INFO_EXT =
1000158004,
+VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT = 1000158005,
VK_STRUCTURE_TYPE_VALIDATION_CACHE_CREATE_INFO_EXT = 100016,
VK_STRUCTURE_TYPE_SHADER_MODULE_VALIDATION_CACHE_CREATE_INFO_EXT =
1000160001,
VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_BINDING_FLAGS_CREATE_INFO_EXT =
1000161000,
@@ -811,6 +818,7 @@ typedef enum VkImageType {
typedef enum VkImageTiling {
VK_IMAGE_TILING_OPTIMAL = 0,
VK_IMAGE_TILING_LINEAR = 1,
+VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT = 1000158000,
VK_IMAGE_TILING_BEGIN_RANGE = VK_IMAGE_TILING_OPTIMAL,
VK_IMAGE_TILING_END_RANGE = VK_IMAGE_TILING_LINEAR,
VK_IMAGE_TILING_RANGE_SIZE = (VK_IMAGE_TILING_LINEAR -
VK_IMAGE_TILING_OPTIMAL + 1),
@@ -1447,6 +1455,10 @@ typedef enum VkImageAspectFlagBits {
VK_IMAGE_ASPECT_PLANE_0_BIT = 0x0010,
VK_IMAGE_ASPECT_PLANE_1_BIT = 0x0020,
VK_IMAGE_ASPECT_PLANE_2_BIT = 0x0040,
+VK_IMAGE_ASPECT_MEMORY_PLANE_0_BIT_EXT = 0x0080,
+VK_IMAGE_ASPECT_MEMORY_PLANE_1_BIT_EXT = 0x0100,
+VK_IMAGE_ASPECT_MEMORY_PLANE_2_BIT_EXT = 0x0200,
+VK_IMAGE_ASPECT_MEMORY_PLANE_3_BIT_EXT = 0x0400,
VK_IMAGE_ASPECT_PLANE_0_BIT_KHR = VK_IMAGE_ASPECT_PLANE_0_BIT,
VK_IMAGE_ASPECT_PLANE_1_BIT_KHR = VK_IMAGE_ASPECT_PLANE_1_BIT,
VK_IMAGE_ASPECT_PLANE_2_BIT_KHR = VK_IMAGE_ASPECT_PLANE_2_BIT,
@@ -7676,6 +7688,62 @@ typedef struct
VkPipelineCoverageModulationStateCreateInfoNV {
#define VK_EXT_POST_DEPTH_COVERAGE_EXTENSION_NAME "VK_EXT_post_depth_coverage"
+#define VK_EXT_image_drm_format_modifier 1
+#define VK_EXT_EXTENSION_159_SPEC_VERSION 0
+#define VK_EXT_EXTENSION_159_EXTENSION_NAME "VK_EXT_extension_159"
+#define VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_SPEC_VERSION 1
+#define VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME
"VK_EXT_image_drm_format_modifier"
+
+typedef struct VkDrmFormatModifierPropertiesEXT {
+uint64_tdrmFormatModifier;
+uint32_tdrmFormatModifierPlaneCount;
+VkFormatFeatureFlagsdrmFormatModifierTilingFeatures;
+} VkDrmFormatModifierPropertiesEXT;
+
+typedef struct VkDrmFormatModifierPropertiesListEXT {
+VkStructureType sType;
+void*pNext;
+uint32_t drmFormatModifierCount;
+VkDrmFormatModifierPropertiesEXT*pDrmFormatModifierProperties;
+} VkDrmFormatModifierPropertiesListEXT;
+
+typedef struct VkPhysicalDeviceImageDrmFormatModifierInfoEXT {
+VkStructureTypesType;
+const void*pNext;
+uint64_t drmFormatModifier;
+} VkPhysicalDeviceImageDrmFormatModifierInfoEXT;
+
+typedef struct VkImageDrmFormatModifierListCreateInfoEXT {
+VkStructureTypesType;
+const void*pNext;
+uint32_t drmFormatModifierCount;
+const uint64_t*pDrmFormatModifiers;
+} VkImageDrmFormatModifierListCreateInfoEXT;
+
+typedef struct VkImageDrmFormatModifierExplicitCreateInfoEXT {
+VkStructureType sType;
+const void* pNext;
+uint64_t drmFormatModifier;
+uint32_t drmFormatModifierPlaneCount;
+const VkSubresourceLayout*pPlaneLayouts;
+} VkImageDrmFormatModifierExplicitCreateInfoEXT;
+
+typedef struct VkImageDrmFormatModifierPropertiesEXT {
+
[Mesa-dev] [PATCH 2/5] anv: Drop some VK_IMAGE_TILING_OPTIMAL checks
The DRM format modifiers extension adds a TILING_DRM_FORMAT_MODIFIER
which will be used for modifiers so we can no longer use OPTIMAL to
indicate tiled inside the driver.
---
src/intel/vulkan/anv_formats.c | 2 +-
src/intel/vulkan/anv_image.c | 6 +++---
src/intel/vulkan/genX_cmd_buffer.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 33faf7cc37f..d44aae1c127 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -508,7 +508,7 @@ get_image_format_features(const struct gen_device_info
*devinfo,
return 0;
struct anv_format_plane base_plane_format = plane_format;
- if (vk_tiling == VK_IMAGE_TILING_OPTIMAL) {
+ if (vk_tiling != VK_IMAGE_TILING_LINEAR) {
base_plane_format = anv_get_format_plane(devinfo, vk_format,
VK_IMAGE_ASPECT_COLOR_BIT,
VK_IMAGE_TILING_LINEAR);
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index b0d8c560adb..70594d6c053 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -334,7 +334,7 @@ make_surface(const struct anv_device *dev,
bool needs_shadow = false;
if (dev->info.gen <= 8 &&
(vk_info->flags & VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT) &&
- vk_info->tiling == VK_IMAGE_TILING_OPTIMAL) {
+ vk_info->tiling != VK_IMAGE_TILING_LINEAR) {
assert(isl_format_is_compressed(plane_format.isl_format));
tiling_flags = ISL_TILING_LINEAR_BIT;
needs_shadow = true;
@@ -829,7 +829,7 @@ anv_layout_to_aux_usage(const struct gen_device_info *
const devinfo,
return ISL_AUX_USAGE_NONE;
/* All images that use an auxiliary surface are required to be tiled. */
- assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
+ assert(image->planes[plane].surface.isl.tiling != ISL_TILING_LINEAR);
/* Stencil has no aux */
assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
@@ -953,7 +953,7 @@ anv_layout_to_fast_clear_type(const struct gen_device_info
* const devinfo,
return ANV_FAST_CLEAR_NONE;
/* All images that use an auxiliary surface are required to be tiled. */
- assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
+ assert(image->planes[plane].surface.isl.tiling != ISL_TILING_LINEAR);
/* Stencil has no aux */
assert(aspect != VK_IMAGE_ASPECT_STENCIL_BIT);
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 099c30f3d66..821506761e2 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -967,7 +967,7 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
if (base_layer >= anv_image_aux_layers(image, aspect, base_level))
return;
- assert(image->tiling == VK_IMAGE_TILING_OPTIMAL);
+ assert(image->planes[plane].surface.isl.tiling != ISL_TILING_LINEAR);
if (initial_layout == VK_IMAGE_LAYOUT_UNDEFINED ||
initial_layout == VK_IMAGE_LAYOUT_PREINITIALIZED) {
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108116] [vulkancts] stencil partial clear tests fail.
https://bugs.freedesktop.org/show_bug.cgi?id=108116 Bug ID: 108116 Summary: [vulkancts] stencil partial clear tests fail. Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org Fails on Vega with VK-GL-CTS 57d5e6cdd5365b92a3959e11ee4c7ab889e48cd0: dEQP-VK.api.image_clearing.core.partial_clear_depth_stencil_attachment.multiple_layers.s8_uint,Fail dEQP-VK.api.image_clearing.core.partial_clear_depth_stencil_attachment.single_layer.s8_uint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.partial_clear_depth_stencil_attachment.single_layer.s8_uint,Fail -- 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 108115] [vulkancts] dEQP-VK.subgroups.vote.graphics.subgroupallequal.* fails
https://bugs.freedesktop.org/show_bug.cgi?id=108115 Bug ID: 108115 Summary: [vulkancts] dEQP-VK.subgroups.vote.graphics.subgroupallequal.* fails Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org We thought for a while it was fixed in one of the release branches, but not master. However, AFAICT all release branches are now merged into master again. On Vega with VK-GL-CTS version 57d5e6cdd5365b92a3959e11ee4c7ab889e48cd0: dEQP-VK.subgroups.vote.graphics.subgroupallequal_bool,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_bvec2,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_bvec3,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_bvec4,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_double,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_dvec2,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_dvec3,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_dvec4,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_float,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_int,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_ivec2,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_ivec3,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_ivec4,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_uint,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_uvec2,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_uvec3,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_uvec4,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_vec2,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_vec3,Fail dEQP-VK.subgroups.vote.graphics.subgroupallequal_vec4,Fail -- 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 108114] [vulkancts] new VK_KHR_16bit_storage tests fail.
https://bugs.freedesktop.org/show_bug.cgi?id=108114 Bug ID: 108114 Summary: [vulkancts] new VK_KHR_16bit_storage tests fail. Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org On Vega as per VK-GL-CTS version 57d5e6cdd5365b92a3959e11ee4c7ab889e48cd0: dEQP-VK.ssbo.layout.instance_array_basic_type.std140.f16vec3,Fail dEQP-VK.ssbo.layout.instance_array_basic_type.std140.i16vec3,Fail dEQP-VK.ssbo.layout.instance_array_basic_type.std140.u16vec3,Fail dEQP-VK.ssbo.layout.instance_array_basic_type.std430.f16vec3,Fail dEQP-VK.ssbo.layout.instance_array_basic_type.std430.i16vec3,Fail dEQP-VK.ssbo.layout.instance_array_basic_type.std430.u16vec3,Fail dEQP-VK.ssbo.layout.random.16bit.all_shared_buffer.44,Fail dEQP-VK.ssbo.layout.random.16bit.basic_arrays.19,Fail dEQP-VK.ssbo.layout.random.16bit.basic_types.19,Fail dEQP-VK.ssbo.layout.random.16bit.nested_structs_instance_arrays.1,Fail dEQP-VK.ssbo.layout.random.16bit.nested_structs_instance_arrays.3,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.15,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.16,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.22,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.34,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.38,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.40,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.50,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.63,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.69,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.77,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.80,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.93,Fail dEQP-VK.ssbo.layout.random.16bit.relaxed.97,Fail dEQP-VK.ssbo.layout.random.16bit.unsized_arrays.17,Fail dEQP-VK.ssbo.layout.random.16bit.vector_types.13,Fail dEQP-VK.ssbo.layout.random.16bit.vector_types.5,Fail dEQP-VK.ssbo.layout.single_basic_type.std140.f16vec3,Fail dEQP-VK.ssbo.layout.single_basic_type.std140.i16vec3,Fail dEQP-VK.ssbo.layout.single_basic_type.std140.u16vec3,Fail dEQP-VK.ssbo.layout.single_basic_type.std430.f16vec3,Fail dEQP-VK.ssbo.layout.single_basic_type.std430.i16vec3,Fail dEQP-VK.ssbo.layout.single_basic_type.std430.u16vec3,Fail -- 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 108113] [vulkancts] r32g32b32 transfer operations not implemented
https://bugs.freedesktop.org/show_bug.cgi?id=108113 Bug ID: 108113 Summary: [vulkancts] r32g32b32 transfer operations not implemented Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: samuel.pitoi...@gmail.com Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org CC: mesa-dev@lists.freedesktop.org r32g32b32 is a nasty format, we only support sampling linear textures from it, no image stores or color attachment. commit d294898f8e66ef5664b7a63356ca263bb14d2bef Author: Jason Ekstrand Date: Fri Jul 20 17:30:42 2018 -0700 dEQP-VK: Add tests for blitting to/from linear images New Tests: dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color.*.linear_*_* dEQP-VK.api.copy_and_blit.core.blit_image.all_formats.color.*.*_linear_* Components: Vulkan Change-Id: I6457959e805b57cb088b23753c21910ef22f4061 added some failing tests. Failing tests on Vega: dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.multiple_layers.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.multiple_layers.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.multiple_layers.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.remaining_array_layers.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.remaining_array_layers.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.remaining_array_layers.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.remaining_array_layers_twostep.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.remaining_array_layers_twostep.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.remaining_array_layers_twostep.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.single_layer.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.single_layer.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.1d.linear.single_layer.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.multiple_layers.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.multiple_layers.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.multiple_layers.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.remaining_array_layers.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.remaining_array_layers.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.remaining_array_layers.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.remaining_array_layers_twostep.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.remaining_array_layers_twostep.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.remaining_array_layers_twostep.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.3d.linear.single_layer.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.core.clear_color_image.3d.linear.single_layer.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.core.clear_color_image.3d.linear.single_layer.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.multiple_layers.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.multiple_layers.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.multiple_layers.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.remaining_array_layers.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.remaining_array_layers.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.remaining_array_layers.r32g32b32_uint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.remaining_array_layers_twostep.r32g32b32_sfloat,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.remaining_array_layers_twostep.r32g32b32_sint,Fail dEQP-VK.api.image_clearing.dedicated_allocation.clear_color_image.1d.linear.remaining_array_layers_twostep.r32g32b32_uint,Fail
[Mesa-dev] [Bug 108082] warning: unknown warning option '-Wno-format-truncation' [-Wunknown-warning-option]
https://bugs.freedesktop.org/show_bug.cgi?id=108082 --- Comment #5 from Vinson Lee --- The warning messages do not appear with meson. -- 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 108112] [vulkancts] some of the coherent memory tests fail.
https://bugs.freedesktop.org/show_bug.cgi?id=108112 Bug ID: 108112 Summary: [vulkancts] some of the coherent memory tests fail. Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Vulkan/radeon Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl QA Contact: mesa-dev@lists.freedesktop.org As per the latest VK-GL-CTS commit (57d5e6cdd5365b92a3959e11ee4c7ab889e48cd0) several new failing coherent memory tests were added. Setting the GLC bit on all SSBO loads & stores fixed the tests, so the action item is to get nir to provide it. Failing tests on Vega: dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_nonlocal.buffer.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_nonlocal.image.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_nonlocal.image.frag,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_local.buffer.comp,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_local.buffer.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_local.image.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_nonlocal.buffer.guard_local.image.frag,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_nonlocal.buffer.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_nonlocal.image.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_nonlocal.image.frag,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.buffer.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.buffer.frag,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.image.vert,Fail dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.image.frag,Fail -- 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] meson: Don't allow building EGL on on KMS systems or Haiku
Currently mesa only supports EGL for KMS (Linux, *BSD) systems and
Haiku, we should actually enforce this. This fixes the default build on
MacOS.
---
meson.build | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 97693b91ecf..202f9d740d7 100644
--- a/meson.build
+++ b/meson.build
@@ -306,7 +306,10 @@ endif
_egl = get_option('egl')
if _egl == 'auto'
- with_egl = with_dri and with_shared_glapi and with_platforms
+ with_egl = (
+(system_has_kms_drm or with_platform_haiku) and
+with_dri and with_shared_glapi and with_platforms
+ )
elif _egl == 'true'
if not with_dri
error('EGL requires dri')
@@ -316,6 +319,8 @@ elif _egl == 'true'
error('No platforms specified, consider -Dplatforms=drm,x11,surfaceless at
least')
elif not ['disabled', 'dri'].contains(with_glx)
error('EGL requires dri, but a GLX is being built without dri')
+ elif not (system_has_kms_drm or with_platform_haiku)
+error('EGL is not valid on systems that don\'t use KMS except Haiku.')
endif
with_egl = true
else
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: Silence a bunch of unused variable warnings.
On Mon, Oct 1, 2018 at 8:04 AM Tapani Pälli wrote:
>
> maybe also move the declaration of ret closer to the actual usage in
> anv_wait_for_bo_fences?
Done.
>
> Reviewed-by: Tapani Pälli
Thanks!
>
> On 9/30/18 9:12 PM, Bas Nieuwenhuizen wrote:
> > All three are only used in asserts, so this silences release build
> > warnings.
> > ---
> > src/intel/vulkan/anv_blorp.c | 3 ++-
> > src/intel/vulkan/anv_queue.c | 2 +-
> > src/intel/vulkan/genX_cmd_buffer.c | 2 +-
> > 3 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index a1c359cf461..df535270241 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -1269,7 +1269,8 @@ void anv_CmdResolveImage(
> > const uint32_t layer_count =
> >anv_get_layerCount(dst_image, [r].dstSubresource);
> >
> > - VkImageAspectFlags src_mask = pRegions[r].srcSubresource.aspectMask,
> > + MAYBE_UNUSED VkImageAspectFlags
> > + src_mask = pRegions[r].srcSubresource.aspectMask,
> >dst_mask = pRegions[r].dstSubresource.aspectMask;
> >
> > assert(anv_image_aspects_compatible(src_mask, dst_mask));
> > diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
> > index e0c0a42069f..3a1fb40b6a1 100644
> > --- a/src/intel/vulkan/anv_queue.c
> > +++ b/src/intel/vulkan/anv_queue.c
> > @@ -542,7 +542,7 @@ anv_wait_for_bo_fences(struct anv_device *device,
> > bool waitAll,
> > uint64_t _timeout)
> > {
> > - int ret;
> > + MAYBE_UNUSED int ret;
> >
> > /* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and is supposed
> > * to block indefinitely timeouts <= 0. Unfortunately, this was broken
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > b/src/intel/vulkan/genX_cmd_buffer.c
> > index 099c30f3d66..d672f41d18b 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -931,7 +931,7 @@ transition_color_buffer(struct anv_cmd_buffer
> > *cmd_buffer,
> > assert(level_count != VK_REMAINING_MIP_LEVELS &&
> > layer_count != VK_REMAINING_ARRAY_LAYERS);
> > /* Ensure the subresource range is valid. */
> > - uint64_t last_level_num = base_level + level_count;
> > + MAYBE_UNUSED uint64_t last_level_num = base_level + level_count;
> > const uint32_t max_depth = anv_minify(image->extent.depth, base_level);
> > UNUSED const uint32_t image_layers = MAX2(image->array_size,
> > max_depth);
> > assert((uint64_t)base_layer + layer_count <= image_layers);
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
The attached patch is for 18.2.
Thanks,
Marek
On Mon, Oct 1, 2018 at 4:14 AM Juan A. Suarez Romero
wrote:
>
> On Mon, 2018-09-24 at 20:21 -0400, Marek Olšák wrote:
> > Looks good to me.
> >
> > Marek
>
> This patch was nominated to stable, but I can't apply it on 18.2 because this
> patch requires 98f777f9d9c ("radeonsi: remove fetch_args callbacks for ALU
> instructions"), which was not nominated.
>
> WDYT? Should both patches added to the 18.2 release, or just get them out of
> the
> release?
>
> J.A.
>
> >
> > On Mon, Sep 24, 2018 at 2:29 AM, Axel Davy wrote:
> > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
> > > Fixes: https://github.com/iXit/Mesa-3D/issues/314
> > >
> > > For this application, NaN is passed to KILL_IF and is expected to
> > > pass.
> > >
> > > v2: Explain in the code why UGE is used.
> > >
> > > Signed-off-by: Axel Davy
> > > Reviewed-by: Marek Olšák
> > >
> > > CC:
> > > ---
> > > src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > index f54d025aec0..a768b449047 100644
> > > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > > @@ -60,7 +60,8 @@ static void kil_emit(const struct lp_build_tgsi_action
> > > *action,
> > >
> > > for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> > > LLVMValueRef value =
> > > lp_build_emit_fetch(bld_base, inst, 0, i);
> > > - conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE,
> > > value,
> > > + /* UGE because NaN shouldn't get killed */
> > > + conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE,
> > > value,
> > > ctx->ac.f32_0, "");
> > > }
> > >
> > > --
> > > 2.18.0
> > >
> > > ___
> > > mesa-stable mailing list
> > > mesa-sta...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
From fd07beec20327c84eed6a3eff21ec02767382476 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marek=20Ol=C5=A1=C3=A1k?=
Date: Mon, 1 Oct 2018 14:29:20 -0400
Subject: [PATCH] radeonsi: NaN should pass kill_if
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index c51d057967c..617ad6d60c2 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -36,7 +36,8 @@ static void kill_if_fetch_args(struct lp_build_tgsi_context *bld_base,
for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
LLVMValueRef value = lp_build_emit_fetch(bld_base, inst, 0, i);
- conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE, value,
+ /* UGE because NaN shouldn't get killed */
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE, value,
ctx->ac.f32_0, "");
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: disable HTILE for very small depth surfaces
What improvement do you get from this?
Thanks,
Marek
On Fri, Sep 28, 2018 at 10:27 AM Samuel Pitoiset
wrote:
>
> Like we disable DCC/CMASK for small color surfaces as well.
> Serious Sam 2017 creates a 1x1 depth surface and I think
> it should be faster to decompress compared to the benefit
> of fast clears.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_image.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index 658ccb65be..64346aa340 100644
> --- a/src/amd/vulkan/radv_image.c
> +++ b/src/amd/vulkan/radv_image.c
> @@ -923,7 +923,9 @@ radv_image_can_enable_fmask(struct radv_image *image)
> static inline bool
> radv_image_can_enable_htile(struct radv_image *image)
> {
> - return image->info.levels == 1 &&
> vk_format_is_depth(image->vk_format);
> + return image->info.levels == 1 &&
> + vk_format_is_depth(image->vk_format) &&
> + image->info.width * image->info.height >= 8 * 8;
> }
>
> VkResult
> --
> 2.19.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] radv: Add support for VK_KHR_driver_properties.
On Mon, Oct 1, 2018 at 12:41 PM Eric Engestrom
wrote:
> On Sunday, 2018-09-30 20:03:49 +0200, Bas Nieuwenhuizen wrote:
> > ---
> > src/amd/vulkan/radv_device.c | 27 +++
> > src/amd/vulkan/radv_extensions.py | 1 +
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> > index f7752eac83b..fe7e7f7f6ac 100644
> > --- a/src/amd/vulkan/radv_device.c
> > +++ b/src/amd/vulkan/radv_device.c
> > @@ -1196,6 +1196,33 @@ void radv_GetPhysicalDeviceProperties2(
> >
> properties->conservativeRasterizationPostDepthCoverage = VK_FALSE;
> > break;
> > }
> > + case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR: {
> > + VkPhysicalDeviceDriverPropertiesKHR *driver_props =
> > + (VkPhysicalDeviceDriverPropertiesKHR *)
> ext;
> > +
> > + driver_props->driverID =
> VK_DRIVER_ID_MESA_RADV_KHR;
> > + memset(driver_props->driverName, 0,
> VK_MAX_DRIVER_NAME_SIZE_KHR);
> > + strcpy(driver_props->driverName, "radv");
> > +
> > + memset(driver_props->driverInfo, 0,
> VK_MAX_DRIVER_INFO_SIZE_KHR);
> > + snprintf(driver_props->driverInfo,
> VK_MAX_DRIVER_INFO_SIZE_KHR,
> > + "Mesa " PACKAGE_VERSION
> > +#ifdef MESA_GIT_SHA1
> > + " ("MESA_GIT_SHA1")"
> > +#endif
>
> Since bc8abc1adf0355b54e55 "bin: always define MESA_GIT_SHA1 to make it
> directly usable in code", the #ifdef dance is no longer necessary :)
>
Neat! I'll update the anv patch accordingly.
> > + " (LLVM %i.%i.%i)",
> > + (HAVE_LLVM >> 8) & 0xff, HAVE_LLVM & 0xff,
> > + MESA_LLVM_VERSION_PATCH);
> > +
> > + driver_props->conformanceVersion =
> (VkConformanceVersionKHR) {
> > + .major = 1,
> > + .minor = 1,
> > + .subminor = 0,
> > + .patch = 2,
> > + };
> > + break;
> > + }
> > +
> > default:
> > break;
> > }
> > diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> > index 584926df390..8df5da76ed5 100644
> > --- a/src/amd/vulkan/radv_extensions.py
> > +++ b/src/amd/vulkan/radv_extensions.py
> > @@ -59,6 +59,7 @@ EXTENSIONS = [
> > Extension('VK_KHR_device_group', 1, True),
> > Extension('VK_KHR_device_group_creation', 1, True),
> > Extension('VK_KHR_draw_indirect_count', 1, True),
> > +Extension('VK_KHR_driver_properties', 1, True),
> > Extension('VK_KHR_external_fence',1,
> 'device->rad_info.has_syncobj_wait_for_submit'),
> > Extension('VK_KHR_external_fence_capabilities', 1, True),
> > Extension('VK_KHR_external_fence_fd', 1,
> 'device->rad_info.has_syncobj_wait_for_submit'),
> > --
> > 2.19.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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: Add support for VK_KHR_driver_properties.
On Sunday, 2018-09-30 20:03:49 +0200, Bas Nieuwenhuizen wrote:
> ---
> src/amd/vulkan/radv_device.c | 27 +++
> src/amd/vulkan/radv_extensions.py | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index f7752eac83b..fe7e7f7f6ac 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1196,6 +1196,33 @@ void radv_GetPhysicalDeviceProperties2(
> properties->conservativeRasterizationPostDepthCoverage
> = VK_FALSE;
> break;
> }
> + case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR: {
> + VkPhysicalDeviceDriverPropertiesKHR *driver_props =
> + (VkPhysicalDeviceDriverPropertiesKHR *) ext;
> +
> + driver_props->driverID = VK_DRIVER_ID_MESA_RADV_KHR;
> + memset(driver_props->driverName, 0,
> VK_MAX_DRIVER_NAME_SIZE_KHR);
> + strcpy(driver_props->driverName, "radv");
> +
> + memset(driver_props->driverInfo, 0,
> VK_MAX_DRIVER_INFO_SIZE_KHR);
> + snprintf(driver_props->driverInfo,
> VK_MAX_DRIVER_INFO_SIZE_KHR,
> + "Mesa " PACKAGE_VERSION
> +#ifdef MESA_GIT_SHA1
> + " ("MESA_GIT_SHA1")"
> +#endif
Since bc8abc1adf0355b54e55 "bin: always define MESA_GIT_SHA1 to make it
directly usable in code", the #ifdef dance is no longer necessary :)
> + " (LLVM %i.%i.%i)",
> + (HAVE_LLVM >> 8) & 0xff, HAVE_LLVM & 0xff,
> + MESA_LLVM_VERSION_PATCH);
> +
> + driver_props->conformanceVersion =
> (VkConformanceVersionKHR) {
> + .major = 1,
> + .minor = 1,
> + .subminor = 0,
> + .patch = 2,
> + };
> + break;
> + }
> +
> default:
> break;
> }
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index 584926df390..8df5da76ed5 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -59,6 +59,7 @@ EXTENSIONS = [
> Extension('VK_KHR_device_group', 1, True),
> Extension('VK_KHR_device_group_creation', 1, True),
> Extension('VK_KHR_draw_indirect_count', 1, True),
> +Extension('VK_KHR_driver_properties', 1, True),
> Extension('VK_KHR_external_fence',1,
> 'device->rad_info.has_syncobj_wait_for_submit'),
> Extension('VK_KHR_external_fence_capabilities', 1, True),
> Extension('VK_KHR_external_fence_fd', 1,
> 'device->rad_info.has_syncobj_wait_for_submit'),
> --
> 2.19.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] radv: Add support for VK_KHR_driver_properties.
On Sun, Sep 30, 2018 at 1:04 PM Bas Nieuwenhuizen
wrote:
> ---
> src/amd/vulkan/radv_device.c | 27 +++
> src/amd/vulkan/radv_extensions.py | 1 +
> 2 files changed, 28 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index f7752eac83b..fe7e7f7f6ac 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1196,6 +1196,33 @@ void radv_GetPhysicalDeviceProperties2(
>
> properties->conservativeRasterizationPostDepthCoverage = VK_FALSE;
> break;
> }
> + case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR: {
> + VkPhysicalDeviceDriverPropertiesKHR *driver_props =
> + (VkPhysicalDeviceDriverPropertiesKHR *)
> ext;
> +
> + driver_props->driverID =
> VK_DRIVER_ID_MESA_RADV_KHR;
> + memset(driver_props->driverName, 0,
> VK_MAX_DRIVER_NAME_SIZE_KHR);
> + strcpy(driver_props->driverName, "radv");
> +
> + memset(driver_props->driverInfo, 0,
> VK_MAX_DRIVER_INFO_SIZE_KHR);
> + snprintf(driver_props->driverInfo,
> VK_MAX_DRIVER_INFO_SIZE_KHR,
> + "Mesa " PACKAGE_VERSION
> +#ifdef MESA_GIT_SHA1
> + " ("MESA_GIT_SHA1")"
> +#endif
> + " (LLVM %i.%i.%i)",
>
I think %d is more customary, but I don't care. Assuming you actually pass
1.1.0.2,
Reviewed-by: Jason Ekstrand
> +(HAVE_LLVM >> 8) & 0xff, HAVE_LLVM & 0xff,
> +MESA_LLVM_VERSION_PATCH);
> +
> + driver_props->conformanceVersion =
> (VkConformanceVersionKHR) {
> + .major = 1,
> + .minor = 1,
> + .subminor = 0,
> + .patch = 2,
> + };
> + break;
> + }
> +
> default:
> break;
> }
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index 584926df390..8df5da76ed5 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -59,6 +59,7 @@ EXTENSIONS = [
> Extension('VK_KHR_device_group', 1, True),
> Extension('VK_KHR_device_group_creation', 1, True),
> Extension('VK_KHR_draw_indirect_count', 1, True),
> +Extension('VK_KHR_driver_properties', 1, True),
> Extension('VK_KHR_external_fence',1,
> 'device->rad_info.has_syncobj_wait_for_submit'),
> Extension('VK_KHR_external_fence_capabilities', 1, True),
> Extension('VK_KHR_external_fence_fd', 1,
> 'device->rad_info.has_syncobj_wait_for_submit'),
> --
> 2.19.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 2/2] anv: Implement VK_KHR_driver_properties
On Sun, Sep 30, 2018 at 12:29 PM Bas Nieuwenhuizen
wrote:
> On Sat, Sep 29, 2018 at 4:40 PM Jason Ekstrand
> wrote:
> >
> > ---
> > src/intel/vulkan/anv_device.c | 27 +++
> > src/intel/vulkan/anv_extensions.py | 1 +
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index aa75de4e1ac..ad690b58e23 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -37,6 +37,7 @@
> > #include "util/build_id.h"
> > #include "util/disk_cache.h"
> > #include "util/mesa-sha1.h"
> > +#include "git_sha1.h"
> > #include "vk_util.h"
> > #include "common/gen_defines.h"
> >
> > @@ -1114,6 +1115,32 @@ void anv_GetPhysicalDeviceProperties2(
> > break;
> >}
> >
> > + case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DRIVER_PROPERTIES_KHR: {
> > + VkPhysicalDeviceDriverPropertiesKHR *driver_props =
> > +(VkPhysicalDeviceDriverPropertiesKHR *) ext;
> > +
> > + driver_props->driverID = 6; /* Intel Mesa driver */
> As far as I can tell the enum for this got included in the header, why
> not just use VK_DRIVER_ID_INTEL_OPEN_SOURCE_MESA_KHR?
Yup. I'll fix that. I went looking for it before I sent these patches
but, for some reason, I didn't find it at the time. I've found it now
though.
> With that
> changed, and assuming you really passed CTS 1.1.1.0, this is
>
I'm doing a full CTS run on 1.1.2.0 right now. I'll update to that before
pushing assuming it passes. It should, we're running the CTS in CI.
> Reviewed-by: Bas Nieuwenhuizen
>
Thanks!
--Jason
> > + memset(driver_props->driverName, 0,
> VK_MAX_DRIVER_NAME_SIZE_KHR);
> > + strcpy(driver_props->driverName,
> > +"Intel open-source Mesa driver");
> > +
> > + memset(driver_props->driverInfo, 0,
> VK_MAX_DRIVER_INFO_SIZE_KHR);
> > + strcpy(driver_props->driverInfo,
> > + "Mesa " PACKAGE_VERSION
> > +#ifdef MESA_GIT_SHA1
> > + " ("MESA_GIT_SHA1")"
> > +#endif
> > +);
> > +
> > + driver_props->conformanceVersion = (VkConformanceVersionKHR) {
> > +.major = 1,
> > +.minor = 1,
> > +.subminor = 1,
> > +.patch = 0,
> > + };
> > + break;
> > + }
> > +
> >case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES: {
> > VkPhysicalDeviceIDProperties *id_props =
> > (VkPhysicalDeviceIDProperties *)ext;
> > diff --git a/src/intel/vulkan/anv_extensions.py
> b/src/intel/vulkan/anv_extensions.py
> > index 951505a854e..d4915c95013 100644
> > --- a/src/intel/vulkan/anv_extensions.py
> > +++ b/src/intel/vulkan/anv_extensions.py
> > @@ -78,6 +78,7 @@ EXTENSIONS = [
> > Extension('VK_KHR_descriptor_update_template',1, True),
> > Extension('VK_KHR_device_group', 1, True),
> > Extension('VK_KHR_device_group_creation', 1, True),
> > +Extension('VK_KHR_driver_properties', 1, True),
> > Extension('VK_KHR_external_fence',1,
> >'device->has_syncobj_wait'),
> > Extension('VK_KHR_external_fence_capabilities', 1, True),
> > --
> > 2.17.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] [PATCH] etnaviv: Use write combine instead of unached mappings for shader bo
The later are sensitive to unalligned accesses on arm64[1] and we don't
need an uncached mapping here.
[1]: https://lists.freedesktop.org/archives/etnaviv/2018-September/001956.html
Signed-off-by: Guido Günther
---
src/gallium/drivers/etnaviv/etnaviv_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_shader.c
b/src/gallium/drivers/etnaviv/etnaviv_shader.c
index 04ababc801f..27c735b83bd 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_shader.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_shader.c
@@ -41,7 +41,7 @@ static bool etna_icache_upload_shader(struct etna_context
*ctx, struct etna_shad
{
if (v->bo)
return true;
- v->bo = etna_bo_new(ctx->screen->dev, v->code_size*4,
DRM_ETNA_GEM_CACHE_UNCACHED);
+ v->bo = etna_bo_new(ctx->screen->dev, v->code_size*4,
DRM_ETNA_GEM_CACHE_WC);
if (!v->bo)
return false;
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't bother to call blorp if the blit is zero-sized
On Monday, 2018-10-01 11:04:09 +0200, Juan A. Suarez Romero wrote: > On Tue, 2018-09-11 at 11:15 -0500, Jason Ekstrand wrote: > > Cc: mesa-sta...@lists.freedesktop.org > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107892 > > --- > > src/mesa/drivers/dri/i965/brw_meta_util.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > This has been reviewed, but not pushed yet. > > > J.A. > > > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c > > b/src/mesa/drivers/dri/i965/brw_meta_util.c > > index 908b0989769..6714d96237c 100644 > > --- a/src/mesa/drivers/dri/i965/brw_meta_util.c > > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c > > @@ -247,6 +247,9 @@ brw_meta_mirror_clip_and_scissor(const struct > > gl_context *ctx, > > clip_src_y1, clip_dst_y1, clip_dst_y0, > > scaleY, false); > > > > + if (*dstX0 == *dstX1 || *dstY0 == *dstY1) > > + return true; This comes right after this code (few lines above in the same function): float scaleX = (float) (*srcX1 - *srcX0) / (*dstX1 - *dstX0); float scaleY = (float) (*srcY1 - *srcY0) / (*dstY1 - *dstY0); if *dstX0 == *dstX1, that would be a division by 0, so I don't think that this new `if *dstX0 == *dstX1` is reachable (same for *dstY0 == *dstY1) > > + > > /* Account for the fact that in the system framebuffer, the origin is at > > * the lower left. > > */ > > ___ > 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 v3] mesa/format_pack: Fix pack_uint_Z_FLOAT32()
Fixed pack_uint_Z_FLOAT32 by casting row data to float instead uint.
Remove code duplicate function pack_uint_Z_FLOAT32_X24S8.
Edited case in "_mesa_get_pack_uint_z_func".
Now it looks like "_mesa_get_pack_float_z_func".
v2: by Nanley Chery
-add coments
-remove _mesa_problem call, which was added for debuging this issue
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91433
Signed-off-by: Illia Iorin
---
src/mesa/main/format_pack.py | 21 +
src/mesa/swrast/s_depth.c| 6 --
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/src/mesa/main/format_pack.py b/src/mesa/main/format_pack.py
index 0b9e0d424d..9f97c09ccc 100644
--- a/src/mesa/main/format_pack.py
+++ b/src/mesa/main/format_pack.py
@@ -510,6 +510,10 @@ pack_float_Z_UNORM32(const GLfloat *src, void *dst)
*d = (GLuint) (*src * scale);
}
+/**
+ ** Pack Z_FLOAT32 and Z_FLOAT32_X24S8 to float.
+ **/
+
static void
pack_float_Z_FLOAT32(const GLfloat *src, void *dst)
{
@@ -582,18 +586,12 @@ pack_uint_Z_UNORM32(const GLuint *src, void *dst)
*d = *src;
}
-static void
-pack_uint_Z_FLOAT32(const GLuint *src, void *dst)
-{
- GLuint *d = ((GLuint *) dst);
- const GLdouble scale = 1.0 / (GLdouble) 0x;
- *d = (GLuint) (*src * scale);
- assert(*d >= 0.0f);
- assert(*d <= 1.0f);
-}
+/**
+ ** Pack Z_FLOAT32 and Z_FLOAT32_X24S8 to uint.
+ **/
static void
-pack_uint_Z_FLOAT32_X24S8(const GLuint *src, void *dst)
+pack_uint_Z_FLOAT32(const GLuint *src, void *dst)
{
GLfloat *d = ((GLfloat *) dst);
const GLdouble scale = 1.0 / (GLdouble) 0x;
@@ -617,9 +615,8 @@ _mesa_get_pack_uint_z_func(mesa_format format)
case MESA_FORMAT_Z_UNORM32:
return pack_uint_Z_UNORM32;
case MESA_FORMAT_Z_FLOAT32:
- return pack_uint_Z_FLOAT32;
case MESA_FORMAT_Z32_FLOAT_S8X24_UINT:
- return pack_uint_Z_FLOAT32_X24S8;
+ return pack_uint_Z_FLOAT32;
default:
_mesa_problem(NULL, "unexpected format in _mesa_get_pack_uint_z_func()");
return NULL;
diff --git a/src/mesa/swrast/s_depth.c b/src/mesa/swrast/s_depth.c
index 4b9640d319..de7f14a4fc 100644
--- a/src/mesa/swrast/s_depth.c
+++ b/src/mesa/swrast/s_depth.c
@@ -310,12 +310,6 @@ _swrast_depth_test_span(struct gl_context *ctx, SWspan
*span)
zBufferVals = zStart;
}
else {
- if (_mesa_get_format_datatype(rb->Format) != GL_UNSIGNED_NORMALIZED) {
- _mesa_problem(ctx, "Incorrectly writing swrast's integer depth "
- "values to %s depth buffer",
- _mesa_get_format_name(rb->Format));
- }
-
/* copy Z buffer values into temp buffer (32-bit Z values) */
zBufferTemp = malloc(count * sizeof(GLuint));
if (!zBufferTemp)
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] meson: swr: do a second llvm search with extra modules for llvm >= 7
I already edited the patch, just waiting on the Intel devs to consider the
SWR code changes that go with this.
- Chuck
On Mon, Oct 1, 2018 at 11:26 AM Dylan Baker wrote:
> Quoting Juan A. Suarez Romero (2018-10-01 01:56:25)
> > On Mon, 2018-09-24 at 13:33 -0700, Dylan Baker wrote:
> > > Quoting Chuck Atkins (2018-09-24 13:24:29)
> > > > Hi Dylan,
> > > >
> > > >
> > > > I think you could simplify this:
> > > >
> > > > > + if dep_llvm.found() and with_gallium_swr and
> dep_llvm.version
> > > > ().version_compare('>= 7')
> > > > > +_llvm_2pass = true
> > > > > +llvm_modules += ['ipo', 'objcarcopts']
> > > > > + endif
> > > > > + if _llvm_2pass
> > > > > +dep_llvm = dependency(
> > > > > + 'llvm',
> > > > > + version : _llvm_version,
> > > > > + modules : llvm_modules,
> > > > > + optional_modules : llvm_optional_modules,
> > > > > + required : _llvm_req,
> > > > > +)
> > > > > + endif
> > > >
> > > >
> > > > if dep_llvm.found() and with_gallium_swr and dep_llvm.version
> > > > ().version_compare('>= 7')
> > > > llvm_modules += ['ipo', 'objcarcopts']
> > > > dep_llvm = dependency(
> > > > 'llvm',
> > > > version : _llvm_version,
> > > > modules : llvm_modules,
> > > > optional_modules : llvm_optional_modules,
> > > > required : _llvm_req,
> > > > )
> > > > endif
> > > > with_llvm = dep_llvm.found()
> > > >
> > > >
> > > > I could, and in fact, that exactly what I did initially. But then I
> wanted to
> > > > explicitly seperate the second pass from the decision to do so
> making it easy
> > > > to allow other drivers to do something similar if needed in the same
> spot.
> > > >
> > > > - Chuck
> > >
> > > Okay, that's something I hadn't considered. It seems fine as is then.
> > >
> >
> > Dylan, is this "seems fine as it is" an implicit R+1? :)
> >
> > J.A.
> >
>
> Yes, with a comment mentioning the upstream meson issue, this is:
> Reviewed-by: Dylan Baker
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] XDC 2018 feedback and comments
Hi all, Once more huge thanks to the entire team from g.p.u.l. and Igalia, personally I think this was an extremely well organized XDC! As usual we're looking for feedback on both XDC itself, and the CFP process and program selection. Both about what was great and should be kept for next year's edition, and where there's room for improvement. The board does keep some notes, for those interested in what we have already: - XDC notes for prospective organizers: https://www.x.org/wiki/Events/RFP/ - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ If you want to send in your comments in private, please send them to both the x.org board and gpul - they want to know how to improve and what to keep for the next conference they're going to organize too. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] meson: swr: do a second llvm search with extra modules for llvm >= 7
Quoting Juan A. Suarez Romero (2018-10-01 01:56:25)
> On Mon, 2018-09-24 at 13:33 -0700, Dylan Baker wrote:
> > Quoting Chuck Atkins (2018-09-24 13:24:29)
> > > Hi Dylan,
> > >
> > >
> > > I think you could simplify this:
> > >
> > > > + if dep_llvm.found() and with_gallium_swr and dep_llvm.version
> > > ().version_compare('>= 7')
> > > > +_llvm_2pass = true
> > > > +llvm_modules += ['ipo', 'objcarcopts']
> > > > + endif
> > > > + if _llvm_2pass
> > > > +dep_llvm = dependency(
> > > > + 'llvm',
> > > > + version : _llvm_version,
> > > > + modules : llvm_modules,
> > > > + optional_modules : llvm_optional_modules,
> > > > + required : _llvm_req,
> > > > +)
> > > > + endif
> > >
> > >
> > > if dep_llvm.found() and with_gallium_swr and dep_llvm.version
> > > ().version_compare('>= 7')
> > > llvm_modules += ['ipo', 'objcarcopts']
> > > dep_llvm = dependency(
> > > 'llvm',
> > > version : _llvm_version,
> > > modules : llvm_modules,
> > > optional_modules : llvm_optional_modules,
> > > required : _llvm_req,
> > > )
> > > endif
> > > with_llvm = dep_llvm.found()
> > >
> > >
> > > I could, and in fact, that exactly what I did initially. But then I
> > > wanted to
> > > explicitly seperate the second pass from the decision to do so making it
> > > easy
> > > to allow other drivers to do something similar if needed in the same spot.
> > >
> > > - Chuck
> >
> > Okay, that's something I hadn't considered. It seems fine as is then.
> >
>
> Dylan, is this "seems fine as it is" an implicit R+1? :)
>
> J.A.
>
Yes, with a comment mentioning the upstream meson issue, this is:
Reviewed-by: Dylan Baker
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] glsl_types/nir: add explicit_array_stride plus nir wrapper helpers
From ARB_gl_spirv:
"Mapping of layouts
std140/std430 -> explicit *Offset*, *ArrayStride*, and *MatrixStride*
Decoration on struct members"
That means that we would not have available any kind of layout info,
and we should use explicit array strides.
This commit adds explicit_array_stride. The default value is -1
meaning that it is not set (as with offset). That should be the
default value for GLSL.
In general, the default constructor is ok. We just need to be careful
with some array lowerings, as it should try to get the explicit array
stride when creating new types.
Note that this means that for the ARB_gl_spirv case
std430_array_stride, std140_size etc are meaningless (unless you guess
the layout, something that you shouldn't).
v2: add missing glsl_full_array_type call, found while testing
ARB_gl_spirv with borrowed tests (Alejandro)
---
src/compiler/glsl/gl_nir_lower_samplers_as_deref.c | 2 +-
src/compiler/glsl_types.cpp| 28 +-
src/compiler/glsl_types.h | 13 +++---
src/compiler/nir/nir_lower_io_arrays_to_elements.c | 3 ++-
src/compiler/nir/nir_split_per_member_structs.c| 3 ++-
src/compiler/nir/nir_split_vars.c | 7 --
src/compiler/nir_types.cpp | 20 +---
src/compiler/nir_types.h | 10 +++-
src/compiler/spirv/vtn_variables.c | 3 ++-
9 files changed, 65 insertions(+), 24 deletions(-)
diff --git a/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
b/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
index 9ff5708f503..9716ac4562a 100644
--- a/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
+++ b/src/compiler/glsl/gl_nir_lower_samplers_as_deref.c
@@ -99,7 +99,7 @@ remove_struct_derefs_prep(nir_deref_instr **p, char **name,
remove_struct_derefs_prep([1], name, location, type);
- *type = glsl_get_array_instance(*type, length);
+ *type = glsl_get_array_instance(*type, length,
glsl_get_explicit_array_stride(cur->type));
break;
}
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index ed3bb3a9889..1326b21913b 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -44,7 +44,7 @@ glsl_type::glsl_type(GLenum gl_type,
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
interface_packing(0), interface_row_major(0),
vector_elements(vector_elements), matrix_columns(matrix_columns),
- length(0)
+ length(0), explicit_array_stride(-1)
{
/* Values of these types must fit in the two bits of
* glsl_type::sampled_type.
@@ -77,7 +77,7 @@ glsl_type::glsl_type(GLenum gl_type, glsl_base_type base_type,
base_type(base_type), sampled_type(type),
sampler_dimensionality(dim), sampler_shadow(shadow),
sampler_array(array), interface_packing(0),
- interface_row_major(0), length(0)
+ interface_row_major(0), length(0), explicit_array_stride(-1)
{
this->mem_ctx = ralloc_context(NULL);
assert(this->mem_ctx != NULL);
@@ -97,7 +97,7 @@ glsl_type::glsl_type(const glsl_struct_field *fields,
unsigned num_fields,
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
interface_packing(0), interface_row_major(0),
vector_elements(0), matrix_columns(0),
- length(num_fields)
+ length(num_fields), explicit_array_stride(-1)
{
unsigned int i;
@@ -127,7 +127,7 @@ glsl_type::glsl_type(const glsl_struct_field *fields,
unsigned num_fields,
interface_packing((unsigned) packing),
interface_row_major((unsigned) row_major),
vector_elements(0), matrix_columns(0),
- length(num_fields)
+ length(num_fields), explicit_array_stride(-1)
{
unsigned int i;
@@ -152,7 +152,7 @@ glsl_type::glsl_type(const glsl_type *return_type,
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
interface_packing(0), interface_row_major(0),
vector_elements(0), matrix_columns(0),
- length(num_params)
+ length(num_params), explicit_array_stride(-1)
{
unsigned int i;
@@ -181,7 +181,7 @@ glsl_type::glsl_type(const char *subroutine_name) :
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
interface_packing(0), interface_row_major(0),
vector_elements(1), matrix_columns(1),
- length(0)
+ length(0), explicit_array_stride(-1)
{
this->mem_ctx = ralloc_context(NULL);
assert(this->mem_ctx != NULL);
@@ -434,12 +434,12 @@ _mesa_glsl_release_types(void)
}
-glsl_type::glsl_type(const glsl_type *array, unsigned length) :
+glsl_type::glsl_type(const glsl_type *array, unsigned length, int
explicit_array_stride) :
base_type(GLSL_TYPE_ARRAY), sampled_type(GLSL_TYPE_VOID),
sampler_dimensionality(0), sampler_shadow(0), sampler_array(0),
interface_packing(0), interface_row_major(0),
vector_elements(0), matrix_columns(0),
- length(length), name(NULL)
+ length(length),
Re: [Mesa-dev] [PATCH v1] loader/dri3: wait for fences if back-buffer available
Yes, it also works
On Mon, Oct 1, 2018 at 5:24 PM Michel Dänzer wrote:
> On 2018-10-01 12:37 p.m., Sergii Romantsov wrote:
> > Kabylake doesn't have such issue, but also it doesn't have
> > a front buffers in that case.
> > Coffelake can be fixed if to wait for fences if it has back-buffer.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108097
> > Fixes: aefac10fecc9 (loader/dri3: Only wait for back buffer fences in
> dri3_get_buffer)
> > CC: Michel Dänzer
> > Signed-off-by: Sergii Romantsov
> > ---
> > src/loader/loader_dri3_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> > index 258678a..e9f59a2 100644
> > --- a/src/loader/loader_dri3_helper.c
> > +++ b/src/loader/loader_dri3_helper.c
> > @@ -1819,7 +1819,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> >draw->buffers[buf_id] = buffer;
> > }
> >
> > - if (buffer_type == loader_dri3_buffer_back)
> > + if (buffer_type == loader_dri3_buffer_back || draw->have_back)
> >dri3_fence_await(draw->conn, draw, buffer);
> >
> > /*
> >
>
> Thanks for the patch, but unfortunately, this re-introduces
> https://bugs.freedesktop.org/106404 . Also, conceptually it's not clear
> why the presence of a back buffer would affect waiting for the fake
> front buffer's fence.
>
>
> Unfortunately, I'm unable to reproduce the problem with radeonsi. Does
> the patch below help by any chance?
>
>
> diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> index f641a34e6d1..1981b5f0515 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -1736,6 +1736,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> struct loader_dri3_drawable *draw)
> {
> struct loader_dri3_buffer *buffer;
> + bool fence_await = buffer_type == loader_dri3_buffer_back;
> int buf_id;
>
> if (buffer_type == loader_dri3_buffer_back) {
> @@ -1791,6 +1792,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> 0, 0, 0, 0,
> draw->width, draw->height);
> dri3_fence_trigger(draw->conn, new_buffer);
> +fence_await = true;
> }
> dri3_free_render_buffer(draw, buffer);
>} else if (buffer_type == loader_dri3_buffer_front) {
> @@ -1812,13 +1814,14 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>new_buffer->linear_buffer,
>0, 0, draw->width, draw->height,
>0, 0, 0);
> - }
> + } else
> +fence_await = true;
>}
>buffer = new_buffer;
>draw->buffers[buf_id] = buffer;
> }
>
> - if (buffer_type == loader_dri3_buffer_back)
> + if (fence_await)
>dri3_fence_await(draw->conn, draw, buffer);
>
> /*
>
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4] virgl: Pass resource size and transfer offsets
From: Tomeu Vizoso
Pass the size of a resource when creating it so a backing can be kept in
the other side.
Also pass the required offset to transfer commands.
This moves vtest closer to how virtio-gpu works, making it more useful
for testing.
v2: - Use new messages for creation and transfers, as changing the
behavior of the existing messages would be messy given that we don't
want to break compatibility with older servers.
v3: - Use correct strides: The resource corresponding to the output display
might have a differnt line stride then the IOVs, so when reading back
to this resource take the resource stride and the the IOV stride
into account.
v4: Fix transfer size calculation (Andrey Simiklit)
Signed-off-by: Tomeu Vizoso (v2)
Signed-off-by: Gert Wollny
---
.../winsys/virgl/vtest/virgl_vtest_socket.c| 143 +++--
.../winsys/virgl/vtest/virgl_vtest_winsys.c| 38 --
.../winsys/virgl/vtest/virgl_vtest_winsys.h| 19 ++-
src/gallium/winsys/virgl/vtest/vtest_protocol.h| 29 +
4 files changed, 201 insertions(+), 28 deletions(-)
diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
index 4d20a63ad6..4fa9632c56 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c
@@ -221,6 +221,42 @@ int virgl_vtest_send_get_caps(struct virgl_vtest_winsys
*vws,
return 0;
}
+static int virgl_vtest_send_resource_create2(struct virgl_vtest_winsys *vws,
+ uint32_t handle,
+ enum pipe_texture_target target,
+ uint32_t format,
+ uint32_t bind,
+ uint32_t width,
+ uint32_t height,
+ uint32_t depth,
+ uint32_t array_size,
+ uint32_t last_level,
+ uint32_t nr_samples,
+ uint32_t size)
+{
+ uint32_t res_create_buf[VCMD_RES_CREATE2_SIZE], vtest_hdr[VTEST_HDR_SIZE];
+
+ vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE2_SIZE;
+ vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE2;
+
+ res_create_buf[VCMD_RES_CREATE2_RES_HANDLE] = handle;
+ res_create_buf[VCMD_RES_CREATE2_TARGET] = target;
+ res_create_buf[VCMD_RES_CREATE2_FORMAT] = format;
+ res_create_buf[VCMD_RES_CREATE2_BIND] = bind;
+ res_create_buf[VCMD_RES_CREATE2_WIDTH] = width;
+ res_create_buf[VCMD_RES_CREATE2_HEIGHT] = height;
+ res_create_buf[VCMD_RES_CREATE2_DEPTH] = depth;
+ res_create_buf[VCMD_RES_CREATE2_ARRAY_SIZE] = array_size;
+ res_create_buf[VCMD_RES_CREATE2_LAST_LEVEL] = last_level;
+ res_create_buf[VCMD_RES_CREATE2_NR_SAMPLES] = nr_samples;
+ res_create_buf[VCMD_RES_CREATE2_DATA_SIZE] = size;
+
+ virgl_block_write(vws->sock_fd, _hdr, sizeof(vtest_hdr));
+ virgl_block_write(vws->sock_fd, _create_buf, sizeof(res_create_buf));
+
+ return 0;
+}
+
int virgl_vtest_send_resource_create(struct virgl_vtest_winsys *vws,
uint32_t handle,
enum pipe_texture_target target,
@@ -231,10 +267,17 @@ int virgl_vtest_send_resource_create(struct
virgl_vtest_winsys *vws,
uint32_t depth,
uint32_t array_size,
uint32_t last_level,
- uint32_t nr_samples)
+ uint32_t nr_samples,
+ uint32_t size)
{
uint32_t res_create_buf[VCMD_RES_CREATE_SIZE], vtest_hdr[VTEST_HDR_SIZE];
+ if (vws->protocol_version >= 1)
+ return virgl_vtest_send_resource_create2(vws, handle, target, format,
+ bind, width, height, depth,
+ array_size, last_level,
+ nr_samples, size);
+
vtest_hdr[VTEST_CMD_LEN] = VCMD_RES_CREATE_SIZE;
vtest_hdr[VTEST_CMD_ID] = VCMD_RESOURCE_CREATE;
@@ -282,7 +325,7 @@ int virgl_vtest_send_resource_unref(struct
virgl_vtest_winsys *vws,
return 0;
}
-int virgl_vtest_send_transfer_cmd(struct virgl_vtest_winsys *vws,
+static int virgl_vtest_send_transfer_cmd(struct virgl_vtest_winsys *vws,
uint32_t vcmd,
uint32_t handle,
uint32_t level, uint32_t stride,
@@ -315,6 +358,73 @@ int virgl_vtest_send_transfer_cmd(struct
virgl_vtest_winsys *vws,
return 0;
}
+static int virgl_vtest_send_transfer_cmd2(struct
Re: [Mesa-dev] [PATCH v2 2/4] drirc: Initial blacklist for adaptive sync
On 09/29/2018 05:20 AM, Kenneth Graunke wrote: On Monday, September 24, 2018 8:18:37 PM CEST Nicholas Kazlauskas wrote: Applications that don't present at a predictable rate (ie. not games) shouldn't have adaptive sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 79 ++ 1 file changed, 79 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index ca69dd164f..14dd3077f8 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -310,6 +312,83 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + It doesn't seem like we're going to be able to enumerate every compositor, every video player, and browser variant out there. Is there a GLX/EGL API to disable VRR that compositors should be using? Since the window property is only set on the first flip an application could set it to 0 using xcb or xlib if they wanted to. An extension may make sense given all the other ones out there for flip related behavior but I'm not sure if this needed yet. On the topic of the blacklist: I still think this it's the correct approach. The goal is to enable variable refresh by default for the whole stack eventually but it's going to take some time. In the initial support it's going to be something the user has to opt into - so the expectation for issues in some programs should be expected. There are also more games out there than there are browsers, video players and compositors just from rough estimates. Especially if you include programs you can run via WINE. A whitelist approach would include many more entries than this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev Nicholas Kazlauskas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v1] loader/dri3: wait for fences if back-buffer available
On 2018-10-01 12:37 p.m., Sergii Romantsov wrote:
> Kabylake doesn't have such issue, but also it doesn't have
> a front buffers in that case.
> Coffelake can be fixed if to wait for fences if it has back-buffer.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108097
> Fixes: aefac10fecc9 (loader/dri3: Only wait for back buffer fences in
> dri3_get_buffer)
> CC: Michel Dänzer
> Signed-off-by: Sergii Romantsov
> ---
> src/loader/loader_dri3_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
> index 258678a..e9f59a2 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -1819,7 +1819,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>draw->buffers[buf_id] = buffer;
> }
>
> - if (buffer_type == loader_dri3_buffer_back)
> + if (buffer_type == loader_dri3_buffer_back || draw->have_back)
>dri3_fence_await(draw->conn, draw, buffer);
>
> /*
>
Thanks for the patch, but unfortunately, this re-introduces
https://bugs.freedesktop.org/106404 . Also, conceptually it's not clear
why the presence of a back buffer would affect waiting for the fake
front buffer's fence.
Unfortunately, I'm unable to reproduce the problem with radeonsi. Does
the patch below help by any chance?
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f641a34e6d1..1981b5f0515 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -1736,6 +1736,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
struct loader_dri3_drawable *draw)
{
struct loader_dri3_buffer *buffer;
+ bool fence_await = buffer_type == loader_dri3_buffer_back;
int buf_id;
if (buffer_type == loader_dri3_buffer_back) {
@@ -1791,6 +1792,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
0, 0, 0, 0,
draw->width, draw->height);
dri3_fence_trigger(draw->conn, new_buffer);
+fence_await = true;
}
dri3_free_render_buffer(draw, buffer);
} else if (buffer_type == loader_dri3_buffer_front) {
@@ -1812,13 +1814,14 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
new_buffer->linear_buffer,
0, 0, draw->width, draw->height,
0, 0, 0);
- }
+ } else
+fence_await = true;
}
buffer = new_buffer;
draw->buffers[buf_id] = buffer;
}
- if (buffer_type == loader_dri3_buffer_back)
+ if (fence_await)
dri3_fence_await(draw->conn, draw, buffer);
/*
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108109] [GLSL] no-overloads.vert fails
https://bugs.freedesktop.org/show_bug.cgi?id=108109 vadym changed: What|Removed |Added CC||vadym.shovkoplias@globallog ||ic.com -- You are receiving this mail because: 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 108109] [GLSL] no-overloads.vert fails
https://bugs.freedesktop.org/show_bug.cgi?id=108109 --- Comment #1 from vadym --- Patch: https://patchwork.freedesktop.org/patch/254237/ -- You are receiving this mail because: 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] glsl/linker: Check the subroutine associated functions names
From Section 6.1.2 (Subroutines) of the GLSL 4.00 specification
"A program will fail to compile or link if any shader
or stage contains two or more functions with the same
name if the name is associated with a subroutine type."
Fixes:
* no-overloads.vert
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108109
Signed-off-by: Vadym Shovkoplias
---
src/compiler/glsl/linker.cpp | 40
1 file changed, 40 insertions(+)
diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 3fde7e78d3..d0d017c7ff 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -4639,6 +4639,45 @@ link_assign_subroutine_types(struct gl_shader_program
*prog)
}
}
+static void
+verify_subroutine_associated_funcs(struct gl_shader_program *prog)
+{
+ unsigned mask = prog->data->linked_stages;
+ while (mask) {
+ const int i = u_bit_scan();
+ gl_program *p = prog->_LinkedShaders[i]->Program;
+ glsl_symbol_table *symbols = prog->_LinkedShaders[i]->symbols;
+
+ /*
+ * From OpenGL ES Shading Language 4.00 specification
+ * (6.1.2 Subroutines):
+ * "A program will fail to compile or link if any shader
+ * or stage contains two or more functions with the same
+ * name if the name is associated with a subroutine type."
+ */
+ for (unsigned j = 0; j < p->sh.NumSubroutineFunctions; j++) {
+ unsigned definitions = 0;
+ char *name = p->sh.SubroutineFunctions[j].name;
+ ir_function *fn = symbols->get_function(name);
+
+ /* Calculate number of function definitions with the same name */
+ foreach_in_list(ir_function_signature, sig, >signatures) {
+if (sig->is_defined)
+ definitions++;
+ }
+
+ if (definitions > 1) {
+linker_error(prog, "%s shader contains %u function "
+ "definitions with name `%s', which is associated with"
+ " a subroutine type.\n",
+ _mesa_shader_stage_to_string(i), definitions, fn->name);
+return;
+ }
+ }
+ }
+}
+
+
static void
set_always_active_io(exec_list *ir, ir_variable_mode io_mode)
{
@@ -5024,6 +5063,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
check_explicit_uniform_locations(ctx, prog);
link_assign_subroutine_types(prog);
+ verify_subroutine_associated_funcs(prog);
if (!prog->data->LinkStatus)
goto done;
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108109] [GLSL] no-overloads.vert fails
https://bugs.freedesktop.org/show_bug.cgi?id=108109
Bug ID: 108109
Summary: [GLSL] no-overloads.vert fails
Product: Mesa
Version: 18.2
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: glsl-compiler
Assignee: mesa-dev@lists.freedesktop.org
Reporter: vadym.shovkopl...@globallogic.com
QA Contact: intel-3d-b...@lists.freedesktop.org
# ./bin/glslparsertest
tests/spec/arb_shader_subroutine/linker/no-overloads.vert fail 1.50
--check-link
Successfully compiled and linked vertex shader
tests/spec/arb_shader_subroutine/linker/no-overloads.vert: (no compiler output)
Shader source:
// [config]
// expect_result: fail
// glsl_version: 1.50
// require_extensions: GL_ARB_shader_subroutine
// check_link: true
// [end config]
#version 150
#extension GL_ARB_shader_subroutine: require
subroutine void func_type();
/* A program will fail to link if any shader contains two or more
* functions with the same name, at least one of which is associated
* with a subroutine type.
*/
subroutine (func_type) void f() {}
void f(int x) {}
void main() {}
PIGLIT: {"result": "fail" }
Accordingly to GLSL spec 4.0 this test shouldn't fail:
Section 6.1.2 Subroutines:
"A program will fail to compile or link if any shader
or stage contains two or more functions with the same
name if the name is associated with a subroutine type."
--
You are receiving this mail because:
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] i965: Don't bother to call blorp if the blit is zero-sized
Hi Jason, I'm still getting crash with this patch when run conformance test in the firefox. Assert is triggered during following call: glBlitFramebuffer(srcX0 = -1, srcY0 = -1, srcX1 = 2147483646, srcY1 = 2147483646, dstX0 = 0, dstY0 = 0, dstX1 = 8, dstY1 = 8, mask = GL_COLOR_BUFFER_BIT, filter = GL_NEAREST) пн, 1 окт. 2018 г. в 12:50, Juan A. Suarez Romero : > On Tue, 2018-09-11 at 11:15 -0500, Jason Ekstrand wrote: > > Cc: mesa-sta...@lists.freedesktop.org > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107892 > > --- > > src/mesa/drivers/dri/i965/brw_meta_util.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > This has been reviewed, but not pushed yet. > > > J.A. > > > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c > b/src/mesa/drivers/dri/i965/brw_meta_util.c > > index 908b0989769..6714d96237c 100644 > > --- a/src/mesa/drivers/dri/i965/brw_meta_util.c > > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c > > @@ -247,6 +247,9 @@ brw_meta_mirror_clip_and_scissor(const struct > gl_context *ctx, > > clip_src_y1, clip_dst_y1, clip_dst_y0, > > scaleY, false); > > > > + if (*dstX0 == *dstX1 || *dstY0 == *dstY1) > > + return true; > > + > > /* Account for the fact that in the system framebuffer, the origin > is at > > * the lower left. > > */ > > ___ > 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 108082] warning: unknown warning option '-Wno-format-truncation' [-Wunknown-warning-option]
https://bugs.freedesktop.org/show_bug.cgi?id=108082 --- Comment #4 from Eric Engestrom --- (In reply to Illia from comment #3) > I've wrote workaround for > this issue which hides the problem, until this problem will be fixed in > autoconf. You can't have any logic based on the value of $CC (or $CXX), because `gcc` might be a symlink to `clang` (as is the case by default on MacOS for instance, but I've seen it on Linux as well), and users also use it to add compiler flags. As for the issue, do you guys see the same warning for any other -Wno-foo from our list? I'm 90% sure this is NOTOURBUG as we're already doing all the checks needed, but I want to figure out if it's clang or autotools going bad. Vinson, can you also try meson on your system? It would help narrow down the issue. (I've also checked that there's no typo in the configure.ac check, just in case, and there isn't) -- 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] [Mesa-stable] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
On 01/10/2018 10:13, Juan A. Suarez Romero wrote:
On Mon, 2018-09-24 at 20:21 -0400, Marek Olšák wrote:
Looks good to me.
Marek
This patch was nominated to stable, but I can't apply it on 18.2 because this
patch requires 98f777f9d9c ("radeonsi: remove fetch_args callbacks for ALU
instructions"), which was not nominated.
WDYT? Should both patches added to the 18.2 release, or just get them out of the
release?
J.A.
Hi,
As Marek is the maintainer for radeonsi, I let him choose.
Yours,
Axel Davy
On Mon, Sep 24, 2018 at 2:29 AM, Axel Davy wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
Fixes: https://github.com/iXit/Mesa-3D/issues/314
For this application, NaN is passed to KILL_IF and is expected to
pass.
v2: Explain in the code why UGE is used.
Signed-off-by: Axel Davy
Reviewed-by: Marek Olšák
CC:
---
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
index f54d025aec0..a768b449047 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
@@ -60,7 +60,8 @@ static void kil_emit(const struct lp_build_tgsi_action
*action,
for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
LLVMValueRef value = lp_build_emit_fetch(bld_base,
inst, 0, i);
- conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE, value,
+ /* UGE because NaN shouldn't get killed */
+ conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE, value,
ctx->ac.f32_0, "");
}
--
2.18.0
___
mesa-stable mailing list
mesa-sta...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-stable mailing list
mesa-sta...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 108082] warning: unknown warning option '-Wno-format-truncation' [-Wunknown-warning-option]
https://bugs.freedesktop.org/show_bug.cgi?id=108082 --- Comment #3 from Illia --- Created attachment 141819 --> https://bugs.freedesktop.org/attachment.cgi?id=141819=edit workaround I've got this warning, and another one: warning: unknown warning option '-Wno-override-init'; did you mean '-Wno-override-module'? [-Wunknown-warning-option] It looks like the reason of problem is "AX_CHECK_COMPILE_FLAG". There is need ed to report problem to their bug tracer. I've wrote workaround for this issue which hides the problem, until this problem will be fixed in autoconf. -- 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 v1] loader/dri3: wait for fences if back-buffer available
Kabylake doesn't have such issue, but also it doesn't have a front buffers in that case. Coffelake can be fixed if to wait for fences if it has back-buffer. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108097 Fixes: aefac10fecc9 (loader/dri3: Only wait for back buffer fences in dri3_get_buffer) CC: Michel Dänzer Signed-off-by: Sergii Romantsov --- src/loader/loader_dri3_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c index 258678a..e9f59a2 100644 --- a/src/loader/loader_dri3_helper.c +++ b/src/loader/loader_dri3_helper.c @@ -1819,7 +1819,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable, draw->buffers[buf_id] = buffer; } - if (buffer_type == loader_dri3_buffer_back) + if (buffer_type == loader_dri3_buffer_back || draw->have_back) dri3_fence_await(draw->conn, draw, buffer); /* -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't bother to call blorp if the blit is zero-sized
On Tue, 2018-09-11 at 11:15 -0500, Jason Ekstrand wrote: > Cc: mesa-sta...@lists.freedesktop.org > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107892 > --- > src/mesa/drivers/dri/i965/brw_meta_util.c | 3 +++ > 1 file changed, 3 insertions(+) > This has been reviewed, but not pushed yet. J.A. > diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c > b/src/mesa/drivers/dri/i965/brw_meta_util.c > index 908b0989769..6714d96237c 100644 > --- a/src/mesa/drivers/dri/i965/brw_meta_util.c > +++ b/src/mesa/drivers/dri/i965/brw_meta_util.c > @@ -247,6 +247,9 @@ brw_meta_mirror_clip_and_scissor(const struct gl_context > *ctx, > clip_src_y1, clip_dst_y1, clip_dst_y0, > scaleY, false); > > + if (*dstX0 == *dstX1 || *dstY0 == *dstY1) > + return true; > + > /* Account for the fact that in the system framebuffer, the origin is at > * the lower left. > */ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] anv/blorp: Emit depth flush and stall prior to HiZ clears
On Fri, 2018-08-31 at 14:48 -0700, Chad Versace wrote: > On Fri 31 Aug 2018, Jason Ekstrand wrote: > > We had the flush/stall after the clear but missed the one that needs to > > go before the clear. > > IIUC, Chad has given a R+1 to this. So I think this patch can be pushed, right? J.A. > > Cc: mesa-sta...@lists.freedesktop.org > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107760 > > --- > > src/intel/vulkan/anv_blorp.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c > > index 3dfc8087630..532e8185c0e 100644 > > --- a/src/intel/vulkan/anv_blorp.c > > +++ b/src/intel/vulkan/anv_blorp.c > > @@ -1605,6 +1605,16 @@ anv_image_hiz_clear(struct anv_cmd_buffer > > *cmd_buffer, > > ISL_AUX_USAGE_NONE, ); > > } > > > > + /* From the Sky Lake PRM Volume 7, "Depth Buffer Clear": > > +* > > +*"If other rendering operations have preceded this clear, a > > The hw spec is vague, in my opinion. Does this WA apply to only > preceding "rendering operations" to *this* depth buffer? To *any* depth > buffer? To *any* render target at all? > > And, does the hiz clear op reset the WA condition? That is, if two > sucessive 3DPRIMITIVEs perform a hiz clear op, does the hw require the > WA before the second one? After all, no true "rendering operations" > occurred between the two. > > Ahh! Why does the specification fail to specify??? > > Anyway, I convinced myself that genX(blorp_exec) emits the requested > bits before the problematic 3DPRIMITIVE. > > Reviewed-by: Chad Versace > > > +*PIPE_CONTROL with depth cache flush enabled, Depth Stall bit > > enabled > > +*must be issued before the rectangle primitive used for the depth > > +*buffer clear operation." > > +*/ > > + cmd_buffer->state.pending_pipe_bits |= > > + ANV_PIPE_DEPTH_CACHE_FLUSH_BIT | ANV_PIPE_DEPTH_STALL_BIT; > > + > > blorp_hiz_clear_depth_stencil(, , , > > level, base_layer, layer_count, > > area.offset.x, area.offset.y, > > -- > > 2.17.1 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > mesa-stable mailing list > mesa-sta...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-stable ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v2 2/2] meson: swr: do a second llvm search with extra modules for llvm >= 7
On Mon, 2018-09-24 at 13:33 -0700, Dylan Baker wrote:
> Quoting Chuck Atkins (2018-09-24 13:24:29)
> > Hi Dylan,
> >
> >
> > I think you could simplify this:
> >
> > > + if dep_llvm.found() and with_gallium_swr and dep_llvm.version
> > ().version_compare('>= 7')
> > > +_llvm_2pass = true
> > > +llvm_modules += ['ipo', 'objcarcopts']
> > > + endif
> > > + if _llvm_2pass
> > > +dep_llvm = dependency(
> > > + 'llvm',
> > > + version : _llvm_version,
> > > + modules : llvm_modules,
> > > + optional_modules : llvm_optional_modules,
> > > + required : _llvm_req,
> > > +)
> > > + endif
> >
> >
> > if dep_llvm.found() and with_gallium_swr and dep_llvm.version
> > ().version_compare('>= 7')
> > llvm_modules += ['ipo', 'objcarcopts']
> > dep_llvm = dependency(
> > 'llvm',
> > version : _llvm_version,
> > modules : llvm_modules,
> > optional_modules : llvm_optional_modules,
> > required : _llvm_req,
> > )
> > endif
> > with_llvm = dep_llvm.found()
> >
> >
> > I could, and in fact, that exactly what I did initially. But then I wanted
> > to
> > explicitly seperate the second pass from the decision to do so making it
> > easy
> > to allow other drivers to do something similar if needed in the same spot.
> >
> > - Chuck
>
> Okay, that's something I hadn't considered. It seems fine as is then.
>
Dylan, is this "seems fine as it is" an implicit R+1? :)
J.A.
> Dylan
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] st/nine: do not double-close the fd on teardown
On Wed, 2018-08-29 at 18:13 +0100, Emil Velikov wrote: > From: Emil Velikov > > As the newly introduced comment says: > The pipe loader takes ownership of the fd > > Thus, there's no need to close it again. This patch seems to be already reviewed, but not pushed to upstream. J.A. > > Cc: Patrick Rudolph > Cc: Axel Davy > Cc: mesa-sta...@lists.freedesktop.org> > Signed-off-by: Emil Velikov > --- > src/gallium/targets/d3dadapter9/drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/targets/d3dadapter9/drm.c > b/src/gallium/targets/d3dadapter9/drm.c > index 85b3e10633e..a2a36dbbda9 100644 > --- a/src/gallium/targets/d3dadapter9/drm.c > +++ b/src/gallium/targets/d3dadapter9/drm.c > @@ -107,7 +107,7 @@ drm_destroy( struct d3dadapter9_context *ctx ) > if (drm->dev) > pipe_loader_release(>dev, 1); > > -close(drm->fd); > +/* The pipe loader takes ownership of the fd */ > FREE(ctx); > } > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 2/6] egl: make eglSwapBuffers* a no-op for !window surfaces
On Mon, 2018-09-03 at 13:05 +0100, Emil Velikov wrote: > From: Emil Velikov > > Analogous to the previous commit - the spec says the function is a > no-op when a pbuffer or pixmap surface is used. > This series seems to be reviewed, but not pushed yet in master. J.A. > Cc: samiuddi > Cc: Eric Engestrom > Cc: Erik Faye-Lund > Cc: Tomasz Figa > Cc: > Signed-off-by: Emil Velikov > --- > src/egl/main/eglapi.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c > index 0af31a3f774..0227197284f 100644 > --- a/src/egl/main/eglapi.c > +++ b/src/egl/main/eglapi.c > @@ -1260,6 +1260,9 @@ eglSwapBuffers(EGLDisplay dpy, EGLSurface surface) >RETURN_EGL_ERROR(disp, EGL_BAD_SURFACE, EGL_FALSE); > #endif > > + if (surf->Type != EGL_WINDOW_BIT) > + RETURN_EGL_EVAL(disp, EGL_TRUE); > + > /* From the EGL 1.5 spec: > * > *If eglSwapBuffers is called and the native window associated with > @@ -1299,6 +1302,9 @@ _eglSwapBuffersWithDamageCommon(_EGLDisplay *disp, > _EGLSurface *surf, > surf != ctx->DrawSurface) >RETURN_EGL_ERROR(disp, EGL_BAD_SURFACE, EGL_FALSE); > > + if (surf->Type != EGL_WINDOW_BIT) > + RETURN_EGL_EVAL(disp, EGL_TRUE); > + > if ((n_rects > 0 && rects == NULL) || n_rects < 0) >RETURN_EGL_ERROR(disp, EGL_BAD_PARAMETER, EGL_FALSE); > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH 22/22 v2] radeonsi: NaN should pass kill_if
On Mon, 2018-09-24 at 20:21 -0400, Marek Olšák wrote:
> Looks good to me.
>
> Marek
This patch was nominated to stable, but I can't apply it on 18.2 because this
patch requires 98f777f9d9c ("radeonsi: remove fetch_args callbacks for ALU
instructions"), which was not nominated.
WDYT? Should both patches added to the 18.2 release, or just get them out of the
release?
J.A.
>
> On Mon, Sep 24, 2018 at 2:29 AM, Axel Davy wrote:
> > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105333
> > Fixes: https://github.com/iXit/Mesa-3D/issues/314
> >
> > For this application, NaN is passed to KILL_IF and is expected to
> > pass.
> >
> > v2: Explain in the code why UGE is used.
> >
> > Signed-off-by: Axel Davy
> > Reviewed-by: Marek Olšák
> >
> > CC:
> > ---
> > src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > index f54d025aec0..a768b449047 100644
> > --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c
> > @@ -60,7 +60,8 @@ static void kil_emit(const struct lp_build_tgsi_action
> > *action,
> >
> > for (i = 0; i < TGSI_NUM_CHANNELS; i++) {
> > LLVMValueRef value = lp_build_emit_fetch(bld_base,
> > inst, 0, i);
> > - conds[i] = LLVMBuildFCmp(builder, LLVMRealOGE,
> > value,
> > + /* UGE because NaN shouldn't get killed */
> > + conds[i] = LLVMBuildFCmp(builder, LLVMRealUGE,
> > value,
> > ctx->ac.f32_0, "");
> > }
> >
> > --
> > 2.18.0
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: disable HTILE for very small depth surfaces
On 9/28/18 10:53 PM, Bas Nieuwenhuizen wrote:
On Fri, Sep 28, 2018 at 4:27 PM Samuel Pitoiset
wrote:
Like we disable DCC/CMASK for small color surfaces as well.
Serious Sam 2017 creates a 1x1 depth surface and I think
it should be faster to decompress compared to the benefit
of fast clears.
I don't think the last sentence rolls correctly, it seems to suggest
that we are moving to doing a decompress operation, but with no HTILE
we will never do that.
Yes, this is what I wanted to explain, not sure why I wrote that. Will
update before pushing.
nit aside,
Reviewed-by: Bas Nieuwenhuizen
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_image.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 658ccb65be..64346aa340 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -923,7 +923,9 @@ radv_image_can_enable_fmask(struct radv_image *image)
static inline bool
radv_image_can_enable_htile(struct radv_image *image)
{
- return image->info.levels == 1 && vk_format_is_depth(image->vk_format);
+ return image->info.levels == 1 &&
+ vk_format_is_depth(image->vk_format) &&
+ image->info.width * image->info.height >= 8 * 8;
}
VkResult
--
2.19.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] anv: Silence a bunch of unused variable warnings.
maybe also move the declaration of ret closer to the actual usage in
anv_wait_for_bo_fences?
Reviewed-by: Tapani Pälli
On 9/30/18 9:12 PM, Bas Nieuwenhuizen wrote:
All three are only used in asserts, so this silences release build
warnings.
---
src/intel/vulkan/anv_blorp.c | 3 ++-
src/intel/vulkan/anv_queue.c | 2 +-
src/intel/vulkan/genX_cmd_buffer.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index a1c359cf461..df535270241 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1269,7 +1269,8 @@ void anv_CmdResolveImage(
const uint32_t layer_count =
anv_get_layerCount(dst_image, [r].dstSubresource);
- VkImageAspectFlags src_mask = pRegions[r].srcSubresource.aspectMask,
+ MAYBE_UNUSED VkImageAspectFlags
+ src_mask = pRegions[r].srcSubresource.aspectMask,
dst_mask = pRegions[r].dstSubresource.aspectMask;
assert(anv_image_aspects_compatible(src_mask, dst_mask));
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index e0c0a42069f..3a1fb40b6a1 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -542,7 +542,7 @@ anv_wait_for_bo_fences(struct anv_device *device,
bool waitAll,
uint64_t _timeout)
{
- int ret;
+ MAYBE_UNUSED int ret;
/* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and is supposed
* to block indefinitely timeouts <= 0. Unfortunately, this was broken
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 099c30f3d66..d672f41d18b 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -931,7 +931,7 @@ transition_color_buffer(struct anv_cmd_buffer *cmd_buffer,
assert(level_count != VK_REMAINING_MIP_LEVELS &&
layer_count != VK_REMAINING_ARRAY_LAYERS);
/* Ensure the subresource range is valid. */
- uint64_t last_level_num = base_level + level_count;
+ MAYBE_UNUSED uint64_t last_level_num = base_level + level_count;
const uint32_t max_depth = anv_minify(image->extent.depth, base_level);
UNUSED const uint32_t image_layers = MAX2(image->array_size, max_depth);
assert((uint64_t)base_layer + layer_count <= image_layers);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
