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 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
> 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 gall
