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

Thu Nov 28 07:29:41 PST 2013

Thanks for the replies. I think my main question (feasibility) has been
answered in the negative.

As Marek says, resource_from_handle only works for 2D non-mipmapped
pipe_resources for the radeon driver. This seems to be the same for svga
driver also.  Even if more drivers were supporting mipmapped textures,
cubemap, etc in resource_from_handle, this doesn't seem to be enough.  I've
tried simply referencing a cubemap pipe_resource in a 2D gl_texture (+
ensuring that st_finalize_texture doesn't clobber the pipe_resource), and
then setting up a sampler_view to limit the layer/face, but this does not
seem to be handled correctly (by the svga driver at least). But I'm not
sure if that's even a correct intended use-case.  From Marek and Roland's
comments (about needing a target override in the sampler_view), it sounds
like it is not a valid use-case.

Sticking with the example of a cubemap face being reinterpreted as a
single-layer 2d texture, and supposing that a target override is added to
pipe_sampler_view. If that was done, then I'm supposing that the underlying
pipe_resource would be a cubemap type which is attached 2d gl_texture.
st_finalize_texture wouldn't like this, as it wants to enforce strict
matching between pipe_resource parameters and gl_texture/image parameters.
But I suppose such complications could be bypassed with some different
logic for egl image target textures.
Why might there be a need to do a resource_from_handle if there's a target
override in the pipe_sampler_view?

On Wed, Nov 27, 2013 at 5:56 PM, Roland Scheidegger <sroland at vmware.com>wrote:

> 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
> >
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131128/b93dcaf2/attachment-0001.html>