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 <srol...@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 <ryanmorris...@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 <ryanmorris...@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@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@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
