RPCS3 / rpcs3

PlayStation 3 emulator and debugger
https://rpcs3.net/
GNU General Public License v2.0
15.4k stars 1.92k forks source link

DX12: Gradient Post Process not blending on screen on Bayonetta #1942

Closed Yukikami39 closed 8 years ago

Yukikami39 commented 8 years ago

i894 cimgpsh_orig 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 bayonet 2 bayonet 3 I used PR #1931

kd-11 commented 8 years ago

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

Yukikami39 commented 8 years ago

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 commented 8 years ago

Alright .Thanks for the report.

Yukikami39 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

SakataGintokiYT commented 8 years ago

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

kd-11 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

Look like quite many game using Vulkan will suddently break

untitled

dbz400 commented 8 years ago

or we can test with add intentional stalls ?

kd-11 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

kd-11 commented 8 years ago

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 commented 8 years ago

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

dbz400 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

dbz400 commented 8 years ago

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 commented 8 years ago

@raven02 Thanks.

dbz400 commented 8 years ago

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

untitled

dbz400 commented 8 years ago

Crash at this one and can always reproduce

untitled

dbz400 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

kd-11 commented 8 years ago

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

dbz400 commented 8 years ago

Thanks @kd-11 .