[Mesa-dev] Mesa EGL extensions

[Kristian Høgsberg]

On Thu, Aug 26, 2010 at 11:55 AM, nobled <nobled at dreamwidth.org> wrote:
> 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[1]. Where'd they come from?

EGL_KHR_surfaceless_{gles1,gles2,opengl} for all practical purposes
Khronos standards, we're down to just a few minor edits.  But it is
still just a draft and as such the extension text isn't publically
available yet.

> Are there any docs for EGL_NOK_texture_from_pixmap either? Mesa's the
> only reference I can find for that, too.

It is an official extension, but I don't know why it's not available
from the Khronos registry.  I'm guessing the web page just hasn't been
updated yet.

> Also, the EGL_MESA_screen_surface spec[2] 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[3]. Could someone official file for
> an allocation of vendor extension enums for Mesa with Khronos?
> (instructions in [3])

I can't speak for EGL_MESA_screen_surface, but shipping unauthorized
tokens certainly is a problem.

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

It's using allocated tokens.

> - The spec file should probably go in src/egl/docs/, not in docs/ with
> the OpenGL extensions.

I don't think so, if anything the MESA_screen surface spec should be in docs/

> - Same concerns about backwards-compatibility as with the
> screen_surface extension - should it require an explicit -D define
> until it's finalized?

It is 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?

Yes.

> The trouble is that seems to go against the
> EGL_KHR_image_base spec for creating EGLImages from existing EGLImage
> siblings/targets/sources:[4]
>
>       * 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
> contradictory).

Yes, but this is also an issue with the image_pixmap extension, which
also concerns sharing EGLImages between multiple processes.  I guess
one way to view this is that the EGLImage created from a drm buffer
name is conceptually the same as the EGLImage in the other process
where the name was assigned.

Kristian