6 ms·

As a professional graphics programmer at a well-known game studio, who has taught and mentored a lot of people: Direct3D 11 is quite good. D3D12 is a bit more l

As a professional graphics programmer at a well-known game studio, who has taught and mentored a lot of people: Direct3D 11 is quite good. D3D12 is a bit more like Vulkan, but not too far in that direction. In order of recommendation for learners, just rating each API on its own merits without considering other factors like portability: D3D11, Metal, WebGPU, D3D12, OpenGL and Vulkan. OpenGL and Vulkan score last place for similar and opposite reasons: both their APIs are a mess, the debugging and tooling story is still underdeveloped. But while OpenGL has backwards API design that often gives users a wrong impression about how GPUs work, Vulkan instead is much more annoying, requiring the user to cross their T's and dot their I's, while still not giving good guidance towards how they should be structuring their rendering code. I am also eternally annoyed at things like VkFramebuffer which should have never existed (yes I do know it is not required in the latest version). I would rank WebGPU higher (disclaimer: I contribute to the WebGPU spec) since the API is a great intermediate, except WGSL is too new and too underbaked for me to seriously recommend it right now. The native implementations Dawn and wgpu are committed to supporting SPIR-V input, which is how I would recommend using it right now. Happy to answer questions or elaborate on this.

bsder 5y ago
Your Windows bias is showing. :) Personally, I find the Vulkan API to be one of the best designed APIs ever, and the debugging tools on desktop are okay. On Android, I'd say the Vulkan tools are, in fact, quite excellent. I can't compare them to iOS though. The problem with Vulkan and DirectX 12 (which I find to be so close as to be indistinguishable) has nothing to do with their APIs. The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do. A lot of beginners also want to render 2D paths--and graphics APIs for that are horrifically bad. "Modern" graphics is mostly about creating a bunch of low-resolution "geometry buffers" and then scanning every single pixel on the screen only once while building the pixel up from some mathematical combination of those lower resolution buffers. Yes, there are triangles involved at a Platonic level, but many of the triangles are smaller than a pixel. See the Unreal Engine 5 demos: https://www.youtube.com/watch?v=qC5KtatMcUw https://www.youtube.com/watch?v=qC5KtatMcUw It's reached a point that "modern" graphics almost doesn't even want a triangle renderer--it just wants pure access to the massively parallel memory and computation pipeline on the GPU and the ability to smash the results into a framebuffer. Vulkan and DX12 reflect this, so they don't really mesh well with beginners. (I'm being a bit glib, but there really is a massive chasm between "modern" game rendering techniques and the kind of 2D/3D that GUI/CAD/Application developers want to use.)
- Jasper_ 5y ago
  > Your Windows bias is showing. :) In a past life, I actually worked on the Linux graphics stack full-time. I'd say my recommendations are based on years of experience and also mentorship. > On Android, I'd say the Vulkan tools are, in fact, quite excellent. It's possible my knowledge is out of date, but the last time I tried to debug Vulkan on Android, the official Google Android tool was known as GAPId. It was in beta and it crashed with an error message when I tried to use on our game. It seems that Google has deprecated it (of course) and replaced it with this: https://gpuinspector.dev/ https://gpuinspector.dev/ which says "Coming soon: Take a capture of a single frame to step through and profile each individual draw call.". It doesn't yet look like it's anywhere near the level of tooling provided by RenderDoc, the Xcode tools, PIX, or Razor, but I might be wrong. I admittedly haven't worked on Android in a few years, so I'd love to know updates from the tooling perspective here. > The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do. I'm not sure I categorically agree with that. Vulkan, D3D12, and such all have ample support for drawing triangles, DrawIndexed is still a cornerstone of all the APIs. I'm, of course, very familiar with the latest advancements with Nanite and visibility buffers and all that, but these aren't things that I'd say the modern APIs are explicitly designed for. Nanite infamously uses a persistent compute shader kernel for its culling workers that is currently undefined behavior (but works on all devices, and probably will continue working for eternity). D3D12's validation layers are much better managed than the Vulkan ones, generally tend to output more helpful messages, and aren't as slow at doing resource tracking. Vulkan has a lot of dead weight in its APIs, and mistakes that made its way into the spec. Subpasses are over-complicated and do not provide much benefit, even on tilers. Pipeline derivatives are worthless (Qualcomm, who pushed hard for them, found they provided a 2% speedup to pipeline compilation assuming you were using them in a way that only Qualcomm could support, but caching removed the rest of the gains). Push descriptors should basically never be used (they're limited to a single dynamic descriptor, and slow on most IHVs). These are all things that I've seen beginners stumble into, and I have to spent time explaining why these features just aren't helpful. It's harder for a new beginner to know the best course of action, and which 5 of the 7 features should be used when trying to, say, bind resources to a given draw call. I wish the spec was more active in trying to mark bad ideas as such, but the nature of multi-IHV participation means you won't get that kind of filter.
robertwinkler 5y ago
When you say that OpenGL is a mess are you including all of OpenGL? Would your rankings change if you picked say OpenGL 3.3 Core profile or 4.x+ core? With the caveat that I only ever really learned 3.3 (not much reason for most 4.x features for me) and I've never used any of the other APIs, I would say that yes the old OpenGL APIs were terrible. They were a poor mapping to how GPUs worked, especially as time went on, and having all the versions with very different ways of doing things kludged together made it a mess. However, I think what they did at the 3.3/4.0 transition cutting away the old cruft made a huge difference and it feels much cleaner and nicer to use. So with that definition of OpenGL (ie 3.3/4.x core), do you still think it gives an inaccurate impression of how GPUs work? Even if it does to some extent, I stand by my original position. An intro 3D graphics course should use OpenGL 3.3 (or newer) rather than anything else. This lets students use whatever OS they want without bogging them down in unnecessary annoying details for no benefit with Vulkan (or dealing with MoltenVk on Macs, not sure how seamless that is). EDIT: I should add that I know you said you were not factoring in portability in your ranking, but I think you should. Windows has not been as dominant with college students (or young people in general) for a long time. I'm sure I don't need to tell you that macs are hugely popular with college students, and there are a decent minority of linux users too these days (It's certainly way more user friendly than it was when I was in college, having to deal with ndiswrapper for broadcom wifi on my XPS m1530).
- pjmlp 5y ago
  > Windows has not been as dominant with college students (or young people in general) for a long time. That depends pretty much where one is located on the globe.
  - robertwinkler 5y ago
    Even if there are places where it's 95% or even 99% windows, I don't think we should force the 1-5% to change their OS or deal with VMs (if you can even get graphics passthrough working) or have to work in the school computer labs.
    - 5y ago

bsder 5y ago

Your Windows bias is showing. :) Personally, I find the Vulkan API to be one of the best designed APIs ever, and the debugging tools on desktop are okay. On Android, I'd say the Vulkan tools are, in fact, quite excellent. I can't compare them to iOS though. The problem with Vulkan and DirectX 12 (which I find to be so close as to be indistinguishable) has nothing to do with their APIs. The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do. A lot of beginners also want to render 2D paths--and graphics APIs for that are horrifically bad. "Modern" graphics is mostly about creating a bunch of low-resolution "geometry buffers" and then scanning every single pixel on the screen only once while building the pixel up from some mathematical combination of those lower resolution buffers. Yes, there are triangles involved at a Platonic level, but many of the triangles are smaller than a pixel. See the Unreal Engine 5 demos: https://www.youtube.com/watch?v=qC5KtatMcUw https://www.youtube.com/watch?v=qC5KtatMcUw It's reached a point that "modern" graphics almost doesn't even want a triangle renderer--it just wants pure access to the massively parallel memory and computation pipeline on the GPU and the ability to smash the results into a framebuffer. Vulkan and DX12 reflect this, so they don't really mesh well with beginners. (I'm being a bit glib, but there really is a massive chasm between "modern" game rendering techniques and the kind of 2D/3D that GUI/CAD/Application developers want to use.)

Jasper_ 5y ago
> Your Windows bias is showing. :) In a past life, I actually worked on the Linux graphics stack full-time. I'd say my recommendations are based on years of experience and also mentorship. > On Android, I'd say the Vulkan tools are, in fact, quite excellent. It's possible my knowledge is out of date, but the last time I tried to debug Vulkan on Android, the official Google Android tool was known as GAPId. It was in beta and it crashed with an error message when I tried to use on our game. It seems that Google has deprecated it (of course) and replaced it with this: https://gpuinspector.dev/ https://gpuinspector.dev/ which says "Coming soon: Take a capture of a single frame to step through and profile each individual draw call.". It doesn't yet look like it's anywhere near the level of tooling provided by RenderDoc, the Xcode tools, PIX, or Razor, but I might be wrong. I admittedly haven't worked on Android in a few years, so I'd love to know updates from the tooling perspective here. > The main problem is that "modern" graphics is only tangentially related to rendering triangles--and rendering triangles is normally what beginners really want to do. I'm not sure I categorically agree with that. Vulkan, D3D12, and such all have ample support for drawing triangles, DrawIndexed is still a cornerstone of all the APIs. I'm, of course, very familiar with the latest advancements with Nanite and visibility buffers and all that, but these aren't things that I'd say the modern APIs are explicitly designed for. Nanite infamously uses a persistent compute shader kernel for its culling workers that is currently undefined behavior (but works on all devices, and probably will continue working for eternity). D3D12's validation layers are much better managed than the Vulkan ones, generally tend to output more helpful messages, and aren't as slow at doing resource tracking. Vulkan has a lot of dead weight in its APIs, and mistakes that made its way into the spec. Subpasses are over-complicated and do not provide much benefit, even on tilers. Pipeline derivatives are worthless (Qualcomm, who pushed hard for them, found they provided a 2% speedup to pipeline compilation assuming you were using them in a way that only Qualcomm could support, but caching removed the rest of the gains). Push descriptors should basically never be used (they're limited to a single dynamic descriptor, and slow on most IHVs). These are all things that I've seen beginners stumble into, and I have to spent time explaining why these features just aren't helpful. It's harder for a new beginner to know the best course of action, and which 5 of the 7 features should be used when trying to, say, bind resources to a given draw call. I wish the spec was more active in trying to mark bad ideas as such, but the nature of multi-IHV participation means you won't get that kind of filter.

robertwinkler 5y ago

When you say that OpenGL is a mess are you including all of OpenGL? Would your rankings change if you picked say OpenGL 3.3 Core profile or 4.x+ core? With the caveat that I only ever really learned 3.3 (not much reason for most 4.x features for me) and I've never used any of the other APIs, I would say that yes the old OpenGL APIs were terrible. They were a poor mapping to how GPUs worked, especially as time went on, and having all the versions with very different ways of doing things kludged together made it a mess. However, I think what they did at the 3.3/4.0 transition cutting away the old cruft made a huge difference and it feels much cleaner and nicer to use. So with that definition of OpenGL (ie 3.3/4.x core), do you still think it gives an inaccurate impression of how GPUs work? Even if it does to some extent, I stand by my original position. An intro 3D graphics course should use OpenGL 3.3 (or newer) rather than anything else. This lets students use whatever OS they want without bogging them down in unnecessary annoying details for no benefit with Vulkan (or dealing with MoltenVk on Macs, not sure how seamless that is). EDIT: I should add that I know you said you were not factoring in portability in your ranking, but I think you should. Windows has not been as dominant with college students (or young people in general) for a long time. I'm sure I don't need to tell you that macs are hugely popular with college students, and there are a decent minority of linux users too these days (It's certainly way more user friendly than it was when I was in college, having to deal with ndiswrapper for broadcom wifi on my XPS m1530).

pjmlp 5y ago
> Windows has not been as dominant with college students (or young people in general) for a long time. That depends pretty much where one is located on the globe.
- robertwinkler 5y ago
  Even if there are places where it's 95% or even 99% windows, I don't think we should force the 1-5% to change their OS or deal with VMs (if you can even get graphics passthrough working) or have to work in the school computer labs.
  - 5y ago