[Mesa-dev] Feasibility of KHR_gl_texture_cubemap_image in mesa/gallium

[Roland Scheidegger]

Hmm yes doing things like 1) will get hacky pretty fast.
resource_from_handle is more like a necessary kludge, because we can't
enforce everybody to use a common object type (like pipe_resource) for
sharing outside gallium. I wouldn't know how to do this cleanly there.
I agree that we're probably going to need a target override in
pipe_sampler_view. Though just about the only interesting override
ARB_texture_view allows is the cube->array and vice versa mapping, the
rest (non-array->array and vice versa) is only necessary because GL
still has distinct array and non-array resources.
Though I actually thought some hw really had different texture layouts
for cube maps and 2d array textures. Might have been early intel dx10
hw? In any case though I guess ever since cube map arrays probably
everybody can do this, and the gallium changes required should be
relatively straightforward (drivers supporting it simply need to use the
target from the view instead of the underlying resource, and for those
which don't support it no changes should be necessary).

Roland


Am 27.11.2013 23:14, schrieb Marek Olšák:
> 1) resource_from_handle and resource_get_handle only support 2D
> textures without mipmaps on Radeon. Adding support for more texture
> types is possible, but changes are needed in the kernel driver too,
> which is where we store information about the layout of the resource.
> 
> 2) This is not possible with Gallium at the moment. We would need to
> add a texture target variable to pipe_sampler_view, which would
> override pipe_resource's target. This is required by ARB_texture_view,
> so it will happen sooner or later anyway.
> 
> I think you'll need both.
> 
> Marek
> 
> On Wed, Nov 27, 2013 at 7:23 PM, Ryan Morris <ryanmorris500 at gmail.com> wrote:
>> .. let me try that again.
>>
>>
>> I've been looking into adding support for the KHR_gl_*_image extensions to
>> mesa/gallium as was attempted here:
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=iCWtx4XZULBjHaK8iC2Y%2BZi%2Fs%2FE1zfBy%2BbxgXKGWhRI%3D%0A&s=2a6413295f63c3caf64b7c5c8555f1b720994c5a321786be450a00dd3cf82e09
>>
>> Looking further into how creating an eglimage out of a cubemap face has got
>> me wondering whether or not it's feasible in the gallium framework.
>> The trouble I'm seeing is that texture memory is "hidden" from the
>> state_tracker layer as the state_tracker can only see a pipe_resource or a
>> winsys handle not how the various cubemap faces are layed out in memory.
>> pipe_resources for a cubemap texture have a specific type
>> (PIPE_TARGET_CUBEMAP) and I presume that the underlying driver
>> implementation is free to allocate memory for cubemaps in whatever way it
>> sees fit (i.e. it's not stipulated by the gallium interface).
>>
>> So then if a user wants to take an eglimage sourced from a cubemap texture
>> and then use that to target a 2D texture, the created 2D texture has to
>> somehow reference the memory attached to the cubemap pipe_resource, but only
>> one face of it.  I can think of two general approaches:
>> (1) Somehow create a pipe_resource with a winsys handle that points to only
>> a sub-face of memory attached to the cubemap pipe_resource.
>> (2) Find a way to use the cubemap pipe_resource such that we only look at
>> one face and it behaves like a 2D texture.
>>
>> I thought (2) could perhaps be accomplished with sampler_views. But any
>> experimenting I've done there has convinced me that a sampler_view (with
>> first_layer and last_layer restricted to the face that I care about) can't
>> convince the underlying driver/GPU to make the cupemap texture behave like a
>> 2d texture.
>>
>> And for (1), I haven't seen any mechanisms that allow for this kind of
>> sub-referencing of memory regions.
>>
>> So my question is, does anyone with more experience with gallium / the mesa
>> state_tracker have an idea of how targeting a 2D texture with an eglimage
>> sourced from a cubemap face would work?  Are any of my above
>> assumptions/conclusions incorrect?
>>
>> Thanks.
>>
>>
>> On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris <ryanmorris500 at gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> This is my first post to this forum, so apologies if I say anything
>>> horrendously wrong.
>>>
>>> I've been looking into adding support for the KHR_gl_*_image extensions to
>>> mesa/gallium as was attempted here:
>>>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=iCWtx4XZULBjHaK8iC2Y%2BZi%2Fs%2FE1zfBy%2BbxgXKGWhRI%3D%0A&s=ba627f40999f4b12b1743290bd33af31c65dfe66483cf3d53f3d5a5b8f20d8e0
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=iCWtx4XZULBjHaK8iC2Y%2BZi%2Fs%2FE1zfBy%2BbxgXKGWhRI%3D%0A&s=ba627f40999f4b12b1743290bd33af31c65dfe66483cf3d53f3d5a5b8f20d8e0
>