- This topic has 4 replies, 3 voices, and was last updated 6 years, 3 months ago by
.
-
Posts
-
All the Intel QuickSync programs/drivers are installed, but it fails to use hardware encoding for this device. The errors thrown in the log are:
600 978 23:59:35 331.522 QsLibraries/QsLibraries: WARNING! Failed to initialize display for device /dev/dri/renderD129 with error -1.
600 978 23:59:35 331.574 QsLibraries/QsLibraries: WARNING! Failed to initialize display for device /dev/dri/card1 with error -1.The user running NX has full permissions to both of those devices so it’s not a permission issue, but unfortunately “error -1” isn’t very descriptive.
NXAGENT – Version 6.2.4
Copyright (C) 2001, 2018 NoMachine.
See http://www.nomachine.com/ for more information.
Session: Starting session at Wed Jul 25 23:59:30 2018.
Info: Agent running with pid 600.
Info: Slave server running with pid 644.
Info: Display running with pid 645.
Info: Listening to slave connections on port 12001.
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/arcade:1001
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Info: Audio server started with pid 660.
Info: Audio client started with pid 661.
Info: Display server started with pid 662.
Session: Session started at Wed Jul 25 23:59:30 2018.
600 665 23:59:30 753.711 TcpConnector/TcpConnector: WARNING! Can’t create the socket for proto ‘TCP’ family ‘IPv6’.
600 665 23:59:30 753.731 TcpConnector/TcpConnector: WARNING! In method ‘startTcp()’ context [A].
600 665 23:59:30 753.737 TcpConnector/TcpConnector: WARNING! Error is 97 ‘Address family not supported by protocol’.
Warning: TcpConnector: WARNING! Can’t create the socket for proto ‘TCP’ family ‘IPv6’.
Warning: TcpConnector: WARNING! Error is 97 ‘Address family not supported by protocol’.
Info: Using MIT-SHM extension.
Info: Using SSE3 for screen analysis.
Session: Connected to display server ‘:0’ at ‘Wed Jul 25 23:59:34 2018’.
Info: Screen capture running with pid 977.
Session: Connected to events server ‘:0’ at ‘Wed Jul 25 23:59:34 2018’.
Info: Using damage extension for screen updates.
Info: Screen analysis running with pid 978.
Info: Using grab method ‘CopyArea’.
Info: Using screen size 1600×900.
Info: RT handler running with pid 993.
Info: Display server for 9673BB4086F806880511977F998058DE connected on Wed Jul 25 23:59:35 2018.
Info: Audio server for 9673BB4086F806880511977F998058DE connected on Wed Jul 25 23:59:35 2018.
Info: Audio client for 9673BB4086F806880511977F998058DE connected on Wed Jul 25 23:59:35 2018.
600 978 23:59:35 331.457 Console: WARNING! Can’t query FD#30.
600 978 23:59:35 331.478 Console: WARNING! Error is 13, ‘Permission denied’.
600 978 23:59:35 331.522 QsLibraries/QsLibraries: WARNING! Failed to initialize display for device /dev/dri/renderD129 with error -1.
600 978 23:59:35 331.574 QsLibraries/QsLibraries: WARNING! Failed to initialize display for device /dev/dri/card1 with error -1.
Info: Using H.264 software encoder.
Info: Audio reader running with pid 1072.
There’s another error regarding “Can’t query FD#30” but I’m not sure if that’s related as I don’t know what it’s trying to access there.
LibVA is working fine for both video devices in the machine (although I’m trying to use the Intel one for encoding due to it being better at lower bitrates):
vainfo –display drm –device /dev/dri/renderD128
vainfo: VA-API version: 1.2 (libva 2.2.0)
vainfo: Driver version: Mesa Gallium driver 18.1.4 for Radeon RX 580 Series (POLARIS10, DRM 3.25.0, 4.17.9-1-ARCH, LLVM 6.0.1)vainfo –display drm –device /dev/dri/renderD129
vainfo: VA-API version: 1.2 (libva 2.2.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Coffee Lake – 2.2.0I seem to have resolved this now and I’m no-longer seeing that particular issue (the issue being that Intel has like 3 different media packages now for different generations).
Unfortunately NoMachine insists on using QuickSync rather than VAAPI and the former is notoriously difficult to get working without applying a lot of hacks whereas the latter covers multiple GPU types and should “just work”.
Is VAAPI being implemented at all? As it would allow hardware encoding on pretty much all GPU types on Linux.
Hello.
Glad to heard you fixed the issue with QuickSync.
The current version doesn’t use VAAPI yet, but work is in progress for that.
Unfortunately NoMachine insists on using QuickSync rather than VAAPI and the former is notoriously difficult to get working without applying a lot of hacks whereas the latter covers multiple GPU types and should “just work”.
Just to say that we started this in 2014. At that time VAAPI was not as mature and it didn’t even support the encoding side.
But now, finally, VAAPI starts to yield some results, and it is widely supported. Also considering the huge mess distributions make with Intel drivers, Intel Media SDK and the tweaking necessary to make QuickSync work, we are finally readying the VAAPI implementation.
This topic was marked as solved, you can't post.