Are there similar smaller alternatives for VMA?
As for the motivation: my 3D API wrapper around OpenGL, D3D11, Metal and WebGPU clocks in at 15kloc for all 3D backends, I'm hesitant to add a Vulkan backend exactly for problems like doing my own memory management for Vulkan resources. If I would integrate VMA, this would more than double the line count just for the memory management of a single 3D backend which simply doesn't seem "right". See: https://github.com/floooh/sokol/blob/master/sokol_gfx.h
 - https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ
 - https://github.com/GPUOpen-LibrariesAndSDKs/V-EZ/issues/73
Ironically WebGPU is what Vulkan should have been in first place, from my point of view.
Can you give some examples preferably with links to source.
I kind of see it as a non-issue. It seems like Vulkan's target audience was specifically elite developers who wanted the most control possible, and based on the results which have been achieved in products like Doom 2016/Eternal it seems like it's working for them.
I suspect WebGPU will be the OpenGL successor for everyone working with graphics who isn't at an AAA game studio.
Vulkan is basically a GPU-programming API with some support for triangle rendering, great for compute workloads, not so great for rendering triangles. At the very least, Khronos should provide additional layers on top of Vulkan to simplify traditional rendering tasks, basically providing one or more optional API layers that are closer to Metal and D3D11.
I think the general idea was the right one, the execution of that idea was the problem (e.g. Metal is the successful execution of the same idea).
I.e. I'd agree with your idea if Metal was actually built by Apple on top of Vulkan as a convenience abstraction and you could use Vulkan there directly too.
I hear that you are saying Metal does a better job of being a convenient graphics API than Vulkan. I am just having trouble parsing why this would be an objective problem with Vulkan, rather than you just not being the target audience of this API.
Contrast this with the situation on Metal (explicit runtime that spawns threads, and explicit callbacks to be able to take advantage of that) or DirectX 12 (explicit runtime that works for the average case, with extremely fine grained control provided over the threading model, priorities, etc., including being able to turn them off completely if you really need it). Both of these are clearly much better models because they are actually exposing the detail that seems obvious in hindsight (applications need queue submission to be nonblocking) and are able to provide much more flexible, efficient, and useful APIs as a result.
By leaving everything up to the user, Vulkan in practice ends up underperforming its competitors unless the drivers patch up the work--at which point you have the unfortunate situation where you have people targeting a low-level API running on a high-level runtime. It's this, not some dumb digression about extensions, that IMO make Vulkan kind of disappointing--it's definitely not a failure, but it could've been much better than it was.
I.e. I'd imagine if this is a real problem, there should be some RFC for the updated version of the API where this is prohibited or some requirements are added about how to control it.
I'm not sure what their approach for that is. May be they break it at some point and then the driver can offer more knobs for such features to be optional or behave differently in the newer versions.
What I think is unapproachable about Vulkan is just the complexity of the problem space. There are a lot of concepts to be aware of just to get the first triangle on the screen (swap-chain, synchronization, render-passes etc.), so in my experience it took quite a few hours of working with it to build an intuition about how everything fits together. And that was coming from an OpenGL background where 70% of the concepts were familiar. I can imagine if you were coming from something like web front-end development, Vulkan could seem pretty inscrutable.
But I will say, since I did cross that bridge, Vulkan became much more intuitive to me than OpenGL. The fact that everything's explicit means there's no mysteries, and the declarative style becomes quite guessable after some time.
Not to mention, error handling is a huge improvement in Vulkan. In openGL, errors are stored in stack that gets popped by calling glGetError. A rookie mistake is only calling the function once, when you really have to call glGetError until the stack is empty every time you check for errors to catch all errors. By contrast, Vulkan just returns a vkResult structure on every function that can fail.
Which are? (I'm genuinely interested)
Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes,....
Now there is LunarG SDK, which still only offers a subset of these kind of features.
If it wasn't for NVidia's early C++ efforts, Vulkan would still be C only.
Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground, otherwise Khronos would most likely still be arguining how OpenGL vNext was supposed to look like.
Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.
Vulkan isn't for newbies. Really, if you're new to 3D graphics then you're not Vulkan's target audience; pretending otherwise only results in pain. That's like complaining that a modern CPU's privileged instructions are too complicated for people new to assembly – yes, they are, and no, that's not a design flaw.
> Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground
That's maybe a point against Khronos, not against Vulkan.
> Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.
Which is exactly what people should be doing. And those middleware engines can be written using Vulkan, because it is designed the way it is.
Yet that doesn't mean I don't care about newbies in 2021, specially when Khronos says OpenGL isn't going to move beyond version 4.6, thus everyone new in the field feels like Vulkan is what they should learn instead.
Isn't this why Vulkan was designed the way it was. It's lower level, giving more control to things like memory. In this way I view it somewhat like the ASM of the GPU (even though though there are lower levels still).
I'm curious if anyone with a lot of experience writing graphics "middleware engine" backends agrees.
The companies who have these resources (for instance the GPU vendors), chickened out by designing Vulkan and thus offloading those QA tasks to the API users (simplified, but that's what it is in the end).
Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users, which in turn are not enough to test Vulkan implementations, because just a handful API users isn't enough to cover all the dusty corners (same situation as back in the bad old days with MiniGL).
??? For example, there are a substantial number of emulators that have already implemented or are in the middle of implementing a Vulkan backend: RPCS3, Dolphin, Yuzu, Cemu, Ryujinx, PPSSPP... these emulators are developed by small teams but often push the hardware hard, bringing bugs to light in the process.
There's always going to be a balance point, and Vulkan's priority is much more about getting as low-level as possible within the constraints than it is about being approachable for developers.
Doesn't khronos contain people from a bunch of different corps (amd, nvidia, intel, qualcom) for this exact reason.
And how else do you propose accessing hardware features which are vendor specific?
Extensions are a PITA to deal with, but they generally represent real disparate hardware features offered by individual GPUs which varies by manufacturer, model, and date. This reminds me of CPU features like SSE2, AVX, AES, etc, etc which general-purpose binary programs are forced to query for at runtime to either take advantage of or fall back to a software implementation. But GPUs have even more architectural change velocity than CPUs.
It seems like a hard problem in general. How do you think this could be done better?
This is exactly how is has been working in the PC world, and is working quite well as far as I can tell.
"Look at these companies that offer an API without extensions by not even trying to support hardware with different features."
In D3D11, the "tier" is basically the minor version number (D3D11.1, .2, etc...), while in Metal you have this handy reference:
Both solutions prevent the "combinatorial explosion" of OpenGL or Vulkan extensions.
But couldn't you do something very similar in Vulkan? I.e. essentially bucket your render-paths into a couple tiers by checking for a set of extensions required to support each one?
If you want to target PC, you have to deal with hardware fragmentation. You can pretend this is a Vulkan issue, but it's just a reality of the platform.
With extension spaghetti, not only are we back in GLAD and GLEW land, each set of extensions is yet another possible code path.
That seems to me like a reasonable decision that graphics API does not try to encompass and duplicate many other unrelated APIs and stays focused on graphics.
Immediate mode OpenGL not even a particularly friendly API, either. I found its implicit global mutable state for things like the matrix stack to be deeply confusing. There's much better drawing libraries out there if what you're looking for is ease-of-use.
JWZ implemented old-school OpenGL in a library on top of a more modern API, and I would entirely agree that's a good approach to compatibility. I'd have advocated for doing the same thing, just without calling everyone idiots.
Can we please just make Direct3D the standard and get the open source community to support it instead of Khronos khruft?
Long story short (read on for details), there is a LOT of work needed beyond just releasing the source of the DirectX libraries to make anything usable on Linux. Microsoft would need to be able to justify to shareholders the spending of all the time and effort needed, which means they need to get something of value. Since the Linux port of DirectX libraries shares the source with the windows version, it seems risky for them to accept outside contributions, since that will either fork the codebase, or pull those changes into the windows version, which feels like a potentially massive hole for people to try to get Patent technologies into the windows implementation, and then sue Microsoft. I'm not sure the advantage in enabling the game studios to more easily port their games to Linux (the main other benefit to Microsoft I see) is worth it, especially since Proton exists, making "porting" mostly a QA exercise, and possibly adding some proton specific optimizations.
The existing DirectX libraries communicate with the DirectX User Mode Driver over a custom interface. Without the GPU makers officially compiling and supporting the User Mode Driver, nothing useful happens. Further it uses an interface to the kernel that is totally alien to linux. Proper kernel drivers that understand this interface and can drive the physical device would be needed, or the libraries changed to communicate over the existing DRM interfaces.
One major problem is that for a non-exclusive mode, the code would need to interoperate with the GL/Vulkin user mode drivers.
On Windows my understanding is that alternate APIs are implemented by having the surface creation code call into DirectX's version, but after that point remaining calls are basically directed to very same DirectX User Mode Driver, which has extra code specific to those APIs to convert those calls into whatever underlying commands need to be sent to the GPU, and sends them along to the hardware exactly as it does for DirectX. The low level commands for the GPU are basically a black box to the DirectX stack, so it does not care what triggered the User Mode Driver to issue them.
For open source drivers, I'm not sure that the MESA/Gallium stack is designed to be able to handle a fully separate user mode driver also talking directly to the GPU via DRI. My very strong suspicion is most such drivers are not designed for that, so the MESA/Gallium driver would need to become unified with the DirectX User Mode driver for an open source route. While possible since Gallium was designed to be able to support multiple APIs, it is basically certain that the way that is approached will not mesh perfectly with the way the DirectX libraries try to interface with the User Mode Driver.
For the NVIDIA proprietary blob driver route, things might be easier, as it is probably feasible to merge the DirectX User Mode Driver with the user mode portions of the existing driver, given that NVidia can unilaterally change the internal architecture of their proprietary drivers without needing to coordinate with anyone, as long as they maintain the CUDA/OpenGl/Vulkan/etc ABIs that apps directly interface with.
1. Already open source
2. Well documented
3. Extremely powerful, as demonstrated by the work at Idtech
Next titles will be most likely XBox exclusives anyway.
I have my own slightly anemic memory manager code that implements a basic scheme with no frills, avoids pitfalls and fits into about 500 lines of code. The only thing I really might want to improve is the some of the free lost handling. The rest shoukd be good for quite a while.
One idea I'm playing with is to provide callback hooks so that resource allocation and management can be delegated to the API user (so they can for instance integrate VMA themselves), and only provide a rudimentary default solution (which probably would be enough for many simple use cases).
1. The usual recommended books for beginners, although good miss what I need, yes I love building ray-tracers and rasterizers but I can finish the book and not have the slightest idea about how a GPU actually works
2. Books like H&P although excellent, treat GPUs as an after-thought in 1 extra chapter, and even the content is like 5-10 years behind.
3. The GPU gems series are too advanced for me, I get lost pretty quickly and quit in frustration
4. Nvidia, AMD resources are 50% advertising, 50% hype and proprietary jargon.
I suppose what I want does not exist, I want a guide that starting from a somewhat basic level (let's say assuming the reader took an undergraduate course in comp architecture) methodically explains how the GPU evolved into a complete separate type of computing architecture, how it works in the nitty gritty details, and how it is been used in different applications (graphics,ML,data processing, etc)
* A trip through the Graphics Pipeline is slightly dated (10 years old) but still very relevant.
* If you're interested in compute shaders specifically, I've put together "compute shader 101".
* Alyssa Rosenzweig's posts on reverse engineering GPUs casts a lot of light on how they work at a low level. It helps to have a big-picture understanding first.
I think there is demand for a good book on this topic.
There isn't a lot of actual under-the-hood information though, because GPUs are closed IPs. So the information needs to be pieced together from the occasional conference talks, performance optimization advice from GPU vendors and what enthusiasts reverse engineer by poking GPUs through the 3D APIs.
Executing shaders better than Nvidia and AMD is not likely.
Selling good graphics adapters at competitive prices to concrete users is even less likely.
Experiments with APIs would have a fatal adoption problem.
Avoiding DRM, if legally feasible, would be less useful than spending the same resources to support Sci-Hub or improve laws.
And of course for the more practical purpose of writing mere software, including Vulkan implementations, specifications are complete and open enough.
General-Purpose Graphics Processor Architectures (Tor M. Aamodt)
> 4. Nvidia, AMD resources are 50% advertising, 50% hype and proprietary jargon.
I found the Nvidia CUDA C Programming Guide very helpful...
Loading it just now, I'm seeing what you see.