<div dir="ltr"><div><div>Thanks for the replies. I think my main question (feasibility) has been answered in the negative. <br><br></div>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.<br>
<br></div>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. <br>
Why might there be a need to do a resource_from_handle if there's a target override in the pipe_sampler_view?<br> <br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 5:56 PM, Roland Scheidegger <span dir="ltr"><<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm yes doing things like 1) will get hacky pretty fast.<br>
resource_from_handle is more like a necessary kludge, because we can't<br>
enforce everybody to use a common object type (like pipe_resource) for<br>
sharing outside gallium. I wouldn't know how to do this cleanly there.<br>
I agree that we're probably going to need a target override in<br>
pipe_sampler_view. Though just about the only interesting override<br>
ARB_texture_view allows is the cube->array and vice versa mapping, the<br>
rest (non-array->array and vice versa) is only necessary because GL<br>
still has distinct array and non-array resources.<br>
Though I actually thought some hw really had different texture layouts<br>
for cube maps and 2d array textures. Might have been early intel dx10<br>
hw? In any case though I guess ever since cube map arrays probably<br>
everybody can do this, and the gallium changes required should be<br>
relatively straightforward (drivers supporting it simply need to use the<br>
target from the view instead of the underlying resource, and for those<br>
which don't support it no changes should be necessary).<br>
<br>
Roland<br>
<br>
<br>
Am 27.11.2013 23:14, schrieb Marek Olšák:<br>
<div class="im">> 1) resource_from_handle and resource_get_handle only support 2D<br>
> textures without mipmaps on Radeon. Adding support for more texture<br>
> types is possible, but changes are needed in the kernel driver too,<br>
> which is where we store information about the layout of the resource.<br>
><br>
> 2) This is not possible with Gallium at the moment. We would need to<br>
> add a texture target variable to pipe_sampler_view, which would<br>
> override pipe_resource's target. This is required by ARB_texture_view,<br>
> so it will happen sooner or later anyway.<br>
><br>
> I think you'll need both.<br>
><br>
> Marek<br>
><br>
> On Wed, Nov 27, 2013 at 7:23 PM, Ryan Morris <<a href="mailto:ryanmorris500@gmail.com">ryanmorris500@gmail.com</a>> wrote:<br>
>> .. let me try that again.<br>
>><br>
>><br>
>> I've been looking into adding support for the KHR_gl_*_image extensions to<br>
>> mesa/gallium as was attempted here:<br>
</div>>> <a href="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" target="_blank">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</a><br>
<div><div class="h5">>><br>
>> Looking further into how creating an eglimage out of a cubemap face has got<br>
>> me wondering whether or not it's feasible in the gallium framework.<br>
>> The trouble I'm seeing is that texture memory is "hidden" from the<br>
>> state_tracker layer as the state_tracker can only see a pipe_resource or a<br>
>> winsys handle not how the various cubemap faces are layed out in memory.<br>
>> pipe_resources for a cubemap texture have a specific type<br>
>> (PIPE_TARGET_CUBEMAP) and I presume that the underlying driver<br>
>> implementation is free to allocate memory for cubemaps in whatever way it<br>
>> sees fit (i.e. it's not stipulated by the gallium interface).<br>
>><br>
>> So then if a user wants to take an eglimage sourced from a cubemap texture<br>
>> and then use that to target a 2D texture, the created 2D texture has to<br>
>> somehow reference the memory attached to the cubemap pipe_resource, but only<br>
>> one face of it. I can think of two general approaches:<br>
>> (1) Somehow create a pipe_resource with a winsys handle that points to only<br>
>> a sub-face of memory attached to the cubemap pipe_resource.<br>
>> (2) Find a way to use the cubemap pipe_resource such that we only look at<br>
>> one face and it behaves like a 2D texture.<br>
>><br>
>> I thought (2) could perhaps be accomplished with sampler_views. But any<br>
>> experimenting I've done there has convinced me that a sampler_view (with<br>
>> first_layer and last_layer restricted to the face that I care about) can't<br>
>> convince the underlying driver/GPU to make the cupemap texture behave like a<br>
>> 2d texture.<br>
>><br>
>> And for (1), I haven't seen any mechanisms that allow for this kind of<br>
>> sub-referencing of memory regions.<br>
>><br>
>> So my question is, does anyone with more experience with gallium / the mesa<br>
>> state_tracker have an idea of how targeting a 2D texture with an eglimage<br>
>> sourced from a cubemap face would work? Are any of my above<br>
>> assumptions/conclusions incorrect?<br>
>><br>
>> Thanks.<br>
>><br>
>><br>
>> On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris <<a href="mailto:ryanmorris500@gmail.com">ryanmorris500@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> This is my first post to this forum, so apologies if I say anything<br>
>>> horrendously wrong.<br>
>>><br>
>>> I've been looking into adding support for the KHR_gl_*_image extensions to<br>
>>> mesa/gallium as was attempted here:<br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> mesa-dev mailing list<br>
>> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
</div></div>>> <a href="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" target="_blank">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</a><br>
<div class="im">>><br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
</div>> <a href="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" target="_blank">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</a><br>
<div class="HOEnZb"><div class="h5">><br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>