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.
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
