[Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v2)
kenneth at whitecape.org
Tue May 5 15:19:59 PDT 2015
On Tuesday, May 05, 2015 03:05:02 PM Matt Turner wrote:
> On Tue, May 5, 2015 at 2:17 PM, Francisco Jerez <currojerez at riseup.net> wrote:
> > Kenneth Graunke <kenneth at whitecape.org> writes:
> >> That then begs the question - could we do the format conversion and
> >> address calculations in a i965-specific NIR pass? It could simplify
> >> the backend changes. NIR also has better CSE, which could help for
> >> repeated image access.
> > I doubt that rewriting things in NIR would be of any help at this point.
> > We could have support for ARB_shader_image_load_store already in the
> > 10.6 release if we refrain from reimplementing the world in the last
> > minute. And I doubt that an implementation in terms of NIR would have
> > simplified anything, it would have required a bunch of intrinsics with
> > driver-specific semantics,
> Can you give an example? We weren't sure exactly how to do the bounds
> checking on IVB in NIR (add an extra uniform, or maybe do the
> image-equivalent of textureSize?) but the other work-arounds didn't
> seem like they would be difficult to implement in NIR.
Note that I'm assuming the NIR pass would be very driver specific, i.e.
it would know which formats require typed/untyped messages, or format
For example, it would see a NIR image load intrinsic that's supposed to
return RGBA32_FLOAT, and turn it into an intrinsic that loads
RGBA32_UINT(*), then emit code to do the conversion.
(*) or leave it alone, knowing i965/fs is going to do that anyway.
I'm not sure how tricky it would be to set up an extra uniform, but with
a uniform variable in place, reading/using its fields should be
I'm not sure what extra intrinsics we'd need.
> > and I must admit that I find generating NIR
> > even more annoying than generating i965 IR directly (for an example of
> > what a mean see how  spends over twenty lines to calculate a simple
> > "a + b * c" expression).
> That's nothing specific to NIR itself, and it's really already been
> solved with the new nir_builder. Take a look at Ken's
Yeah, using nir_builder makes this /much/ less annoying...basically one
line of code.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part.
More information about the mesa-dev