The 30th Game Developers Conference (GDC) will take place on March 14th through March 18th, with the expo itself starting on March 16th. The sessions have been published at some point, with DX12 and Vulkan prominently featured. While the technologies have not been adopted as quickly as advertised, the direction is definitely forward. In fact, NVIDIA, Khronos Group, and Valve have just finished hosting a developer day for Vulkan. It is coming.
One interesting session will be hosted by Codemasters and Intel, which discusses bringing the F1 2015 engine to DirectX 12. It will highlight a few features they implemented, such as voxel based raytracing using conservative rasterization, which overestimates the size of individual triangles so you don't get edge effects on pixels that are partially influenced by an edge that cuts through a tiny, but not negligible, portion of them. Sites like Game Debate (Update: Whoops, forgot the link) wonder if these features will be patched in to older titles, like F1 2015, or if they're just R&D for future games.
Another keynote will discuss bringing Vulkan to mobile through Unreal Engine 4. This one will be hosted by ARM and Epic Games. Mobile processors have quite a few cores, albeit ones that are slower at single-threaded tasks, and decent GPUs. Being able to keep them loaded will bring their gaming potential up closer to the GPU's theoretical performance, which has surpassed both the Xbox 360 and PlayStation 3, sometimes by a factor of 2 or more.
Many (most?) slide decks and video recordings are available for free after the fact, but we can't really know which ones ahead of time. It should be an interesting year, though.
Scott, will Vulkan make
Scott, will Vulkan make gaming on linux equivalent to gaming on Windows? I have that in my mind, but i think it is wishful thinking. There must be more to it as there always is. Also, will it allow AMD to more easily make proper drivers for Linux and improve their reputation in that world? Yes or No or I don’t know answers are fine unless you are in the mood to elaborate. Thanks.
In short, no idea.
In short, no idea.
To elaborate, these new APIs are supposed to pull a lot of the "does the game developer mean this or that…" questions out of driver space and into the developer's hands. It also seems to pull some tasks into the driver, like how to effectively schedule compute tasks that are time-insensitive (asynchronous compute). Vulkan and DirectX 12 also diverged in a few areas, which could make one more efficient than the other… or not.
I would guess that it depends on how much the driver developers actually need to do. Khronos Group APIs are designed to be self-dependent, so the OS itself shouldn't matter too much from a technical standpoint. Business side? No idea.
Thanks Scott, I appreciate
Thanks Scott, I appreciate the response. I always thought linux not being a gaming platform, as far as few developers developing games for linux, was what kept it from being widely adopted as a desktop OS. With the Steam machine stuff and Vulkan, I am hoping this is the year that linux finally became a great gaming platform. I am also hoping that this will be the year that AMD rises from the ashes, which I am sure it will.
I’m not having that windows
I’m not having that windows 10 spyware on my hardware, so Vulkan will have to be My graphics API, with OpenGL there to run the legacy code until the Linux based application ecosystem moves fully onto Vulkan.
AMD better realize that it needs to get some design wins from Linux based laptop OEM’s, or I will have to forgo AMD if I want a Linux based OEM supported laptop!
I want a Zen based Steam machine, with an AMD discrete GPU, I REALLY want a full blown High performance Gaming APU on an Interposer that is derived from AMD’s HPC/Workstation Interposer based APUs with at least the option to go to 32 GB of HBM2! A high end gaming APU on an interposer for some serious gaming with at least 16 Zen cores, HBM, and a big GPU die, also with HBM memory error correction for 3d graphics software workloads (Blender 3D).
AMD’s drivers for Linux
AMD’s drivers for Linux gaming are pretty bad. Just FYI.
An interposer can be used different ways, but from your post it sounds like you want an APU with Zen CPU cores, Polaris GPU processors, all on one chip using a shared System/Video cache similar to the PS4 architecture?
I don’t think that’s going to happen any time soon for the desktop.
I think the Windows “spying” situation is completely blown out of proportion, and even then you can DISABLE the major features people have issues with.
The bottom line is that you’re going to be spending a LOT more money for the same gaming experience on Linux (not to mention a lot of the great games aren’t even there).
Why not consider a dual-boot setup with games on Windows, and everything else on Linux?
I’ll never agree to that EULA
I’ll never agree to that EULA and giving M$ the rights to any and all of my personal information, HELL NO! It’s Steam OS and Vulkan for the user privacy/gaming WIN! Without all the windows spyware!
It’s not wishful thinking at
It’s not wishful thinking at all; this has been the whole problem with OpenGL (and D3D9/D3D11) all along. The old APIs are high-level and contain many heuristics and complexities that involve “guessing” what the game engine is trying to do, and then trying to optimize for it.
Furthermore, it gets even worse, most of the games on Windows aren’t just running ad-hoc on the APIs, rather the API detects the game that is running, and enables a bunch of “profile overrides” specifically for that game, which is why a lot of games require you to get day 1 driver patches for them to work properly. Back in the old days when Quake3 came out, there was this funny thing where if you changed the name of any game to quake3.exe, you sometimes got better performance because the driver would enable additional optimizations that were originally designed for Quake3. This is the pure hell that we currently have to deal with.
This was also a massive burden for AMD with their low development resources. This is why they came up with Mantle, to try and hold a gun to Microsoft and Khronos’ head, and get them to develop Mantle-like APIs, or else AMD would just make Mantle an open API and build a new ecosystem around it (they were going to let Intel and Nvidia make their own Mantle drivers too).
In the end, Microsoft and Khronos got the message loud and clear, and built D3D12 and Vulkan respectively.
Short answer is yes, this will absolutely allow Linux to have easy performance parity with Windows, for the first time ever, because the driver design is so much simpler that it’s easier for the community to develop/maintain the drivers, and all the old complexity that used to hold us back has been shoved into the application/gameengine’s domain, so now it’s the game’s job to optimize.
AMD will probably be the first class citizen GPU for Linux, going forward; they are going to be using an open source kernel driver (amdgpu) for both their proprietary userspace (catalyst/crimson), and for the opensource userspace (mesa), and they’re also planning on making the Vulkan driver itself opensource eventually.
Nvidia has already come out
Nvidia has already come out and said they aren’t going to support the entire feature set.
I suspect that means no support for those that leasen their proprietary GameWorks features.
I suspect how well the
I suspect how well the technology gets adopted will determine NVidia’s involvement.
For example, lots of games run under 70% in Linux of what they get on Windows and that’s just due to drivers (I believe)
So NVidia has to prioritize where they’ll invest their time and money.
“Nvidia has already come out
“Nvidia has already come out and said they aren’t going to support the entire feature set.”
Niether are AMD. At least, not out of the gate for either vendor. That’s why there are multiple DX12 feature levels (as there were for past D3D releases) with both required and optional components at each feature level. AMD has implemented some optional components, Nvidia have releaed others. GEN+1 architectures will likely implement more/all of these optional features and move up a feature level or two depending on what/how much these features are actually used in reality.
On mobile, thermal throttling
On mobile, thermal throttling may prove to be a bottleneck if the CPU can feed the GPU cores better.
I collected some GDC2016
I collected some GDC2016 presentation links @ http://bit.ly/1S70Xyy