Yesterday, 04:00 PM
(This post was last modified: Yesterday, 05:18 PM by Gustaaf Mixer. Edited 4 times in total.)
This thread is a solution I would like to share, for a question I did not find in the forums.
It could be argued my hardware for Jellyfin is a bit of a niche mixed bag.
The platform consists of an Intel Core i3 530, 6G of DDR3 memory, and an ARC A310.
So that's an heirloom PC from early 2010, upgraded with a GPU from late 2022.
It has a few funky behaviors, some of them proving a hindrance to getting QVS up and running.
The key to getting this setup working is that VPL may become very confused when there are 2 GPUs available.
I presume not often, but it sure did in my case.
After initially installing the Arc GPU, I coud see /dev/dri/renderD128 and /dev/dri/renderD129.
The first is the ancient integrated graphics GPU that supports next to nothing, and the other is a pretty nice GPU for transcoding purposes.
I was able to get vaapi acceleration working, but I had to configure the environment and pass the necessary command line arguments to ffmpeg to convince the system to use the discrete GPU.
However, QSV remained elusive, even though, clearly, hardware acceleration worked, as proven by vaapi.
About a day of trying just about everything under the sun to get to the bottom of this, I decided to simplify my situation, and just disable the integrated graphics.
Just to be sure VPL wasn't getting confused even though I specified very clearly which device to use. (Foreboding!)
One of the funky behaviors the machine has, is that it does not boot at all if I merely suggested that the integrated graphics could be deactivated in the presence of a discrete GPU.
So I had to solve it another way.
This machine runs Arch Linux and uses the syslinux bootloader, so the code below is specific to that configuration, but the principle holds for just about any Linux kernel:
The relevant bit is
The
Once I did that, I ended up with only one GPU in the system, and lo and behold, everything started working effortlessly, and pretty much out of the box.
Moral of this story - I am not sure who to ask, but maybe this information could be integrated in the Jellyfin guides for Intel graphics?
It sure would have saved me quite a lot of time, which is why I decided to share this story.
note: I briefly tried the xe driver, but that made
Thanks for reading.
It could be argued my hardware for Jellyfin is a bit of a niche mixed bag.
The platform consists of an Intel Core i3 530, 6G of DDR3 memory, and an ARC A310.
So that's an heirloom PC from early 2010, upgraded with a GPU from late 2022.
It has a few funky behaviors, some of them proving a hindrance to getting QVS up and running.
The key to getting this setup working is that VPL may become very confused when there are 2 GPUs available.
I presume not often, but it sure did in my case.
After initially installing the Arc GPU, I coud see /dev/dri/renderD128 and /dev/dri/renderD129.
The first is the ancient integrated graphics GPU that supports next to nothing, and the other is a pretty nice GPU for transcoding purposes.
I was able to get vaapi acceleration working, but I had to configure the environment and pass the necessary command line arguments to ffmpeg to convince the system to use the discrete GPU.
However, QSV remained elusive, even though, clearly, hardware acceleration worked, as proven by vaapi.
About a day of trying just about everything under the sun to get to the bottom of this, I decided to simplify my situation, and just disable the integrated graphics.
Just to be sure VPL wasn't getting confused even though I specified very clearly which device to use. (Foreboding!)
One of the funky behaviors the machine has, is that it does not boot at all if I merely suggested that the integrated graphics could be deactivated in the presence of a discrete GPU.
So I had to solve it another way.
This machine runs Arch Linux and uses the syslinux bootloader, so the code below is specific to that configuration, but the principle holds for just about any Linux kernel:
LABEL arch blacklist i915
MENU LABEL Arch Linux Blacklist iGPU i915
LINUX ../vmlinuz-linux
APPEND root=/dev/sda1 rw i915.force_probe=!0042
INITRD ../initramfs-linux.img
The relevant bit is
i915.force_probe=!0042, which prevents loading the i915 for my integrated graphics specifically.The
0042 is the pci ID, which can for example be obtained as follows (see the numbers between brackets at the end of the line):
lspci -nnk | grep "Integrated Graphics"
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0042] (rev 12)
Once I did that, I ended up with only one GPU in the system, and lo and behold, everything started working effortlessly, and pretty much out of the box.
Moral of this story - I am not sure who to ask, but maybe this information could be integrated in the Jellyfin guides for Intel graphics?
It sure would have saved me quite a lot of time, which is why I decided to share this story.
note: I briefly tried the xe driver, but that made
vainfo explode with a segfault, so I reconsidered rather quickly. ;-PThanks for reading.