[Mesa-dev] [Bug 111019] radv doesn't handle variable descriptor count properly
https://bugs.freedesktop.org/show_bug.cgi?id=111019 Bas Nieuwenhuizen changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Bas Nieuwenhuizen --- Fixed in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1484 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] softpipe: Don't draw when rasterizer_discard is set
Am Montag, den 29.07.2019, 11:39 -0400 schrieb Ilia Mirkin: > Hi Gert, > > I just saw you pushed commit > > https://cgit.freedesktop.org/mesa/mesa/commit/?id=4ee638cd7826e8a4bed76f51c7b73395a2fcdb > > which just returns if rasterizer_discard is set, similar to if the > render condition doesn't match. However this breaks TF and any > image/etc writes in vertex stages when GL_RASTERIZER_DISCARD is > enabled, no? Yeah, you're right, I was too focused on the CTS and didn't test the piglits, it breaks a number of TF tests. -> I'll revert this commit, Best, Gert ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111019] radv doesn't handle variable descriptor count properly
https://bugs.freedesktop.org/show_bug.cgi?id=111019 --- Comment #4 from Józef Kucia --- It seems that layout->buffer_count is incorrectly used for VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT_EXT. layout->buffer_count is based on the upper limit taken from descriptor set layout. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] softpipe: Don't draw when rasterizer_discard is set
Hi Gert, I just saw you pushed commit https://cgit.freedesktop.org/mesa/mesa/commit/?id=4ee638cd7826e8a4bed76f51c7b73395a2fcdb which just returns if rasterizer_discard is set, similar to if the render condition doesn't match. However this breaks TF and any image/etc writes in vertex stages when GL_RASTERIZER_DISCARD is enabled, no? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111019] radv doesn't handle variable descriptor count properly
https://bugs.freedesktop.org/show_bug.cgi?id=111019 Józef Kucia changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111019] radv doesn't handle variable descriptor count properly
https://bugs.freedesktop.org/show_bug.cgi?id=111019 --- Comment #3 from Józef Kucia --- Created attachment 144908 --> https://bugs.freedesktop.org/attachment.cgi?id=144908=edit Minimal reproducer 2 With the fix it works for samplers now. Unfortunately, it still doesn't work for other descriptor types. I'm attaching a slightly modified program to reproduce the bug. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 107767] Segfault with standalone compiler and --dump-builder
https://bugs.freedesktop.org/show_bug.cgi?id=107767 Sergii Romantsov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Sergii Romantsov --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/201 -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv/gfx10: do not use the fast depth or stencil clear bytes path
r-b
On Mon, Jul 29, 2019 at 2:35 PM Samuel Pitoiset
wrote:
>
>
> On 7/29/19 2:30 PM, Bas Nieuwenhuizen wrote:
> > On Mon, Jul 29, 2019 at 2:20 PM Samuel Pitoiset
> > wrote:
> >>
> >> On 7/29/19 2:15 PM, Bas Nieuwenhuizen wrote:
> >>> On Mon, Jul 29, 2019 at 2:11 PM Samuel Pitoiset
> >>> wrote:
> The HTILE masks seem to be different and so we need to rework that
> path. Just disabled for now and implement later.
> >>> The HTILE masks are not different per amdvlk?
> >>>
> >>> Can you at least rework the commit message to reflect that?
> >> "It needs to be reworked on GFX10, so just disable it for now." ?
> > How about just "It causes issues on GFX10"? We don't know it needs to
> > be reworked either?
> Looks like it needs but whatever, I'm fine with that, so Rb?
> >
> >
> This fixes rendering issues with vkmark and Wreckfest at least.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_clear.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_clear.c
> b/src/amd/vulkan/radv_meta_clear.c
> index b93ba3e0b29..8ddc2e38cd4 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1005,7 +1005,7 @@ radv_can_fast_clear_depth(struct radv_cmd_buffer
> *cmd_buffer,
> if (!view_mask && clear_rect->layerCount !=
> iview->image->info.array_size)
> return false;
>
> - if (cmd_buffer->device->physical_device->rad_info.chip_class <
> GFX9 &&
> + if (cmd_buffer->device->physical_device->rad_info.chip_class !=
> GFX9 &&
> (!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT) ||
> ((vk_format_aspects(iview->image->vk_format) &
> VK_IMAGE_ASPECT_STENCIL_BIT) &&
> !(aspects & VK_IMAGE_ASPECT_STENCIL_BIT
> @@ -1048,7 +1048,8 @@ radv_fast_clear_depth(struct radv_cmd_buffer
> *cmd_buffer,
>
> iview->image->planes[0].surface.htile_size, clear_word);
> } else {
> /* Only clear depth or stencil bytes in the HTILE
> buffer. */
> -
> assert(cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9);
> + /* TODO: Implement that path for GFX10. */
> +
> assert(cmd_buffer->device->physical_device->rad_info.chip_class == GFX9);
> flush_bits = clear_htile_mask(cmd_buffer,
> iview->image->bo,
> iview->image->offset +
> iview->image->htile_offset,
>
> iview->image->planes[0].surface.htile_size, clear_word,
> --
> 2.22.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/gfx10: do not use the fast depth or stencil clear bytes path
On 7/29/19 2:30 PM, Bas Nieuwenhuizen wrote:
On Mon, Jul 29, 2019 at 2:20 PM Samuel Pitoiset
wrote:
On 7/29/19 2:15 PM, Bas Nieuwenhuizen wrote:
On Mon, Jul 29, 2019 at 2:11 PM Samuel Pitoiset
wrote:
The HTILE masks seem to be different and so we need to rework that
path. Just disabled for now and implement later.
The HTILE masks are not different per amdvlk?
Can you at least rework the commit message to reflect that?
"It needs to be reworked on GFX10, so just disable it for now." ?
How about just "It causes issues on GFX10"? We don't know it needs to
be reworked either?
Looks like it needs but whatever, I'm fine with that, so Rb?
This fixes rendering issues with vkmark and Wreckfest at least.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_clear.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index b93ba3e0b29..8ddc2e38cd4 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1005,7 +1005,7 @@ radv_can_fast_clear_depth(struct radv_cmd_buffer
*cmd_buffer,
if (!view_mask && clear_rect->layerCount !=
iview->image->info.array_size)
return false;
- if (cmd_buffer->device->physical_device->rad_info.chip_class < GFX9 &&
+ if (cmd_buffer->device->physical_device->rad_info.chip_class != GFX9 &&
(!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT) ||
((vk_format_aspects(iview->image->vk_format) &
VK_IMAGE_ASPECT_STENCIL_BIT) &&
!(aspects & VK_IMAGE_ASPECT_STENCIL_BIT
@@ -1048,7 +1048,8 @@ radv_fast_clear_depth(struct radv_cmd_buffer *cmd_buffer,
iview->image->planes[0].surface.htile_size, clear_word);
} else {
/* Only clear depth or stencil bytes in the HTILE buffer. */
- assert(cmd_buffer->device->physical_device->rad_info.chip_class
>= GFX9);
+ /* TODO: Implement that path for GFX10. */
+ assert(cmd_buffer->device->physical_device->rad_info.chip_class
== GFX9);
flush_bits = clear_htile_mask(cmd_buffer, iview->image->bo,
iview->image->offset +
iview->image->htile_offset,
iview->image->planes[0].surface.htile_size, clear_word,
--
2.22.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/gfx10: do not use the fast depth or stencil clear bytes path
On Mon, Jul 29, 2019 at 2:20 PM Samuel Pitoiset
wrote:
>
>
> On 7/29/19 2:15 PM, Bas Nieuwenhuizen wrote:
> > On Mon, Jul 29, 2019 at 2:11 PM Samuel Pitoiset
> > wrote:
> >> The HTILE masks seem to be different and so we need to rework that
> >> path. Just disabled for now and implement later.
> > The HTILE masks are not different per amdvlk?
> >
> > Can you at least rework the commit message to reflect that?
> "It needs to be reworked on GFX10, so just disable it for now." ?
How about just "It causes issues on GFX10"? We don't know it needs to
be reworked either?
> >> This fixes rendering issues with vkmark and Wreckfest at least.
> >>
> >> Signed-off-by: Samuel Pitoiset
> >> ---
> >> src/amd/vulkan/radv_meta_clear.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/amd/vulkan/radv_meta_clear.c
> >> b/src/amd/vulkan/radv_meta_clear.c
> >> index b93ba3e0b29..8ddc2e38cd4 100644
> >> --- a/src/amd/vulkan/radv_meta_clear.c
> >> +++ b/src/amd/vulkan/radv_meta_clear.c
> >> @@ -1005,7 +1005,7 @@ radv_can_fast_clear_depth(struct radv_cmd_buffer
> >> *cmd_buffer,
> >> if (!view_mask && clear_rect->layerCount !=
> >> iview->image->info.array_size)
> >> return false;
> >>
> >> - if (cmd_buffer->device->physical_device->rad_info.chip_class <
> >> GFX9 &&
> >> + if (cmd_buffer->device->physical_device->rad_info.chip_class !=
> >> GFX9 &&
> >> (!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT) ||
> >> ((vk_format_aspects(iview->image->vk_format) &
> >> VK_IMAGE_ASPECT_STENCIL_BIT) &&
> >> !(aspects & VK_IMAGE_ASPECT_STENCIL_BIT
> >> @@ -1048,7 +1048,8 @@ radv_fast_clear_depth(struct radv_cmd_buffer
> >> *cmd_buffer,
> >>
> >> iview->image->planes[0].surface.htile_size, clear_word);
> >> } else {
> >> /* Only clear depth or stencil bytes in the HTILE buffer.
> >> */
> >> -
> >> assert(cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9);
> >> + /* TODO: Implement that path for GFX10. */
> >> +
> >> assert(cmd_buffer->device->physical_device->rad_info.chip_class == GFX9);
> >> flush_bits = clear_htile_mask(cmd_buffer,
> >> iview->image->bo,
> >>iview->image->offset +
> >> iview->image->htile_offset,
> >>
> >> iview->image->planes[0].surface.htile_size, clear_word,
> >> --
> >> 2.22.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/gfx10: do not use the fast depth or stencil clear bytes path
On 7/29/19 2:15 PM, Bas Nieuwenhuizen wrote:
On Mon, Jul 29, 2019 at 2:11 PM Samuel Pitoiset
wrote:
The HTILE masks seem to be different and so we need to rework that
path. Just disabled for now and implement later.
The HTILE masks are not different per amdvlk?
Can you at least rework the commit message to reflect that?
"It needs to be reworked on GFX10, so just disable it for now." ?
This fixes rendering issues with vkmark and Wreckfest at least.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_clear.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index b93ba3e0b29..8ddc2e38cd4 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1005,7 +1005,7 @@ radv_can_fast_clear_depth(struct radv_cmd_buffer
*cmd_buffer,
if (!view_mask && clear_rect->layerCount !=
iview->image->info.array_size)
return false;
- if (cmd_buffer->device->physical_device->rad_info.chip_class < GFX9 &&
+ if (cmd_buffer->device->physical_device->rad_info.chip_class != GFX9 &&
(!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT) ||
((vk_format_aspects(iview->image->vk_format) &
VK_IMAGE_ASPECT_STENCIL_BIT) &&
!(aspects & VK_IMAGE_ASPECT_STENCIL_BIT
@@ -1048,7 +1048,8 @@ radv_fast_clear_depth(struct radv_cmd_buffer *cmd_buffer,
iview->image->planes[0].surface.htile_size, clear_word);
} else {
/* Only clear depth or stencil bytes in the HTILE buffer. */
- assert(cmd_buffer->device->physical_device->rad_info.chip_class
>= GFX9);
+ /* TODO: Implement that path for GFX10. */
+ assert(cmd_buffer->device->physical_device->rad_info.chip_class
== GFX9);
flush_bits = clear_htile_mask(cmd_buffer, iview->image->bo,
iview->image->offset +
iview->image->htile_offset,
iview->image->planes[0].surface.htile_size, clear_word,
--
2.22.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/gfx10: do not use the fast depth or stencil clear bytes path
On Mon, Jul 29, 2019 at 2:11 PM Samuel Pitoiset
wrote:
>
> The HTILE masks seem to be different and so we need to rework that
> path. Just disabled for now and implement later.
The HTILE masks are not different per amdvlk?
Can you at least rework the commit message to reflect that?
>
> This fixes rendering issues with vkmark and Wreckfest at least.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_clear.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_clear.c
> b/src/amd/vulkan/radv_meta_clear.c
> index b93ba3e0b29..8ddc2e38cd4 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1005,7 +1005,7 @@ radv_can_fast_clear_depth(struct radv_cmd_buffer
> *cmd_buffer,
> if (!view_mask && clear_rect->layerCount !=
> iview->image->info.array_size)
> return false;
>
> - if (cmd_buffer->device->physical_device->rad_info.chip_class < GFX9 &&
> + if (cmd_buffer->device->physical_device->rad_info.chip_class != GFX9
> &&
> (!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT) ||
> ((vk_format_aspects(iview->image->vk_format) &
> VK_IMAGE_ASPECT_STENCIL_BIT) &&
> !(aspects & VK_IMAGE_ASPECT_STENCIL_BIT
> @@ -1048,7 +1048,8 @@ radv_fast_clear_depth(struct radv_cmd_buffer
> *cmd_buffer,
>
> iview->image->planes[0].surface.htile_size, clear_word);
> } else {
> /* Only clear depth or stencil bytes in the HTILE buffer. */
> -
> assert(cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9);
> + /* TODO: Implement that path for GFX10. */
> +
> assert(cmd_buffer->device->physical_device->rad_info.chip_class == GFX9);
> flush_bits = clear_htile_mask(cmd_buffer, iview->image->bo,
> iview->image->offset +
> iview->image->htile_offset,
>
> iview->image->planes[0].surface.htile_size, clear_word,
> --
> 2.22.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] radv/gfx10: do not use the fast depth or stencil clear bytes path
The HTILE masks seem to be different and so we need to rework that
path. Just disabled for now and implement later.
This fixes rendering issues with vkmark and Wreckfest at least.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_clear.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index b93ba3e0b29..8ddc2e38cd4 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1005,7 +1005,7 @@ radv_can_fast_clear_depth(struct radv_cmd_buffer
*cmd_buffer,
if (!view_mask && clear_rect->layerCount !=
iview->image->info.array_size)
return false;
- if (cmd_buffer->device->physical_device->rad_info.chip_class < GFX9 &&
+ if (cmd_buffer->device->physical_device->rad_info.chip_class != GFX9 &&
(!(aspects & VK_IMAGE_ASPECT_DEPTH_BIT) ||
((vk_format_aspects(iview->image->vk_format) &
VK_IMAGE_ASPECT_STENCIL_BIT) &&
!(aspects & VK_IMAGE_ASPECT_STENCIL_BIT
@@ -1048,7 +1048,8 @@ radv_fast_clear_depth(struct radv_cmd_buffer *cmd_buffer,
iview->image->planes[0].surface.htile_size, clear_word);
} else {
/* Only clear depth or stencil bytes in the HTILE buffer. */
- assert(cmd_buffer->device->physical_device->rad_info.chip_class
>= GFX9);
+ /* TODO: Implement that path for GFX10. */
+ assert(cmd_buffer->device->physical_device->rad_info.chip_class
== GFX9);
flush_bits = clear_htile_mask(cmd_buffer, iview->image->bo,
iview->image->offset +
iview->image->htile_offset,
iview->image->planes[0].surface.htile_size, clear_word,
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: implement VK_EXT_index_type_uint8
r-b
On Mon, Jul 29, 2019 at 10:47 AM Samuel Pitoiset
wrote:
>
> Natively supported on VI+.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 60 +++
> src/amd/vulkan/radv_device.c | 6
> src/amd/vulkan/radv_extensions.py | 1 +
> 3 files changed, 61 insertions(+), 6 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index d9783e6ca8a..e0ea47b5745 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2541,6 +2541,21 @@ struct radv_draw_info {
> uint64_t strmout_buffer_offset;
> };
>
> +static uint32_t
> +radv_get_primitive_reset_index(struct radv_cmd_buffer *cmd_buffer)
> +{
> + switch (cmd_buffer->state.index_type) {
> + case V_028A7C_VGT_INDEX_8:
> + return 0xffu;
> + case V_028A7C_VGT_INDEX_16:
> + return 0xu;
> + case V_028A7C_VGT_INDEX_32:
> + return 0xu;
> + default:
> + unreachable("invalid index type");
> + }
> +}
> +
> static void
> si_emit_ia_multi_vgt_param(struct radv_cmd_buffer *cmd_buffer,
>bool instanced_draw, bool indirect_draw,
> @@ -2612,7 +2627,7 @@ radv_emit_draw_registers(struct radv_cmd_buffer
> *cmd_buffer,
>
> if (primitive_reset_en) {
> uint32_t primitive_reset_index =
> - state->index_type ? 0xu : 0xu;
> + radv_get_primitive_reset_index(cmd_buffer);
>
> if (primitive_reset_index !=
> state->last_primitive_reset_index) {
> radeon_set_context_reg(cs,
> @@ -3233,6 +3248,36 @@ void radv_CmdBindVertexBuffers(
> cmd_buffer->state.dirty |= RADV_CMD_DIRTY_VERTEX_BUFFER;
> }
>
> +static uint32_t
> +vk_to_index_type(VkIndexType type)
> +{
> + switch (type) {
> + case VK_INDEX_TYPE_UINT8_EXT:
> + return V_028A7C_VGT_INDEX_8;
> + case VK_INDEX_TYPE_UINT16:
> + return V_028A7C_VGT_INDEX_16;
> + case VK_INDEX_TYPE_UINT32:
> + return V_028A7C_VGT_INDEX_32;
> + default:
> + unreachable("invalid index type");
> + }
> +}
> +
> +static uint32_t
> +radv_get_vgt_index_size(uint32_t type)
> +{
> + switch (type) {
> + case V_028A7C_VGT_INDEX_8:
> + return 1;
> + case V_028A7C_VGT_INDEX_16:
> + return 2;
> + case V_028A7C_VGT_INDEX_32:
> + return 4;
> + default:
> + unreachable("invalid index type");
> + }
> +}
> +
> void radv_CmdBindIndexBuffer(
> VkCommandBuffer commandBuffer,
> VkBuffer buffer,
> @@ -3251,12 +3296,12 @@ void radv_CmdBindIndexBuffer(
>
> cmd_buffer->state.index_buffer = index_buffer;
> cmd_buffer->state.index_offset = offset;
> - cmd_buffer->state.index_type = indexType; /* vk matches hw */
> + cmd_buffer->state.index_type = vk_to_index_type(indexType);
> cmd_buffer->state.index_va = radv_buffer_get_va(index_buffer->bo);
> cmd_buffer->state.index_va += index_buffer->offset + offset;
>
> - int index_size_shift = cmd_buffer->state.index_type ? 2 : 1;
> - cmd_buffer->state.max_index_count = (index_buffer->size - offset) >>
> index_size_shift;
> + int index_size = radv_get_vgt_index_size(indexType);
> + cmd_buffer->state.max_index_count = (index_buffer->size - offset) /
> index_size;
> cmd_buffer->state.dirty |= RADV_CMD_DIRTY_INDEX_BUFFER;
> radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs,
> index_buffer->bo);
> }
> @@ -4275,7 +4320,7 @@ radv_emit_draw_packets(struct radv_cmd_buffer
> *cmd_buffer,
> }
>
> if (info->indexed) {
> - int index_size = state->index_type ? 4 : 2;
> + int index_size =
> radv_get_vgt_index_size(state->index_type);
> uint64_t index_va;
>
> index_va = state->index_va;
> @@ -4354,8 +4399,11 @@ static bool radv_need_late_scissor_emission(struct
> radv_cmd_buffer *cmd_buffer,
> if (cmd_buffer->state.dirty & used_states)
> return true;
>
> + uint32_t primitive_reset_index =
> + radv_get_primitive_reset_index(cmd_buffer);
> +
> if (info->indexed && state->pipeline->graphics.prim_restart_enable &&
> - (state->index_type ? 0xu : 0xu) !=
> state->last_primitive_reset_index)
> + primitive_reset_index != state->last_primitive_reset_index)
> return true;
>
> return false;
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 9ba100df6e8..65e3ccf91ad 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -987,6 +987,12 @@ void
Re: [Mesa-dev] [PATCH] ac: do not crash when the buffer data format is invalid
r-b
On Mon, Jul 29, 2019 at 12:00 PM Samuel Pitoiset
wrote:
>
> This might happen when a pipeline doesn't define the vertex input
> state, so the buffer data format is 0 (aka INVALID).
>
> This fixes crashes when compiling some shaders on GFX10.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_llvm_build.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 250bfc5229e..278f8893432 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -1508,6 +1508,7 @@ ac_get_tbuffer_format(struct ac_llvm_context *ctx,
> unsigned format;
> switch (dfmt) {
> default: unreachable("bad dfmt");
> + case V_008F0C_BUF_DATA_FORMAT_INVALID: format =
> V_008F0C_IMG_FORMAT_INVALID; break;
> case V_008F0C_BUF_DATA_FORMAT_8: format =
> V_008F0C_IMG_FORMAT_8_UINT; break;
> case V_008F0C_BUF_DATA_FORMAT_8_8: format =
> V_008F0C_IMG_FORMAT_8_8_UINT; break;
> case V_008F0C_BUF_DATA_FORMAT_8_8_8_8: format =
> V_008F0C_IMG_FORMAT_8_8_8_8_UINT; break;
> --
> 2.22.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: do not crash when the buffer data format is invalid
This might happen when a pipeline doesn't define the vertex input
state, so the buffer data format is 0 (aka INVALID).
This fixes crashes when compiling some shaders on GFX10.
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 250bfc5229e..278f8893432 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1508,6 +1508,7 @@ ac_get_tbuffer_format(struct ac_llvm_context *ctx,
unsigned format;
switch (dfmt) {
default: unreachable("bad dfmt");
+ case V_008F0C_BUF_DATA_FORMAT_INVALID: format =
V_008F0C_IMG_FORMAT_INVALID; break;
case V_008F0C_BUF_DATA_FORMAT_8: format =
V_008F0C_IMG_FORMAT_8_UINT; break;
case V_008F0C_BUF_DATA_FORMAT_8_8: format =
V_008F0C_IMG_FORMAT_8_8_UINT; break;
case V_008F0C_BUF_DATA_FORMAT_8_8_8_8: format =
V_008F0C_IMG_FORMAT_8_8_8_8_UINT; break;
--
2.22.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: implement VK_EXT_index_type_uint8
Natively supported on VI+.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 60 +++
src/amd/vulkan/radv_device.c | 6
src/amd/vulkan/radv_extensions.py | 1 +
3 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index d9783e6ca8a..e0ea47b5745 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2541,6 +2541,21 @@ struct radv_draw_info {
uint64_t strmout_buffer_offset;
};
+static uint32_t
+radv_get_primitive_reset_index(struct radv_cmd_buffer *cmd_buffer)
+{
+ switch (cmd_buffer->state.index_type) {
+ case V_028A7C_VGT_INDEX_8:
+ return 0xffu;
+ case V_028A7C_VGT_INDEX_16:
+ return 0xu;
+ case V_028A7C_VGT_INDEX_32:
+ return 0xu;
+ default:
+ unreachable("invalid index type");
+ }
+}
+
static void
si_emit_ia_multi_vgt_param(struct radv_cmd_buffer *cmd_buffer,
bool instanced_draw, bool indirect_draw,
@@ -2612,7 +2627,7 @@ radv_emit_draw_registers(struct radv_cmd_buffer
*cmd_buffer,
if (primitive_reset_en) {
uint32_t primitive_reset_index =
- state->index_type ? 0xu : 0xu;
+ radv_get_primitive_reset_index(cmd_buffer);
if (primitive_reset_index != state->last_primitive_reset_index)
{
radeon_set_context_reg(cs,
@@ -3233,6 +3248,36 @@ void radv_CmdBindVertexBuffers(
cmd_buffer->state.dirty |= RADV_CMD_DIRTY_VERTEX_BUFFER;
}
+static uint32_t
+vk_to_index_type(VkIndexType type)
+{
+ switch (type) {
+ case VK_INDEX_TYPE_UINT8_EXT:
+ return V_028A7C_VGT_INDEX_8;
+ case VK_INDEX_TYPE_UINT16:
+ return V_028A7C_VGT_INDEX_16;
+ case VK_INDEX_TYPE_UINT32:
+ return V_028A7C_VGT_INDEX_32;
+ default:
+ unreachable("invalid index type");
+ }
+}
+
+static uint32_t
+radv_get_vgt_index_size(uint32_t type)
+{
+ switch (type) {
+ case V_028A7C_VGT_INDEX_8:
+ return 1;
+ case V_028A7C_VGT_INDEX_16:
+ return 2;
+ case V_028A7C_VGT_INDEX_32:
+ return 4;
+ default:
+ unreachable("invalid index type");
+ }
+}
+
void radv_CmdBindIndexBuffer(
VkCommandBuffer commandBuffer,
VkBuffer buffer,
@@ -3251,12 +3296,12 @@ void radv_CmdBindIndexBuffer(
cmd_buffer->state.index_buffer = index_buffer;
cmd_buffer->state.index_offset = offset;
- cmd_buffer->state.index_type = indexType; /* vk matches hw */
+ cmd_buffer->state.index_type = vk_to_index_type(indexType);
cmd_buffer->state.index_va = radv_buffer_get_va(index_buffer->bo);
cmd_buffer->state.index_va += index_buffer->offset + offset;
- int index_size_shift = cmd_buffer->state.index_type ? 2 : 1;
- cmd_buffer->state.max_index_count = (index_buffer->size - offset) >>
index_size_shift;
+ int index_size = radv_get_vgt_index_size(indexType);
+ cmd_buffer->state.max_index_count = (index_buffer->size - offset) /
index_size;
cmd_buffer->state.dirty |= RADV_CMD_DIRTY_INDEX_BUFFER;
radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs,
index_buffer->bo);
}
@@ -4275,7 +4320,7 @@ radv_emit_draw_packets(struct radv_cmd_buffer *cmd_buffer,
}
if (info->indexed) {
- int index_size = state->index_type ? 4 : 2;
+ int index_size =
radv_get_vgt_index_size(state->index_type);
uint64_t index_va;
index_va = state->index_va;
@@ -4354,8 +4399,11 @@ static bool radv_need_late_scissor_emission(struct
radv_cmd_buffer *cmd_buffer,
if (cmd_buffer->state.dirty & used_states)
return true;
+ uint32_t primitive_reset_index =
+ radv_get_primitive_reset_index(cmd_buffer);
+
if (info->indexed && state->pipeline->graphics.prim_restart_enable &&
- (state->index_type ? 0xu : 0xu) !=
state->last_primitive_reset_index)
+ primitive_reset_index != state->last_primitive_reset_index)
return true;
return false;
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 9ba100df6e8..65e3ccf91ad 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -987,6 +987,12 @@ void radv_GetPhysicalDeviceFeatures2(
features->uniformBufferStandardLayout = true;
break;
}
+ case
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INDEX_TYPE_UINT8_FEATURES_EXT: {
+ VkPhysicalDeviceIndexTypeUint8FeaturesEXT *features =
+
