DX12: Gradient Post Process not blending on screen on Bayonetta

[Yukikami39]

In the demo theres no post process used in the first cutscene so you could see, the background rendered perfectly ( with some vertex corruptions here and there ) and models kinda did not I used PR #1931

[kd-11]

Does this only affect dx12? What happens with other backends?

[Yukikami39]

bayonetta wont run on vulkan, crashes the emulator after the P+ intro, opengl goes little bit further into menu, but freezes on the loading screen when going ingame and gives this {rsx::thread} class std::runtime_error thrown: OpenGL error: invalid operation. file 'C:\rpcs3\rpcs3\Emu\RSX\GL\GLGSRender.cpp' function 'GLGSRender::end' line 415

so yea currently only dx12 can run it

[dbz400]

Alright .Thanks for the report.

[Yukikami39]

@kd-11 @raven02

I think this should help somehow http://cemu.info/changelog/cemu_1_5_0.txt cemu had the same issue as rpcs3 with bayonetta and cemu 1.5.0 fixed the issue, might be worth looking in the changelog to see what fixed it

cemu 1.4.2 : https://www.youtube.com/watch?v=zyKigIv2bL4 cemu 1.5.0 : https://www.youtube.com/watch?v=ddtrWLp5xuk

[kd-11]

Looks like they fixed some texture formats. I dont have access to any amd dx12 debugging tools and I havent seen any good frame debuggers for dx12 except maybe nsight but that only works with nvidia gpus. Does vulkan crash the emulator from windows i.e "rpcs3 has stopped working" or in the emulator with a message?

[dbz400]

I run it in debug mode in VS2015 , Vulkan backend breaks at the following line

CHECK_RESULT(m_swap_chain->queuePresentKHR(m_swap_chain->get_present_queue(), &present));

[Yukikami39]

@kd-11 yea, as I said, vulkan crashes after the P+ intro with stopped working

[SakataGintokiYT]

@kd-11 @raven02 What about this ? http://developer.amd.com/tools-and-sdks/graphics-development/gpu-perfstudio/

[kd-11]

GPU Perf Studio is only useful for opengl. The vulkan and dx12 debugging has no frame debugger where you can inspect individual draw calls, just a command log. Its useful, but you cannot tell what draw call draws what part which is what is usually useful and has no real time shader editing. It also has some annoying bugs which I have reported but are yet to be resolved. Renderdoc is so much better and I moved to using it, but no dx12 support, only gl and vulkan.

[kd-11]

@raven02 queuePresentKHR exception implies resource is being used concurrently, an issue that is very difficult to debug. We could add intentional stalls but that is usually a crazy solution. Is it a regression?

[dbz400]

@kd-11 .Not too sure if it is an regression .I will try to track back some very old build that first provide vulkan nvidia support to see if it crashes.

[kd-11]

@raven02 Disable glcheck in gl_helpers.h (change #if 1 to #ifdef _DEBUG, you can see the original commented out) for release builds and enable debug output instead. The driver will give more meaningful messages. glcheck is only suitable when the developer is the one doing the debugging with the game. Try running in opengl mode.

[dbz400]

@kd-11 , regarding disable _glcheck , is it applicable for vulkan that we can use it to debug the queuePresentKHR exception ? (I just hit another queuePresentKHR exception in another game )

[dbz400]

Look like quite many game using Vulkan will suddently break

[dbz400]

or we can test with add intentional stalls ?

[kd-11]

You can stall the pipeline manually (using sleep) to check whether we are skipping a wait somewhere. Its rather difficult to debug this without access to the hardware and drivers though. Is it for all games? If not, what is different about the games that cause the crash?

By the way, check if any gcm samples can trigger this. That would be so much easier to check.

[dbz400]

It is not for all games and i checked few GCM samples also not able to trigger .

BTW , where to add the sleep would be appropriate ?

I try to enable the debug output option to run this crash scene , other than hits the queuePresentKHR exception , the exact moment crash also shows this in log console

·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdBeginRenderPass()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdBindPipeline()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdBindDescriptorSets()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdDraw()
·E {rsx::thread} RSX: ERROR: [DS] Code 52 : DS 0x822151 encountered the following validation error at draw time: Descriptor in binding #21 at global descriptor index 20 is being used in draw but has not been updated.
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdEndRenderPass()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdSetViewport()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdSetScissor()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdSetLineWidth()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdBeginRenderPass()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdBindPipeline()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdBindDescriptorSets()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdDraw()
·E {rsx::thread} RSX: ERROR: [DS] Code 52 : DS 0x822151 encountered the following validation error at draw time: Descriptor in binding #21 at global descriptor index 20 is being used in draw but has not been updated.
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkCmdEndRenderPass()
·E {rsx::thread} RSX: ERROR: [DS] Code 32 : You must call vkBeginCommandBuffer() before this call to vkEndCommandBuffer()
·E {rsx::thread} RSX: ERROR: [DS] Code 7 : Cannot submit cmd buffer using deleted image 0x821f17.

[kd-11]

Yea. The crash is here:

·E {rsx::thread} RSX: ERROR: [DS] Code 7 : Cannot submit cmd buffer using deleted image 0x821f17

You'll have to inspect the lifetime of vk::image objects to find out what was deleted while in use (probably a framebuffer). Try blocking after every queuePresentKHR before m_invalidated_resources is cleared. m_invalidated_resources contains rtt images that we deem to be not useful anymore and can be recycled or destroyed.

[dbz400]

Just wonder how to do blocking after queuePresentKHR before m_rtts.invalidated_resources.clear() ?

[kd-11]

You can stall manually (thread sleep) or add a pipeline barrier with ALL_GRAPHICS_BIT and wait on that (should be similar to issuing a glFinish()). I think it will be easier to just add messages to any image creation and deletion points. I think VkImage will be a ptr handle so you can add messages to check which image gets created/deleted and compare with the output from the debug layer.

[dbz400]

Yep , will try to add messages to image create/delete and compare with log output

[dbz400]

I track it here

    ~image()
    {
        LOG_ERROR(RSX, "Deleted image 0x%x", value);
        vkDestroyImage(m_device, value, nullptr);
    }

·E {rsx::thread} RSX: Deleted image 0x4e2b9 ·E {rsx::thread} RSX: ERROR: [DS] Code 7 : Cannot submit cmd buffer using deleted image 0x4e2b9.

[kd-11]

@raven02 Are other images deleted before this one or is it possible to obtain a call stack by breaking with the debugger? It may be a simple case of bad code ordering (hopefully). If not, I can write a special build that tracks images with refs or at least tags them with descriptive strings.

[kd-11]

By the way, any other games that exhibit this behaviour? If I own a copy, I can test rather quickly.

[dbz400]

Another game exhits this crash is Dai-3-Ji Super Robot Taisen Z Jigoku-hen (I think you have this one) .This is the save NPJB00520-STG-000.zip

[kd-11]

@raven02 Thanks.

[dbz400]

Fight the red one using green one and will trigger a scene then 5 seconds later will crash .

[dbz400]

Crash at this one and can always reproduce

[dbz400]

I tried something stupid that comment out the vkDestroyImage . The crash gone for both 1942 Strike and Dai-3-Ji Super Robot Taisen Z Jigoku-hen

//vkDestroyImage((*owner), m_image_contents, nullptr); //vkDestroyImage(m_device, value, nullptr);

[kd-11]

Well, that'll crash your GPU in minutes with some games. GL and vulkan don't properly reuse their invalidated/old texture resources and discard immediately at the end of every frame. New surfaces are generated for each frame (If the game does not manage surfaces conservatively). I'll rewrite some parts of both renderers once rsx refactoring is finished.

[dbz400]

Cool . It is good we can confirm the deleted image trigger the crash. If you have any test build want me to test , let me know .

[kd-11]

I found the cause of this error. I'll upload a fix for this as well as the rtt recycling code soon.

[kd-11]

https://github.com/RPCS3/rpcs3/pull/2045 should solve the texture-related issues.

[dbz400]

Thanks @kd-11 .