By the way, one (maybe) silly question, will the forward renderer benefit from the vulkan port at the same level as the deferred renderer?
Ok, so the issues I was seeing with Nvidia seem to stem from having a dual hybrid GPU setup on my PC (AMD & NV, with AMD as the ‘primary’/output card), which seems to have made the NV driver do some weird stuff. In single-GPU setups we are seeing the same improvements as on AMD. Sorry for the false alarm! :eek:
As of why UE4 is not way faster in Vulkan, it’s a matter of changing how the renderer talks to Vulkan. To do so the best way for Vulkan, D3D12 & Vulkan, we’d have to basically break all the code and rewrite it, which is not feasible as it would break licensees and marketplace. So instead we do small changes/deprecate code paths, and slowly get there. But that’s the end goal, to have a fast renderer 
4.20 is almost free of validation errors, so it has a lot of fixes.
Having dual GPUs varies results depending on the system, ie: processor has few PCIe lanes, so usually 1st slot (nearest CPU) will be X16 while second will be X8, in this case there is a performance issue, unless the processor is able to more than 32 PCIe lanes and if the mobo allows it, you would have X16 on 1st and 2nd slots, the latest Threadripper processors with 64 PCIe you would have X16 on the four slots, if the mobo has that amount.
Im looking forward to see the fixes as soon the preview 1 is ready for download.
Great, thanks!
Did you consider doing it like the new audio engine? So let people switch between old and compatible with everything, and new but breaking all old stuff?
Also, could you say if it’s making use of parallel rendering already and with what amount of draw calls you do your tests? So if you test with something like 30000 draw calls per frame, how much faster is Vulkan then compared to D3D11?
Not really. The programming interface (the RHI API) is common for all the RHIs (Metal, GL, D3D, etc). So we would basically have to change the complete renderer (which is a man-years operation) and keep the new one working along the old one. So in short no 
Some systems have a smaller footprint such that that approach is feasible, as you noticed 
Initial parallel support is working, but not yet ready. Still got some weeks before 4.20 cut-off, so hopefully it can make it. Most of the issues are correctness issues (as in following the Vulkan spec re:transitioning resources, which work on some drivers, but there are no warranties on others).
What happened to releasing those slides?
They’re stuck in our mkt dpt 
Slides are finally available on Unreal Engine guides and white papers - Unreal Engine? (UE4 Vulkan Updates & Tips).
The Vulkan optimizations & fixes were merged today into the main UE4 deopt, so it will be copied into the public github repo today or tomorrow (they will go into 4.20). Thanks for your patience!
Nice, thanks for the update 
I think there’s a typo on the Infiltrator perf slides, should be either 26 ms (13 x 2 …) or 76 fps (???)
Makes sense!
Very nice. Since the “some weeks” are over now, did you know if it could make it?
I’ve read through the last Dev-Rendering commit and I saw some parallel stuff, couldn’t directly see if it’s “ready” or not though.
Great, thanks! Now I really wish I could hear you talking to that… No news from AMD on when they’ll release the video?
I understand it so that the ms are only the render thread time, and the FPS are the whole game FPS, so those numbers are both correct.
@ not sure what happened but any project I set rendering to Vulkan is crashing the engine when opening… even one created from scratch… any ideas?
I have found an issue with newest NVidia drivers messing up the Registry descriptor pointing to the vulkan json file and because of this a crash will occur because there is no way to find the Vulkan runtime with that registry info bugged. The current recommendation is to rollback the driver to previous versions like 387.92 will make it work again.
Hi Nilson, this is on Windows? I’ve been running on the 397.64 and seems to be ok.
Yes, it is on Windows. It works fine with 387.92 and if you install 397.64 right after it messes all over again. Even asking for a clean install on the driver installation has not effect. So for now the only way to run on my case is rolling back the driver version, and I do it just for the sake of having my assets tested in Vulkan aswel and not only D3D.
@ I have found why the issue is happening. If you have your Windows since its installation with only NVidia cards/drivers, you won’t get this issue. But once, you install an AMD card and do the same, when you go back to a NVidia card and reinstall its driver you discover that this issue happens. I have reproduced this in a new machine with same mobo+processor and Windows version (both with 1803 build) and the AMD card was R9 390 while NVidia GTX 1080. It might be needed (still veryfing) to completely remove Vulkan runtime (which is left even if you remove AMD or NVidia drivers by Windows uninstall) and erase all registry entries about it. Once I finish this I might get the steps on repro and solution on NVidia forum aswel.
Cheers!
Are there any medium term things that can be achieved without that much disruption? For instance, rendering scene captures or shadows in parallel with the main base pass?
I think when everyone talking about parallel support to please be more specific when it refers to parallelism as for passes or multi-GPU support, which changes completely how parallelism for passes will be handled too.
I think what’s being talked about in 4.20 is multi-threaded rendering, not parallel passes right?
Hi, how can I enable Vulkan for Editor in 4.19.2? When I add “-vulkan” at the end of the shortcut. It crashes when Initialing completed.
@ Since 4.20 is branched now, can you say what made it into 4.20 regarding Vulkan, specifically regarding the “Initial parallel support” that you said will “hopefully” make it into 4.20?
Also, any news from AMD on when they’ll release the video?