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

Abdiel Janulgue abdiel.janulgue at linux.intel.com
Mon Jan 7 00:40:47 PST 2013

On Thursday, January 03, 2013 05:00:39 PM Eric Anholt wrote:
> 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

Yes. In addition, we also support cubemap faces and slices of volume textures 
as sources.

> 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.

Good idea! I'll clean up the patches and submit a third revision of the 
implementation for review and put the error reporting in place for non-tile-
aligned hw.


> Thinking about this all reminds me: We should error out for making
> depth/stencil textures EGLimages as renderbuffers work.  That way lies
> madness.

More information about the mesa-dev mailing list