[meta-oe][PATCH] libva: Removed virtual/mesa dependency

[meta-oe][PATCH] libva: Removed virtual/mesa dependency

[bartlomiej.burdukiewicz]

Mesa can be compiled with libva support, in order to avoid recursive
dependency between mesa and libva, virtual/mesa must be removed
from libva recipe.

Signed-off-by: Bartłomiej Burdukiewicz <bartlomiej.burdukiewicz@gmail.com>
---
 meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 92cea83bc1..c1a441a18b 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -23,7 +23,7 @@ SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940
 
 UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
 
-DEPENDS = "libdrm virtual/mesa"
+DEPENDS = "libdrm"
 
 inherit meson pkgconfig features_check
 
-- 
2.26.2

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 1053 bytes --]



On 4/24/20 8:01 AM, Bartłomiej Burdukiewicz wrote:
> Mesa can be compiled with libva support, in order to avoid recursive
> dependency between mesa and libva, virtual/mesa must be removed
> from libva recipe.
> 
> Signed-off-by: Bartłomiej Burdukiewicz <bartlomiej.burdukiewicz@gmail.com>
> ---
>  meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb b/meta/recipes-graphics/libva/libva_2.6.1.bb
> index 92cea83bc1..c1a441a18b 100644
> --- a/meta/recipes-graphics/libva/libva_2.6.1.bb
> +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
> @@ -23,7 +23,7 @@ SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940
>
>  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>
> -DEPENDS = "libdrm virtual/mesa"
> +DEPENDS = "libdrm"

I am not sure how it will work with non-mesa graphics stacks. Or is it
non-issue ?

>
>  inherit meson pkgconfig features_check
>
> 
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]

Re: [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Bartłomiej Burdukiewicz]

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

On Sat, Apr 25, 2020 at 06:46 AM, Khem Raj wrote:

>
> 
> 
> On 4/24/20 8:01 AM, Bartłomiej Burdukiewicz wrote:
> > Mesa can be compiled with libva support, in order to avoid recursive
> > dependency between mesa and libva, virtual/mesa must be removed
> > from libva recipe.
> > 
> > Signed-off-by: Bartłomiej Burdukiewicz <bartlomiej.burdukiewicz@gmail.com>
> > ---
> >  meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb
> b/meta/recipes-graphics/libva/libva_2.6.1.bb
> > index 92cea83bc1..c1a441a18b 100644
> > --- a/meta/recipes-graphics/libva/libva_2.6.1.bb
> > +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
> > @@ -23,7 +23,7 @@ SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940
> >
> >  UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
> >
> > -DEPENDS = "libdrm virtual/mesa"
> > +DEPENDS = "libdrm"
> 
> I am not sure how it will work with non-mesa graphics stacks. Or is it
> non-issue ?

It looks like libva is designed to work without mesa (or other graphical stacks), since it's using libdrm to dispatch kernel calls.
https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/media/File:DRM_architecture.svg

There is also ebuild in Gentoo for libva do not depend on mesa (https://data.gpo.zugaina.org/gentoo/x11-libs/libva/libva-2.6.1.ebuild) or other graphical stacks (like nvidia-drivers or etc.).

I'll provide more information about actual problem that is happening in meta-kodi and it's related to this patch.

There is append that I created for meta-kodi, that is extending mesa with libva and libvdpau capabilities: 
https://github.com/dev-0x7C6/meta-kodi/blob/zeus/recipes-graphics/mesa/mesa_%25.bbappend

And this is current workaround for libva to avoid recursive dependency:
https://github.com/dev-0x7C6/meta-kodi/blob/zeus/recipes-graphics/libva/libva_%25.bbappend

> 
> >
> >  inherit meson pkgconfig features_check
> >
> > 
> > 
> > 
> > 
> 
>

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

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Fred Baksik]

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


On Sat, Apr 25, 2020, at 3:38 PM, Bartłomiej Burdukiewicz wrote:
> On Sat, Apr 25, 2020 at 06:46 AM, Khem Raj wrote:

>> On 4/24/20 8:01 AM, Bartłomiej Burdukiewicz wrote: > Mesa can be compiled with libva support, in order to avoid recursive > dependency between mesa and libva, virtual/mesa must be removed > from libva recipe. > > Signed-off-by: Bartłomiej Burdukiewicz bartlomiej.burdukiewicz@gmail.com > --- > meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb b/meta/recipes-graphics/libva/libva_2.6.1.bb > index 92cea83bc1..c1a441a18b 100644 > --- a/meta/recipes-graphics/libva/libva_2.6.1.bb > +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb > @@ -23,7 +23,7 @@ SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940 > > UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases" <https://github.com/intel/libva/releases%22> > > -DEPENDS = "libdrm virtual/mesa" > +DEPENDS = "libdrm"

>> I am not sure how it will work with non-mesa graphics stacks. Or is it non-issue ?

> It looks like libva is designed to work without mesa (or other graphical stacks), since it's using libdrm to dispatch kernel calls. https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/media/File:DRM_architecture.svg

> There is also ebuild in Gentoo for libva do not depend on mesa (https://data.gpo.zugaina.org/gentoo/x11-libs/libva/libva-2.6.1.ebuild) or other graphical stacks (like nvidia-drivers or etc.).

> I'll provide more information about actual problem that is happening in meta-kodi and it's related to this patch.

> There is append that I created for meta-kodi, that is extending mesa with libva and libvdpau capabilities: https://github.com/dev-0x7C6/meta-kodi/blob/zeus/recipes-graphics/mesa/mesa_%25.bbappend

> And this is current workaround for libva to avoid recursive dependency: https://github.com/dev-0x7C6/meta-kodi/blob/zeus/recipes-graphics/libva/libva_%25.bbappend

>>> inherit meson pkgconfig features_check

> 

FYI, meta-amd also had to have appends to properly support va with AMD hardware via the mesa library. I think only Intel supplies accelerated video through DRM (without requiring mesa).

Requiring virtual/mesa always seems to be redundant because libva recipe already required the OpenGL distro feature. 

I wanted to point out that libva can be built without enabling GLX support. But with_glx is set to auto and will use OpenGL if meson detects OpenGL being available and X11 is enabled. GLX support seems to enable some additional code for integration with the OpenGL stack. 

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

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Anuj Mittal]

On Sat, 2020-04-25 at 12:38 -0700, Bartłomiej Burdukiewicz wrote:
> On Sat, Apr 25, 2020 at 06:46 AM, Khem Raj wrote:
> 
> > On 4/24/20 8:01 AM, Bartłomiej Burdukiewicz wrote: > Mesa can be
> > compiled with libva support, in order to avoid recursive >
> > dependency between mesa and libva, virtual/mesa must be removed >
> > from libva recipe. > > Signed-off-by: Bartłomiej Burdukiewicz
> > bartlomiej.burdukiewicz@gmail.com > --- > meta/recipes-
> > graphics/libva/libva_2.6.1.bb | 2 +- > 1 file changed, 1
> > insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-
> > graphics/libva/libva_2.6.1.bb b/meta/recipes-
> > graphics/libva/libva_2.6.1.bb > index 92cea83bc1..c1a441a18b 100644
> > > --- a/meta/recipes-graphics/libva/libva_2.6.1.bb > +++
> > b/meta/recipes-graphics/libva/libva_2.6.1.bb > @@ -23,7 +23,7 @@
> > SRC_URI[sha256sum] =
> > "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940 > >
> > UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases" > >
> > -DEPENDS = "libdrm virtual/mesa" > +DEPENDS = "libdrm"
> > 
> > I am not sure how it will work with non-mesa graphics stacks. Or is
> > it non-issue ?
> > 
> 
> It looks like libva is designed to work without mesa (or other
> graphical stacks), since it's using libdrm to dispatch kernel calls. 
> https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/media/File:DRM_architecture.svg
> 
> There is also ebuild in Gentoo for libva do not depend on mesa (
> https://data.gpo.zugaina.org/gentoo/x11-libs/libva/libva-2.6.1.ebuild
> ) or other graphical stacks (like nvidia-drivers or etc.).

I see a DEPEND on opengl there which is what glx backend in libva
expects:

https://github.com/intel/libva/blob/master/meson.build#L95

Just removing the dependency will force glx backend to not be built. Is
there software out there that expects libva-glx to be present?

Thanks,

Anuj

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Bartłomiej Burdukiewicz]

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

On Sun, 26 Apr 2020 06:23:57 CEST Anuj Mittal wrote:
> On Sat, 2020-04-25 at 12:38 -0700, Bartłomiej Burdukiewicz wrote:
> 
> > On Sat, Apr 25, 2020 at 06:46 AM, Khem Raj wrote:
> > 
> > 
> > > On 4/24/20 8:01 AM, Bartłomiej Burdukiewicz wrote: > Mesa can be
> > > compiled with libva support, in order to avoid recursive >
> > > dependency between mesa and libva, virtual/mesa must be removed >
> > > from libva recipe. > > Signed-off-by: Bartłomiej Burdukiewicz
> > > bartlomiej.burdukiewicz@gmail.com > --- > meta/recipes-
> > > graphics/libva/libva_2.6.1.bb | 2 +- > 1 file changed, 1
> > > insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-
> > > graphics/libva/libva_2.6.1.bb b/meta/recipes-
> > > graphics/libva/libva_2.6.1.bb > index 92cea83bc1..c1a441a18b 100644
> > > 
> > > > --- a/meta/recipes-graphics/libva/libva_2.6.1.bb > +++
> > > 
> > > b/meta/recipes-graphics/libva/libva_2.6.1.bb > @@ -23,7 +23,7 @@
> > > SRC_URI[sha256sum] =
> > > "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940 > >
> > > UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases" > >
> > > -DEPENDS = "libdrm virtual/mesa" > +DEPENDS = "libdrm"
> > > 
> > > I am not sure how it will work with non-mesa graphics stacks. Or is
> > > it non-issue ?
> > > 
> > 
> > 
> > It looks like libva is designed to work without mesa (or other
> > graphical stacks), since it's using libdrm to dispatch kernel calls. 
> > https://en.wikipedia.org/wiki/Direct_Rendering_Manager#/media/File:DRM_arc
> > hitecture.svg
 
> > There is also ebuild in Gentoo for libva do not depend on mesa (
> > https://data.gpo.zugaina.org/gentoo/x11-libs/libva/libva-2.6.1.ebuild
> > ) or other graphical stacks (like nvidia-drivers or etc.).
> 
> 
> I see a DEPEND on opengl there which is what glx backend in libva
> expects:
> 
> https://github.com/intel/libva/blob/master/meson.build#L95
> 
> Just removing the dependency will force glx backend to not be built. Is
> there software out there that expects libva-glx to be present?
> 
> Thanks,
> 
> Anuj

Sorry I was incorrect on Gentoo ebuild it's pulling virtual/opengl which is 
mesa (this is also for building libva-glx). I check what is pulling libva glx 
for Gentoo:

https://pastebin.com/bzppfKSz

For short: 

xine-lib - which is outdated,
qmplay2 - https://github.com/zaps166/QMPlay2#va-api--opengl-information
kodi - libva (with glx) is required for every display backed (wayland/gbm/X11) 
which is strange to me, this is probably lazy approach. I was able to run 
libva with kodi in gbm context without glx, not sure about X11 sessions.
mythtv - https://www.mythtv.org/wiki/VAAPI unclear

Other media player don't have strong requirements for GLX.

I'm now totally unsure. Probably adding PACKAGECONFIG with glx flag (disabled 
by default) will be better approach with conditional virtual/mesa dependency. 
This will fix recursive dependency problem for common cases. There is also ton 
of articles that GLX is deprecated, so softly going away should be a proper 
way.

Or just those bbappends should stay where they are. Another thing is that 
meta-intel layer introduced libva-intel package which also need separate 
bbappend to remove virtual/mesa, this made me to post that patch in first 
place.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 499 bytes --]

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Richard Purdie]

On Tue, 2020-04-28 at 01:09 +0200, Bartłomiej Burdukiewicz wrote:
> Other media player don't have strong requirements for GLX.
> 
> I'm now totally unsure. Probably adding PACKAGECONFIG with glx flag
> (disabled 
> by default) will be better approach with conditional virtual/mesa
> dependency. 
> This will fix recursive dependency problem for common cases. There is
> also ton 
> of articles that GLX is deprecated, so softly going away should be a
> proper 
> way.
> 
> Or just those bbappends should stay where they are. Another thing is
> that 
> meta-intel layer introduced libva-intel package which also need
> separate 
> bbappend to remove virtual/mesa, this made me to post that patch in
> first 
> place.

Turning it into a PACKAGECONFIG is definitely a good idea and I'm happy
to have a patch to do that. What the defaults should be I'm less sure
about, initially leaving as it is today, maybe discuss changing the
default in a follow up second patch?

Cheers,

Richard

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Bartłomiej Burdukiewicz]

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

On Wed, 28 Apr 2020 10:47:42 CEST Richard Purdie wrote:
> On Tue, 2020-04-28 at 01:09 +0200, Bartłomiej Burdukiewicz wrote:
> > Other media player don't have strong requirements for GLX.
> > 
> > I'm now totally unsure. Probably adding PACKAGECONFIG with glx flag
> > (disabled
> > by default) will be better approach with conditional virtual/mesa
> > dependency.
> > This will fix recursive dependency problem for common cases. There is
> > also ton
> > of articles that GLX is deprecated, so softly going away should be a
> > proper
> > way.
> > 
> > Or just those bbappends should stay where they are. Another thing is
> > that
> > meta-intel layer introduced libva-intel package which also need
> > separate
> > bbappend to remove virtual/mesa, this made me to post that patch in
> > first
> > place.
> 
> Turning it into a PACKAGECONFIG is definitely a good idea and I'm happy
> to have a patch to do that. What the defaults should be I'm less sure
> about, initially leaving as it is today, maybe discuss changing the
> default in a follow up second patch?
> 
> Cheers,
> 
> Richard

Ok sounds reasonable, I'll prepare new patch and do some testing around it.

Thanks,
Bartłomiej 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 499 bytes --]

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Zoltan Boszormenyi]

2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta:
> Mesa can be compiled with libva support, in order to avoid recursive
> dependency between mesa and libva, virtual/mesa must be removed
> from libva recipe.

This is why this patch series was created, to break the
circular dependency in a clean way:
https://patchwork.openembedded.org/series/22976/#

The libva-initial recipe was introduced that doesn't need
mesa, then mesa can be built with vaapi state tracker enabled,
finally libva can be built with dependency on mesa so its
GLX support is enabled.

What happened to it?

Best regards,
Zoltán Böszörményi

> 
> Signed-off-by: Bartłomiej Burdukiewicz <bartlomiej.burdukiewicz@gmail.com>
> ---
>   meta/recipes-graphics/libva/libva_2.6.1.bb | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb b/meta/recipes-graphics/libva/libva_2.6.1.bb
> index 92cea83bc1..c1a441a18b 100644
> --- a/meta/recipes-graphics/libva/libva_2.6.1.bb
> +++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
> @@ -23,7 +23,7 @@ SRC_URI[sha256sum] = "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e4862940
>   
>   UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>   
> -DEPENDS = "libdrm virtual/mesa"
> +DEPENDS = "libdrm"
>   
>   inherit meson pkgconfig features_check
>   
> 
> 
> 
> 

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Bartłomiej Burdukiewicz]

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

On Wednesday, 6 May 2020 14:41:25 CEST Böszörményi Zoltán wrote:
> 2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta:
> > Mesa can be compiled with libva support, in order to avoid recursive
> > dependency between mesa and libva, virtual/mesa must be removed
> > from libva recipe.
> 
> This is why this patch series was created, to break the
> circular dependency in a clean way:
> https://patchwork.openembedded.org/series/22976/#
> 
> The libva-initial recipe was introduced that doesn't need
> mesa, then mesa can be built with vaapi state tracker enabled,
> finally libva can be built with dependency on mesa so its
> GLX support is enabled.
> 
> What happened to it?
> 
> Best regards,
> Zoltán Böszörményi

Was those patches merged upstream?
Never seen them before.

Cheers,
Bartłomiej Burdukiewicz

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 499 bytes --]

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Richard Purdie]

On Wed, 2020-05-06 at 14:41 +0200, Zoltan Boszormenyi via
lists.openembedded.org wrote:
> 2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta:
> > Mesa can be compiled with libva support, in order to avoid
> > recursive
> > dependency between mesa and libva, virtual/mesa must be removed
> > from libva recipe.
> 
> This is why this patch series was created, to break the
> circular dependency in a clean way:
> https://patchwork.openembedded.org/series/22976/#
> 
> The libva-initial recipe was introduced that doesn't need
> mesa, then mesa can be built with vaapi state tracker enabled,
> finally libva can be built with dependency on mesa so its
> GLX support is enabled.
> 
> What happened to it?

I think it came in late during the release and was a bit too risky to
be taken at the time. It think it is a good solution to the problem,
would you be able to rebase the patches and we can queue them for
testing? Its a much better time now to merge a change like that.

Cheers,

Richard

Re: [OE-core] [meta-oe][PATCH] libva: Removed virtual/mesa dependency

[Zoltan Boszormenyi]

2020. 05. 07. 13:48 keltezéssel, Richard Purdie írta:
> On Wed, 2020-05-06 at 14:41 +0200, Zoltan Boszormenyi via
> lists.openembedded.org wrote:
>> 2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta:
>>> Mesa can be compiled with libva support, in order to avoid
>>> recursive
>>> dependency between mesa and libva, virtual/mesa must be removed
>>> from libva recipe.
>>
>> This is why this patch series was created, to break the
>> circular dependency in a clean way:
>> https://patchwork.openembedded.org/series/22976/#
>>
>> The libva-initial recipe was introduced that doesn't need
>> mesa, then mesa can be built with vaapi state tracker enabled,
>> finally libva can be built with dependency on mesa so its
>> GLX support is enabled.
>>
>> What happened to it?
> 
> I think it came in late during the release and was a bit too risky to
> be taken at the time.

I didn't get that impression after the response from Khem Raj:
 >> OK, I guess, we should give it a test.

> It think it is a good solution to the problem,
> would you be able to rebase the patches and we can queue them for
> testing? Its a much better time now to merge a change like that.

I will rebase them, thanks.
Does it have a chance to be backported to 3.1?

> 
> Cheers,
> 
> Richard
> 
> 
> 
>