4 ms·

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

by 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.
- vladharbuz 5y ago
  If at any point you had the motivation to write a quick post or comment detailing your Vulkan recommendations for beginners, I and many others would definitely appreciate it. I've been bitten by exactly the issues you mentioned, and had to figure things out by myself, which was honestly pretty frustrating. I'd be extremely curious to know what other things I could have avoided, since that would make my work a lot more enjoyable!
  - karanbhangui 5y ago
    This is an interesting read from their site: https://blog.mecheye.net/2020/06/modern-graphics-apis-1-intro/ https://blog.mecheye.net/2020/06/modern-graphics-apis-1-intr...
  - Jasper_ 5y ago
    I've had a few blog posts in the works for a little while (as someone else already found!), but they've been on the backburner for a bit as my "main side project" (heh) has switched to my YouTube channel instead.
bitwize 5y ago
> Your Windows bias is showing. :) Pretty much anyone who works in 3D graphics acknowledges that Direct3D is head and shoulders above OpenGL in terms of ease of use, tooling, and support from GPU vendors, and has been for many years now. Even Carmack has come around to this perspective. Really the only reason to use OpenGL is to target Linux, Android, and formerly macOS -- and since game vendors don't really want to do that, now you know why many games and engines support Direct3D exclusively. The thing you have to understand about Microsoft is that "Developers! Developers! Developers!" isn't just a meme to them. They really put the developer experience front and center and it shows. It shows in Direct3D, it showed in Internet Explorer back in the day, and it shows in things like Visual Studio Code today. Sometimes the Microsoft stuff is simply better. > "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. Pretty amazing how "modern" graphics is a fancier version of Atari 7800 graphics! The 7800 didn't have tiles and sprites as such; rather it had per-scanline display lists specifying locations in RAM where graphic bitmaps were stored; the graphics chip pulled the pixel colors from the memory pointed to by the appropriate display list entry as part of the scanout process.

by bsder 5y ago

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.

vladharbuz 5y ago
If at any point you had the motivation to write a quick post or comment detailing your Vulkan recommendations for beginners, I and many others would definitely appreciate it. I've been bitten by exactly the issues you mentioned, and had to figure things out by myself, which was honestly pretty frustrating. I'd be extremely curious to know what other things I could have avoided, since that would make my work a lot more enjoyable!
- karanbhangui 5y ago
  This is an interesting read from their site: https://blog.mecheye.net/2020/06/modern-graphics-apis-1-intro/ https://blog.mecheye.net/2020/06/modern-graphics-apis-1-intr...
- Jasper_ 5y ago
  I've had a few blog posts in the works for a little while (as someone else already found!), but they've been on the backburner for a bit as my "main side project" (heh) has switched to my YouTube channel instead.

bitwize 5y ago

> Your Windows bias is showing. :) Pretty much anyone who works in 3D graphics acknowledges that Direct3D is head and shoulders above OpenGL in terms of ease of use, tooling, and support from GPU vendors, and has been for many years now. Even Carmack has come around to this perspective. Really the only reason to use OpenGL is to target Linux, Android, and formerly macOS -- and since game vendors don't really want to do that, now you know why many games and engines support Direct3D exclusively. The thing you have to understand about Microsoft is that "Developers! Developers! Developers!" isn't just a meme to them. They really put the developer experience front and center and it shows. It shows in Direct3D, it showed in Internet Explorer back in the day, and it shows in things like Visual Studio Code today. Sometimes the Microsoft stuff is simply better. > "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. Pretty amazing how "modern" graphics is a fancier version of Atari 7800 graphics! The 7800 didn't have tiles and sprites as such; rather it had per-scanline display lists specifying locations in RAM where graphic bitmaps were stored; the graphics chip pulled the pixel colors from the memory pointed to by the appropriate display list entry as part of the scanout process.