windows: add opt-in D3D11 shader support

[GGRei]

Summary

Adds opt-in D3D11 support for v-gui’s built-in shader pipelines.

This PR moves the built-in GUI shaders to a generated v shader pipeline with OpenGL, Metal, and HLSL/D3D11 output, while keeping D3D11 behind the explicit -d sokol_d3d11 flag.

It also updates the Windows raster/readback path so default Windows OpenGL does not accidentally use D3D11-only readback, and the D3D11 path uses the proper backend when enabled.

Fix #72
Codex review validation : here

Details

• Adds generated built-in shader descriptors from shaders/gui_builtin.glsl.
• Routes built-in pipelines through *_shader_desc(gfx.query_backend()).
• Keeps runtime custom shaders as OpenGL/Metal only for now.
• Documents the D3D11 custom-shader fallback behavior.
• Uses sapp.glue_environment().defaults for render-target formats instead of direct enum casting.
• Adds Windows codegen coverage for default Windows vs -d sokol_d3d11 readback routing.
• Extends the optional Windows smoke workflow with D3D11 compile probes.
• CI now runs the generated-shader freshness check with GUI_CHECK_GENERATED_SHADERS=1 and triggers on shader source changes.
• Removes the old duplicated built-in GLSL/Metal shader strings now replaced by the generated shader header; the remaining GLSL/Metal sources are only for the runtime custom Shader API.

Note: the generated built-in shader header now targets the current Sokol shader set: glsl410 for desktop GLCORE, hlsl4 for D3D11, and metal_macos for macOS Metal. Runtime custom Shader.glsl remains GLSL 3.3, that path is separate from the generated built-in shaders.

Validation

• v -no-parallel test .: 72 passed / 1 skipped / 73 total
• GUI_CHECK_GENERATED_SHADERS=1 v -no-parallel test _shaders_test.v: passed
• v -no-parallel test _sokol_formats_test.v _windows_readback_codegen_test.v: passed
• v -no-parallel test _render_test.v _render_filters_test.v _print_pdf_test.v _print_integration_test.v nativebridge/_readback_abi_test.v: passed
• Windows generated-C probes for default Windows and -d sokol_d3d11: passed
• v check-md docs/SHADERS.md docs/WINDOWS.md shaders/README.md: passed
• git diff --check: passed

Windows Testing Requested

D3D11 is still opt-in in this PR. Before making it the default Windows path, it should be tested on real Windows with -d sokol_d3d11, especially:

• examples/showcase.v
• examples/gradient_demo.v
• examples/shadow_demo.v
• examples/blur_demo.v
• examples/image_clip.v
• examples/svg_demo.v
• examples/printing.v
• examples/custom_shader.v fallback behavior

[squidink7]

Just tested this PR and so far no change on my setup, windows still open blank and then close a second later with no output.

[GGRei]

@squidink7 Could you share:

• the exact command you used;
• which gui example you tested;
• whether you were on this PR branch when testing;
• whether the same example behaves differently with and without -d sokol_d3d11;
• if possible, the output of running it from a terminal, even if it is empty plus the exit code.

The most useful comparison would be the same gui example run once normally, then once with -d sokol_d3d11.

[squidink7]

I'm trying to develop a gui program to run on my remote Windows 11 enterprise system at work, so the hardware is a little atypical hence the strange graphics requirements.
After testing a few more examples I got one of them to work but others still exhibit the same behaviour mentioned before.
To answer each question:

• v -cc gcc -d sokol_d3d11 run ..\..\..\.vmodules\gui\examples\showcase.v
• Examples that don't work:
  • showcase
  • blur_demo
  • buttons
  • arrows
• Example that works:
  • text_transform
• I am on this branch yes
• The working examples stop working without the flag, the broken examples behave the same
• The output after running the examples:

C:\Users\me\Downloads\v_windows\v>v -cc gcc -d sokol_d3d11 run ..\..\..\.vmodules\gui\examples\showcase.v

C:\Users\me\Downloads\v_windows\v>v -cc gcc -d sokol_d3d11 run ..\..\..\.vmodules\gui\examples\text_transform.v

C:\Users\me\Downloads\v_windows\v>

If there's any specific examples you'd like me to test and report if they do or don't work please let me know.

[GGRei]

Thanks, that helps.

Since text_transform works with -d sokol_d3d11, the base D3D11 path is working on your setup. The difference seems to be in the gui primitives used by examples like buttons, blur_demo, arrows, and showcase.

As there is no console output, could you check the process exit code right after one failing run?

v -cc gcc -d sokol_d3d11 run ..\..\.vmodules\gui\examples\buttons.v
echo %ERRORLEVEL%

If it is something like 3221225477, that would point to an access violation/crash.

If you have time, testing border_demo, progress_bars, shadow_demo, gradient_demo, and image_clip with the same command style would also help narrow down which rendering primitive triggers it.

[squidink7]

None of the demos you listed work for me, and the return code for all of them is -1073740791, so likely some access violation.

[GGRei]

Thanks, that is a very useful signal.

-1073740791 is 0xC0000409 on Windows, so this looks like a fail-fast / stack-buffer-overrun style crash, not a clean early exit.

Given that text_transform works but buttons, border_demo, progress_bars, shadow_demo, blur_demo, gradient_demo, image_clip, and showcase fail, the issue is probably not the base D3D11 backend itself. It points more toward a shared gui rendering primitive, most likely the generated/SGL pipeline used for rounded rectangles or related built-in gui shaders.

One last useful comparison, only if you have MSVC available: could you try one failing example with -cc msvc too?

v -cc msvc -d sokol_d3d11 run ..\..\.vmodules\gui\examples\buttons.v
echo %ERRORLEVEL%

If gcc and msvc both fail the same way, I will treat it as a gui/D3D11 pipeline issue rather than a MinGW-specific one.

[squidink7]

Unfortunately I don't have msvc, as this is a work machine (and not at a programming company) I'm unable to install any software outside of my user account which means no Visual Studio :(

[GGRei]

@squidink7 Could you please update to the latest version of the PR and try again? The D3D11 custom SGL shader path has been adjusted.

[squidink7]

That fixed it for showcase! I haven't yet tested any of the others but I'll update this if anything breaks.