Tagged: gpu h.264
March 9, 2021 at 10:17 #32306
I think we’re getting closer! I still don’t have encode acceleration, I put the debug library back and generated a new log file, which I am attaching. The libraries are loading now, and it looks like it’s trying to access the QS hardware. Within that logfile are warnings that say there’s a permissions issue. Per the old Intel Media SDK instructions, I had already added both myself (the user account connecting) and the nx user to the “video” and “render” user groups, which I understood would be needed for access to the GPU devices. If there’s something permissions-wise beyond that which needs to happen, I’m not aware of it.
Suggestions for the next steps?
Attachments:March 9, 2021 at 12:27 #32317fishermanModerator
1. Can you make sure that devices under /dev/dri are also in video group and have correct permissions
ls -la /dev/dri
2. we have hard coded path to look for iHD driver in /opt/intel/mediasdk/lib64/
You could try to create these directories and add symbolic there. so something like:
mkdir /opt/intel/mediasdk/lib64/ ln -s /path/where/he/has/iHD_drv_video.so /opt/intel/mediasdk/lib64/iHD_drv_video.soMarch 10, 2021 at 09:20 #32323
Hmm…well interesting, one is in one, the other, the other in the other…but nx is part of both groups so, should be ok, I imagine?
jason@CB5:/dev/dri$ groups nx
nx : nx video render
jason@CB5:/dev/dri$ ls -la
drwxr-xr-x 3 root root 100 Mar 8 15:01 .
drwxr-xr-x 22 root root 4300 Mar 8 15:01 ..
drwxr-xr-x 2 root root 80 Mar 8 15:01 by-path
crw-rw----+ 1 root video 226, 0 Mar 8 15:01 card0
crw-rw----+ 1 root render 226, 128 Mar 8 15:01 renderD128
I’ll create the folders and links, and re-test and report back.
Thanks!March 10, 2021 at 09:44 #32325
Success! Although not quite in the way I expected, initially. When I connected, I received this message:
Cannot detect any display running. Do you want NoMachine to create a new display and proceed to connect to the desktop
This created a virtual desktop and connected me to that instead of to the existing session. After, I fiddled some more, I was able to get connected to the desktop with QS encoding. I realized that the debug library was writing to the session file a lot, so I shut nx down, and put the original back, and everything started working when I started it back up. I don’t know if the debug was interfering with connecting to the desktop for certain, but everything seems to be working as I want now!
So in the end it does seem like the hardcoded path to the iHD driver was pretty key here, at least for me. This is kinda a key point for the KB article you guys have on compiling Intel Media SDK support into the kernel, those instructions are not accurate anymore, as Intel has discontinued part of it. The pieces are all still around, but not quite in the same ways any more referred to in the instructions.
For my setup, I didn’t have to do a kernel recompile, after looking, I was fairly confident the Ubuntu 20.04 kernel is built with it already in place. It seems like you just need to add the Intel Media SDK libs from repo(apt get)m then link the files to the names nx is looking for in
/usr/lib/x86_64-linux-gnuand create the
/opt/intel/mediasdk/lib64path and link the driver (listed in vainfo) that is hardcoded for, at least for distros that have built their kernel with the Intel Media SDK already.
Thanks for the assistance!March 25, 2021 at 16:51 #32601CarinParticipant
We’ve opened a Trouble Report for this issue:https://www.nomachine.com/TR03S10162.
You can sign up to receive notification of a fix when it’s available.
Thanks for reporting.March 25, 2021 at 17:18 #32602
I think you replied to the wrong topic, or you linked the trouble report. 😀March 25, 2021 at 17:20 #32604CarinParticipant
Thank you, Coleman! The link was corrected.
This topic was marked as solved, you can't post.