LLGL Aims To Be Abstraction Layer For OpenGL, Direct3D 11/12 & Vulkan

[phoronix]

Phoronix: LLGL Aims To Be Abstraction Layer For OpenGL, Direct3D 11/12 & Vulkan

One of my "hobbies" when news is light and there isn't any fun/new/exciting hardware keeping me busy on a given weekend is checking out the various Vulkan projects on GitHub. It's been great seeing all of the independent graphics renderers/engines being tried by different individuals, tons of different Vulkan samples, and a lot of other innovative projects around Vulkan, many of which I've written about in the past few months on Phoronix. One of the projects I see being regularly updated when checking on weekends and haven't written about yet is LLGL, the Low-Level Graphics Library...

http://www.phoronix.com/scan.php?page=news_item&px=LLGL-Abstract-Graphics-APIs

[Daktyl198]

So this is supposed to be a lighter-weight SDL type of thing, right? That could be interesting. How do you switch between the APIs during runtime, or does it select one automatically?

[artivision]

Is there any project for D3D12 to Vulkan?

[efikkan]

The purpose of a "low level" API dissipates when using a such abstraction. It can never generate efficient code for each API. So the only reason to use a such API is when performance don't matter, but "ease" of portability does.

[quikee]

So this is supposed to be a lighter-weight SDL type of thing, right? That could be interesting. How do you switch between the APIs during runtime, or does it select one automatically?

No..SDL abstracts the platform specific bits (initialization of GL, window creation which each platform does in its own way - WGL, EGL, GLX...) but then you still write the (platform independent part of) OpenGL.
This OTOH abstracts the whole graphic library API and invents it's own. So you write using LLGL API and then can choose whatever back end you want.

[starshipeleven]

The purpose of a "low level" API dissipates when using a such abstraction. It can never generate efficient code for each API. So the only reason to use a such API is when performance don't matter, but "ease" of portability does.

There is a tradeoff but I don't think it is going to be as harsh as you think.

If the API is low-level enough (similar to Vulkan/DX12) the performance impact to offloading on Vulkan/DX12 will be limited, and the impact of offloading on DX11 or OpenGL will be also limited as you are taking lower-level stuff and assembling it to then offload in higher-level APIs like them.

It is at least possible, anyway.

[starshipeleven]

Am I the only one that finds the lack of Metal amusing?

[efikkan]

There is a tradeoff but I don't think it is going to be as harsh as you think.

If the API is low-level enough (similar to Vulkan/DX12) the performance impact to offloading on Vulkan/DX12 will be limited, and the impact of offloading on DX11 or OpenGL will be also limited as you are taking lower-level stuff and assembling it to then offload in higher-level APIs like them.

It is at least possible, anyway.

Such abstractions can't result in efficient usage of the low-level APIs.

[MistaED]

Same vein, might be a little more developed: https://github.com/ronsaldo/abstract-gpu

I think with upfront creation of command buffers, pipelines, stuff like that outside the render loop, the abstraction would be quite cheap especially on the thin APIs. The older APIs would be just playing back a buffer full of draw calls which was built by your client code in a deferred fashion, then you could even offload it to another thread which holds the context that talks to the older APIs. If there's some feature that you can't do that is a substantial performance win, you can always modify the abstraction to allow you to do it for a certain API.

[johanb]

Why both DX11/12 and Vulkan? Would be better to go with Vulkan and put effort on Metal so it becomes truly cross platform.