Vulkan status

Actually, I don’t know where in the engine texture arrays are used by default. Since the texture array code is implemented for OpenGL, D3D11, D3D12 and Metal I am quite sure they are used somewhere, but I have no idea where.

I am using this PR to expose the texture array functionality to materials: .com/EpicGames/UnrealEngine/pull/2340

So with that PR its very easy to see the crash, just import a texture array and use it in any material. But as I said, since the texture array code itself is in the engine (that PR only makes them usable from materials), they are probably used somewhere in the engine, so that PR shouldn’t be necessary for reproducing this issue. I am using textures arrays because the only real alternative would be texture atlases, and texture arrays achieve the same thing, just a lot nicer :slight_smile:

@

I just searched through github, and I found a commit where you edited the function:

.com/EpicGames/UnrealEngine/commit/9cac5b41e76753f5f627e13d3e4984da193dee29#diff-d533638022f4babfe13c1658ad6d7043L835

You removed the


 return Texture->Surface.Lock(MipIndex, TextureIndex, LockMode, DestStride);

and replaced it with a


VULKAN_SIGNAL_UNIMPLEMENTED(); return nullptr;

That was back in May 2016.

Hey @, do you know when it will be fixed? Or is it already in fixed in some internal branch? :slight_smile:

Not yet, sorry :frowning: it’s in our TODO list but no current fix date yet, moreso due to the fact that it’s not an easy to repro case.

But do you need a repro for that? You see that the function is completely unimplemented in Vulkan, while its implemented for all other APIs. So its pretty clear that it can’t work with Vulkan, do you need a repro case for seeing that a function that pretty much just has a check(false) inside (thats what VULKAN_SIGNAL_UNIMPLEMENTED() is doing) crashes? :rolleyes:

There are also at least one other place where it would crash if not in that function, like here:

.com/EpicGames/UnrealEngine/blob/76085d1106078d8988e4404391428252ba1eb9a7/Engine/Source/Runtime/VulkanRHI/Public/VulkanResources.h#L498

There its also just doing check(false) if someone tries to get a Texture2DArray with Vulkan.

If the code would just do whatever it does for the other APIs it might just work. Maybe you could just ask whoever wrote the Metal implementation how they tested it. Or you could just implement those things (so that its no longer doing things like check(false) or VULKAN_SIGNAL_UNIMPLEMENTED() there, and wait for someone like me to try it out, maybe it will just work. No matter what you do, it won’t get worse than a check(false), right? :cool:

Just this one time I added the missing code: as nothing is calling it, it won’t cause issues if it’s broken; however just want you to understand that you’re running into this code since it’s (still unfortunately) an experimental RHI with a PR that we haven’t integrated/cleaned into the engine; there will potentially be issues because of it. We want our code to be clean, solid, optimal and cause as few problems for you and everyone else (including us!). If you can fix it, feel free to contribute a PR. This will make its way to main/git master next week.

Awesome, thanks very much! :cool:

I am completely aware of that Vulkan is still experimental, but since nothing is calling it, even if maybe all materials that use texture arrays will fail to compile and show the default material or something like that, anything in this case is better than just crashing due to a check(false). It still allows me to see if all the other things in the game work correctly, while just crashing doesn’t, and I hope it helps you if more people test Vulkan with their games.

I am really wondering though why the texture array RHI stuff was implemented for OpenGL, D3D11, D3D12 and Metal if its really not used anywhere. It’s definitely great that it is since that allows that PR to easily expose it to materials without having to modify any RHI specific stuff.

Do you have something like a list of things that are known to be broken in Vulkan, so things that I don’t even need to mention if I see them not working? For example I would guess that distance field features might not be supported yet?

No list right now; once we get QA to do more serious testing of features (and/or whatever we get from user’s reports) then we know that’s broken. There might be spir-v issues in the shaders that might cause glitches we haven’t seen for example. It ‘should’ have the same features/support as GL4.

Hey, guys. Nougat just dropped for S6 and had at least minimal Vulkan support. Christmas came early I guess. I thought my S6 was turning into an expensive paperweight, but it has some life left.

Just a quick question that is related to Vulkan: Do we have any demos specifically made for vulkan? I’d like to try out my new S8 with UE4 and Vulkan but I can’t seem to find any demos and the Protostar demo from last year is nowhere to find :frowning:

Samsung is the one who distributes Protostar (not sure how)…

Not directly related to Vulkan.
From the RHI perspective how much Vulkan and DiretX 12 are similiar ? Aside from current implementation, is it possible to have 100% feature parity ?

That is the plan! API wise differences should be really minor.

Bam! Oculus supports Vulkan now, officially:

https://developer.oculus.com/downloads/package/oculus-sdk-for-windows/

When is support coming to UE4 ?

How much longer till the Desktop version of Vulkan becomes Stable?

We’re actively working on it. While not making any promises :wink: I’m personally aiming for 4.17 to have a way better experience.

With Oculus VR support ?

Does “a way better experience” mean “at least parity with dx11”?

Well that sure is reassuring thank you

Hey Rolando,

I just compiled 4.17 to test some Vulkan stuff. It was a few engine versions ago that I last looked at Vulkan, so I thought it was time for it again, and I think if you want 4.17 to have a “way better experience” it’s probably good to start reporting bugs with Vulkan as soon as possible so that things can get fixed before the 4.17 release :cool:

I couldn’t test the texture arrays with Vulkan due to that I could not even get them to work with D3D11 on 4.17, something in 4.17 seems to be a bit broken with texture arrays. I’m sure Koderz will fix this relatively soon, I just don’t know the texture array code enough to figure out why they don’t work in 4.17.

I tested some other Vulkan stuff though! I remembered you said running the editor with vulkan might actually work, and so I did. Using the third person example project (only thing I changed was that I set the light to movable, I don’t like dealing with baked lighting). And, I was surprised! The editor actually launched, it let me select the project, and it absolutely did not crash. Didn’t expect it would work that well! Also no visual issues, everything looked the way it should look (probably not too hard in the default third person project, but I remember when I tested vulkan editor a long while ago slate would have weird wrong colors, and slate definitely works perfectly now).

After a bit of testing I found some small issues though:

  1. profilegpu does nothing. Just nothing. No window opens, also no profiling output in the log.
  2. stat gpu is not working too. No stats appear, so its also just doing nothing.
  3. stat unit has a flickering gpu time:

Also I’m not sure if that gpu time is correct, it looks significantly too low.

  1. There is no selection outline. When I select something, I see nothing indicating that I selected something apart from the pivot point that moved. No outline, also no filled orange thing. Just nothing.

  2. From some very specific positions at specific angles, I can get geometry or even the whole screen to flicker:


[video]https://i.gyazo.com/07a627585e50aab83bdeecfc563e1255.mp4[/video] (had to be mp4, the gif version was lower framerate and exactly removed the black frames)

That “whole screen flicker” is pretty much just a black frame sometimes. It is not completely dependent on the camera position and angle, after a while it just disappears at locations where it happened before.

  1. This one is very rare, so I get it something like once every 50 seconds or so when I try to reproduce it, so I’m not able to capture a gif of that unless I capture my screen for a few minutes. If you want to see it I can do that, but you probably understand how it looks like from my description:

Sometimes it looks like randomly colored and distributed triangles that fill ~half the game screen pop up for one frame. Its not geometry of the game, it looks like random huge triangles. Only one at a time though. So one huge triangle for one frame. The most successful way of reproducing this that I found is holding the right mouse button in the game window, moving the mouse a bit to turn the camera, and release the right mouse button again. Then repeat that all the time. So just always turning the camera a bit. it does not seem to happen when I just hold the right mouse button all the time and then rotate the camera. Maybe related to making the mouse cursor visible and invisible, I don’t know.

That’s all I found for now in the third person project :smiley:

My GPU is still a R9 390 with the newest stable driver and I’m using Windows 10 now.