Coleman

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • AvatarColeman
    Participant

    Thanks! I should have closed this thread, support helped me get it going in my other thread. In my case, the link to the hardcoded location for the media sdk .so was the thing I needed to get it all working. Your instructions cover the whole library path, support just had me do the one file. I didn’t need anything with the plugin config.

    It’s good to have all the bits summarized in one place though!

     

    in reply to: Verify GPU encoding used? #32602
    AvatarColeman
    Participant

    I think you replied to the wrong topic, or you linked the trouble report. ūüėÄ

     

    in reply to: Poor performance/lag when host screen is off #32378
    AvatarColeman
    Participant

    Thanks for the reply! I’ll just do that, disable the power off mode on the laptop.

    in reply to: Verify GPU encoding used? #32325
    AvatarColeman
    Participant

    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-gnu and create the /opt/intel/mediasdk/lib64 path 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!

    in reply to: Poor performance/lag when host screen is off #32324
    AvatarColeman
    Participant

    Output here…additional data point, I think it’s specifically when the screen is powered off from the power saver settings, not just from the screensaver blanking.

    jason@CB5:/dev/dri$ xset q
    Keyboard Control:  auto repeat:  off    key click percent:  0    LED mask:  00000000
    XKB indicators:  00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
    auto repeat delay:  500    repeat rate:  20
    auto repeating keys:  00ffffffdffffbbf  fadfffefffedffff  9fffffffffffffff   fff7ffffffffffff
    bell percent:  50    bell pitch:  400    bell duration:  100
    Pointer Control: acceleration:  2/1    threshold:  4
    Screen Saver: prefer blanking:  no    allow exposures:  no
    timeout:  60    cycle:  60
    Colors: default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff
    Font Path: /usr/share/fonts/X11/misc,/usr/share/fonts/X11/Type1,built-ins
    DPMS (Energy Star): Standby: 0    Suspend: 0    Off: 120
    DPMS is Enabled
    Monitor is Off

    in reply to: Verify GPU encoding used? #32323
    AvatarColeman
    Participant

    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
    total 0
    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!

    in reply to: Verify GPU encoding used? #32306
    AvatarColeman
    Participant

    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?

    Thanks!

     

    in reply to: Verify GPU encoding used? #32270
    AvatarColeman
    Participant

    Ok, I think I may have found the immediate problem:

    @CB5:/usr/lib/x86_64-linux-gnu# ls libva* -la
    lrwxrwxrwx 1 root root     20 Mar  1 16:37 libva-drm.so.2 -> libva-drm.so.2.800.0
    -rw-r--r-- 1 root root  14664 Jun 29  2020 libva-drm.so.2.800.0
    lrwxrwxrwx 1 root root     16 Mar  1 16:37 libva.so.2 -> libva.so.2.800.0
    -rw-r--r-- 1 root root 162336 Jun 29  2020 libva.so.2.800.0
    lrwxrwxrwx 1 root root     24 Jun 29  2020 libva-wayland.so.2 -> libva-wayland.so.2.800.0
    -rw-r--r-- 1 root root  23248 Jun 29  2020 libva-wayland.so.2.800.0
    lrwxrwxrwx 1 root root     20 Mar  1 16:37 libva-x11.so.2 -> libva-x11.so.2.800.0
    -rw-r--r-- 1 root root  27336 Jun 29  2020 libva-x11.so.2.800.0

    I don’t appear to actually have anything linked as “libva.so”.¬† I’m not super familiar with the intricacies of libva, so I’m not sure if it’s safe/would fix the issue, to just link libva-drm.so.2.800.0 as libva.so the way it’s currently linked as “libva.so.2”. i.e. not sure if that’s the current version of the same library and also compatible, so insight here would be helpful!

    Thanks!

     

    in reply to: Verify GPU encoding used? #32268
    AvatarColeman
    Participant

    Updated session log- I’m already looking to see if I can figure anything out about the obvious problem in the log (failure to load libva.so) but if you have ideas/knowledge already on this, please do let me know!

     

    Attachments:
    in reply to: Verify GPU encoding used? #32238
    AvatarColeman
    Participant

    It is:

    apt search libva-drm2
    Sorting… Done
    Full Text Search… Done
    libva-drm2/groovy,now 2.8.0-1 amd64 [installed,automatic]
    Video Acceleration (VA) API for Linux — DRM runtime

    in reply to: Verify GPU encoding used? #32222
    AvatarColeman
    Participant

    Certainly!

    The server host is an Intel gen5 (Broadwell) processor, using the integrated graphics.

    lspci:
    00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics [8086:1606] (rev 09) (prog-if 00 [VGA controller])
    DeviceName: VGA compatible controller
    Subsystem: Intel Corporation HD Graphics [8086:1606]
    vainfo:
    libva info: VA-API version 1.8.0
    libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
    libva info: Found init function __vaDriverInit_1_8
    libva info: va_openDriver() returns 0
    vainfo: VA-API version: 1.8 (libva 2.8.0)
    vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics – 20.2.0 ()

    Session attached.

    Attachments:
    in reply to: Verify GPU encoding used? #32201
    AvatarColeman
    Participant

    About /usr/NX/var/log/node folder please check on the server side.

    I finally found the session logs, per https://www.nomachine.com/FR11Q03892

    As of version 7.0.208: The display agent log files should be stored in the correspondent session directory created under the home directory of the session owner, e.g. the user’s home/.nx/node/C-display-sessionid directory. Which is where my session logs are.

    The session log is verifying (in addition to the client information) that I am getting only the software encoder, though I still have no indication why.

    Thank you

    in reply to: Verify GPU encoding used? #32126
    AvatarColeman
    Participant

    “/usr/NX/var/log/node folder please check on the server side.”
    The server doesn’t have it.

    jason@CB5:/usr/NX/var/log$ du -a .
    4 ./logrotate
    4 ./archives
    40 ./nxupdate.log
    12 ./nxd.log
    44 ./nxinstall.log
    28 ./nxerror.log
    16 ./nxserver.log
    152 .

    I did upgrade my client and I can see the string now, and it is indicating that I’m not getting h.264 acceleration, so I’ll have to figure out why that is.
    Thanks!

    in reply to: Verify GPU encoding used? #32108
    AvatarColeman
    Participant

    That’s actually what I was referring to when I found old posts mentioning a way to check. Maybe I don’t have the logging enabled for that, but I don’t have a node subdirectory in /usr/NX/var/log. Since the posts were a few years old, I started thinking that the log information was moved elsewhere, but none of the files in the log directory has anything like that. On my install, the only subdirs off that are “archives” and “logrotate”.

    I did find that post you linked as well. So, one thing about that particular item, it doesn’t say where in the UI that information is located. My server version is 7.1.3 but I’ve just noticed that I think my client is rather outdated (it was kind of tricky to find something that showed the client version, at least on Windows). If my older client (I think it’s 6.4.6) is able to display the string properly, than I am on all software, which I’ll have to figure out. I’ll update my client and see if that changes what I’m seeing in the connection information. I’m assuming I’m looking in the right place (Display Settings on the client; it’s the only place that has a string that looks like the information mentioned in the KB article).

    Thanks!

    in reply to: Disable hardware acceleration on the client side? #23812
    AvatarColeman
    Participant

    Ah, thanks! I was looking for settings prior to establishing the connection.

     

Viewing 15 posts - 1 through 15 (of 16 total)