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

Thu Nov 28 14:53:57 PST 2013

A pipe_resource can only be used with the pipe_screen and all its
contexts. You can't use the same pipe_resource in 2 pipe_screens. The
correct way to get the pipe_resource from one pipe_screen to another
is to export it using resource_get_handle and import it in the other
pipe_screen using resource_from_handle.

If all APIs supported by EGL use the same pipe_screen, all you need is
the target override in pipe_sampler_view. If not, then
resource_from_handle and resource_get_handle must support all texture
targets.

pipe_screen and winsys are actually singletons in the radeon driver
(even if the driver is duplicated in several shared objects), so it
should work on that. For example, if you load a DRI radeon driver, and
then you load a VDPAU radeon driver, the VDPAU driver will actually
use the gallium driver from the DRi driver. If you do it the other way
around, the DRI driver will use the gallium driver from the VDPAU
driver. Crazy, huh? But it makes API interop a lot easier and it's
actually a requirement for NV_vdpau_interop to work.

Marek

On Thu, Nov 28, 2013 at 4:29 PM, Ryan Morris <ryanmorris500 at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>