Hacker News new | past | comments | ask | show | jobs | submit login

Thanks for the clarification. From the sparse documentation of SDL_GPU it was somewhat difficult to understand which parts are part of the SDL 3 merge, and which parts are something else.

I did find an example of using the GPU API, but I didn't see any mention of selecting a backend (Vk, etc.) in the example - is this possible or is the backend selected e.g. based on the OS?




> is this possible or is the backend selected e.g. based on the OS?

Selected in a reasonable order by default, but can be overridden.

There are three ways to do so:

- Set the SDL_HINT_GPU_DRIVER hint with SDL_SetHint() [1].

- Pass a non-NULL name to SDL_CreateGPUDevice() [2].

- Set the SDL_PROP_GPU_DEVICE_CREATE_NAME_STRING property when calling SDL_CreateGPUDeviceWithProperties() [3].

The name can be one of "D3D11", "D3D12", "Metal" or "Vulkan" (case-insensitive). Setting the driver name for NDA platforms would presumably work as well, but I don't see why you would do that.

The second method is just a convenient, albeit limited, wrapper for the third, so that the user does not have to create and destroy their own properties object.

The global hint takes precedence over the individual properties.

[1] https://wiki.libsdl.org/SDL3/SDL_HINT_GPU_DRIVER

[2] https://wiki.libsdl.org/SDL3/SDL_CreateGPUDevice

[3] https://wiki.libsdl.org/SDL3/SDL_CreateGPUDeviceWithProperti...


> The global hint takes precedence over the individual properties.

This seems like a bad design - when I explicitly pass something to a function I expect it to be honored and not overwritten by some global state, especially one that can come from an environment variable.

I'm not even sure how a hint or a null parameter makes sense at all here since the program will be responsible for passing the shaders in the correct format (which isn't even checked outside of debug mode lol). There also doesn't seem to even be a way for the application to check what shader format is supported by the mystery device it was handed against its wishes, outside of getting the name and then mapping that back to supported shaders which may or may not change in the future.

Having two entry points for device creation with widly different argument types (one using flags, one using string-based properties with comically long names you might find the Java world) is also not something I would have expected in a newly designed API - that kind of uglyness is usually the result of changing requirements that the initial entry point did not forsee.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: