On 07/07/15 21:28, Ilia Mirkin wrote:
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.
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.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
