On 20/08/14 16:31, Ilia Mirkin wrote:
Hm, it's not tested. And you're right, that would (most likely) mess
up, since it would only have the pipe_resource's target. Any
suggestions on how to fix it? Should the target be added to
pipe_sampler_view?
On Wed, Aug 20, 2014 at 11:25 AM, Roland Scheidegger <srol...@vmware.com> wrote:
Didn't look at it that closely, but I'm pretty surprised this really
works. One things ARB_texture_view can do is cast cube maps (and cube
map arrays) to 2d arrays and vice versa (also 1d/2d to the respective
array type), and we cannot express that in sampler views (yet) (we can't
express it in surfaces neither but there it should not matter). Which
means the type used in the shader for sampling will not match the
sampler view, which sounds quite broken to me.
Roland
Probably the only sane thing to do eliminate the disctinction between
PIPE_TEXTURE_FOO and PIPE_TEXTURE_FOO_ARRAY like in
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476202.aspx ,
e.g.,:
enum pipe_texture_target {
PIPE_BUFFER = 0,
PIPE_TEXTURE_1D = 1,
PIPE_TEXTURE_2D = 2,
PIPE_TEXTURE_3D = 3,
PIPE_TEXTURE_CUBE = 4, // Must have same layout as PIPE_TEXTURE_2D
PIPE_TEXTURE_RECT = 5,
PIPE_TEXTURE_1D_ARRAY = PIPE_TEXTURE_1D,
PIPE_TEXTURE_2D_ARRAY = PIPE_TEXTURE_2D,
PIPE_TEXTURE_CUBE_ARRAY = PIPE_TEXTURE_CUBE,
PIPE_MAX_TEXTURE_TYPES
};
We could also remove PIPE_TEXTURE_CUBE and have cube-maps be
PIPE_TEXTURE_2D with a flag, but that's probably a lot of work.
Instead, drivers that want to be able to support ARB_texture_view will
need to ensure PIPE_TEXTURE_CUBE/PIPE_TEXTURE_2D layout match.
Jose
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
