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
[New] libva-intel-media-driver port
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
# LIMD Port does have room for improvement:
* CMRT lib is disabled due to:
https://github.com/intel/media-driver/pull/819#issuecomment-599480840
* using a nasty patch after configure to fix missing /usr/X11R6
includes and missing -lc LD_FLAG
* Tests are disabled due to causing segfaults, probably cmrtlib?
* c++17 <= is required to triger __ISO_C_VISIBLE <= 2011 for
aligned_malloc in /usr/include/stdlib.h used for
/media_driver/linux/common/os/mos_utilities_specific.h: _aligned_malloc
# igdgmm port:
* Tests are broken
# Result
Compiles in current state
tested with mpv + 4k 70Gb film on 2 core i5-7200u, 4k youtube in mpv works
perfectly also
Additional flags for mpv were:
--enable-vaapi \
--disable-vaapi-drm \ # asks for vt.h
--enable-vaapi-x-egl \
--enable-vaapi-x11 \
I also tested ffmpeg with --enable-vaapi and
LIBavutil_EXTRALIBS=-lm -pthread -L/usr/local/lib -lva-glx -lva-drm -lva-x11
-lva
I'll include a head of a log.
--
Eugene Moz.
ffmpeg started on 2021-02-07 at 19:18:16
Report written to "ffmpeg-20210207-191816.log"
Log level: 48
Command line:
ffmpeg -hide_banner -threads 1 -f x11grab -i :0.0 -vaapi_device /dev/drmR128
-vcodec h264_vaapi -vf "format=nv12|vaapi,hwupload" output.mp4 -report
Splitting the commandline.
Reading option '-hide_banner' ... matched as option 'hide_banner' (do not show
program banner) with argument '1'.
Reading option '-threads' ... matched as AVOption 'threads' with argument '1'.
Reading option '-f' ... matched as option 'f' (force format) with argument
'x11grab'.
Reading option '-i' ... matched as input url with argument ':0.0'.
Reading option '-vaapi_device' ... matched as option 'vaapi_device' (set VAAPI
hardware device (DRM path or X11 display name)) with argument '/dev/drmR128'.
Reading option '-vcodec' ... matched as option 'vcodec' (force video codec
('copy' to copy stream)) with argument 'h264_vaapi'.
Reading option '-vf' ... matched as option 'vf' (set video filters) with
argument 'format=nv12|vaapi,hwupload'.
Reading option 'output.mp4' ... matched as output url.
Reading option '-report' ... matched as option 'report' (generate a report)
with argument '1'.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option hide_banner (do not show program banner) with argument 1.
Applying option vaapi_device (set VAAPI hardware device (DRM path or X11
display name)) with argument /dev/drmR128.
[AVHWDeviceContext @ 0x255396f6cc0] libva: VA-API version 1.10.0
[AVHWDeviceContext @ 0x255396f6cc0] libva: Trying to open
/usr/local/lib/dri/iHD_drv_video.so
[AVHWDeviceContext @ 0x255396f6cc0] libva: Found init function
__vaDriverInit_1_10
[AVHWDeviceContext @ 0x255396f6cc0] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x255396f6cc0] Initialised VAAPI connection: version 1.10
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x41524742 -> bgra.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x42475241 -> argb.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x41424752 -> rgba.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x52474241 -> abgr.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x58524742 -> bgr0.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x42475258 -> 0rgb.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x58424752 -> rgb0.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x52474258 -> 0bgr.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x30335241 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x30334241 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x30335258 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x30334258 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x36314752 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x50424752 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x50524742 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x56555941 -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x30303859 -> gray.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x3231564e -> nv12.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x3132564e -> unknown.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x32595559 -> yuyv422.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x59565955 -> uyvy422.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x32315659 -> yuv420p.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x30323449 -> yuv420p.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x50313134 -> yuv411p.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x48323234 -> yuv422p.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x56323234 -> yuv440p.
[AVHWDeviceContext @ 0x255396f6cc0] Format 0x50343434 -> yuv444p.
