On Tue, Jul 7, 2015 at 4:24 PM, Jose Fonseca <jfons...@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.ol...@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.
Of course we could just ignore that and guarantee that first==last for images.
>
> 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
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
