[Bug 103241] Anv crashes when using 64-bit vertex inputs

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103241

Jason Ekstrand <jason at jlekstrand.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|jason at jlekstrand.net        |apinheiro at igalia.com

--- Comment #3 from Jason Ekstrand <jason at jlekstrand.net> ---
It's been almost 6 months since I last looked at this (sorry about that). 
Here's what I remember from when I was looking at it before.

The fundamental problem here seems to be in the way we're trying to handle
dvec4 (and dvec3) vertex attributes in GL and Vulkan.  In GL a dvec4 vertex
attribute takes up one API slot though it consumes two slots for the purposes
of limits.  In Vulkan, it takes up two API slots.

When we did attrib64 for Vulkan, we decided that NIR should just use the Vulkan
convention (which is what TGSI does as well) and we should try to contain the
GL convention to GL.  To do this we have a double_inputs_read field which is
used to flag dvec3 and dvec4 inputs to vertex shaders so that we can map back
and forth.  In glsl_to_nir we map one direction and then we map the other
direction when we do the vertex attribute setup in i965.  So far so good.

When I tried to fix this bug 6 months ago, I wrote a patch which makes
nir_gather_info more properly handle double_inputs_read so that it wouldn't
flag partially used things as being a dvec4 unnecessarily.  This caused
problems because suddenly, nir_gather_info started disagreeing with glsl_to_nir
in some cases and we started failing GL tests.  The problem was that
glsl_to_nir would decide on some mapping and then we would manage to eliminate
some variable uses during NIR optimizations and nir_gather_info would come up
with a different double_inputs_read map.  The new map (which was a subset of
the old) would then be used for state setup and the mapping would mismatch and
everything would explode.

I think what we need to do is to somehow compute the mapping in glsl_to_nir (or
earlier) and then hang on to that mapping and leave it unchanged and then use
it for state setup.  This mapping should probably live in gl_shader_program or
something like that.  We need some sort of a mapping for Vulkan but they
probably aren't the same thing.

Alejandro, could you look at this?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180511/b8129ded/attachment.html>