Learning More About The Intel Vulkan Driver, Linux Vulkan Plans

[mdias]

If it's really THAT low-level it looks like Vulkan will be a huge extra effort especially for small studios which will increase development costs significantly. Is it still the messiah under the 3d graphics APIs or will it ruin the current ecosystem of hundrets of small indie studios?

It will most likely be as if nothing had happened for small studios. The engine they'll be using will most likely provide Vulkan support the same way they provide OpenGL and D3D.
Teams that use their own engine will have more work to do though. That said, OpenGL will not vanish; you can ship your games with tested OpenGL code and release Vulkan support any time later...

[gufide]

Porting Cairo would be great. Every drawing would be done on the GPU. This could increase performance of almost everything.

[r_a_trip]

OGL atop Vulkan is universal OGL

LunarG said that OGL could be implemented atop Vulkan as a vendor neutral OGL implementation, but that it wouldn't be easy.

Am I wrong if I say that it would be a big pain once and that it would make implementing OGL extensions easier in the long run, because the vendor specific quirks are abstracted away by Vulkan? If so, it seems like a worthwhile endeavour.

[kwahoo]

I was going to say the same thing. Most smaller studios don't bother creating their own engines and if they do, it's usually DX9/OGL2.x based anyway.


Out of curiosity though, is Vulkan going to be in a separate library from Mesa? I just think it'd be easier for maintenance and users if Mesa was strictly classic openGL.

UE4/Source 2 is not the answer for everyone.

DSOGaming: Can the Road Hog Engine compete with CRYENGINE, Frostbite 3 and Unreal Engine 4? And what’s your opinion on those engines? If you had to choose one of them, which one of them would it be?

KN: It’s hard to compare, because our technology has different goals. We are focused on our specific needs, while mentioned engines are designed as general engines for sale. If I would have to choose an ‘off the shelf’ game engine I would pick Unreal Engine 4 for large games and Unity for small and medium ones. They both feature powerful and easy to use tools, a thing that is very important for a successful production. It’s just much harder to rewrite tools than replace some parts of rendering to suit your needs.

JP: It’s hard to work with such big engines like UE or CryEngine, because of high compilation times and many abstraction layers in their code. In RoadHog – we just code what we need.

http://www.dsogaming.com/interviews/flying-wild-hog-talks-shadow-warrior-64bit-cpu-optimizations-mantle-mod-tools-future-plans/

Some small studios using their own proprietary engines: Frictional Games, Frozenbyte, 11 bit Studios, Croteam, Flying Wild Hog, SCS Software hell, even Dennaton and Vlambeer. I don't think they will even move to third party engines.

[Drago]

UE4/Source 2 is not the answer for everyone.

http://www.dsogaming.com/interviews/flying-wild-hog-talks-shadow-warrior-64bit-cpu-optimizations-mantle-mod-tools-future-plans/

Some small studios using their own proprietary engines: Frictional Games, Frozenbyte, 11 bit Studios, Croteam, Flying Wild Hog, SCS Software hell, even Dennaton and Vlambeer. I don't think they will even move to third party engines.

Many of these used own engines, because the free ones weren't advanced enough, and the non-free ones were well to expensive. Since one month things have changed. Building an engine, and most importantly its developer tools is way too much work. I presume much more AAA titles will use U4 or S2 now.

[mczak]

LunarG said that OGL could be implemented atop Vulkan as a vendor neutral OGL implementation, but that it wouldn't be easy.

Am I wrong if I say that it would be a big pain once and that it would make implementing OGL extensions easier in the long run, because the vendor specific quirks are abstracted away by Vulkan? If so, it seems like a worthwhile endeavour.

Maybe, but I wouldn't expect a OGL driver shared by everyone soon. Some vendors sell their workstation-class cards mostly by their super optimized drivers, and I wouldn't expect them to just give that up.

[mark45]

High quality Vulkan video presentation just made it.

[Almindor]

It will most likely be as if nothing had happened for small studios. The engine they'll be using will most likely provide Vulkan support the same way they provide OpenGL and D3D.
Teams that use their own engine will have more work to do though. That said, OpenGL will not vanish; you can ship your games with tested OpenGL code and release Vulkan support any time later...

I think the solution is straightforward. Vulkan will be the framework upon which to build higher level libraries. Notice the plural, which is a good thing as it'll provide competition and specialization.

This way CAD vs Game etc. can be all happy with Vulkan coz they all can have different midleware libraries on top of Vulkan. This is a good approach since it gets rid of the "one huge thing to rule them all" approach of OGL and DX.

[Ancurio]

If it's really THAT low-level it looks like Vulkan will be a huge extra effort especially for small studios which will increase development costs significantly. Is it still the messiah under the 3d graphics APIs or will it ruin the current ecosystem of hundrets of small indie studios?

Having a harder to use graphics interface is nothing compared to dealing with vendor specific driver bugs, trust me.

[zanny]

UE4/Source 2 is not the answer for everyone.

No, but with Vulkan you can implement an OpenGL like convenience library on top of it that developers can use for near-OGL like features.

Remember, Vulkan starts out with GLSL support, and there will certainly be free software Vulkan convenience libraries designed to offer easier UX than the bare API, which will fill the role OGL does now.

The difference is that under OGL you have this massive bloated API and a sea of inconsistency underneath - you either got it all or nothing, and you could never get closer to the source when needed without just dropping the API entirely and writing kernels for GPUs in their native ASMs. With Vulkan the roots are bare and the community can build whatever abstractions we want on top of them.