mesa, libgbm and weston

mesa, libgbm and weston

[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:

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...

-- 
Denys

Re: mesa, libgbm and weston

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Thu, Apr 21, 2016 at 5:06 PM Denys Dmytriyenko <denis@denix.org> wrote:

> 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.
>

I'd say this, either libgbm or virtual/libgbm.

2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa,
> 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.

[-- Attachment #2: Type: text/html, Size: 2175 bytes --]

Re: mesa, libgbm and weston

[Denys Dmytriyenko]

On Fri, Apr 22, 2016 at 12:27:16AM +0000, Christopher Larson wrote:
> On Thu, Apr 21, 2016 at 5:06 PM Denys Dmytriyenko <denis@denix.org> wrote:
> 
> > 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.
> >
> 
> I'd say this, either libgbm or virtual/libgbm.
> 
> 2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa,
> > 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?

-- 
Denys

Re: mesa, libgbm and weston

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On 22 April 2016 at 01:27, Christopher Larson <clarson@kergoth.com> wrote:

> 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.
>

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

[-- Attachment #2: Type: text/html, Size: 1186 bytes --]

Re: mesa, libgbm and weston

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On 25 April 2016 at 17:50, Denys Dmytriyenko <denis@denix.org> wrote:

> 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

[-- Attachment #2: Type: text/html, Size: 1232 bytes --]

Re: mesa, libgbm and weston

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On 26 April 2016 at 12:59, Burton, Ross <ross.burton@intel.com> wrote:

> 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

[-- Attachment #2: Type: text/html, Size: 904 bytes --]

Re: mesa, libgbm and weston

[Denys Dmytriyenko]

On Tue, Apr 26, 2016 at 12:36:10PM +0100, Burton, Ross wrote:
> On 22 April 2016 at 01:27, Christopher Larson <clarson@kergoth.com> wrote:
> 
> > 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.
> >
> 
> 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.

-- 
Denys

Re: mesa, libgbm and weston

[Denys Dmytriyenko]

On Tue, Apr 26, 2016 at 12:59:05PM +0100, Burton, Ross wrote:
> On 25 April 2016 at 17:50, Denys Dmytriyenko <denis@denix.org> wrote:
> 
> > 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?

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...

-- 
Denys

Re: mesa, libgbm and weston

[Denys Dmytriyenko]

On Tue, Apr 26, 2016 at 03:00:59PM +0100, Burton, Ross wrote:
> On 26 April 2016 at 12:59, Burton, Ross <ross.burton@intel.com> wrote:
> 
> > 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?

Thanks, making few builds now to test those.

What about virtual/libgbm package and updating mesa's PROVIDES list?

-- 
Denys

Re: mesa, libgbm and weston

[Otavio Salvador]

On Tue, Apr 26, 2016 at 11:27 AM, Denys Dmytriyenko <denis@denix.org> wrote:
> On Tue, Apr 26, 2016 at 03:00:59PM +0100, Burton, Ross wrote:
>> On 26 April 2016 at 12:59, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> > 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?
>
> 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.


-- 
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

Re: mesa, libgbm and weston

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On 26 April 2016 at 12:36, Burton, Ross <ross.burton@intel.com> wrote:

> 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

[-- Attachment #2: Type: text/html, Size: 1275 bytes --]