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

[Roland Scheidegger]

Am 20.08.2014 17:55, schrieb 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
>> https://urldefense.proofpoint.com/v1/url?u=http://msdn.microsoft.com/en-us/library/windows/desktop/ff476202.aspx&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=x03OmuVWAQgfFbsFB2SLMLwSYavxkU8Zsypu9lEIkpg%3D%0A&s=4b0ca75d91e6d53d92658d9e334cf2a73a01efe5667464c969f5c085409052ff ,
>> 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.
Well that should be enough, but I don't think it fits out design. We've
encapsulated other "override" information like the format in the view
already, and I see no reason why the target "cast" should be treated any
different.


> 
> 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?
I suspect d3d9-class hw couldn't do it (can r300 access a cube map as a
regular 2d texture when sampling)?. Usually it's probably the same hw
which also does not support array textures but it can be different (IIRC
i965 was one such chipset which really had different layout for cube
maps and arrays in particular, though it would not apply to anything
that's supported by ilo).

Roland