Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V

[elect]

I am just afraid OpenGL will become "second class citizen" and wont be developed anymore as it has been so far..

Anyway, choice is always good, so software houses will go with Vulkan and we, independent devs, will stay on GL

[clementl]

I am just afraid OpenGL will become "second class citizen" and wont be developed anymore as it has been so far..

Anyway, choice is always good, so software houses will go with Vulkan and we, independent devs, will stay on GL

I hope that OpenGL, in long term, becomes unnecessary through SPIR-V libraries. Would make for a much cleaner API.

[oleid]

I am just afraid OpenGL will become "second class citizen" and wont be developed anymore as it has been so far.

As much as I like AMD hardware, sadly I've to admit, that OpenGL always used to be a 2nd class citizen for them. Just compare the speed of their OpenGL implementation vs their Direct3D implementation -- even on Windows. I consider Vulkan to be the chance for getting fast 3D from AMD on Linux.

Furthermore, I hope that Vulkan is easy to implement, so that we'll get a decent free implementation in mesa. Considering that AMD will use large amounts of the free 3D stack for their latest driver, I think we'll get free Vulkan on Linux rather quickly.

[dragorth]

Not naive at all.

A very naive question, but would wine be able to use Vulkan instead of OpenGL? or is it too specific for what wine does?

In one word, yes.

Now, the question becomes, "Will they?"

Currently, they translate DirectX to OpenGL, which, depending on the game, is about half as fast as native. Presumably, they can start by using their existing HLSL transpiler, and at the start of the game, simply transform that to SPIR-V.

This would require they rewrite the OpenGL specific portions as their Vulkan equivalent. They may not be willing to do that, especially so soon. Remember, they are against supporting the DirectX 9 state tracker, due to its low number of affected users. However, if every vendor really does support this, they lose some of the reasons not to support it.

If an OpenGL implementation is made on top of Vulcan, then they could have a free lunch. Keep in mind, however, that we already hve something similar to this system in place, gallium3d, so in this scenario, we should see very little speed increase. One benefit it would have, however, is every GPU manufacturer would presumably put their resources behind a common implementation to optimize the SPIR-V compiler portion.

[clementl]

As much as I like AMD hardware, sadly I've to admit, that OpenGL always used to be a 2nd class citizen for them. Just compare the speed of their OpenGL implementation vs their Direct3D implementation -- even on Windows. I consider Vulkan to be the chance for getting fast 3D from AMD on Linux.

Furthermore, I hope that Vulkan is easy to implement, so that we'll get a decent free implementation in mesa. Considering that AMD will use large amounts of the free 3D stack for their latest driver, I think we'll get free Vulkan on Linux rather quickly.

They don't really have a DirectX implementation, Microsoft does. A key difference between DirectX and OpenGL has always been that Microsoft implemented DirectX, and vendor's only had to write a back-end for it.

[Geri]

Intel, AMD, Nvidia, Valve, Sony, EPIC, and Unity, among others all disagree with you, plus there's some very good posts by Elanthis as to exactly why we need new graphics APIs somewhere in this forum, I'm inclined to agree with them as opposed to you.

its irrelevant. only one thing matters: the demand of the market.

[clementl]

its irrelevant. only one thing matters: the demand of the market.

Yes, and you know what the market of a graphical API is? 3D developers. Not the end-user, they don't care as long as the product runs great. If the developers are willing to implement Vulkan right now, then it has already been successful.

[curaga]

In one word, yes.

Now, the question becomes, "Will they?"

Currently, they translate DirectX to OpenGL, which, depending on the game, is about half as fast as native. Presumably, they can start by using their existing HLSL transpiler, and at the start of the game, simply transform that to SPIR-V.

Maybe he meant as in passthrough? The Windows game using Vulkan can be almost directly passed through with less translation.

[clementl]

Maybe he meant as in passthrough? The Windows game using Vulkan can be almost directly passed through with less translation.

That's already the case with current Windows OpenGL games. The main improvement Vulkan could bring is that more games with Linux-compatible API's will come out.

[Geri]

Yes, and you know what the market of a graphical API is? 3D developers. Not the end-user, they don't care as long as the product runs great.

yeah. thats why 80% of the games available on linux still using the opengl 1.0's glvertex3f vertex path right from 1994 to render. i would be very curious, how you, and other gogetter would please them to use a new api, if they dont even want to use the vertex array feature from 1997. why they would switch aniway? becouse you tell them to do so? or amd tells them to do so? the world does not works like that.