On 1 February 2016 at 06:34, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Sun, Jan 31, 2016 at 3:26 PM, Dave Airlie <airl...@gmail.com> wrote:
>> On 31 January 2016 at 23:39, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> On Sun, Jan 31, 2016 at 2:37 AM, Dave Airlie <airl...@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.
Dave.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
