Vulkan-based graphics library to improve developer efficiency

[hexed sigil]

I’m considering the idea of a higher-but-still-pretty-low-level library to reduce the time and cost of Vulkan development. The basic problem, as I see it, is this:

• Application code is complex
• Vulkan code is complex
• Trying to interface these two things directly is extremely time-consuming and results in a large amount of complicated and brittle code.

I believe an intermediate graphics library, perhaps modeled after OpenGL’s API style, would greatly improve programmer efficiency with no loss of performance and allow more agile application development. WebGPU and ANGLE are proof this approach can work well, but unfortunately those libraries are both “lowest common denominator” abstraction layers that each offer less functionality than even OpenGL 4.6.

I am curious to hear if other developers around here recognize a need for reducing development time and costs with something like this? I have a lot of experience with Khronos graphics APIs and could probably write the whole thing myself, but would prefer to collaborate with others if there is a general need for this.

My general concept right now is like a cleaned-up version of OpenGL 4.6, with the following additions:

• glInstance objects
• glPipeline objects
• glCommandBuffer objects (probably this is how multithreading would work, although I would not force use of them)
• Raytracing support
• Lots of additional error checking in debug builds

I think it would be possible to make an example of a spinning cube with raytraced shadows in less than 150 lines of code, as well as more complex applications that would be indistinguishable from a pure Vulkan app.

Attached is some concept code I wrote down. Please let me know if this idea interests you.

[stray vigil]

That already exists: WebGPU. It's the middle ground between Vulkan/DX12 complexity and older, less verbose apis.

Tbh. I don't see a broad target audience for such a library with all the other libraries around (VMA, vkBoostrap, etc.)

And if you get too close to OpenGL's design you're going to deny developers access to some crucial features to get the best out of a low-level api

btw. ray tracing is already possible with OpenGL using the interop extensions, and there is at least one commercial title that acutally uses this

and there are whole immediate libraries like you describe

[hexed sigil]

I don't think WebGPU supports indirect draw, compute shaders, tessellation, and other things.

[stray vigil]

e.g. one from Meta (I think it's even called IGL)

WebGPU does compute

It has a broad feature set and even recently got subgroup support

[hexed sigil]

Okay, but from what I can tell every library like this is focused on web or mobile, and is less capable than OpenGL 4.6

[stray vigil]

This is the one from Meta: https://github.com/facebook/igl

I'm not a fan of such libraries, but it's pretty much what a library like your describe should look like

[hexed sigil]

I know there are a lot of lowest-common-denominator abstraction layers, but these all seem to be focused on web and mobile. The solution should be more capable than OpenGL 4.6, not less so.

[polar torrent]

Perhaps you're looking for something like this? #showcase message

I'm personally working on (and using) a library to limit boilerplate code by:

• simplifying instance/device creation
• manage swapchains
• provide lots of methods to handle common patterns

By using all this, I can make my HelloTriangle and unit tests much shorter. This is just an example (perhaps the ideas might inspire you), I don't expect you to be interested in it (it's in Java anyway).

Also, on the graphics programmer discord, I remember a forum where people have shared lots of 'engines'

[still stirrup]

looks interesting, I guess this is new
why did they decide to do this?
if webgpu was also a thing

[stray vigil]

The only people that can answer this are it's authors. I'm in no way involvedi n that project.

[hexed sigil]

I started messing around with this, just to get a feel for how the implementation would work. My initial impressions are pretty positive:

#include "UltraGL/UltraGL.h"

using namespace UltraGL;

int main()
{
    // Create an instance
    glInstance* inst = glCreateInstance();

    // Get the device count
    int count = glCountInstanceDevices(inst);

    for (int n = 0; n < count; ++n)
    {
        glDevice* device = glGetInstanceDevice(inst, n);

        // Get the device vendor
        printf(glGetDeviceString(device, GL_DEVICE_VENDOR));
        printf("\n");

        // Get the device name
        printf(glGetDeviceString(device, GL_DEVICE_RENDERER));

        if (glSelectDevice(inst, device)) break;
    }

    glDeleteInstance(inst);
    return 0;
}

[karmic prawn]

There are plenty of 'simplify Vulkan' abstractions out there (e.g. this one https://github.com/Ipotrick/Daxa). So the question is, how can you make your API stand out from the rest

[stray vigil]

I would also advise against trying to wrap Vulkan in an OpenGL-like interface or trying to shove it into OpenGL concepts. What do you gain from calling a glGet function on things that are part of a single struct in Vulkan?

[hexed sigil]

The fact so many libraries exist indicates there is a definite need, but no one has gotten the formula right.

[hexed sigil]

Continuity with OpenGL to ease transition of OpenGL apps, and allow them to toggle between APIs easily with minimal changes.

And compatibility with languages other than C++

Now that I am actually writing code it's a lot easier than I was expecting. I think I could probably get the whole thing done in three months or so, plus a compatibility layer with OpenGL 4.6 to compile existing OpenGL apps with Vulkan.

[polar torrent]

or just NIH 🙂

[hexed sigil]

National Institute of Health?

[polar torrent]

Not Invented Here

[hexed sigil]

If it was a totally new API design, then I would agree with you, but I am adhering pretty closely to an existing well-known standard.

[polar torrent]

My point is that a lot of people have made their own 'simplify/shorten vulkan' libraries, so this probably means that they didn't want to use someone elses library. I doubt all these libraries are better than their predecessor

[hexed sigil]

Okay, how do these libraries ease the porting of OpenGL apps? How do I compare them side-by-side with OpenGL to ensure they work as expected?

[stray vigil]

Porting from OpenGL to Vulkan is rarely a good idea.

And libraries like VMA already abstract away complex(er) parts of the api. And they're widely used.

[hexed sigil]

Why?

[stray vigil]

Because a low-level api like Vulkan is very different from OpenGL. And if you do a naive port you end up with a bad Vulkan renderer that's often slower than the OpenGL thing.

There are so many libraries available that make using Vulkan easier. That's one of the reasons stuff like Meta's IGL isn't widely used. And tbh. the target audience for porting from OpenGL to anything has become pretty small, esp. outside of the hobby developer area.

[hexed sigil]

My VK and GL renderers are faster than just about anything out there. That experience makes me disagree with the idea that Vulkan code has to be structured in a drastically different way to obtain the performance benefits.