<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement a NIR -> vec4 pass"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89580#c24">Comment # 24</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Implement a NIR -> vec4 pass"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89580">bug 89580</a>
from <span class="vcard"><a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> <span class="fn">Jason Ekstrand</span></a>
</span></b>
<pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=89580#c23">comment #23</a>)
<span class="quote">> Jason, about the stuff with uniforms that has been bugging me:
>
> The thing is that the vec4 backend and the nir_lower_io pass do not seem to
> work very well together for uniforms. The reason for this is that the vec4
> backend assumes that uniform elements are vec4-sized while nir_lower_io
> (specifically, the get_io_offset function) doesn't. This creates a problem
> because the offsets we compute in nir are not in the same units than what
> the vec4 backend expects.</span >
[...]
<span class="quote">> Initially, I fixed this by patching get_io_offset so that as soon as it was
> computing an offset into something that had indirect indexing in a vertex
> shader, it would use vec4 units to compute sizes all over get_io_offset.
> That solution worked fine, but it did not look very clean to me (I imagine
> we do not want NIR to deal with this sort of things, since the decision to
> pad uniform elements to vec4 sizes seems like a backend thing to me and
> other drivers could decide to not do that), so I was trying to find a
> different solution.</span >
[...]
<span class="quote">> So at this point I am not sure about the best approach to follow, I think
> our current patch for nir_lower_io with indirect array accesses is a bit
> ugly, but at the same time it is small, quite self-contained and it works,
> the alternative to this seems to be a large change that would make the
> nir-vec4 backend quite different to the current vec4_visitor and that also
> looks troublesome (and I guess it would also take some time to get working),
> so I am not sure if it is a good idea right now or if there is a better
> solution to this problem that I am missing.
>
> What do you think?</span >
The plan that Connor and myself have had is to rename nir_lower_io to
nir_lower_io_scalar and add a nir_lower_io_vec4 for vec4-based backends.
Hopefully, those can share most of their code. The whole point of nir_lower_io
is to turn it from variables and derefs into something that is nice for drivers
to work with. If that means we need a vec4 version in order to be nice to
vec4-based backends, that's fine. Intel isn't the only hardware with
vec4-based shaders.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>