On Wed, Aug 20, 2014 at 11:47 AM, Jose Fonseca <jfons...@vmware.com> wrote: > 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.
Another quick + cheap alternative (at least looking at nv50/nvc0 code) would be to pass a separate target parameter to ->create_sampler_view(). That would be enough for nouveau, but perhaps not more generally? Take a look at nv50_tex.c:nv50_create_texture_view -- it also needs to work out the depth of the texture (presumably to deal with out-of-bounds accesses) and that is written to the texture info structure. Anyways, I guess I'll have to add a PIPE_CAP_TEXTURE_VIEW if the layouts might not be compatible for some drivers? Or is there something that exists that I should restrict it to? -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
