Vulkan and the future of Magnum

[mosra]

As the news about the OpenGL successor are starting to appear, I'm considering what to do next. I deliberately didn't implement any new GL-related functionality lately, partly because I'm putting all available resources into finally finishing #44 and partly because I didn't want to accidentally create APIs that would be incompatible with the approaches found in glNext, now called Vulkan.

Magnum is not just an OpenGL wrapper, it has also math library, some ugly scenegraph implementation, data import framework etc. These things are not dependent on the underlying graphics API and thus the following decisions should not influence them (besides the effort to make stuff more data-oriented).

So, these are the possible next steps:

• Stick with OpenGL and/or abandon this project because it is now a dead end, not worth pursuing further and get a job in a completely different area. (I don't know, really. Maybe in the end I will find out that this would have been the most sane and healthy decision.)
• Try to cram Vulkan into current API. (This is a bad idea, because from the sources I found, Vulkan has no notion of textures, buffers or anything else, thus I would need to invent new abstractions, which would make stuff more limited that it needs to be.)
• Drop everything related to OpenGL (and thus drop support for all pre-ES3.1 hardware and HTML5, because Vulkan doesn't seem to target also the web). (Not an option, web is very relevant today).
• Create entirely new higher-level API abstracting both OpenGL and Vulkan. Magnum's original design decision was to stick with one family of APIs (OpenGL/GLES/WebGL) and not try to make abstractions that would work also with DirectX (9, 10, 11, 12), AMD's Mantle or Apple's Metal. This allowed me to have a very thin abstraction layer, not limiting the user in any way and keeping the library fairly tiny. Abstracting the stuff out makes this just yet another 3D engine and then there is no point in using Magnum instead of say Unreal 4, providing it is now completely free.
• Create entirely new API as tiny wrapper around Vulkan. Probably as a compile-time option to switch between the two backends, because the user might want to target only WebGL, or just try to fry the GPU in Vulkan.
• Keep the OpenGL API, but rework it to avoid performance pitfalls and add new functionality to match AZDO, NV_command_list and Vulkan approaches more closely (ability to compile state objects, command buffers, use uniform buffers, bindless resources etc.). For older hardware or WebGL the user would still be able to use the old approaches. Try to converge the new functionality with Vulkan as much as possible so it is possible for the user to switch to it without much pain.
• Drop problematic, old and obsolete portions of GL API and things that don't have even distant equivalent in Vulkan (1D textures, rectangle textures, renderbuffers, buffer textures, tessellation...). Some of it still needs to be there because of missing alternatives on older hardware, sadly (until the support for these is dropped, see #78).

In any case, the GL API is deemed to be removed at some point in the future, staying with Vulkan backend only.

Thoughts?

[bkaradzic]

Magnum is not just an OpenGL wrapper

Switch to bgfx, and focus on these:

it has also math library, some ugly scenegraph implementation, data import framework etc.

You'll have more time to make that "ugly scenegraph implementation" pretty, and it will work everywhere... :)

[mosra]

I expected this exact comment, yeah :)

[bkaradzic]

I expected this exact comment, yeah :)

I thought it's not obvious, since you haven't listed it. :)

[Jiboo]

Hello mosra,

If the first goal was to make an OpenGL wrapper + math library (like an OpenGL quickstarter for c++), I think that the next step would be to define the next goal. I don't know which option would be best, I think you should pick the one that will seems to be the most fun/enriching/profitable for you.

I would add an option: Stick with the code, and target only the web, though Emscriptem, as WebGL will probably stick with GLES. You'd keep your current goal, but you limit all users to web only. There's tons of library with this goal, but in JavaScript, none in C++ (Yeah UE4 could do that, but it also cover the current features of Magnum though, but you'd be just lighter & simpler, maybe the JS conversion of Unity or UE4 is too heavy).

Bye, JB.

[Squareys]

I haven't used Magnum nearly at all, but have been looking at it with great interest lately. I was hoping to move to Magnum from Irrlicht (easy to use "high-performance" graphics engine, supports many APIs but originally designed around D3D9), which I was using with OpenGL. Because of Irrlichts support for very old OpenGL versions and D3D9 oriented design, Magnum sounds like a charm, being GL only and completely unsupportive of versions which couldn't run a distortion shader (and therefore I don't care about). Also, bye undocumented euler rotations, hello quaternions! :D And C++11!

Create entirely new API as tiny wrapper around Vulkan. Probably as a compile-time option to switch between the two backends

For me seems like the most flexible option. When the time comes, dropping the GL support is super simple with this and also, this would not hold down the Vulkan API, since no compromises would have to be made. And after all, since "Vulkan only" seems to be the end goal for the (distant) future, compromises don't really seem like an option.

[wivlaro]

Magnum strengths as I see them:

• Properly C++11 throughout
• Entity-component based
• Bare-bones scenegraph
• BSD license
• Magic OpenGL abstraction
• Generally it's all quite modern
• Superb documentation
• Test coverage
• Solid and consistent design

If you were going for a [partial?] rewrite, things I would like to see:

• Rename Feature -> Component, check out prior art to see if there's anything to be learned there.
• Math libraries, they are CLOSE to being SIMD vectorizable as they are, you shouldn't need to do major work there to make them nicely optimal, just playing with compiler options and checking memory alignment might be all that's required.
• Resource loader - it seems kind of complex, hard to predict the program flow. Importing a model requires quite a bit of code and it isn't too obvious how it's all connected at first.
• Focus on static libs rather than shared, this kind of project benefits more from easily transferrable/strippable binaries rather than having to manage shared libraries on target platforms

I'm guessing uptake of Vulkan is not going to be overnight. We're going to be left with a lot of legacy OpenGL for a while to come yet, so let's not rush to abandon Magnum. Maybe we don't want to be implementing new OpenGL extensions for the moment, but there's other features to be worked on in Magnum?

I read this, this morning, I think at least some of it is applicable to Magnum: http://jmonkeyengine.org/301602/in-the-age-of-free-aaa-game-engines-are-we-still-relevant/

[mosra]

Thanks for the insightful inputs, everyone.

I did some reading, actually a lot of reading, about data-oriented design, Entity-Component systems, SIMD, Vulkan/AZDO, proper GPU feeding etc. Vulkan still has some time to be released, so this is my take on things:

• First I need to finish/fix the long-standing issues (OpenGEX, static builds...) and wrap that with a (probably) last pre-Vulkan release, to have something actually working for people to use (that includes fixing up support for all platforms, which might steal a considerable amount of time). That's currently the top priority (although I have embarrassingly little free time now so it might look like I abandoned the project already).
• Then I'll start vulkanizing the existing OpenGL API with things that are proven to give some speedup (state capture, optional draw call reordering etc.). Vulkan specs and drivers won't be available at least until SIGGRAPH, but the general idea about the API is already pretty clear, so that gives me some time to prepare. I'll cover the details in separate issues.
• With the new GPU approach it will soon become clear that the current scene graph and resource manager implementation with all its heap-allocated virtual glory is insufficient. The solution is to create a new, lower-level, data-oriented and more generalized entity-component system (yeah, let's not invent another silly naming again). The original scene graph is still kinda nice for tiny projects where _GameObject_s full of virtual calls are sustainable, so it might end up reimplemented on top of the new system. I already have a rough idea about the design, will elaborate later in separate issue.

What I won't do, probably:

• First-class SIMD support. The data layout and data access pattern would be optimized to enable these, but I have neither the time nor resources to implement and test all kinds of intrinsics for every kind of hardware out there (not to speak about "naive" SIMD approach like in SIMD-enabled Vector4 class, which is generally considered a bad idea).
• Support for some questionable OpenGL features like tessellation or shader subroutines. On the other hand, the Vulkan-compatible features like compute and shader storage will be added, similarly with GLES/WebGL extensions to match Vulkan-compatible desktop functionality.
• Library-specific model/material file format for easier import. I'd like to keep the resource import low-level, allowing the user to preprocess the raw data into their own custom model format where they have total control over data layout. I admit that the current state of resource manager and especially the example supporting it horrendous and don't know how to solve this yet (will depend a lot on and affect the design of the new "scene graph").

When these are finished, I think that the lib will be ready for adopting the new Vulkan ideas and dropping the GL ways of thinking along the way. Because of WebGL it would still need to keep some sort of GL compatibility, but hopefully the GL could be wrapped in a Vulkan-compatible package.

[vinjn]

Vulkan has notions of textures and buffers, as well as vertex buffer and index buffer.

[mosra]

ETA for Vulkan: late 2015 [source]

[mosra]

The decision is to have separate OpenGL and Vulkan API wrappers with no abstraction covering both, details in #147, so closing this one.