Vulkan: freezes/crashes (Nvidia Specific)

[B1ackDaemon]

4 Elements HD [NPUB30347] - freezes ingame, when tutorial dialog appears.
http://rghost.ru/7JpXZHY22/image.png
Bayonetta [BLES00599] and Bayonetta: First Climax demo [NPEB90193] - always freezes after you trying to pass "Press Start Button" screen.
http://rghost.ru/6CysPvx6M/image.png
Disgaea 3 [BLES00452] - freezes after intro skip, when you start new game.
The Guided Fate Paradox [NPUB31320] - got ingame freeze, when try attempt to equip items.

Those freezes doesn't occur, when using OpenGL renderer. Also noticed, that VSync option doesn't work. Tested on GeForce GTX 970 with 364.91 drivers (Vulkan API 1.0.8).

Edit: added logs from recent master build 75fe95e, PR #1676
http://rghost.ru/7SSVCm8j5

[vlj]

Nvidia drivers don't support VSync with Vulkan atm. They expose Mailbox/FIFO/... present mode but for some reasons they're not vsynced.

[kd-11]

Seems vkAllocateDescriptorSets fails at least for the first two.

[kd-11]

@B1ackDaemon You could try and increase the descriptor pool sizes. They currently top out at 1000 draw calls per frame. They were increased before, but it seems they need to be increased some more. I've seen games with > 1000 calls in some situations.

[SakataGintokiYT]

@kd-11
VKGSRender.cpp
VkDescriptorPoolSize uniform_buffer_pool ?

VKHelpers.h
infos.maxSets = 1000; ?

[kd-11]

@SakataGintokiYT you need to change that as well as in the VKGSRender intitialization code. There are some values there like 3000 and 16000 which are calculated using 1000 * num_descriptors; i.e there are 3 uniform buffer descriptors, 16 texture descriptors and 16 vertex texture descriptors giving 3000, 16000 and 16000 respectively. You'll need to recalculate those values as well. We'll need to automatically balance the draw call load by flushing the command queues when we run out of descriptors, but increasing the sets should be ok for now.

[kd-11]

#1766 will fix most of the descriptor set issues.

[dbz400]

Vsync is working with Vulkan in Nvidia driver 368.81 (driver level , not the VSync option in RPCS3)

[dbz400]

@kd-11 .Thanks for fixing the memory type crash on NV . The 1942 Joint Strike is a different crash that startup ok but everytime crash with the following error only

·E {rsx::thread} RSX: ERROR: [DS] Code 7 : Cannot submit cmd buffer using deleted image 0x2000.
·E {rsx::thread} RSX: ERROR: [MEM] Code 12 : vkCmdBeginRenderPass(): Cannot read invalid memory 0x1ffa, please fill the memory before using.
·E {rsx::thread} RSX: ERROR: [DS] Code 7 : Cannot submit cmd buffer using deleted image 0x295b.
·E {rsx::thread} RSX: ERROR: [MEM] Code 12 : vkCmdBeginRenderPass(): Cannot read invalid memory 0x2954, please fill the memory before using.

[kd-11]

About 1942; on radeon it detects that we are issuing commands without an open commandbuffer, but as far as I can tell, that is not the case. I'm suspecting a bug in the validation layers somewhere that caused the commandbuffer to detect as closed. Maybe its because of the deleted image stuff. I'll look into it separately.

[kd-11]

@raven02; Just a hunch, could you check if commenting out the if(m_rtts_dirty) return block in prepare_rtts fixes the crash with 1942? I suspect we are doing something shady with the framebuffers like deleting them after every frame.

[dbz400]

@kd-11 Just tried to comment out that block and compile but it still crashes with the same error.

if (!m_rtts_dirty)
    return;

[dbz400]

Just tried out 4 elements HD and want to test the mentioned freeze , it boots up then hit this error .

F {rsx::thread} class fmt::exception thrown: vk::image::image(): Assertion failed! Result is C4650B07h
(in file c:\rpcs3\rpcs3\emu\rsx\vk\VKHelpers.h:368)

[kd-11]

@raven02 Thats a failed VkCreateImage call. You'll need to check the specifics of the failed image configuration in that case. NV uses their own internal error codes so there's no way to know what that error code means.

[dbz400]

I see this error code before when we check the resize/full screen issue previously.

            info.sType = VK_STRUCTURE_TYPE_IMAGE_CREATE_INFO;
            info.imageType = image_type;
            info.format = format;
            info.extent = { width, height, depth };
            info.mipLevels = mipmaps;
            info.arrayLayers = layers;
            info.samples = samples;
            info.tiling = tiling;
            info.usage = usage;
            info.flags = image_flags;
            info.initialLayout = initial_layout;
            info.sharingMode = VK_SHARING_MODE_EXCLUSIVE;

            CHECK_RESULT(vkCreateImage(m_device, &info, nullptr, &value));

[dbz400]

Get more detail when enabled debug output. It is width = 0 .

E {rsx::thread} RSX: ERROR: [ParameterValidation] Code 1 : vkCreateImage: parameter pCreateInfo->extent.width must be greater than 0
 {rsx::thread} RSX: ERROR: [Image] Code 13 : CreateImage extents is 0 for at least one required dimension for image of type 1: Width = 0 Height = 47104 Depth = 1.
E {rsx::thread} RSX: ERROR: [Image] Code 13 : CreateImage extents exceed allowable limits for format: Width = 0 Height = 47104 Depth = 1:  Limits for Width = 16384 Height = 16384 Depth = 1 for format VK_FORMAT_B8G8R8A8_UNORM.
E {rsx::thread} RSX: ERROR: [Driver] Code 0 : vkCreateImage: image creation failed due to invalid parameter

[dbz400]

Interesting . I tried a build few days ago, it can show few screens though hit the same error once reach the title screen.

It first "break" at #1982

[kd-11]

@raven02 Can you obtain a callstack using visual studio? If we can find the function responsible for creating an image with bogus dimensions, we can probably find the broken register decode. That height value of 47104 is also bogus. Just add a check and throw in the image constructor for width 0 and break, then get the callstack.

[dbz400]

Sure . let me check this out.

[dbz400]

[dbz400]

Probably is NV3089_IMAGE_IN_SIZE or NV3089_IMAGE_OUT_SIZE

[kd-11]

@raven02
I'm almost certain you stumbled upon a 3d texture. Very interesting. The texture upload algorithm is broken in case we have texture_dimension_3d since height is never set, hence the bogus value. However, width is still computed using tex.width() so that might be another bug.

[dbz400]

Yep, this is the 1st texture/image show when bootup in DX12

[dbz400]

I put in the following in VKtexturecache.h and looks like width zero is 2D texture

        if (tex.width() == 0)
            throw EXCEPTION ("width is zero, height = %x , teture type : %x", tex.height(), tex.get_extended_texture_dimension());

F {rsx::thread} class fmt::exception thrown: vk::texture_cache::upload_texture(): width is zero, height = f800 , teture type : 1
(in file c:\users\jacky\documents\github\rpcs3\rpcs3\emu\rsx\vk\VKTextureCache.h:230)

[Nezarn]

@raven02 also since you're there, you could fix that typo lol (teture type should be texture type, no?)

[dbz400]

@Nezarn. Yep, it is only for testing purpose .

[kd-11]

@raven02 #2018

[dbz400]

@kd-11 . no more assertion failed but infinite looping with the following errors and black screen

E {rsx::thread} RSX: Texture upload requested but invalid texture dimensions passed
E {rsx::thread} RSX: Texture upload failed to texture index 0. Binding null sampler.

[kd-11]

Well, yea, 0 dimensions will give a blank output. I'm surprised that DX12 is getting a different texture dimension than vulkan here: I'm probably missing something thats broken elsewhere. Can you check what dimensions DX12 gets for this texture upload request?

[dbz400]

Sure will check this out on DX12

[dbz400]

@kd-11 , not really , DX12 also failed at zero width and f800 height as well . I logged at get_texture_description():

LOG_ERROR(RSX, "width = %x , height = %x", texture.width(), texture.height());

E {rsx::thread} RSX: width = 0 , height = f800
F {rsx::thread} class fmt::exception thrown: `anonymous-namespace'::upload_single_texture(): HRESULT = The parameter is incorrect.
(in file Emu\RSX\D3D12\D3D12Texture.cpp:138)

[dbz400]

It affects all backends indeed