On 6/25/19 11:42 PM, Adam Carter wrote:
What about USE flags for mesa and libva?
x11-libs/libva-2.4.0:0/2::gentoo USE="X drm opengl -utils -vdpau
-wayland"
media-libs/mesa-19.1.1::gentoo USE="classic dri3 egl gallium gbm gles2
llvm vaapi -d3d9 -debug -gles1 (-libglvnd) -lm_sensors -opencl -osmesa
-pax_kernel -pic (-selinux) -test -unwind -valgrind -vdpau -vulkan
-vulkan-overlay -wayland -xa -xvmc"
This wouldn't happen to be a 10-bit encoded x265, would it? If it is,
10-bit hardware decoding is only supported in Kaby Lake or newer (this
could explain it decoding in software/on CPU instead of GPU.)
That's possible. Is there an easy way to tell?
I also had to boot with UEFI or no hardware decoding happened at all.
Mine was old enough to give you a choice but video performance suffered
in BIOS boot mode.
Damn - this is in BIOS mode... Very odd that makes a difference. Nice find.
When I got my celeron-based NUC I discovered that just because the CPU
has some hardware offloading doesn't mean software will use it. :(
This box is a NUC (NUC6i5SYB) that im using for a media PC.
Mine's an older Celeron. It struggled with 1080p video. I found back
then (maybe six years ago?) a thread stating Intel locks out some
hardware in BIOS mode so performance will suffer. All I did at the time
was grind my teeth and fight it to get it to boot in UEFI mode, and I
could see the hardware offload on 1080p was working correctly.
I see from your other reply it is a 10-bit file, that would explain why
hardware offloading doesn't work - it's not supported on that CPU. Have
you tried an 8-bit encoded file to see if the hardware offloading works?
Dan
