Am 20.08.2014 17:47, schrieb Jose Fonseca: > 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, I think you meant PIPE_TXTURE_2D there?
> 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. Yes, but that's not what I'm talking about. Even d3d10, which does not have any distinct cube/array texture layouts (actually 10 still had a separate one for cubes, because there was hw which really required a different layout afaik, but it got abandoned in 10.1), still requires shader resource views to have them (and they must match what's declared in the shader): http://msdn.microsoft.com/en-us/library/windows/desktop/ff476211%28v=vs.85%29.aspx So, my guess is we should do the same - just have that type in the sampler view (and drivers wishing to support the extension must take the type from the view, and not the underlying resource - or they could get it from the shader itself, presumably, if they really wanted, this is actually what we do for texture size queries in llvmpipe, but it's more of a necessary hack). You are right though we would not really require distinct types at the resource level, but they don't really get in the way neither. Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
