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

Ryan Morris ryanmorris500 at gmail.com
Wed Nov 27 10:23:15 PST 2013

.. 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:

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?


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:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131127/0ba7fb99/attachment-0001.html>

More information about the mesa-dev mailing list