Hi , do you know if it happens with 4.18 or 4.19? There’s been like a year’s worth of fixes since 4.15 
Hi Nilson, is this also broken on OpenGL? By SM5 do you mean D3D?
Running at 200 screenpercentage would make it GPU bound no matter with RHI (D3D, GL, etc). Are you GPU or CPU bound?
Yes, it’s been hard to get driver support on Android devices. IIRC some of the features you want (Subsurface scattering) require geometry shaders which are not available on mobile devices, and the renderer has not been brought up to date to check what can we run with what devices (on the flip side of the coin, we have to work on all the lower end devices too).
Don’t see why we can’t get WPO working though, and maybe AO… I’ll enter a ticket for the mobile rendering guys to check out. The # of samplers issue is a bug, I’ll enter a ticket for that too.
Yes Im currently using D3D (SM5) not OpenGL. My project is this: https://www.unrealengine.com/marketp…dscape-seasons and it taxes GPU a lot, but it is fully customizable and at D3D I can run it at Epic or Cinematic with no issues with 100+FPS, I was expecting to have it working same way in Vulkan. I didn’t try OpenGL yet (not sure why) but maybe because I recall of some feature I would need in a future implementation, Im almost sure the research is writen somewhere.
Wow, thank you! I remembered UDK had AO, Refraction, Transmission, and not nearly as much limitations as what we currently have for mobile. If we can fall back to a cheaper version of subsurface scattering for mobile that doesn’t require geometry shaders, like Transmission, that might at least look a bit more correct than the default opaque surfaces for skin and wax/gels.
I was actually hoping to develop a mobile game that brings feature parity with PCs and release it on Steam as well. But when I saw how stringent the requirements were for developing in Vulkan (and only two devices are currently supported), I fell back to traditional mobile development and was shocked to see how much is missing from it.
Yes, this still happens with 4.18, 4.19 I will try once it releases. I did not specify it in my answerhub post I guess, I started with mobile rendering since 4.15 but th issue has occured on all versions after that too. I’ve been looking everywhere and only 3 times or something has this question been asked but left unanswered. I honestly don’t know what’s going on. Tbh, I think the fault lies more with ES3.1 than with Vulkan but I’m not sure.
The UDK mobile renderer was its own thing, whereas for UE4 we decided to reuse the code for the desktop renderer to reduce the number of headaches from two code paths I’ll enter them as part of the ticket.
Yes it’s sad not too many mobile devices support Vulkan. As you mentioned, you running into the limitations of the mobile renderer, not of Vulkan itself (well, also the mobile device’s capabilities).
Well, if Vulkan was theoretically more widely supported, say, 2-3 years from now, there wouldn’t even need to be a separate mobile rendering path. Vulkan can just conglomerate everything into one universal API that supports every rendering feature imaginable, every device imaginable, and games can target every device by simply scaling per device. Well, a man can dream, can’t he?!
I’ve been tracking the limitations of features between mobile and DX11. I’ll make a separate post about it.
Hey @ ,
could you give an update on where Vulkan in UE4 currently is? How far are you from equal performance to DX11, what’s still missing, is it making use of parallel rendering already, if not when will it do?
Last dev-rendering merge was more than 2 months ago, so there’s no way to see what’s actually happening
@Chariots Thanks a lot for your testing! Very interesting. I saw on github that a few months ago GPU skinning was enabled for Vulkan, so it makes a lot of sense that skeletal mesh rendering is significantly faster than before.
@ Beep 
I have done my testings with Vulkan and shared with , basically because I was not being able to have a successful material presentation (no error in compiling) meaning it was invisible. The material compiler was unable to handle a custom node as dependency of another custom node (weird but understandable trick teached by Ryan Brucks). To make my material work I had to unfold the custom node (dependency) inside the main custom node, which in the end resulted in the same amount of instructions inside the shader, which seems correct too.
Now, my testings didn’t show a good performance with Vulkan in any scenario I have tested. I think it can’t properly handle the raymarching custom node as efficient as DX12 can. I also have tried both DX12 and Vulkan (tested OpenGL too later) with Forward Render and both executed faster, but still Vulkan was behind DX12.
Im cool everything at least works, but I was really with the thought that maybe Vulkan would provide significant gains over DX12. Maybe thats mainly because Im using NVidia card and not AMD, which some speculates have a better Vulkan implementation and the GPU also helps with their technology. (I dont have a card to test unfortunetely and for their cost today I wont buy one)
I don’t think anyone expects that a good Vulkan renderer gives significantly better performance than a good DX12 renderer, they should be roughly equal. The PC DX12 renderer in UE4 is far from ideal though, so I guess you mean you expected that the UE4 Vulkan renderer would be better than the UE4 PC DX12 renderer? I think that will definitely be the case on PC at some point, because there’s no point in doing any DX12 related work on PC any more when you have Vulkan that works pretty much everywhere. The Vulkan code in UE4 is still way newer though, so I don’t expect it just yet.
I expected that Vulkan would at least be on par, 30%+ difference it too much for my taste. I don’t know where the bottleneck is. Just to place those tests here, since I posted as message to :
"So far, we have choosen a scene not too complex, with simple materials mostly (all green), FX 9370 3.6GHz and GTX 1080 not OC’ed
Conditions: texture sizes 2048, Epic settings, Full HD, dynamic lighting, main light with movement each second to simulate 1 hour = 36 seconds (time pass 100 x faster), minimum SM5 feature set, Vulkan for Desktop
test a) Deferred Render, DX12, SM5, 160 raymarch steps : 69 FPS
test b) Deferred Render, DX12, SM5, 384 raymarch steps : 51 FPS
test c) Forward Render, DX12, SM5, 160 raymarch steps: 84 FPS
test d) Forward Render, DX12, SM5, 384 raymarch steps: 58 FPS
test e) Deferred Render, Vulkan, SM5, 160 raymarch steps : 46 FPS
test f) Deferred Render, Vulkan, SM5, 384 raymarch steps : 35 FPS
test g) Forward Render, Vulkan, SM5, 160 raymarch steps: 57 FPS
test h) Forward Render, Vulkan, SM5, 384 raymarch steps: 41 FPS"
Just to complete as info, the material tested was a giant cube with two-sided material, so I am drawing inside and the camera picks a very small part of this mesh since it is inside it, this is how it looks like in a video at 15min:50sec (it is just too long, so check that the spot) : https://youtu.be/InBJKNQcU9M
The scene I was expecting to get in test “e” at least 80 FPS, but went from 69 to 46 which is 33% less… would be nice to stay the same…
I posted today a bug submission form with an issue with Vulkan (also OpenGL) where the reflections are incorrect when using Planar Reflections. I have not tested with just SSR yet and haven’t tested with Forward render, all tests with deferred render. The receiver asked me for screenshots besides the sample project, but I instead made 3 small videos show the issue in two different scenarios, and how they are correct in DX12. Tomorrow I will try with SSR and if I have time I will check Forward render aswel.
first => first video with planar reflection issue - YouTube
second => second video showing the Planar Reflections issue - YouTube
third => Third video with Planar Reflections issue - YouTube
Hi all, first post here. I see 4.19 was just released almost an hour ago, and looking through the release notes there is no mention of Vulkan updates this time around. Could Epic provide us with a summary of the current status of the Vulkan rendering API? How close is it to production stability for Windows and Linux desktops?
Thanks in advance,
I’d like to know that too. Using Vulkan on Unity giving my project a huge boost (hundreds times faster). I’m waiting for the same in Unreal. Don’t care of Dx12, please implement Vulkan as quickly as possible on PC and Linux. It’s a hellish good technology.
There is though. For example here’s a few bug fixes:
- Bug Fix: Fixed Anisotropic Filtering not working on Vulkan.
- Bug Fix: Memory is no longer reallocated on every Vulkan draw call.
The recent issues I have found with Planar Reflections still not fixed yet and affects OpenGL aswel.
The 4.19 cut off was a few months ago, so a ton of fixes (specially for performance) are going to be on 4.20.
Planar reflections is a known bug that’ll be fixed for 4.20.
I’ll update this thread post-GDC.
There’s no way it is actually running HUNDREDS of times faster just from using vulkan, unless the previous renderer was complete fail…