Questions about KHR_platform_gbm behaviour with multiple gbm_devices
Christopher James Halse Rogers
raof at ubuntu.com
Thu Mar 3 07:06:10 UTC 2022
Hey all.
I've got some questions about the behaviour of KHR_platform_gbm in the
presence of multiple devices. Particularly: the spec as-written doesn't
mandate that the gbm_surface passed in to
eglCreatePlatformWindowSurface must have been created from the
gbm_device used to create the EGLDisplay (and if you can pass
EGL_DEFAULT_DISPLAY to eglGetPlatformDisplay you *cannot* create a
surface from the underlying gbm_device).
What would people expect to work now, and what would be the right
behaviour be?
There would seem to be the following combinations:
If gbm_device(A) means a gbm_device constructed from an FD to DRM node
A, and so on:
1) EGLDisplay(gbm_device(fd1(A))) + gbm_surface(gbm_device(A)) -
obvious case, works.
2) EGLDisplay(gbm_device(A)) + gbm_surface(gbm_device'(A)) - same
underlying DRM node, different gbm_device*s
3) EGLDisplay(gbm_device(A)) + gbm_surface(gbm_device(B)) - EGLDisplay
and surface are on different DRM devices
[Extra bonus round]
4) EGLDisplay(gbm_device(A)) + gbm_surface(gbm_device(B)) - EGLDisplay
on kmsro node, surface from associated rendering DRM device
Empirically, on AMD & Intel it seems that:
(1) & (2) work - as long as EGLDisplay and the surface have the same
underlying DRM device, it works
(3) - EGLDisplay on Intel node, gbm_surface from AMD node fails, but
everything *seems* to be OK until you actually SwapBuffers (at which
point you get EGL_BAD_SURFACE).
For *my* convenience it would be nice if (1) & (2) were specified to
work, and (3) & (4) were specified to fail at
eglCreatePlatformWindowSurface, but any clarity would be good (although
“different gbm_device is Undefined Behaviour” would be
disappointing ;))
More information about the mesa-dev
mailing list