OpenGL: Use Silk.NET Bindings

[IsaacMarovitz]

Silk.NET bindings are rigorously maintained, backed by the .NET Foundation, and take full advantage of the latest .NET features.

By comparison, OpenTK is rather slow on the uptake and lacks much of the serious backing Silk benefits from.

This PR migrates our OpenGL backend from the OpenTK bindings to Silk.NET. The migration should result in no user-facing changes (maybe a performance uplift if we're lucky).

Changes / Differences in OpenTK and Silk.NET bindings:

• The previous HwCapabilities implementation has been rewritten to follow the Vulkan backend's model as the Silk bindings perform API calls on a given GL instance, not in a static context.
• Unless classes actually need other properties of the OpenGLRenderer class, I've only supplied the current GL instance. We may want to change everything to take the OpenGLRenderer for consistency's sake, but I'll leave that up to the reviewer.
• Silk is a lot more pedantic about integer sizes than OpenTK; as a result, some things have had to be redefined or cast to uint.
  • The most prominent example of this change is with all GL object handles, which are now represented with uint instead of int.
• Silk locks all deprecated (as of 3.3) APIs behind a Legacy name space. This includes enums like GL_CLAMPand GL_QUAD_STRIP. Ryujinx does use these deprecated APIs in some places (as they're still present in Maxwell IR), so we have to use the Legacy namespace instead of the regular one (using both causes horrible redefinitions).

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.1.0+03e2f49-linux_arm64
• ryujinx-Release-1.1.0+03e2f49-linux_x64
• ryujinx-Release-1.1.0+03e2f49-macos_universal
• ryujinx-Release-1.1.0+03e2f49-win_x64

Old GUI (GTK3)

• gtk-ryujinx-Release-1.1.0+03e2f49-linux_arm64
• gtk-ryujinx-Release-1.1.0+03e2f49-linux_x64
• gtk-ryujinx-Release-1.1.0+03e2f49-win_x64

GUI-less (SDL2)

• sdl2-ryujinx-headless-Release-1.1.0+03e2f49-linux_arm64
• sdl2-ryujinx-headless-Release-1.1.0+03e2f49-linux_x64
• sdl2-ryujinx-headless-Release-1.1.0+03e2f49-macos_universal
• sdl2-ryujinx-headless-Release-1.1.0+03e2f49-win_x64

Only for Developers

• ryujinx-Debug-1.1.0+03e2f49-linux_arm64
• sdl2-ryujinx-headless-Debug-1.1.0+03e2f49-linux_arm64
• gtk-ryujinx-Debug-1.1.0+03e2f49-linux_arm64
• ryujinx-Debug-1.1.0+03e2f49-linux_x64
• sdl2-ryujinx-headless-Debug-1.1.0+03e2f49-linux_x64
• gtk-ryujinx-Debug-1.1.0+03e2f49-linux_x64
• ryujinx-Debug-1.1.0+03e2f49-macos_universal
• sdl2-ryujinx-headless-Debug-1.1.0+03e2f49-macos_universal
• ryujinx-Debug-1.1.0+03e2f49-win_x64
• sdl2-ryujinx-headless-Debug-1.1.0+03e2f49-win_x64
• gtk-ryujinx-Debug-1.1.0+03e2f49-win_x64

[TSRBerry]

I don't quite see the benefits of replacing OpenTK now. It's working fine and it's not like we are held back by it in any way.
Without having the required experience with our GPU code I can only say so much, but reading your description alone makes me think this is not worth the effort.

Is there a special reason you did this? Did you want to do something that wasn't possible with OpenTK?

[IsaacMarovitz]

Is there a special reason you did this? Did you want to do something that wasn't possible with OpenTK?

I initially started looking into this as I was interested in trying Silk Windowing over SPB (Less for us to maintain, and would resolve some of the jank/confusion of using SPB as talked about with yam on the Discord).

The bindings are mostly pretty similar, but there are benefits to the Silk bindings.

• Better memory handling when communicating with Vulkan (Silk takes advantage of modern C# features like Spans more effectively). As I've not resolved all the issues yet, I've been unable to do performance testing, but it's possible it could amount to something.
• Better handling of the OpenGL API context (OpenTK used a static context). While this is not a necessity, it is more in line with the Vulkan backend and Ryujinx's general philosophies.

[IsaacMarovitz]

This function should be rewritten not to use deprecated OpenGL calls, as they will prevent Renderdoc from performing a capture. This was an issue with the previous HwCapabilities implementation too, but due to the Lazy nature, it would only get triggered if a game requested a draw with quads. As all caps are now init'd at the start of the Renderer, this function gets called regardless of whether the game requests quads or not.

Another route would be to remove the use of GL_QUAD and GL_QUAD_STRIP entirely and just use the existing vertex remapping draw calls when they are requested (similar to Vulkan backend).

I'm personally more in favour of that approach as it gives us control over the conversion of quads to triangles, and were not subject to potential poor driver implementation of this deprecated feature.

[gdkchan]

I don't think there is a way to make it not use deprecated features. We'd have to remove it and assume that quads are never supported. I think ideally it should just check if renderdoc is attached, and disable it in this case.

There is also alpha test which I believe is deprecated too, but I think we always assume it is supported right now.

[IsaacMarovitz]

Tested with: Balatro, Hat in Time, Deltarune, Kirby & Forgotten Land, MK8D, TOTK (broken cause asahi), P5R, Arceus, Scott Pilgrim, Undertale, Mania, Wonder, and ACNH.

[sunshineinabox]

Currently crashing on Windonws in GTK and Avalonia when emulation is stopped. You might have to bind the context with INativeContext that is how I was able to stop it IIRC, but I will have to confirm later.

Also am not sure if threaded rendering is working correctly, because the context is passed before the background context is created. Solving this might solve GTK crash also.

EDIT: Will post logs later.