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

[Jose Fonseca]

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.

This would enable drivers to treat them uniformly internally if they 
wanted (e.g, by concatenating all views bindings into a single array as 
you described). Or seperate internal objects if they wanted.

This seems the best of both worlds.

There is even a precendent: {create,bind,delete}_{fs,vs,gs}_state. 
These all use the same template structure, but drivers are free to 
create joint or disjoint private structures for each kind.  And in face 
llvmpipe (and all draw based drivers), end up using different private 
objects.

Jose