search

libsdl-org / SDL

Simple Directmedia Layer
https://libsdl.org
zlib License
9.45k stars 1.76k forks source link

GPU: Access to platform-specific objects #10876

Open Helco opened 3 days ago

Helco commented 3 days ago

I would like to propose additional APIs for the GPU subsystem that allows an application developer to access the internal platform-specific objects similar to how SDL_GetWindowProperties allows access to objects like the HWND on Windows or the Cocoa window pointer on MacOS. I have two concrete use-cases for this in mind:

  1. Use API-specific features not supported by SDL_gpu
  2. Enable usage of internal profilers/debuggers like Remotery
thatcosmonaut commented 2 days ago

I may end up being forced to expose at least the device handle to allow hardware video decoding, but I will not be happy about it.

I wouldn't call wanting to use unspecified unsupported features a "concrete use case". I would literally prefer you to just copy paste the backend implementations into your project directly than try to get random hardware features interoperating with SDL GPU. This always turns out to be a mess for everyone involved and I don't want to be involved with the support issues that will inevitably result from this decision.

Helco commented 2 days ago

I would argue otherwise: It is not realistic to create a common subset of 3D graphics that both works on every platform that SDL as a whole wants to support and provides all features applications developers would want. With hardware video decoding you mentioned exactly such a feature that is not in scope for SDL_gpu right now but desirable for enough people to allow usage at all when also using SDL_gpu.

With the window properties there is precedent where the library provides access that can very well cause problems if not used carefully in conjunction with SDLs own windowing functions. Similarly SDL_Renderer was already used in combination e.g. with direct OpenGL in the past. Support of related issues is also clear: If you mess up internal stuff by using the internal objects - don't blame SDL for it. Which is reasonable with SDL denoting itself as "library designed to provide low level access".

TheSpydog commented 2 days ago

The thing is, modern graphics APIs are extremely fragile. You can't just grab a device handle and go wild with it like you could in the GL/D3D11 days. For Vulkan and D3D12, you have command buffer memory barriers and resource states, submit/present synchronization, resource cycling (there's not a 1:1 correspondence with an SDL_GPUTexture and the underlying texture handle), descriptor heaps/pools, and all sorts of other gotchas to worry about.

If you attempt to write any serious extension to the API we provide, you'll almost certainly end up needing more information about SDL_GPU's internal state. For instance, "what was this texture's previous resource state so I can barrier it appropriately"? In order for you to get that information and not have to make hardcoded assumptions about the backend implementation (which may change!), we'd need to expose more internal information. At some point all our guts would fall out and you'd be stuck essentially doing what cosmonaut said, forking our driver with extra steps. You might as well just go that route from the get-go.

All that said... I'm not opposed to exposing a very specific subset of device handles for the sake of Remotery and friends. That seems like it'd be generally helpful and not particularly invasive.

thatcosmonaut commented 2 days ago

@TheSpydog is right, and to add to that...

I would argue otherwise: It is not realistic to create a common subset of 3D graphics that both works on every platform that SDL as a whole wants to support and provides all features applications developers would want.

You're absolutely right, and we have done our best to identify a broad, powerful feature set that is supported by a wide range of hardware and operating systems. If you need something outside of that scope you are an advanced user and are much better served not using our abstraction. The only benefit SDL GPU would provide you in that instance is that we already wrote a bunch of code that works, and you can much more easily benefit from that by forking our backends as a starting point instead of using a janky interop procedure. You will only benefit from our abstraction insofar as you are willing to be bound by the limits of our abstraction.