Squall-Leonhart
commented
7 months ago This is a regression in the mesa driver and also affects vulkan games
Closed leifliddy closed 7 months ago
Squall-Leonhart
commented
7 months ago This is a regression in the mesa driver and also affects vulkan games
leifliddy
commented
7 months ago @Squall-Leonhart I'm not sure that csgo issue lines up with that I'm experiencing with Cemu
I don't have any issues running any Steam games with with running vulkan utilities....
Here's some additional information on this issue It appears to be related to this line: https://gitlab.freedesktop.org/mesa/mesa/-/blob/23.3/src/amd/vulkan/meta/radv_meta_clear.c?ref_type=heads#L325
gdb Cemu core.MainThread.1000.9a22b0dc20db4405bb56fcdb330d478e.352706.1708782917000000
......
Downloading separate debug info for /usr/lib64/libvulkan_radeon.so
Downloading separate debug info for /lib64/libdrm_amdgpu.so.1
Downloading separate debug info for /lib64/libelf.so.1
Downloading separate debug info for /root/.cache/debuginfod_client/46905bd6ac3e5483cc688f1b72207a0e7dee153c/debuginfo
Downloading separate debug info for /lib64/libVkLayer_MESA_device_select.so
Downloading separate debug info for system-supplied DSO at 0x7ffed913d000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./Cemu'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f23790aba42 in emit_color_clear (view_mask=0, clear_rect=0x7f2268bfe080, clear_att=0x7f2268bfe140, cmd_buffer=0x471aeb0) at ../src/amd/vulkan/meta/radv_meta_clear.c:325
Downloading source file /usr/src/debug/mesa-23.3.5-1.fc39.x86_64/redhat-linux-build/../src/amd/vulkan/meta/radv_meta_clear.c
325 if (device->meta_state.color_clear[samples_log2][clear_att->colorAttachment].color_pipelines[fs_key] ==
[Current thread is 1 (Thread 0x7f2268c006c0 (LWP 352769))](gdb) bt
#0 0x00007f23790aba42 in emit_color_clear (view_mask=0, clear_rect=0x7f2268bfe080, clear_att=0x7f2268bfe140, cmd_buffer=0x471aeb0) at ../src/amd/vulkan/meta/radv_meta_clear.c:325
#1 emit_clear (cmd_buffer=cmd_buffer@entry=0x471aeb0, clear_att=clear_att@entry=0x7f2268bfe140, clear_rect=clear_rect@entry=0x7f2268bfe080, pre_flush=pre_flush@entry=0x0, post_flush=post_flush@entry=0x0, view_mask=view_mask@entry=0)
at ../src/amd/vulkan/meta/radv_meta_clear.c:1780
#2 0x00007f23790ac0f6 in radv_clear_image_layer
(cmd_buffer=cmd_buffer@entry=0x471aeb0, image=image@entry=0x7f21ecf50430, image_layout=image_layout@entry=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, range=range@entry=0x7f2268bff5d0, format=format@entry=VK_FORMAT_BC3_UNORM_BLOCK, level=level@entry=0, layer_count=1, clear_val=0x7f2268bfe470) at ../src/amd/vulkan/meta/radv_meta_clear.c:2000
#3 0x00007f23790ac30c in radv_cmd_clear_image
(cmd_buffer=cmd_buffer@entry=0x471aeb0, image=image@entry=0x7f21ecf50430, image_layout=image_layout@entry=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, clear_value=clear_value@entry=0x7f2268bff690, range_count=range_count@entry=1, ranges=ranges@entry=0x7f2268bff5d0, cs=false) at ../src/amd/vulkan/meta/radv_meta_clear.c:2142
#4 0x00007f23790acd72 in radv_CmdClearColorImage (commandBuffer=0x471aeb0, image_h=0x7f21ecf50430, imageLayout=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, pColor=0x7f2268bff690, rangeCount=1, pRanges=0x7f2268bff5d0)
at ../src/amd/vulkan/meta/radv_meta_clear.c:2179
#5 0x000000000062a86c in ??? ()
#6 0x000000000062ac1e in ??? ()
#7 0x0000000000af89b3 in ??? ()
#8 0x00000000007d854d in ??? ()
#9 0x00000000005f317f in ??? ()
#10 0x00007f23a5ce31e3 in std::execute_native_thread_routine (__p=0x7f224d16aa80) at ../../../../../libstdc++-v3/src/c++11/thread.cc:104
#11 0x00007f23a5ee7897 in start_thread (arg=<optimized out>) at pthread_create.c:444
#12 0x00007f23a5f6e80c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78Can you make sure you're on the amdgpu driver and not radeonsi
leifliddy
commented
7 months ago I filed a ticket with Mesa -- it has a bit more information in it.
Like the output of inxi -GSC -xx
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10677
It's definitely using amdgpu and not radeonsi
Display: x11 server: X.Org v: 1.20.14 with: Xwayland v: 23.2.4 driver: X:
loaded: amdgpu unloaded: fbdev,modesetting,radeon,vesa dri: radeonsinvm, i see you are.
Valgrind output would be really beneficial here, I suspect a local variable might be getting freed to early though, as was the case with a similar Godot crash in 2020
leifliddy
commented
7 months ago You can find the valgrind output here: https://leifliddy.com/.steam/valgrind.log
It never got past the initial loading screen -- valgrind stopped after logging more then 10000000 errors. I might try again tomorrow and remove the error limit cutoff. \
Also, I want to try and get rid of this error:
==26083== Downloading debug info for /home/leif.liddy/programs/cemu/Cemu...
==26083== Server query failed: No such file or directoryIf I don't strip the Cemu binary (after building it) -- can it get the debug info from the binary itself?
leifliddy
commented
7 months ago Looks like I'm not the only one experiencing this issue https://www.reddit.com/r/EmuDeck/comments/x7g2lj/tekken_tag_2_through_cemu_crashes_on_character/
leifliddy
commented
7 months ago I have a better backtrace -- by using a non-stripped type=debug binary
(gdb) bt
#0 0x00007fbf0ecaba42 in emit_color_clear (view_mask=0, clear_rect=0x7fbdfdffe030, clear_att=0x7fbdfdffe0f0, cmd_buffer=0x4e72ab0) at ../src/amd/vulkan/meta/radv_meta_clear.c:325
#1 emit_clear (cmd_buffer=cmd_buffer@entry=0x4e72ab0, clear_att=clear_att@entry=0x7fbdfdffe0f0, clear_rect=clear_rect@entry=0x7fbdfdffe030, pre_flush=pre_flush@entry=0x0, post_flush=post_flush@entry=0x0, view_mask=view_mask@entry=0)
at ../src/amd/vulkan/meta/radv_meta_clear.c:1780
#2 0x00007fbf0ecac0f6 in radv_clear_image_layer
(cmd_buffer=cmd_buffer@entry=0x4e72ab0, image=image@entry=0x7fbd883fe660, image_layout=image_layout@entry=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, range=range@entry=0x7fbdfdfff5b0, format=format@entry=VK_FORMAT_BC3_UNORM_BLOCK, level=level@entry=0, layer_count=1, clear_val=0x7fbdfdffe420) at ../src/amd/vulkan/meta/radv_meta_clear.c:2000
#3 0x00007fbf0ecac30c in radv_cmd_clear_image
(cmd_buffer=cmd_buffer@entry=0x4e72ab0, image=image@entry=0x7fbd883fe660, image_layout=image_layout@entry=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, clear_value=clear_value@entry=0x7fbdfdfff680, range_count=range_count@entry=1, ranges=ranges@entry=0x7fbdfdfff5b0, cs=false) at ../src/amd/vulkan/meta/radv_meta_clear.c:2142
#4 0x00007fbf0ecacd72 in radv_CmdClearColorImage (commandBuffer=0x4e72ab0, image_h=0x7fbd883fe660, imageLayout=VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL, pColor=0x7fbdfdfff680, rangeCount=1, pRanges=0x7fbdfdfff5b0)
at ../src/amd/vulkan/meta/radv_meta_clear.c:2179
#5 0x000000000061940e in VulkanRenderer::ClearColorImageRaw (this=0x49dc310, image=0x7fbd883fe660, sliceIndex=0, mipIndex=0, color=..., inputLayout=VK_IMAGE_LAYOUT_GENERAL, outputLayout=VK_IMAGE_LAYOUT_GENERAL)
at /root/cemu/src/Cafe/HW/Latte/Renderer/Vulkan/VulkanRenderer.cpp:2807
#6 0x00000000006194cb in VulkanRenderer::ClearColorImage (this=0x49dc310, vkTexture=0x7fbd883ff080, sliceIndex=0, mipIndex=0, color=..., outputLayout=VK_IMAGE_LAYOUT_GENERAL)
at /root/cemu/src/Cafe/HW/Latte/Renderer/Vulkan/VulkanRenderer.cpp:2826
#7 0x000000000061a948 in VulkanRenderer::texture_clearColorSlice (this=0x49dc310, hostTexture=0x7fbd883ff080, sliceIndex=0, mipIndex=0, r=0.968627453, g=0.968627453, b=0, a=0)
at /root/cemu/src/Cafe/HW/Latte/Renderer/Vulkan/VulkanRenderer.cpp:3182
#8 0x0000000000ba8ca8 in LatteRenderTarget_applyTextureColorClear (texture=0x7fbd883ff080, sliceIndex=0, mipIndex=0, r=0.968627453, g=0.968627453, b=0, a=0, eventCounter=90337)
at /root/cemu/src/Cafe/HW/Latte/Core/LatteRenderTarget.cpp:753
#9 0x0000000000ba8ffb in LatteRenderTarget_itHLEClearColorDepthStencil
(clearMask=1, colorBufferMPTR=428130304, colorBufferFormat=290, colorBufferTilemode=Latte::E_HWTILEMODE::TM_2D_TILED_THIN1, colorBufferWidth=64, colorBufferHeight=64, colorBufferPitch=64, colorBufferViewFirstSlice=0, colorBufferViewNumSlice=1, depthBufferMPTR=0, depthBufferFormat=0, depthBufferTileMode=Latte::E_HWTILEMODE::TM_LINEAR_GENERAL, depthBufferWidth=0, depthBufferHeight=0, depthBufferPitch=0, depthBufferViewFirstSlice=0, depthBufferViewNumSlice=0, r=0.968627453, g=0.968627453, b=0, a=0, clearDepth=0, clearStencil=0) at /root/cemu/src/Cafe/HW/Latte/Core/LatteRenderTarget.cpp:825
#10 0x0000000000b97613 in LatteCP_itHLEClearColorDepthStencil (cmd=0x7fbd9e0cc188, nWords=23) at /root/cemu/src/Cafe/HW/Latte/Core/LatteCommandProcessor.cpp:894
#11 0x0000000000b98906 in LatteCP_ProcessRingbuffer () at /root/cemu/src/Cafe/HW/Latte/Core/LatteCommandProcessor.cpp:1588
#12 0x00000000005ca24f in Latte_ThreadEntry () at /root/cemu/src/Cafe/HW/Latte/Core/LatteThread.cpp:200
#13 0x0000000000564ddf in std::__invoke_impl<int, int (*)()> (__f=@0x7fbde916a8c8: 0x5c9fd7 <Latte_ThreadEntry()>) at /usr/include/c++/13/bits/invoke.h:61
#14 0x0000000000564d98 in std::__invoke<int (*)()> (__fn=@0x7fbde916a8c8: 0x5c9fd7 <Latte_ThreadEntry()>) at /usr/include/c++/13/bits/invoke.h:96
#15 0x0000000000564d46 in std::thread::_Invoker<std::tuple<int (*)()> >::_M_invoke<0ul> (this=0x7fbde916a8c8) at /usr/include/c++/13/bits/std_thread.h:292
#16 0x0000000000564d1c in std::thread::_Invoker<std::tuple<int (*)()> >::operator() (this=0x7fbde916a8c8) at /usr/include/c++/13/bits/std_thread.h:299
#17 0x0000000000564d00 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<int (*)()> > >::_M_run (this=0x7fbde916a8c0) at /usr/include/c++/13/bits/std_thread.h:244
#18 0x00007fbf3aee31e3 in std::execute_native_thread_routine (__p=0x7fbde916a8c0) at ../../../../../libstdc++-v3/src/c++11/thread.cc:104
#19 0x00007fbf3acac897 in start_thread (arg=<optimized out>) at pthread_create.c:444
#20 0x00007fbf3ad3380c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78Redoing the valgrind log with that debug build will get significantly better output.
leifliddy
commented
7 months ago Ok, I redid the valgrind log with the debug binary: https://leifliddy.com/.cemu/valgrind.log
I also installed the vulkan-validation-layers package and set
export VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation
That log can be found here:
https://leifliddy.com/.cemu/cemu.vulkan.validation.log
leifliddy
commented
7 months ago The Mesa guys are that saying based on the validation log I just posted -- that it looks like it's an application bug.
mbriar
commented
7 months ago FWIW, it was me that commented on the Mesa issue, but i'm no Mesa developer myself. However, this VVL error does make me think that this might be a CEMU bug:
VUID-vkCmdClearColorImage-image-00007(ERROR / SPEC): msgNum: 1066391558 - Validation Error: [ VUID-vkCmdClearColorImage-image-00007 ] Object 0: handle = 0x6b1af10, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x7ea00000007ea, name = tex_1984c000_fmt0033, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x3f8fd806 | vkCmdClearColorImage(): image (VkImage 0x7ea00000007ea[tex_1984c000_fmt0033]) was created with a compressed format (VK_FORMAT_BC3_UNORM_BLOCK). The Vulkan spec states: image must not have a compressed or depth/stencil format (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdClearColorImage-image-00007)
Objects: 2
[0] 0x6b1af10, type: 6, name: NULL
[1] 0x7ea00000007ea, type: 10, name: tex_1984c000_fmt0033Yeah, this looks like something the windows drivers just tolerate despite being a violation, many of the valgrind errors are luckily just libhid jank and some benign mutex stuff
leifliddy
commented
7 months ago I should have mentioned that I could never got passed the initial loading screen with valgrind (after running for several hours) so it never got to the point where the error occurred.
Would using less options help?
I was using
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=valgrind.log --max-stackframe=407929264 --error-limit=no ./Cemu_debug_gcc 
Exzap
commented
7 months ago No more info is needed, thanks. I will fix this when I get a chance.
Current Behavior
I compiled Cemu for Fedora 39 using my project: https://github.com/leifliddy/podman-cemu-builder
Update: this issue also occurs with the
Cemu-2.0-66-x86_64.AppImageas well.Cemu + Tekken has always worked perfectly. However, I recently changed the GPU on my system from an Nvidia RTX 3070 --> AMD RX 7900 XTX. So I believe this issue is related to the AMD card (with Cemu or Mesa) I'm just using the open source drivers from the kernel and Mesa 23.3.5
And now the game crashes (consistently and always with the same error). Which is right after selecting a character. I created a new Cemu env to test this with. So no shader caches existed....no existing game profiles, and just using the default cemu config.
**as a side note: Tekken 8 (Steam/Proton) runs perfectly on this machine
Expected Behavior
I expected the game to run and not exit with
Steps to Reproduce
Run Tekken TT2 on a F39 system with a AMD Radeon RX 7900 XTX card.
System Info (Optional)
OS: Fedora 39 GPU: AMD Radeon RX 7900 XTX (RADV NAVI31)
Emulation Settings (Optional)
No response
Logs (Optional)
Here's the full error log