Page 1 of 1

Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Tue Mar 03, 2015 2:22 pm
by frag.machine

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Wed Mar 04, 2015 12:49 am
by mankrip
I wonder what mh would say about their "DirectX-style" shaders approach in OpenGL.

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Wed Mar 04, 2015 1:48 am
by frag.machine
Frankly, I don't see a problem in adopting good ideas, don't matter their origin. :P

I like the idea of a mid-to-low-level API over which one can build an OpenGL wrapper. Video card drivers tend to be smaller and (hopefully) less buggy, game developers willing to get closer to the metal in order to squeeze more performance finally have a neutral way to accomplish it, and even Linux support may become easier.

EDIT: And, speaking of the devil...

Source Engine 2 Announced

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Wed Mar 04, 2015 4:18 pm
by mh
mankrip wrote:I wonder what mh would say about their "DirectX-style" shaders approach in OpenGL.
I think it's a positive move.

There are problems with the current GLSL model where the compiler is part of the driver and you must pass plain-text shader files from the programs.

Problem one is the old chestnut of IP protection. For open-source stuff that's irrelevant, but it's important to and a barrier to many commercial teams. Refraining from entering into philosophical debates about whether or not it should be, reality is that it's consequently a barrier to uptake of OpenGL.

Problem two is that plain-text parsing is slow. That's not an issue for Quake-engine projects where there are at most a handful of shaders (if the project has even moved beyond GL 1.x and immediate mode; many haven't). It's an issue in the AAA space where there are a lot more shaders and compiling them from plain-text causes either slow launches or run-time hitches.

Problem three is that each vendor has their own GLSL compiler meaning that each vendor has their own bugs. The GLSL you end up writing needs to be an intersection of what works on the vendors you care about.

None of these are problems with D3D.

Using an IR representation for shaders also opens up a fantastic opportunity in that you can in theory compile any language down to the IR. So if you want to author your shaders in HLSL and compile the same source to Vulkan IR and D3D bytecode, now you can (assuming the availability of a compiler, of course, but I consider that only a matter of time). You could even write them in QC if a compiler was available. That's a lot more significant than it appears on the surface, cos with the APIs converging the future will be a case where the bulk of any porting job will be in porting the shaders. The capability to compile HLSL down to Vulkan IR just makes this extra work go away.

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Wed Mar 04, 2015 9:06 pm
by Baker
[ a good read ]

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Fri Mar 06, 2015 11:12 pm
by mankrip
Baker wrote:[ a good read ]
:D Indeed.

It sounds like one of the best things to happen to OpenGL in a long time.

And not needing driver-supplied compilers should also help Linux gaming. I have a feeling that the Linux versions of many graphics drivers are poorly coded, specially in the case of IGAs.
Well, they'll be able to just write poor bytecode interpreters instead…

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Sat Mar 07, 2015 11:33 am
by Tr3B
Actually I can't wait to see how the BFG renderer will perform with a Vulkan backend. I agree with mh in all aspects. Vulkan is potentially great.

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Sat Mar 07, 2015 3:16 pm
by mh
mankrip wrote:And not needing driver-supplied compilers should also help Linux gaming. I have a feeling that the Linux versions of many graphics drivers are poorly coded, specially in the case of IGAs.
Well, they'll be able to just write poor bytecode interpreters instead…
It's important to realize that it's not actually bytecode interpretation going on here.

What really happens is that it's a two-step compilation process.

Step 1 takes the plain-text shader source and compiles it to a vendor-neutral intermediate representation. This step can (but doesn't have to) carry out optimizations like dead-code removal, instruction reordering, etc. It also does syntax-checking and all of the other really slow validation stuff (in D3D it will also validate it against hardware capabilities; I don't yet know whether or not the SPIR-V compiler will do this). The really critical part of this step is that the end result is a known-good binary representation of the shader source. This step happens outside of the driver via a separate tool and doesn't even need D3D to be initialized (it can be a command-line tool).

Step 2 takes that intermediate representation and compiles it again to a vendor-specific shader. Because it's already syntax-checked, because certain pre-validation is already done, because certain optimization may be already done, this step can be really really fast. This step happens inside the driver and does need D3D to be initialized.

What you actually ship with your game is the IR version of the shaders. So if you have hundreds or thousands of shaders, all of the slow stuff is skipped over when your game launches because all it needs to do is load and do the final compilation of the IR.

In the open-source world this doesn't preclude also shipping the shader source code. You can even do the compilation-to-IR as part of your game's installer if you wish.

What's really cool about Vulkan is that the bytecode specification is going to be open and (presumably) there is going to be a single open-source reference implementation of the GLSL-to-bytecode compiler. I expect that vendors may eventually build their own compilers with vendor-specific optimizations in them (and it may be required to use them as part of a vendor logo program) but for the rest of us, that means we're going to have consistently compiled shaders: no more wild-west. It also means that all we need to feed the driver is valid bytecode; it's not going to matter how the bytecode was generated; we could use the reference compiler, we could use a different compiler, we could hex-edit it by hand, whatever. So long as the bytecode is valid the driver will create a shader from it.

What it also means is that we're going to start seeing bytecode to high-level-language converters. It will be possible to author shaders in GLSL, compile them to SPIR-V, then convert that to a HLSL version of the shaders, all tool-driven. We may even see converters to-and-from SPIR-V and D3D bytecode. That's going to colossally enhance portability of games and everyone will win.

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Posted: Sat Mar 14, 2015 1:13 am
by revelator
Wholly agree that would be an awsome enhancement :) looking forward to see how it ends up looking.