search

FNA-XNA / FNA3D

FNA3D - 3D Graphics Library for FNA
http://fna-xna.github.io/
Other
272 stars 45 forks source link

FNA3D Trace Suite #72

Open thatcosmonaut opened 3 years ago

thatcosmonaut commented 3 years ago

The categories below are mostly suggestions, getting long traces is good but getting all of a game's graphical features will be most helpful. Traces should be sent privately to flibit.

To enable tracing, simply set -DTRACING_SUPPORT=ON when configuring, then traces will be dumped to FNA3D_Trace.bin. Traces technically have proprietary data in them, so only send them privately!

TODO:

Optional, ignore these unless you know what you're doing:

TheSpydog commented 3 years ago

A few non-FNA3D-related things I've encountered while going through the catalog:

Axiom Verge: Throws an exception when starting. This appears to have been introduced back in FNA 20.02. (Maybe in this commit?)

Super Bernie World: The engine calls FNAPlatform.SetPresentationInterval via reflection, which is no longer present since we moved it to FNA3D.

Flinthook: Won't boot unless you comment out the inner contents of the NLog.Retail.config file. And even then, it crashes (without an error log) after going through the first tunnel on a new profile.

Bastion:

System.InvalidOperationException: The render target must not be set on the device when it is used as a texture.
  at Microsoft.Xna.Framework.Graphics.TextureCollection.set_Item (System.Int32 index, Microsoft.Xna.Framework.Graphics.Texture value) [0x0004a] in <c6c6c3a876c6444eaffb184c105ebfc1>:0

As a result of this exception, it destroys the GraphicsDevice (which internally destroys the Vulkan device). However, it apparently tries to recover from this exception by recreating the GraphicsDevice. At which point we get a validation error and a native crash with MoltenVK:

VUID-vkCreateDevice-ppEnabledExtensionNames-01387(ERROR / SPEC): msgNum: 307460652 - Validation Error: [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x12537a2c | Missing extension required by the device extension VK_KHR_dedicated_allocation: VK_KHR_get_memory_requirements2. The Vulkan spec states: All required extensions for each extension in the VkDeviceCreateInfo::ppEnabledExtensionNames list must also be present in that list (https://vulkan.lunarg.com/doc/view/1.2.154.0/mac/1.2-extensions/vkspec.html#VUID-vkCreateDevice-ppEnabledExtensionNames-01387)

Simply Chess: The game's vertex layouts are incorrectly specified. This is purely an application issue, and it just happens to work by chance with OpenGL. When attempting to enter the gameplay scene with Vulkan, we get an assert and a handful of validation errors, which are summed up as: Vertex attribute vs_v3(3) is missing from the vertex descriptor.

TheSpydog commented 3 years ago

MoltenVK Bugs:

Chasm:

Murder Miners:

Reus:

Simply Chess:

flibitijibibo commented 3 years ago

Axiom Verge, Bastion, and all the Tribute games are all spec violations but they're also SpriteBatch+Shader games, so nothing to see there. Flotilla is also a spec violation but only regarding BloomComponent, that one just needs bloom disabled. Simply Chess has bad shaders and can also be skipped. Kitsune's games can be tested once they update FNA.

The only weird one is Owlboy, but that should be fixed with an FNA+FAudio sync. Will need debug symbols if this is not the case.

flibitijibibo commented 3 years ago

Alphabetized the list and split off the spec violations into an optional list. If you know how to work around the spec violation in your local copy, great, if not don't worry about it. Flotilla's the only scary one in the list so far but bloom is easy to disable in that game. EDIT: Patch submitted, sent spec fixes for Bastion as well. Flinthook/MercKings both have working versions in revision control but they're currently unpublished because of NLog issues (read: it sucks and it breaks things, especially Mono).

flibitijibibo commented 3 years ago

Flotilla upstream is now compliant, not sure when it will get pushed in binary form to customers but building master should work with the public content.

TheSpydog commented 3 years ago

The only weird one is Owlboy, but that should be fixed with an FNA+FAudio sync. Will need debug symbols if this is not the case.

Agh, yeah, it turns out I was just using an outdated version of FAudio. It works fine with 20.12.

flibitijibibo commented 3 years ago

fnalibs update for latest MoltenVK and FNA3D Git revision.

flibitijibibo commented 3 years ago

Looks like the latest MoltenVK is not a fan of FEZ:

[mvk-error] VK_ERROR_DEVICE_LOST: Command buffer 0x7fdb87a685c0 "" execution failed (code 1): Internal Error (IOAF code -536870211)
TheSpydog commented 3 years ago

Looks like the latest MoltenVK is not a fan of FEZ:

[mvk-error] VK_ERROR_DEVICE_LOST: Command buffer 0x7fdb87a685c0 "" execution failed (code 1): Internal Error (IOAF code -536870211)

I'm not seeing this on my machine (MBP 2016, Intel Iris Graphics 540) with the latest LunarG SDK. Is this on NVIDIA?

Also, since updating to the latest MVK I'm now seeing this at the start of every game:

VUID-VkDeviceCreateInfo-pProperties-04451(ERROR / SPEC): msgNum: 976972960 - Validation Error: [ VUID-VkDeviceCreateInfo-pProperties-04451 ] Object 0: handle = 0x7fd38344dd70, type = VK_OBJECT_TYPE_PHYSICAL_DEVICE; | MessageID = 0x3a3b6ca0 |
vkCreateDevice: VK_KHR_portability_subset must be enabled because physical device VkPhysicalDevice 0x7fd38344dd70[] supports it
The Vulkan spec states: If the [VK_KHR_portability_subset] extension is included in pProperties of vkEnumerateDeviceExtensionProperties, ppEnabledExtensions must include "VK_KHR_portability_subset". (https://vulkan.lunarg.com/doc/view/1.2.162.0/mac/1.2-extensions/vkspec.html#VUID-VkDeviceCreateInfo-pProperties-04451)

Apparently this extension must be enabled if it's supported by the physical device, even if it's unused by the application? What a strange requirement...

thatcosmonaut commented 3 years ago

Looks like this is an open issue on the Vulkan-Portability repo so we should probably wait for clarification from Khronos before patching this in.

https://github.com/KhronosGroup/Vulkan-Portability/issues/14

flibitijibibo commented 3 years ago

Yeah, I've been running on NVIDIA. Maybe the spec violation is the problem for me... I wouldn't object to including it, we don't have any reason not to as far as I know.

thatcosmonaut commented 3 years ago

I suppose it's basically a no-op on conformant implementations.

flibitijibibo commented 3 years ago

As of now, Flotilla on Steam is compliant, as are the Linux/macOS builds of Mercenary Kings and Flinthook.

TheSpydog commented 3 years ago

Ran into a spec violation in Capsized's opening video cutscene:

System.InvalidOperationException: The render target must not be set on the device when it is used as a texture.
flibitijibibo commented 3 years ago

Weird, I didn't touch the Bloom at all for that game... it does come from the 3.1 era though. It's an easy fix either way, I'll look at it alongside any other support issues that come from the update bomb.

flibitijibibo commented 3 years ago

Woops, the spec violation error was actually a false positive:

https://github.com/FNA-XNA/FNA/commit/cd17482545fab3ab7b09977fb00bc9b28f2c8e4a

thatcosmonaut commented 3 years ago

Ran a bunch of RADV tests, Flotilla complains about a buffer not being cleaned up on close but that's the only thing I've seen out of the games I own.

harpaj commented 3 years ago

Would it be possible/helpful for someone outside of the FNA dev team to help with these tests? I have a recent Nvidia GPU and a good bunch of the games in the list in my steam account, so if it helps and you point me to some instructions what to do, I would be happy to help!

thatcosmonaut commented 3 years ago

the process is currently:

  1. compile FNA.dll (xbuild FNA.sln)
  2. throw FNA.dll and FNA.dll.config into the game folder
  3. download fnalibs.tar.bz2, put the contents of the correct subdirectory into the game folder (depending on platform). on windows you might have to do some sleuthing to determine if the game is 32-bit or 64-bit
  4. run the game with /gldevice:Vulkan
  5. report results here
harpaj commented 3 years ago

Thank you! "The Adventures of Shuggy" works completely flawlessly (Ubuntu 20.04)

FNA3D Driver: Vulkan
Vulkan Device: GeForce GTX 1050 Ti
Vulkan Driver: NVIDIA 450.80.02
Vulkan Conformance: 1.2.0
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FNA3D Vulkan is still in development! You have been warned!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Using VK_PRESENT_MODE_FIFO_RELAXED_KHR!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/gateways/video.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial00.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial01.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial02.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial03.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial04.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial05.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial06.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial07.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial08.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial09.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial10.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial11.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial12.ogv does not have an XNB file! Hacking Duration property!
Video /home/johannes/.steam/debian-installation/steamapps/common/Adventures Of Shuggy/video/tutorial13.ogv does not have an XNB file! Hacking Duration property!

(the video warnings also occur in opengl). Is there anything else I should add, any other information I can provide?

flibitijibibo commented 3 years ago

That's accurate since I threw out the XNBs for those, so it looks like Shuggy is set! Thanks for checking it out.

felipe19930 commented 3 years ago

I've tried updating FEZ's libraries as described by @thatcosmonaut, but I got this upon launching the game:

* Assertion at local-propagation.c:106, condition `ins->opcode > MONO_CEE_LAST' not met

Stacktrace:

  at <unknown> <0xffffffff>
  at SDL2.SDL.SDL_RWFromFile (string,string) <0x00013>
  at SDL2.SDL.SDL_GameControllerAddMappingsFromFile (string) <0x00017>
  at Microsoft.Xna.Framework.SDL2_FNAPlatform.ProgramInit (Microsoft.Xna.Framework.LaunchParameters) <0x003ef>
  at Microsoft.Xna.Framework.FNAPlatform..cctor () <0x01483>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
  at <unknown> <0xffffffff>
  at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.get_Adapters () <0x0001b>
  at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.get_DefaultAdapter () <0x0000b>
  at FezEngine.Tools.Settings.RevertToDefaults () <0x0000f>
  at FezEngine.Tools.Settings..ctor () <0x00127>
  at FezEngine.Tools.SettingsManager.InitializeSettings () <0x0006b>
  at FezGame.Program.Main (string[]) <0x00163>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

    ./FEZ.bin.x86_64() [0x624cff]
    /usr/lib/libpthread.so.0(+0x140f0) [0x7fcc68b750f0]
    /usr/lib/libc.so.6(gsignal+0x145) [0x7fcc689d5615]
    /usr/lib/libc.so.6(abort+0x116) [0x7fcc689be862]
    ./FEZ.bin.x86_64() [0x584c89]
    ./FEZ.bin.x86_64(monoeg_g_logv+0x47) [0x584e97]
    ./FEZ.bin.x86_64(monoeg_assertion_message+0x96) [0x584fe6]
    ./FEZ.bin.x86_64() [0x5dd762]
    ./FEZ.bin.x86_64() [0x46a6b0]
    ./FEZ.bin.x86_64() [0x46adc0]
    ./FEZ.bin.x86_64() [0x46b86b]
    ./FEZ.bin.x86_64() [0x45d2ae]
    [0x4023a166]

Debug info from gdb:

ERROR: ld.so: object '/home/gui/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
/usr/bin/gdb: /home/gui/.local/share/Steam/ubuntu12_32/steam-runtime/pinned_libs_64/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /usr/lib/libdebuginfod.so.1)

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

/mnt/HDDLinux/Games/steamapps/common/FEZ/./FEZ: line 23: 10216 Aborted                 (core dumped) ./FEZ.bin.x86_64 $@

I'm on Arch Linux, NVIDIA driver 455.45.01

flibitijibibo commented 3 years ago

FEZ requires the public beta branch to run FNA3D.

TheSpydog commented 3 years ago

I'm occasionally seeing this when starting up Flinthook on Windows AMD:

UNASSIGNED-Threading-MultipleThreads(ERROR / SPEC): msgNum: 337425955 - Validation Error: [ UNASSIGNED-Threading-MultipleThreads ] Object 0: handle = 0x42d0860000000003, type = VK_OBJECT_TYPE_UNKNOWN; | MessageID = 0x141cb623 | THREADING ERROR : vkMapMemory(): object of type NON_DISPATCHABLE_HANDLE is simultaneously used in thread 0x5364 and thread 0x5df8

UNASSIGNED-Threading-MultipleThreads(ERROR / SPEC): msgNum: 337425955 - Validation Error: [ UNASSIGNED-Threading-MultipleThreads ] Object 0: handle = 0x42d0860000000003, type = VK_OBJECT_TYPE_UNKNOWN; | MessageID = 0x141cb623 | THREADING ERROR : vkUnmapMemory(): object of type NON_DISPATCHABLE_HANDLE is simultaneously used in thread 0x5df8 and thread 0x5364

Although sometimes the second error is this instead:

VUID-vkUnmapMemory-memory-00689(ERROR / SPEC): msgNum: 918320700 - Validation Error: [ VUID-vkUnmapMemory-memory-00689 ] Object 0: handle = 0x42d0860000000003, type = VK_OBJECT_TYPE_UNKNOWN; | MessageID = 0x36bc763c | Unmapping Memory without memory being mapped: VkNonDispatchableHandle 0x42d0860000000003[]. The Vulkan spec states: memory must be currently host mapped (https://vulkan.lunarg.com/doc/view/1.2.154.1/windows/1.2-extensions/vkspec.html#VUID-vkUnmapMemory-memory-00689)

thatcosmonaut commented 3 years ago

My guess is that Flinthook is doing some threaded memory set/get somewhere and we need to stick a mutex around the buffer map.

thatcosmonaut commented 3 years ago

Actually, refresh my memory - is buffer access supposed to be thread-safe in XNA or is this a spec violation?

flibitijibibo commented 3 years ago

My assumption is that it's thread-safe, but I'd be interested in knowing why a buffer was being accessed twice at the same time. I think Flinthook just uses threads for loading, I don't think it does any uploads twice at the same time. It definitely works elsewhere so we probably need a mutex here.

thatcosmonaut commented 3 years ago

It's either a buffer set or the texture staging buffer being accessed simultaneously, we should probably just put a mutex around each of those map/unmaps.

felipe19930 commented 3 years ago

Found this minor graphical issue in FEZ with the Vulkan backend only.

A little above the windmill (in the first level), a horizontal line made of yellow pixels keeps flashing every second:

FEZ

It stops flashing if I keep jumping, or if I'm holding onto the vines on the wall.

Video: https://www.youtube.com/watch?v=8NkVDxC8w68

OS: Arch Linux 64-bit GPU: NVIDIA GTX 660 (driver: 455.45.01)

harpaj commented 3 years ago

I tested a bit more, with Ubuntu 20.04, GeForce GTX 1050 Ti, NVIDIA 450.80.02: A Virus named TOM: Completely fine.

FEZ: I don’t get the FNA startup log from the other games, so I am not sure if all logs are captured. Game runs fine when windowed and fullscreen, but crashes when switching to borderless window. That happens with OpenGL as well though.

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  40 (X_TranslateCoords)
  Resource id in failed request:  0x602ce9
  Serial number of failed request:  1191
  Current serial number in output stream:  1191

There is a bit of screen tearing at times, but also that happens with OpenGL, too, and I couldn’t say whether it’s worse with Vulkan.

Also, FWIW, I can’t reproduce the yellow line above the windmill @felipe19930 reported above.

Gnomoria: Crashes on startup both with Vulkan and OpenGL. Flibit said on Discord that this is more or less expected and can be ignored.

TheSpydog commented 3 years ago

Got a whole bunch of vkMap/Unmap threading errors with Salt & Sanctuary. Hopefully should be fixed by a mutex, as mentioned above for Flinthook.

flibitijibibo commented 3 years ago

@harpaj The FEZ issue sounds like normal FEZ actually, try changing it to either pixel-perfect or supersampled instead of full aspect in the video settings. The borderless window issue would be SDL if anything, but I'd be surprised if the X11 backend had any real issues there.

felipe19930 commented 3 years ago

The yellow pixel thingy goes away too by changing the scaling mode to pixel-perfect or supersampled. Great!

Another apparent bug I found while testing FEZ: After hitting Alt+Tab, the game will crash instantly, and an error message will show up in dmesg or journalctl:

NVRM: Xid (PCI:0000:01:00): 31, pid=28460, Ch 0000003d, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_PROP_0 faulted @ 0x1_168c0000. Fault is of type FAULT_PTE ACCESS_TYPE_WRITE

I recorded a video of it crashing, not sure if it's helpful, but here it is anyway:

https://www.youtube.com/watch?v=4ZQJSDI3ogY

This crash is only reproducible with the Vulkan back-end, however. Here's a video with the OpenGL back-end, where alt-tabbing works just fine:

https://www.youtube.com/watch?v=xOZbF5zSeyA

I'm not sure if FNA itself is supposed to display an error after that, but I couldn't find anything useful in the log files after that crash. Let me know if there's a proper way to capture it.

Thanks

flibitijibibo commented 3 years ago

Woof, that error is from the driver - if a debug binary of FNA doesn't produce errors from the Vulkan validation errors (install those if you haven't already) I would file an issue with NV for sure.

felipe19930 commented 3 years ago

You know what, let me try to reproduce the crash with the non-Flatpak version of Steam first, just to be sure it's not related to Flatpak itself...

if a debug binary of FNA doesn't produce errors from the Vulkan validation errors

I do have a debug build of FNA.dll, but wouldn't I need debug binaries for fnalibs as well? If that's the case, I'll have to look on how to compile them and stuff.

flibitijibibo commented 3 years ago

Only FNA.dll has to be a debug binary, FNA3D will know to load the validation layers in that situation.

felipe19930 commented 3 years ago

So yeah, I tested with the non-Flatpak'd version of Steam, and alt-tab works as expected, no crashes whatsoever.

Plus, I got nothing useful with the debug build of FNA in the Flatpak'd Steam, so this crash can be discarded as a Flatpak-Steam bug, I guess...

So sorry!

flibitijibibo commented 3 years ago

Script to make Axiom Verge testable:

https://gist.github.com/flibitijibibo/3aff839641a0063321cb7d645749ff70

flibitijibibo commented 3 years ago

FNA3D now has tracing support! This means we can capture call streams in a backend-ambiguous manner, making mass testing a lot easier... once we have data.

To enable tracing, simply set -DTRACING_SUPPORT=ON when configuring, then traces will be dumped to FNA3D_Trace.bin. Traces technically have proprietary data in them, so only send them privately!

Once we have good traces of the catalog (we may need a new column...) I can run tests on all hardware and make sure that the renderer is in good shape no matter what we change.

flibitijibibo commented 3 years ago

I've reset the OP to be a checklist for FNA3D traces. Once we have traces of a majority of titles we'll be able to do mass testing on all possible GPU configurations with as little user input as possible.