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

[Marek Olšák]

I'd like to discuss one more thing that will affect whether image
slots will be global (shared by all shaders) or not.

Which image unit an image uniform uses is not a compile-time thing,
but it's specified later using glUniform1i. That means we need a
per-shader table that maps image uniforms to global image units. One
possible solution is to add this pipe_context function:

void (*set_shader_image_mapping)(
   struct pipe_context *, unsigned shader,
   unsigned start_decl_index, unsigned count,
   unsigned *decl_to_slot_mapping);

This is only required if the shader image slots are global and not
per-shader. (if they are per-shader, st/mesa can reorder the slots for
each shader independently just like it already does for textures and
UBOs) Shader storage buffer objects suffer from the same issue. Atomic
counters don't.

Therefore, image slots must be per-shader (like sampler slots) to
avoid this craziness and keep things simple.

Marek



On Tue, Jul 7, 2015 at 10:49 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev