[Mesa-dev] [PATCH] anv: fix bug when using component qualifier in FS outputs
Jason Ekstrand
jason at jlekstrand.net
Wed Nov 8 16:19:46 UTC 2017
On Thu, Nov 2, 2017 at 12:28 AM, Samuel Iglesias Gonsálvez <
siglesias at igalia.com> wrote:
> We can write to the same output but in different components, like
> in this example:
>
> layout(location = 0, component = 0) out ivec2 dEQP_FragColor_0;
> layout(location = 0, component = 2) out ivec2 dEQP_FragColor_1;
>
> Therefore, they are not two different outputs but only one.
>
> Fixes:
>
> dEQP-VK.glsl.440.linkage.varying.component.frag_out.*
>
> Signed-off-by: Samuel Iglesias Gonsálvez <siglesias at igalia.com>
> ---
> src/compiler/shader_enums.h | 1 +
> src/intel/vulkan/anv_pipeline.c | 10 +++++++++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
> index 9d229d4199e..90729dbfd96 100644
> --- a/src/compiler/shader_enums.h
> +++ b/src/compiler/shader_enums.h
> @@ -603,6 +603,7 @@ typedef enum
> FRAG_RESULT_DATA5,
> FRAG_RESULT_DATA6,
> FRAG_RESULT_DATA7,
> + FRAG_RESULT_MAX, /**< Number of fragment program results */
> } gl_frag_result;
>
> const char *gl_frag_result_name(gl_frag_result result);
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_
> pipeline.c
> index 907b24a758d..be007f24e3f 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -872,6 +872,8 @@ anv_pipeline_compile_fs(struct anv_pipeline *pipeline,
> unsigned num_rts = 0;
> struct anv_pipeline_binding rt_bindings[8];
> nir_function_impl *impl = nir_shader_get_entrypoint(nir);
> + int map_old_to_new_loc[FRAG_RESULT_MAX];
> + memset(map_old_to_new_loc, -1, sizeof(int) * FRAG_RESULT_MAX);
> nir_foreach_variable_safe(var, &nir->outputs) {
> if (var->data.location < FRAG_RESULT_DATA0)
> continue;
> @@ -886,7 +888,13 @@ anv_pipeline_compile_fs(struct anv_pipeline *pipeline,
> }
>
> /* Give it a new, compacted, location */
> - var->data.location = FRAG_RESULT_DATA0 + num_rts;
> + if (var->data.location != -1) {
>
How is this even possible?
> + if (map_old_to_new_loc[var->data.location] == -1)
> + map_old_to_new_loc[var->data.location] =
> FRAG_RESULT_DATA0 + num_rts;
> + var->data.location = map_old_to_new_loc[var->data.location];
> + } else {
> + var->data.location = FRAG_RESULT_DATA0 + num_rts;
> + }
>
I see what you are trying to fix. However, if we're going to get composite
types right, I think we need to do it in three passes:
1) Define a `bool rt_used[MAX_RTS]` map and walk over everything and flag
the given RT as used.
2) Walk over rt_used and generated a `int rt_to_binding[MAX_RTS]` map as
well as set up the `rt_bindings` map (which is really just a map going in
the other direction).
3) Walk the variables again and re-assign locations using `rt_to_binding`
I don't see how any more direct method will actually yield the correct
result in all of the crazy cases such as where you have an array of vec2s
at component 0 and then a bunch of stray floats at components 2 and 3.
Sorry for not responding earlier,
--Jason
> unsigned array_len =
> glsl_type_is_array(var->type) ? glsl_get_length(var->type) :
> 1;
> --
> 2.14.2
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171108/b7e045e5/attachment-0001.html>
More information about the mesa-dev
mailing list