A little over three weeks ago, Valve hosted a fairly big developer conference, which excluded journalists so that attendees could network without feeling anxious. The goal was not to keep information from the public, however, and so they created high-quality recordings of the talks and the Steamworks Development YouTube channel, which I assume is owned by Valve but cannot verify this, made the videos public.
Again, each of these talks were aimed at various types of developers, and they were hosted by numerous companies. One video has Tim Sweeney, the founder of Epic Games, discuss Physically-Based Rendering (PBR) and another has Na'Tosha Bard, the technical director at Unity, highlight points that a game developer should know if they intend to publish to Linux, including SteamOS.
In all, there are 25 videos, ranging from ten minutes to an hour and a half, with most clocking in around 45 minutes. It's a fairly large commitment if you want to watch it all, but the topics vary wildly, so it could easily be a “kill an hour learning something” sort of thing. Also, the talks from 2014 are available, too. (There wasn't a Steam Dev Days conference in 2015.)
Thanks Phoronix for finding these.
Inspiring!
Inspiring!
Scott are there ever going to
Scott are there ever going to be gaming benchmarks for Vulkan on windows 7/8.1, as well as Vulkan on Linux? And what about Vulkan’s Multi-GPU(Not dependent on CF/SLI) ability like what was just demonstrated with DX12? What does Khronos say about any Vulkan Multi-GPU Adaptor testing currently?
Windows 7 / 8.1? Not sure.
Windows 7 / 8.1? Not sure. Also, Linux is waiting for games, but that's going to start rolling with with Feral and the engines beginning to support it. The APIs are still early.
As for Vulkan Multi-GPU, though, it's not quite ready. Vulkan's command list model, like DirectX 12 and OpenCL, is set up to make it very easy to communicate between graphics cards. Unfortunately, Vulkan 1.0 didn't ship with a few features, like (according to what I've heard) being able to render to a texture on one GPU and grab it from another. I assume the game could just create multiple whole Vulkan contexts and do that manually, but I'm not sure if that's just annoying for the developer, or actually (non-trivially) slower performance than if the driver does it like DirectX 12 Explicit Linked would. Hopefully not, but that won't affect Vulkan anyway; this is a high priority for Vulkan 1.1.
I'm pretty sure it would affect engines, like Oxide's Nitrous, that mix-and-match vendors in multi-GPU, though. I'm almost positive the only way you'll ever mix those is to do the multiple context thing I was referring to earlier.
So it’s like what is
So it’s like what is described in this PCgamer article(1):
“There are a couple layers to Multiadapter: Implicit and Explicit Multiadapter. Implicit will work more or less like previous versions of DirectX, where the API handles alternate frame rendering across a pair of linked GPUs in SLI/Crossfire. AMD and Nvidia will still need to work with developers to create multi-GPU profiles for games to best take advantage of both cards.
Things get more complicated with Explicit Multiadapter, which is new in DX12. Explicit Multiadapter will have two distinct API patterns: Linked GPUs and Unlinked GPUs. Linked GPUs refer to the special pairing of specific hardware, similar to what we’re familiar with via SLI and Crossfire. DirectX 12 will view linked GPUs as a single GPU, allowing them to collaborate more closely and share resources in each other’s rendering pipeline.
Unlinked GPUs, meanwhile, will allow systems to benefit from, say, installing an Nvidia card alongside one from AMD, as was rumored a few months ago. It will also allow systems with a dedicated GPU to take advantage of onboard graphics, which is the biggest feature Microsoft is touting.”
I’d prefer going with the Vulkan/DX12 APIs and the games/gaming engine makers to go with Explicit Multiadapter of the Unlinked variety and keep the Supplied by the GPU makers’ Driver Model/drivers as simple as possible with the games/gaming engine makers developing the across the industry standardized middleware/Graphics API methods to manage GPUs(Any multi-GPU PCIe configurations). There is still the possibility to manage GPU’s unlinked such that they can be treated as one under the Vulkan/Dx12 APIs, and Unlinked has the advantage of allowing for all GPUs from any GPU/Graphics makers for gaming. I do not want any GPU maker’s GPUs to have any unnecessary Driver complexity other than just enough driver ability to get at the GPU’s Metal. So no special driver methods with the most simple drivers possible.
I not technically against the GPU makers pairing up two GPUs on a single PCIe card and abstracting that away in hardware/Firmware to make any dual GPU configuration on a single PCIe card act as a single GPU. But I want the control over the GPUs metal at the driver level to only be enough to make the GPU’s metal available to the OS/Graphics APIs with any Middleware load balancing given over to the DX12/Vulkan API’s control. Now if the GPU makers can figure ot a way to link up two or more of their GPUs on 2 different PCIe cards and still allow for a different maker’s third GPU to be used then I’m ok with that if that is done with Firmware on the GPUs cards and abstracted away below the driver level, but I never want any DX12/Vulkan enabled systems to not be able to use any and all Graphcs adaptops plugged into somsone’s system, and that includes integrated APU/SOC graphics.
Really the GPU makers have not the brainpower or the resources compared to the Games/Gaming engine makers and the OS/API makers to really load balance any two GPU/Other processors. As that really takes everybody’s efforts including the academic/research community. So I’d rather development not be under any one GPU maker’s propitary NDAs and limitations.
(1)”DirectX 12 will be able to use your integrated GPU to improve performance”
http://www.pcgamer.com/directx-12-will-be-able-to-use-your-integrated-gpu-to-improve-performance/