Khronos unveils Vulkan: OpenGL built for modern systems
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Khronos unveils Vulkan: OpenGL built for modern systems
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Khronos unveils Vulkan: OpenGL built for modern systems
I wonder what mh would say about their "DirectX-style" shaders approach in OpenGL.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: Khronos unveils Vulkan: OpenGL built for modern systems
Frankly, I don't see a problem in adopting good ideas, don't matter their origin.
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
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
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: Khronos unveils Vulkan: OpenGL built for modern systems
I think it's a positive move.mankrip wrote:I wonder what mh would say about their "DirectX-style" shaders approach in OpenGL.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Khronos unveils Vulkan: OpenGL built for modern systems
[ a good read ]
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Khronos unveils Vulkan: OpenGL built for modern systems
Indeed.Baker wrote:[ a good read ]
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
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
It's important to realize that it's not actually bytecode interpretation going on here.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…
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: Khronos unveils Vulkan: OpenGL built for modern systems
Wholly agree that would be an awsome enhancement looking forward to see how it ends up looking.
Productivity is a state of mind.