[Mesa-dev] [PATCH] nvc0: advertise 8 bits subpixel precision for viewport bounds
Based on subpixel precision returned by the blob. Signed-off-by: Józef Kucia --- I've checked that the blob returns 8 for the following GPUs: GeForce GTX 460 (GF104), GeForce GTX 760 (GK104), GeForce GTX 970 (GM204). Generally, I expect that 8 bits precision should be supported by any D3D11-capable GPU. --- src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index fb0a9c8..836ee23 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -156,6 +156,8 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) return NOUVEAU_MIN_BUFFER_MAP_ALIGN; case PIPE_CAP_MAX_VIEWPORTS: return NVC0_MAX_VIEWPORTS; + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: + return 8; case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS: return 4; case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK: @@ -272,7 +274,6 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_PCI_BUS: case PIPE_CAP_PCI_DEVICE: case PIPE_CAP_PCI_FUNCTION: - case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_VENDOR_ID: -- 2.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GL_DEPTH_STENCIL_TEXTURE_MODE and filter type
Hello, Sampling the stencil value in Mesa seems to work only with NEAREST filter type. This seems to be consistent with the following excerpt from the GL spec: "In order to access the stencil index texture component the DEPTH_STENCIL_TEXTURE_MODE texture parameter should be set to STENCIL_INDEX . When this mode is set the depth component is ignored and the texture value includes only the stencil index component. The stencil index value is treated as an unsigned integer texture and returns an unsigned integer value when sampled. When sampling the stencil index only NEAREST filtering is supported. The DEPTH_STENCIL_TEXTURE_MODE is ignored for non depth/stencil textures.". On the other hand, I think it would make sense to allow the same filter types as for integer samplers. The Nvidia blob seems to allow the usage of NEAREST_MIPMAP_NEAREST for stencil texturing. Moreover, there is the following item in the GL 4.5 spec changelog: "Add NEAREST_MIPMAP_NEAREST to the allowed filter modes for STENCIL_INDEX textures in section 8.17 (Bug 12791).". The section 8.17 says that is said to be complete when "The internal format is DEPTH_STENCIL and the value of DEPTH_STENCIL_TEXTURE_MODE for the texture is STENCIL_INDEX" and the minification filter is NEAREST or NEAREST_MIPMAP_NEAREST. I don't have access to the bug 12791 so I cannot say what it is about exactly, but was its intention to allow NEAREST_MIPMAP_NEAREST for stencil texturing using DEPTH_STENCIL_TEXTURE_MODE? Or was this change meant to be just for STENCIL_INDEX textures? Is there are a reason why NEAREST_MIPMAP_NEAREST cannot also be used with depth stencil textures and DEPTH_STENCIL_TEXTURE_MODE? Is this just an inconsistency in the GL spec? Cheers, Józef Kucia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main: allow NEAREST_MIPMAP_NEAREST for stencil texturing
On Mon, Dec 5, 2016 at 1:40 PM, wrote: > From: Roland Scheidegger > > As per GL 4.5 rules, which fixed a spec mistake in GL_ARB_stencil_texturing. > The extension spec wasn't updated, but just allow it with older GL versions > as well, hoping there aren't any crazy tests which want to see an error > there... (Compile tested only.) > > Reported by Józef Kucia > --- > src/mesa/main/texobj.h | 23 --- > 1 file changed, 8 insertions(+), 15 deletions(-) FWIW, the patch looks good to me. Thanks! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium: add a cap for VIEWPORT_SUBPIXEL_BITS
This allows Gallium drivers to advertise the subpixel precision for floating point viewports bounds. Signed-off-by: Józef Kucia --- Currently all Mesa drivers return 0 for GL_VIEWPORT_SUBPIXEL_BITS regardless whether floating point viewport bounds are supported. From the ARB_viewport_array spec: "More specifically, if VIEWPORT_SUBPIXEL_BITS is zero, then this indicates that the viewport bounds are likely implemented using integers in hardware." I do not have commit access. --- src/gallium/docs/source/screen.rst | 2 ++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/mesa/state_tracker/st_extensions.c | 2 ++ 18 files changed, 20 insertions(+) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 141b45a..34f2e72 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -345,6 +345,8 @@ The integer capabilities: supported in ``set_window_rectangles``. * ``PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED``: If true, the driver implements support for ``pipe_rasterizer_state::offset_units_unscaled``. +* ``PIPE_CAP_VIEWPORT_SUBPIXEL_BITS``: Number of bits of subpixel precision for + floating point viewport bounds. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 5255c10..81fb2ad 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -267,6 +267,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_MAX_VIEWPORTS: diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 3f0ab98..6b5218b 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -290,6 +290,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_SAMPLER_VIEW_TARGET: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_MAX_VIEWPORTS: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 2024688..448f512 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -505,6 +505,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 684c7a5..61c3fb7 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -328,6 +328,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; } /* should only get here on unhandled cases */ diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 68d8317..3d75021 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c @@ -199,6 +199,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 303ecf1..d18a768 100644 --- a/src/gallium/drivers/no
Re: [Mesa-dev] [PATCH] gallium: add a cap for VIEWPORT_SUBPIXEL_BITS
On Sat, Jul 16, 2016 at 11:51 PM, Ilia Mirkin wrote: > Of course none of this actually changes backends to return > 0 bits... > did you mean to follow up with further patches? Yes, I wanted to try to change GL_VIEWPORT_SUBPIXEL_BITS at least for some drivers (r600, radeonsi, nouveau). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium: add a cap for VIEWPORT_SUBPIXEL_BITS
On Mon, Jul 18, 2016 at 1:35 PM, Marek Olšák wrote: > FWIW, r600 and radeonsi should return 8. > > Marek Thanks, I'll send patches. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] r600: advertise 8 bits subpixel precision for viewport bounds
Signed-off-by: Józef Kucia --- src/gallium/drivers/r600/r600_pipe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 6bd027b..a3b6189 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -371,7 +371,6 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES: case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: - case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: @@ -420,6 +419,8 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_MAX_VIEWPORTS: return R600_MAX_VIEWPORTS; + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: + return 8; /* Timer queries, present when the clock frequency is non zero. */ case PIPE_CAP_QUERY_TIME_ELAPSED: -- 2.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] radeonsi: advertise 8 bits subpixel precision for viewport bounds
Signed-off-by: Józef Kucia --- src/gallium/drivers/radeonsi/si_pipe.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_pipe.c b/src/gallium/drivers/radeonsi/si_pipe.c index 768dc8c..6a496c2 100644 --- a/src/gallium/drivers/radeonsi/si_pipe.c +++ b/src/gallium/drivers/radeonsi/si_pipe.c @@ -444,7 +444,6 @@ static int si_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES: case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: - case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS: @@ -490,6 +489,8 @@ static int si_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_MAX_VIEWPORTS: return R600_MAX_VIEWPORTS; + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: + return 8; /* Timer queries, present when the clock frequency is non zero. */ case PIPE_CAP_QUERY_TIMESTAMP: -- 2.7.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium: add a cap for VIEWPORT_SUBPIXEL_BITS (v2)
This allows Gallium drivers to advertise the subpixel precision for floating point viewports bounds. v2: - Set ViewportSubpixelBits in st_init_limits. Signed-off-by: Józef Kucia --- Currently all Mesa drivers return 0 for GL_VIEWPORT_SUBPIXEL_BITS regardless whether floating point viewport bounds are supported. From the ARB_viewport_array spec: "More specifically, if VIEWPORT_SUBPIXEL_BITS is zero, then this indicates that the viewport bounds are likely implemented using integers in hardware." I do not have commit access. --- src/gallium/docs/source/screen.rst | 2 ++ src/gallium/drivers/freedreno/freedreno_screen.c | 1 + src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/nouveau/nv30/nv30_screen.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_screen.c | 1 + src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 + src/gallium/drivers/r300/r300_screen.c | 1 + src/gallium/drivers/r600/r600_pipe.c | 1 + src/gallium/drivers/radeonsi/si_pipe.c | 1 + src/gallium/drivers/softpipe/sp_screen.c | 1 + src/gallium/drivers/svga/svga_screen.c | 1 + src/gallium/drivers/swr/swr_screen.cpp | 1 + src/gallium/drivers/vc4/vc4_screen.c | 1 + src/gallium/drivers/virgl/virgl_screen.c | 1 + src/gallium/include/pipe/p_defines.h | 1 + src/mesa/state_tracker/st_extensions.c | 3 +++ 18 files changed, 21 insertions(+) diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst index 141b45a..34f2e72 100644 --- a/src/gallium/docs/source/screen.rst +++ b/src/gallium/docs/source/screen.rst @@ -345,6 +345,8 @@ The integer capabilities: supported in ``set_window_rectangles``. * ``PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED``: If true, the driver implements support for ``pipe_rasterizer_state::offset_units_unscaled``. +* ``PIPE_CAP_VIEWPORT_SUBPIXEL_BITS``: Number of bits of subpixel precision for + floating point viewport bounds. .. _pipe_capf: diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c b/src/gallium/drivers/freedreno/freedreno_screen.c index 5255c10..81fb2ad 100644 --- a/src/gallium/drivers/freedreno/freedreno_screen.c +++ b/src/gallium/drivers/freedreno/freedreno_screen.c @@ -267,6 +267,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_MAX_VIEWPORTS: diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 3f0ab98..6b5218b 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -290,6 +290,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS: case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE: case PIPE_CAP_SAMPLER_VIEW_TARGET: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_MAX_VIEWPORTS: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index 2024688..448f512 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -505,6 +505,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index 684c7a5..61c3fb7 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -328,6 +328,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; } /* should only get here on unhandled cases */ diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c b/src/gallium/drivers/nouveau/nv30/nv30_screen.c index 68d8317..3d75021 100644 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c @@ -199,6 +199,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_VOTE: case PIPE_CAP_MAX_WINDOW_RECTANGLES: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS: return 0; case PIPE_CAP_VENDOR_ID: diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 303ecf
Re: [Mesa-dev] [PATCH RFC 5/8] gm107/ir: add emission for SUSTx and SULDx
On Mon, Jul 18, 2016 at 10:55 PM, Samuel Pitoiset
wrote:
> + } else if (insn->tex.target == TEX_TARGET_2D_ARRAY ||
> + insn->tex.target == TEX_TARGET_CUBE ||
> + insn->tex.target == TEX_TARGET_CUBE_ARRAY) {
> + target = 8;
> + } else if (insn->tex.target == TEX_TARGET_3D ||
> + insn->tex.target == TEX_TARGET_CUBE_ARRAY) {
> + target = 10;
TEX_TARGET_CUBE_ARRAY is listed twice. Apart from that a switch
statement might be more readable.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: Fix driverUUID
--- 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 83d218fb6bf0..6deb69d22d48 100644 --- a/src/amd/vulkan/radv_device.c +++ b/src/amd/vulkan/radv_device.c @@ -337,7 +337,7 @@ radv_physical_device_init(struct radv_physical_device *device, device->rad_info.chip_class > GFX9) fprintf(stderr, "WARNING: radv is not a conformant vulkan implementation, testing use only.\n"); - radv_get_driver_uuid(&device->device_uuid); + radv_get_driver_uuid(&device->driver_uuid); radv_get_device_uuid(&device->rad_info, &device->device_uuid); if (device->rad_info.family == CHIP_STONEY || -- 2.19.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT
Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/main/get.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index ee77c45d03c1..efc9c11f79d3 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -906,6 +906,9 @@ find_custom_value(struct gl_context *ctx, const struct value_desc *d, union valu break; /* GL_EXT_external_objects */ + case GL_NUM_DEVICE_UUIDS_EXT: + v->value_int = 1; + break; case GL_DRIVER_UUID_EXT: _mesa_get_driver_uuid(ctx, v->value_int_4); break; -- 2.19.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: fix alpha-to-coverage if color writes are disabled
If alpha-to-coverage is enabled, we have to compute alpha even if color writes are disabled. Signed-off-by: Józef Kucia --- Found while running The Witness under Wine. --- src/gallium/drivers/radeonsi/si_state_shaders.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c b/src/gallium/drivers/radeonsi/si_state_shaders.c index 9143f61fcdf2..eaf72e8ee684 100644 --- a/src/gallium/drivers/radeonsi/si_state_shaders.c +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c @@ -1173,6 +1173,8 @@ static void si_shader_selector_key_hw_vs(struct si_context *sctx, ps->info.writes_stencil || ps->info.writes_samplemask || si_get_alpha_test_func(sctx) != PIPE_FUNC_ALWAYS; + const struct si_state_blend *blend = sctx->queued.named.blend; + bool alpha_to_coverage = blend && blend->alpha_to_coverage; unsigned ps_colormask = sctx->framebuffer.colorbuf_enabled_4bit & sctx->queued.named.blend->cb_target_mask; @@ -1182,7 +1184,8 @@ static void si_shader_selector_key_hw_vs(struct si_context *sctx, ps_disabled = sctx->queued.named.rasterizer->rasterizer_discard || (!ps_colormask && !ps_modifies_zs && - !ps->info.writes_memory); + !ps->info.writes_memory && + !alpha_to_coverage); } /* Find out which VS outputs aren't used by the PS. */ -- 2.15.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/17] anv: Rework state tracking to better separate
On Sat, Dec 16, 2017 at 2:08 AM, Jason Ekstrand wrote: > This series is intended to address a bug filed in September: > > https://bugs.freedesktop.org/show_bug.cgi?id=102897 FWIW, I tested the series. It fixes the original issue, and I didn't notice any regressions: Tested-by: Józef Kucia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: set no-signed-zeros-fp-math
On Wed, Jan 10, 2018 at 10:31 PM, Samuel Pitoiset wrote: > + LLVMAddTargetDependentFunctionAttr(main_function, > + "no-signed-zeros-fp-math", > + "true"); > + Is this option safe to enable for Vulkan? The Vulkan spec in the "Precision and Operation of SPIR-V Instructions" section says: "Positive and negative infinities and positive and negative zeros are generated as dictated by IEEE 754, but subject to the precisions allowed in the following table." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv: Fix descriptors copying
Trivial.
Cc: mesa-sta...@lists.freedesktop.org
---
I do not have commit access.
---
src/intel/vulkan/anv_descriptor_set.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_descriptor_set.c
b/src/intel/vulkan/anv_descriptor_set.c
index 91387c065e..8407798230 100644
--- a/src/intel/vulkan/anv_descriptor_set.c
+++ b/src/intel/vulkan/anv_descriptor_set.c
@@ -764,7 +764,7 @@ void anv_UpdateDescriptorSets(
for (uint32_t i = 0; i < descriptorCopyCount; i++) {
const VkCopyDescriptorSet *copy = &pDescriptorCopies[i];
- ANV_FROM_HANDLE(anv_descriptor_set, src, copy->dstSet);
+ ANV_FROM_HANDLE(anv_descriptor_set, src, copy->srcSet);
ANV_FROM_HANDLE(anv_descriptor_set, dst, copy->dstSet);
const struct anv_descriptor_set_binding_layout *src_layout =
--
2.13.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] anv: Fix descriptors copying
On Wed, Sep 20, 2017 at 12:55 PM, Juan A. Suarez Romero wrote: > On Sat, 2017-09-16 at 08:56 -0700, Jason Ekstrand wrote: >> Oh, and >> >> Reviewed-by: Jason Ekstrand >> >> > > Józef, are you pushing this patch? It is not in master yet, and it > would be great to include it in the next stable releases. > I do not have commit access. Please push the patch for me. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] anv: Fix vkCmdFillBuffer()
The vkCmdFillBuffer() command fills a buffer with an uint32_t value.
---
src/intel/vulkan/anv_blorp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 8d0c275248..a8ebdb384c 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -533,8 +533,8 @@ isl_format_for_size(unsigned size_B)
switch (size_B) {
case 1: return ISL_FORMAT_R8_UINT;
case 2: return ISL_FORMAT_R8G8_UINT;
- case 4: return ISL_FORMAT_R8G8B8A8_UINT;
- case 8: return ISL_FORMAT_R16G16B16A16_UINT;
+ case 4: return ISL_FORMAT_R32_UINT;
+ case 8: return ISL_FORMAT_R32G32_UINT;
case 16: return ISL_FORMAT_R32G32B32A32_UINT;
default:
unreachable("Not a power-of-two format size");
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] anv: Remove unreachable cases from isl_format_for_size()
The dstOffset and fillSize parameters must be multiple of 4.
---
src/intel/vulkan/anv_blorp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index a8ebdb384c..8dead1d87a 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -531,8 +531,6 @@ static enum isl_format
isl_format_for_size(unsigned size_B)
{
switch (size_B) {
- case 1: return ISL_FORMAT_R8_UINT;
- case 2: return ISL_FORMAT_R8G8_UINT;
case 4: return ISL_FORMAT_R32_UINT;
case 8: return ISL_FORMAT_R32G32_UINT;
case 16: return ISL_FORMAT_R32G32B32A32_UINT;
--
2.13.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] anv: Fix vkCmdFillBuffer()
On Mon, Oct 2, 2017 at 9:19 PM, Lionel Landwerlin
wrote:
> I guess it makes things clearer.
> Does this fix something?
Yes, it fixes buffer fills. After the change buffers are filled with
uint32_t values instead of uint8_t or uint16_t values.
Before the change, when the fill value is 0xabcdef buffers are filled
with 0xcdefcdef or 0xefefefef.
>
>
> On 02/10/17 18:58, Józef Kucia wrote:
>>
>> The vkCmdFillBuffer() command fills a buffer with an uint32_t value.
>> ---
>> src/intel/vulkan/anv_blorp.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
>> index 8d0c275248..a8ebdb384c 100644
>> --- a/src/intel/vulkan/anv_blorp.c
>> +++ b/src/intel/vulkan/anv_blorp.c
>> @@ -533,8 +533,8 @@ isl_format_for_size(unsigned size_B)
>> switch (size_B) {
>> case 1: return ISL_FORMAT_R8_UINT;
>> case 2: return ISL_FORMAT_R8G8_UINT;
>> - case 4: return ISL_FORMAT_R8G8B8A8_UINT;
>> - case 8: return ISL_FORMAT_R16G16B16A16_UINT;
>> + case 4: return ISL_FORMAT_R32_UINT;
>> + case 8: return ISL_FORMAT_R32G32_UINT;
>> case 16: return ISL_FORMAT_R32G32B32A32_UINT;
>> default:
>> unreachable("Not a power-of-two format size");
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] spirv: Fix SpvOpAtomicISub
Cc: mesa-sta...@lists.freedesktop.org --- src/compiler/spirv/spirv_to_nir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/compiler/spirv/spirv_to_nir.c b/src/compiler/spirv/spirv_to_nir.c index 8fe379e4e0..079ff0fe95 100644 --- a/src/compiler/spirv/spirv_to_nir.c +++ b/src/compiler/spirv/spirv_to_nir.c @@ -2034,6 +2034,7 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode, case SpvOpAtomicIDecrement: case SpvOpAtomicExchange: case SpvOpAtomicIAdd: + case SpvOpAtomicISub: case SpvOpAtomicSMin: case SpvOpAtomicUMin: case SpvOpAtomicSMax: -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv: Do not assert() on VK_ATTACHMENT_UNUSED
--- src/intel/vulkan/genX_cmd_buffer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 93d360a1bb..43437c8eb0 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -2996,10 +2996,11 @@ cmd_buffer_subpass_sync_fast_clear_values(struct anv_cmd_buffer *cmd_buffer) * render pass and used in the subpass. */ const uint32_t a = state->subpass->color_attachments[i].attachment; - assert(a < state->pass->attachment_count); if (a == VK_ATTACHMENT_UNUSED) continue; + assert(a < state->pass->attachment_count); + /* Store some information regarding this attachment. */ const struct anv_attachment_state *att_state = &state->attachments[a]; const struct anv_image_view *iview = state->framebuffer->attachments[a]; -- 2.13.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] st/mesa: Add both front and back buffers for double-buffer visuals
On Wed, Jan 18, 2017 at 2:25 AM, Boyan Ding wrote: > I don't think I find that. The only place in state tracker where > _mesa_add_renderbuffer is called is st_framebuffer_create and only one > of the front and back buffers is allocated based on the default > behavior. When update_framebuffer_state() in state tracker is called > after draw buffer changes to front, state tracker will find it refers > to a null renderbuffer and remove it afterwards. Buffers are allocated on demand in st_DrawBuffers() and st_ReadBuffer(). The issue is though a bit different. A single GL context is used with two windows (drawables). glDrawBuffer/glDrawBuffers() is called when the first window is current, then after glXMakeCurrent() with the second window a new st_framebuffer is created but GL_FRONT renderbuffer is never allocated for the newly created st_framebuffer. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: advertise 8 bits of subpixel precision for viewports
On Wed, Apr 11, 2018 at 10:38 AM, Samuel Pitoiset wrote: > Agreed. > > Reviewed-by: Samuel Pitoiset Please push the patch for me. I don't have commit access. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix calculation of layers array length for isl_view
On Fri, Sep 7, 2018 at 4:42 PM Danylo Piliaiev wrote: > @@ -1546,8 +1548,8 @@ update_image_surface(struct brw_context *brw, > .format = format, > .base_level = obj->MinLevel + u->Level, > .levels = 1, > -.base_array_layer = obj->MinLayer + u->_Layer, > -.array_len = num_layers, > +.base_array_layer = base_layer, > +.array_len = num_layers - base_layer, > .swizzle = ISL_SWIZZLE_IDENTITY, > .usage = ISL_SURF_USAGE_STORAGE_BIT, > }; This sets the "array_len" to the number of layers remaining in the original texture. Shouldn't it take into account the number of layers in the GL texture view? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Fix calculation of layers array length for isl_view
On Fri, Sep 7, 2018 at 6:44 PM Ilia Mirkin wrote: > > On Fri, Sep 7, 2018 at 12:35 PM, Józef Kucia wrote: > > On Fri, Sep 7, 2018 at 4:42 PM Danylo Piliaiev > > wrote: > > > >> @@ -1546,8 +1548,8 @@ update_image_surface(struct brw_context *brw, > >> .format = format, > >> .base_level = obj->MinLevel + u->Level, > >> .levels = 1, > >> -.base_array_layer = obj->MinLayer + u->_Layer, > >> -.array_len = num_layers, > >> +.base_array_layer = base_layer, > >> +.array_len = num_layers - base_layer, > >> .swizzle = ISL_SWIZZLE_IDENTITY, > >> .usage = ISL_SURF_USAGE_STORAGE_BIT, > >> }; > > > > This sets the "array_len" to the number of layers remaining in the > > original texture. Shouldn't it take into account the number of layers > > in the GL texture view? > > Errr, right. Here is the logic in st/mesa, which I believe is correct. > (But convoluted. Because there are so many bits to it.) > > https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_atom_image.c#n101 There is also view_num_layers in brw_update_texture_surface(). It could be adapted. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeonsi: avoid sending GS_EMIT in shaders without outputs
Fixes GPU hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107857
Signed-off-by: Józef Kucia
---
src/gallium/drivers/radeonsi/si_shader.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 36f58e2ce52c..fedc616ebf61 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -4326,9 +4326,12 @@ static void si_llvm_emit_vertex(struct ac_shader_abi
*abi,
gs_next_vertex = LLVMBuildAdd(ctx->ac.builder, gs_next_vertex,
ctx->i32_1, "");
LLVMBuildStore(ctx->ac.builder, gs_next_vertex,
ctx->gs_next_vertex[stream]);
- /* Signal vertex emission */
- ac_build_sendmsg(&ctx->ac, AC_SENDMSG_GS_OP_EMIT | AC_SENDMSG_GS |
(stream << 8),
-si_get_gs_wave_id(ctx));
+ /* Signal vertex emission if vertex data was written. */
+ if (offset) {
+ ac_build_sendmsg(&ctx->ac, AC_SENDMSG_GS_OP_EMIT |
AC_SENDMSG_GS | (stream << 8),
+si_get_gs_wave_id(ctx));
+ }
+
if (!use_kill)
lp_build_endif(&if_state);
}
--
2.16.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir/alu_to_scalar: Use ssa_for_alu_src in hand-rolled expansions
On Wed, Oct 3, 2018 at 9:17 PM Jason Ekstrand wrote: > > The ssa_for_alu_src helper will correctly handle swizzles and other > source modifiers for you. The expansions for unpack_half_2x16, > pack_uvec2_to_uint, and pack_uvec4_to_uint were all broken with regards > to swizzles. The brokenness of unpack_half_2x16 was causing rendering > errors in Rise of the Tomb Raider on Intel ever since c11833ab24dcba26 > which added an extra copy propagation to the optimization pipeline and > caused us to start seeing swizzles where we hadn't seen any before. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107926 > Fixes: 9ce901058f3d "nir: Add lowering of nir_op_unpack_half_2x16." > Fixes: 9b8786eba955 "nir: Add lowering support for packing opcodes." > Cc: Alex Smith > Cc: Matt Turner > --- > src/compiler/nir/nir_lower_alu_to_scalar.c | 33 -- > 1 file changed, 18 insertions(+), 15 deletions(-) Fixes a regression I've noticed in one of our D3D12 to Vulkan translation samples. Thanks! Tested-by: Józef Kucia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix resetting the pool for timestamp queries
On Thu, Oct 4, 2018 at 10:42 AM Samuel Pitoiset wrote: > > Since the driver no longer uses the availability bit for > timestamp queries it shouldn't reset it. Instead, it should > reset the query values to UINT32_MAX. This fixes VM faults. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108164 > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_query.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) Thanks! Tested-by: Józef Kucia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: Fix assert in print_intrinsic_instr().
Signed-off-by: Józef Kucia
---
src/compiler/nir/nir_print.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index e20c28fec874..9ecb2a7c54e6 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -721,7 +721,7 @@ print_intrinsic_instr(nir_intrinsic_instr *instr,
print_state *state)
[GLSL_SAMPLER_DIM_SUBPASS_MS] = "Subpass-MSAA",
};
enum glsl_sampler_dim dim = nir_intrinsic_image_dim(instr);
- assert(dim < ARRAY_SIZE(dim_name) && dim_name[idx]);
+ assert(dim < ARRAY_SIZE(dim_name) && dim_name[dim]);
fprintf(fp, " image_dim=%s", dim_name[dim]);
} else if (idx == NIR_INTRINSIC_IMAGE_ARRAY) {
bool array = nir_intrinsic_image_dim(instr);
--
2.18.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: flush pipeline before query result copies
On Thu, Nov 29, 2018 at 4:43 PM Lionel Landwerlin wrote: > > Pipeline barriers inserted through vkCmdPipelineBarrier() should be > taken into account when copying results. > > In the particular bug below, the results of the > vkCmdCopyQueryPoolResults() command was being overwritten by the > preceding vkCmdCopyBuffer() with a same destination buffer. This is > because we copy the buffers using the 3D pipeline whereas we copy the > query results using the command streamer. Those work in parallel > unless synchronized. > > Signed-off-by: Lionel Landwerlin > Suggested-by: Jason Ekstrand > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108894 Thanks for the fix. For what it's worth, we have more test failures on Anv. A lot failures are related to clearing multisample array textures. See failures in test_clear_render_target_view(), if you are interested. Thanks, Józef ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: Fix assert in print_intrinsic_instr().
On Mon, Nov 26, 2018 at 4:23 PM Lionel Landwerlin wrote: > > On 26/11/2018 15:04, Józef Kucia wrote: > > Signed-off-by: Józef Kucia > > > Reviewed-by: Lionel Landwerlin > > Please push the patch for me. I don't have commit access. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: flush pipeline before query result copies
On Thu, Nov 29, 2018 at 5:25 PM Lionel Landwerlin wrote: > Pretty easy. > > Fetch http://source.winehq.org/git/vkd3d.git > > Usual autotool compilation. > > make tests/d3d12 > > I commented the tests I wasn't interested in for to make it easier and using > vktrace to understand what's going on. Yeah, it's easy. You just need a relatively recent version of widl in the path, SPIR-V and Vulkan headers. Widl is usually installed together with Wine. You can also build widl from wine.git (make tools/widl), and pass WIDL=/path/to/widl to configure. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radv: remove one invalid case in radv_tex_dim()
On Wed, Feb 21, 2018 at 3:27 PM, Samuel Pitoiset wrote: > According to "Table 1. Image and image view parameter compatibility > requirements", this is invalid. > > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_image.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c > index 5ac0f72589..ae407198ba 100644 > --- a/src/amd/vulkan/radv_image.c > +++ b/src/amd/vulkan/radv_image.c > @@ -337,10 +337,7 @@ static unsigned radv_tex_dim(VkImageType image_type, > VkImageViewType view_type, > else > return nr_layers > 1 ? V_008F1C_SQ_RSRC_IMG_2D_ARRAY > : V_008F1C_SQ_RSRC_IMG_2D; > case VK_IMAGE_TYPE_3D: > - if (view_type == VK_IMAGE_VIEW_TYPE_3D) > - return V_008F1C_SQ_RSRC_IMG_3D; > - else > - return V_008F1C_SQ_RSRC_IMG_2D_ARRAY; > + return V_008F1C_SQ_RSRC_IMG_3D; VK_KHR_maintenance1 allows 2D image views to to be created from 3D images. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: fix possible GPU hangs by zeroing the descriptor set
On Fri, Sep 8, 2017 at 2:43 PM, Samuel Pitoiset
wrote:
> when an application doesn't update the contents of a descriptor
> set object, it contains random values and this might end up with
> GPU VM faults if a shader tries to access that descriptor.
>
> The Vulkan spec doesn't state what a driver should do when
> a descriptor is unset, but zeroing the contents seems to be
> a safe solution.
FWIW, this is invalid usage. The Vulkan spec states: "Descriptors in
each bound descriptor set, specified via vkCmdBindDescriptorSets, must
be
valid if they are statically used by the currently bound VkPipeline
object, specified via
vkCmdBindPipeline".
>
> This fixes a GPU hang with Unity because a pixel shader tries
> to access a descriptor that is unset by the application.
> Though, maybe that descriptor load should have been DCE'd.
>
> Cc: Pierre-Loup A. Griffais
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_descriptor_set.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_descriptor_set.c
> b/src/amd/vulkan/radv_descriptor_set.c
> index 260bfbc12b..6271f9d06e 100644
> --- a/src/amd/vulkan/radv_descriptor_set.c
> +++ b/src/amd/vulkan/radv_descriptor_set.c
> @@ -327,6 +327,12 @@ radv_descriptor_set_create(struct radv_device *device,
> list_add(&set->vram_list, prev);
> } else
> return vk_error(VK_ERROR_OUT_OF_POOL_MEMORY_KHR);
> +
> + /* Initialize the descriptor set to zero in order to avoid GPU
> +* VM faults when an application doesn't update the contents
> of
> +* a descriptor set object.
> +*/
> + memset(set->mapped_ptr, 0, layout->size);
> }
>
> for (unsigned i = 0; i < layout->binding_count; ++i) {
> --
> 2.14.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] radv: advertise 8 bits of subpixel precision for viewports
This is what radeonsi does.
---
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 4fc7392e65e6..35b686ab7f02 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -831,7 +831,7 @@ void radv_GetPhysicalDeviceProperties(
.maxViewports = MAX_VIEWPORTS,
.maxViewportDimensions= { (1 << 14), (1 <<
14) },
.viewportBoundsRange = { INT16_MIN,
INT16_MAX },
- .viewportSubPixelBits = 13, /* We take a
float? */
+ .viewportSubPixelBits = 8,
.minMemoryMapAlignment= 4096, /* A page */
.minTexelBufferOffsetAlignment= 1,
.minUniformBufferOffsetAlignment = 4,
--
2.16.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT
On Tue, Mar 12, 2019 at 4:11 PM Józef Kucia wrote: > src/mesa/main/get.c | 3 +++ > 1 file changed, 3 insertions(+) Ping. The patch fixes glGetIntegerv(GL_NUM_DEVICE_UUIDS_EXT, ...). GL_NUM_DEVICE_UUIDS_EXT is implemented in the same way in find_value_indexed(). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT
On Thu, Mar 21, 2019 at 1:24 PM Tapani Pälli wrote: > Yeah, checked that value matches of find_value_indexed; > > Reviewed-by: Tapani Pälli I don't have commits rights. Please push the patch for me. > Does this affect 'ext_semaphore-api-errors' Piglit test that calls this > in any way? No. Before the patch numDevices is 0 and 1 is invalid index anyway. glGetUnsignedBytei_vEXT(GL_DEVICE_UUID_EXT, numDevices + 1, data); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: clear vertex bindings while resetting command buffer
Only vertex inputs accessed by vertex shader must have valid buffers
bound.
Signed-off-by: Józef Kucia
---
src/amd/vulkan/radv_cmd_buffer.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index b04c998fac2e..890662841d21 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -301,7 +301,6 @@ radv_cmd_buffer_destroy(struct radv_cmd_buffer *cmd_buffer)
static VkResult
radv_reset_cmd_buffer(struct radv_cmd_buffer *cmd_buffer)
{
-
cmd_buffer->device->ws->cs_reset(cmd_buffer->cs);
list_for_each_entry_safe(struct radv_cmd_buffer_upload, up,
@@ -326,6 +325,8 @@ radv_reset_cmd_buffer(struct radv_cmd_buffer *cmd_buffer)
cmd_buffer->record_result = VK_SUCCESS;
+ memset(cmd_buffer->vertex_bindings, 0,
sizeof(cmd_buffer->vertex_bindings));
+
for (unsigned i = 0; i < VK_PIPELINE_BIND_POINT_RANGE_SIZE; i++) {
cmd_buffer->descriptors[i].dirty = 0;
cmd_buffer->descriptors[i].valid = 0;
--
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: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()
On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez wrote: > > According to the Vulkan spec, uniform blocks are not allowed to be > updated through vkCmdPushDescriptorSetKHR(). > > There are these spec quotes from "13.2.1. Descriptor Set Layout" > that are relevant for this case: > > "VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies > that descriptor sets must not be allocated using this layout, and > descriptors are instead pushed by vkCmdPushDescriptorSetKHR." > > "If flags contains > VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all > elements of pBindings must not have a descriptorType of > VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT". > > There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid > this case but it is implied in the creation of the descriptor set > layout as aforementioned. > > Signed-off-by: Samuel Iglesias Gonsálvez > --- > > My only doubt is I did well in the case of > radv_meta_push_descriptor_set(), let me know if you prefer to change > it to false. > Perhaps I'm missing something, but what is the point to add the additional checks for invalid usage? A correct program must not use inline uniform blocks with push descriptors. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()
On Tue, Jun 11, 2019 at 12:19 PM Samuel Iglesias Gonsálvez wrote: > Right, it should be detected by the Validation Layers. However it is > arguable what to do in the driver's side. We can just keep it as it is > now, ignore inline uniform block updates (this patch) or even add an > assert if it affects stability of the HW (it is not the case here, we > tested it). I think ignoring the updates it's the best option, but I am > OK with what RADV developers prefer to do. IMHO the code should be left as it is. An assert could be a good addition, but an additional bool parameter only for handling invalid usage doesn't seem right. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
