mesa, libgbm and weston
All,
I've been meaning to ask this for quite some time. It appears that Weston's DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the entire mesa, but it only needs libgbm. Now, mesa in OE-Core provides libgbm as one of its packages, hence virtual/mesa is added in DEPENDS for kms:
PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa mtdev"
On TI platforms with SGX GPU we have GLES/EGL stack (provided by proprietary blobs, yeah) and a separate libgbm, based on Rob Clark's https://github.com/robclark/libgbm
Since that is enough to run Weston on our platforms, I've been carrying this bbappend for long time:
PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev libgbm mtdev"
It's been working fine for long time, but people keep on asking questions and require cleaner solution, since bbappend in a separate layer is somewhat confusing. Now, the question is what is a proper solution here:
1. Change weston recipe in oe-core to depend on libgbm instead of virtual/mesa assuming that it is provided by mesa recipe and it works for other platforms.
2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa, although it looks like a hack and is somewhat reverse...
Signature · 1 line
Denys
Quoted 28 lines · Denys Dmytriyenko
All,
I've been meaning to ask this for quite some time. It appears that Weston's DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the entire
mesa, but it only needs libgbm. Now, mesa in OE-Core provides libgbm as one of
its packages, hence virtual/mesa is added in DEPENDS for kms:PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa mtdev"
On TI platforms with SGX GPU we have GLES/EGL stack (provided by proprietary
blobs, yeah) and a separate libgbm, based on Rob Clark's
https://github.com/robclark/libgbm
Since that is enough to run Weston on our platforms, I've been carrying this
bbappend for long time:PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev libgbm mtdev"
It's been working fine for long time, but people keep on asking questions and
require cleaner solution, since bbappend in a separate layer is somewhat confusing. Now, the question is what is a proper solution here:
Quoted 5 lines
1. Change weston recipe in oe-core to depend on libgbm instead of virtual/mesa
assuming that it is provided by mesa recipe and it works for other platforms.
I'd say this, either libgbm or virtual/libgbm.
2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa,
Quoted 3 lines
although
it looks like a hack and is somewhat reverse...
I think the libgbm recipe would basically be lying if you do that, that doesn't sound ideal.
Quoted 38 lines · Christopher Larson
Quoted 28 lines · Denys Dmytriyenko
All,
I've been meaning to ask this for quite some time. It appears that Weston's DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the entire
mesa, but it only needs libgbm. Now, mesa in OE-Core provides libgbm as one of
its packages, hence virtual/mesa is added in DEPENDS for kms:PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev virtual/mesa mtdev"
On TI platforms with SGX GPU we have GLES/EGL stack (provided by proprietary
blobs, yeah) and a separate libgbm, based on Rob Clark's
https://github.com/robclark/libgbm
Since that is enough to run Weston on our platforms, I've been carrying this
bbappend for long time:PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm udev libgbm mtdev"
It's been working fine for long time, but people keep on asking questions and
require cleaner solution, since bbappend in a separate layer is somewhat confusing. Now, the question is what is a proper solution here:Quoted 5 lines
1. Change weston recipe in oe-core to depend on libgbm instead of virtual/mesa
assuming that it is provided by mesa recipe and it works for other platforms.I'd say this, either libgbm or virtual/libgbm.
Quoted 7 lines
2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa,
Quoted 3 lines
although
it looks like a hack and is somewhat reverse...I think the libgbm recipe would basically be lying if you do that, that doesn't sound ideal.
Thanks, Chris.
One other thing I was thinking is how to avoid conflict between separate libgbm and the one provided by mesa-gl. As mesa-gl may be useful for providing SW rendering for OpenGL, while leaving OpenGLES to a separate provider, like SGX. Unfortunately, mesa-gl also provides libgbm - would PACKAGECONFIG to use a standalone external libgbm work and be acceptable here?
Signature · 1 line
Denys
Quoted 9 lines · Denys Dmytriyenko
One other thing I was thinking is how to avoid conflict between separate libgbm and the one provided by mesa-gl. As mesa-gl may be useful for providing
SW rendering for OpenGL, while leaving OpenGLES to a separate provider, like
SGX. Unfortunately, mesa-gl also provides libgbm - would PACKAGECONFIG to use
a standalone external libgbm work and be acceptable here?
I added a PACKAGECONFIG for libgbm to mesa.inc, enabled it for mesa and disabled it for mesa-gl, and mesa-gl still build fine but didn't ship a libgbm.
I've forgotten the details about all of this: does mesa-gl shipping libgbm make sense at all? Or in the real world will BSPs either use mesa or their own GLES driver + their own libgbm + mesa-gl if required?
Ross
Quoted 8 lines · Ross
I added a PACKAGECONFIG for libgbm to mesa.inc, enabled it for mesa and disabled it for mesa-gl, and mesa-gl still build fine but didn't ship a libgbm.
I've forgotten the details about all of this: does mesa-gl shipping libgbm make sense at all? Or in the real world will BSPs either use mesa or their own GLES driver + their own libgbm + mesa-gl if required?
I've just sent a couple of mesa patches, can you see if these help?
Ross
Quoted 6 lines · Ross
Quoted 4 lines · Ross
I added a PACKAGECONFIG for libgbm to mesa.inc, enabled it for mesa and disabled it for mesa-gl, and mesa-gl still build fine but didn't ship a libgbm.
Quoted 6 lines
Quoted 4 lines
I've forgotten the details about all of this: does mesa-gl shipping libgbm make sense at all? Or in the real world will BSPs either use mesa or their own GLES driver + their own libgbm + mesa-gl if required?
I've just sent a couple of mesa patches, can you see if these help?
Thanks, making few builds now to test those.
What about virtual/libgbm package and updating mesa's PROVIDES list?
Signature · 1 line
Denys
Quoted 12 lines · Denys Dmytriyenko
Quoted 11 lines · Ross
Quoted 8 lines · Ross
I added a PACKAGECONFIG for libgbm to mesa.inc, enabled it for mesa and disabled it for mesa-gl, and mesa-gl still build fine but didn't ship a libgbm.
I've forgotten the details about all of this: does mesa-gl shipping libgbm make sense at all? Or in the real world will BSPs either use mesa or their own GLES driver + their own libgbm + mesa-gl if required?
Quoted 5 lines
Quoted 1 line
I've just sent a couple of mesa patches, can you see if these help?
Thanks, making few builds now to test those.
What about virtual/libgbm package and updating mesa's PROVIDES list?
I think it would make it even more flexible; I am in favor of it.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 12 lines · Ross
Quoted 9 lines · Denys Dmytriyenko
One other thing I was thinking is how to avoid conflict between separate libgbm and the one provided by mesa-gl. As mesa-gl may be useful for providing
SW rendering for OpenGL, while leaving OpenGLES to a separate provider, like
SGX. Unfortunately, mesa-gl also provides libgbm - would PACKAGECONFIG to use
a standalone external libgbm work and be acceptable here?
Quoted 7 lines
I added a PACKAGECONFIG for libgbm to mesa.inc, enabled it for mesa and disabled it for mesa-gl, and mesa-gl still build fine but didn't ship a libgbm.
I've forgotten the details about all of this: does mesa-gl shipping libgbm make sense at all? Or in the real world will BSPs either use mesa or their own GLES driver + their own libgbm + mesa-gl if required?
Hmm, that is a good question. Probably expecting a separate libgbm by default when using own GLES driver + mesa-gl does make sense. I wonder if anyone is using the one from mesa-gl with their own GLES, then we would need it configurable via PACKAGECONFIG...
Signature · 1 line
Denys
Quoted 8 lines · Christopher Larson
1. Change weston recipe in oe-core to depend on libgbm instead of
Quoted 4 lines
virtual/mesa
assuming that it is provided by mesa recipe and it works for other platforms.I'd say this, either libgbm or virtual/libgbm.
We used virtual/mesa to mean "the Mesa APIs and so on" so libgbm is covered by this. Of course at the time there was only one implementation in mesa. Now that there are genuine alternative reimplementations of libgdm then I agree that a virtual/libgbm is a good move, and replacing all of the virtual/mesa instances that are actually just for libgdm.
Ross
Quoted 8 lines · Ross
Quoted 6 lines · Christopher Larson
1. Change weston recipe in oe-core to depend on libgbm instead of
Quoted 4 lines
virtual/mesa
assuming that it is provided by mesa recipe and it works for other platforms.
Quoted 8 lines
Quoted 2 lines
I'd say this, either libgbm or virtual/libgbm.
We used virtual/mesa to mean "the Mesa APIs and so on" so libgbm is covered by this. Of course at the time there was only one implementation in mesa. Now that there are genuine alternative reimplementations of libgdm then I agree that a virtual/libgbm is a good move, and replacing all of the virtual/mesa instances that are actually just for libgdm.
Thanks, Ross, that makes sense.
Signature · 1 line
Denys
Quoted 5 lines · Ross
We used virtual/mesa to mean "the Mesa APIs and so on" so libgbm is covered by this. Of course at the time there was only one implementation in mesa. Now that there are genuine alternative reimplementations of libgdm then I agree that a virtual/libgbm is a good move, and replacing all of the virtual/mesa instances that are actually just for libgdm.
Just had a chat with a friendly graphics developer. Currently libgbm is tied to the drivers and GL stack implementation, so it makes perfect sense that mesa's libgbm should probably be renamed along with the GL bits to libgbm-mesa, and other drivers ship their own libgbm, and we have a virtual/libgbm to pick between.
Patches welcome from someone who has relevant hardware to test it actually works.
Ross