SteamOS with Vulkan? I would at least be skeptical.
-
Hey Guest. Check out your NeoGAF Wrapped 2025 results here!
Khronos announces Vulkan (previously GLNext/Next-gen OpenGL)
- Thread starter gofreak
- Start date
SteamOS with Vulkan? I would at least be skeptical.
Are there any penalties to using OGL (or Vulkan) on Windows? The general lower performance in OGL renderers is entirely to do with the state of drivers and not because of additional overheads or anything, right?
No, not really. Maybe you don't have the various options for interacting with the windowing system, but other than that I can't think of anything.
MrCunningham
Member
Pretty sure all of the current Source games support OpenGL, and it is possible to switch the renderer in Windows to OpenGL through the command line terminal. The OpenGL support in UE4 isn't experimental either as it is there for Mac and Linux support. There is a dedicated Mac client for UE4. There are also quite a few different branches of UE3 with OpenGL support.
We are going to have to wait and see on Vulkan. But there really aren't any performance penalties using OpenGL in Windows. Though generally when it comes to OpenGL, Nvidia's OpenGL driver performance has always been a little better than AMD or Intel's. On Linux Nvidia pretty much dominates performance. But Vulkan may change the tides for AMD though if it is based on their Mantle API.
TheHellsLord
Member
Conceptually there should not be any penalty for OGL. It's however hard to pinpoint wether the lower performance we see today is solely up to drivers either. It is entirely possibly that there are differences in all parts of the pipeline (engines being mainly optimized for DX on Windows, driver development being focused on DX on Windows and perhaps Microsoft is able to work more efficiently due to them taking DX into account when designing the rest of the OS while Mantle/OGL/Vulkan are more like Add Ons).
Looking at the quite different driver overheads we see on AMD and Nvidia cards when both are using DX11 it's quite clear that each of those components can play a big role when it comes to performance bottlenecks and that even though in theory they perform the same function the specific implementation can make for quite a big difference.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
You just got me some Wednesday reading material - thanks!I agree with everything you just said (except, of course, that the llvm IR is only the smartest low-level IR, since obviously the smartest high-level IR is INSPIRE).
It would be quite a hindrance for future tool development not to be able to use the latest version of llvm.
agiantenemycrab
Member
EDIT:
Here is the full SPIR-V specification from Khronos.
From the look of it SPIR-V is not actually based on LLVM IR at all. The whitepaper makes no mention of it, and the IR listing they give looks nothing like any LLVM IR I've ever seen.
OpenCL kernel:
which compiles to:
I know the opensource Intel Linux GPU team had a very hard time getting LLVM IR to work as the shader IR for their Mesa driver under Linux, so its possible Khronos has become wary of using it as a base for SPIR-V. Odd considering regular old SPIR is most definitely LLVM based.
Here is the full SPIR-V specification from Khronos.
From the look of it SPIR-V is not actually based on LLVM IR at all. The whitepaper makes no mention of it, and the IR listing they give looks nothing like any LLVM IR I've ever seen.
OpenCL kernel:
Code:
__kernel void add(__global int* in1, __global int* in2, __global int* out) {
size_t i = get_local_id(0);
out[i] = in1[i] + in2[i];
}which compiles to:
I know the opensource Intel Linux GPU team had a very hard time getting LLVM IR to work as the shader IR for their Mesa driver under Linux, so its possible Khronos has become wary of using it as a base for SPIR-V. Odd considering regular old SPIR is most definitely LLVM based.
That's the key reason why Vulkan may be good. Legacy support and member politicking were said to be holding the API back (as far as our gaming hobby is concerned anyways).
http://richg42.blogspot.co.uk/2014/05/things-that-drive-me-nuts-about-opengl.html
Vulkan demo from PowerVR.
https://www.youtube.com/watch?v=KdnRI0nquKc
https://www.youtube.com/watch?v=KdnRI0nquKc
yeah. The OGL 2.1 to 3.0 transition took so long and irreparably damaged openGL as a gaming api primarily due to this. AFAIK it was the graphics productivity and tools bloc that was constantly putting up barriers to evolving the api.
most ogl games target older ogl versions due to compability issues. ogl has for a while had far less overhead than current dx.
the real penalty/difficulty is making sure users have up to date drivers, many casual users have gpus supporting the latest standards but never update their gpu drivers. I'm hoping maybe steam can do something to help here.
Yes, but you know this gif comes to mind, unless they discontinue OGL. I am just being very sceptical with the decision to branch out from the brand, just like I was with Mantle API.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Thanks for the link.
It's a verbatim derivation of llvm IR. I can literally translate it to llvm SSA as I read the example you posted ; )
Of course they've actually properly 'forked' llvm IR, but that does not help my original concern - all this tech is heavily reliant on llvm. And until llvm bigwigs sit on their behinds and provide a stable IR 'ABI', everybody will be body-balancing on a proverbial surfboard (think ms windows and their non-existent ABI).
Yes, but you know this gif comes to mind, unless they discontinue OGL. I am just being very sceptical with the decision to branch out from the brand, just like I was with Mantle API.
Would you rather they kept the crufty old api? The one that nobody (in game development) wants to use?
There is a reason DX has been successful. They weren't afraid to develop with the times, nor afraid to break backwards compatibility.
ScepticMatt
Member
Does Dota 2 count as "real AAA" for you? If so you can already see it working in the debugger.
Other than that Gabe Newell stated on the Vulkan page that they will use it for their future games, of which L4D3 might be the first to come out.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Their specularities are badly broken compared to the ES3.0 version of the same demo: https://www.youtube.com/watch?v=j_dYQcpagGs
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
But the specularities are not missing. They're just broken. Just pay attention to the floor.
Yes, that was apparently the old name. The website now says:
Which sounds a little snobbish but eh.
LLVM is a library suite that aids in the development and building up of compilers. It is not a virtual machine. Not really sure how the history of the name came to be. Targeting LLVM specs, your compiler does gain the benefit of portability. Not unlike targeting POSIX compliance.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
It started out as a pseudo VM, literally. During apple's early OSX-on-intel days llvm was responsible for getting GLSL and transforming it on the fly (incl. jitting it) to either intel's abominable GMA900, or when the code was too much for that (read: often) to the CPU.
LLVM started out as a GLSL low-level abstraction layer.
None whatsoever. PSGL was was for ps3 and it wasn't popular. AFAIK the PS4 does not use PSGL.
TheHellsLord
Member
I don't think POSIX compliance is a good analogy either.
Basically you have compiler front ends that create an intermediate representation similar to MSIL in .Net or Java Bytecode. Instead of running that inside a VM (like those languages do) the LLVM backend turns them into native code.
Perhaps that's how the VM part slipped into the name.
The benefit is clear however - you only have to write the compiler frontend yourself which turns the programming language into the LLVM IR. The compilation process itself is done by the common backend (for each platform) and that's where the interesting stuff like register allocation and automatic code optimization happen.
Basing your IR on that is likely to be smart as there already are people around who know how to work with that. Other than that I don't really see much benefit as the backend has to target GPUs rather than CPUs so you won't be using any existing LLVM backend like for example for x86 and the frontends are also different given that GLSL is different from regular languages like C++.
Perhaps I'm missing something there?
Basically you have compiler front ends that create an intermediate representation similar to MSIL in .Net or Java Bytecode. Instead of running that inside a VM (like those languages do) the LLVM backend turns them into native code.
Perhaps that's how the VM part slipped into the name.
The benefit is clear however - you only have to write the compiler frontend yourself which turns the programming language into the LLVM IR. The compilation process itself is done by the common backend (for each platform) and that's where the interesting stuff like register allocation and automatic code optimization happen.
Basing your IR on that is likely to be smart as there already are people around who know how to work with that. Other than that I don't really see much benefit as the backend has to target GPUs rather than CPUs so you won't be using any existing LLVM backend like for example for x86 and the frontends are also different given that GLSL is different from regular languages like C++.
Perhaps I'm missing something there?
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
It indeed isn't a good one.
LLVM can also run its IR non-natively, Java-bytecode style.
LLVM has R600 (VLIW5/VLIW4) AMD targets as well as NV PTX (nvidia's internal GPU low-level abstraction level) backends. And while I'm not aware if AMD use the R600 backend for production purposes, CUDA uses llvm heavily.
Apropos, while on the subject - sony's ps4 compiler toolchain is entirely llvm/clang based. Actually, sony contributed a lot to the llvm codebase over the course of the past two years.
Threre is a provisional specification of SpirV.
https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf
It's not LLVM IR, but they've avoided unecessary incompatibilities so that it can easily be mapped to LLVM IR.
https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf
It's not LLVM IR, but they've avoided unecessary incompatibilities so that it can easily be mapped to LLVM IR.
Can you still use fullscreen exclusive mode? I've heard (from byuu, iirc) that it's a Windows concept and maybe it's in my head, but a lot of SDL-based games seem to not support it.
They literally say to use the other guys stuff if you want 1.0 functionality. Damn. Well, it lasted about as long as I thought this would last. Now to go ahead and get FreeSync over and done with.
I love my Linux for sure but I use Windows, too. What exactly bothers you with Windows?
I don't think you have been paying attention...
ashecitism
Member
TheHellsLord said:
I read the Open GL ES 3.1 support in a more inclusive way. I thought it was referring to the class of capabilities not just to mobile platforms. I can create an Open GL ES 3.1 context on my desktop machine today. IIRC, the main addition to ES3.1 over 3.0 was glDispatchCompute and its kin as well as some instanced drawing routines. So I think they were basically saying that all modern GPUs will be supported.
The Anandtech article sees it similarly.
http://www.anandtech.com/show/9038/next-generation-opengl-becomes-vulkan-additional-details-released
Interesting quote from ashecitism's link
LOL, sure enough. There will be some confusion.
Some Windows graphics drivers have awful OpenGL support. That's the main reason why ANGLE exists.
ashecitism
Member
https://twitter.com/VulkanAPI
@VulkanAPI Hey is tomorrow's* glNext w/ Valve session going to be live streamed?
Vulkan ‏@VulkanAPI 10h10 hours ago
@ValveTime No live streaming. Video will be posted online afterwards.
*today
@VulkanAPI Hey is tomorrow's* glNext w/ Valve session going to be live streamed?
Vulkan ‏@VulkanAPI 10h10 hours ago
@ValveTime No live streaming. Video will be posted online afterwards.
*today
It's going to be interesting to watch for sure! Valve are probably going to show something from the new Source Engine as the screenshot from the release was a Dota2 debug screenshot.
Hopefully they are going to announce when driver support will be available and when the public can get it's hands on the API.
Wonder when it's going to get uploaded. Hopefully rather fast!
Also they said that Arkham Knight and Witcher 3 were hitting Linux so I guess they are going to utilize Vulkan.
Hopefully they are going to announce when driver support will be available and when the public can get it's hands on the API.
Wonder when it's going to get uploaded. Hopefully rather fast!
Also they said that Arkham Knight and Witcher 3 were hitting Linux so I guess they are going to utilize Vulkan.
blu
Wants the largest console games publisher to avoid Nintendo's platforms.
Here's the GDC OCL2.1 + SPIR-V lecture to watch: https://www.youtube.com/watch?v=ez18sOaR748
I'm not sure if it's already been uploaded elsewhere but the talk labeled as glnext presented by Valve, Frostbite, Epic etc is now available on GDC Vault.
http://gdcvault.com/browse/gdc-15
Cannot directly link to it because it's locked behind a registration wall but it's still free to watch. Just need to put in personal info (can be fake if you want).
http://gdcvault.com/browse/gdc-15
Cannot directly link to it because it's locked behind a registration wall but it's still free to watch. Just need to put in personal info (can be fake if you want).
agiantenemycrab
Member
I'm still a Junior and I can't make a new topic so apologies if this is an off-topic necrobump but Khronos just released the SPIR-V version 1.0 specification to coincide with SC '15. The specification documents are available at the Khronos registry. I would assume that a full 1.0 spec for Vulkan is not that far behind. Thought some GAFfers might be interested.
We are really interested, thanks!
There are engines where DX is the only native implementation (and everything else runs under DX wrapper) so it's more than just optimization problem.TheHellsLord said:
In a twisted way, Vulcan is the best chance DX12 has to get "proper" support, as it promises to lift the need for software to have legacy API support (and with it, legacy pipeline designs).Durante said:
And given its purpoted mantle-origins, why would it be a question over what kind of games you can write against it?