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

[Francisco Jerez]

Kenneth Graunke <kenneth at whitecape.org> writes:

> 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

imageSize is not enough...  We'd have to get through a bunch of other
driver-specific uniforms somehow (strides, tiling and swizzling
parameters) for untyped surface access to work.

>> 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.
>
Yeah, the format conversion wasn't my concern, it's straightforward
arithmetic.  I'm more worried about handling typed vs untyped access and
passing through the bunch of parameters required for the latter.

> (*) 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.
>
prog_to_nir seems far more readable indeed, but I don't see how this
suggestion is of any help at this point nine days before the end of the
merge window.  Given that reimplementing this in NIR wouldn't be
particularly beneficial neither short-term [we miss the merge window for
no practical benefit] nor long-term [long-term we have an SSA-form
back-end IR, hopefully one that allows us to share code between
back-ends], this is likely to be a complete waste of my time.

> --Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150506/fe7bd099/attachment.sig>