How will Vulkan replace openGL in Blender in the near future?

What i think is more interesting about all this Khronos Announces is the " kernel cloning functionality" in OpenCL 2.1, maybe that means we can hope to have again a working GPU OpenCL accelerated version.
Any one have a advise about this?

For now. I don’t think it will have much impact for Blender. Vulkan is the Kronos Group basically splitting OpenGl into two camps. DCC and realtime application like games. DCC will stick with OpenGL, games will use Vulkan instead. That means that Vulakn can develop at a much faster pace than OpenGL, and could finally start adding features to the table as opposed to just following DirectX.

actually, real time animation will be viable soon,

if this is the next wave, maybe blender should catch it?

Could you render 90% of what people do here in real time?

Also, somebody told me once we have an old game engine…

While presently Vulkan is pretty irrelevant, its very existence will likely push OpenGL driver development into the background on consumer platforms. The driver quality is going to go down even lower over time, and eventually it’s entirely conceivable that if you want OpenGL beyond some version (no commercial games require OGL 4 for instance), you’re going to have to shell out for a FirePro or a Quadro. So blender should try to prepare for a switch at some point a few years down the line.

certainly no one is dumping OpenGL.

However Vulkan would make lots of sense due to better draw calls and thus better viewport handling. problem is, only new hardware supports it, so blender cant go full gung ho on vulkan. maybe two options? just like we have for cuda and opencl

well honestly at one point old hardware has to be old hardware.
you cannot keep compatibility to those things for ever.

I hope the route is just to upgrade blender to newer opengl version, get that working and get the ball rolling on the PBR viewport.
Once that is done, when whatever is covered that is supported in current old opengl version, maybe vulkan could be added on-top.

#if GL_VULKAN whatever :stuck_out_tongue:
enable this fancy features.

because who wouldn’t want this draw performance in the viewport

it’ll run on the ati 7000 series so hardware that is over 4 years old. “new” is subjective. blender had no problem adopting cuda which runs on far less hardware then vulkan.

Well as it seems Vulcan does not replace openGL but adds to the mix.
On OS X with Metal there will be even a Metal Vulcan bridge.

This will be quite interesting.

Wasnt Vulkan more like a platform independent DirectX12 / 11
With some of the same ideas behind it, ea parallel uploading (computers with multiple cores) of data towards the multiple GPU cores.

For a game developer i can imagine developing something only once, and have it work on all platforms is nicer then directX.

For an application such as blender, I’m not really sure about the benefit.
Sure viewport and game engine might get a bit faster, but i don’t think thats a high prio given that it already works quite well.
People use Blender to render something, or to make game assets (mostly for other gaming engines).

And this wouldn’t make a huge difference for Cycles, Cycles is a render engine written to work on a GPU
There the GPU does perform the complex Cycles code, as if it is a distributed rendering problem (calculation over all GPU cores).
Uploading textures might be a bit faster towards the GPU, but overall that is a small moment in time, as compared to rendering.
(ea do the cycles node math and calculate the final color of a pixel).

Perhaps a small benefit could be, if it works for OSX, as that operating system has a long past of aged drivers.
On the other hand if it would only be suported by a minority of a few exotic graphics cards… well you get the point here.

@cekuhnen exactly, so either way your viewport is going to be opengl based. since it’s cross-platform.
but if you ever want to get to the promise land of “close to the metal” you either need a abstraction layer from opengl to the os+hw specific method. OR jump on the vulkan train which seems to be write once deploy on cross-platforms and with different hardware.

since the vulkan base was the amd mantle code, i guess amd cards should be fine. nvidia it seems kepler onwards on win7+ or linux will be supported.

worth to mention, those gnomes in the videos, are not instances, it’s individual geometry. so it’s no particle/instance sorcery … it could reflect a huuuuge performance boost in viewport for very very large scenes.

@PGTART I beg to differ that the BGE is performing/works quite well :stuck_out_tongue: it works, but larger stuff really fried my gfx cards. especially the Screenspace effects… in that video you can see later on some screenspace stuff happen flawless.

// I dont bash on the BGE I love it, I do single character and game asset modelling which I test out in the BGE and have not had a bottle neck with that yet. I actually love the BGE for prototyping. Only instance it almost fried my gfx cards where downloading larger scenes, I remember a german dude doing some demo on a train yard with SSAO, and DOF and BLOOM that sent my old 580s into the 90°C region. //

and on that note, I think. People doing short movies like the Blender foundations larger scenes in Tears Of Steel would hugely benefit from a viewport boost on the scale of Vulkan.

As I said, those gnomes in the video where not instances, they could have all been individual geometry.

Ton said the goal is to support hardware 5 years old. Kepler was released in 2012, which isn´t exactly ancient.

Cross-platform graphics APIs basically don’t exist anymore today. Even developing with OpenGL needs special adjustments for different platforms due to the available versions.
The only way to handle that is by creating an abstraction for a certain number of graphics backends. The good thing is that this can be made in an iterative manner e.g. by first creating an abstract layer with just OpenGL as backend. Later other backends, such as Vulkan can be added. Then the abstraction layer might be adjusted to also support multi-threading whenever that is possible with the backend.
That is a very long way. However, there are signs that there is at least some interest in that.

http://wiki.blender.org/index.php/Dev:Ref/GoogleSummerOfCode/2016/Ideas

Create an OpenGL drawing API

  • Benefits: Simplify drawing code and prepare for migration to more modern OpenGL system (or possibly Vulkan).
  • Description: Currently Blender uses deprecated OpenGL immediate-mode for most areas of 2D drawing.
    This project would involve writing an API to abstract away OpenGL calls for the many areas of the code that only do simple 2D drawing.
  • Difficulty: Easy/Medium
  • Possible mentors: Campbell Barton, Inês Almeida

Dantus is right, selecting a socketed draw mode, like openGL_ES compatible mode, or vulkan or ??? Should enable/disable features and change materials and options for materials etc, in the viewport and in the game engine, this change would also open up the bge on android.

ape i dont think blender could be moved to vulkan in less than a year which would make vlukan capable hardware more than 5 years old. i would advocate learning vulkan before attempting to rewrite blender for it so even later.

that is why you socket the render, and do marginal improvements over time to vulkan render, while the vast majority still use openGL. Maybe vulkan starts with 95% of features disabled, and as they are working, turn em on. The important bit is to seperate the function so that you can add to the new system and maintain the old systems at the same time.

The problem is, how do you abstract two very different APIs (Vulkan and OpenGL) without losing the benefits of either? This is neither a small nor simple task.

Particularly, I don’t think it’s a good idea to task inexperienced GSOC students with this, because that didn’t really pan out in the past and Vulkan is even harder to use than modern OpenGL.

I believe it would be better to investigate integration of an external abstraction layer like bgfx, which is already optimized for drawcall throughput on many legacy APIs.

BeerBaron - I did not mean to hang blenders star on Vulcan, I mean to add the ability to choose a different API,

be it* a openGL_ES profile on a tablet, or say Vulcan, or ???

just to add a layer of abstraction / bindings that can easily be re-targeted.

Like switching between cycles and blender internal, but for the whole ‘Draw mode’

Gonna try it out, opengl never really worked for me so i’m happy to get something better

Just make it a Blender 3.0 project, by then it should use the latest technology available and be in par with the other software titans.