Here’s the breakdown of what is actually happening under the hood:

1. The Shader Version Gap

The error versions tried: QList(130, 120) tells us that your application is looking for older, "baked" GLSL shader code (OpenGL 3.0/2.1 era). However, the only shader found in your binary is Version(300), which corresponds to OpenGL ES 3.0.

• What you're missing: Your application was likely compiled/packaged with shaders targeting modern mobile or DirectX/Vulkan backends, but the runtime is falling back to a legacy OpenGL path that doesn't have the corresponding "blobs" to talk to the GPU.

2. Why it "Works" on the Newer Machine

The newer machine likely has a more robust driver set or a different default RHI priority.

• DirectX 11 vs. OpenGL: On Windows, Qt and similar frameworks perform significantly better on DirectX because they can use the ANGLE layer, which translates OpenGL calls to DirectX.
• The "Speed" Illusion: If the scene is still fast, your system might be successfully falling back to a software rasterizer or a partial hardware acceleration path, but you'll eventually hit a "Black Screen" or a crash when the app tries to call a specific graphics pipeline that failed to build.

Comparison of Backends

How to Fix This

You likely need to force the application to use a backend that matches its baked shaders. Try one of the following:

• Force the RHI: Set an environment variable before launching the app to see if it clears the warning:

• QT_RHI_BACKEND=d3d11 (For Windows)

• QT_RHI_BACKEND=vulkan (If supported)

• Update Drivers: Even if the machine is "older," ensure the GPU drivers support OpenGL 3.3+.

• Check Shader Baking: If you are the developer, ensure your qsb (Qt Shader Baker) settings include the desktop GLSL versions (--glsl "130,120,100") and not just the ES versions.

Note: The "Failed to build graphics pipeline" error is the most critical. It means certain effects, materials, or lighting calculations simply won't render, even if the rest of the UI seems to be moving.

Would you like me to show you how to check which OpenGL versions your current GPU drivers actually support?

P.S. Sorry, but my answer above was generated with Gemini. I think it can be usefull.

WARNING Initializing RHI with OpenGL backend
WARNING No GLSL shader code found (versions tried: QList(130, 120) ) in baked shader QShader(stage=0 shaders=QList(ShaderKey(1 Version(300 QFlags()) 0)) desc.isValid=true)
WARNING Failed to build graphics pipeline: Creation Failed

No problem with this setting on the newer machine so far ...
Speed of the scene is comparable to DirextX11+

What am I missing?

best regards, kevin_d

best regards, kevin_d

I think you can use the QSG_RHI_BACKEND environment variable for that.

Thanks for your reply.
Appearantly, the Graphic Chip does not support DirectX11 ...
Is there a way of a fallback to either OpenGL or DirectX10 ?

best regards, kevin_d

Disclaimer: I do not currently work on any program on Windows (nor DirectX specifically), so I have not attempted to reproduce this nor to run anything on Windows at all at the moment.

Based on reading source code, (and depending which Qt version—here I have assumed 6.10), it seems like in order for this to happen:

{Warning:} Initializing RHI with DirectX backend
{Warning:} RHI: Unable to use requested RHI Api, trying to fall back on OpenGL

The Qt method bool QRhiD3D11::create(QRhi::Flags flags) has to return false.

You can see the body of the method here: https://github.com/qt/qtbase/blob/v6.10.2/src/gui/rhi/qrhid3d11.cpp#L197-L419

This suggests at least two potential paths toward a deeper diagnosis:

1. Make sure Visual Studio has access to Qt framework debug symbols and source code, and step through QRhiD3D11::create in a debugger.
2. Try to write a (non Qt) small DirectX "hello world" that uses functions like createDXGIFactory2 and dxgiFactory->EnumAdapters1 (which are the functions that Qt is trying to use under the hood).

In option (2), the idea is that if you directly write some DirectX code (in a separate main that does not use Qt at all), then you can perhaps more quickly discover what part of DirectX is failing to cooperate.

I offer this in the spirit of brainstorming. Again, I am not actively developing any Windows/DirectX codebase at the moment, so my advice is certainly not "expert" in that regard. However, I have done such work in years past, and I have used the approaches (1) and (2) successfully in the past to debug similar scenarios where it was not clear to me whether Qt was misbehaving or whether something nested "underneath" Qt was misbehaving.

{Warning:} D3D11 smoke test: Failed to create vertex shader
{Warning:} Initializing RHI with DirectX backend
{Warning:} RHI: Unable to use requested RHI Api, trying to fall back on OpenGL
{Warning:} Initializing RHI with OpenGL backend
{Warning:} QOpenGLContext::makeCurrent() called with non-opengl surface 0x190509c29d0
{Warning:} QRhiGles2: Failed to make context current. Expect bad things to happen.

My DirectX Version is locally at 12

best regards, kevin_d

extern "C"
{
    __declspec(dllexport) unsigned long NvOptimusEnablement = 1;
    __declspec(dllexport) unsigned long AmdPowerXpressRequestHighPerformance = 1;
}