<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#c25">Comment # 25</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:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> <span class="fn">Iago Toral</span></a>
</span></b>
<pre>(In reply to Jason Ekstrand from <a href="show_bug.cgi?id=89580#c24">comment #24</a>)
<span class="quote">> (In reply to Iago Toral from <a href="show_bug.cgi?id=89580#c23">comment #23</a>)
> > 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.
>
> [...]
>
> > 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.
>
> [...]
>
> > 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?
>
> 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.</span >
Nice, that makes sense. In that case I guess we will leave our implementation
as is and modify it when that plan materializes.</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>