[Mesa-dev] [PATCH 6/7] st/mesa: convert GLSL image intrinsics into TGSI

[Ilia Mirkin]

On Sun, Jan 31, 2016 at 3:36 PM, Dave Airlie <airlied at gmail.com> wrote:
> On 1 February 2016 at 06:34, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Sun, Jan 31, 2016 at 3:26 PM, Dave Airlie <airlied at gmail.com> wrote:
>>> On 31 January 2016 at 23:39, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Sun, Jan 31, 2016 at 2:37 AM, Dave Airlie <airlied at gmail.com> wrote:
>>>>>> +   for (i = 0; i < program->shader->NumImages; i++) {
>>>>>> +      if (program->images_used & (1 << i)) {
>>>>>> +         t->images[i] = ureg_DECL_image(ureg, i,
>>>>>> +                                        program->image_targets[i],
>>>>>> +                                        program->image_formats[i],
>>>>>> +                                        true, false);
>>>>>
>>>>> Can we not know if the image is writable from the GL level?
>>>>
>>>> Yes, we can. But do we care? It was there already so I kept the flag,
>>>> but I'd be fully in favor of removing it...
>>>>
>>>> layout(writeonly) in GLSL lets you not specify a format, which would
>>>> come through as PIPE_FORMAT_NONE in here. But beyond validation, I
>>>> don't see what the use is. Something like layout(readonly) just causes
>>>> imageStore() to error out...
>>>
>>> I think on radeon it might let us not bind the image to the CB, but just
>>> texture loads on it directly.
>>
>> Wouldn't you want to do that anyways, even if it's not marked
>> readonly? (This reminds me - I forgot all about the caching modifiers
>> on image declarations. Oops. But I'll add those later.)
>
> No as we need to bind it to the CB to do stores or atomic operations on it,
>
> r600/evergreen can't directly access images/buffers it has to bind them
> to the CB block to do atomic or writes.

OK, but this won't give you that info at bind time. gl_image_unit has
an "access" flag that we totally ignored for pipe_image_view which we
could throw in. Would that be helpful as well? I guess at that point,
having those two match up in the shader would be beneficial since
presumably it would mean totally different shader code generated
depending on the bind flag.