[Mesa-dev] [RFC] gallium: add interface for writable shader images
jfonseca at vmware.com
Tue Jul 7 13:35:43 PDT 2015
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
>> 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),
>>> 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
>>> 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
D3D11_TEX2D_ARRAY_UAV allows to specify first/last layer
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.
More information about the mesa-dev