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

so here for blender we settled for openGL 2.1 as the new main common standard and Khronos just announced that they will dump openGL and replace it with Vulkan.

What do the dev think? How hard would a transition be?

How do you get to the conclusion that anyone is going to “dump” OpenGL? The very article you linked to states:

OpenGL won’t go away. The lower level control afforded by Vulkan means that it may not be a good fit for all programs. For them, traditional OpenGL, with the driver handling a greater part of the workload, could be the better fit. A similar situation exists with Direct3D 11 and 12. As such, OpenGL (and Direct3D 11) will continue to have a developer audience, and Khronos intends to continue OpenGL development going forward to meet the needs of this audience.

Blender most likely falls into the category of programs that won’t benefit from Vulkan and OpenGL will be a better fit. For a CAD/DCC application you want the driver to be an abstraction layer to the hardware, so you don’t have to add special case code for every GPU under the sun. That’s the downside that they never tell you when they rave about how those APIs are close to the metal.

Actually, that’s the whole point of SPIR-V (eventually).

http://www.g-truc.net/post-0714.html

Code in whatever language you’re comfortable in, run on whatever platform is supported.

SPIR is just an intermediate binary code, not a hardware abstraction. It will end up just like OpenCL, where just because my code compiles and runs on platform A doesn’t mean it will do the same on platform B. The joke from the early Java days “compile once, debug everywhere” will apply.

SPIR-V is completely different from SPIR and SPIR 2

I don’t think Vulkan right now is important for Blender. Any features that are going to show up in Vulkan are likely to show up in OpenGL as well. The main selling point of Vulkan is less CPU/driver overhead and that’s just not as important for Blender as it is for high-fps games.

Having driver developers go from an IR to machine code is much better than trusting them to write a reliable compiler that goes from a highlevel language all the way to machine code. That’s what AMD failed at. The IR model has proven itself, in fact some (most?) companies already use LLVM as an IR to write GPU compilers for. LLVM was never really designed with GPUs in mind, though. SPIR is a really good thing and it will also be used for OpenCL going forward.

I read the German text and I guess I must have misunderstood or overlooked it. I just forwarded an English link. Ops my fault!

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