Vulkan status

[RCaloca]

Hey guys, so we have an initial version of the mobile renderer working on Vulkan released with 4.12. It is aimed at Android developers and mobile emulation on PC/Desktop.

Best way to test on PC is to run the editor adding -game -vulkan -featureleveles31 to your command line.

Trying to run the Editor under Vulkan (ie not adding -game and having -vulkan) is not supported (yet!). Trying to run a non-ES3.1 path (like -SM4 or -SM5) is not supported (yet!).

We're working hard on making Vulkan a great RHI for people to use, so pardon our dust

[TheJamsh]

Stuff

Currently, what are the major benefits to running Vulcan over ES2 or 3.1, can we expect to see any major performance boosts at all, particularly where pixel shaders / lighting is concerned? 3.1 didn't seem to actually give us any better performance when we tried it, and the hassle of using the source build of the engine didn't make it worthwhile. Currently we're just stuck to plain ol' ES2.

Reason I ask is, we're on the verge of releasing this, and our biggest problem right now is that we're using two dynamic lights to light everything (Skylight & Directional). When the Earth object is in the background and taking up the whole screen, our render time goes through the roof. We hit 60 and above on an nVidia shield, but a lot of newer devices struggle to get over 30. In fact, we've had to drop support for phones entirely right now.

I've done a lot of work on it and I can only imagine that the cost is coming from all those pixels that need lighting calculated, but there's not really much I can do about that aside from making everything a lot uglier and trying to fake it in the materials. Before I sink a few days into setting up the engine with source and distributing it to everyone, would Vulkan make much of a difference?

[John Alcatraz]

This is how it looks like here to run the Particle Effects demo with -game -vulkan -featureleveles31 :

You see, quite a bit of artifacts there. Also, the resolution looks very low, although the screen percentage is set to 140. Changing the screen percentage does not change the way it looks like. Not sure if it's caused by UE4 or maybe driver stuff.

[Yaakuro]

Hi Epic

[MENTION=396]RCaloca[/MENTION] You asked me for the PR that supports Vulkan on GNU/Linux (GNUX)

https://github.com/EpicGames/UnrealEngine/pull/2276

and here how it works on GNUX: https://www.youtube.com/watch?v=Z6TwWHoGBpE

This is an older commit point of the master branch.


Unfortunately when I use the current master branch, I get this:

Fatal error: [File:/media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanUtil.cpp] [Line: 444] 
Result failed, VkResult=-4
 at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanMemory.cpp:1237 
 with error VK_ERROR_DEVICE_LOST

Thread 30 "RenderThread 1" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7fff7a345700 (LWP 12505)]
0x00007ffff7bcb2a9 in raise (sig=5) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
35	../sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7bcb2a9 in raise (sig=5) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
#1  0x00007fff9dc6a032 in FLinuxPlatformMisc::DebugBreak () at Runtime/Core/Public/Linux/LinuxPlatformMisc.h:38
#2  VulkanRHI::VerifyVulkanResult (Result=VK_ERROR_DEVICE_LOST, VkFunction=0x7fff9dd93215 "Result", Filename=0x7fff9dd933dc "/media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanMemory.cpp", Line=1237)
    at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanUtil.cpp:443
#3  0x00007fff9dc85fb5 in VulkanRHI::FFenceManager::CheckFenceState (this=<optimized out>, Fence=<optimized out>) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanMemory.cpp:1237
#4  0x00007fff9dc6ad2f in VulkanRHI::FFenceManager::IsFenceSignaled (this=0x3082, Fence=0x30d9) at Runtime/VulkanRHI/Public/VulkanMemory.h:884
#5  FVulkanCmdBuffer::RefreshFenceStatus (this=0x7fffa33ee4f0) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanCommandBuffer.cpp:89
#6  0x00007fff9dc6b870 in FVulkanCommandBufferManager::PrepareForNewActiveCommandBuffer (this=<optimized out>) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanCommandBuffer.cpp:173
#7  0x00007fff9dc9be82 in FVulkanDynamicRHI::Present (this=0x7fff9e1cae00) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanViewport.cpp:364
#8  0x00007fff9dc9bbb3 in FVulkanCommandListContext::RHIEndDrawingViewport (this=0x7fffa28fab40, ViewportRHI=<optimized out>, bPresent=<optimized out>, bLockToVsync=<optimized out>)
    at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/VulkanRHI/Private/VulkanRHI.cpp:718
#9  0x00007ffff10301c0 in FRHICommandList::EndDrawingViewport (this=0x65acf8 <GRHICommandList@@UE4+16>, Viewport=0x7fff85113e60, bPresent=true, bLockToVsync=true) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/RHI/Private/RHICommandList.cpp:1342
#10 0x00007fffca15d1d9 in FSlateRHIRenderer::DrawWindow_RenderThread (this=<optimized out>, RHICmdList=..., ViewportInfo=..., WindowElementList=..., bLockToVsync=<optimized out>, bClear=<optimized out>)
    at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/SlateRHIRenderer/Private/SlateRHIRenderer.cpp:480
#11 0x00007fffca188625 in FSlateRHIRenderer::DrawWindows_Private(FSlateDrawBuffer&)::EURCMacro_SlateDrawWindowsCommand::DoTask(ENamedThreads::Type, TRefCountPtr<FGraphEvent> const&) (CurrentThread=ENamedThreads::StatsThread, this=<optimized out>, 
    MyCompletionGraphEvent=...) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/SlateRHIRenderer/Private/SlateRHIRenderer.cpp:648
#12 TGraphTask<FSlateRHIRenderer::DrawWindows_Private(FSlateDrawBuffer&)::EURCMacro_SlateDrawWindowsCommand>::ExecuteTask(TArray<FBaseGraphTask*, FDefaultAllocator>&, ENamedThreads::Type) (this=<optimized out>, NewTasks=..., CurrentThread=<optimized out>)
    at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/Core/Public/Async/TaskGraphInterfaces.h:999
#13 0x00007ffff6f03992 in FBaseGraphTask::Execute (this=<optimized out>, NewTasks=..., CurrentThread=5) at Runtime/Core/Public/Async/TaskGraphInterfaces.h:472
#14 FNamedTaskThread::ProcessTasksNamedThread (this=<optimized out>, QueueIndex=<optimized out>, bAllowStall=<optimized out>) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/Core/Private/Async/TaskGraph.cpp:930
#15 0x00007ffff6f01535 in FNamedTaskThread::ProcessTasksUntilQuit (this=<optimized out>, QueueIndex=<optimized out>) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/Core/Private/Async/TaskGraph.cpp:677
#16 0x00007ffff12a691a in RenderingThreadMain (TaskGraphBoundSyncEvent=<optimized out>) at /media/Data/UnrealEngineMaster/Engine/Source/Runtime/RenderCore/Private/RenderingThread.cpp:318

Signal 11 caught.

[RCaloca]

Thanks guys! [MENTION=24522]John Alcatraz[/MENTION]: I'll try out the Particle FX demo; our 'clean' test is with SunTemple currently, we're slowly adding more tests/maps, there is still a bit of cleaning up to do for stability, however I haven't seen those artifacts. What card/driver are you running on? [MENTION=10867]Yaakuro[/MENTION]: thanks for the PR, I'll ping our Linux guys as most of the fixes seem to be Linux only. Also we're pretty sure the NV Linux drivers are not up to par with the Windows ones, causing more instability.

[John Alcatraz]

Thanks guys! [MENTION=24522]John Alcatraz[/MENTION]: I'll try out the Particle FX demo; our 'clean' test is with SunTemple currently, we're slowly adding more tests/maps, there is still a bit of cleaning up to do for stability, however I haven't seen those artifacts. What card/driver are you running on?

I'm on a AMD R9 390 with 16.5.3 drivers.

[JackP_oldaccount]

Hi guys,

Currently, what are the major benefits to running Vulcan over ES2 or 3.1, can we expect to see any major performance boosts at all, particularly where pixel shaders / lighting is concerned? 3.1 didn't seem to actually give us any better performance when we tried it, and the hassle of using the source build of the engine didn't make it worthwhile. Currently we're just stuck to plain ol' ES2.

I've done a lot of work on it and I can only imagine that the cost is coming from all those pixels that need lighting calculated, but there's not really much I can do about that aside from making everything a lot uglier and trying to fake it in the materials. Before I sink a few days into setting up the engine with source and distributing it to everyone, would Vulkan make much of a difference?

Vulkan is just an alternative API to the same graphics hardware and if you're already GPU bound you're not going to get any performance improvement from using it. The same shaders will be executed by the GPU in both cases. Like Metal vs OpenGL ES on iOS, the main advantage of Vulkan is that the driver overhead is much reduced compared to OpenGL ES, so if you're CPU bound because of the number of drawcalls you're issuing, then Vulkan can definitely help you. In the ProtoStar demo we saw approximately 4x less overhead in API calls compared to OpenGL.

How many draw calls are you issuing? Have you tried using the quality level overrides for lower-end ES2 devices? Apart from content optimizaiton, resolution scaling is probably easiest way to gain performance if you're really pixel shader bound.

Also please note that there are still bugs both in Vulkan drivers in devices as well as in our Vulkan RHI so things are very experimental at the moment.

- Jack

[TheJamsh]

Text

Hey Jack, thanks for the detailed post.

Our Draw Calls are pretty minimal I believe, but I can't get direct numbers on the device it seems (what stat group should I be looking at?). Stat.RenderThreadCommands - Draw is at something like 20-30 ms, which is insane. The problem is, there's no breakdown of what's causing it to be that high.

We have a Dynamic Dir Light and a Dynamic Skylight (which we need by design), but even turning those off didn't yield much more. A completely unlit scene rarely goes above 7FPS on a Nexus 7. Just have no idea where that time is being sunk.

[mebalzer]

Hi guys,

I have been trying to get an answer if there are problems of using Vulkan with the Nexus 6P crashing as soon as the app starts up. I am on the latest GitHub build (4.12.1) and even switched over the NDK r12 beta to no avail. I have even tried to install the APK on a Shield TV to see if the NVIDIA Vulkan API works and even though it did not crash, the screen image was a 2D image with some animated artifacts. I have been even able to use the 'Vulkan Mobile Preview' in the editor without issue.

I am currently trying to push the limits of the "Sun Temple" and have had great visuals, albeit poor FPS. It would be great to see how well it performs on the Nexus 6P with Vulkan enabled. I have also found that enabling "Sustained Performance" really takes a FPS hit. Running it disabled and the results are now comparable to the the Nexus 6 (also running 'N'). I have also found the "scan-line racing" also performs poorly as well as adding an odd image trail.

Any answers or feedback is welcomed.

[Chris Babcock]

The only part of the NDK we use is the Vulkan header; the libvulkan.so is loading dynamically and it loads the Vulkan driver if available on the device. Driver issues can only be fixed in Nexus 6P by updating the Android N preview. I know there are issues with the driver in preview 2. As Jack mentioned above, Vulkan is a work in progress at the moment.

The rest of the post seems to be about DayDream. This is also a work in progress in the Android N previews and DayDream hardware is not available yet.

[JackP_oldaccount]

I have been trying to get an answer if there are problems of using Vulkan with the Nexus 6P crashing as soon as the app starts up.

To follow up from what Chris said, we are seeing a crash on startup on the Nexus 6P with preview 2. We have ticket UE-30753 to look at the issue but I don't have anything to report yet.

[mebalzer]

Actually I am on preview 3 (Beta) and still seeing these issues.

I have been working with Sascha Willems from the Vulkan Hardware database, and he has provided me a series of updated Android demos that I would be happy to share with you if that will help. Most of the demos seem to work on the Nexus 6P, and all work on the Shield TV. However none of my enabled UE4 Vulkan demos work with either NDK 11c or 12 beta.

I guess my question is what Android hardware do you have that this works on? I would love to know since part of my testing with UE4 requires Vulkan to work under Android (it does not need to be Google VR). (See my latest tweets and post later today on my UE4 "The Fight" conversions)

Thanks,

Mike Balzer
All Things 3D
NEOD.io

[JackP_oldaccount]

As you may have seen, we demonstrated a UE4 Vulkan demo called Protostar on Samsung Galaxy S7 in late February. Our initial development work has been on those devices, although we require the very latest Vulkan drivers on S7 (both Adreno or Exynos variants) to work with UE 4.12.

I've added a note to the UE-30753 ticket with your report that preview 3 Nexus 6P still having the same issue. We plan to address this for 4.13 but at the moment we don't know if the problem lies with UE4, the driver or both. Our Vulkan support is still very experimental.

- Jack

[Matthew J]

Hello everyone,

We recently tested a fix for the UE-30753 bug and it's now been fixed. The fix is currently sitting in our of our development streams so it isn't available on Github quite yet, but if any of you would like that information whenever it has been merged into Master or Release, please let me know and I'll be sure to follow up.

[motorsep]

Three questions to Epic devs:

1. Do you know if Vulkan is coming to Galaxy S6 family of phones ?
2. Do you have approximate ETA (this fall, this winter, next year) on when UE4 with Gear VR will be able to run Vulkan instead of GLES 2.0 ?
3. Based on #2, when stock UE4 will be shipping with Vulkan ?

Thanks