feat: support WSL2 D3D12 GzSim sessions

[karttikjangid]

Summary

Adds a WSL2-specific GzSim, VNC, and Python-exercise launch path for RoboticsAcademy running through Docker Desktop on Windows.

This is the RAM companion to [RoboticsAcademy #3973](JdeRobot/RoboticsAcademy#3973), which fixes the Windows-specific Docker Compose configuration.

Important Info :

I am currently still working on this but finding out a way to make the windows workflow is proving to be very hard . There maybe more commits associated with this .

Why this is needed

The existing Docker workflow and GPU documentation are Linux-oriented:

• They assume GPU rendering is exposed through /dev/dri.
• They use the native Linux GPU VNC path based on TurboVNC and VirtualGL.
• They use Linux Docker/NVIDIA setup instructions that do not apply to Docker Desktop-managed WSL2.
• The generic Compose workflow can copy a configuration that contains /dev/dri.

Docker Desktop with WSL2 exposes the GPU through /dev/dxg, not /dev/dri.

Therefore, attempting to start the Windows Compose configuration with /dev/dri fails before the container starts. That startup failure is fixed separately by [RoboticsAcademy #3973](JdeRobot/RoboticsAcademy#3973).

However, removing /dev/dri alone is insufficient: RAM then treats the WSL2 container as having no GPU and continues to use a VNC/GPU path that assumes native Linux DRI devices. This PR adds the missing RAM runtime support for the WSL2 graphics stack.

Changes

Detect WSL2 GPU access

check_gpu_acceleration() now checks for /dev/dxg before the existing /dev/dri logic.

When /dev/dxg exists, RAM verifies NVIDIA visibility with nvidia-smi and reports NVIDIA acceleration when it succeeds.

This avoids incorrectly disabling GPU acceleration only because /dev/dri is absent in WSL2.

Add a WSL2 VNC backend

GzSim sessions on WSL2 now use:

Xvfb → x11vnc → noVNC/websockify

This backend was verified independently with an actual browser/noVNC session, including a completed RFB connection and framebuffer negotiation.

The implementation:

• Reuses RAM's configured display and VNC ports.
• Starts Xvfb, x11vnc, and noVNC without shell wrappers.
• Preserves optional TLS certificate support already used by noVNC.
• Tracks only the child processes it starts.
• Terminates only its owned process groups during shutdown.
• Does not use broad cleanup commands such as pkill or fuser -k.

Use the D3D12 OpenGL path for GzSim

For the WSL2 branch only, GzSim is started with:

GALLIUM_DRIVER=d3d12

The setting is local to the GzSim process. It is not added to the container-wide environment and does not affect native Linux GPU rendering.

Start Python exercises with the required ROS environment

For WSL2 Python exercise entrypoints, RAM now starts the program after sourcing:

/opt/ros/humble/setup.bash

It also supplies the workspace HAL, GUI, and console interface paths through PYTHONPATH.

This fixes Python exercise startup in the WSL2 development container, where launching academy.py directly can otherwise fail to import the required ROS/HAL interfaces.

exec python3 is used so the process tracked by RAM remains the actual exercise process and preserves normal signal handling.

Cross-platform behaviour

The new path is selected exclusively by the presence of /dev/dxg.

• Windows + Docker Desktop + WSL2: /dev/dxg exists, so RAM uses the Xvfb/x11vnc/noVNC backend and D3D12 rendering path.
• Native Linux with /dev/dri: /dev/dxg is absent, so the existing TurboVNC/VirtualGL GPU path is unchanged.
• CPU-only Linux and macOS-equivalent containers: /dev/dxg is absent, so the existing CPU VNC path is unchanged.

No existing Linux or macOS branch is changed.

Validation

Validated in a Windows 11, Docker Desktop, WSL2, NVIDIA environment:

• /dev/dxg is present and /dev/dri is absent in the container.
• NVIDIA is visible inside the container.
• GALLIUM_DRIVER=d3d12 glxinfo -B reports hardware-accelerated D3D12/NVIDIA rendering when run with an X server.
• Xvfb, x11vnc, and noVNC start successfully.
• A browser establishes a noVNC/RFB session, rather than only reaching a listening TCP port.
• RAM starts the exercise process with the ROS and workspace interface environment available.
• Existing native Linux GPU and CPU branches remain outside the /dev/dxg condition.

Related work and scope

• Required Windows Compose change: [RoboticsAcademy #3973](fix(compose): support Docker Desktop WSL2 NVIDIA workflow RoboticsAcademy#3973)
• This PR intentionally does not change Docker Compose files, exercise algorithms, /dev/dri Linux behaviour, or ZIP/archive handling.
• The development Compose configuration bind-mounts src, so this RAM revision must be checked out there until the change is released in a RoboticsAcademy image.

Why the existing Windows workflow fails

The existing documented Windows workflow describes a Linux GPU workflow based on /dev/dri, Linux NVIDIA runtime installation, legacy docker-compose, and generic copied Compose files.

Docker Desktop owns Docker on Windows, and WSL2 GPU rendering uses /dev/dxg.

PR #3973 fixes the container-start layer. This RAM PR fixes the runtime layer after the container starts.

[javizqh]

This is irrelevant to the changes