[Bug 89580] Implement a NIR -> vec4 pass

[bugzilla-daemon at freedesktop.org]

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

--- Comment #26 from Jason Ekstrand <jason at jlekstrand.net> ---
(In reply to Iago Toral from comment #25)
> (In reply to Jason Ekstrand from comment #24)
> > (In reply to Iago Toral from comment #23)
> > > 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.
> 
> Nice, that makes sense. In that case I guess we will leave our
> implementation as is and modify it when that plan materializes.

It sounded, from what you said above, like you had already modified
nir_lower_io to handle vec4.  If that's  the case just go ahead and do the
rename and add the vec4 version.  No reason to wait for me or Connor to do it.

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