timo

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
    Posts
  • in reply to: No hardware encoder in Linux server #48909
    timo
    Participant

    libmfxhw64.so is Intel Media SDK.

    Are you sure your hardware supports this?

    Newer hardware (like ARC/DG2 cards but also newer UHD IGPs) use libmfx-gen.so instead.

    Not sure about Ubuntu but for Fedora that’s shipped with

    intel-vpl-gpu-rt

    in reply to: Intel ARC encoding issues on Arch #48889
    timo
    Participant

    Just wanted to let you know with 8.12.12 we can finally succefully enable hardware encoding with our ARC A380 (Fedora 40).

    Thanks for supporting this.

    in reply to: Release timetable for NoMachine and Network #48334
    timo
    Participant

    Thanks Brit.

    Please let me know if there is a way to test a beta/prerelease on one of our Intel Arc based servers.

    Br,
    Timo

    in reply to: Release timetable for NoMachine and Network #48304
    timo
    Participant

    Hi,

    btw, any ETA for the next 8.x release with oneVPL support?

    Thanks and br,
    Timo

    in reply to: Intel ARC encoding issues on Arch #47619
    timo
    Participant

    This is actually fantastic news!

    in reply to: Intel ARC encoding issues on Arch #47614
    timo
    Participant

    Hi,

    it certainly doesn’t work for us with an Intel ARC 380* on a recent Fedora 39.

    Br,
    Timo

    (*) And UHD Graphics P630

    timo
    Participant

    For the Intel UHD P630 machine

    $ ls -l /dev/dri/
    total 0
    drwxr-xr-x. 2 root root         80 Jun 13 21:31 by-path
    crw-rw—-+ 1 root video  226,   1 Jun 13 21:31 card1
    crw-rw-rw-. 1 root render 226, 128 Jun  9 18:43 renderD128

    The server housing the Intel Arc 380 (DG2)

    /dev/dri

    did not exist there.
    I guess, that’s why you were asking.

    Reason is the terrible Intel Arc that behaves erratic on boot.
    A power cycle solved that.
    (We have two of them, that behave identical. And you can find
    plenty of bug reports of that sort. So it’s certainly not a hardware error.)
    For that matter I suggested to focus debugging on the P630 first
    as it also fails for encoding but doesn’t come with the additional
    woes of the Intel Arc (on Linux).

    I’ll send you the logs for the DG2 properly initialized.

    in reply to: Jump host support in client #44391
    timo
    Participant

    Unfortunately, placing anything on the jumphost server is out of question in our case for various reason.

    in reply to: Jump host support in client #44342
    timo
    Participant

    Hi,

    thanks for your answer.

    To my best knowledge our topology does not provide a HTTP or SOCKS5 proxy.

    We need to go the way opening a tunnel on a jumphost to the remote target like

    ssh user@jumphost -L [forwardport]:remotetarget:22

    and then connect via SSH protocol to localhost:[forwardport].

    That works but including the jumphost-connection directly into
    the client would definitely ease the use a lot for our coworkers.
    (Even more helpful on client platforms like Android)

    Br,
    Timo

    timo
    Participant

    Found the time to compare against the WQHD setup.

    Seems like this has to do with scaling on HiDPI setups.
    The default puts the NM client window to a geometry of said 1280 x 720 px.
    Consequently, syncing the server’s desktop res fails to up that and provides just that.
    Fonts are visibly washed out, whereas on the WQHD it’s crisp.

    There are plenty of threads and help topics about that.
    Yet, all application specific steps I tried did not help.

    Only option that seems to have an effect for me at all is that one

    win11_hidpi_scaling_compat

    Then again everything gets very small.
    Up the scaling on the client does not help as it only allows going
    from 300 % (auto for that res) to 350 % max, besides being a global setting.

    Changing dpi on the server (Fedora 38, GNOME 4) came to my mind,
    but that ended up in a non-working state where the mapping from mouse to screen space
    seems to be off. (Wasn’t able to click buttons and fields anymore straightforward).

    Can someone confirm this on a Windows 11 UHD (4K) setup?
    Wonder if that’s only to do with the res (or better the actual dpi from the panel “driver”)
    or if that’s also dependent on the GPU driver, etc …

    As a workaround I’m now switching the display to FHD.
    But even than it only works with additionally setting the compat dialog as posted above.

    timo
    Participant

    Hi,

    in case it may be relevant (changelog gave no hints in that regard though),
    I updated the server (and client) to 8.5.3 but the issue still persists as decribed.

    timo
    Participant

    Thanks for your help!

    I sent you the new logs.

    All packages are from the official Fedora repositories.

    timo
    Participant

    Following your hints I also had to link

    libva-drm.so -> libva-drm.so.2

    Unfortunately, it still doesn’t work and now claims
    Intel Quick Sync H.264 acceleration is not supported

    118288 118918 2023-04-16 10:20:36 167.670 QsLibraries/QsLibraries: Loading ‘libva.so’.
    118288 118918 2023-04-16 10:20:36 168.002 QsLibraries/QsLibraries: ‘libva.so’ library loaded.
    118288 118918 2023-04-16 10:20:36 168.514 QsLibraries/QsLibraries: ‘libva-drm.so’ library loaded.
    118288 118918 2023-04-16 10:20:36 168.609 QsLibraries/QsLibraries: Adding renderer ‘card1’ from /sys/bus/pci/devices/0000:00:02.0/drm.
    118288 118918 2023-04-16 10:20:36 168.617 QsLibraries/QsLibraries: Adding renderer ‘renderD128’ from /sys/bus/pci/devices/0000:00:02.0/drm.
    118288 118918 2023-04-16 10:20:36 168.711 QsLibraries/QsLibraries: Found 15 Intel devices.
    118288 118918 2023-04-16 10:20:36 168.787 QsLibraries/QsLibraries: Trying to open /dev/dri/renderD128.
    libva info: VA-API version 1.18.0
    libva info: User environment variable requested driver ‘iHD’
    libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so
    libva info: Found init function __vaDriverInit_1_18
    libva info: va_openDriver() returns 0
    118288 118918 2023-04-16 10:20:36 171.823 QsLibraries/QsLibraries: Display initialized.
    118288 118918 2023-04-16 10:20:36 171.854 QuickSync/QuickSync: Using 8 cpu cores.
    118288 118918 2023-04-16 10:20:36 172.012 QuickSync/QuickSync: Using provided bitrate of 7053 kbps.
    118288 118918 2023-04-16 10:20:36 172.023 QuickSync/QuickSync: Requesting software session with version 1.10.
    118288 118918 2023-04-16 10:20:36 172.026 QuickSync/QuickSync: Allocating session.
    Info: Intel Quick Sync H.264 acceleration is not supported.
    Info: Please consider updating your Intel drivers.
    118288 118918 2023-04-16 10:20:36 172.819 QuickSync/QuickSync: Closing session.
    118288 118918 2023-04-16 10:20:36 172.830 QuickSync/QuickSync: Releasing threads.
    Info: Using H.264 software encoder.

    The system has the most recent Intel packages installed

    rpm -qa | grep intel

    intel-gpu-firmware-20230310-148.fc38.noarch
    intel-mediasdk-22.6.4-3.fc38.x86_64
    oneVPL-intel-gpu-23.1.3-2.fc38.x86_64
    intel-gmmlib-22.3.5-1.fc38.x86_64
    xorg-x11-drv-intel-2.99.917-55.20210115.fc38.x86_64
    libva-intel-driver-2.4.1-12.20221130gitab755cb.fc38.x86_64
    intel-media-driver-23.1.6-1.fc38.x86_64

    N.B. The same environment with an Intel ARC 380 shows the message.

    Thanks for your help.

    timo
    Participant

    Thanks for your help.

    Yes, will give it a try asap.

    timo
    Participant

    Hello,

    any news on that one?

    Thanks for your help.

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