[Mesa-dev] [PATCH] st/glsl: make sure to propagate initialisers to driver storage
This essentially reverts 20234cfe3a20.
Fixes piglit test:
tests/spec/arb_get_program_binary/execution/uniform-after-restore.shader_test
Fixes: 20234cfe3a20 "st/mesa: don't propagate uniforms when restoring from
cache"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110784
---
src/mesa/program/ir_to_mesa.cpp| 41 ++
src/mesa/program/ir_to_mesa.h | 3 +-
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
src/mesa/state_tracker/st_shader_cache.c | 2 +-
5 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp
index f875c00238f..005b855230b 100644
--- a/src/mesa/program/ir_to_mesa.cpp
+++ b/src/mesa/program/ir_to_mesa.cpp
@@ -2506,8 +2506,7 @@ _mesa_generate_parameters_list_for_uniforms(struct
gl_context *ctx,
void
_mesa_associate_uniform_storage(struct gl_context *ctx,
struct gl_shader_program *shader_program,
-struct gl_program *prog,
-bool propagate_to_storage)
+struct gl_program *prog)
{
struct gl_program_parameter_list *params = prog->Parameters;
gl_shader_stage shader_type = prog->info.stage;
@@ -2633,26 +2632,24 @@ _mesa_associate_uniform_storage(struct gl_context *ctx,
* data from the linker's backing store. This will cause values from
* initializers in the source code to be copied over.
*/
- if (propagate_to_storage) {
-unsigned array_elements = MAX2(1, storage->array_elements);
-if (ctx->Const.PackedDriverUniformStorage && !prog->is_arb_asm &&
-(storage->is_bindless || !storage->type->contains_opaque())) {
- const int dmul = storage->type->is_64bit() ? 2 : 1;
- const unsigned components =
- storage->type->vector_elements *
- storage->type->matrix_columns;
-
- for (unsigned s = 0; s < storage->num_driver_storage; s++) {
- gl_constant_value *uni_storage = (gl_constant_value *)
- storage->driver_storage[s].data;
- memcpy(uni_storage, storage->storage,
- sizeof(storage->storage[0]) * components *
- array_elements * dmul);
- }
-} else {
- _mesa_propagate_uniforms_to_driver_storage(storage, 0,
- array_elements);
+ unsigned array_elements = MAX2(1, storage->array_elements);
+ if (ctx->Const.PackedDriverUniformStorage && !prog->is_arb_asm &&
+ (storage->is_bindless || !storage->type->contains_opaque())) {
+const int dmul = storage->type->is_64bit() ? 2 : 1;
+const unsigned components =
+ storage->type->vector_elements *
+ storage->type->matrix_columns;
+
+for (unsigned s = 0; s < storage->num_driver_storage; s++) {
+ gl_constant_value *uni_storage = (gl_constant_value *)
+ storage->driver_storage[s].data;
+ memcpy(uni_storage, storage->storage,
+ sizeof(storage->storage[0]) * components *
+ array_elements * dmul);
}
+ } else {
+_mesa_propagate_uniforms_to_driver_storage(storage, 0,
+ array_elements);
}
last_location = location;
@@ -3011,7 +3008,7 @@ get_mesa_program(struct gl_context *ctx,
* prog->ParameterValues to get reallocated (e.g., anything that adds a
* program constant) has to happen before creating this linkage.
*/
- _mesa_associate_uniform_storage(ctx, shader_program, prog, true);
+ _mesa_associate_uniform_storage(ctx, shader_program, prog);
if (!shader_program->data->LinkStatus) {
goto fail_exit;
}
diff --git a/src/mesa/program/ir_to_mesa.h b/src/mesa/program/ir_to_mesa.h
index f5665e6316e..33eb801bae8 100644
--- a/src/mesa/program/ir_to_mesa.h
+++ b/src/mesa/program/ir_to_mesa.h
@@ -50,8 +50,7 @@ _mesa_generate_parameters_list_for_uniforms(struct gl_context
*ctx,
void
_mesa_associate_uniform_storage(struct gl_context *ctx,
struct gl_shader_program *shader_program,
-struct gl_program *prog,
-bool propagate_to_storage);
+struct gl_program *prog);
#ifdef __cplusplus
}
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 11fc03baf86..b40cb9223df 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -524,7 +524,7 @@ st_glsl_to_nir_post_opts(struct st_context *st, struct
[Mesa-dev] [Bug 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely
https://bugs.freedesktop.org/show_bug.cgi?id=110697 QwertyChouskie changed: What|Removed |Added Keywords||regression --- Comment #6 from QwertyChouskie --- (In reply to acc12345acc from comment #5) > Apparently this bug was introduced in Mesa 19.0. (there also is a > possibility of this not being a Mesa bug) I'm adding the regression keyword then. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/7] radv: decompress HTILE if the resolve src image is compressed
On Mon, May 27, 2019 at 5:38 PM Samuel Pitoiset
wrote:
>
> It's required to decompress HTILE before resolving with the
> compute path.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta_resolve.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_meta_resolve.c
> b/src/amd/vulkan/radv_meta_resolve.c
> index 2d048207b7a..8891a98e4d7 100644
> --- a/src/amd/vulkan/radv_meta_resolve.c
> +++ b/src/amd/vulkan/radv_meta_resolve.c
> @@ -769,6 +769,32 @@ radv_decompress_resolve_subpass_src(struct
> radv_cmd_buffer *cmd_buffer)
> radv_decompress_resolve_src(cmd_buffer, src_image,
> src_att.layout, 1, );
> }
> +
> + if (subpass->ds_resolve_attachment) {
> + struct radv_subpass_attachment src_att =
> *subpass->depth_stencil_attachment;
> + struct radv_image *src_image =
> + fb->attachments[src_att.attachment].attachment->image;
> + uint32_t queue_mask =
> + radv_image_queue_family_mask(src_image,
> +
> cmd_buffer->queue_family_index,
> +
> cmd_buffer->queue_family_index);
> +
> + VkImageSubresourceRange range;
> + range.aspectMask = VK_IMAGE_ASPECT_DEPTH_BIT;
> + range.baseMipLevel = 0;
> + range.levelCount = 1;
> + range.baseArrayLayer = 0;
> + range.layerCount = src_image->info.array_size;
Shouldn't we take this from the image view + layers in the framebuffer?
> +
> + if (radv_layout_is_htile_compressed(src_image, src_att.layout,
> + queue_mask)) {
> + radv_decompress_depth_image_inplace(cmd_buffer,
> src_image,
> + );
> +
> + cmd_buffer->state.flush_bits |=
> RADV_CMD_FLAG_FLUSH_AND_INV_DB |
> +
> RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
> + }
Can't we do a proper layout transition? That should deal automatically
with tc compatible HTILE, and avoid open-coding this.
> + }
> }
>
> /**
> --
> 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 1/7] radv: record if a render pass has depth/stencil resolve attachments
That seems OK.
On Tue, May 28, 2019 at 8:25 AM Samuel Pitoiset
wrote:
>
>
> On 5/27/19 6:48 PM, Bas Nieuwenhuizen wrote:
> > On Mon, May 27, 2019 at 5:38 PM Samuel Pitoiset
> > wrote:
> >> Only supported with vkCreateRenderPass2().
> >>
> >> Signed-off-by: Samuel Pitoiset
> >> ---
> >> src/amd/vulkan/radv_pass.c| 30 +-
> >> src/amd/vulkan/radv_private.h | 3 +++
> >> 2 files changed, 32 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/amd/vulkan/radv_pass.c b/src/amd/vulkan/radv_pass.c
> >> index 4d1e38a780e..b21bf37e401 100644
> >> --- a/src/amd/vulkan/radv_pass.c
> >> +++ b/src/amd/vulkan/radv_pass.c
> >> @@ -75,6 +75,10 @@ radv_render_pass_compile(struct radv_render_pass *pass)
> >> subpass->depth_stencil_attachment->attachment ==
> >> VK_ATTACHMENT_UNUSED)
> >> subpass->depth_stencil_attachment = NULL;
> >>
> >> + if (subpass->ds_resolve_attachment &&
> >> + subpass->ds_resolve_attachment->attachment ==
> >> VK_ATTACHMENT_UNUSED)
> >> + subpass->ds_resolve_attachment = NULL;
> >> +
> >> for (uint32_t j = 0; j < subpass->attachment_count; j++) {
> >> struct radv_subpass_attachment *subpass_att =
> >> >attachments[j];
> >> @@ -126,6 +130,9 @@ radv_render_pass_compile(struct radv_render_pass *pass)
> >> subpass->has_resolve = true;
> >> }
> >> }
> >> +
> >> + if (subpass->ds_resolve_attachment)
> >> + subpass->has_resolve = true;
> > I think this makes the code assume that there are also color resolves
> > to be done, which might not be the case?
> Right, how about renaming has_resolve to has_color_resolves, remove this
> if statement and update the checks in radv_cmd_buffer_resolve_subpass() ?
> >
> >> }
> >> }
> >>
> >> @@ -291,10 +298,15 @@ VkResult radv_CreateRenderPass(
> >> static unsigned
> >> radv_num_subpass_attachments2(const VkSubpassDescription2KHR *desc)
> >> {
> >> + const VkSubpassDescriptionDepthStencilResolveKHR *ds_resolve =
> >> + vk_find_struct_const(desc->pNext,
> >> +
> >> SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR);
> >> +
> >> return desc->inputAttachmentCount +
> >> desc->colorAttachmentCount +
> >> (desc->pResolveAttachments ? desc->colorAttachmentCount :
> >> 0) +
> >> - (desc->pDepthStencilAttachment != NULL);
> >> + (desc->pDepthStencilAttachment != NULL) +
> >> + (ds_resolve && ds_resolve->pDepthStencilResolveAttachment);
> >> }
> >>
> >> VkResult radv_CreateRenderPass2KHR(
> >> @@ -411,6 +423,22 @@ VkResult radv_CreateRenderPass2KHR(
> >> .layout =
> >> desc->pDepthStencilAttachment->layout,
> >> };
> >> }
> >> +
> >> + const VkSubpassDescriptionDepthStencilResolveKHR
> >> *ds_resolve =
> >> + vk_find_struct_const(desc->pNext,
> >> +
> >> SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR);
> >> +
> >> + if (ds_resolve &&
> >> ds_resolve->pDepthStencilResolveAttachment) {
> >> + subpass->ds_resolve_attachment = p++;
> >> +
> >> + *subpass->ds_resolve_attachment = (struct
> >> radv_subpass_attachment) {
> >> + .attachment =
> >> ds_resolve->pDepthStencilResolveAttachment->attachment,
> >> + .layout =
> >> ds_resolve->pDepthStencilResolveAttachment->layout,
> >> + };
> >> +
> >> + subpass->depth_resolve_mode =
> >> ds_resolve->depthResolveMode;
> >> + subpass->stencil_resolve_mode =
> >> ds_resolve->stencilResolveMode;
> >> + }
> >> }
> >>
> >> for (unsigned i = 0; i < pCreateInfo->dependencyCount; ++i) {
> >> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> >> index 7834a505562..e826740bc9f 100644
> >> --- a/src/amd/vulkan/radv_private.h
> >> +++ b/src/amd/vulkan/radv_private.h
> >> @@ -1882,6 +1882,9 @@ struct radv_subpass {
> >> struct radv_subpass_attachment * color_attachments;
> >> struct radv_subpass_attachment * resolve_attachments;
> >> struct radv_subpass_attachment *
> >> depth_stencil_attachment;
> >> + struct radv_subpass_attachment * ds_resolve_attachment;
> >> + VkResolveModeFlagBitsKHR depth_resolve_mode;
> >> + VkResolveModeFlagBitsKHR stencil_resolve_mode;
> >>
> >> /** Subpass has at least one resolve attachment */
> >>
Re: [Mesa-dev] [PATCH] radv: sync before resetting a pool if there is active pending queries
r-b
On Tue, May 28, 2019 at 11:05 AM Samuel Pitoiset
wrote:
>
> Make sure to sync all previous work if the given command buffer
> has pending active queries. Otherwise the GPU might write queries
> data after the reset operation.
>
> This fixes a bunch of new dEQP-VK.query_pool.* CTS failures.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 6 ++
> src/amd/vulkan/radv_private.h| 5 +
> src/amd/vulkan/radv_query.c | 11 +++
> src/amd/vulkan/si_cmd_buffer.c | 5 +
> 4 files changed, 27 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 43730f0568c..3c7d3de69e8 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2950,6 +2950,12 @@ VkResult radv_EndCommandBuffer(
> if (cmd_buffer->queue_family_index != RADV_QUEUE_TRANSFER) {
> if (cmd_buffer->device->physical_device->rad_info.chip_class
> == GFX6)
> cmd_buffer->state.flush_bits |=
> RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH |
> RADV_CMD_FLAG_WRITEBACK_GLOBAL_L2;
> +
> + /* Make sure to sync all pending active queries at the end of
> +* command buffer.
> +*/
> + cmd_buffer->state.flush_bits |=
> cmd_buffer->active_query_flush_bits;
> +
> si_emit_cache_flush(cmd_buffer);
> }
>
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index 7834a505562..08b2621685d 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -1142,6 +1142,11 @@ struct radv_cmd_buffer {
> * Whether a query pool has been resetted and we have to flush caches.
> */
> bool pending_reset_query;
> +
> + /**
> +* Bitmask of pending active query flushes.
> +*/
> + enum radv_cmd_flush_bits active_query_flush_bits;
> };
>
> struct radv_image;
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 014f5cede6a..ff9ceceb3ed 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1444,6 +1444,12 @@ void radv_CmdResetQueryPool(
> ? TIMESTAMP_NOT_READY : 0;
> uint32_t flush_bits = 0;
>
> + /* Make sure to sync all previous work if the given command buffer has
> +* pending active queries. Otherwise the GPU might write queries data
> +* after the reset operation.
> +*/
> + cmd_buffer->state.flush_bits |= cmd_buffer->active_query_flush_bits;
> +
> flush_bits |= radv_fill_buffer(cmd_buffer, pool->bo,
>firstQuery * pool->stride,
>queryCount * pool->stride, value);
> @@ -1624,6 +1630,11 @@ static void emit_end_query(struct radv_cmd_buffer
> *cmd_buffer,
> default:
> unreachable("ending unhandled query type");
> }
> +
> + cmd_buffer->active_query_flush_bits |= RADV_CMD_FLAG_PS_PARTIAL_FLUSH
> |
> + RADV_CMD_FLAG_CS_PARTIAL_FLUSH
> |
> + RADV_CMD_FLAG_INV_GLOBAL_L2 |
> + RADV_CMD_FLAG_INV_VMEM_L1;
> }
>
> void radv_CmdBeginQueryIndexedEXT(
> diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
> index c73c6ecd65c..aae8d578c10 100644
> --- a/src/amd/vulkan/si_cmd_buffer.c
> +++ b/src/amd/vulkan/si_cmd_buffer.c
> @@ -989,6 +989,11 @@ si_emit_cache_flush(struct radv_cmd_buffer *cmd_buffer)
> if (unlikely(cmd_buffer->device->trace_bo))
> radv_cmd_buffer_trace_emit(cmd_buffer);
>
> + /* Clear the caches that have been flushed to avoid syncing too much
> +* when there is some pending active queries.
> +*/
> + cmd_buffer->active_query_flush_bits &= ~cmd_buffer->state.flush_bits;
> +
> cmd_buffer->state.flush_bits = 0;
>
> /* If the driver used a compute shader for resetting a query pool, it
> --
> 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 1/2] radv: always use view format when performing subpass resolves
Don't you also need to change it in the pipeline selection? (e.g. your
newly added radv_get_resolve_pipeline())
Otherwise r-b for the eries.
On Tue, May 28, 2019 at 11:02 AM Samuel Pitoiset
wrote:
>
> It makes sense to use the image view formats when resolving
> inside subpasses, while we have to use the image formats for
> normal resolves.
>
> Original patch by Philip Rebohle.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110348
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_meta.h| 2 ++
> src/amd/vulkan/radv_meta_resolve.c| 9 ++---
> src/amd/vulkan/radv_meta_resolve_cs.c | 8 ++--
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index 0bd75d6c207..4a7c37be9b3 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -183,8 +183,10 @@ void radv_expand_fmask_image_inplace(struct
> radv_cmd_buffer *cmd_buffer,
>
> void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
> struct radv_image *src_image,
> +VkFormat src_format,
> VkImageLayout src_image_layout,
> struct radv_image *dest_image,
> +VkFormat dest_format,
> VkImageLayout dest_image_layout,
> uint32_t region_count,
> const VkImageResolve *regions);
> diff --git a/src/amd/vulkan/radv_meta_resolve.c
> b/src/amd/vulkan/radv_meta_resolve.c
> index 1544513a9bc..b4551a98637 100644
> --- a/src/amd/vulkan/radv_meta_resolve.c
> +++ b/src/amd/vulkan/radv_meta_resolve.c
> @@ -439,8 +439,10 @@ void radv_CmdResolveImage(
> if (resolve_method == RESOLVE_COMPUTE) {
> radv_meta_resolve_compute_image(cmd_buffer,
> src_image,
> + src_image->vk_format,
> src_image_layout,
> dest_image,
> + dest_image->vk_format,
> dest_image_layout,
> region_count, regions);
> return;
> @@ -658,7 +660,8 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
> *cmd_buffer)
> if (dest_att.attachment == VK_ATTACHMENT_UNUSED)
> continue;
>
> - struct radv_image *dst_img =
> cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment->image;
> + struct radv_image_view *dest_iview =
> cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment;
> + struct radv_image *dst_img = dest_iview->image;
>
> if (radv_image_has_dcc(dst_img)) {
> radv_initialize_dcc(cmd_buffer, dst_img, 0x);
> @@ -673,14 +676,14 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
> *cmd_buffer)
>
> radv_cmd_buffer_set_subpass(cmd_buffer, _subpass);
>
> - VkResult ret = build_resolve_pipeline(cmd_buffer->device,
> radv_format_meta_fs_key(dst_img->vk_format));
> + VkResult ret = build_resolve_pipeline(cmd_buffer->device,
> radv_format_meta_fs_key(dest_iview->vk_format));
> if (ret != VK_SUCCESS) {
> cmd_buffer->record_result = ret;
> continue;
> }
>
> emit_resolve(cmd_buffer,
> -dst_img->vk_format,
> +dest_iview->vk_format,
> &(VkOffset2D) { 0, 0 },
> &(VkExtent2D) { fb->width, fb->height });
> }
> diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
> b/src/amd/vulkan/radv_meta_resolve_cs.c
> index 67df4800023..506e4139e93 100644
> --- a/src/amd/vulkan/radv_meta_resolve_cs.c
> +++ b/src/amd/vulkan/radv_meta_resolve_cs.c
> @@ -413,8 +413,10 @@ emit_resolve(struct radv_cmd_buffer *cmd_buffer,
>
> void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
> struct radv_image *src_image,
> +VkFormat src_format,
> VkImageLayout src_image_layout,
> struct radv_image *dest_image,
> +VkFormat dest_format,
> VkImageLayout dest_image_layout,
> uint32_t region_count,
> const VkImageResolve *regions)
> @@ -460,7 +462,7 @@ void radv_meta_resolve_compute_image(struct
>
[Mesa-dev] [MR] Revert "egl: Add a 565 pbuffer-only EGL config under X11."
This reverts commit dacb11a5. The reason for introducing this change was to fulfill CTS's requirement to be able to run a 565-no-depth-no-stencil config for ES 3.0 on X11. Unfortunately, enabling this causes other problems. The most relevant one is that, for i965, CTS was passing for GL 4.5 and now it fails while trying to run the "41" configs that have been activated by this change. While we don't have a proper solution for this "regression", it is better to go back to the previous state. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110357 https://gitlab.freedesktop.org/mesa/mesa/merge_requests/963 -- Br, Andres ___ 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 --- Comment #5 from Andrés Gómez García --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/963 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] etnaviv: implement set_active_query_state(..) for hw queries
Clear w/ quad uses a normal draw which adds up to OQ. st/meta
uses set_active_query_state(..) to tell the driver to pause
queries in such cases.
Fixes spec@arb_occlusion_query@occlusion_query_meta_save piglit.
Signed-off-by: Christian Gmeiner
---
src/gallium/drivers/etnaviv/etnaviv_query.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_query.c
b/src/gallium/drivers/etnaviv/etnaviv_query.c
index b076e87e782..bd75ca90b8a 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_query.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_query.c
@@ -134,8 +134,17 @@ etna_get_driver_query_group_info(struct pipe_screen
*pscreen, unsigned index,
}
static void
-etna_set_active_query_state(struct pipe_context *pipe, boolean enable)
+etna_set_active_query_state(struct pipe_context *pctx, boolean enable)
{
+ struct etna_context *ctx = etna_context(pctx);
+
+ if (enable) {
+ list_for_each_entry(struct etna_hw_query, hq, >active_hw_queries,
node)
+ etna_hw_query_resume(hq, ctx);
+ } else {
+ list_for_each_entry(struct etna_hw_query, hq, >active_hw_queries,
node)
+ etna_hw_query_suspend(hq, ctx);
+ }
}
void
--
2.21.0
___
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 --- Comment #4 from Andrés Gómez García --- (In reply to Eric Engestrom from comment #3) > (In reply to Juan A. Suarez from comment #2) > > This bug is a blocker for 19.1.0. > > Is reverting dacb11a585 enough to fix the issue? > > If so, I'd suggest doing that, and a new attempt can land after however long > it takes. It should be enough. Unfortunately, I've been chasing another rabbit down the whole while testing this for quite a while :( I'll post a MR soon-ish. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #5 from network...@rkmail.ru --- (In reply to Samuel Pitoiset from comment #4) > Make sure to use latest Proton (4.2-5). I'm absolutely sure I already had 4.2-5 when I originally reported 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 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #4 from Samuel Pitoiset --- Make sure to use latest Proton (4.2-5). -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #3 from network...@rkmail.ru --- (In reply to Samuel Pitoiset from comment #2) > Not sure what's your expectation about Radeon VII but on my Vega 56, I get > more than 110FPS in Ultra at 4K. This seems *quite* acceptable to me. Well, on my system it was 35-50 fps at FullHD, everything set to medium, except textures. Textures were set to "ultra". With same config my RX480 did 70+ fps. I'll try to test it more with new mesa git on Friday. -- 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 110760] Low FPS in Quake Champions with Vega20
https://bugs.freedesktop.org/show_bug.cgi?id=110760 --- Comment #2 from Samuel Pitoiset --- Not sure what's your expectation about Radeon VII but on my Vega 56, I get more than 110FPS in Ultra at 4K. This seems *quite* acceptable to me. Btw, the assertion noticed by Tim is fixed with https://gitlab.freedesktop.org/mesa/mesa/commit/47a10edefb3510d1cae071037dac78a46b31949b -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] list: add some iterator debug
On Mon, May 27, 2019 at 5:06 AM Rob Clark wrote: > > On Mon, May 27, 2019 at 4:39 AM Erik Faye-Lund > wrote: > > > > On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote: > > > On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote: > > > > On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund > > > > wrote: > > > > > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote: > > > > > > This ends up embedded in a for loop expression, ie. the C part > > > > > > in > > > > > > an > > > > > > for (A;B;C) > > > > > > > > > > > > iirc, that means it needs to be a C expr rather than > > > > > > statement.. > > > > > > or > > > > > > something roughly like that, I'm too lazy to dig out my C > > > > > > grammar > > > > > > > > > > > > > > > > Can't you just call a static helper function to do the > > > > > validation? > > > > > Function calls are valid expressions... > > > > > > > > I do like the fact that with the current patch I get the correct > > > > line > > > > # in the assert msg.. but perhaps #ifdef MSVC we can make it a > > > > static > > > > inline instead? I'm not sure how many people do active feature dev > > > > of > > > > mesa on windows (as opposed to doing dev on linux and then > > > > compiling/shipping non-debug builds on windows), so maybe just > > > > disabling the list debug on MSVC is fine. > > > > > > > > BR, > > > > -R > > > > I guess I should also have mentioned that I *do* sometimes do feature > > development for Mesa on Windows, so I'd really like to get to benefit > > from debug-helpers. > > > > ok, that was the answer I was looking for, whether it actually > benefits anyone to re-invent assert > I've pushed a MR[1] with a slightly different solution, but I think this should work for MSVC --- #ifdef DEBUG # define list_assert(cond, msg) assert(cond && msg) #else # define list_assert(cond, msg) (void)(0 && (cond)) #endif --- [1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/962 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/13] panfrost/midgard: RA improvements (esp. RA)
Patch Series Reviewed-By: Ryan Houdek On Sat, May 25, 2019 at 7:39 PM Alyssa Rosenzweig wrote: > This fairly-lengthy series is focused on improving the register > allocator and by extension the performance of the generated code. > Meanwhile, we cleanup the compiler, refactoring as we go, driven by the > overall arc of the RA improvements. I was particularly motivated by the > concerns raised by compiling code like: > > vec3 A = B * C; > float d = A.x * A.y; > > to something like > > vmul.fmul r0.xyz, [B], [C] > smul.fmul r1.x, r0.x, r0.y > > There are two clear problems here. One is that the r0.w component is > never used, but r1.x is -- doubling the register pressure from what it > needs to be, given register pressure is measured in vec4 for Midgard. On > many shaders, this affects the need to spill or number of threads > created. So the first half of the series, culminating in "Extend RA..." > would rewrite this code to use r0.w vs r1.x. > > The other is a bit more minor, but there's no need to use r0.x at all! > It turns out that within a VLIW bundle, we can push values directly > across, bypassing the register file, represented by the pseudo- pipeline > registers r24/r25. So by the improvements in the latter half of the > series, culminating in "Implement...", we instead get something like: > > vmul.fmul r24.xyz, [B], [C] > smul.fmul r0.x, r24.x, r24.y > > In addition to various stylistic cleanups, a major consequence of this > series is a unification of pre-schedule and post-schedule MIR. The > immediate effect is that our main work RA can now run post-schedule, > rather than just pre-schedule, without duplicating a whole bunch of > code. This will become particularly important as we want to balance > pipeline register creation with having to implement spilling eventually. > > Alyssa Rosenzweig (13): > panfrost/midgard: Remove pinning > panfrost/midgard: Share some utility functions > panfrost/midgard: Set int outmod for "pasted" code > panfrost/midgard: Fix liveness analysis bugs > panfrost/midgard: Set masks on ld_vary > panfrost/midgard: Extend RA to non-vec4 sources > panfrost/midgard: Misc. cleanup for readibility > panfrost/midgard: Refactor schedule/emit pipeline > panfrost/midgard: Add MIR helpers > panfrost/midgard: Implement "pipeline register" prepass > panfrost/midgard: Cleanup copy propagation > panfrost/midgard: Remove r0 scheduling code > panfrost/midgard: .pos propagation > > src/gallium/drivers/panfrost/meson.build | 4 + > .../drivers/panfrost/midgard/compiler.h | 117 ++- > .../drivers/panfrost/midgard/helpers.h| 73 ++ > .../panfrost/midgard/midgard_compile.c| 937 ++ > .../drivers/panfrost/midgard/midgard_emit.c | 229 + > .../panfrost/midgard/midgard_liveness.c | 10 +- > .../drivers/panfrost/midgard/midgard_ops.h| 21 + > .../drivers/panfrost/midgard/midgard_ra.c | 387 ++-- > .../panfrost/midgard/midgard_ra_pipeline.c| 87 ++ > .../panfrost/midgard/midgard_schedule.c | 425 > src/gallium/drivers/panfrost/midgard/mir.c| 53 + > 11 files changed, 1389 insertions(+), 954 deletions(-) > create mode 100644 src/gallium/drivers/panfrost/midgard/midgard_emit.c > create mode 100644 > src/gallium/drivers/panfrost/midgard/midgard_ra_pipeline.c > create mode 100644 src/gallium/drivers/panfrost/midgard/midgard_schedule.c > create mode 100644 src/gallium/drivers/panfrost/midgard/mir.c > > -- > 2.20.1 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radv: allocate more space in the CS when emitting events
r-b On Tue, May 28, 2019 at 12:54 PM Samuel Pitoiset wrote: > > If the driver waits for CP DMA to be idle and emit an EOP event > we need more space. > > This fixes a crash with Quake Champions. > > Cc: > Signed-off-by: Samuel Pitoiset > --- > src/amd/vulkan/radv_cmd_buffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/amd/vulkan/radv_cmd_buffer.c > b/src/amd/vulkan/radv_cmd_buffer.c > index 43730f0568c..0e9c1894a40 100644 > --- a/src/amd/vulkan/radv_cmd_buffer.c > +++ b/src/amd/vulkan/radv_cmd_buffer.c > @@ -4782,7 +4782,7 @@ static void write_event(struct radv_cmd_buffer > *cmd_buffer, > > radv_cs_add_buffer(cmd_buffer->device->ws, cs, event->bo); > > - MAYBE_UNUSED unsigned cdw_max = > radeon_check_space(cmd_buffer->device->ws, cs, 18); > + MAYBE_UNUSED unsigned cdw_max = > radeon_check_space(cmd_buffer->device->ws, cs, 21); > > /* Flags that only require a top-of-pipe event. */ > VkPipelineStageFlags top_of_pipe_flags = > -- > 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] radv: allocate more space in the CS when emitting events
If the driver waits for CP DMA to be idle and emit an EOP event we need more space. This fixes a crash with Quake Champions. Cc: Signed-off-by: Samuel Pitoiset --- src/amd/vulkan/radv_cmd_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c index 43730f0568c..0e9c1894a40 100644 --- a/src/amd/vulkan/radv_cmd_buffer.c +++ b/src/amd/vulkan/radv_cmd_buffer.c @@ -4782,7 +4782,7 @@ static void write_event(struct radv_cmd_buffer *cmd_buffer, radv_cs_add_buffer(cmd_buffer->device->ws, cs, event->bo); - MAYBE_UNUSED unsigned cdw_max = radeon_check_space(cmd_buffer->device->ws, cs, 18); + MAYBE_UNUSED unsigned cdw_max = radeon_check_space(cmd_buffer->device->ws, cs, 21); /* Flags that only require a top-of-pipe event. */ VkPipelineStageFlags top_of_pipe_flags = -- 2.21.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radv: sync before resetting a pool if there is active pending queries
Make sure to sync all previous work if the given command buffer
has pending active queries. Otherwise the GPU might write queries
data after the reset operation.
This fixes a bunch of new dEQP-VK.query_pool.* CTS failures.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 6 ++
src/amd/vulkan/radv_private.h| 5 +
src/amd/vulkan/radv_query.c | 11 +++
src/amd/vulkan/si_cmd_buffer.c | 5 +
4 files changed, 27 insertions(+)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 43730f0568c..3c7d3de69e8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2950,6 +2950,12 @@ VkResult radv_EndCommandBuffer(
if (cmd_buffer->queue_family_index != RADV_QUEUE_TRANSFER) {
if (cmd_buffer->device->physical_device->rad_info.chip_class ==
GFX6)
cmd_buffer->state.flush_bits |=
RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH |
RADV_CMD_FLAG_WRITEBACK_GLOBAL_L2;
+
+ /* Make sure to sync all pending active queries at the end of
+* command buffer.
+*/
+ cmd_buffer->state.flush_bits |=
cmd_buffer->active_query_flush_bits;
+
si_emit_cache_flush(cmd_buffer);
}
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 7834a505562..08b2621685d 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1142,6 +1142,11 @@ struct radv_cmd_buffer {
* Whether a query pool has been resetted and we have to flush caches.
*/
bool pending_reset_query;
+
+ /**
+* Bitmask of pending active query flushes.
+*/
+ enum radv_cmd_flush_bits active_query_flush_bits;
};
struct radv_image;
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 014f5cede6a..ff9ceceb3ed 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1444,6 +1444,12 @@ void radv_CmdResetQueryPool(
? TIMESTAMP_NOT_READY : 0;
uint32_t flush_bits = 0;
+ /* Make sure to sync all previous work if the given command buffer has
+* pending active queries. Otherwise the GPU might write queries data
+* after the reset operation.
+*/
+ cmd_buffer->state.flush_bits |= cmd_buffer->active_query_flush_bits;
+
flush_bits |= radv_fill_buffer(cmd_buffer, pool->bo,
firstQuery * pool->stride,
queryCount * pool->stride, value);
@@ -1624,6 +1630,11 @@ static void emit_end_query(struct radv_cmd_buffer
*cmd_buffer,
default:
unreachable("ending unhandled query type");
}
+
+ cmd_buffer->active_query_flush_bits |= RADV_CMD_FLAG_PS_PARTIAL_FLUSH |
+ RADV_CMD_FLAG_CS_PARTIAL_FLUSH |
+ RADV_CMD_FLAG_INV_GLOBAL_L2 |
+ RADV_CMD_FLAG_INV_VMEM_L1;
}
void radv_CmdBeginQueryIndexedEXT(
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index c73c6ecd65c..aae8d578c10 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -989,6 +989,11 @@ si_emit_cache_flush(struct radv_cmd_buffer *cmd_buffer)
if (unlikely(cmd_buffer->device->trace_bo))
radv_cmd_buffer_trace_emit(cmd_buffer);
+ /* Clear the caches that have been flushed to avoid syncing too much
+* when there is some pending active queries.
+*/
+ cmd_buffer->active_query_flush_bits &= ~cmd_buffer->state.flush_bits;
+
cmd_buffer->state.flush_bits = 0;
/* If the driver used a compute shader for resetting a query pool, it
--
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: always use view format when performing subpass resolves
It makes sense to use the image view formats when resolving
inside subpasses, while we have to use the image formats for
normal resolves.
Original patch by Philip Rebohle.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110348
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta.h| 2 ++
src/amd/vulkan/radv_meta_resolve.c| 9 ++---
src/amd/vulkan/radv_meta_resolve_cs.c | 8 ++--
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 0bd75d6c207..4a7c37be9b3 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -183,8 +183,10 @@ void radv_expand_fmask_image_inplace(struct
radv_cmd_buffer *cmd_buffer,
void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *src_image,
+VkFormat src_format,
VkImageLayout src_image_layout,
struct radv_image *dest_image,
+VkFormat dest_format,
VkImageLayout dest_image_layout,
uint32_t region_count,
const VkImageResolve *regions);
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index 1544513a9bc..b4551a98637 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -439,8 +439,10 @@ void radv_CmdResolveImage(
if (resolve_method == RESOLVE_COMPUTE) {
radv_meta_resolve_compute_image(cmd_buffer,
src_image,
+ src_image->vk_format,
src_image_layout,
dest_image,
+ dest_image->vk_format,
dest_image_layout,
region_count, regions);
return;
@@ -658,7 +660,8 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
if (dest_att.attachment == VK_ATTACHMENT_UNUSED)
continue;
- struct radv_image *dst_img =
cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment->image;
+ struct radv_image_view *dest_iview =
cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment;
+ struct radv_image *dst_img = dest_iview->image;
if (radv_image_has_dcc(dst_img)) {
radv_initialize_dcc(cmd_buffer, dst_img, 0x);
@@ -673,14 +676,14 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
radv_cmd_buffer_set_subpass(cmd_buffer, _subpass);
- VkResult ret = build_resolve_pipeline(cmd_buffer->device,
radv_format_meta_fs_key(dst_img->vk_format));
+ VkResult ret = build_resolve_pipeline(cmd_buffer->device,
radv_format_meta_fs_key(dest_iview->vk_format));
if (ret != VK_SUCCESS) {
cmd_buffer->record_result = ret;
continue;
}
emit_resolve(cmd_buffer,
-dst_img->vk_format,
+dest_iview->vk_format,
&(VkOffset2D) { 0, 0 },
&(VkExtent2D) { fb->width, fb->height });
}
diff --git a/src/amd/vulkan/radv_meta_resolve_cs.c
b/src/amd/vulkan/radv_meta_resolve_cs.c
index 67df4800023..506e4139e93 100644
--- a/src/amd/vulkan/radv_meta_resolve_cs.c
+++ b/src/amd/vulkan/radv_meta_resolve_cs.c
@@ -413,8 +413,10 @@ emit_resolve(struct radv_cmd_buffer *cmd_buffer,
void radv_meta_resolve_compute_image(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *src_image,
+VkFormat src_format,
VkImageLayout src_image_layout,
struct radv_image *dest_image,
+VkFormat dest_format,
VkImageLayout dest_image_layout,
uint32_t region_count,
const VkImageResolve *regions)
@@ -460,7 +462,7 @@ void radv_meta_resolve_compute_image(struct radv_cmd_buffer
*cmd_buffer,
.sType =
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
.image =
radv_image_to_handle(src_image),
.viewType =
radv_meta_get_view_type(src_image),
-
[Mesa-dev] [PATCH 2/2] radv: use view format when selecting the resolve path for subpasses
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index b4551a98637..2b97c42fc69 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -331,6 +331,7 @@ enum radv_resolve_method {
};
static void radv_pick_resolve_method_images(struct radv_image *src_image,
+ VkFormat src_format,
struct radv_image *dest_image,
VkImageLayout dest_image_layout,
struct radv_cmd_buffer *cmd_buffer,
@@ -341,10 +342,10 @@ static void radv_pick_resolve_method_images(struct
radv_image *src_image,
cmd_buffer->queue_family_index,
cmd_buffer->queue_family_index);
- if (src_image->vk_format == VK_FORMAT_R16G16_UNORM ||
- src_image->vk_format == VK_FORMAT_R16G16_SNORM)
+ if (src_format == VK_FORMAT_R16G16_UNORM ||
+ src_format == VK_FORMAT_R16G16_SNORM)
*method = RESOLVE_COMPUTE;
- else if (vk_format_is_int(src_image->vk_format))
+ else if (vk_format_is_int(src_format))
*method = RESOLVE_COMPUTE;
else if (src_image->info.array_size > 1 ||
dest_image->info.array_size > 1)
@@ -422,9 +423,9 @@ void radv_CmdResolveImage(
} else
resolve_method = RESOLVE_COMPUTE;
- radv_pick_resolve_method_images(src_image, dest_image,
- dest_image_layout, cmd_buffer,
- _method);
+ radv_pick_resolve_method_images(src_image, src_image->vk_format,
+ dest_image, dest_image_layout,
+ cmd_buffer, _method);
if (resolve_method == RESOLVE_FRAGMENT) {
radv_meta_resolve_fragment_image(cmd_buffer,
@@ -634,9 +635,13 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
cmd_buffer->state.attachments[dest_att.attachment].pending_clear_aspects = 0;
struct radv_image *dst_img =
cmd_buffer->state.framebuffer->attachments[dest_att.attachment].attachment->image;
- struct radv_image *src_img =
cmd_buffer->state.framebuffer->attachments[src_att.attachment].attachment->image;
+ struct radv_image_view *src_iview=
cmd_buffer->state.framebuffer->attachments[src_att.attachment].attachment;
+ struct radv_image *src_img = src_iview->image;
+
+ radv_pick_resolve_method_images(src_img, src_iview->vk_format,
+ dst_img, dest_att.layout,
+ cmd_buffer, _method);
- radv_pick_resolve_method_images(src_img, dst_img,
dest_att.layout, cmd_buffer, _method);
if (resolve_method == RESOLVE_FRAGMENT) {
break;
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/uvd: fix poc for hevc encode
It would be better to have those checks in the state tracker than in the
backend code.
Christian.
Am 27.05.19 um 20:41 schrieb boyuan.zh...@amd.com:
From: Boyuan Zhang
MaxPicOrderCntLsb should be at 16 according to the spec,
therefore add minimum value check.
Also use poc value passed from st instead of calculation
in slice header encoding.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_uvd_enc.c | 3 ++-
src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 3 +--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c
b/src/gallium/drivers/radeon/radeon_uvd_enc.c
index 521d08f304..9256e43a08 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
@@ -73,7 +73,8 @@ radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
- enc->enc_pic.max_poc = pic->seq.intra_period;
+ enc->enc_pic.max_poc =
+ (pic->seq.intra_period >= 16) ? pic->seq.intra_period : 16;
enc->enc_pic.log2_max_poc = 0;
for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
i = (i >> 1);
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
index ddb219792a..8f0e0099e7 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
@@ -768,8 +768,7 @@ radeon_uvd_enc_slice_header_hevc(struct radeon_uvd_encoder
*enc)
if ((enc->enc_pic.nal_unit_type != 19)
&& (enc->enc_pic.nal_unit_type != 20)) {
radeon_uvd_enc_code_fixed_bits(enc,
- enc->enc_pic.frame_num %
- enc->enc_pic.max_poc,
+ enc->enc_pic.pic_order_cnt,
enc->enc_pic.log2_max_poc);
if (enc->enc_pic.picture_type == PIPE_H265_ENC_PICTURE_TYPE_P)
radeon_uvd_enc_code_fixed_bits(enc, 0x1, 1);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: fix default cbuf info.
On Tue, 2019-05-28 at 02:08 +0200, Roland Scheidegger wrote:
> Am 27.05.19 um 11:39 schrieb Juan A. Suarez Romero:
> > On Fri, 2019-05-24 at 03:08 +0200, srol...@vmware.com wrote:
> > > From: Roland Scheidegger
> > >
> > > The default null_output really needs to be static, otherwise the values
> > > we'll eventually get later are doubly random (they are not initialized,
> > > and even if they were it's a pointer to a local stack variable).
> > > VMware bug 2349556.
> >
> > Shouldn't this be CC to @stable ?
> I forgot to mention this, but it should not actually be an issue in the
> public branch, since that part of the information gathered there isn't
> actually used by llvmpipe, hence if it contains garbage or not doesn't
> matter. So there isn't really any need for stable.
> But we have a branch where llvmpipe uses it.
>
Thanks for the feedback!
J.A.
> Roland
>
> >
> > > ---
> > > src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > index b4e3c2fbc8..9fc9b8c77e 100644
> > > --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > @@ -608,7 +608,7 @@ finished:
> > > */
> > >
> > > for (index = 0; index < PIPE_MAX_COLOR_BUFS; ++index) {
> > > - const struct lp_tgsi_channel_info null_output[4];
> > > + static const struct lp_tgsi_channel_info null_output[4];
> > >info->cbuf[index] = null_output;
> > > }
> > >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Prevent classic swrast crash on a surfaceless context v2.
Pushed that.
Thanks!
best
Mathias
On Monday, 27 May 2019 17:34:29 CEST Marek Olšák wrote:
> Reviewed-by: Marek Olšák
>
> M.
>
> On Mon, May 27, 2019, 4:17 AM wrote:
>
> > From: Mathias Fröhlich
> >
> > Hi Emil,
> >
> > thanks for that hint to look at _mesa_get_incomplete_framebuffer.
> > That one seems definitely more appropriate!
> >
> > Though, I miss a bit the idea how I can create either a sensible
> > helper function for that task or how I can create something above
> > in the call stack to the MakeCurrent call that already catches
> > this case. Since that incomplete framebuffer is a mesa side thing I
> > cannot easily pull that above the __DriverAPIRec::MakeCurrent call.
> > But really putting those hand full lines of code into a helper does
> > as well not gain much. So I implemented that for the swrast case
> > directly.
> >
> > So, to mention, I sent that change including our egl device code
> > with some unrelated egl device fixes through intels CI and did not
> > get regressions.
> >
> > please review
> >
> > thanks and best
> > Mathias
> >
> >
> >
> >
> >
> > This fixes the egl_mesa_platform_surfaceless piglit test as well
> > as the new device egl extensions piglit test on classic swrast.
> >
> > v2: Fix swrast surfaceless contexts on the driver side.
> >
> > Signed-off-by: Mathias Fröhlich
> > ---
> > src/mesa/drivers/dri/swrast/swrast.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/swrast/swrast.c
> > b/src/mesa/drivers/dri/swrast/swrast.c
> > index 36cf11334cb..4899fb2df95 100644
> > --- a/src/mesa/drivers/dri/swrast/swrast.c
> > +++ b/src/mesa/drivers/dri/swrast/swrast.c
> > @@ -36,6 +36,7 @@
> > #include "main/api_exec.h"
> > #include "main/context.h"
> > #include "main/extensions.h"
> > +#include "main/fbobject.h"
> > #include "main/formats.h"
> > #include "main/framebuffer.h"
> > #include "main/imports.h"
> > @@ -686,7 +687,7 @@ swrast_check_and_update_window_size( struct gl_context
> > *ctx, struct gl_framebuff
> > {
> > GLsizei width, height;
> >
> > -if (!fb)
> > +if (!fb || fb == _mesa_get_incomplete_framebuffer())
> > return;
> >
> > get_window_size(fb, , );
> > @@ -884,6 +885,12 @@ dri_make_current(__DRIcontext * cPriv,
> > mesaDraw = >Base;
> > mesaRead = >Base;
> > }
> > +else {
> > + struct gl_framebuffer *incomplete
> > + = _mesa_get_incomplete_framebuffer();
> > + mesaDraw = incomplete;
> > + mesaRead = incomplete;
> > +}
> >
> > /* check for same context and buffer */
> > if (mesaCtx == _mesa_get_current_context()
> > --
> > 2.21.0
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] radv: record if a render pass has depth/stencil resolve attachments
On 5/27/19 6:48 PM, Bas Nieuwenhuizen wrote:
On Mon, May 27, 2019 at 5:38 PM Samuel Pitoiset
wrote:
Only supported with vkCreateRenderPass2().
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pass.c| 30 +-
src/amd/vulkan/radv_private.h | 3 +++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_pass.c b/src/amd/vulkan/radv_pass.c
index 4d1e38a780e..b21bf37e401 100644
--- a/src/amd/vulkan/radv_pass.c
+++ b/src/amd/vulkan/radv_pass.c
@@ -75,6 +75,10 @@ radv_render_pass_compile(struct radv_render_pass *pass)
subpass->depth_stencil_attachment->attachment ==
VK_ATTACHMENT_UNUSED)
subpass->depth_stencil_attachment = NULL;
+ if (subpass->ds_resolve_attachment &&
+ subpass->ds_resolve_attachment->attachment ==
VK_ATTACHMENT_UNUSED)
+ subpass->ds_resolve_attachment = NULL;
+
for (uint32_t j = 0; j < subpass->attachment_count; j++) {
struct radv_subpass_attachment *subpass_att =
>attachments[j];
@@ -126,6 +130,9 @@ radv_render_pass_compile(struct radv_render_pass *pass)
subpass->has_resolve = true;
}
}
+
+ if (subpass->ds_resolve_attachment)
+ subpass->has_resolve = true;
I think this makes the code assume that there are also color resolves
to be done, which might not be the case?
Right, how about renaming has_resolve to has_color_resolves, remove this
if statement and update the checks in radv_cmd_buffer_resolve_subpass() ?
}
}
@@ -291,10 +298,15 @@ VkResult radv_CreateRenderPass(
static unsigned
radv_num_subpass_attachments2(const VkSubpassDescription2KHR *desc)
{
+ const VkSubpassDescriptionDepthStencilResolveKHR *ds_resolve =
+ vk_find_struct_const(desc->pNext,
+
SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR);
+
return desc->inputAttachmentCount +
desc->colorAttachmentCount +
(desc->pResolveAttachments ? desc->colorAttachmentCount : 0) +
- (desc->pDepthStencilAttachment != NULL);
+ (desc->pDepthStencilAttachment != NULL) +
+ (ds_resolve && ds_resolve->pDepthStencilResolveAttachment);
}
VkResult radv_CreateRenderPass2KHR(
@@ -411,6 +423,22 @@ VkResult radv_CreateRenderPass2KHR(
.layout =
desc->pDepthStencilAttachment->layout,
};
}
+
+ const VkSubpassDescriptionDepthStencilResolveKHR *ds_resolve =
+ vk_find_struct_const(desc->pNext,
+
SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR);
+
+ if (ds_resolve && ds_resolve->pDepthStencilResolveAttachment) {
+ subpass->ds_resolve_attachment = p++;
+
+ *subpass->ds_resolve_attachment = (struct
radv_subpass_attachment) {
+ .attachment =
ds_resolve->pDepthStencilResolveAttachment->attachment,
+ .layout =
ds_resolve->pDepthStencilResolveAttachment->layout,
+ };
+
+ subpass->depth_resolve_mode =
ds_resolve->depthResolveMode;
+ subpass->stencil_resolve_mode =
ds_resolve->stencilResolveMode;
+ }
}
for (unsigned i = 0; i < pCreateInfo->dependencyCount; ++i) {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 7834a505562..e826740bc9f 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1882,6 +1882,9 @@ struct radv_subpass {
struct radv_subpass_attachment * color_attachments;
struct radv_subpass_attachment * resolve_attachments;
struct radv_subpass_attachment * depth_stencil_attachment;
+ struct radv_subpass_attachment * ds_resolve_attachment;
+ VkResolveModeFlagBitsKHR depth_resolve_mode;
+ VkResolveModeFlagBitsKHR stencil_resolve_mode;
/** Subpass has at least one resolve attachment */
bool has_resolve;
--
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] panfrost: Don't flip scanout
On 5/26/19 1:51 AM, Alyssa Rosenzweig wrote:
The mesa/st flips the viewport, so we respect that rather than
trying to flip the framebuffer itself and ignoring the viewport and
using a messy heuristic.
However, this brings an underlying disagreement about the interpretation
of winding order to light. The blob uses a different strategy than Mesa
for handling viewport Y flipping, so the meanings of the winding order
bit are flipped for it. To keep things clean on our end, we rename to
explicitly use Gallium (rather than flipped OpenGL) conventions.
Fixes upside-down Xwayland/egl windows.
Suggested-by: Rob Clark
Signed-off-by: Alyssa Rosenzweig
Cc: Tomeu Vizoso
This is a great cleanup, thanks!
Reviewed-by: Tomeu Vizoso
Cheers,
Tomeu
---
.../drivers/panfrost/include/panfrost-job.h | 8 +--
src/gallium/drivers/panfrost/pan_context.c| 54 +++
src/gallium/drivers/panfrost/pan_context.h| 7 +--
src/gallium/drivers/panfrost/pan_fragment.c | 7 +--
src/gallium/drivers/panfrost/pan_mfbd.c | 16 ++
src/gallium/drivers/panfrost/pan_sfbd.c | 17 ++
.../drivers/panfrost/pandecode/decode.c | 12 ++---
7 files changed, 40 insertions(+), 81 deletions(-)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index f4f145890de..8a4a7644070 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -73,9 +73,11 @@ enum mali_draw_mode {
#define MALI_OCCLUSION_QUERY(1 << 3)
#define MALI_OCCLUSION_PRECISE (1 << 4)
-#define MALI_FRONT_FACE(v) (v << 5)
-#define MALI_CCW (0)
-#define MALI_CW (1)
+/* Set for a glFrontFace(GL_CCW) in a Y=0=TOP coordinate system (like Gallium).
+ * In OpenGL, this would corresponds to glFrontFace(GL_CW). Mesa and the blob
+ * disagree about how to do viewport flipping, so the blob actually sets this
+ * for GL_CW but then has a negative viewport stride */
+#define MALI_FRONT_CCW_TOP (1 << 5)
#define MALI_CULL_FACE_FRONT(1 << 6)
#define MALI_CULL_FACE_BACK (1 << 7)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 5cae386f070..d0170a63def 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1143,15 +1143,6 @@ panfrost_emit_for_draw(struct panfrost_context *ctx,
bool with_vertex_data)
const struct pipe_viewport_state *vp = >pipe_viewport;
-/* For flipped-Y buffers (signaled by negative scale), the translate is
- * flipped as well */
-
-bool invert_y = vp->scale[1] < 0.0;
-float translate_y = vp->translate[1];
-
-if (invert_y)
-translate_y = ctx->pipe_framebuffer.height - translate_y;
-
for (int i = 0; i <= PIPE_SHADER_FRAGMENT; ++i) {
struct panfrost_constant_buffer *buf =
>constant_buffer[i];
@@ -1171,11 +1162,11 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool with_vertex_data)
if (sysval == PAN_SYSVAL_VIEWPORT_SCALE) {
uniforms[4*i + 0] = vp->scale[0];
-uniforms[4*i + 1] = fabsf(vp->scale[1]);
+uniforms[4*i + 1] = vp->scale[1];
uniforms[4*i + 2] = vp->scale[2];
} else if (sysval == PAN_SYSVAL_VIEWPORT_OFFSET) {
uniforms[4*i + 0] = vp->translate[0];
-uniforms[4*i + 1] = translate_y;
+uniforms[4*i + 1] = vp->translate[1];
uniforms[4*i + 2] = vp->translate[2];
} else {
assert(0);
@@ -1245,24 +1236,28 @@ panfrost_emit_for_draw(struct panfrost_context *ctx,
bool with_vertex_data)
view.viewport0[0] = (int) (vp->translate[0] - vp->scale[0]);
view.viewport1[0] = MALI_POSITIVE((int) (vp->translate[0] +
vp->scale[0]));
-view.viewport0[1] = (int) (translate_y - fabs(vp->scale[1]));
-view.viewport1[1] = MALI_POSITIVE((int) (translate_y +
fabs(vp->scale[1])));
+int miny = (int) (vp->translate[1] - vp->scale[1]);
+int maxy = (int) (vp->translate[1] + vp->scale[1]);
if (ss && ctx->rasterizer && ctx->rasterizer->base.scissor) {
-/* Invert scissor if needed */
-unsigned miny = invert_y ?
-ctx->pipe_framebuffer.height - ss->maxy : ss->miny;
-
-unsigned maxy = invert_y ?
-ctx->pipe_framebuffer.height - ss->miny : ss->maxy;
-
-/* Set the actual scissor */
view.viewport0[0] = ss->minx;
-view.viewport0[1] = miny;
view.viewport1[0] =
