feat: Filled in basic Graphics Output implementation for Vulkan via SDL3-CS

[Feralnex]

PR Details

Filled in basic Graphics Output implementation for Vulkan API via SDL3-CS. In general Vulkan doesn't expose current display mode or bounds of the display or even native handle to the monitor like in DXGI. In the end I've managed to implement a trick to achieve that.

The trick is to create hidden window on each display that SDL3 returns and create on each one of them a hidden window. Then to determine if GPU can render to specific display a surface needs to be created for Vulkan to render to and check if it supports rendering to that window on this display and if it does then also fetch supported formats while at it. Afterwards all is cleaned up of course.

I could use Silk.Net.SDL but current version lacks details about Numerator and Denominator of the Refresh Rate when it comes to display modes.

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.

[Ethereal77]

Please note that GraphicsProfile is not a DX concept (it is not FeatureLevel, even though it follows a similar naming), but a Stride concept. It was used more in the past when we had to support D3D 9, OpenGL ES, D3D 10, etc., as some of those did not support certain output formats, or some combinations of parameters.

If the Vulkan implementation supports all GraphicsProfiles, I'd say so without referencing Direct3D feature levels, to avoid confusion.

[Feralnex]

I fully agree so I updated method documentation and comment

[Feralnex]

After merging this PR I'll update Vortice.Vulkan to newest version. My prayers have been answered..

[xen2]

Sorry for late feedback.

Ideally we don't want to pull a dep (of something we already use) just for this, it should use the same lib & bindings (either Silk.NET.SDL, probably easier, or switch everything to SDL3-CS but it would be large work and they lack a few platforms recently added such as iossimulator-arm64).

Also, no way to get those info without creating a hidden window?
If not, how long does it add at runtime startup? (fine if a few msec, but wondering if it's much more?).
Note: SDL3-CS loading/JIT probably adds a lot there too.

[Feralnex]

@xen2 Thanks for feedback. I was tired of waiting for Silk.Net 3 where You could finally get proper frequency per display mode rather than rounded values of integers (in SDL3 we have cross platform frequency provided in Numerator and Denominator) and tbh I don't remember if there weren't other things that made me use SDL3-CS as it was quite some time ago.

I spend quite some time on research and I couldn't find any other way to achiev it other than this little hack - creating that hidden window.

Regarding the timings I didn't do them when creating the PR, I could come back to it next week as this week I have pretty occupied already. I will take care of the conflicts too if we want to go with this solution (at least for now).

[Feralnex]

@xen2 I did some primitive timings and from the moment of launching the NewGame project until first Update breakpoint hit in BasicCameraController I get on my branch delays of around 150ms-200ms (sometimes even a lot less but these were the most common ones) - might be because of the other processes too but indeed using SDL3 for sure introduces some delays (not mentioning the probably necessary evil - hidden window). I could probably switch to Silk.Net but we won't get precise refresh rates until they release SDL3.

Regarding if it's necessary to create hidden window - I'm open to suggestions, I couldn't find any better option.