where does this sit with respect to gbm
Created by: robclark
- gbm has some extra stuff, like surfaces, for gluing together with egl.. but gbm_surface perhaps doesn't make as much sense for other APIs like v4l
- gbm is (mostly) using fourcc, but if "liballoc" uses dataformat this might not fit so nicely as a (backward compatible) extension to gbm
Possibly this new thing just ends up sitting on the side as a separate API which only deals with allocation, with some small extension to gbm to get from a alloc_bo_t
to a struct gbm_bo
? You could also maybe just do that via importing the dma-buf fd into gbm, but it would be convenient for buffers allocated via the gl/vk driver's "liballoc" backend, to be able to recover the original pipe_resource
or equivalent.
The other possibility is new set of EGL extension, plus maybe some optional (ie. not supported by all backends) features like surfaces, so this new thing replaces gbm. Although there are existing users who use gbm to do gl apps on "bare metal" so this would mean that mesa has to support both gbm and new thing as potential args to eglGetDevice()
..