vk: detect prime-select forced to Nvidia

[kvark]

Follow-up to #94 that makes our check as strict as possible (within the data we have).
Closes #93
See https://github.com/canonical/nvidia-prime/blob/master/prime-select for more info.

[flukejones]

This file is common to those distros that do have a gpu selector enabled xorg-nvidia mode so it's probably not a bad stop-gap solution.

My own gpu selector (https://gitlab.com/asus-linux/supergfxctl/) doesn't use this at all, and doesn't touch any xorg stuff mostly assuming wayland. So in cases where distros like nobara are used (which use supergfx) the xorg thing is a non-issue.

I'm okay with this solution particularly since it cuts the scope right down.

[flukejones]

A possible other way to find this info: glxinfo -B, and then cut one of the lines:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 4090 Laptop GPU/PCIe/SSE2

The above is what i get when I explicitly offload to Nvidia with __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo -B and this should be true of running plain glxinfo -B in an Xorg nvidia-primary session.

Sample outputs:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 16376 MB
    Total available memory: 16376 MB
    Currently available dedicated video memory: 16064 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce RTX 4090 Laptop GPU/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 550.54.14
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6.0 NVIDIA 550.54.14
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)

OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 550.54.14
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) Graphics (RPL-S) (0xa788)
    Version: 24.0.0
    Accelerated: yes
    Video memory: 63908MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Graphics (RPL-S)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.0
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.0
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.0
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

This does require the mesa-utils package be installed. Possibly you could use GLX lib directly to find this info?

[davidbuzz]

results of testing this pr:
blade]$ git status
On branch intel-followup
Your branch is up to date with 'origin/intel-followup'.

blade]$ prime-select query
nvidia

running the next comand example/bunnymark.. it seems to run ok.. but it appears to be choosing the Adapter "Intel(R) UHD Graphics (CML GT2)" , not the nvidia..?

RUST_LOG=blade_graphics=debug RUST_BACKTRACE=1 cargo run --example bunnymark > followup.pr95.txt 2>&1

screenshot:

execution log:
followup.pr95.txt

[flukejones]

@davidbuzz have you tried offloading

[flukejones]

❯ __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia RUST_LOG=blade_graphics=debug cargo run --example bunnymark
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/examples/bunnymark`
[2024-03-18T01:14:28Z WARN  blade_graphics::hal::init] Requested layer is not found: "VK_LAYER_MESA_overlay"
DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.
TU: error: ../src/freedreno/vulkan/tu_knl.cc:232: device /dev/dri/renderD128 (nvidia-drm) is not compatible with turnip (VK_ERROR_INCOMPATIBLE_DRIVER)
TU: error: ../src/freedreno/vulkan/tu_knl.cc:232: device /dev/dri/renderD129 (i915) is not compatible with turnip (VK_ERROR_INCOMPATIBLE_DRIVER)
[2024-03-18T01:14:28Z INFO  blade_graphics::hal::init] Adapter "NVIDIA GeForce RTX 4090 Laptop GPU"
[2024-03-18T01:14:28Z INFO  blade_graphics::hal::init] Ray tracing is supported
[2024-03-18T01:14:28Z DEBUG blade_graphics::hal::init] Ray tracing properties: PhysicalDeviceAccelerationStructurePropertiesKHR {

❯ RUST_LOG=blade_graphics=debug cargo run --example bunnymark
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/examples/bunnymark`
[2024-03-18T01:15:09Z WARN  blade_graphics::hal::init] Requested layer is not found: "VK_LAYER_MESA_overlay"
DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.
TU: error: ../src/freedreno/vulkan/tu_knl.cc:232: device /dev/dri/renderD128 (nvidia-drm) is not compatible with turnip (VK_ERROR_INCOMPATIBLE_DRIVER)
TU: error: ../src/freedreno/vulkan/tu_knl.cc:232: device /dev/dri/renderD129 (i915) is not compatible with turnip (VK_ERROR_INCOMPATIBLE_DRIVER)
[2024-03-18T01:15:09Z INFO  blade_graphics::hal::init] Adapter "Intel(R) Graphics (RPL-S)"
[2024-03-18T01:15:09Z INFO  blade_graphics::hal::init] No ray tracing extensions are supported
[2024-03-18T01:15:09Z DEBUG blade_graphics::hal::init] Adapter AdapterCapabilities {

This is the exact outcome I expect

[kvark]

@flukejones the point of the fix is to make it run well without any configuration. "offloading" is therefore not something we can ask people to do.

[kvark]

@flukejones also, @davidbuzz is running Wayland, not Xorg, which explains why the fix of this PR didn't affect execution on their end. So the original issue wasn't just Xorg. And it got resolved after the driver update.

[kvark]

It also means that the current workaround in main branch wouldn't work any more for them, since it's Xorg-only.
I'm going to go ahead and merge this, but we need to get back to the drawing board, collect good bug reports, and revise the fix.

[flukejones]

@kvark if the driver is openGL then the above is the correct output, but if it's supposed to be using Vulkan then yeah, usually vulkan apps default to dgpu. How do we tell which is being used?

[flukejones]

And from what I saw of the original issue, David is using what Ubuntu defaults to, which is Xorg. You see this in the nvidia-smi output. Most distros up until this years have always defaulted to xorg if nvidia is installed too.

Lastly, the entire reason I ended up here in the first place is that I do not want Zed defaulting to my dgpu. But if this is the behaviour you want then I think there needs to be a configurable compile-time option.

[kvark]

And from what I saw of the original issue, David is using what Ubuntu defaults to, which is Xorg. You see this in the nvidia-smi output. Most distros up until this years have always defaulted to xorg if nvidia is installed too.

@flukejones I'm chatting with David, and it definitely looks like they are running Wayland. We checked "$XDG_SESSION_TYPE" as well as "About Ubuntu" screen to verify.

Lastly, the entire reason I ended up here in the first place is that I do not want Zed defaulting to my dgpu. But if this is the behaviour you want then I think there needs to be a configurable compile-time option.

We are on the same page here. I, too, don't want Zed to run on dGPU unless it's the users choice. Ideally, this would be configured by the environment, such that we don't need any fixes in Blade. "offloading" is exactly this kind of environment.
But unfortunately sometimes it's failing on Intel when the configuration is with "prime-select", and so this latest fix in #97 takes care of that.

TL;DR: unless you do prime-select on your machine to force Nvidia, you'll get Intel picked up for Zed, just as you expect.

[flukejones]

Sure but the problem is that prime-select doesn't actually affect wayland. Wayland ignores the generated xorg conf that forces nvidia and the prime-select script does very little else to make nvidia primary (again, only on xorg). Ubuntu haven't changed that ancient script so I'm not actually sure what's going on here.

So what you've really ended up with here is a quirk to try and work around something that shouldn't be in use anymore. But I guess if it works.. I just don't like it.