Community Spotlight: Harjinder Singh’s GPU-Accelerated ThinLinc Lab (AlmaLinux, VirtualGL & XFCE)

Blog
, , ,
1

Hey everyone,

With the recent HP Teradici/PCoIP/ Anyware EOL announcement, a lot of EUC engineers are looking for robust Linux remoting alternatives.

Recently, Harjinder Singh (Citrix/EUC Consultant) built out an incredibly detailed POC lab using ThinLinc to test GPU-accelerated workloads for VFX and CAD, and the results are well worth highlighting here.

You can check out his original LinkedIn posts:

Here is a breakdown of his lab and findings:

The Infrastructure Stack

  • OS: AlmaLinux 9.7

  • Hardware: NVIDIA P4000 GPU (Passthrough)

  • Virtualization: Vates Virtualization Management Stack (XCP-ng / Xen Orchestra)

  • Broker: Cendio ThinLinc (+ Web Access)

  • Acceleration: VirtualGL

The Journey: GNOME vs. XFCE Harjinder initially started testing with GNOME (Foundation 40.x). While general responsiveness was good, he ran into a few bottlenecks, most notably, Blender falling back to CPU rendering despite seeing the P4000.

To optimize, he rebuilt the VDA using XFCE and updated VirtualGL. The result? A massive improvement in responsiveness, stable session performance, and resolved application crashes.

Application Performance Highlights With VirtualGL updated and XFCE running smoothly, the GPU acceleration truly kicked in:

  • Blender (v5.1): Cycles rendering (300 samples) dropped from a painful 52 minutes on the CPU down to just 3 minutes and 42 seconds on the GPU.

  • FreeCAD: Architectural/BIM workloads ran smoothly with stable CPU load and low GPU utilization.

  • DaVinci Resolve: Successfully auto-detected multiple monitors with highly responsive playback and timeline scrubbing.

What’s Next for the Lab? Harjinder is still testing, with plans to tackle high-latency network scenarios, audio/video redirection, AD integration, and multi-session load testing.

Let’s Discuss:

  • Have any of you tested DaVinci Resolve or FreeCAD over ThinLinc? What was your experience?

  • Do you agree with the XFCE over GNOME preference for these types of heavy 3D workloads?

Let us know below, and a huge thank you to Harjinder for sharing his setup with the EUC community!

2

Hi everyone — thanks again to the ThinLinc team for sharing the posts and putting together the spotlight thread.

I’m still pretty early in the POC and definitely still learning parts of both Linux and ThinLinc as the lab evolves.

Most of my background has actually been around Windows-based Citrix CVAD deployments, with only some dabbling in Linux VDA work over the last year or so, so this project has been as much a learning exercise for me as it has been a technical POC.

The original idea behind the lab was to try something closer to a real Linux VFX/CAD/AEC production workstation environment where companies are likely using PCoIP/Teradici/DCV for remote working instead of Citrix/Horizon. I was recommended Thinlinc as a solution after HP’s odd decision to shutter PCoIP.

The main goals were:

  • Build a good Linux workstation environment aligned as closely as possible to the VFX Reference Platform standard.
  • Compare different Linux remoting approaches including CVAD,ThinLinc, and Amazon Web Services DCV
  • Test Linux GPU remoting for general and VFX/AEC/CAD workflows.- how does it compare to Citrix and its HDX protocol.
  • Provider a good user experience.

The choice of AlmaLinux 9.7 was intentional and came down to:

  • Alma/Rocky/RHEL 9.x is the VFX reference platform for Linux workstations.
  • Application compatibility and vendor support - BlackMagic Design “Da Vinci Resolve”, SideFX Houdini, Citrix etc.
  • Citrix/Ominssa Linux VDA support is essentially the same as the VFX reference Linux standard - RHEL/Rocky 9.x.
  • Previously looked at Rocky 9.4 Linux VDAs with Citrix CVAD.

Apps such as Da Vinci Resolve and SideFX Houdini are only supported on Alma/Rocky/RHEL 9.x, so my aim was to stay as close to what might actually be seen in production Linux workstation deployments and aim to have a stable VDA.

Still lots left to learn, improve and test. Hopefully some of the findings are useful to others.

Harj

1 Like
3

Hi All

Thought I’d provide an update on the lab - as you’re the SME’s with Thinlinc+ Linux it’d be good to have some CC.

POC Status:
Current VDA version - Build 3

Virtual GL from the RHEL/ALMA/ROCKY repos is 3.1.2 - its buggy and was used in builds 1 (Gnome). For Build 2 - XFCE DE. Manually installed latest VirtualGL 3.1.4 which fixed a number of app issues in build 1 although I’ve kept "libturbo.jpeg v.2x. " via the repo.

All testing is on the LAN atm.

Reason for moving to build 3**

Insufficient VM resources - 4vCPU/24 GB - was inadequate for Blender/Resolve workloads even for a VDA POC lab. The VDA is now 8vCPU/32GB.

Blender: Insufficient storage for the CAD/VFX workloads - Significant performance impact (90%+ CPU load) unit testing apps esp Blender over time. Root cause was insufficent free disk space. Build 3 - has 2x the disk space and 2x vCPUs.

Resolve - loves to generate large amount of cache/tmp files (100GB+) and its usually best practice to have dedicated disks for media and scratch data. For a POC I thought I could get by without them but it is. Build 3 - dedicated scratch and media vdisks specifically for resolve and blender.

Memory - Unit testing a render test of blender complex scene (Build 2), simply starting the render results in system memory and swap file exhaustion. Build 3 has a 32GB swap file and memory increased to 32GB. 32GB of ram is still insufficient for this particular test.

Build 3 Issues

Resolve - performance when working with a single display even when using dual monitors is good. However, there is a noticeable slow down in the editor when switching on Dual monitors option within Resolve. Resolve is not as responsive in the timeline, scrubbing through the time line, switching between the various resolve panels (media, cutting, editing, fusion, etc). This is potentially also in Build 1/2 - didn’t really test for it

Blender:
Blender crashes at startup when configured to use Vulkan instead of OpenGL.Surprisingly this is known random issue impacting various versions of Windows/Linux for nearly 2+ years and didn’t impact previous builds. The quick work around is to only use OpenGL for now. Not ideal but it allows for testing and troubleshooting.

Rendering times has slowed down by a small amount compared to build 2 - the classroom benchmark render @ 300 sample cycles renders (CUDA+OpenGL) in 4mins 4s vs 3min 42s (build 2) .

FreeCAD:
Consistent slight delay in FreedCAD when zooming into the models for the first time. This behaviour exists on Windows version on physical workstation so is app related and not Linux or VDI.

Local user accounts:
Having issues with new local users logging in via Thinlinc. SSH, local console and XRDP are fine.

WIP:
Looking to deploy two additional commercial apps - BricsCAD (AEC workloads) and SlideFX’s Houdini (VFX workloads) to build 3. Hopefully, be able to test simple to complex sample files for both apps.

Optimisations - Disable XFCE eye candy and switch tuned profile to - “throughput + virtual-guest”

Update:

Switched the tuned profile from “virtual guest” to “virtual guest + throughput_performance” and the results from Blender render:

Classroom scene (300 samples):
GPU : CUDA/OpenGL : 2mins27s
CPU ; 39mins

34% improvement in GPU rendering time using the P4000.
25% improvement in CPU rendering time.

Harj