Announcement

Collapse
No announcement yet.

Vulkan status

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    [MENTION=3163]ZacD[/MENTION]: I'll let someone [MENTION=2150]JackP[/MENTION] answer the android question, but FYI we're actively working on Vulkan: We don't have a firm/commited date yet but I'd expect Vulkan to be very close to 'done' in a few months. This is in part as Vulkan is driving changes to the RHI interfaces which have to be done on all other RHIs (D3D11, D3D12, Metal, OpenGL, consoles) so it's not quick, and we want to build a solid foundation for the future of the renderer/engine

    Leave a comment:


  • replied
    From what I've heard.

    1. "Vulkan will be officially supported in Android commencing with Android "N"". So support on Galaxy S6 would depend on Samsung updating their phones. In the past Samsung is slow and bad about keeping their phones on the latest version of Android, except for their flagships, so the S7 might get it by the end of the year, and the S6 might get it months later or never.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    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

    Leave a comment:


  • replied
    Originally posted by mebalzer View Post
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Originally posted by JackP View Post
    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.

    Leave a comment:


  • replied
    Hi guys,

    Originally posted by TheJamsh View Post
    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

    Leave a comment:


  • replied
    Originally posted by RCaloca View Post
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    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:
    Code:
    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.
    Last edited by Yaakuro; 06-04-2016, 08:57 AM.

    Leave a comment:


  • replied
    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.
    Last edited by John Alcatraz; 06-03-2016, 11:05 PM.

    Leave a comment:

Working...
X