[Bug 89580] Implement a NIR -> vec4 pass

[bugzilla-daemon at freedesktop.org]

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

--- Comment #25 from Iago Toral <itoral at igalia.com> ---
(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.

-- 
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/c5840188/attachment.html>