[Mesa-dev] [PATCH 2/2] mesa/st: add ARB_texture_view support

[Roland Scheidegger]

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
>> <sroland at 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