Re: [New] libva-intel-media-driver port
Hopefuly, I'll have some spare time soon. I'll see how best to integrate it. 6.9 is closing on us =) -- Eugene Moz.
Re: [New] libva-intel-media-driver port
On 2021/02/10 21:50, Bryan Steele wrote: > Putting something into ports knowing that it's the wrong place feels > wrong, and will undoubtedly cause friction later when moved to base. Moving from base to ports is a bit more tricky but not impossible. Moving from ports to base is no problem at all.
Re: [New] libva-intel-media-driver port
On Wed, Feb 10, 2021 at 09:50:47PM -0500, Bryan Steele wrote: Hello Bryan, > It's certainly something that would be nice to have, and has been > attempted a few times. Someone just needs to pick up the work that has > been started by others. > > The original ports discussions: > > https://marc.info/?t=15762647571=1=2 > https://marc.info/?t=15758739041=1=2 > > ..when it moved to tech@ to attempt xenocara integration: > > https://marc.info/?t=15767653863=1=2 Thanks for the pointers! I was surprised that just a few weeks ago you were suggesting libva might go into ports ;) Being more serious, I wonder if we can suggest a concrete path to Eugene should he be able and willing to put more time into this? I know that he was looking into upstreaming OpenBSD relevant patches, which is a positive chunk of work to be doing in parallel. However, it's not totally clear to me what he might need to do to get libva and its associated parts (libva-intel-media-driver etc) into xenocara and ports (as appropriate). He may well be much more au fait with these things than I am, but equally, he might not mind more detailed input from people who know more than me! Now that I understand how to use ffmpeg's hardware acceleration better (in particular when the hardware can do both decoding and encoding), I realise I undersold the effect of Eugene's work: on my 5 year old integrated "GPU" OpenBSD desktop, I'm seeing some video tasks running 50x faster than before! I imagine the folks porting OBS to OpenBSD would probably love to take advantage of this :) Laurie
Re: [New] libva-intel-media-driver port
On Tue, Feb 09, 2021 at 01:47:37PM +, Laurence Tratt wrote: > On Tue, Feb 09, 2021 at 10:57:32PM +1100, Jonathan Gray wrote: > > Hello Jonathan, > > > See previous libva discussions. If it is to support more than just Intel > > it needs to be in xenocara and new Mesa Makefiles will need to be written. > > > > That would also be the case to use gallium-va with the iris Mesa driver for > > Intel >= gen8. > > I'm not aware of the previous discussions, but I'm not sure if you're saying > "don't put it in ports" or not? Yes. On AMD graphics (and I guess Intel >= gen8) Mesa needs to be linked with libva, and Mesa is a part of xenocara. Building the base system does not depend on ports. > Even if it means that *only* Intel hardware benefits for the time being, this > port is really very useful and I've been working with Eugene to test his > work. Now that I've got it up and running, it's pretty impressive: for > example, on my OpenBSD machine, ffmpeg video encoding on a test file went > from 6m30 down to 2m20 (also, not coincidentally, moving from fully consuming > all 4 cores at to consuming only a small portion of 1 core). It's certainly something that would be nice to have, and has been attempted a few times. Someone just needs to pick up the work that has been started by others. The original ports discussions: https://marc.info/?t=15762647571=1=2 https://marc.info/?t=15758739041=1=2 ..when it moved to tech@ to attempt xenocara integration: https://marc.info/?t=15767653863=1=2 > If nothing else, support in ports might be a useful stepping stone on the way > to having libva in xenocara which, I imagine, is a rather harder job? > > Laurie Putting something into ports knowing that it's the wrong place feels wrong, and will undoubtedly cause friction later when moved to base. -Bryan.
Re: [New] libva-intel-media-driver port
On 21/02/09 11:08AM, Stuart Henderson wrote:
> Quick comments from a read-through, I have not tried building:
>
>
> ports fetching from github /archive/ URLs should use GH_* variables
> not MASTER_DISTES - see ports/infrastructure/Makefile.template
>
> the patches directory should be generated with "make update-patches",
> don't split patches between patches/ and files/
>
> DESCR should describe what it does and should not just be a copy
> of COMMENT
>
> leave out MAINTAINER completely if you aren't going to set it to
> yourself
>
> the library should be generated directly with ports versioning,
> no symlinks
>
> instead of setting PORT_LIB_MAJOR/PORT_LIB_MINOR, take it from
> the SHARED_LIBS setting by using ${LIBigdgmm_VERSION:R} for major
> and ${LIBigdgmm_VERSION:E} for minor
>
> see other ports or Makefile.template for the expected style
> for CONFIGURE_ARGS / LIB_DEPENDS (one per line) and WANTLIB
> (not one per line), don't use "c++" in WANTLIB that is covered
> by COMPILER_LIBCXX, there is no such thing as COMPILER_LIBC
>
I have revamped both igdgmm and libva-intel-media-driver ports.
Please do see, if they are satisfactory.
--
Eugene Moz.
igdgmm.tar.gz
Description: Binary data
libva-intel-media-driver.tar.gz
Description: Binary data
Re: [New] libva-intel-media-driver port
On Tue, Feb 09, 2021 at 10:57:32PM +1100, Jonathan Gray wrote: Hello Jonathan, > See previous libva discussions. If it is to support more than just Intel > it needs to be in xenocara and new Mesa Makefiles will need to be written. > > That would also be the case to use gallium-va with the iris Mesa driver for > Intel >= gen8. I'm not aware of the previous discussions, but I'm not sure if you're saying "don't put it in ports" or not? Even if it means that *only* Intel hardware benefits for the time being, this port is really very useful and I've been working with Eugene to test his work. Now that I've got it up and running, it's pretty impressive: for example, on my OpenBSD machine, ffmpeg video encoding on a test file went from 6m30 down to 2m20 (also, not coincidentally, moving from fully consuming all 4 cores at to consuming only a small portion of 1 core). If nothing else, support in ports might be a useful stepping stone on the way to having libva in xenocara which, I imagine, is a rather harder job? Laurie
Re: [New] libva-intel-media-driver port
On Tue, Feb 09, 2021 at 11:08:15AM +, Stuart Henderson wrote:
> Quick comments from a read-through, I have not tried building:
>
>
> ports fetching from github /archive/ URLs should use GH_* variables
> not MASTER_DISTES - see ports/infrastructure/Makefile.template
>
> the patches directory should be generated with "make update-patches",
> don't split patches between patches/ and files/
>
> DESCR should describe what it does and should not just be a copy
> of COMMENT
>
> leave out MAINTAINER completely if you aren't going to set it to
> yourself
>
> the library should be generated directly with ports versioning,
> no symlinks
>
> instead of setting PORT_LIB_MAJOR/PORT_LIB_MINOR, take it from
> the SHARED_LIBS setting by using ${LIBigdgmm_VERSION:R} for major
> and ${LIBigdgmm_VERSION:E} for minor
>
> see other ports or Makefile.template for the expected style
> for CONFIGURE_ARGS / LIB_DEPENDS (one per line) and WANTLIB
> (not one per line), don't use "c++" in WANTLIB that is covered
> by COMPILER_LIBCXX, there is no such thing as COMPILER_LIBC
See previous libva discussions. If it is to support more than just
Intel it needs to be in xenocara and new Mesa Makefiles will need to be
written.
That would also be the case to use gallium-va with the iris
Mesa driver for Intel >= gen8.
Re: [New] libva-intel-media-driver port
On 21/02/09 11:08, Stuart Henderson wrote:
> Quick comments from a read-through, I have not tried building:
>
>
> ports fetching from github /archive/ URLs should use GH_* variables
> not MASTER_DISTES - see ports/infrastructure/Makefile.template
>
> the patches directory should be generated with "make update-patches",
> don't split patches between patches/ and files/
>
> DESCR should describe what it does and should not just be a copy
> of COMMENT
>
> leave out MAINTAINER completely if you aren't going to set it to
> yourself
>
> the library should be generated directly with ports versioning,
> no symlinks
>
> instead of setting PORT_LIB_MAJOR/PORT_LIB_MINOR, take it from
> the SHARED_LIBS setting by using ${LIBigdgmm_VERSION:R} for major
> and ${LIBigdgmm_VERSION:E} for minor
>
> see other ports or Makefile.template for the expected style
> for CONFIGURE_ARGS / LIB_DEPENDS (one per line) and WANTLIB
> (not one per line), don't use "c++" in WANTLIB that is covered
> by COMPILER_LIBCXX, there is no such thing as COMPILER_LIBC
>
Thank you, for following up. Still learning ports, now that I know that
it builds, time to make it right. I could be a mantainer, if nobody else
wants the pleasure.
P.S. sorry for double, forgot to set cc
--
Eugene Moz.
signature.asc
Description: PGP signature
Re: [New] libva-intel-media-driver port
Quick comments from a read-through, I have not tried building:
ports fetching from github /archive/ URLs should use GH_* variables
not MASTER_DISTES - see ports/infrastructure/Makefile.template
the patches directory should be generated with "make update-patches",
don't split patches between patches/ and files/
DESCR should describe what it does and should not just be a copy
of COMMENT
leave out MAINTAINER completely if you aren't going to set it to
yourself
the library should be generated directly with ports versioning,
no symlinks
instead of setting PORT_LIB_MAJOR/PORT_LIB_MINOR, take it from
the SHARED_LIBS setting by using ${LIBigdgmm_VERSION:R} for major
and ${LIBigdgmm_VERSION:E} for minor
see other ports or Makefile.template for the expected style
for CONFIGURE_ARGS / LIB_DEPENDS (one per line) and WANTLIB
(not one per line), don't use "c++" in WANTLIB that is covered
by COMPILER_LIBCXX, there is no such thing as COMPILER_LIBC
Re: [New] libva-intel-media-driver port
On 21/02/08 11:27PM, Eugene Moz. wrote:
> On 21/02/07 07:42PM, Eugene Moz. wrote:
> > Hello.
> > Here's the libva-intel-media-driver that I ported, it requires igdgmm
> > library which I also ported.
> > This work is based on this:
> > https://github.com/intel/media-driver/pull/819
> > I include thy ports:
> > multimedia/libva-2.10.0 # LIMD-21 requires at least 2.8.0
> > multimedia/libva-utils-2.10.0 # with vainfo utility
> > multimedia/igdgmm-20.4.1 # latest atm, required for LIMD
> > multimedia/libva-intel-media-driver-21.1.1 # latest atm
>
> Hello,
> As someone mentioned, I forgot to tweak MASTER_SITES in
> multimedia/igdgmm/Makefile
> Please do change Makefile as so, should be fine now.
> See attached patch.
> --
> Eugene Moz.
> --- Makefile.orig Mon Feb 8 23:16:59 2021
> +++ Makefile Mon Feb 8 23:26:34 2021
> @@ -6,8 +6,8 @@
> DISTNAME = intel-gmmlib-${V}
>
> CATEGORIES = multimedia
> -HOMEPAGE = https://github.com/intel/gmmlib/
> -MASTER_SITES = https://github.com/jbeich/gmmlib/archive/
> +HOMEPAGE = https://github.com/intel/gmmlib/
> +MASTER_SITES = https://github.com/intel/gmmlib/archive/
> MAINTAINER = example example
>
> IGDGMM_LIB_MAJOR = 20
Here's the updated builds, with solved hacky after-configure patch
problem
Should now build fine.
--
Eugene Moz.
igdgmm.tar.gz
Description: Binary data
libva-intel-media-driver.tar.gz
Description: Binary data
Re: [New] libva-intel-media-driver port
On 21/02/07 07:42PM, Eugene Moz. wrote:
> Hello.
> Here's the libva-intel-media-driver that I ported, it requires igdgmm
> library which I also ported.
> This work is based on this:
> https://github.com/intel/media-driver/pull/819
> I include thy ports:
> multimedia/libva-2.10.0 # LIMD-21 requires at least 2.8.0
> multimedia/libva-utils-2.10.0 # with vainfo utility
> multimedia/igdgmm-20.4.1 # latest atm, required for LIMD
> multimedia/libva-intel-media-driver-21.1.1 # latest atm
Hello,
As someone mentioned, I forgot to tweak MASTER_SITES in
multimedia/igdgmm/Makefile
Please do change Makefile as so, should be fine now.
See attached patch.
--
Eugene Moz.
--- Makefile.orig Mon Feb 8 23:16:59 2021
+++ MakefileMon Feb 8 23:26:34 2021
@@ -6,8 +6,8 @@
DISTNAME = intel-gmmlib-${V}
CATEGORIES = multimedia
-HOMEPAGE = https://github.com/intel/gmmlib/
-MASTER_SITES = https://github.com/jbeich/gmmlib/archive/
+HOMEPAGE = https://github.com/intel/gmmlib/
+MASTER_SITES = https://github.com/intel/gmmlib/archive/
MAINTAINER = example example
IGDGMM_LIB_MAJOR = 20
