GLOVE: OpenGL ES Over Vulkan As Open-Source

[Britoid]

I'm looking forward to seeing if OpenGL over Vulkan ever comes about.

[starshipeleven]

Vulkan _is_ a replacement for OpenGL, but just like X.Org it will still be around for many years, I think many more years than X.Org because OpenGL isn't as bad as X.Org. And yeah, the major players also say it's not a replacement because for now it would be counter productive saying otherwise, it will take its time and people will realize.
And while Vulkan is a lot more lower level, with a couple hundred abstraction LOC it can be as short as GL as most of the abstraction is in the initialization.

Vulkan is NOT a replacement for OpenGL as it does not have a remotely similar target. As simple as that. To be a replacement it should provide the same level of ease of use that OpenGL has, which it does not and is not designed to do.

What is a replacement for OpenGL are the "abstraction frameworks built on Vulkan", but not just Vulkan alone.

[microcode]

Glad to see they were able to get good performance, I wonder how close you could get for a broader implementation of OpenGL, and if it's close enough, how quickly we could just ditch the beautiful-awful OpenGL drivers we have today (after exposing a couple of unique features through VK extensions, if the need arises).

Maybe at some point we can drop system OpenGL implementations altogether, and just LTO each legacy application's subset of OpenGL into the binaries.

[kpedersen]

Vulkan _is_ a replacement for OpenGL, but just like X.Org it will still be around for many years

OpenGL will likely outlive Vulkan. The reason being *is* because it is higher level so can be built ontop of things like Vulkan, Metal, Mantle, etc.
It is very likely we will see the official OpenGL implementation transition to using Vulkan as some sort of back end.

That said, this isn't a "OpenGL is better" kind of thing. It is almost like comparing Apples to Chewbacca. OpenGL is just a graphics API whereas Vulkan is more like an API creation framework. You would very rarely use it directly as a game developer. You would also find it very hard to go the other way and to map Vulkan to Metal or OpenGL.

Vulkan is cool. I do look forward to when the SDK becomes more standardized rather than having to use 3rd party things.

[Weasel]

Maybe at some point we can drop system OpenGL implementations altogether, and just LTO each legacy application's subset of OpenGL into the binaries.

That requires recompilation, so no.

[cl333r]

OpenGL will likely outlive Vulkan. The reason being *is* because it is higher level so can be built ontop of things like Vulkan, Metal, Mantle, etc.
It is very likely we will see the official OpenGL implementation transition to using Vulkan as some sort of back end.

That said, this isn't a "OpenGL is better" kind of thing. It is almost like comparing Apples to Chewbacca. OpenGL is just a graphics API whereas Vulkan is more like an API creation framework. You would very rarely use it directly as a game developer. You would also find it very hard to go the other way and to map Vulkan to Metal or OpenGL.

Vulkan is cool. I do look forward to when the SDK becomes more standardized rather than having to use 3rd party things.

Totally disagree. I played with both OpenGL (shader based, not fixed function) and Vulkan (the Vulkan Tutorial) and let me tell you once you have utility functions around it's close to being as simple as OpenGL. People who didn't try them out seem to regurgitate Vulkan cliches they read elsewhere and I'm speaking from my own experience.

[Sniperfox47]

Can't wait to see more of classic OpenGL implimented in this. Would be nice to have a single OpenGL target without having to worry about all the ideosyncracies of the different drivers and their various issues.

And to all of the devs our there saying OpenGL is easier than Vulkan, go actually try Vulkan. The only thing that's really "harder" with Vulkan is memory management since you don't have a lot of the same automations and safety catches that OpenGL drivers give you, but AMD's (GPUOpen's) memory allocator library helps with that a lot. Pipeline management can also be problematic on mobile platforms, but that just requires you using the API to get used to the best-practices.

I would much rather the little bit of extra boilerplate code and a memory management API in Vulkan than deal with the complexity of all the driver issues and varying version support, incorrect reporting of version support, etc from OpenGL. Honestly Vulkan seems far *less* hard to me after getting used to it.

[Weasel]

Can't wait to see more of classic OpenGL implimented in this. Would be nice to have a single OpenGL target without having to worry about all the ideosyncracies of the different drivers and their various issues.

I want to see all of OpenGL implemented atop Vulkan. It's not that I hate OpenGL or anything like that, in fact quite the opposite: this ensures that it has a failback "survival" mechanism. I mean, nobody forces anyone to use GLOVE if they want "native" OpenGL.

[microcode]

That requires recompilation, so no.

I said legacy, not source-unavailable, I don't see why you have to be hostile and presumptuous.

[Ardje]

I have never developed/touched a DX or OGL application so I'm a total ignorant on the subject , in any case what I mean is if the DX Api requires the use of windows.h and structures or types like HWND, HINSTANCE, WPARAM, LPARAM, etc...

To explain it better: DXVK is a windows driver that implements the direct X 11 api and state machine on the vulkan api in windows.
Wine converts the windows vulkan calls to native linux vulkan calls.
So DXVK is 100% windows.
There are some things to get right though, as the vulkan calls in windows needs to point to the vulkan "driver" of wine and wine needs to point to the correct vulkan driver on linux. The vulkan standard implies that you can have multiple cards with multiple drivers, so you need some administration for that.
So on mac it goes a step further, since vulkan needs to be converted to metal 8-D.