Hardly any specific resources exist for learning either Vulkan or DirectX 12. They were both introduced years ago, yet hardly any questions, just really no interest it seems among novice/intermediate low-level API coders.

I'm unable to experiment myself. I only have a Fermi (don't laugh). I'm really peeved that it was announced that Fermi would have Vulkan support and Nvidia didn't follow through. I'm thinking about getting a new GPU just for messing around with Vulkan/DX12.

I just want some clarity as to why such underwhelming interest from the indie community.

It seems gfx API questions have declined in general with more people using U engines, but i think low level is as popular as high level.

No RT support for DX11/GL implies high level has no future anyways, so nothing wrong with going DX12/VK.

Using VK personally i can say it is more work, but i'm very happy about the speed up i got.

JoeJ said:
No RT support for DX11/GL implies high level has no future anyways

My use of ‘low-level’ was meant as directing using the APIs, not indirectly as using a framework or engine.

Your quote here makes it sound to me like one could only use RT on DX11/GL if directly using those APIs. Does your meaning of low-level differ from mine?

JoeJ said:
Using VK personally i can say it is more work, but i'm very happy about the speed up i got.

Are you seeing this with RT specifically?

fleabay said:
My use of ‘low-level’ was meant as directing using the APIs, not indirectly as using a framework or engine. Your quote here makes it sound to me like one could only use RT on DX11/GL if directly using those APIs. Does your meaning of low-level differ from mine?

I'm totally confused now as well : )

What i meant is simply: DXR can be used only from DX12 / VK (low level), but not at all from DX11 or OpenGL (high level).

It seems neither Microsoft nor NVidia have interest on updating high level APIs.

And this makes sense, because after all legacy game engines have made the transition to low level, the only people that keep using high level APIs are hobby programmers / newbies for learning purposes.

Also, game engines increase in complexity but decrease in number. Big engines that make the real money are maintained by a small amount of experts, and they take the burden of working with low level APIs.

But that's just my personal opinion from the outside. I do not work in game industry.

fleabay said:
Are you seeing this with RT specifically?

RT is part of my project, but that's not the point. My project is realtime GI and it's all compute. Neither RTX nor rasterization hardware is used. My experience is also restricted to compute for most, i can't say much about rendering.

So, moving from OpenCL (which was faster than OpenGL compute shaders) to Vulkan gave me a speedup of two. That's much more than typical games get from the transition to low level API.

The reason is with VK i can avoid slow CPU - GPU communication, by prerecording the whole program flow just once, uploading to GPU and then per frame i only need one CPU command to execute the program.
With OpenCL i had to download a small result to CPU just to setup the size of the next workload, and i had to do this for each single shader. OpenGL allows indirect dispatch so the download is not necessary, but i still need to dispatch each shader with one CPU command. (That's much better but in practice OpenCL still was faster, surprisingly the most on NV GPUs.)

So this gave me that big speed up on the GPU side because there is no waiting to get work from CPU.
For typical game workloads it's mostly multithreaded command buffer generation and async compute that gives benefit, i guess. Former for CPU and latter for GPU.

I have to add performance is the only reason to move to low level, IMO. If you have no performance problems, then i would not wonder if you end up just pissed. VK needs 10 times more code than my OpenCL version. It's tedious, having to care about each tiny little thing manually. And rendering is much more complicated than simple compute. : /

My personal hope is that there will be another DirectX-API in the near future that is not as low-level as DX12, but has some of the new features (like RTX). I'm not certain how much that is even possible (I've had a quick look at the raycasting-API, but since I haven't used DX12 directly IDK).

The thing is, right now I don't have that much time on hand, and what I have I want to (somehow) spend productively. And so DX12 is totally unnecessary for me. My 2D-game runs at something like 0.5ms in builds, and the only slowdowns I have in the debug-version of the editor are due to some inefficicency on the pure CPU-side of things (drawing my editor-UI myself; having a godawful custom-made scripting backend…). So porting to DX12 really doesn't pay out for me personally. And I belive there are many other people like that, especially indies. If you have a 2D-game, chances are that you don't need DX12. Ever.

My personal hope is that there will be another DirectX-API in the near future that is not as low-level as DX12, but has some of the new features (like RTX). I'm not certain how much that is even possible (I've had a quick look at the raycasting-API, but since I haven't used DX12 directly IDK).

I would hope so too.

DXR already is a high level API if you ask me, and i wondered why there is no support for older APIs. NV is strong with high level API performance, and they could just make extensions if they wanted.
I believe it's just not worth to support us few left U engine boycotting nerds : )
So i don't believe in such a new API to happen.

I would also like the total opposite of that: Vendor APIs.
We don't have as many vendors left as there were when GPUs came out, if we ignore mobiles.
Mantle had a very nice feature of conditional command buffer execution. It can skip over commands, it can even repeat them e.g. until some error is small enough.
VK or DX12 can't do this, and i suffer because i have many commands that mostly do no work at all, but still execute expensive memory barriers, flushing caches for nothing.
VK recently added conditional draws. That's very similar but lacks support for conditional barriers. So it's useless to implement real program flow. I have been told NV hardware lacked HW support, so the feature was dropped.

So there is always a lot compromise and waiting until all companies agree on something. Probably Turing has support now, but still no conditional barriers.

I would prefer to write multiple code paths over constantly working around virtual limitations.

There's probably a few factors at work here. Like JoeJ mentioned there are now multiple free(ish) options for extremely high-quality engines that indie developers can use to make their games. This is different than it was 10 years ago, where starting from something like D3D, OpenGL, or XNA was the standard route. There's also the fact that D3D12 and Vulkan are not really aimed at satisfying those kinds of developers. They're really meant for people who are looking to push the bleeding edge in terms of new functionality and high draw call counts, which isn't most indie games. As a result they're very difficult to get started with, and there's not a whole lot of resources aimed at helping newcomers learn the ropes (IMO a lot of the documentation assumes a base level of knowledge of how GPU's work).

I do think there's plenty of room to fill in other areas of the spectrum in terms of API's. D3D11 certainly isn't dead, and with 11on12 it will continue to work as long as D3D12 runs. The cool thing about 11on12 is that it's all open source userland code: this means it's possible to make similar libraries that convert existing API's like Metal or Vulkan into D3D12 or Vulkan calls, and it's also possible for people to come up with their own brand-new abstraction that sits on top of the lower-level libraries. Those libraries may not be quite as a efficient as if they sat directly atop a driver written by Nvidia/Intel/AMD, but part of the reason things moved towards more explicit API's is that those drivers were getting very very complicated. Ideally if there's hoops you have to jump through to make a higher-level API work, it should be in an open-source library instead of implemented N times in closed-source drivers. Or at least, that's my personal opinion.