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

[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,
    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