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

[Ilia Mirkin]

On Wed, Aug 20, 2014 at 11:47 AM, Jose Fonseca <jfonseca at 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 <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.

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