[Mesa-dev] Mesa EGL extensions
nobled at dreamwidth.org
Thu Aug 26 08:55:56 PDT 2010
This is a little long, but I was wondering about a couple of the EGL
extensions Mesa implements:
Re: the new EGL_KHR_screenless_opengl and friends that took up the
functionality of EGL_MESA_no_surface - are there specs for those
anywhere on the web? Google gave nothing but Mesa itself, and the KHR
string says it's a Khronos extension, but I can't find it on the
Khronos EGL registry page. Where'd they come from?
Are there any docs for EGL_NOK_texture_from_pixmap either? Mesa's the
only reference I can find for that, too.
Also, the EGL_MESA_screen_surface spec still says it's preliminary
and totally subject to change -- if that's still true, shouldn't it
not be shipped by default if it doesn't guarantee
backwards-compatibility, maybe leave it out unless someone passes a
flag like -DEGL_MESA_screen_surface deliberately? (It also looks like
it hasn't been touched since before the EGL headers were added in Mesa
7.5; are there any changes planned?)
'Cause one reason it probably *shouldn't* offer
backwards-compatibility is it's using EGL enums that are intentionally
just outside the available range. Could someone official file for
an allocation of vendor extension enums for Mesa with Khronos?
(instructions in )
Finally, a few things about the new EGL_MESA_drm_image extension:
- Is it also using unallocated enums? They're in the 0x31D0
"any_vendor_use" range in the eglenum.spec file, but I think that
means 'these might belong to any vendor after Khronos allocates them;
aka Reserved', based on the instructions after that seeming to be
directed to Khronos employees who can edit the file.
- The spec file should probably go in src/egl/docs/, not in docs/ with
the OpenGL extensions.
- Same concerns about backwards-compatibility as with the
screen_surface extension - should it require an explicit -D define
until it's finalized?
- The spec allows creating an EGLImageKHR from scratch, then exporting
the underlying DRM handle, then creating a new EGLImage from that
using the standard eglCreateImageKHR call. The exporting is what lets
clients integrate with the modesetting API, but the point of
'importing' a DRM handle is to make passing the EGLImage between
processes possible, right? The trouble is that seems to go against the
EGL_KHR_image_base spec for creating EGLImages from existing EGLImage
* If the resource specified by <dpy>, <ctx>, <target>, <buffer> and
<attrib_list> is itself an EGLImage sibling, the error
EGL_BAD_ACCESS is generated.
It's discussed in more detail in Issues #4 and #5. I might be missing
something - can the requirement even apply to sources shared across
processes? - but if drm_image does need to contradict the base
EGLImage extension, that should probably be pointed out and more
explicitly justified (and if not, then it should clarify how it isn't
More information about the mesa-dev