| ▲ | vblanco 6 days ago |
| This is a fantastic article that demonstrates how many parts of vulkan and DX12 are no longer needed. I hope the IHVs have a look at it because current DX12 seems semi abandoned, with it not supporting buffer pointers even when every gpu made on the last 10 (or more!) years can do pointers just fine, and while Vulkan doesnt do a 2.0 release that cleans things, so it carries a lot of baggage, and specially, tons of drivers that dont implement the extensions that really improve things. If this api existed, you could emulate openGL on top of this faster than current opengl to vulkan layers, and something like SDL3 gpu would get a 3x/4x boost too. |
|
| ▲ | pjmlp 6 days ago | parent | next [-] |
| DirectX documentation is on a bad state currently, you have the Frank Lunas's books, which don't cover the latest improvements, and then is hunting through Learn, Github samples and reference docs. Vulkan is another mess, even if there was a 2.0, how are devs supposed to actually use it, especially on Android, the biggest consumer Vulkan platform? |
|
| ▲ | _bohm 6 days ago | parent | prev | next [-] |
| I'm surprised he made no mention of the SDL3 GPU API since his proposed API has pretty significant overlap with it. |
|
| ▲ | tadfisher 6 days ago | parent | prev | next [-] |
| Isn't this all because PCI resizable BAR is not required to run any GPU besides Intel Arc? As in, maybe it's mostly down to Microsoft/Intel mandating reBAR in UEFI so we can start using stuff like bindless textures without thousands of support tickets and negative reviews. I think this puts a floor on supported hardware though, like Nvidia 30xx and Radeon 5xxx. And of course motherboard support is a crapshoot until 2020 or so. |
| |
| ▲ | vblanco 6 days ago | parent [-] | | This is not really directly about resizable BAR. you could do mostly the same api without it. Resizable bar simplifies it a little bit because you skip manual transfer operations, but its not completely required as you can write things to a cpu-writeable buffer and then begin your frame with a transfer command. Bindless textures never needed any kind of resizable BAR, you have been able to use them since early 2010s on opengl through an extension. Buffer pointers also have never needed it. |
|
|
| ▲ | exDM69 5 days ago | parent | prev | next [-] |
| > tons of drivers that dont implement the extensions that really improve things. This isn't really the case, at least on desktop side. All three desktop GPU vendors support Vulkan 1.4 (or most of the features via extensions) on all major platforms even on really old hardware (e.g. Intel Skylake is 10+ years old and has all the latest Vulkan features). Even Apple + MoltenVK is pretty good. Even mobile GPU vendors have pretty good support in their latest drivers. The biggest issue is that Android consumer devices don't get GPU driver updates so they're not available to the general public. |
| |
| ▲ | pjmlp 5 days ago | parent [-] | | Neither do laptops, where not using the driver from the OEM with whatver custom code they added can lead to interesting experiences, like power configuration going bad, not able to handle the mixed GPU setups, and so on. |
|
|
| ▲ | kllrnohj 6 days ago | parent | prev | next [-] |
| No longer needed is a strong statement given how recent the GPU support is. It's unlikely anything could accept those minimum requirements today. But soon? Hopefully |
| |
| ▲ | jsheard 6 days ago | parent [-] | | Those requirements more or less line up with the introduction of hardware raytracing, and some major titles are already treating that as a hard requirement, like the recent Doom and Indiana Jones games. | | |
| ▲ | kllrnohj 6 days ago | parent | next [-] | | Only if you're ignoring mobile entirely. One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs. | | |
| ▲ | pjmlp 5 days ago | parent | next [-] | | It is not unified, when the first thing an application has to do is to find out if their set of extension spaghetti is available on the device. | |
| ▲ | m-schuetz 5 days ago | parent | prev | next [-] | | On the contrary, I would say this is the main thing Vulkan got wrong and the main reason whe the API is so bad. Desktop and mobile are way too different for a uniform rendering API. They should be two different flavours with a common denominator. OpenGL and OpenGL ES were much better in that regard. | | |
| ▲ | HelloNurse 4 days ago | parent [-] | | It is unreasonable to expect to run the same graphics code on desktop GPUs and mobile ones: mobile applications have to render something less expensive that doesn't exceed the limited capabilities of a low-power device with slow memory. The different, separate engine variants for mobile and desktop users, on the other hand, can be based on the same graphics API; they'll just use different features from it in addition to having different algorithms and architecture. | | |
| ▲ | flohofwoe 4 days ago | parent [-] | | > they'll just use different features from it in addition to having different algorithms and architecture. ...so you'll have different code paths for desktop and mobile anyway. The same can be achieved with a Vulkan vs VulkanES split which would overlap for maybe 50..70% of the core API, but significantly differ in the rest (like resource binding). | | |
| ▲ | kllrnohj 4 days ago | parent [-] | | But they don't actually differ, see the "no graphics API" blog post we're all commenting on :) The primary difference between mobile & desktop is performance, not feature set (ignoring for a minute the problem of outdated drivers). And beyond that if you look at historical trends, mobile is and always has been just "desktop from 5-7 years ago". An API split that makes sense now will stop making sense rather quickly. | | |
| ▲ | m-schuetz 3 days ago | parent [-] | | Different features/architecture is precisely the issue with mobile, be it due to hardware constraints or due to lack in deiver support. Render passes were only bolted into Vulkan because of mobile tiler GPUs, they never made any sense for desktop GPUs and only made Vulkan worse for desktop graphics development. And this is the reason why mobile and desktop should be separate graphics APIs. Mobile is holding desktop back not just feature wise, it also fucks up the API. |
|
|
|
| |
| ▲ | eek2121 5 days ago | parent | prev | next [-] | | Mobile is getting RT, fyi. Apple already has it (for a few generations, at least), I think Qualcomm does as well (I'm less familiar with their stuff, because they've been behind the game forever, however the last I've read, their latest stuff has it), and things are rapidly improving. Vulkan is the actual barrier. On Windows, DirectX does an average job at supporting it. Microsoft doesn't really innovate these days, so NVIDIA largely drives the market, and sometimes AMD pitches in. | | |
| ▲ | pjmlp 4 days ago | parent [-] | | Where do you think many DirectX features came from? It has been mostly NVidia in collaboration with Microsoft, even HLSL traces back to Cg. |
| |
| ▲ | flohofwoe 5 days ago | parent | prev | next [-] | | > One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs. In hindsight it really would have been better to have a separate VulkanES which is specialized for mobile GPUs. | | |
| ▲ | pjmlp 5 days ago | parent [-] | | Apparently in many Android devices it is still better to target OpenGL ES than Vulkan due to driver quality, outside Samsung and Google brands. |
| |
| ▲ | jsheard 6 days ago | parent | prev [-] | | Eh, I think the jury is still out on whether unifying desktop and mobile graphics APIs is really worth it. In practice Vulkan written to take full advantage of desktop GPUs is wildly incompatible with most mobile GPUs, so there's fragmentation between them regardless. | | |
| ▲ | kllrnohj 6 days ago | parent | next [-] | | It's quite useful for things like skia or piet-gpu/vello or the general category of "things that use the GPU that aren't games" (image/video editors, effects pipelines, compute, etc etc etc) | | |
| ▲ | Groxx 6 days ago | parent | next [-] | | would it also apply to stuff like the Switch, and relatively high-end "mobile" gaming in general? (I'm not sure what those chips actually look like tho) there are also some arm laptops that just run Qualcomm chips, the same as some phones (tablets with a keyboard, basically, but a bit more "PC"-like due to running Windows). AFAICT the fusion seems likely to be an accurate prediction. | | |
| ▲ | deliciousturkey 5 days ago | parent [-] | | Switch has its own API. The GPU also doesn't have limitations you'd associate with "mobile". In terms of architecture, it's a full desktop GPU with desktop-class features. | | |
| ▲ | kllrnohj 5 days ago | parent [-] | | well, it's a desktop GPU with desktop-class features from 2014 which makes it quite outdated relative to current mobile GPUs. The just released Switch 2 uses an Ampere-based GPU, which means it's desktop-class for 2020 (RTX 3xxx series), which is nothing to scoff about but "desktop-class features" is a rapidly moving target and the Switch ends up being a lot closer to mobile than it does to desktop since it's always launching with ~2 generations old GPUs. | | |
| ▲ | deliciousturkey a day ago | parent | next [-] | | The context was Only if you're ignoring mobile entirely. One of the things Vulkan did which would be a shame to lose is it unified desktop and mobile GPU APIs. In this context, both old Switch and Switch 2 have full desktop-class GPUs. They don't need to care about the API problems that mobile vendors imposed to Vulkan. | |
| ▲ | pjmlp 5 days ago | parent | prev [-] | | Still beats the design of all Web 3D APIs, and has much better development tooling, let that sink in how behind they are. |
|
|
| |
| ▲ | pjmlp 4 days ago | parent | prev | next [-] | | Those already have their own abstraction API, and implementing a RHI isn't a big issue as FOSS circles make it to be. | |
| ▲ | jsheard 6 days ago | parent | prev [-] | | I suppose that's true, yeah. I was focusing too much on games specifically. |
| |
| ▲ | ablob 5 days ago | parent | prev | next [-] | | I feel like it's a win by default.
I do like to write my own programs every now and then and recently there's been more and more graphics sprinkled into them.
Being able to reuse those components and just render onto a target without changing anything else seems to be very useful here.
This kind of seamless interoperability between platforms is very desirable in my book.
I can't think of a better approach to achieve this than the graphics API itself. Also there is no inherent thing that blocks extensions by default.
I feel like a reasonable core that can optionally do more things similar to CPU extensions (i.e. vector extensions) could be the way to go here. | |
| ▲ | eek2121 5 days ago | parent | prev | next [-] | | I definitely disagree here. What matters for mobile is power consumption. Capabilities can be pretty easily implemented...if you disagree, ask Apple. They have seemingly nailed it (with a few unrelated limitations). Mobile vendors insisting on using closed, proprietary drivers that they refuse to constantly update/stay on top of is the actual issue. If you have a GPU capable of cutting edge graphics, you have to have a top notch driver stack. Nobody gets this right except AMD and NVIDIA (and both have their flaws). Apple doesn't even come close, and they are ahead of everyone else except AMD/NVIDIA. AMD seems to do it the best, NVIDIA, a distant second, Apple 3rd, and everyone else 10th. | | |
| ▲ | aleph_minus_one 4 days ago | parent [-] | | > If you have a GPU capable of cutting edge graphics, you have to have a top notch driver stack. Nobody gets this right except AMD and NVIDIA (and both have their flaws). Apple doesn't even come close, and they are ahead of everyone else except AMD/NVIDIA. AMD seems to do it the best, NVIDIA, a distant second, Apple 3rd, and everyone else 10th. What about Intel? | | |
| ▲ | pjmlp 4 days ago | parent [-] | | It is quite telling how good their iGPUs are at 3D that no one counts them in. I remember there was time about 15 years ago, they were famous for reporting OpenGL capabilities as supported, when they were actually only available as software rendering, which voided any purpose to use such features in first place. | | |
| ▲ | aleph_minus_one 4 days ago | parent [-] | | I know that in the past (such as your mentioned 15 years ago) Intel GPUs did have driver issues. > It is quite telling how good their iGPUs are at 3D that no one counts them in. I'm not so certain about this: in > https://old.reddit.com/r/laptops/comments/1eqyau2/apuigpu_ti... APUs/iGPUs are compared, and here Intel's integrated GPUs seem to be very competitive with AMD's APUs. --- You of course have to compare dedicated graphics cards with each other, and similarly for integrated GPUs, so let's compare (Intel's) dedicated GPUs (Intel Arc), too: When I look at > https://www.tomshardware.com/reviews/gpu-hierarchy,4388.html the current Intel Arc generation (Intel-Arc-B, "Battlemage") seems to be competitive with entry-level GPUs of NVidia and AMD, i.e. you can get much more powerful GPUs from NVidia and AMD, but for a much higher price. I thus clearly would not call Intel's dedicated GPUs to be so bad "at 3D that no one counts them in". |
|
|
| |
| ▲ | 01HNNWZ0MV43FF 5 days ago | parent | prev [-] | | If the APIs aren't unified, the engines will be, since VR games will want to work on both standalone headsets and streaming headsets |
|
| |
| ▲ | tjpnz 6 days ago | parent | prev [-] | | Doom was able to drop it and is now Steam Deck verified. | | |
| ▲ | nicolaslem 5 days ago | parent | next [-] | | Little known fact, the Steam Deck has hardware ray tracing, it's just so weak as to be almost non-existent. | |
| ▲ | 6 days ago | parent | prev [-] | | [deleted] |
|
|
|
|
| ▲ | torginus 5 days ago | parent | prev | next [-] |
| It's weird how the 'next-gen' APIs will turn out to be failures in many ways imo. I think still as sizeable amount of graphics devs still stuck to the old way of doing things. I know a couple graphics wizards (who work on major AAA titles) who never liked Vulkan/DX12, and many engines haven't really been rebuilt to accomodate the 'new' way of doing graphics. Ironically a lot of the time, these new APIs end up being slower in practice (something confirmed by gaming benchmarks), probably exactly because of the issues outlined in the article - having precompiled 'pipeline states', instead of the good ol state machine has forced devs to precompile a truly staggering amount of states, and even then sometimes compilation can occur, leading to these well known stutters. The other issue is synchronization - as the article mentions how unnecessarily heavy Vulkan synchronization is, and devs aren't really experts or have the time to figure out when to use what kind of barrier, so they adopt a 'better be safe than sorry approach', leading to unneccessary flushes and pipeline stalls that can tank performance in real life workloads. This is definitely a huge issue combined with the API complexity, leading many devs to use wrappers like the aforementioned SDL3, which is definitely very conservative when it comes to synchronization. Old APIs with smart drivers could either figure this out better, or GPU driver devs looked at the workloads and patched up rendering manually on popular titles. Additionally by the early to mid 10s, when these new APIs started getting released, a lot of crafty devs, together with new shader models and OpenGL extensions made it possible to render tens of thousands of varied and interesting objects, essentially the whole scene's worth, in a single draw call. The most sophisticated and complex of these was AZDO, which I'm not sure made it actually into a released games, but even with much less sophisticated approaches (and combined with ideas like PBR materials and deferred rendering), you could pretty much draw anything. This meant much of the perf bottleneck of the old APIs disappeared. |
| |
| ▲ | eek2121 5 days ago | parent [-] | | I think the big issue is that there is no 'next-gen API'. Microsoft has largely abandoned DirectX, Vulkan is restrictive as anything, Metal isn't changing much beyond matching DX/Vk, and NVIDIA/AMD/Apple/Qualcomm aren't interested in (re)-inventing the wheel. There are some interesting GPU improvements coming down the pipeline, like a possible OoO part from AMD (if certain credible leaks are valid), however, crickets from Microsoft, and NVIDIA just wants vendor lock-in. Yes, we need a vastly simpler API. I'd argue even simpler than the one proposed. One of my biggest hopes for RT is that it will standardize like 80% of stuff to the point where it can be abstracted to libraries. It probably won't happen, but one can wish... | | |
| ▲ | aleph_minus_one 4 days ago | parent [-] | | > Microsoft has largely abandoned DirectX What does Microsoft then intend to use to replace the functionality that DirectX provides? |
|
|
|
| ▲ | PeterStuer 5 days ago | parent | prev [-] |
| Still have some 1080's in gaming machines going strong. But as even nVidea retired support I guess it is time to move on. |
