mirror of
https://github.com/shadps4-emu/shadPS4.git
synced 2026-04-26 00:05:58 +03:00
[GH-ISSUE #978] Linux Bloodbourne Missing Geometery #296
Labels
No labels
Bloodborne
bug
contributor wanted
documentation
enhancement
frontend
good first issue
help wanted
linux
pull-request
question
release
verification progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/shadPS4#296
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mxli2025 on GitHub (Sep 18, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/978
above is what it looks like on first load
below is after running around abit quitting to mainmenu and reloading
Loading bug maybe ? as it can display it
LCD Deck
Mint 22
no mods
@gurrgur commented on GitHub (Sep 18, 2024):
I have the same issue on Arch Linux / RX6700XT / RADV. I can also confirm that on second load most of the time, the geometry data loads properly.
I did two traces in Renderdoc (first with missing meshes and second with no missing meshes) and noticed that some vs input vertex buffers and index buffers are filled with zeros only on the trace with missing meshes.
My (uneducated) theory on this is that when the game loads in new assets from disk, due to some unknown reason (perhaps sync issue like missing fence / barrier?) the meshes are only partly loaded into GPU memory. On the second load, the data is already cashed in system memory so that the upload to GPU is quick enough to complete in time. Rdoc also shows, that a compute shader acesses these buffer objects before they are passed to the VS stage (which is part of a depth pass IIRC).
Also, I'd like to add that when moving from one area to another, the geometry disappears again. For example, load into central yarnham and climb the ladder. After some steps on the ladder, the screen will turn grey for a short amount of time and after that the meshes will be gone.
@gurrgur commented on GitHub (Sep 18, 2024):
Oh and this is a RADV only issue. amdvlk has no missing meshes (though it has waaaaaaay worse perf).
And finally, sometimes it looks like some of the zero filled vertex buffers are instead filled with garbage data leading to flicker. Seems kind of random and apparently depends on timing.
@LNDF commented on GitHub (Sep 19, 2024):
Same issue. Fedora 40 using RADV.
It might be nice to see what the validation layers print out.
@mxli2025 commented on GitHub (Sep 19, 2024):
issue #976 , seems to be similar. Windows on a nVidia card.
@grassponderer commented on GitHub (Sep 23, 2024):
Same here. Arch, 6900XT using vulkan-radeon, tested on linux, linux-zen, and linux-cachyos, no difference.
When I tried amdvlk, got to the first loading screen before the area loads in, then shadps4 crashes. I don't know if it's helpful, but I noticed that I get the following error spammed repeatedly:
[Render.Vulkan] <Error> tile_manager.cpp:TryDetile:391: Unsupported tiled image: R32Sfloat (Depth_MacroTiled)Don't have enough background as to whether or not this might point to the cause of the issue though.
@Hermiten commented on GitHub (Oct 1, 2024):
Can you test with the last update ?
This commit https://github.com/shadps4-emu/shadPS4/pull/1146 can maybe fix somethings
@R1chterScale commented on GitHub (Oct 2, 2024):
No dice
@HermitsA commented on GitHub (Oct 6, 2024):
As a compromise, using the amdgpu-pro drivers fix this. You can have both the mesa and proprietary drivers on the same machine, defaulting to mesa normally, and enabled by using "progl [command]". You can also try the amdvlk drivers, altough performance was horrible last time i tested.
Tested on the 3 different vulkan implementations (RADV, AMDVLK, VULKAN-AMDGPU-PRO) on a 6700xt with archlinux
@Mast3rwaf1z commented on GitHub (Nov 6, 2024):
I have the same issues, amdgpu-pro works, but the game stutters, i just tried running through nightmare of mensis with radv, no textures but the game is much more smooth with RADV.
@grassponderer commented on GitHub (Nov 17, 2024):
Just a quick update, now it seems to work for me using this
https://github.com/ngoquang2708/shadPS4/actions/runs/11869943285
and AMDVLK. Seems to be related to #1193 since when using amdvlk these error don't get spammed.
@Malumen commented on GitHub (Nov 24, 2024):
how do we enable AMDvlk?
@grassponderer commented on GitHub (Nov 26, 2024):
Assuming you use arch, the safest way without messing up everything else that uses vulkan-radeon is probably https://github.com/Frogging-Family/amdvlk-opt
@Channeira commented on GitHub (Nov 26, 2024):
Did someone report the RADV specific issues to mesa already?
@dunestorm333 commented on GitHub (Nov 30, 2024):
Can confirm, this is still a problem on the latest shadPS4 build :(
Running Fedora 41 (Linux 6.11.10-300.fc41.x86_64)
Mesa 24.2.7
AMD 6800XT
@Mershl commented on GitHub (Dec 11, 2024):
RADV users please give this build a test run https://github.com/diegolix29/shadPS4/actions/runs/12286290681
played through the intro + half of yharnam on an 7900XTX using RADV without seeing the issue, this is the first build I've tested that does not show the issue.
@dunestorm333 commented on GitHub (Dec 11, 2024):
You are my hero!
This build appears to have solved this issue for me:
@raphaelthegreat commented on GitHub (Dec 11, 2024):
Issues on the main repo should be about main branch only, please test that
@Missake212 commented on GitHub (Dec 22, 2024):
Does this still happen on latest main ?
@R1chterScale commented on GitHub (Dec 22, 2024):
No, seems good now, might be interesting to bisect the change to report to the Mesa devs
@rharish101 commented on GitHub (Dec 22, 2024):
Can confirm that it's fixed for me on RADV (on a 7900 XTX), although I only tested this in Iosefka's clinic.