[Mesa-dev] [RFC] intel: add support for EGL_KHR_gl_image

[Eric Anholt]

Abdiel Janulgue <abdiel.janulgue at linux.intel.com> writes:

> On Friday, December 14, 2012 11:38:04 AM Eric Anholt wrote:
>> Abdiel Janulgue <abdiel.janulgue at linux.intel.com> writes:
>> > This patch set adds support for KHR_gl_texture_2D_image,
>> > KHR_gl_texture_cubemap_image and KHR_gl_texture_3D_image for Gen 4 ->
>> > Gen7 HW. The extension enables us to be a bit more conformant to the
>> > spec in Android at least. I've tested it on SandyBridge and IvyBridge.
>> > 
>> > The approach is to export a mipmap level to a DRIImage accounting for
>> > the level's offset from the surface base address including the x and y
>> > offsets on cubemap face or 3D texture slices.
>> > 
>> > I've pushed it in git at gitorious.org/mesa3d/mesa.git KHR_gl_image
>> > branch. I'll submit a a separate piglit test to soon to piglit-dev.
>> 
>> Cool.  We really should have these extensions.
>> 
>> But we also really need some piglit tests to stress this. 
>
> Thanks! I just submitted an initial test to piglit list.
>
>> The
>> intel_setup_image_from_mipmap_tree() code in this series can orphan
>> siblings the moment they're created.  intel_finalize_mipmap_tree() can
>> also do so currently.  We need to be able to track somehow where the
>> canonical miptree contents are and resolve our work back to it.
>
> Good catch. Do you think if it would make sense to drop support for this non-
> tile-aligned <= gen4 hack in this case? It would make the code much more 
> simpler. The older hardware doesn't seem to support rendering to the fine 
> grained X and Y tile offsets anyways - which is needed to resolve back to the 
> specific miptree level.

Sorry for the delay, I think we all disappeared over the holidays.

Let's see if I've got this all right.  It looks like today we have
extensions for:

OES_EGL_image:
* turn an EGLImage into a 0-level texture
* turn an EGLImage into a renderbuffer

EGL_MESA_DRM_image:
* Create an EGLImage from a format/width/height/drm usage
* possibly create an EGLImage from a format/bo name/stride
* turn an EGLImage into a format/width/height/stride/bo name (can this
  be any EGLImage or just one from EGL_MESA_DRM_image?)

EGL_KHR_image_pixmap:
* turn a pixmap (from X?) into an EGLImage? (don't have the spec on
  hand)

And then as of your changes we support:
* turn a GL 2D texture miplevel into an EGLImage

So I think this is the first time we need to deal with x,y offsets, and
I'd like us to be spec compatible.  Tile alignment is really ugly -- not
only did original gen4 not support the fine-grained offsets, but even
gm45+ don't support sufficiently fine-grained alignments to point at
arbitrary miplevels.  Depth buffers need to be aligned to 8x8, while
miptree levels only get aligned to up to the nearest 4 vertically.

If it's just going from a texture to a texture, I think we're safe on
gm45+ -- miptrees always have images aligned to at least 4x2.  But for
renderbuffers I think we can weasel out by:

   "If the GL is unable to create a renderbuffer using the specified
    eglImageOES, the error INVALID_OPERATION is generated.  If <image>
    does not refer to a valid eglImageOES object, the error
    INVALID_VALUE is generated."

and there's corresponding text for textures:

   "If the GL is unable to specify a texture object using the supplied
    eglImageOES <image> (if, for example, <image> refers to a multisampled
    eglImageOES), the error INVALID_OPERATION is generated."

If we did that for these misalignment, I think I'd be satisfied with
dropping the actual rebasing.  It would mean that everything but
miplevels of depth work on gm45+, and single-level textures work
pre-gm45.  Faking shared storage for misalignment just seems
unreasonably hard unless we have a strong requirement for it.

Thinking about this all reminds me: We should error out for making
depth/stencil textures EGLimages as renderbuffers work.  That way lies
madness.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130103/5c1f5c9c/attachment.pgp>