fix: map GraphicsProfile.Level_11_2 to a valid Direct3D feature level

[sasvdw]

PR Details

Summary — GraphicsProfile.Level_11_2 is unusable on the Direct3D backends; this maps it to the
real feature level it represents (FL 11_1) so it behaves like every other profile.

Description — GraphicsProfile.Level_11_2 = 0xB200 has no corresponding native Direct3D feature
level (real levels jump 11_1 (0xB100) → 12_0 (0xC000); Direct3D 11.2 was an API revision that runs
on FL 11_1 hardware, not a new feature level). GraphicsProfileHelper.ToFeatureLevel raw-cast the
profile to the non-existent 0xB200, so selecting Level 11.2 crashed at startup on Direct3D11
(rejected in GraphicsAdapter.IsProfileSupported) and Direct3D12 (passed its unconditional
IsProfileSupported, then failed at CreateDevice(0xB200)), while Vulkan — which ignores the
profile — ran.

Three Direct3D code paths change; the GraphicsProfile enum is untouched, so this is non-breaking
with no serialization impact:

• GraphicsProfileHelper.ToFeatureLevel maps Level_11_2 → 11_1 instead of emitting 0xB200.
  Every other profile equals a real D3DFeatureLevel and keeps the direct cast.
• GraphicsAdapter.Direct3D.cs (Direct3D11 IsProfileSupported) resolves the feature level via
  ToFeatureLevel() rather than a raw cast, so the exact-match check tests the real FL 11_1.
• ShaderCompiler.cs (ShaderProfileFromGraphicsProfile) lists Level_11_2 alongside
  11_0/11_1 in the shader-model 5_0 case so it no longer throws.

Direct3D11 and Direct3D12 now accept Level_11_2 and run at FL 11_1, matching Vulkan. Legitimate
rejection is preserved: profiles a device genuinely cannot provide (e.g. Level_11_x on FL10-only
hardware) still fail the capability check as before — only the invalid-value failure is removed.

Motivation and context — see #3301. The failure is hardware-independent: a WARP
software-renderer proof (in the repro) shows WARP reporting FL 12_1 yet rejecting 0xB200 with
E_INVALIDARG while accepting 0xB100. The mapping has been wrong since the 2018 open-source commit;
a June-2025 documentation pass added the [Display("Level 11.2 ~ …")] tooltip that makes the unusable
option look legitimate in Game Settings.

Related Issue

Fixes #3301. Repro (minimal code-only game + WARP proof):
https://github.com/sasvdw/stride-graphicsprofile-level112-repro

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

Validation status (kept honest — check the boxes above as each is satisfied):

• Docs: no documentation change required — the profile simply works now, and the existing tooltip
  becomes accurate.
• Tests: sources/engine/Stride.Graphics.Tests/TestGraphicsProfileHelper.cs covers the mapping —
  Level_11_2 resolves to FL 11_1 (not 0xB200), and every profile maps to a defined
  D3DFeatureLevel. Verified red/green (both facts fail on the raw cast, pass on the fix).
• Build: Stride.Graphics (Direct3D11 + Direct3D12) and Stride.Shaders.Compilers build clean;
  the full test suite runs in CI.
• Editor: outstanding — build + run the editor with a project set to Level 11.2 to confirm it
  launches (this is the mandatory personal-testing step before marking the PR ready).

[github-actions]

🤖 Draft PR — automatic CI is skipped to save runner minutes.

• Mark the PR ready for review to run the full automatic CI — or add a ci-run-on-draft label to run it now without leaving draft.
• Or arm a specific opt-in suite: ci-enduser, ci-editor, ci-ios, ci-android.

[Ethereal77]

LGTM. Good catch!

A little nitpick: The comments look a bit too verbose for my taste (even though I tend to write big explanatory comments 😁)

[sasvdw]

@Ethereal77, happy to take suggestions... Was a really tough one from a comments point of view. There's a genuine footgun highlighted in the comments that is bound to cause issues if someone just looks at the changes at surface level.

[Ethereal77]

I agree with you. Better documentation is always preferable, specially around conflicting code. But, I think that if you have already created and used a helper ToFeatureLevel(), and that helper already documents why the mapping 11_2 is special, then the call site of the helper does not need the same comment, as the potential bug is not there anymore.

In the shader compiler, as it does not use the helper, the comment makes sense.

[sasvdw]

@Ethereal77, after further consideration, I think I've landed on something more concise while also adding tests to ensure everything stays up to date.

I also removed the comment from the shader compiler because it's an entirely different case and should be straightforward knowledge for anyone with an understanding of this domain.

[Ethereal77]

👍 Looks nice