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

[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:
> http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html
>
> 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
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>