Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
https://github.com/Planimeter/game-engine-3d/blob/main/src/g...
Try reading the above implementation. It’s a Hello, Triangle with SDL. Should compile out of the box on Windows.
Not SDL2, but GLFW has something like that under the tests/ directory:
https://github.com/glfw/glfw/blob/master/tests/triangle-vulk...
I wonder if using your library (https://github.com/floooh/sokol) instead of OpenGL will alleviate some of these issues for newcomers! There's already a sokol port of the learnopengl.com code (https://github.com/GeertArien/learnopengl-examples), so it shouldn't be too hard to match between the tutorial articles and these.
I wonder if using your library (https://github.com/floooh/sokol) instead of OpenGL will alleviate some of these issues for newcomers! There's already a sokol port of the learnopengl.com code (https://github.com/GeertArien/learnopengl-examples), so it shouldn't be too hard to match between the tutorial articles and these.
dawn is the WebGPU backend in chromium, while wgpu is the WebGPU backend for firefox written in Rust. wgpu is seeing a lot of use in non-browser uses; there are some examples on their website.
https://wgpu.rs/
SPIR-V is an intermediate bytecode format. That bytecode is the data that you use in the Vulkan API, and under the hood your graphics drivers compile that bytecode into the device-specific native shader binary that runs on the graphics hardware.
Vulkan doesn't come with any tools to generate that bytecode though. Foreign shader language (like HLSL, GLSL, etc) to SPIR-V compilers exist, and various graphics toolchains can generate SPIR-V. https://github.com/KhronosGroup/SPIRV-Tools does have tools to validate and optimizing SPIR-V bytecode.
There's standardized C API which is both implemented by Dawn and wgpu.rs:
https://github.com/webgpu-native/webgpu-headers/blob/main/we...
...and this standardized API would also enable other independent native implementations.
There's even thought put into the API being extensible via 'struct chaining', this is how the native implementations also accept SPIRV shader bytecode instead of just WGSL shader source code.
Apple -> MoltenVK is an emulation layer and doesn't give you as much control as using Metal directly.
Nintendo and Sony prefer their own APIs, NVN and LibGNM, and AIUI Vulkan is a second-class API on those platforms which does not offer as much power, it is widely understood studios use NVN and LibGNM to get access to the real hardware on those platforms.
Windows/AMD/NVidia/Intel -> HW manufacturers tend to prototype and release new features with D3D first and then 'backport' them to Vulkan after a while. DirectX 12 for example had mesh shaders for over 2 years before Vulkan got a vendor neutral extension for them[0]
Android and Linux are the only platform where Vulkan is a first-class citizen.
You could maybe argue Nvidia treats Vulkan as a first-class citizen because they tend to have vendor-specific Vulkan extensions for the latest features available before anyone else. But otherwise, no, Vulkan is not a first-class API anywhere except Linux and Android.
Graphics API wars are alive and well.
[0] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423