2010/7/8 Kristian Høgsberg <krh@xxxxxxxxxxxxx>:
...
> In the work on the EGL extension, the other Khronos members have
> indicated that sharing buffers by passing an integer could work for
> their implementations too, and that's what the draft standard
> currently requires. I could try to get that changed to a
> size+bytearray couple, but then the "pass the blob" API makes it all
> the way into user APIs. We could implement the integer ID in
> userspace by creating a file in a shared directory by the name of the
> integer handle and serialize meta data into that. I'm not fond of
> either approach, but they're possible.
Chris was asking for details about this extensions, and I thought I'd
post it here too to give a better idea of what it might look like.
We're looking at two new entry points:
EGLDisplayNameKHR eglGetDisplayNameKHR(EGLDisplay dpy);
EGLBoolean eglExportImageKHR(EGLDisplay dpy,
EGLImageKHR image,
EGLDisplayNameKHR target_dpy
EGLImageNameKHR *handle);
with
typedef khronos_uint32_t EGLDisplayNameKHR;
typedef khronos_uint32_t EGLImageNameKHR;
The process that wants to receive a shared EGLImage must call
eglGetDisplayNameKHR() to get a global name for the EGLDisplay handle
it wants to import the EGLImage into and send that to the process
sharing the image. The process sharing the EGLImage then calls
eglExportImageKHR() and gets an integer handle for the EGLImage it can
send back to the receiving process, which will pass it as the
EGLClientBuffer argument to eglCreateImage(). At that point, the
receiving process can use the EGLImage as usual.
As I said above, nothing here requires using integer names, but it
makes an application level API easier to use and does fit in rather
nicely with how GL otherwise uses integer names for various objects.
Kristian
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
