| View previous topic :: View next topic |
| Author |
Message |
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
 Posted: Mon Dec 17, 2018 9:59 am Post subject: Using Intel i965 for VAAPI and use nvidia-driver for GLX |
 |
|
I have an Intel 8086k and an Nvidia GTX 1080. I've fully configured my nvidia-drivers with everything working properly. I am wondering if it is still possible for me to take advantage of the unused Intel Quicksync through VAAPI? When I look in my dmesg output, I see nothing Intel graphics related in there. It's like the hardware is unavailable to me once the Nvidia card took over from BIOS bootup. Or am I just missing the entire kernel configuration for i965?
I know I have NVENC available to me, but the encoding bitrates for NVENC are rather high when I compare it to software x264 encoding for visually similar outputs. I just want to try out VAAPI/Quicksync and see if there's any differences.
_________________
John5788 |
|
| Back to top |
|
 |
Dwosky
Tux's lil' helper
Joined: 07 Nov 2018
Posts: 141
|
| Posted: Mon Dec 17, 2018 3:30 pm Post subject: |
|
|
| What's the output of lspci? Do you see one or two VGA devices? |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Mon Dec 17, 2018 5:02 pm Post subject: |
|
|
lspci only shows me one VGA device:
| Code: |
$ lspci | grep -i vga
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080] (rev a1)
|
Do I need a dummy HDMI/DP plug on the integrated graphics connector on my motherboard for it to show up? Something like this https://www.amazon.com/CompuLab-fit-Headless-Display-Emulator/dp/B00FLZXGJ6 ?
_________________
John5788 |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Mon Dec 17, 2018 6:13 pm Post subject: |
|
|
I looked around in the BIOS and found a setting: iGPU Multi-Monitor support. I enabled this and now I get i915 device mentioned in my dmesg and a new line in my lspci output:
| Code: |
$ lspci
00:02.0 Display controller: Intel Corporation Device 3e92
|
| Code: |
[ 0.795468] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[ 0.796716] i915 0000:00:02.0: enabling device (0000 -> 0003)
[ 0.796845] WARN_ON(!((dev_priv)->info.platform == INTEL_SKYLAKE) && !((dev_priv)->info.platform == INTEL_KABYLAKE))
[ 0.796851] ------------[ cut here ]------------
[ 0.796888] WARNING: CPU: 5 PID: 1 at drivers/gpu/drm/i915/i915_drv.c:242 intel_detect_pch+0x58d/0x7d0
[ 0.796909] Modules linked in:
[ 0.796918] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.14.83-gentoo #1
[ 0.796933] Hardware name: System manufacturer System Product Name/ROG MAXIMUS X CODE, BIOS 1704 09/14/2018
[ 0.796954] task: ffff9a97b7de4040 task.stack: ffffa99ec0028000
[ 0.797642] RIP: 0010:intel_detect_pch+0x58d/0x7d0
[ 0.797642] RSP: 0000:ffffa99ec002bd50 EFLAGS: 00010282
[ 0.797642] RAX: 0000000000000068 RBX: ffff9a97b6d76000 RCX: 0000000000000000
[ 0.797642] RDX: 0000000000000001 RSI: 0000000000000046 RDI: 00000000ffffffff
[ 0.797642] RBP: ffff9a97b5590000 R08: 0000000000000002 R09: 0000000000000233
[ 0.797642] R10: ffff9a97b7463080 R11: 0016ed09c86f9abc R12: ffff9a97b6d5b000
[ 0.797642] R13: ffffffffa88abfe0 R14: ffffffffa88abc80 R15: 0000000000000000
[ 0.797642] FS: 0000000000000000(0000) GS:ffff9a97be340000(0000) knlGS:0000000000000000
[ 0.797642] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.797642] CR2: 0000000000000000 CR3: 00000009dce0a001 CR4: 00000000003606e0
[ 0.797642] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.797642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.797642] Call Trace:
[ 0.797642] i915_driver_load+0x341/0xe50
[ 0.797642] ? preempt_count_sub+0x5/0xa0
[ 0.797642] ? _raw_spin_unlock_irqrestore+0x22/0x40
[ 0.797642] pci_device_probe+0xcd/0x150
[ 0.797642] driver_probe_device+0x2ed/0x430
[ 0.797642] ? set_debug_rodata+0x11/0x11
[ 0.797642] __driver_attach+0xa0/0xe0
[ 0.797642] ? driver_probe_device+0x430/0x430
[ 0.797642] ? driver_probe_device+0x430/0x430
[ 0.797642] bus_for_each_dev+0x5e/0x90
[ 0.797642] bus_add_driver+0x1c2/0x260
[ 0.797642] ? mipi_dsi_bus_init+0x11/0x11
[ 0.797642] driver_register+0x57/0xc0
[ 0.797642] ? mipi_dsi_bus_init+0x11/0x11
[ 0.797642] do_one_initcall+0x4e/0x190
[ 0.797642] kernel_init_freeable+0x181/0x208
[ 0.797642] ? rest_init+0xc0/0xc0
[ 0.797642] kernel_init+0xa/0x100
[ 0.797642] ret_from_fork+0x3a/0x50
[ 0.797642] Code: a8 e8 18 fe fd ff 8b 85 28 06 00 00 83 e8 16 83 e0 fd 0f 84 b8 fb ff ff 48 c7 c6 b8 19 b0 a8 48 c7 c7 cf 33 ab a8 e8 1e 01 be ff <0f> 0b e9 9e fb ff ff c7 85 c0 36 00 00 06 00 00 00 48 c7 c2 f3
[ 0.797642] ---[ end trace 3da8d60c01f3fec9 ]---
[ 0.821366] [drm] Memory usable by graphics device = 4096M
[ 0.821967] checking generic (d1000000 7e9000) vs hw (b0000000 10000000)
[ 0.821967] [drm] Replacing VGA console driver
[ 0.828356] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 0.828961] [drm] Driver supports precise vblank timestamp query.
[ 0.834049] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_01.bin failed with error -2
[ 0.834676] i915 0000:00:02.0: Failed to load DMC firmware [https://01.org/linuxgraphics/downloads/firmware], disabling runtime power management.
[ 1.108975] [drm] failed to retrieve link info, disabling eDP
[ 1.111319] [drm] Initialized i915 1.6.0 20170818 for 0000:00:02.0 on minor 0
|
It seems a little bit buggy though on gentoo-sources-4.14.83. After GRUB boots the kernel and loads a few modules, my screen blanks and goes black, then comes back right before XDM starts, so I miss the entire bootup sequence visually. I think the dmesg errors have something to do with that.
_________________
John5788 |
|
| Back to top |
|
|
ali3nx
l33t
Joined: 21 Sep 2003
Posts: 732
Location: Winnipeg, Canada
|
| Posted: Mon Dec 17, 2018 6:15 pm Post subject: |
|
|
Something i've done with gentoo and several intel skylake and kaby lake based pc builds i use for gpu computing is to force enable igpu multi mode in uefi bios config and that will keep the intel igpu enabled even if you have pci express graphics card connected to the motherboard.
My gpu miner builds required this because the nvidia gpu's were hung from zip ties on a wire rack and the graphics ports as a result are inaccessible. if i wanted to use a local console the igpu was the only avenue to accomplish that. I suspect the same method could be used to have the igpu still be enabled even if your using the nvidia gpu as the primary display device.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper! |
|
| Back to top |
|
|
ali3nx
l33t
Joined: 21 Sep 2003
Posts: 732
Location: Winnipeg, Canada
|
| Posted: Mon Dec 17, 2018 6:22 pm Post subject: |
|
|
| John5788 wrote: | I looked around in the BIOS and found a setting: iGPU Multi-Monitor support. I enabled this and now I get i915 device mentioned in my dmesg and a new line in my lspci output:
| Code: |
$ lspci
00:02.0 Display controller: Intel Corporation Device 3e92
|
| Code: |
[ 0.795468] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3
[ 0.796716] i915 0000:00:02.0: enabling device (0000 -> 0003)
[ 0.796845] WARN_ON(!((dev_priv)->info.platform == INTEL_SKYLAKE) && !((dev_priv)->info.platform == INTEL_KABYLAKE))
[ 0.796851] ------------[ cut here ]------------
[ 0.796888] WARNING: CPU: 5 PID: 1 at drivers/gpu/drm/i915/i915_drv.c:242 intel_detect_pch+0x58d/0x7d0
[ 0.796909] Modules linked in:
[ 0.796918] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.14.83-gentoo #1
[ 0.796933] Hardware name: System manufacturer System Product Name/ROG MAXIMUS X CODE, BIOS 1704 09/14/2018
[ 0.796954] task: ffff9a97b7de4040 task.stack: ffffa99ec0028000
[ 0.797642] RIP: 0010:intel_detect_pch+0x58d/0x7d0
[ 0.797642] RSP: 0000:ffffa99ec002bd50 EFLAGS: 00010282
[ 0.797642] RAX: 0000000000000068 RBX: ffff9a97b6d76000 RCX: 0000000000000000
[ 0.797642] RDX: 0000000000000001 RSI: 0000000000000046 RDI: 00000000ffffffff
[ 0.797642] RBP: ffff9a97b5590000 R08: 0000000000000002 R09: 0000000000000233
[ 0.797642] R10: ffff9a97b7463080 R11: 0016ed09c86f9abc R12: ffff9a97b6d5b000
[ 0.797642] R13: ffffffffa88abfe0 R14: ffffffffa88abc80 R15: 0000000000000000
[ 0.797642] FS: 0000000000000000(0000) GS:ffff9a97be340000(0000) knlGS:0000000000000000
[ 0.797642] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.797642] CR2: 0000000000000000 CR3: 00000009dce0a001 CR4: 00000000003606e0
[ 0.797642] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.797642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.797642] Call Trace:
[ 0.797642] i915_driver_load+0x341/0xe50
[ 0.797642] ? preempt_count_sub+0x5/0xa0
[ 0.797642] ? _raw_spin_unlock_irqrestore+0x22/0x40
[ 0.797642] pci_device_probe+0xcd/0x150
[ 0.797642] driver_probe_device+0x2ed/0x430
[ 0.797642] ? set_debug_rodata+0x11/0x11
[ 0.797642] __driver_attach+0xa0/0xe0
[ 0.797642] ? driver_probe_device+0x430/0x430
[ 0.797642] ? driver_probe_device+0x430/0x430
[ 0.797642] bus_for_each_dev+0x5e/0x90
[ 0.797642] bus_add_driver+0x1c2/0x260
[ 0.797642] ? mipi_dsi_bus_init+0x11/0x11
[ 0.797642] driver_register+0x57/0xc0
[ 0.797642] ? mipi_dsi_bus_init+0x11/0x11
[ 0.797642] do_one_initcall+0x4e/0x190
[ 0.797642] kernel_init_freeable+0x181/0x208
[ 0.797642] ? rest_init+0xc0/0xc0
[ 0.797642] kernel_init+0xa/0x100
[ 0.797642] ret_from_fork+0x3a/0x50
[ 0.797642] Code: a8 e8 18 fe fd ff 8b 85 28 06 00 00 83 e8 16 83 e0 fd 0f 84 b8 fb ff ff 48 c7 c6 b8 19 b0 a8 48 c7 c7 cf 33 ab a8 e8 1e 01 be ff <0f> 0b e9 9e fb ff ff c7 85 c0 36 00 00 06 00 00 00 48 c7 c2 f3
[ 0.797642] ---[ end trace 3da8d60c01f3fec9 ]---
[ 0.821366] [drm] Memory usable by graphics device = 4096M
[ 0.821967] checking generic (d1000000 7e9000) vs hw (b0000000 10000000)
[ 0.821967] [drm] Replacing VGA console driver
[ 0.828356] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 0.828961] [drm] Driver supports precise vblank timestamp query.
[ 0.834049] i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_01.bin failed with error -2
[ 0.834676] i915 0000:00:02.0: Failed to load DMC firmware [https://01.org/linuxgraphics/downloads/firmware], disabling runtime power management.
[ 1.108975] [drm] failed to retrieve link info, disabling eDP
[ 1.111319] [drm] Initialized i915 1.6.0 20170818 for 0000:00:02.0 on minor 0
|
It seems a little bit buggy though on gentoo-sources-4.14.83. After GRUB boots the kernel and loads a few modules, my screen blanks and goes black, then comes back right before XDM starts, so I miss the entire bootup sequence visually. I think the dmesg errors have something to do with that. |
Just to follow up on my previous comment the inteldrmfb framebuffer driver with 8th gen intel cpu's is only supported with Linux 4.18 or newer. 4.19.x definitely works however.
https://forums.gentoo.org/viewtopic-p-8281730.html#8281730
You'll likely also require the intel igpu DMC power management firmware compiled into your kernel binary and that firmware file is provided by linux-firmware.
| Code: | | Direct firmware load for i915/kbl_dmc_ver1_01.bin failed with error |
Strange how helping someone with a similar issue manifested twice within the time span of half a day 
https://www.reddit.com/r/linux4noobs/comments/a70so0/laptop_questions_trying_to_decide_if_i_should_or/ebzf9bf/
tdr from the #gentoo irc channel helped with some kernel config testing for the system that i was trying to resolve the black screen issue and the kernel config that worked best had the i915 driver configured as a kernel module rather than compiled into the kernel binary. the dmc power management firmware being compiled into the kernel binary however still appeared to be a benefit.
Something you might want to check for and ensure your using is uefi bios config with launch csm and fast boot disabled or there's a high chance the nvidia graphics driver will not function properly and print a VGA console corruption warning to dmesg. if the nvidia driver initializes with legacy bios compat and the intel graphics chipset doesn't things might not be stable.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper! |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Mon Dec 17, 2018 7:08 pm Post subject: |
|
|
Hi ali3nx,
I built the kbl_dmc_ver1_01.bin blob into my kernel and it looks like the error about failing to load firmware has cleared. However, I am still getting black screen during the bootup process. It's strange to me that this happens since I don't have any displays connected to the integrated graphics device. I am using nvidia-drm.modeset=1 on my kernel boot options and this has been working well. It's only since I enabled iGPU Multi Monitor support in BIOS that I have started experiencing it.
It's not the entire bootup sequence blacked out. After GRUB loads and boots the kernel, I get a couple of seconds where I can see stuff loading, then I believe the kernel modules start to autoload and my screen goes blank until right before XDM loads. I can see what output I missed for about maybe 1 second before XDM starts up and I lose visibility on any potential error messages during bootup sequence.
I'll try building i915 as a kernel module instead of compiled in and see if that makes any difference. Maybe even upgrading to a newer kernel too then as a last resort. It doesn't really bother me since I wind up at the login screen anyway, but it just masks potential bootup errors I will miss because my screen is blanked out.
_________________
John5788 |
|
| Back to top |
|
|
ali3nx
l33t
Joined: 21 Sep 2003
Posts: 732
Location: Winnipeg, Canada
|
| Posted: Mon Dec 17, 2018 7:14 pm Post subject: |
|
|
| John5788 wrote: | | Maybe even upgrading to a newer kernel too then as a last resort. |
You will likely have many problems with linux 4.14. upgrading to the newest available 4.19.x kernel and testing that i'm confident would produce much different or improved results. any kernel version older than 4.18 would not display the intel framebuffer on my gpu compute node.
Something to keep in mind is my setup on that pc build i'm using the nvidia graphics as secondary display devices and the intel dvi port with an old spare lcd panel as the primary display device. i've not attempted to test the setup "the other way around" but i suspect if the intel graphics chipset is not supported by the kernel your using things will just misbehave.
The xorg config with my gpu compute node setup i had to code by hand and so that the first display device in xorg.conf that was loaded would be the primary display device desired to display a login console. this was also necessary for being able to control the gpu fans at boot since nvidia-smi requires an x server instance to function and a prerequisite of nvidia-smi functioning from a bash script was having the nvidia Coolbits fan control and overclocking directive active before the fan control bash script executed. Perhaps some useful reference from my xorg.conf file you could use for setup testing.
This xorg config is from a test bench system that only had one nvidia gpu but the concept should be obvious. if xorg or the kernel initialization is autodetecting the incorrect display device first and attempting to assign the primary display to the intel gpu you may just see a black screen on the nvidia gpu.
https://paste.pound-python.org/show/FRV1lH6c0gfGrBkap9zD/
| John5788 wrote: | | I am using nvidia-drm.modeset=1 on my kernel boot options |
I've never had to do this with gentoo but perhaps there's a reason why your hardware or kernel config requires or benefits from doing so.
| John5788 wrote: | | I'll try building i915 as a kernel module instead of compiled in and see if that makes any difference |
Using a module for the i915 driver likely would be best for this use case scenrio as kernel image included driver code will typically always initialize first. Considering the nvidia driver will be a module the graphics subsystem initialization preference with i915 compiled into the kernel binary might struggle to figure things out if your attempting to use the nvidia gpu as the primary display device.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper! |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Mon Dec 17, 2018 9:20 pm Post subject: |
|
|
Loading the i915 driver as a module does change the bootup behavior for me. The screen doesn't blank until much later and I can see more things before it blanks and goes to XDM. I'm ok with this for now, I'll deal with it more later if there are problems.
Now, moving onto the VAAPI problems. I've appended "intel i965" to my VIDEO_CARDS in /etc/portage/make.conf
| Code: | VIDEO_CARDS="nvidia intel i965"
|
and I re-emerged world with changed use flags. This brought in a new libva-intel-driver dependency as well as rebuilding a few other packages. After rebooting with this new setup, I try to invoke vainfo to query the Intel hardware decoder and get this:
| Code: | $ LIBVA_DRIVER_NAME=i965 vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: User requested driver 'i965'
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
vainfo: /var/tmp/portage/x11-libs/libva-intel-driver-1.7.3/work/intel-vaapi-driver-1.7.3/src/intel_driver.c:106: intel_driver_init: Assertion `VA_CHECK_DRM_AUTH_TYPE(ctx, VA_DRM_AUTH_DRI1) || VA_CHECK_DRM_AUTH_TYPE(ctx, VA_DRM_AUTH_DRI2) || VA_CHECK_DRM_AUTH_TYPE(ctx, VA_DRM_AUTH_CUSTOM)' failed.
Aborted
|
Using VDPAU/nvidia, I can query just fine:
| Code: | $ LIBVA_DRIVER_NAME=vdpau vainfo
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib64/va/drivers/vdpau_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG4Simple : VAEntrypointVLD
VAProfileMPEG4AdvancedSimple : VAEntrypointVLD
VAProfileH264Baseline : VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD |
I do see my Intel card in /dev/dri:
| Code: | $ ls /dev/dri/
total 0
drwxr-xr-x 3 root root 140 Dec 17 11:38 .
drwxr-xr-x 22 root root 4400 Dec 17 11:38 ..
drwxr-xr-x 2 root root 120 Dec 17 11:38 by-path
crw-rw----+ 1 root video 226, 0 Dec 17 11:38 card0
crw-rw----+ 1 root video 226, 1 Dec 17 11:38 card1
crw-rw---- 1 root video 226, 128 Dec 17 11:38 renderD128
crw-rw---- 1 root video 226, 129 Dec 17 11:38 renderD129 |
| Code: | # cat /sys/kernel/debug/dri/128/name
i915 dev=0000:00:02.0 unique=0000:00:02.0
# cat /sys/kernel/debug/dri/129/name
nvidia-drm dev=0000:01:00.0 unique=0000:01:00.0
|
Not sure why vainfo isn't working with the i915 driver.
_________________
John5788 |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Mon Dec 17, 2018 10:40 pm Post subject: |
|
|
I tried updating to libva-2.3.0 and it looks like things just got worse as VDPAU is no longer working:
| Code: | $ LIBVA_DRIVER_NAME=vdpau vainfo
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib64/va/drivers/vdpau_drv_video.so
libva error: /usr/lib64/va/drivers/vdpau_drv_video.so has no function __vaDriverInit_1_0
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
$ LIBVA_DRIVER_NAME=i965 vainfo
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'i965'
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva error: /usr/lib64/va/drivers/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit |
_________________
John5788 |
|
| Back to top |
|
|
ali3nx
l33t
Joined: 21 Sep 2003
Posts: 732
Location: Winnipeg, Canada
|
| Posted: Mon Dec 17, 2018 10:46 pm Post subject: |
|
|
| John5788 wrote: | I tried updating to libva-2.3.0 and it looks like things just got worse as VDPAU is no longer working:
| Code: | $ LIBVA_DRIVER_NAME=vdpau vainfo
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'vdpau'
libva info: Trying to open /usr/lib64/va/drivers/vdpau_drv_video.so
libva error: /usr/lib64/va/drivers/vdpau_drv_video.so has no function __vaDriverInit_1_0
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
$ LIBVA_DRIVER_NAME=i965 vainfo
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'i965'
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva error: /usr/lib64/va/drivers/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit |
|
This issue may or may not have something to do with one of the gentoo xorg dev's changing the mesa ebuilds recently but it's certainly worth some more detailed investigation.
https://forums.gentoo.org/viewtopic-t-1089598-highlight-.html
You may also still require the i915 xorg driver in addition to the i965 driver and it's possible if you still haven't upgraded to 4.19 that also may be responsible for the libva failure.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper! |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Tue Dec 18, 2018 1:44 am Post subject: |
|
|
I'm still on 4.14, waiting on last resort to upgrade to 4.19. I don't really like unmasking gentoo-sources because a lot of times the ~keyword ebuilds just get removed from portage and forces me to find another unstable version to update to, even though I was perfectly fine on whatever version I was on before. I'd rather wait for 4.19 to be marked stable, hope that comes soon.
Anyway, I did some more looking around and I found this command to run, which looks like I have working vaapi?
| Code: |
$ vainfo --display drm --device /dev/dri/renderD128
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.3 (libva 2.3.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake - 2.2.0
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileH264MultiviewHigh : VAEntrypointVLD
VAProfileH264MultiviewHigh : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileH264StereoHigh : VAEntrypointEncSlice
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointEncSlice
VAProfileVP9Profile2 : VAEntrypointVLD |
I'm not sure how this is different from the way I was calling it before with setting the env variable.
But calling out /dev/dri/renderD129 still doesn't let me access VDPAU/nvidia from VAAPI:
| Code: | $ vainfo --display drm --device /dev/dri/renderD129
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
vaInitialize failed with error code -1 (unknown libva error),exit
$ vainfo
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/nvidia_drv_video.so
libva error: /usr/lib64/va/drivers/nvidia_drv_video.so has no function __vaDriverInit_1_0
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
|
Maybe I need newer nvidia-drivers? Otherwise this just means I don't get VDPAU from VAAPI, which I might not be too bummed about if I can use Intel instead.
_________________
John5788 |
|
| Back to top |
|
|
ali3nx
l33t
Joined: 21 Sep 2003
Posts: 732
Location: Winnipeg, Canada
|
| Posted: Tue Dec 18, 2018 2:40 am Post subject: |
|
|
Ultimately if the graphics card drivers lack hardware support the results you get from functionality testing will be inconclusive.
The current stable nvidia drivers do support a 1080 perfectly fine however but if your using uefi boot that issue i previously mentioned regarding the fast boot and launch csm bios config for nvidia drivers is important. alternatively if your not using uefi boot with such a new motherboard that could also be a source of complications or hardware misbehaving.
Within the time span of a couple years that i've been crypto mining or gpu computing one person i helped from reddit that had a pc hardware problem with graphics cards not being usable or even showing up in a fresh win 10 OS install despite clearly being connected to the motherboard and powered the reason why that happened was the OS install was not installed with uefi boot active.
Reinstalling with uefi correctly configured immediately fixed the problem. I mostly mention this because i'm aware many people still prefer to install gentoo without uefi boot but doing that with very new pc hardware can be a source of hardware misbehaving in general.
| John5788 wrote: | | I'm still on 4.14, waiting on last resort to upgrade to 4.19. I don't really like unmasking gentoo-sources because a lot of times the ~keyword ebuilds just get removed from portage and forces me to find another unstable version to update to |
I also prefer the stable drivers so that new sources don't get pulled in with every update but some clever package keywording may help avoid that being as much of an annoyance. for a test to see if it would change the test results it may be worth a temporary kernel upgrade. you can always remove the "new" kernel version entirely if the upgrade doesn't change the results or improve system behavior.
4.19 completely fixed any problems i was experiencing with the intel graphics chipset not working correctly but despite the config working i still get a backtrace from efifb when booting that system so driver version upgrades can make an enormous difference.
https://forums.gentoo.org/viewtopic-p-8275204.html#8275204
As for the differences with how vdpau or vaapi are functioning and the inconsistencies software side your seeing it's curious but to be honest i've never deliberately used nvenc or vaapi on gentoo despite owning hardware capable of using both and generally understanding the configuration requirements for building software to support both.
That mentioned the changes to the mesa ebuild with mesa 18.2.x vs i think it was mesa 18.1.x conditional videocard environment checks changed a lot of significant avenues for mesa to support vdpau, vaapi, gallium and vulkan all at the same time. the new ebuild for some reason was changed to force software support to be xorg driver hardware dependent rather than permitting mesa to be built as you see fit.
There may be some history in the git log that shows those changes and a diff view between the ebuilds but i'm honestly not that adept at using gitweb to find the old mesa ebuilds.
https://gitweb.gentoo.org/repo/gentoo.git/log/media-libs/mesa?showmsg=1
Those ebuild changes were apparently done to make the maintaining mesa more manageable but how those changes effected mesa or gpu hardware rendering that may rely on mesa being built a certain way functioning i'm not entirely clear on.
The hardware issues i experienced attempting to fix my black screen issue with the inteldrmfb driver and intel i915 with that pc build i own are likely very similar and the things tested to resolve it would likely be good first steps to check off a diagnostic todo list for anyone that has a similar problem with a newer kaby lake 8th gen intel system attempting to use the igpu.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper! |
|
| Back to top |
|
|
John5788
Advocate
Joined: 06 Apr 2004
Posts: 2140
Location: 127.0.0.1
|
| Posted: Tue Dec 18, 2018 5:21 am Post subject: |
|
|
| ali3nx wrote: |
I also prefer the stable drivers so that new sources don't get pulled in with every update but some clever package keywording may help avoid that being as much of an annoyance. for a test to see if it would change the test results it may be worth a temporary kernel upgrade. you can always remove the "new" kernel version entirely if the upgrade doesn't change the results or improve system behavior. |
It's not that I unmask on gentoo-sources-*, I only unmask a specific version at a time. The problem is when that version gets removed from portage because it was never going to be a candidate for stable anyway, emerge --depclean will ask to prune the package everytime until I move to a new version that is in the portage tree.
But my problem I think it has to do with x11-libs/libva-vdpau-driver being out of date. I've filed a bug report here: https://bugs.gentoo.org/673376
When I do a query for who owns the nvidia_drv_video.so driver file that is failing to initialize:
| Code: | $ equery belongs /usr/lib64/va/drivers/nvidia_drv_video.so
* Searching for /usr/lib64/va/drivers/nvidia_drv_video.so ...
x11-libs/libva-vdpau-driver-0.7.4-r4 (/usr/lib64/va/drivers/vdpau_drv_video.so)
x11-libs/libva-vdpau-driver-0.7.4-r4 (/usr/lib64/va/drivers/nvidia_drv_video.so -> vdpau_drv_video.so) |
It looks like it belongs to an older libva-vdpau-driver-0.7.4-r4 rather than nvidia-drivers. A search on Google brought me to Debian's bug tracker where I found someone else with the same problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881358 and the solution was to update to libva-vdpau-driver-0.7.4-7. Hopefully my bug report will version bump this package to the latest version and I can try again. This bug won't be a big deal for me since I only wanted to use VAAPI with the i965 driver, which it seems to be working. I'll test an encode shortly after I figure out the syntax to direct encode requests to /dev/dri/renderD128.
Update: VAAPI encoding/decoding via i965 works. Found some ffmpeg example command to run off the official website and gave it a go:
| Code: | $ ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi output.mp4
..SNIP...
libva info: VA-API version 1.3.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_3
libva info: va_openDriver() returns 0
..SNIP...
Stream mapping:
Stream #0:1 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
Stream #0:0 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mp4, to 'output.mp4':
Metadata:
encoder : Lavf57.71.100
Stream #0:0(eng): Video: h264 (h264_vaapi) (High) ([33][0][0][0] / 0x0021), vaapi_vld, 1280x720 [SAR 1:1 DAR 16:9], q=0-31, 23.98 fps, 24k tbn, 23.98 tbc (default)
Metadata:
BPS-eng : 3282869
DURATION-eng : 00:21:17.068000000
NUMBER_OF_FRAMES-eng: 30619
NUMBER_OF_BYTES-eng: 524055977
_STATISTICS_WRITING_APP-eng: mkvmerge v28.2.0 ('The Awakening') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2018-12-16 08:59:22
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
encoder : Lavc57.89.100 h264_vaapi
...SNIP...
|
ffmpeg uses up a little more CPU than I was expecting it to, about 8-10%, but better than fully loaded software x264 encoder at 100% CPU utilization.
Directly calling out NVENC with ffmpeg still works as well, I just can't use the nvidia encoder from the VAAPI->VDPAU path anymore until the bug is resolved.
_________________
John5788 |
|
| Back to top |
|
|
|
Kernel & Hardware
