<div dir="ltr"><div>.. let me try that again.<br><br>I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here:<br><a href="http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html">http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html</a><br>
<br></div><div>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.<br></div><div>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).  <br>
</div><div><br></div><div>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:<br>
</div><div>(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.<br></div><div>(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.<br>
<br></div><div>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.<br>
<br></div><div>And for (1), I haven't seen any mechanisms that allow for this kind of sub-referencing of memory regions.  <br><br></div><div>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?<br>
<br></div><div>Thanks.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 1:04 PM, Ryan Morris <span dir="ltr"><<a href="mailto:ryanmorris500@gmail.com" target="_blank">ryanmorris500@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><br>This is my first post to this forum, so apologies if I say anything horrendously wrong.<br><br>
I've been looking into adding support for the KHR_gl_*_image extensions to mesa/gallium as was attempted here:<br>
<br></div>
</blockquote></div><br></div>