[Mesa-dev] i965 implementation of the ARB_shader_image_load_store built-ins. (v2)

[Kenneth Graunke]

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
conversion.

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
straightforward.

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 [1] 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
> src/mesa/program/prog_to_nir.c.

Yeah, using nir_builder makes this /much/ less annoying...basically one
line of code.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150505/2b37b58a/attachment.sig>