[Mesa-dev] [RFC] gallium: add interface for writable shader images

[Roland Scheidegger]

Am 07.07.2015 um 22:35 schrieb Jose Fonseca:
> On 07/07/15 21:28, Ilia Mirkin wrote:
>> On Tue, Jul 7, 2015 at 4:24 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>> I'm not experienced with the semantics around resources that can be
>>> read/written by shaders, so I can't really make educated comments.
>>>
>>> But overall this looks good to me FWIW.
>>>
>>> On 05/07/15 14:25, Marek Olšák wrote:
>>>>
>>>> From: Marek Olšák <marek.olsak at amd.com>
>>>>
>>>> Other approaches are being considered:
>>>>
>>>> 1) Don't use resource wrappers (views) and pass all view parameters
>>>>      (format, layer range, level) to set_shader_images just like
>>>>      set_vertex_buffers, set_constant_buffer, or even
>>>> glBindImageTexture
>>>> do.
>>>
>>>
>>> I don't know how much pipe drivers leverage this nowadays, but these
>>> structures are convenient placeholders for driver data, particular
>>> when they
>>> don't support something (e.g., a certain format, or need some
>>> swizzling),
>>> natively.
>>>
>>>>
>>>> 2) Use pipe_sampler_view instead of pipe_image_view,
>>>>      and maybe even use set_sampler_views instead of set_shader_images.
>>>>      set_sampler_views would have to use start_slot >=
>>>> PIPE_MAX_SAMPLERS
>>>> for
>>>>      all writable images to allow for OpenGL textures in the lower
>>>> slots.
>>>
>>>
>>> If pipe_sampler_view  and pipe_image_view are the same, we could
>>> indeed use
>>> one structure for both.  While still keeping the separate
>>> create/bind/destroy functions.
>>
>> The big difference is that a sampler view has a first/last layer and
>> first/last level, while image views are more like surfaces which just
>> have the one of each. But they also need a byte range for buffer
>> images.
> 
> D3D11_TEX2D_ARRAY_UAV allows to specify first/last layer
> https://msdn.microsoft.com/en-us/library/windows/desktop/ff476242.aspx ,
> so it sounds that once pipe_image_view is updated to handle D3D11, the
> difference would reduce to the absence of last_level
> 
>> Of course we could just ignore that and guarantee that first==last for
>> images.
> 
> Yes, it might not be a bad idea.
> 

You could of course argue then isn't it really more like pipe_surface?
At least in d3d11 clearly they are much closer in concept to rts. The
actual structures are of course mostly the same in gallium, the
differences boil down to pipe_surface having (long obsolete)
width/height parameters and a writable flag, whereas sampler views
instead have swizzling fields (I don't think they'd have any use for
this), support multiple levels (again, not needed for shader images /
uavs), and have a target parameter (in d3d10, rts actually have a target
parameter too, but it is of no practical consequence, hence there was no
need for that in gallium - I'm not sure if it would be required for
shader images / uavs, uavs certainly have such target parameter too but
I'm not sure it matters).
But in any case, I'm pretty impartial to what structure is used, as long
as it is created/destroyed separately.

Roland