Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
On Thu, May 30, 2019, 7:08 PM Bas Nieuwenhuizen
wrote:
>
>
> On Fri, May 31, 2019, 12:49 AM Marek Olšák wrote:
>
>>
>>
>> On Thu, May 30, 2019, 6:44 PM Bas Nieuwenhuizen
>> wrote:
>>
>>>
>>>
>>> On Thu, May 30, 2019, 11:45 PM Marek Olšák wrote:
>>>
On Thu, May 30, 2019, 3:54 PM Rhys Perry
wrote:
> Otherwise LLVM can sink them and their texture coordinate calculations
> into divergent branches.
>
> v2: simplify the conditions on which the intrinsic is marked as
> convergent
>
> Cc:
> Signed-off-by: Rhys Perry
> Reviewed-By: Bas Nieuwenhuizen
> ---
> src/amd/common/ac_nir_to_llvm.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 265e3b636c4..b1a191ac24c 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1394,6 +1394,18 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
> }
>
> args->attributes = AC_FUNC_ATTR_READNONE;
> + /* Prevent texture instructions with implicit derivatives from
> being
> +* sinked into branches. */
> + switch (instr->op) {
> + case nir_texop_tex:
> + case nir_texop_txb:
> + case nir_texop_lod:
> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> + break;
> + default:
> + break;
> + }
>
I think this should only apply to the fragment shader.
>>>
>>> Well these opcodes will only be used in fragment shaders anyway, right?
>>>
>>
>> I think the normal tex opcode can be used in vertex shaders as well,
>> probably only in OpenGL.
>>
>
> What is the behavior there? Implicit lod of 0?
>
Yes.
Marek
>> Marek
>>
>>
Marek
+
> return ac_build_image_opcode(>ac, args);
> }
>
> --
> 2.21.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
On Fri, May 31, 2019, 12:49 AM Marek Olšák wrote:
>
>
> On Thu, May 30, 2019, 6:44 PM Bas Nieuwenhuizen
> wrote:
>
>>
>>
>> On Thu, May 30, 2019, 11:45 PM Marek Olšák wrote:
>>
>>>
>>>
>>> On Thu, May 30, 2019, 3:54 PM Rhys Perry
>>> wrote:
>>>
Otherwise LLVM can sink them and their texture coordinate calculations
into divergent branches.
v2: simplify the conditions on which the intrinsic is marked as
convergent
Cc:
Signed-off-by: Rhys Perry
Reviewed-By: Bas Nieuwenhuizen
---
src/amd/common/ac_nir_to_llvm.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c
b/src/amd/common/ac_nir_to_llvm.c
index 265e3b636c4..b1a191ac24c 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1394,6 +1394,18 @@ static LLVMValueRef build_tex_intrinsic(struct
ac_nir_context *ctx,
}
args->attributes = AC_FUNC_ATTR_READNONE;
+ /* Prevent texture instructions with implicit derivatives from
being
+* sinked into branches. */
+ switch (instr->op) {
+ case nir_texop_tex:
+ case nir_texop_txb:
+ case nir_texop_lod:
+ args->attributes |= AC_FUNC_ATTR_CONVERGENT;
+ break;
+ default:
+ break;
+ }
>>>
>>> I think this should only apply to the fragment shader.
>>>
>>
>> Well these opcodes will only be used in fragment shaders anyway, right?
>>
>
> I think the normal tex opcode can be used in vertex shaders as well,
> probably only in OpenGL.
>
What is the behavior there? Implicit lod of 0?
>
> Marek
>
>
>>> Marek
>>>
>>> +
return ac_build_image_opcode(>ac, args);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
On Thu, May 30, 2019, 6:44 PM Bas Nieuwenhuizen
wrote:
>
>
> On Thu, May 30, 2019, 11:45 PM Marek Olšák wrote:
>
>>
>>
>> On Thu, May 30, 2019, 3:54 PM Rhys Perry
>> wrote:
>>
>>> Otherwise LLVM can sink them and their texture coordinate calculations
>>> into divergent branches.
>>>
>>> v2: simplify the conditions on which the intrinsic is marked as
>>> convergent
>>>
>>> Cc:
>>> Signed-off-by: Rhys Perry
>>> Reviewed-By: Bas Nieuwenhuizen
>>> ---
>>> src/amd/common/ac_nir_to_llvm.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>>> b/src/amd/common/ac_nir_to_llvm.c
>>> index 265e3b636c4..b1a191ac24c 100644
>>> --- a/src/amd/common/ac_nir_to_llvm.c
>>> +++ b/src/amd/common/ac_nir_to_llvm.c
>>> @@ -1394,6 +1394,18 @@ static LLVMValueRef build_tex_intrinsic(struct
>>> ac_nir_context *ctx,
>>> }
>>>
>>> args->attributes = AC_FUNC_ATTR_READNONE;
>>> + /* Prevent texture instructions with implicit derivatives from
>>> being
>>> +* sinked into branches. */
>>> + switch (instr->op) {
>>> + case nir_texop_tex:
>>> + case nir_texop_txb:
>>> + case nir_texop_lod:
>>> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
>>> + break;
>>> + default:
>>> + break;
>>> + }
>>>
>>
>> I think this should only apply to the fragment shader.
>>
>
> Well these opcodes will only be used in fragment shaders anyway, right?
>
I think the normal tex opcode can be used in vertex shaders as well,
probably only in OpenGL.
Marek
>> Marek
>>
>> +
>>> return ac_build_image_opcode(>ac, args);
>>> }
>>>
>>> --
>>> 2.21.0
>>>
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
On Thu, May 30, 2019, 11:45 PM Marek Olšák wrote:
>
>
> On Thu, May 30, 2019, 3:54 PM Rhys Perry wrote:
>
>> Otherwise LLVM can sink them and their texture coordinate calculations
>> into divergent branches.
>>
>> v2: simplify the conditions on which the intrinsic is marked as convergent
>>
>> Cc:
>> Signed-off-by: Rhys Perry
>> Reviewed-By: Bas Nieuwenhuizen
>> ---
>> src/amd/common/ac_nir_to_llvm.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 265e3b636c4..b1a191ac24c 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -1394,6 +1394,18 @@ static LLVMValueRef build_tex_intrinsic(struct
>> ac_nir_context *ctx,
>> }
>>
>> args->attributes = AC_FUNC_ATTR_READNONE;
>> + /* Prevent texture instructions with implicit derivatives from
>> being
>> +* sinked into branches. */
>> + switch (instr->op) {
>> + case nir_texop_tex:
>> + case nir_texop_txb:
>> + case nir_texop_lod:
>> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
>> + break;
>> + default:
>> + break;
>> + }
>>
>
> I think this should only apply to the fragment shader.
>
Well these opcodes will only be used in fragment shaders anyway, right?
>
> Marek
>
> +
>> return ac_build_image_opcode(>ac, args);
>> }
>>
>> --
>> 2.21.0
>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] freedreno: Fix GCC build error.
../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is not
constant
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
^
Suggested-by: Kristian Høgsberg
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110698
Signed-off-by: Vinson Lee
---
src/freedreno/vulkan/tu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/freedreno/vulkan/tu_device.c b/src/freedreno/vulkan/tu_device.c
index 2e930d9841fe..fdb9e1e0a1e2 100644
--- a/src/freedreno/vulkan/tu_device.c
+++ b/src/freedreno/vulkan/tu_device.c
@@ -897,7 +897,7 @@ static const VkQueueFamilyProperties
tu_queue_family_properties = {
VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT,
.queueCount = 1,
.timestampValidBits = 64,
- .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
+ .minImageTransferGranularity = { 1, 1, 1 },
};
void
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/8] egl: add EGL_platform_device support
Hi Emil, What are your plans for pushing this? Thanks, Marek On Thu, May 16, 2019, 3:23 PM Marek Olšák wrote: > Acked-by: Marek Olšák > > Marek > > On Thu, May 16, 2019 at 1:03 PM Emil Velikov > wrote: > >> This new 'platform' is added by default with no guards. >> >> It is effectively a copy of the surfaceless one, with updated function >> names and brand new probe function. >> >> Due to the reuse, some of the ifdef HAVE_SURFACELESS_PLATFORM guards >> have been dropped. >> >> A worthy mention are the changes in _egFindDisplay, since the original >> and dup'd fd are required, we make use of the plat_opt argument. >> >> Note that no hacks for eglGetDisplay are added - the API works only with >> the eglGetPlatformDisplay* API. >> >> v2: >> - s/_eglCompareDeviceDisplay/_eglSameDeviceDisplay/ (Eric) >> - let ^^ return bool (Eric) >> - fixup meson build, move files() further up (Eric) >> - copy from plat. surfaceless w/o the visual cleanups >> - close and free when destroying the dpy >> - sprinkle a few _eglDeviceSupports >> - split fd handling into separate function >> - use directly the render node if no FD is given (Mathias) >> >> v3: >> - s/dpy/disp/g >> - drop swap_buffers* callbacks >> - drop loader_set_logger() >> - drop local define >> - re-introduce _eglGetDRMDeviceRenderNode() >> - EGL_WARN on ForceSoftware with HW device - continue using the HW device >> - bail out for "EGL_MESA_device_software" until it's fixed >> - wire-up the Android build >> >> v4: >> - use new style _eglFindDisplay() >> - split hw vs sw code paths >> - don't close the internal fd (already handled in FiniDisplay()) >> - make swrast work (bit hacky bit will do for now) >> - Android for real, drop autotools >> - Correct HW + LIBGL_ALWAYS_SOFTWARE check >> - use the dri2_create_drawable() helper >> >> v5: >> - enhance comment around fd checks (Mathias) >> - rebase for dri2_init_surface() changes >> >> Cc: Mathias Fröhlich >> Acked-by: Marek Olšák (v4) >> Signed-off-by: Emil Velikov >> --- >> src/egl/Android.mk | 1 + >> src/egl/drivers/dri2/egl_dri2.c| 3 + >> src/egl/drivers/dri2/egl_dri2.h| 13 +- >> src/egl/drivers/dri2/platform_device.c | 435 + >> src/egl/main/eglapi.c | 13 +- >> src/egl/main/egldevice.c | 16 + >> src/egl/main/egldevice.h | 3 + >> src/egl/main/egldisplay.c | 67 >> src/egl/main/egldisplay.h | 7 +- >> src/egl/main/eglglobals.c | 1 + >> src/egl/meson.build| 1 + >> 11 files changed, 549 insertions(+), 11 deletions(-) >> create mode 100644 src/egl/drivers/dri2/platform_device.c >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
On Thu, May 30, 2019, 3:54 PM Rhys Perry wrote:
> Otherwise LLVM can sink them and their texture coordinate calculations
> into divergent branches.
>
> v2: simplify the conditions on which the intrinsic is marked as convergent
>
> Cc:
> Signed-off-by: Rhys Perry
> Reviewed-By: Bas Nieuwenhuizen
> ---
> src/amd/common/ac_nir_to_llvm.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 265e3b636c4..b1a191ac24c 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1394,6 +1394,18 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
> }
>
> args->attributes = AC_FUNC_ATTR_READNONE;
> + /* Prevent texture instructions with implicit derivatives from
> being
> +* sinked into branches. */
> + switch (instr->op) {
> + case nir_texop_tex:
> + case nir_texop_txb:
> + case nir_texop_lod:
> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> + break;
> + default:
> + break;
> + }
>
I think this should only apply to the fragment shader.
Marek
+
> return ac_build_image_opcode(>ac, args);
> }
>
> --
> 2.21.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 03/18] intel/blorp: Use the hardware op for CCS ambiguate on gen10+
Thanks. Landed.
On Thu, May 30, 2019 at 7:02 AM Jason Ekstrand wrote:
>
> Feel free to land
>
> On Wed, May 29, 2019 at 4:50 PM Nanley Chery wrote:
>>
>> On Wed, Feb 14, 2018 at 12:19 PM Jason Ekstrand wrote:
>> >
>> > Cannonlake hardware adds a new resolve type in 3DSTATE_PS called
>> > FAST_CLEAR_0 which does an ambiguate. Now that the hardware can do it
>> > directly, we should use that instead of binding the CCS as a render
>> > target and doing it manually. This was tested with a full Vulkan CTS
>> > run on Cannonlake.
>> > ---
>> > src/intel/blorp/blorp_clear.c | 12 +++-
>> > src/intel/blorp/blorp_genX_exec.h | 6 ++
>> > 2 files changed, 17 insertions(+), 1 deletion(-)
>> >
>>
>> This patch is
>> Reviewed-by: Nanley Chery
>>
>> > diff --git a/src/intel/blorp/blorp_clear.c b/src/intel/blorp/blorp_clear.c
>> > index 421a6c5..4ba65d0 100644
>> > --- a/src/intel/blorp/blorp_clear.c
>> > +++ b/src/intel/blorp/blorp_clear.c
>> > @@ -758,7 +758,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
>> > params.x1 = ALIGN(params.x1, x_scaledown) / x_scaledown;
>> > params.y1 = ALIGN(params.y1, y_scaledown) / y_scaledown;
>> >
>> > - if (batch->blorp->isl_dev->info->gen >= 9) {
>> > + if (batch->blorp->isl_dev->info->gen >= 10) {
>> > + assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
>> > + resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE ||
>> > + resolve_op == ISL_AUX_OP_AMBIGUATE);
>> > + } else if (batch->blorp->isl_dev->info->gen >= 9) {
>> >assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
>> > resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE);
>> > } else {
>> > @@ -893,6 +897,12 @@ blorp_ccs_ambiguate(struct blorp_batch *batch,
>> > struct blorp_surf *surf,
>> > uint32_t level, uint32_t layer)
>> > {
>> > + if (ISL_DEV_GEN(batch->blorp->isl_dev) >= 10) {
>> > + /* On gen10 and above, we have a hardware resolve op for this */
>> > + return blorp_ccs_resolve(batch, surf, level, layer, 1,
>> > + surf->surf->format, ISL_AUX_OP_AMBIGUATE);
>> > + }
>> > +
>> > struct blorp_params params;
>> > blorp_params_init();
>> >
>> > diff --git a/src/intel/blorp/blorp_genX_exec.h
>> > b/src/intel/blorp/blorp_genX_exec.h
>> > index 5e1312a..85abf6b 100644
>> > --- a/src/intel/blorp/blorp_genX_exec.h
>> > +++ b/src/intel/blorp/blorp_genX_exec.h
>> > @@ -752,6 +752,12 @@ blorp_emit_ps_config(struct blorp_batch *batch,
>> >switch (params->fast_clear_op) {
>> >case ISL_AUX_OP_NONE:
>> > break;
>> > +#if GEN_GEN >= 10
>> > + case ISL_AUX_OP_AMBIGUATE:
>> > + ps.RenderTargetFastClearEnable = true;
>> > + ps.RenderTargetResolveType = FAST_CLEAR_0;
>> > + break;
>> > +#endif
>> > #if GEN_GEN >= 9
>> >case ISL_AUX_OP_PARTIAL_RESOLVE:
>> > ps.RenderTargetResolveType = RESOLVE_PARTIAL;
>> > --
>> > 2.5.0.400.gff86faf
>> >
>> > ___
>> > 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] ac/nir: mark some texture intrinsics as convergent
Otherwise LLVM can sink them and their texture coordinate calculations
into divergent branches.
v2: simplify the conditions on which the intrinsic is marked as convergent
Cc:
Signed-off-by: Rhys Perry
Reviewed-By: Bas Nieuwenhuizen
---
src/amd/common/ac_nir_to_llvm.c | 12
1 file changed, 12 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 265e3b636c4..b1a191ac24c 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1394,6 +1394,18 @@ static LLVMValueRef build_tex_intrinsic(struct
ac_nir_context *ctx,
}
args->attributes = AC_FUNC_ATTR_READNONE;
+ /* Prevent texture instructions with implicit derivatives from being
+* sinked into branches. */
+ switch (instr->op) {
+ case nir_texop_tex:
+ case nir_texop_txb:
+ case nir_texop_lod:
+ args->attributes |= AC_FUNC_ATTR_CONVERGENT;
+ break;
+ default:
+ break;
+ }
+
return ac_build_image_opcode(>ac, args);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
It doesn't matter if the opcode supplies a lod. The only thing that matters
is if the opcode computes derivatives. It seems that the only opcodes
computing derivatives are tex, tex_bias, and query_lod. This only applies
to fragment shaders. Other stages never compute derivatives. There is an NV
extension that enables derivatives in compute shaders.
Marek
On Thu, May 30, 2019, 2:47 PM Rhys Perry wrote:
> Seems txf can(should?) have a lod supplied. txf_ms and tg4 always use
> the 0th level.
>
> I'll add txf, txf_ms and tg4 to the list of nir_texop which don't ever
> have implicit derivatives.
>
> On Thu, 30 May 2019 at 19:43, Ilia Mirkin wrote:
> >
> > txf supplies an lod, but tg4's is implicitly always 0.
> >
> > On Thu, May 30, 2019 at 2:26 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > On Thu, May 30, 2019 at 6:50 PM Rhys Perry
> wrote:
> > > >
> > > > Otherwise LLVM can sink them and their texture coordinate
> calculations
> > > > into divergent branches.
> > > >
> > > > Cc:
> > > > Signed-off-by: Rhys Perry
> > > > ---
> > > > src/amd/common/ac_nir_to_llvm.c | 29 +
> > > > 1 file changed, 29 insertions(+)
> > > >
> > > > diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> > > > index 265e3b636c4..d2dc617de36 100644
> > > > --- a/src/amd/common/ac_nir_to_llvm.c
> > > > +++ b/src/amd/common/ac_nir_to_llvm.c
> > > > @@ -1316,6 +1316,30 @@ static nir_deref_instr
> *get_tex_texture_deref(const nir_tex_instr *instr)
> > > > return texture_deref_instr;
> > > > }
> > > >
> > > > +static bool has_implicit_derivatives(const nir_tex_instr *instr)
> > > > +{
> > > > + switch (instr->op) {
> > > > + case nir_texop_txs:
> > > > + case nir_texop_query_levels:
> > > > + case nir_texop_texture_samples:
> > > > + case nir_texop_samples_identical:
> > > > + return false;
> > > > + default:
> > > > + break;
> > > > + }
> > > > + for (unsigned i = 0; i < instr->num_srcs; i++) {
> > > > + switch (instr->src[i].src_type) {
> > > > + case nir_tex_src_lod:
> > > > + case nir_tex_src_ddx:
> > > > + case nir_tex_src_ddy:
> > > > + return false;
> > > > + default:
> > > > + break;
> > > > + }
> > > > + }
> > > > + return true;
> > > > +}
> > >
> > > txf, tg4 and friends do not provide any of lod/ddx/ddy do they?
> > >
> > > > +
> > > > static LLVMValueRef build_tex_intrinsic(struct ac_nir_context *ctx,
> > > > const nir_tex_instr *instr,
> > > > struct ac_image_args *args)
> > > > @@ -1394,6 +1418,11 @@ static LLVMValueRef
> build_tex_intrinsic(struct ac_nir_context *ctx,
> > > > }
> > > >
> > > > args->attributes = AC_FUNC_ATTR_READNONE;
> > > > + /* Prevent texture instructions with implicit derivatives
> from being
> > > > +* sinked into branches. */
> > > > + if (has_implicit_derivatives(instr))
> > > > + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> > > > +
> > > > return ac_build_image_opcode(>ac, args);
> > > > }
> > > >
> > > > --
> > > > 2.21.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] ac/nir: mark some texture intrinsics as convergent
Seems txf can(should?) have a lod supplied. txf_ms and tg4 always use
the 0th level.
I'll add txf, txf_ms and tg4 to the list of nir_texop which don't ever
have implicit derivatives.
On Thu, 30 May 2019 at 19:43, Ilia Mirkin wrote:
>
> txf supplies an lod, but tg4's is implicitly always 0.
>
> On Thu, May 30, 2019 at 2:26 PM Bas Nieuwenhuizen
> wrote:
> >
> > On Thu, May 30, 2019 at 6:50 PM Rhys Perry wrote:
> > >
> > > Otherwise LLVM can sink them and their texture coordinate calculations
> > > into divergent branches.
> > >
> > > Cc:
> > > Signed-off-by: Rhys Perry
> > > ---
> > > src/amd/common/ac_nir_to_llvm.c | 29 +
> > > 1 file changed, 29 insertions(+)
> > >
> > > diff --git a/src/amd/common/ac_nir_to_llvm.c
> > > b/src/amd/common/ac_nir_to_llvm.c
> > > index 265e3b636c4..d2dc617de36 100644
> > > --- a/src/amd/common/ac_nir_to_llvm.c
> > > +++ b/src/amd/common/ac_nir_to_llvm.c
> > > @@ -1316,6 +1316,30 @@ static nir_deref_instr
> > > *get_tex_texture_deref(const nir_tex_instr *instr)
> > > return texture_deref_instr;
> > > }
> > >
> > > +static bool has_implicit_derivatives(const nir_tex_instr *instr)
> > > +{
> > > + switch (instr->op) {
> > > + case nir_texop_txs:
> > > + case nir_texop_query_levels:
> > > + case nir_texop_texture_samples:
> > > + case nir_texop_samples_identical:
> > > + return false;
> > > + default:
> > > + break;
> > > + }
> > > + for (unsigned i = 0; i < instr->num_srcs; i++) {
> > > + switch (instr->src[i].src_type) {
> > > + case nir_tex_src_lod:
> > > + case nir_tex_src_ddx:
> > > + case nir_tex_src_ddy:
> > > + return false;
> > > + default:
> > > + break;
> > > + }
> > > + }
> > > + return true;
> > > +}
> >
> > txf, tg4 and friends do not provide any of lod/ddx/ddy do they?
> >
> > > +
> > > static LLVMValueRef build_tex_intrinsic(struct ac_nir_context *ctx,
> > > const nir_tex_instr *instr,
> > > struct ac_image_args *args)
> > > @@ -1394,6 +1418,11 @@ static LLVMValueRef build_tex_intrinsic(struct
> > > ac_nir_context *ctx,
> > > }
> > >
> > > args->attributes = AC_FUNC_ATTR_READNONE;
> > > + /* Prevent texture instructions with implicit derivatives from
> > > being
> > > +* sinked into branches. */
> > > + if (has_implicit_derivatives(instr))
> > > + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> > > +
> > > return ac_build_image_opcode(>ac, args);
> > > }
> > >
> > > --
> > > 2.21.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] ac/nir: mark some texture intrinsics as convergent
txf supplies an lod, but tg4's is implicitly always 0.
On Thu, May 30, 2019 at 2:26 PM Bas Nieuwenhuizen
wrote:
>
> On Thu, May 30, 2019 at 6:50 PM Rhys Perry wrote:
> >
> > Otherwise LLVM can sink them and their texture coordinate calculations
> > into divergent branches.
> >
> > Cc:
> > Signed-off-by: Rhys Perry
> > ---
> > src/amd/common/ac_nir_to_llvm.c | 29 +
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/src/amd/common/ac_nir_to_llvm.c
> > b/src/amd/common/ac_nir_to_llvm.c
> > index 265e3b636c4..d2dc617de36 100644
> > --- a/src/amd/common/ac_nir_to_llvm.c
> > +++ b/src/amd/common/ac_nir_to_llvm.c
> > @@ -1316,6 +1316,30 @@ static nir_deref_instr *get_tex_texture_deref(const
> > nir_tex_instr *instr)
> > return texture_deref_instr;
> > }
> >
> > +static bool has_implicit_derivatives(const nir_tex_instr *instr)
> > +{
> > + switch (instr->op) {
> > + case nir_texop_txs:
> > + case nir_texop_query_levels:
> > + case nir_texop_texture_samples:
> > + case nir_texop_samples_identical:
> > + return false;
> > + default:
> > + break;
> > + }
> > + for (unsigned i = 0; i < instr->num_srcs; i++) {
> > + switch (instr->src[i].src_type) {
> > + case nir_tex_src_lod:
> > + case nir_tex_src_ddx:
> > + case nir_tex_src_ddy:
> > + return false;
> > + default:
> > + break;
> > + }
> > + }
> > + return true;
> > +}
>
> txf, tg4 and friends do not provide any of lod/ddx/ddy do they?
>
> > +
> > static LLVMValueRef build_tex_intrinsic(struct ac_nir_context *ctx,
> > const nir_tex_instr *instr,
> > struct ac_image_args *args)
> > @@ -1394,6 +1418,11 @@ static LLVMValueRef build_tex_intrinsic(struct
> > ac_nir_context *ctx,
> > }
> >
> > args->attributes = AC_FUNC_ATTR_READNONE;
> > + /* Prevent texture instructions with implicit derivatives from being
> > +* sinked into branches. */
> > + if (has_implicit_derivatives(instr))
> > + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> > +
> > return ac_build_image_opcode(>ac, args);
> > }
> >
> > --
> > 2.21.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] ac/nir: mark some texture intrinsics as convergent
On Thu, May 30, 2019 at 6:50 PM Rhys Perry wrote:
>
> Otherwise LLVM can sink them and their texture coordinate calculations
> into divergent branches.
>
> Cc:
> Signed-off-by: Rhys Perry
> ---
> src/amd/common/ac_nir_to_llvm.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 265e3b636c4..d2dc617de36 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1316,6 +1316,30 @@ static nir_deref_instr *get_tex_texture_deref(const
> nir_tex_instr *instr)
> return texture_deref_instr;
> }
>
> +static bool has_implicit_derivatives(const nir_tex_instr *instr)
> +{
> + switch (instr->op) {
> + case nir_texop_txs:
> + case nir_texop_query_levels:
> + case nir_texop_texture_samples:
> + case nir_texop_samples_identical:
> + return false;
> + default:
> + break;
> + }
> + for (unsigned i = 0; i < instr->num_srcs; i++) {
> + switch (instr->src[i].src_type) {
> + case nir_tex_src_lod:
> + case nir_tex_src_ddx:
> + case nir_tex_src_ddy:
> + return false;
> + default:
> + break;
> + }
> + }
> + return true;
> +}
txf, tg4 and friends do not provide any of lod/ddx/ddy do they?
> +
> static LLVMValueRef build_tex_intrinsic(struct ac_nir_context *ctx,
> const nir_tex_instr *instr,
> struct ac_image_args *args)
> @@ -1394,6 +1418,11 @@ static LLVMValueRef build_tex_intrinsic(struct
> ac_nir_context *ctx,
> }
>
> args->attributes = AC_FUNC_ATTR_READNONE;
> + /* Prevent texture instructions with implicit derivatives from being
> +* sinked into branches. */
> + if (has_implicit_derivatives(instr))
> + args->attributes |= AC_FUNC_ATTR_CONVERGENT;
> +
> return ac_build_image_opcode(>ac, args);
> }
>
> --
> 2.21.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix some compiler warnings
Or even better, cast it to uint32_t explicitly. On Thu, May 30, 2019 at 8:23 PM Bas Nieuwenhuizen wrote: > > maybe use UINT32_MAX? > > otherwise r-b > > On Thu, May 30, 2019 at 6:50 PM Rhys Perry wrote: > > > > Fixes -Woverflow warnings with GCC 9.1.1 > > > > Signed-off-by: Rhys Perry > > --- > > src/amd/vulkan/si_cmd_buffer.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c > > index aae8d578c10..d87c00b94e9 100644 > > --- a/src/amd/vulkan/si_cmd_buffer.c > > +++ b/src/amd/vulkan/si_cmd_buffer.c > > @@ -1360,7 +1360,7 @@ void radv_emit_default_sample_locations(struct > > radeon_cmdbuf *cs, int nr_samples > > default: > > case 1: > > radeon_set_context_reg_seq(cs, > > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > > - radeon_emit(cs, centroid_priority_1x); > > + radeon_emit(cs, centroid_priority_1x & 0x); > > radeon_emit(cs, centroid_priority_1x >> 32); > > radeon_set_context_reg(cs, > > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_1x); > > radeon_set_context_reg(cs, > > R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_1x); > > @@ -1369,7 +1369,7 @@ void radv_emit_default_sample_locations(struct > > radeon_cmdbuf *cs, int nr_samples > > break; > > case 2: > > radeon_set_context_reg_seq(cs, > > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > > - radeon_emit(cs, centroid_priority_2x); > > + radeon_emit(cs, centroid_priority_2x & 0x); > > radeon_emit(cs, centroid_priority_2x >> 32); > > radeon_set_context_reg(cs, > > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_2x); > > radeon_set_context_reg(cs, > > R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_2x); > > @@ -1378,7 +1378,7 @@ void radv_emit_default_sample_locations(struct > > radeon_cmdbuf *cs, int nr_samples > > break; > > case 4: > > radeon_set_context_reg_seq(cs, > > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > > - radeon_emit(cs, centroid_priority_4x); > > + radeon_emit(cs, centroid_priority_4x & 0x); > > radeon_emit(cs, centroid_priority_4x >> 32); > > radeon_set_context_reg(cs, > > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_4x); > > radeon_set_context_reg(cs, > > R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_4x); > > @@ -1387,7 +1387,7 @@ void radv_emit_default_sample_locations(struct > > radeon_cmdbuf *cs, int nr_samples > > break; > > case 8: > > radeon_set_context_reg_seq(cs, > > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > > - radeon_emit(cs, centroid_priority_8x); > > + radeon_emit(cs, centroid_priority_8x & 0x); > > radeon_emit(cs, centroid_priority_8x >> 32); > > radeon_set_context_reg_seq(cs, > > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, 14); > > radeon_emit_array(cs, sample_locs_8x, 4); > > -- > > 2.21.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: fix some compiler warnings
maybe use UINT32_MAX? otherwise r-b On Thu, May 30, 2019 at 6:50 PM Rhys Perry wrote: > > Fixes -Woverflow warnings with GCC 9.1.1 > > Signed-off-by: Rhys Perry > --- > src/amd/vulkan/si_cmd_buffer.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c > index aae8d578c10..d87c00b94e9 100644 > --- a/src/amd/vulkan/si_cmd_buffer.c > +++ b/src/amd/vulkan/si_cmd_buffer.c > @@ -1360,7 +1360,7 @@ void radv_emit_default_sample_locations(struct > radeon_cmdbuf *cs, int nr_samples > default: > case 1: > radeon_set_context_reg_seq(cs, > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > - radeon_emit(cs, centroid_priority_1x); > + radeon_emit(cs, centroid_priority_1x & 0x); > radeon_emit(cs, centroid_priority_1x >> 32); > radeon_set_context_reg(cs, > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_1x); > radeon_set_context_reg(cs, > R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_1x); > @@ -1369,7 +1369,7 @@ void radv_emit_default_sample_locations(struct > radeon_cmdbuf *cs, int nr_samples > break; > case 2: > radeon_set_context_reg_seq(cs, > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > - radeon_emit(cs, centroid_priority_2x); > + radeon_emit(cs, centroid_priority_2x & 0x); > radeon_emit(cs, centroid_priority_2x >> 32); > radeon_set_context_reg(cs, > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_2x); > radeon_set_context_reg(cs, > R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_2x); > @@ -1378,7 +1378,7 @@ void radv_emit_default_sample_locations(struct > radeon_cmdbuf *cs, int nr_samples > break; > case 4: > radeon_set_context_reg_seq(cs, > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > - radeon_emit(cs, centroid_priority_4x); > + radeon_emit(cs, centroid_priority_4x & 0x); > radeon_emit(cs, centroid_priority_4x >> 32); > radeon_set_context_reg(cs, > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_4x); > radeon_set_context_reg(cs, > R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_4x); > @@ -1387,7 +1387,7 @@ void radv_emit_default_sample_locations(struct > radeon_cmdbuf *cs, int nr_samples > break; > case 8: > radeon_set_context_reg_seq(cs, > R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); > - radeon_emit(cs, centroid_priority_8x); > + radeon_emit(cs, centroid_priority_8x & 0x); > radeon_emit(cs, centroid_priority_8x >> 32); > radeon_set_context_reg_seq(cs, > R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, 14); > radeon_emit_array(cs, sample_locs_8x, 4); > -- > 2.21.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] ac/nir: mark some texture intrinsics as convergent
Otherwise LLVM can sink them and their texture coordinate calculations
into divergent branches.
Cc:
Signed-off-by: Rhys Perry
---
src/amd/common/ac_nir_to_llvm.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 265e3b636c4..d2dc617de36 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1316,6 +1316,30 @@ static nir_deref_instr *get_tex_texture_deref(const
nir_tex_instr *instr)
return texture_deref_instr;
}
+static bool has_implicit_derivatives(const nir_tex_instr *instr)
+{
+ switch (instr->op) {
+ case nir_texop_txs:
+ case nir_texop_query_levels:
+ case nir_texop_texture_samples:
+ case nir_texop_samples_identical:
+ return false;
+ default:
+ break;
+ }
+ for (unsigned i = 0; i < instr->num_srcs; i++) {
+ switch (instr->src[i].src_type) {
+ case nir_tex_src_lod:
+ case nir_tex_src_ddx:
+ case nir_tex_src_ddy:
+ return false;
+ default:
+ break;
+ }
+ }
+ return true;
+}
+
static LLVMValueRef build_tex_intrinsic(struct ac_nir_context *ctx,
const nir_tex_instr *instr,
struct ac_image_args *args)
@@ -1394,6 +1418,11 @@ static LLVMValueRef build_tex_intrinsic(struct
ac_nir_context *ctx,
}
args->attributes = AC_FUNC_ATTR_READNONE;
+ /* Prevent texture instructions with implicit derivatives from being
+* sinked into branches. */
+ if (has_implicit_derivatives(instr))
+ args->attributes |= AC_FUNC_ATTR_CONVERGENT;
+
return ac_build_image_opcode(>ac, args);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: fix some compiler warnings
Fixes -Woverflow warnings with GCC 9.1.1 Signed-off-by: Rhys Perry --- src/amd/vulkan/si_cmd_buffer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c index aae8d578c10..d87c00b94e9 100644 --- a/src/amd/vulkan/si_cmd_buffer.c +++ b/src/amd/vulkan/si_cmd_buffer.c @@ -1360,7 +1360,7 @@ void radv_emit_default_sample_locations(struct radeon_cmdbuf *cs, int nr_samples default: case 1: radeon_set_context_reg_seq(cs, R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); - radeon_emit(cs, centroid_priority_1x); + radeon_emit(cs, centroid_priority_1x & 0x); radeon_emit(cs, centroid_priority_1x >> 32); radeon_set_context_reg(cs, R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_1x); radeon_set_context_reg(cs, R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_1x); @@ -1369,7 +1369,7 @@ void radv_emit_default_sample_locations(struct radeon_cmdbuf *cs, int nr_samples break; case 2: radeon_set_context_reg_seq(cs, R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); - radeon_emit(cs, centroid_priority_2x); + radeon_emit(cs, centroid_priority_2x & 0x); radeon_emit(cs, centroid_priority_2x >> 32); radeon_set_context_reg(cs, R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_2x); radeon_set_context_reg(cs, R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_2x); @@ -1378,7 +1378,7 @@ void radv_emit_default_sample_locations(struct radeon_cmdbuf *cs, int nr_samples break; case 4: radeon_set_context_reg_seq(cs, R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); - radeon_emit(cs, centroid_priority_4x); + radeon_emit(cs, centroid_priority_4x & 0x); radeon_emit(cs, centroid_priority_4x >> 32); radeon_set_context_reg(cs, R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, sample_locs_4x); radeon_set_context_reg(cs, R_028C08_PA_SC_AA_SAMPLE_LOCS_PIXEL_X1Y0_0, sample_locs_4x); @@ -1387,7 +1387,7 @@ void radv_emit_default_sample_locations(struct radeon_cmdbuf *cs, int nr_samples break; case 8: radeon_set_context_reg_seq(cs, R_028BD4_PA_SC_CENTROID_PRIORITY_0, 2); - radeon_emit(cs, centroid_priority_8x); + radeon_emit(cs, centroid_priority_8x & 0x); radeon_emit(cs, centroid_priority_8x >> 32); radeon_set_context_reg_seq(cs, R_028BF8_PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0, 14); radeon_emit_array(cs, sample_locs_8x, 4); -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: use RADV_CMD_DRITY_DYNAMIC_* when restoring viewport/scissor
r-b for both if you fix the DRITY in the title of this one.
On Thu, May 30, 2019 at 12:26 PM Samuel Pitoiset
wrote:
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
> index 721c7039830..3bfe49b4dab 100644
> --- a/src/amd/vulkan/radv_meta.c
> +++ b/src/amd/vulkan/radv_meta.c
> @@ -127,8 +127,8 @@ radv_meta_restore(const struct radv_meta_saved_state
> *state,
> state->scissor.scissors,
> MAX_SCISSORS);
>
> - cmd_buffer->state.dirty |= 1 << VK_DYNAMIC_STATE_VIEWPORT |
> - 1 << VK_DYNAMIC_STATE_SCISSOR;
> + cmd_buffer->state.dirty |= RADV_CMD_DIRTY_DYNAMIC_VIEWPORT |
> + RADV_CMD_DIRTY_DYNAMIC_SCISSOR;
> }
>
> if (state->flags & RADV_META_SAVE_COMPUTE_PIPELINE) {
> --
> 2.21.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] [Bug 110625] [TRACKER] Mesa 19.1 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=110625 Juan A. Suarez changed: What|Removed |Added CC||jasua...@igalia.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 110357] [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Juan A. Suarez changed: What|Removed |Added CC||jasua...@igalia.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] [PATCH 8/8] radv: enable VK_EXT_sample_locations
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 8
src/amd/vulkan/radv_extensions.py | 2 +-
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 3cf050ed220..16efc6134f1 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1370,17 +1370,9 @@ void radv_GetPhysicalDeviceProperties2(
case
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLE_LOCATIONS_PROPERTIES_EXT: {
VkPhysicalDeviceSampleLocationsPropertiesEXT
*properties =
(VkPhysicalDeviceSampleLocationsPropertiesEXT
*)ext;
- /* TODO: The ext is currently disabled because the
-* driver needs to handle sample locations during
-* layout transitions for depth/stencil surfaces and
-* HTILE.
-*/
- properties->sampleLocationSampleCounts =
VK_SAMPLE_COUNT_1_BIT;
- /*
properties->sampleLocationSampleCounts =
VK_SAMPLE_COUNT_2_BIT |
VK_SAMPLE_COUNT_4_BIT |
VK_SAMPLE_COUNT_8_BIT;
- */
properties->maxSampleLocationGridSize = (VkExtent2D){ 2
, 2 };
properties->sampleLocationCoordinateRange[0] = 0.0f;
properties->sampleLocationCoordinateRange[1] = 0.9375f;
diff --git a/src/amd/vulkan/radv_extensions.py
b/src/amd/vulkan/radv_extensions.py
index d6e9d5c034b..b14bd990e5f 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -119,7 +119,7 @@ EXTENSIONS = [
Extension('VK_EXT_memory_priority', 1, True),
Extension('VK_EXT_pci_bus_info', 2, True),
Extension('VK_EXT_pipeline_creation_feedback',1, True),
-Extension('VK_EXT_sample_locations', 1, False),
+Extension('VK_EXT_sample_locations', 1, True),
Extension('VK_EXT_sampler_filter_minmax', 1,
'device->rad_info.chip_class >= GFX7'),
Extension('VK_EXT_scalar_block_layout', 1,
'device->rad_info.chip_class >= GFX7'),
Extension('VK_EXT_shader_viewport_index_layer', 1, True),
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 03/18] intel/blorp: Use the hardware op for CCS ambiguate on gen10+
Feel free to land
On Wed, May 29, 2019 at 4:50 PM Nanley Chery wrote:
> On Wed, Feb 14, 2018 at 12:19 PM Jason Ekstrand
> wrote:
> >
> > Cannonlake hardware adds a new resolve type in 3DSTATE_PS called
> > FAST_CLEAR_0 which does an ambiguate. Now that the hardware can do it
> > directly, we should use that instead of binding the CCS as a render
> > target and doing it manually. This was tested with a full Vulkan CTS
> > run on Cannonlake.
> > ---
> > src/intel/blorp/blorp_clear.c | 12 +++-
> > src/intel/blorp/blorp_genX_exec.h | 6 ++
> > 2 files changed, 17 insertions(+), 1 deletion(-)
> >
>
> This patch is
> Reviewed-by: Nanley Chery
>
> > diff --git a/src/intel/blorp/blorp_clear.c
> b/src/intel/blorp/blorp_clear.c
> > index 421a6c5..4ba65d0 100644
> > --- a/src/intel/blorp/blorp_clear.c
> > +++ b/src/intel/blorp/blorp_clear.c
> > @@ -758,7 +758,11 @@ blorp_ccs_resolve(struct blorp_batch *batch,
> > params.x1 = ALIGN(params.x1, x_scaledown) / x_scaledown;
> > params.y1 = ALIGN(params.y1, y_scaledown) / y_scaledown;
> >
> > - if (batch->blorp->isl_dev->info->gen >= 9) {
> > + if (batch->blorp->isl_dev->info->gen >= 10) {
> > + assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
> > + resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE ||
> > + resolve_op == ISL_AUX_OP_AMBIGUATE);
> > + } else if (batch->blorp->isl_dev->info->gen >= 9) {
> >assert(resolve_op == ISL_AUX_OP_FULL_RESOLVE ||
> > resolve_op == ISL_AUX_OP_PARTIAL_RESOLVE);
> > } else {
> > @@ -893,6 +897,12 @@ blorp_ccs_ambiguate(struct blorp_batch *batch,
> > struct blorp_surf *surf,
> > uint32_t level, uint32_t layer)
> > {
> > + if (ISL_DEV_GEN(batch->blorp->isl_dev) >= 10) {
> > + /* On gen10 and above, we have a hardware resolve op for this */
> > + return blorp_ccs_resolve(batch, surf, level, layer, 1,
> > + surf->surf->format,
> ISL_AUX_OP_AMBIGUATE);
> > + }
> > +
> > struct blorp_params params;
> > blorp_params_init();
> >
> > diff --git a/src/intel/blorp/blorp_genX_exec.h
> b/src/intel/blorp/blorp_genX_exec.h
> > index 5e1312a..85abf6b 100644
> > --- a/src/intel/blorp/blorp_genX_exec.h
> > +++ b/src/intel/blorp/blorp_genX_exec.h
> > @@ -752,6 +752,12 @@ blorp_emit_ps_config(struct blorp_batch *batch,
> >switch (params->fast_clear_op) {
> >case ISL_AUX_OP_NONE:
> > break;
> > +#if GEN_GEN >= 10
> > + case ISL_AUX_OP_AMBIGUATE:
> > + ps.RenderTargetFastClearEnable = true;
> > + ps.RenderTargetResolveType = FAST_CLEAR_0;
> > + break;
> > +#endif
> > #if GEN_GEN >= 9
> >case ISL_AUX_OP_PARTIAL_RESOLVE:
> > ps.RenderTargetResolveType = RESOLVE_PARTIAL;
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > 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 2/8] radv: allow to set dynamic sample locations to the depth decompress pass
If VK_EXT_sample_locations is used, the driver might need to emit
the sample locations specified during layout transitions.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_decompress.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_meta_decompress.c
b/src/amd/vulkan/radv_meta_decompress.c
index fe8e114e91b..c51beb0c32d 100644
--- a/src/amd/vulkan/radv_meta_decompress.c
+++ b/src/amd/vulkan/radv_meta_decompress.c
@@ -126,6 +126,11 @@ create_pipeline(struct radv_device *device,
goto cleanup;
}
+ const VkPipelineSampleLocationsStateCreateInfoEXT
sample_locs_create_info = {
+ .sType =
VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT,
+ .sampleLocationsEnable = false,
+ };
+
const VkGraphicsPipelineCreateInfo pipeline_create_info = {
.sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO,
.stageCount = 2,
@@ -168,6 +173,7 @@ create_pipeline(struct radv_device *device,
},
.pMultisampleState = &(VkPipelineMultisampleStateCreateInfo) {
.sType =
VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO,
+ .pNext = _locs_create_info,
.rasterizationSamples = samples,
.sampleShadingEnable = false,
.pSampleMask = NULL,
@@ -189,10 +195,11 @@ create_pipeline(struct radv_device *device,
},
.pDynamicState = &(VkPipelineDynamicStateCreateInfo) {
.sType =
VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO,
- .dynamicStateCount = 2,
+ .dynamicStateCount = 3,
.pDynamicStates = (VkDynamicState[]) {
VK_DYNAMIC_STATE_VIEWPORT,
VK_DYNAMIC_STATE_SCISSOR,
+ VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_EXT,
},
},
.layout = layout,
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/8] radv: enable HTILE for images that might need variable sample locations
This is now supported. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_image.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c index b69dda39ce1..161997ae196 100644 --- a/src/amd/vulkan/radv_image.c +++ b/src/amd/vulkan/radv_image.c @@ -76,13 +76,6 @@ radv_use_tc_compat_htile_for_image(struct radv_device *device, (pCreateInfo->flags & VK_IMAGE_CREATE_EXTENDED_USAGE_BIT)) return false; - /* TODO: Implement layout transitions with variable sample locations -* before enabling HTILE for depth/stencil images created with this -* flags because the depth decompress pass needs to know them. -*/ - if (pCreateInfo->flags & VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT) - return false; - if (pCreateInfo->tiling == VK_IMAGE_TILING_LINEAR) return false; -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/8] radv: handle sample locations during automatic layout transitions
From the Vulkan spec 1.1.109:
"Some implementations may need to evaluate depth image values
while performing image layout transitions. To accommodate this,
instances of the VkSampleLocationsInfoEXT structure can be
specified for each situation where an explicit or automatic
layout transition has to take place. [...] and
VkRenderPassSampleLocationsBeginInfoEXT can be chained from
VkRenderPassBeginInfo to provide sample locations for layout
transitions performed implicitly by a render pass instance."
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 155 ---
src/amd/vulkan/radv_private.h| 9 ++
2 files changed, 150 insertions(+), 14 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 570acaa0905..81b3f5f9886 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2645,11 +2645,55 @@ void radv_subpass_barrier(struct radv_cmd_buffer
*cmd_buffer,
NULL);
}
+static uint32_t
+radv_get_subpass_id(struct radv_cmd_buffer *cmd_buffer)
+{
+ struct radv_cmd_state *state = _buffer->state;
+ uint32_t subpass_id = state->subpass - state->pass->subpasses;
+
+ /* The id of this subpass shouldn't exceed the number of subpasses in
+* this render pass minus 1.
+*/
+ assert(subpass_id < state->pass->subpass_count);
+ return subpass_id;
+}
+
+static struct radv_sample_locations_state *
+radv_get_attachment_sample_locations(struct radv_cmd_buffer *cmd_buffer,
+uint32_t att_idx)
+{
+ struct radv_cmd_state *state = _buffer->state;
+ uint32_t subpass_id = radv_get_subpass_id(cmd_buffer);
+ struct radv_image_view *view =
state->framebuffer->attachments[att_idx].attachment;
+
+ if (view->image->info.samples == 1)
+ return NULL;
+
+ if (state->pass->attachments[att_idx].first_subpass_idx == subpass_id) {
+ /* Return the initial sample locations if this is the initial
+* layout transition of the given subpass attachemnt.
+*/
+ if (state->attachments[att_idx].sample_location.count > 0)
+ return >attachments[att_idx].sample_location;
+ } else {
+ /* Otherwise return the subpass sample locations if defined. */
+ if (state->subpass_sample_locs) {
+ for (uint32_t i = 0; i <
state->num_subpass_sample_locs; i++) {
+ if (state->subpass_sample_locs[i].subpass_idx
== subpass_id)
+ return
>subpass_sample_locs[i].sample_location;
+ }
+ }
+ }
+
+ return NULL;
+}
+
static void radv_handle_subpass_image_transition(struct radv_cmd_buffer
*cmd_buffer,
struct radv_subpass_attachment
att)
{
unsigned idx = att.attachment;
struct radv_image_view *view =
cmd_buffer->state.framebuffer->attachments[idx].attachment;
+ struct radv_sample_locations_state *sample_locs;
VkImageSubresourceRange range;
range.aspectMask = 0;
range.baseMipLevel = view->base_mip;
@@ -2668,10 +2712,15 @@ static void radv_handle_subpass_image_transition(struct
radv_cmd_buffer *cmd_buf
range.layerCount =
util_last_bit(cmd_buffer->state.subpass->view_mask);
}
+ /* Get the subpass sample locations for the given attachment, if NULL
+* is returned the driver will use the default HW locations.
+*/
+ sample_locs = radv_get_attachment_sample_locations(cmd_buffer, idx);
+
radv_handle_image_transition(cmd_buffer,
view->image,
cmd_buffer->state.attachments[idx].current_layout,
-att.layout, 0, 0, , NULL);
+att.layout, 0, 0, , sample_locs);
cmd_buffer->state.attachments[idx].current_layout = att.layout;
@@ -2687,6 +2736,89 @@ radv_cmd_buffer_set_subpass(struct radv_cmd_buffer
*cmd_buffer,
cmd_buffer->state.dirty |= RADV_CMD_DIRTY_FRAMEBUFFER;
}
+static VkResult
+radv_cmd_state_setup_sample_locations(struct radv_cmd_buffer *cmd_buffer,
+ struct radv_render_pass *pass,
+ const VkRenderPassBeginInfo *info)
+{
+ const struct VkRenderPassSampleLocationsBeginInfoEXT *sample_locs =
+ vk_find_struct_const(info->pNext,
+
RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT);
+ struct radv_cmd_state *state = _buffer->state;
+ struct radv_framebuffer *framebuffer = state->framebuffer;
+
+ if (!sample_locs) {
+
[Mesa-dev] [PATCH 4/8] radv: handle sample locations during explicit depth/stencil transitions
From the Vulkan spec 1.1.109,
"Some implementations may need to evaluate depth image values
while performing image layout transitions. To accommodate this,
instances of the VkSampleLocationsInfoEXT structure can be
specified for each situation where an explicit or automatic
layout transition has to take place. VkSampleLocationsInfoEXT
can be chained from VkImageMemoryBarrier structures to provide
sample locations for layout transitions performed by
vkCmdWaitEvents and vkCmdPipelineBarrier calls."
This handles explicit depth/stencil layout transitions performed
with CmdWaitEvents() or CmdPipelineBarrier().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 35 +---
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8db4fcdbdc1..570acaa0905 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -32,6 +32,7 @@
#include "sid.h"
#include "gfx9d.h"
#include "vk_format.h"
+#include "vk_util.h"
#include "radv_debug.h"
#include "radv_meta.h"
@@ -57,7 +58,8 @@ static void radv_handle_image_transition(struct
radv_cmd_buffer *cmd_buffer,
VkImageLayout dst_layout,
uint32_t src_family,
uint32_t dst_family,
-const VkImageSubresourceRange *range);
+const VkImageSubresourceRange *range,
+struct radv_sample_locations_state
*sample_locs);
const struct radv_dynamic_state default_dynamic_state = {
.viewport = {
@@ -2669,7 +2671,7 @@ static void radv_handle_subpass_image_transition(struct
radv_cmd_buffer *cmd_buf
radv_handle_image_transition(cmd_buffer,
view->image,
cmd_buffer->state.attachments[idx].current_layout,
-att.layout, 0, 0, );
+att.layout, 0, 0, , NULL);
cmd_buffer->state.attachments[idx].current_layout = att.layout;
@@ -4651,7 +4653,8 @@ static void radv_handle_depth_image_transition(struct
radv_cmd_buffer *cmd_buffe
VkImageLayout dst_layout,
unsigned src_queue_mask,
unsigned dst_queue_mask,
- const VkImageSubresourceRange
*range)
+ const VkImageSubresourceRange
*range,
+ struct
radv_sample_locations_state *sample_locs)
{
if (!radv_image_has_htile(image))
return;
@@ -4680,7 +4683,7 @@ static void radv_handle_depth_image_transition(struct
radv_cmd_buffer *cmd_buffe
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
radv_decompress_depth_image_inplace(cmd_buffer, image,
- _range, NULL);
+ _range, sample_locs);
cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB |
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
@@ -4842,7 +4845,8 @@ static void radv_handle_image_transition(struct
radv_cmd_buffer *cmd_buffer,
VkImageLayout dst_layout,
uint32_t src_family,
uint32_t dst_family,
-const VkImageSubresourceRange *range)
+const VkImageSubresourceRange *range,
+struct radv_sample_locations_state
*sample_locs)
{
if (image->exclusive && src_family != dst_family) {
/* This is an acquire or a release operation and there will be
@@ -4875,7 +4879,7 @@ static void radv_handle_image_transition(struct
radv_cmd_buffer *cmd_buffer,
radv_handle_depth_image_transition(cmd_buffer, image,
src_layout, dst_layout,
src_queue_mask,
dst_queue_mask,
- range);
+ range, sample_locs);
} else {
radv_handle_color_image_transition(cmd_buffer, image,
src_layout, dst_layout,
@@ -4957,12 +4961,29 @@ radv_barrier(struct radv_cmd_buffer *cmd_buffer,
for (uint32_t i = 0; i < imageMemoryBarrierCount; i++) {
RADV_FROM_HANDLE(radv_image, image,
[Mesa-dev] [PATCH 0/8] radv: add support for sample locations during layout transitions
Hi, This series implements user sample locations during explicit and automatic (subpass) layout transitions as defined by VK_EXT_sample_locations. Previously, HTILE was disabled for depth/stencil images that might need sample locations because it was a bit tricky to implement. The last patch of this series enables VK_EXT_sample_locations. Please review, thanks! Samuel Pitoiset (8): radv: allow to save/restore sample locations during meta operations radv: allow to set dynamic sample locations to the depth decompress pass radv: allow the depth decompress pass to emit dynamic sample locations radv: handle sample locations during explicit depth/stencil transitions radv: determine the first subpass id for every attachments radv: handle sample locations during automatic layout transitions radv: enable HTILE for images that might need variable sample locations radv: enable VK_EXT_sample_locations src/amd/vulkan/radv_cmd_buffer.c | 189 +++--- src/amd/vulkan/radv_device.c | 8 -- src/amd/vulkan/radv_extensions.py | 2 +- src/amd/vulkan/radv_image.c | 7 - src/amd/vulkan/radv_meta.c| 20 +++ src/amd/vulkan/radv_meta.h| 8 +- src/amd/vulkan/radv_meta_decompress.c | 38 +- src/amd/vulkan/radv_pass.c| 18 +++ src/amd/vulkan/radv_private.h | 12 +- 9 files changed, 258 insertions(+), 44 deletions(-) -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/8] radv: determine the first subpass id for every attachments
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pass.c| 18 ++
src/amd/vulkan/radv_private.h | 3 ++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pass.c b/src/amd/vulkan/radv_pass.c
index 4d1e38a780e..8fa098eaac8 100644
--- a/src/amd/vulkan/radv_pass.c
+++ b/src/amd/vulkan/radv_pass.c
@@ -62,6 +62,22 @@ radv_render_pass_add_subpass_dep(struct radv_render_pass
*pass,
static void
radv_render_pass_compile(struct radv_render_pass *pass)
{
+ for (uint32_t i = 0; i < pass->subpass_count; i++) {
+ struct radv_subpass *subpass = >subpasses[i];
+
+ for (uint32_t j = 0; j < subpass->attachment_count; j++) {
+ struct radv_subpass_attachment *subpass_att =
+ >attachments[j];
+ if (subpass_att->attachment == VK_ATTACHMENT_UNUSED)
+ continue;
+
+ struct radv_render_pass_attachment *pass_att =
+ >attachments[subpass_att->attachment];
+
+ pass_att->first_subpass_idx = UINT32_MAX;
+ }
+ }
+
for (uint32_t i = 0; i < pass->subpass_count; i++) {
struct radv_subpass *subpass = >subpasses[i];
uint32_t color_sample_count = 1, depth_sample_count = 1;
@@ -84,6 +100,8 @@ radv_render_pass_compile(struct radv_render_pass *pass)
struct radv_render_pass_attachment *pass_att =
>attachments[subpass_att->attachment];
+ if (i < pass_att->first_subpass_idx)
+ pass_att->first_subpass_idx = i;
pass_att->last_subpass_idx = i;
}
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 828edb56540..180f8b976ab 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1920,7 +1920,8 @@ struct radv_render_pass_attachment {
VkImageLayoutinitial_layout;
VkImageLayoutfinal_layout;
- /* The subpass id in which the attachment will be used last. */
+ /* The subpass id in which the attachment will be used first/last. */
+ uint32_t first_subpass_idx;
uint32_t last_subpass_idx;
};
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/8] radv: allow to save/restore sample locations during meta operations
This will be used for the depth decompress pass that might need
to emit variable sample locations during layout transitions.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta.c | 20
src/amd/vulkan/radv_meta.h | 2 ++
2 files changed, 22 insertions(+)
diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
index 3bfe49b4dab..44715483565 100644
--- a/src/amd/vulkan/radv_meta.c
+++ b/src/amd/vulkan/radv_meta.c
@@ -73,6 +73,15 @@ radv_meta_save(struct radv_meta_saved_state *state,
1 << VK_DYNAMIC_STATE_SCISSOR;
}
+ if (state->flags & RADV_META_SAVE_SAMPLE_LOCATIONS) {
+ state->sample_location.per_pixel =
cmd_buffer->state.dynamic.sample_location.per_pixel;
+ state->sample_location.grid_size =
cmd_buffer->state.dynamic.sample_location.grid_size;
+ state->sample_location.count =
cmd_buffer->state.dynamic.sample_location.count;
+ typed_memcpy(state->sample_location.locations,
+
cmd_buffer->state.dynamic.sample_location.locations,
+MAX_SAMPLE_LOCATIONS);
+ }
+
if (state->flags & RADV_META_SAVE_COMPUTE_PIPELINE) {
assert(!(state->flags & RADV_META_SAVE_GRAPHICS_PIPELINE));
@@ -131,6 +140,17 @@ radv_meta_restore(const struct radv_meta_saved_state
*state,
RADV_CMD_DIRTY_DYNAMIC_SCISSOR;
}
+ if (state->flags & RADV_META_SAVE_SAMPLE_LOCATIONS) {
+ cmd_buffer->state.dynamic.sample_location.per_pixel =
state->sample_location.per_pixel;
+ cmd_buffer->state.dynamic.sample_location.grid_size =
state->sample_location.grid_size;
+ cmd_buffer->state.dynamic.sample_location.count =
state->sample_location.count;
+
typed_memcpy(cmd_buffer->state.dynamic.sample_location.locations,
+state->sample_location.locations,
+MAX_SAMPLE_LOCATIONS);
+
+ cmd_buffer->state.dirty |=
RADV_CMD_DIRTY_DYNAMIC_SAMPLE_LOCATIONS;
+ }
+
if (state->flags & RADV_META_SAVE_COMPUTE_PIPELINE) {
radv_CmdBindPipeline(radv_cmd_buffer_to_handle(cmd_buffer),
VK_PIPELINE_BIND_POINT_COMPUTE,
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 4a7c37be9b3..66c8df6b9e9 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -39,6 +39,7 @@ enum radv_meta_save_flags {
RADV_META_SAVE_DESCRIPTORS = (1 << 2),
RADV_META_SAVE_GRAPHICS_PIPELINE = (1 << 3),
RADV_META_SAVE_COMPUTE_PIPELINE = (1 << 4),
+ RADV_META_SAVE_SAMPLE_LOCATIONS = (1 << 5),
};
struct radv_meta_saved_state {
@@ -48,6 +49,7 @@ struct radv_meta_saved_state {
struct radv_pipeline *old_pipeline;
struct radv_viewport_state viewport;
struct radv_scissor_state scissor;
+ struct radv_sample_locations_state sample_location;
char push_constants[128];
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/8] radv: allow the depth decompress pass to emit dynamic sample locations
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 3 ++-
src/amd/vulkan/radv_meta.h| 6 --
src/amd/vulkan/radv_meta_decompress.c | 29 +++
3 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 5338a8b9fe2..8db4fcdbdc1 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4679,7 +4679,8 @@ static void radv_handle_depth_image_transition(struct
radv_cmd_buffer *cmd_buffe
cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB |
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
- radv_decompress_depth_image_inplace(cmd_buffer, image,
_range);
+ radv_decompress_depth_image_inplace(cmd_buffer, image,
+ _range, NULL);
cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB |
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 66c8df6b9e9..59b9121cf39 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -169,10 +169,12 @@ void radv_meta_clear_image_cs(struct radv_cmd_buffer
*cmd_buffer,
void radv_decompress_depth_image_inplace(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
-VkImageSubresourceRange
*subresourceRange);
+VkImageSubresourceRange
*subresourceRange,
+struct radv_sample_locations_state
*sample_locs);
void radv_resummarize_depth_image_inplace(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
- VkImageSubresourceRange
*subresourceRange);
+ VkImageSubresourceRange
*subresourceRange,
+ struct radv_sample_locations_state
*sample_locs);
void radv_fast_clear_flush_image_inplace(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
const VkImageSubresourceRange
*subresourceRange);
diff --git a/src/amd/vulkan/radv_meta_decompress.c
b/src/amd/vulkan/radv_meta_decompress.c
index c51beb0c32d..578a287d07b 100644
--- a/src/amd/vulkan/radv_meta_decompress.c
+++ b/src/amd/vulkan/radv_meta_decompress.c
@@ -323,6 +323,7 @@ enum radv_depth_op {
static void radv_process_depth_image_inplace(struct radv_cmd_buffer
*cmd_buffer,
struct radv_image *image,
VkImageSubresourceRange
*subresourceRange,
+struct radv_sample_locations_state
*sample_locs,
enum radv_depth_op op)
{
struct radv_meta_saved_state saved_state;
@@ -354,6 +355,7 @@ static void radv_process_depth_image_inplace(struct
radv_cmd_buffer *cmd_buffer,
radv_meta_save(_state, cmd_buffer,
RADV_META_SAVE_GRAPHICS_PIPELINE |
+ RADV_META_SAVE_SAMPLE_LOCATIONS |
RADV_META_SAVE_PASS);
switch (op) {
@@ -384,6 +386,21 @@ static void radv_process_depth_image_inplace(struct
radv_cmd_buffer *cmd_buffer,
.extent = { width, height },
});
+ if (sample_locs) {
+ assert(image->flags &
VK_IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT);
+
+ /* Set the sample locations specified during explicit or
+* automatic layout transitions, otherwise the depth decompress
+* pass uses the default HW locations.
+*/
+ radv_CmdSetSampleLocationsEXT(cmd_buffer_h,
&(VkSampleLocationsInfoEXT) {
+ .sampleLocationsPerPixel = sample_locs->per_pixel,
+ .sampleLocationGridSize = sample_locs->grid_size,
+ .sampleLocationsCount = sample_locs->count,
+ .pSampleLocations = sample_locs->locations,
+ });
+ }
+
for (uint32_t layer = 0; layer < radv_get_layerCount(image,
subresourceRange); layer++) {
struct radv_image_view iview;
@@ -449,16 +466,20 @@ static void radv_process_depth_image_inplace(struct
radv_cmd_buffer *cmd_buffer,
void radv_decompress_depth_image_inplace(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
-VkImageSubresourceRange
*subresourceRange)
+VkImageSubresourceRange
*subresourceRange,
+
[Mesa-dev] [PATCH] radv: set the subpass before any initial subpass transitions
This might fix initial subpass transitions when multiview is used.
Noticed while implementing sample locations during layout transitions.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 7744ef48d06..abf454595f5 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2658,7 +2658,7 @@ static void radv_handle_subpass_image_transition(struct
radv_cmd_buffer *cmd_buf
range.baseArrayLayer = view->base_layer;
range.layerCount = cmd_buffer->state.framebuffer->layers;
- if (cmd_buffer->state.subpass && cmd_buffer->state.subpass->view_mask) {
+ if (cmd_buffer->state.subpass->view_mask) {
/* If the current subpass uses multiview, the driver might have
* performed a fast color/depth clear to the whole image
* (including all layers). To make sure the driver will
@@ -3761,6 +3761,8 @@ radv_cmd_buffer_begin_subpass(struct radv_cmd_buffer
*cmd_buffer,
radv_subpass_barrier(cmd_buffer, >start_barrier);
+ radv_cmd_buffer_set_subpass(cmd_buffer, subpass);
+
for (uint32_t i = 0; i < subpass->attachment_count; ++i) {
const uint32_t a = subpass->attachments[i].attachment;
if (a == VK_ATTACHMENT_UNUSED)
@@ -3770,7 +3772,6 @@ radv_cmd_buffer_begin_subpass(struct radv_cmd_buffer
*cmd_buffer,
subpass->attachments[i]);
}
- radv_cmd_buffer_set_subpass(cmd_buffer, subpass);
radv_cmd_buffer_clear_subpass(cmd_buffer);
assert(cmd_buffer->cs->cdw <= cdw_max);
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: enable transformFeedbackStreamsLinesTriangles
r-b On Thu, May 30, 2019 at 10:05 AM Samuel Pitoiset wrote: > > The driver should already support this without any changes. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_device.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c > index d04dcbed89e..16efc6134f1 100644 > --- a/src/amd/vulkan/radv_device.c > +++ b/src/amd/vulkan/radv_device.c > @@ -1351,7 +1351,7 @@ void radv_GetPhysicalDeviceProperties2( > properties->maxTransformFeedbackBufferDataSize = > UINT32_MAX; > properties->maxTransformFeedbackBufferDataStride = > 512; > properties->transformFeedbackQueries = true; > - properties->transformFeedbackStreamsLinesTriangles = > false; > + properties->transformFeedbackStreamsLinesTriangles = > true; > > properties->transformFeedbackRasterizationStreamSelect = false; > properties->transformFeedbackDraw = true; > break; > -- > 2.21.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] d3dadapter9: Revert to old throttling limit value
Thanks Juan for warning me it didn't make it to mesa-dev. Here it is. Axel Forwarded Message Subject:[PATCH] d3dadapter9: Revert to old throttling limit value Date: Sun, 26 May 2019 23:23:59 +0200 From: Axel Davy CC: Axel Davy , mesa-sta...@lists.freedesktop.org Recently PIPE_CAP_MAX_FRAMES_IN_FLIGHT was changed from 2 to 1: 20909284f204091757c050aa40cfffaf3f981b9c No driver seems to overwrite the default value. One user reports severe regressions for some games. For now, revert to the value 2 for nine. Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Axel Davy --- src/gallium/targets/d3dadapter9/drm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/targets/d3dadapter9/drm.c b/src/gallium/targets/d3dadapter9/drm.c index b0b9bb12f2c..657c619ac42 100644 --- a/src/gallium/targets/d3dadapter9/drm.c +++ b/src/gallium/targets/d3dadapter9/drm.c @@ -243,8 +243,10 @@ drm_create_adapter( int fd, return D3DERR_DRIVERINTERNALERROR; } - ctx->base.throttling_value = - ctx->base.hal->get_param(ctx->base.hal, PIPE_CAP_MAX_FRAMES_IN_FLIGHT); + /* Previously was set to PIPE_CAP_MAX_FRAMES_IN_FLIGHT, + * but the change of value of this cap to 1 seems to cause + * regressions. */ + ctx->base.throttling_value = 2; ctx->base.throttling = ctx->base.throttling_value > 0; driParseOptionInfo(, __driConfigOptionsNine); -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radv: use CmdPushConstants when restoring constants after meta operations
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
index ec4fc4a6d4b..721c7039830 100644
--- a/src/amd/vulkan/radv_meta.c
+++ b/src/amd/vulkan/radv_meta.c
@@ -143,13 +143,15 @@ radv_meta_restore(const struct radv_meta_saved_state
*state,
}
if (state->flags & RADV_META_SAVE_CONSTANTS) {
- memcpy(cmd_buffer->push_constants, state->push_constants,
- MAX_PUSH_CONSTANTS_SIZE);
- cmd_buffer->push_constant_stages |= VK_SHADER_STAGE_COMPUTE_BIT;
+ VkShaderStageFlags stages = VK_SHADER_STAGE_COMPUTE_BIT;
- if (state->flags & RADV_META_SAVE_GRAPHICS_PIPELINE) {
- cmd_buffer->push_constant_stages |=
VK_SHADER_STAGE_ALL_GRAPHICS;
- }
+ if (state->flags & RADV_META_SAVE_GRAPHICS_PIPELINE)
+ stages |= VK_SHADER_STAGE_ALL_GRAPHICS;
+
+ radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
+ VK_NULL_HANDLE, stages, 0,
+ MAX_PUSH_CONSTANTS_SIZE,
+ state->push_constants);
}
if (state->flags & RADV_META_SAVE_PASS) {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radv: use RADV_CMD_DRITY_DYNAMIC_* when restoring viewport/scissor
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
index 721c7039830..3bfe49b4dab 100644
--- a/src/amd/vulkan/radv_meta.c
+++ b/src/amd/vulkan/radv_meta.c
@@ -127,8 +127,8 @@ radv_meta_restore(const struct radv_meta_saved_state *state,
state->scissor.scissors,
MAX_SCISSORS);
- cmd_buffer->state.dirty |= 1 << VK_DYNAMIC_STATE_VIEWPORT |
- 1 << VK_DYNAMIC_STATE_SCISSOR;
+ cmd_buffer->state.dirty |= RADV_CMD_DIRTY_DYNAMIC_VIEWPORT |
+ RADV_CMD_DIRTY_DYNAMIC_SCISSOR;
}
if (state->flags & RADV_META_SAVE_COMPUTE_PIPELINE) {
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: enable transformFeedbackStreamsLinesTriangles
The driver should already support this without any changes. Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c index d04dcbed89e..16efc6134f1 100644 --- a/src/amd/vulkan/radv_device.c +++ b/src/amd/vulkan/radv_device.c @@ -1351,7 +1351,7 @@ void radv_GetPhysicalDeviceProperties2( properties->maxTransformFeedbackBufferDataSize = UINT32_MAX; properties->maxTransformFeedbackBufferDataStride = 512; properties->transformFeedbackQueries = true; - properties->transformFeedbackStreamsLinesTriangles = false; + properties->transformFeedbackStreamsLinesTriangles = true; properties->transformFeedbackRasterizationStreamSelect = false; properties->transformFeedbackDraw = true; break; -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Crash in iris_bufmgr.c
On Wednesday, May 29, 2019 10:30:45 PM PDT Mathias Fröhlich wrote: > Hi Kenneth, > > since your recent changes, I get a zero pointer dereference in > alloc_bo_from_cache on one workload here: > > What I get is > > Thread 2 "" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffef776700 (LWP 20924)] > list_del (item=0x7fffe8ae4020) at ../src/util/list.h:91 > 91 item->prev->next = item->next; > (gdb) p item->prev > $1 = (struct list_head *) 0x0 > (gdb) where > #0 list_del (item=0x7fffe8ae4020) at ../src/util/list.h:91 > #1 0x7469072f in alloc_bo_from_cache (bufmgr=0x4d8370, > bucket=0x4d8418, memzone=IRIS_MEMZONE_OTHER, flags=0, match_zone=true) > at ../src/gallium/drivers/iris/iris_bufmgr.c:387 > [...] > > I think the reason is that you use list_for_each_entry_safe in > alloc_bo_from_cache in the outer loop and store a pointer to > the next list entry. But when you call into iris_bo_cache_purge_bucket > from inside that loop the function body there may walk the same list > node than __next from list_for_each_entry_safe in alloc_bo_from_cache > points to and may zero the list pointers out. > > You may know best how to fix that. > > best and thanks > Mathias Ouch. Thanks for letting me know. Fixed by: commit 53878f7a8989879b0f3ca37df9fd1fb37f2525ca Author: Kenneth Graunke Date: Wed May 29 23:20:31 2019 -0700 iris: Be lazy about cleaning up purged BOs in the cache. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
