Questions about KHR_platform_gbm behaviour with multiple gbm_devices

Christopher James Halse Rogers raof at
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