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

[Jose Fonseca]

This should be possible with:

   struct pipe_resource * (*resource_from_handle)(struct pipe_screen *,
						  const struct pipe_resource *templat,
						  struct winsys_handle *handle);


Nothing impedes this to work with cubemaps.   "templat" needs to match of course, and it is assumed that given the same template and handle info, the same layout will be replicated.   If more info is necesary, the struct winsys_handle should have the information  -- struct winsys_handle  could have any members desired, or be a pointer to a shared memory where all the layout is described.


All the state tracker needs to know is which face to use, when creating the sampler/surface views.


Jose





----- Original Message -----
> .. 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:
> http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html
> 
> 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=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=Iex6Y9OBTPLHmrCnHXxtJDPlHBsprQK0Oa3EW6tPgJE%3D%0A&s=6dd50ee644eb2f6c109c94a5110dc633528ca381d1c223c39904e8436fb29621
>