Forum

Khronos unveils Vulkan: OpenGL built for modern systems

Discuss programming topics that involve the OpenGL API.

Moderator: InsideQC Admins

Khronos unveils Vulkan: OpenGL built for modern systems

Postby frag.machine » Tue Mar 03, 2015 2:22 pm

I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
User avatar
frag.machine
 
Posts: 2077
Joined: Sat Nov 25, 2006 1:49 pm

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby mankrip » Wed Mar 04, 2015 12:49 am

I wonder what mh would say about their "DirectX-style" shaders approach in OpenGL.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby frag.machine » Wed Mar 04, 2015 1:48 am

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
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
User avatar
frag.machine
 
Posts: 2077
Joined: Sat Nov 25, 2006 1:49 pm

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby mh » Wed Mar 04, 2015 4:18 pm

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.
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
User avatar
mh
 
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby Baker » Wed Mar 04, 2015 9:06 pm

[ a good read ]
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby mankrip » Fri Mar 06, 2015 11:12 pm

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…
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
User avatar
mankrip
 
Posts: 915
Joined: Fri Jul 04, 2008 3:02 am

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby Tr3B » Sat Mar 07, 2015 11:33 am

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.
Tr3B
 
Posts: 15
Joined: Tue May 13, 2014 2:24 pm

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby mh » Sat Mar 07, 2015 3:16 pm

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.
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
User avatar
mh
 
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Khronos unveils Vulkan: OpenGL built for modern systems

Postby revelator » Sat Mar 14, 2015 1:13 am

Wholly agree that would be an awsome enhancement :) looking forward to see how it ends up looking.
Productivity is a state of mind.
User avatar
revelator
 
Posts: 2542
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger


Return to OpenGL Programming

Who is online

Users browsing this forum: No registered users and 1 guest