[Mesa-dev] Mesa EGL extensions

[Chia-I Wu]

2010/8/27 Kristian Høgsberg <krh at bitplanet.net>:
> 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.
I am not aware of any user of EGL_MESA_screen_surface.  It was
designed for Xegl which was dead for a while, IIRC.

It is conceptually useful though.  It enables EGL on platforms without
window systems.  The bulk of the extension is about mode setting.  But
as the extension predates KMS, which is still getting new features
itself, the extension does not receive much attention.

With the new DRM display and image extensions, there is nothing in
EGL_MESA_screen_surface that cannot be accomplished by the new
extensions.  The complexity of mode setting, which is taken care of by
EGL_MESA_screen_surface, can also be moved to an utility library.
Personally, I would vote for killing the extension in the git history.
>> 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.
Allocated for Mesa?
>> - 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
olv at LunarG.com