Bug 105775

Hi,

Can you build mesa with debug symbols and attach a backtrace?

I'll try, although I'm just a regular user ;-) 

Which exact package do I need to rebuild? I'd think it's not necessary to re-build everything, perhaps just "mesa-vulkan-drivers"?

Well, the main problem is that I don't have any GCN 1.0 cards and when I tried on Polaris it didn't crash...

You will need to clone mesa from https://cgit.freedesktop.org/mesa/mesa/ and built it. Let me know if you need help.

OK, thanks :)

I've looked into this[1] short explanation, but I have no "Make-config" file after cloning mesa.

[1] https://www.mesa3d.org/debugging.html

Is there another file I can put "-DDEBUG" to?

It might be easier to install packages with the debug symbols from your distro:

https://wiki.debian.org/HowToGetABacktrace

though I don't know offhand which debian package contains radv.

Otherwise try

CFLAGS="-O0 -g" ./autogen.sh --with-gallium-drivers= --with-dri-drivers= --with-egl-platforms=x11,drm  --enable-debug --with-vulkan-drivers=radeon

and then run the game with "set launch options" set to

VK_ICD_FILENAMES=${MESA_DIR}/src/amd/vulkan/dev_icd.json %command%

with the ${MESA_DIR} replaced by the git clone.

Thanks Bas. It seems "mesa-vulkan-drivers" has debug symbols enabled for that dbg package[1]. I'll download it then run the game and attach any log files here. If that's not enough (e.g. if radv is not present in mesa-vulkan-drivers) I'll rebuild all the packages and then redo the process.

---------------------------------------------

[1]
[code]amarildo@amarildo:~$ apt-cache search mesa | grep dbg
libglw1-mesa-dbgsym - Debug symbols for libglw1-mesa
libegl-mesa0-dbgsym - debug symbols for libegl-mesa0
libgl1-mesa-dri-dbgsym - debug symbols for libgl1-mesa-dri
libglapi-mesa-dbgsym - debug symbols for libglapi-mesa
libglx-mesa0-dbgsym - debug symbols for libglx-mesa0
libosmesa6-dbgsym - debug symbols for libosmesa6
libwayland-egl1-mesa-dbgsym - debug symbols for libwayland-egl1-mesa
mesa-opencl-icd-dbgsym - debug symbols for mesa-opencl-icd
mesa-va-drivers-dbgsym - debug symbols for mesa-va-drivers
mesa-vdpau-drivers-dbgsym - debug symbols for mesa-vdpau-drivers
mesa-vulkan-drivers-dbgsym - debug symbols for mesa-vulkan-drivers
mesa-utils-dbgsym - debug symbols for mesa-utils
mesa-utils-extra-dbgsym - debug symbols for mesa-utils-extra
[/code]

Just FYI, 

Tahiti GPU, no crash here, I did one lap of Melbourne and entered the pits and exited again.

Meanwhile, could you test with Firejail?

On Arch Linux

pacman -S firejail

On Debian/Ubuntu/Family

apt install firejail

Then edit:

/etc/firejail/steam.profile

and comment the following lines:

#seccomp
#private-dev

The game didn't start at first, I had to comment the 'seccomp' line. I'm afraid it (firejail) has something to do with the crash, but I'm not sure.

I installed "mesa-vulkan-drivers-dbgsym" and ran Steam inside gdb and firejail (via "STEAM_DEBUGGER=gdb firejail --allow-debuggers steam") but it was like I wasn't debugging it at all.

So if you may, please install and run steam within firejail to see if that causes F1 2017 to crash.

To run Steam through firejail, after commenting the necessary lines above in it's firejail profile, do:

firejail steam

Thanks

BTW, how did you do that lap? Because if you're alone, e.g. in a time-trial event, the game runs fine. It's when running a e.g. Race Weekend and coming out of the pits that the game crashes.

I did a championship lap, there were no other cars on the screen as I'm no good at the game, they were in the lap somewhere.

Firejail isn't the issue. Ran Steam outside of it.

Then I tried  compiling mesa with the above suggestion, it says "configure: error: --enable-llvm is required when building radv", and when I enable it, it says "configure: error: --enable-llvm selected but llvm-config is not found", and no such file exists.

This is so frustrating.

Gaming on Linux with Pitcairn has never been easy, and AMD's support of my card has always been lacking, delayed, and problematic. Sadly, it's times like these that make me wanna go to Windows, everything "just works there", drivers and games are actually well tested, and regular users never need to debug themselves and compile programs to test stuff.

-2 looks like out of device memory, you might have the game settings up to high, or too high resolution.

Usually I test all my games on max graphical settings, that includes X-Plane, Project Cars 2, GTA V, Far Cry 4, and so on, all on 1080p with no crashes and usually close to 60 FPS. VRAM surely runs high, so I tend to use a combination of High/Very High and Ultra settings to get constant 60 FPS on these games.

While testing F1 2017 on Linux, the game ran fine at "High" settings while driving by myself.

I also tested it with all graphical options on the lowest possible and 720p, but it still crashes.

Maybe Vulkan handles VRAM diferently? Surely the game shouldn't use 2 GB of VRAM while all graphics settings are on "Ultra Low" and 720p.
Besides, the R9 270X ran the game fine while using the amdgpu-pro driver, as per Phoronix results. So I personally don't see VRAM getting full, but I'll still try to find a way of monitoring VRAM usage and will try the game again.

The crash is in the game code so I don't think a Mesa backtrace would help. It looks like the dump file hasn't been attached properly - could you re-attach it so I can look at what call is failing?

Ah, I thought it was a RADV problem.

I'll attach a new dump bellow.

Created attachment 138415 [details]
New dmp

Thanks.

The failing call is vkEndCommandBuffer. That matches with a few other crashes we have logged on GCN 1.0 cards.

RADV devs, any ideas what might cause that to happen for 1.0 cards specifically? We've never seen it on newer cards. I doubt it would be really running out of VRAM when running on lowest settings at 720p.

Dave, are you able to reproduce it if you run the benchmark at high settings or something like that?

Created attachment 138416 [details]
dmp when starting a race

Just to chime in, when running everything on low at 1600x900 windowed, the game crashes for me too on a 270x with 4GB of VRAM, so if this dmp contains the same failing call, it sounds extremely unlikely if it's due to too little VRAM.

Yes, same call failing there too.

FYI, I can actually reproduce the crash on Polaris, I will investigate tomorrow.

Thansk for all the details.

That's a critical issue. Only SI is affected but the problem can be reproduced with recent chips and RADV_DEBUG=noibs. I have started to work on this but the fix isn't yet working.

Thanks, Samuel. Looking forward to the fix.

If there's anything I can do to speed testing, let me know.

Here's the fix https://patchwork.freedesktop.org/patch/218066/

I have tested it using RADV_DEBUG=noibs with Dawn Of War III, that seems to work.

Should be fixed with https://cgit.freedesktop.org/mesa/mesa/commit/?id=fedd0a4215bcd387525000d76b77993ca38916ae

The limitation of 4 IBs per submission is quite annoying but I will fix later on in master (don't expect any backports because this would require a new libdrm release).

Thanks!