Open thatcosmonaut opened 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:
public Color(Color color, float alpha)
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.
MoltenVK Bugs:
Chasm:
Murder Miners:
Reus:
[x] During gameplay there's a constant spew of this validation error:
VUID-VkRenderPassBeginInfo-clearValueCount-00902(ERROR / SPEC): msgNum: 1306546659 - Validation Error: [ VUID-VkRenderPassBeginInfo-clearValueCount-00902 ] Object 0: handle = 0x4d500000004d5, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x4de051e3 | In vkCmdBeginRenderPass() the VkRenderPassBeginInfo struct has a clearValueCount of 1 but there must be at least 2 entries in pClearValues array to account for the highest index attachment in VkRenderPass 0x4d500000004d5[] that uses VK_ATTACHMENT_LOAD_OP_CLEAR is 2. Note that the pClearValues array is indexed by attachment number so even if some pClearValues entries between 0 and 1 correspond to attachments that aren't cleared they will be ignored. The Vulkan spec states: clearValueCount must be greater than the largest attachment index in renderPass that specifies a loadOp (or stencilLoadOp, if the attachment has a depth/stencil format) of VK_ATTACHMENT_LOAD_OP_CLEAR (https://vulkan.lunarg.com/doc/view/1.2.154.0/mac/1.2-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-clearValueCount-00902) Objects: 1 [0] 0x4d500000004d5, type: 18, name: NULL
[x] This appears once, when first entering the gameplay scene:
VUID-vkCmdCopyBufferToImage-renderpass(ERROR / SPEC): msgNum: 70620365 - Validation Error: [ VUID-vkCmdCopyBufferToImage-renderpass ] Object 0: handle = 0x7fdca5c291e8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x43594cd | vkCmdCopyBufferToImage(): It is invalid to issue this call inside an active VkRenderPass 0x65b000000065b[]. The Vulkan spec states: This command must only be called outside of a render pass instance (https://vulkan.lunarg.com/doc/view/1.2.154.0/mac/1.2-extensions/vkspec.html#VUID-vkCmdCopyBufferToImage-renderpass) Objects: 1 [0] 0x7fdca5c291e8, type: 6, name: NULL
Simply Chess:
VUID-VkImageMemoryBarrier-newLayout-01198(ERROR / SPEC): msgNum: 947939354 - Validation Error: [ VUID-VkImageMemoryBarrier-newLayout-01198 ] Object 0: handle = 0x7fa4c26335c8, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x3880681a | vkCmdPipelineBarrier(): Image Layout cannot be transitioned to UNDEFINED or PREINITIALIZED. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define a image layout transition, newLayout must not be VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED (https://vulkan.lunarg.com/doc/view/1.2.154.0/mac/1.2-extensions/vkspec.html#VUID-VkImageMemoryBarrier-newLayout-01198)
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.
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).
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.
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.
fnalibs update for latest MoltenVK and FNA3D Git revision.
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)
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...
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
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.
I suppose it's basically a no-op on conformant implementations.
As of now, Flotilla on Steam is compliant, as are the Linux/macOS builds of Mercenary Kings and Flinthook.
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.
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.
Woops, the spec violation error was actually a false positive:
https://github.com/FNA-XNA/FNA/commit/cd17482545fab3ab7b09977fb00bc9b28f2c8e4a
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.
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!
the process is currently:
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?
That's accurate since I threw out the XNBs for those, so it looks like Shuggy is set! Thanks for checking it out.
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
FEZ requires the public beta branch to run FNA3D.
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)
My guess is that Flinthook is doing some threaded memory set/get somewhere and we need to stick a mutex around the buffer map.
Actually, refresh my memory - is buffer access supposed to be thread-safe in XNA or is this a spec violation?
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.
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.
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:
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)
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.
Got a whole bunch of vkMap/Unmap threading errors with Salt & Sanctuary. Hopefully should be fixed by a mutex, as mentioned above for Flinthook.
@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.
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
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.
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.
Only FNA.dll has to be a debug binary, FNA3D will know to load the validation layers in that situation.
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!
Script to make Axiom Verge testable:
https://gist.github.com/flibitijibibo/3aff839641a0063321cb7d645749ff70
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.
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.
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: