While the D3D11 renderer works on most hardware, there are a number of cases where D3D11 calls fail (unsupported surface formats, compile failures, things like that) where an HRESULT value should be returned. We do check this in a few places, but it's not nearly as thorough as it should be.

The short version is that we need to go to every ID3D11Device_, ID3D11DeviceContext_, and IDXGISwapChain_ call and assign it to an HRESULT res variable. For convenience, I've added two macros for error checking:

https://github.com/FNA-XNA/FNA3D/blob/master/src/FNA3D_Driver_D3D11.c#L60-L70

Examples of both are already present in the renderer.

An example warning:

D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 0 is still bound on input! [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]
D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets[AndUnorderedAccessViews]: Forcing PS shader resource slot 1 to NULL. [ STATE_SETTING WARNING #7: DEVICE_PSSETSHADERRESOURCES_HAZARD]

Basically what happens is, Textures[1] might be set to a RenderTarget, then an app might do:

GraphicsDevice.SetRenderTarget(thatTexture);

// Then later, but before a draw...
GraphicsDevice.Textures[1] = null; /* AKA: Not thatTexture anymore */

Even though the state will be valid by the time it Draws, you'll still get a warning from D3D. We just need to do the opposite of what our RestoreTargetTextures does here.

Part of FNA3D's rendering system is a faux-backbuffer, which allows for rendering at a given resolution and then blitting it to the window surface which is a different size. This is important for SDL_WINDOW_FULLSCREEN_DESKTOP in particular.

However, this isn't necessary if the sizes are the same. OpenGL only allocates an intermediate buffer when necessary, and as it turns out this can help performance for really high resolutions like 4K and above. Doing a 4K blit every frame can be expensive, particularly for lower-end hardware.

D3D11 and Vulkan don't do this as far as I can tell, yet both allow this to work; we can just set the swapchain image as the render target instead of the intermediate buffer. Doing this will save a LOT of memory and improve overall performance. OpenGLRenderer can probably be copied aggressively for both renderers.

hi, is there any chance of a basic example in C using fna3d straight up in an sdl2 app?

thank you

Certain operations cause the image layout tracking to get out of whack, particularly having to do with mip levels. We'll need some slightly more advanced state tracking on textures to make sure that the subresources have correct memory barriers - each layer and mip level can be in a different layout, so our resource tracking should be able to keep track of that.

After #174 is done, both memory and command buffer management will be isolated from the Vulkan renderer - one nice side effect of this is that most of the defrag work now sits in driver implementations of the managers and not the renderer. With this in mind, we can move the defrag logic to a standalone framework that the memory/commandbuffer managers can interact with, making the defrag work almost entirely automatic from a renderer's point of view.

Once this is done, we will probably just want to combine Memory/CommandBuffer/Defragmenter into a unified helper called FNA3D_GPUManager or something.

This one is easier than it sounds: RGB10A2 is already supported for render targets, so I just need to add logic to support it for DXGI and Vulkan window surfaces. I finally got HDR10 working in my lab so I can properly test this myself now.

• DXGI swapchain
• Vulkan RGB10A2_UNORM, check for ST2084 colorspace

Just making a reminder for myself... expected release date is mid-November I think.

FNA3D_SwapBuffers has a parameter for a window handle...

https://github.com/FNA-XNA/FNA3D/blob/master/include/FNA3D.h#L532

... but even though it dates all the way back to the original IGLDevice, it doesn't actually do much other than validate.

Like much of what FNA3D supports and doesn't support, it roots back to OpenGL. You can hypothetically have a shared context and blit a faux-backbuffer to multiple window surfaces, but it's a whole lot of MakeCurrent calls and, assuming it worked (it absolutely would not), would be horrifically slow. So I included the parameter to be complete but in reality it doesn't do anything.

We have Vulkan and Direct3D11 now, and both can absolutely do this with no problems. The important detail is how we support it. The easiest way is via the following:

• The D3D11/Vulkan device structure stores a variable-length swapchain list, instead of just a single window/swapchain pair
• Store the swapchain in the window via SDL_SetWindowData
• In CreateDevice/ResetBackbuffer/SwapBuffers, look up the overrideWindowHandle's swapchain data and create if it's a new window. Blit the faux-backbuffer to the correct swapchain and present

Vulkan unconditionally has a faux-backbuffer for various reasons, D3D11's is optional but it wouldn't be hard to unconditionally have one the moment it sees two or more windows. We will need to specify that the BackBufferWidth/Height values in PresentationParameters should be set to the maximum size needed across all windows, because as long as you do that you can use the src/dest parameters of SwapBuffers to ensure you're rendering the correct size for each swapchain. I'm hesitant to take the SwapchainRenderTarget idea from MonoGame because it would mean exposing that whole component of the renderer, which leaves OpenGL a little too far behind the other renderers. Plus, once you have a single device for multiple windows the device "backbuffer" basically becomes that target anyway...

This is a pretty high priority because developers need this for their editors; the GameMaker team have expressed interest in this (and have been giving this a try over here) and I've received requests for this from other studios as well.

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:

• A Virus Named TOM, First world including cutscenes
• The Adventures of Shuggy, Any%
• Apotheon, Any%
• Axiom Verge (randomizer branch), Any%
• Before the Echo, Any%
• Bleed, Any difficulty
• Bleed 2, Any difficulty
• Blueberry Garden, Beat the game
• Capsized, Any difficulty
• Celeste, All chapters
• Charlie Murder, Any% (maybe less...)
• Chasm, 30 minutes
• CometStriker DX, 5 straight days of the stress tester (seriously)
• Cryptark, Arcade
• The Dishwasher: Vampire Smile, Any difficulty
• Dust: An Elysian Tail, Any%
• Escape Goat 1, Any%
• Escape Goat 2, Any% + A stained glass level
• FEZ, 209.4%
• Fist Puncher, Any difficulty
• Flinthook, Finish a run
• Flotilla, Complete a skirmish
• Full Metal Furies, First chapter
• Gateways, Any%
• Gnomoria, 15 minutes
• Growing Pains, Any%
• Hacknet, Any%
• Hidden in Plain Sight, All games
• Little Racers STREET, Daily challenge
• Mercenary Kings, Complete a mission
• Murder Miners, Full multiplayer match
• Owlboy, Any%
• Planetfriend, 15 minutes
• QuadCow Art Book, All exhibits
• Reus, All tutorials + First sim
• Rex Rocket, Any%
• River City Ransom: Underground, Any%
• Rogue Legacy, Any% with as many visual attributes as possible
• Salt and Sanctuary, Any%
• Skulls of the Shogun, World 1
• Solaroids, Any%
• Soulcaster 1/2, Beat either game
• SpeedRunners, Complete a run
• Star-Twine, Play a game
• Steel Assault, Beat the game
• Streets of Rage 4, Any difficulty
• SUMICO, Complete first section
• Super Hexagon, complete a stage
• TMNT, Any%
• TowerFall Ascension, Co-op through first boss
• Unexplored, Complete a dungeon
• Wizorb, Complete Chapter 1
• Wyv and Keep, Any%

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

• Bastion (Bloom/Color violation), All levels
• Simply Chess (Bad attribs), Complete a match

FNA now supports many renderers, more than 3 times what FNA supported just two years ago. Additionally, the renderers we support are far more complex and require a lot of testing to ensure high accuracy, stability, and performance. With this in mind, we need to start working on adding functionality that dramatically simplifies mass testing of new features and renderers.

The first step is to add a tracing tool to FNA3D. In short: We need a system that, when enabled, captures all incoming FNA3D calls (and their associated data) and writes it to a file that can be played back with a simple program. The API used when capturing should not matter, and when playing the file back you should be able to use any backend that FNA3D currently supports. The one exception to this rule would be any trace that uses the SysRenderer APIs, as that requires data outside FNA3D's own scope.

Once this is done, we can simply do captures of our whole catalog, and as long as the ABI doesn't break we can very easily test new renderers locally while also integrating the catalog into a GitHub Action that plays everything back against a bunch of reference devices (WARP, llvmpipe GL/VK, etc.) to trivially catch regressions regarding accuracy and stability. Performance is a bit tougher to test, but that can be checked out after we have a good testing system in place for the basic stuff.

We encountered a situation where FNA is behaving differently on macOS compared to XNA/FNA on Windows or FNA on Linux. In our game Hybrid Beasts, the rendered terrain is composed of tiled textures whose color is updated from an internal datastructure colors and then rendered into a RenderTarget2D named renderTarget using an intermediate (re-used) texture tempTileTexture. The renderTarget of all tiles is then drawn to show the current level.

The issue can be reproduced on macOS simply by starting into the first level of the free demo of Hybrid Beasts .

The code for one tile looks like this:

// Copy colors from color-array into tile texture for a specific tile`
public void RefreshTexture()`
{
   AresGame.Ares.GetGraphicsDevice().Textures[0] = null; // Prelim: Why is this needed

   // Write changed colors to temp texture
   tempTileTexture.SetData<Color>(colors);

   // Set renderer to tile rendertarget
   AresGame.Ares.GetGraphicsDevice().SetRenderTarget(renderTarget);

   // Clear
   AresGame.Ares.GetGraphicsDevice().Clear(Color.Transparent);

   // Create updated (mipmapped) rendertarget by drawing tempTileTexture into it
   DrawEngine.spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.AlphaBlend);
   DrawEngine.spriteBatch.Draw(tempTileTexture, Vector2Constants.Zero, Color.White);
   DrawEngine.spriteBatch.End();
}

Here is how the result looks on macOS:
Only tiles with (even tiny) fragments of terrain in it are drawn, all others are transparent. However, here these tiles all show the same texture (maybe the lower right / last created tiles).

Here is how a similar scene looks on Windows:
Here all tiles show the correct representation of the internal terrain data.

Same as FAudio...

FNA-XNA/FAudio@0288084

... but with all the wacky defines we know and love from FNA3D:

FNA3D_DRIVER_OPENGL;MOJOSHADER_NO_VERSION_INCLUDE;MOJOSHADER_USE_SDL_STDLIB;MOJOSHADER_EFFECT_SUPPORT;MOJOSHADER_DEPTH_CLIPPING;MOJOSHADER_FLIP_RENDERTARGET;MOJOSHADER_XNA4_VERTEX_TEXTURES;SUPPORT_PROFILE_ARB1=0;SUPPORT_PROFILE_ARB1_NV=0;SUPPORT_PROFILE_BYTECODE=0;SUPPORT_PROFILE_D3D=0;SUPPORT_PROFILE_METAL=0;SUPPORT_PROFILE_HLSL=0;

(Assigning to Spydog but technically Eden is looking at this)

Current API PR: libsdl-org/SDL#9312

New versions dropped yesterday:

https://github.com/nothings/stb

stb_image is pretty straightforward, stb_image_write less so because we added defines to trim down the build size. It's pretty much entirely defs with no real code changes, so it shouldn't be too painful to merge? I hope?

ES3 was, for a long time, the only choice for a lot of places:

• Xbox
• Switch
• Stadia
• iOS/tvOS
• Emscripten
• FNADroid

Nowadays, thanks to FNA3D, it now looks like this...

• Xbox D3D11 (UWP), GLon12 (GDK)
• Switch Vulkan
• Stadia Vulkan
• iOS/tvOS MoltenVK
• Emscripten
• FNADroid Never supported, even then would be Vulkan-only

We're so close to making ES3 unnecessary, sadly Emscripten is completely screwed thanks to WebGPU. But, that doesn't mean we necessarily have to keep all of ES3, we could hypothetically just restrict it to WebGL2 use instead.

The checklist:

• Vulkan by default
• Remove FORCE_ES3 environment variable
• Rename useES3 to webGL, update SDL_GetPlatform checks
• See what WebGL2 looks like, maybe we can strip down the useES3 paths

If somebody makes a WebGPU-based ICD for Vulkan we can just strip all the ES3 code out.

Originally reported by QuarkRobot: DXGI, for whatever reason, secretly inserts keyboard shortcuts which interfere with our window/event systems in FNA:

https://stackoverflow.com/questions/2353178/disable-alt-enter-in-a-direct3d-directx-application

Most XNA/FNA developers write these shortcuts in themselves and it's not done for any other renderer, so let's turn this junk off.

The compression ratio of traces is usually really low (sometimes less than 1%...?!) so we should probably just skip the manual compression step and do this at runtime.

We already have miniz in the repo, so maybe we can just use that? Since the ratio is so low we can prioritize performance and it will still almost certainly be super tiny compared to the uncompressed trace.

• Compress in FNA3D_Tracing.c
• Decompress in replay.c

Here is the project as requested by @flibitijibibo at FNA-XNA/FNA#328 relating to scaling to full screen not working properly.

Project Files : Google Drive

While MSDN says that ID3D11DeviceContext::ClearDepthStencilView clamps the clear depth to the range of 0-1, it doesn't appear to actually do that. On my machine if you set the clear depth to -1 it just doesn't clear the depth buffer at all (or it sets it to 1, it's hard to tell which in renderdoc).

Naturally the code passing a depth of -1 is the broken code, but in classic OpenGL FNA this does what you'd expect it to (the depth value is clamped) and in D3D11 FNA3D it is busted. I think it's worth just clamping the input to the clear API, either in FNA or FNA3D.

Now that we don't have to make ourselves miserable with C# interop, this is now a lot more realistic! First up is making an HLSL emitter for MojoShader, followed by the driver. FNA3D's API is supposed to map extremely close to D3D11, but target/vertex bindings will be a little bit fussy anyway. Pipeline state objects should work similarly to MetalRenderer, I don't think we'll expose anything like an FNA3D_PSO*.

D3D11 Programming Guide

In commit 71073a3, support for the WARP software rasterizer was added to the D3D11 backend. However, the implementation used was severly flawed. See the following snippet from D3D11_PrepareWindowAttributes:

	const uint32_t driverType = SDL_GetHintBoolean("FNA3D_D3D11_USE_WARP", SDL_FALSE)
		? D3D_DRIVER_TYPE_HARDWARE
		: D3D_DRIVER_TYPE_WARP;

This ternary is flipped; it uses WARP rendering when FNA3D_D3D11_USE_WARP is false (the default), and uses hardware rendering if it is true - the exact opposite logic of what is intended (a similar ternary also is in D3D11_CreateDevice).

This is a fairly urgent matter as it causes severe performance drops by default on all Windows systems. However, as far as I know this commit is not included in any releases yet, which means that it can be corrected before this bug affects people in the wild (at least going of the latest version commit).

The foundation has been laid out already, largely down to fixes outside of FNA3D.

DXVK:

• Joshua-Ashton/dxvk-native#14

Shaders (only need one):

• icculus/mojoshader#56
• Wait for vkd3d-shader to be feature-complete, then use d3dcompiler-native

Win32 API (Optional):

• FormatMessage equivalent for HRESULT error strings
• ID3DUserDefinedAnnotation_SetMarker need MultiByteToWideChar? SDL_iconv?

Vulkan-headers has the possibility to be unbundled (building 'just works' if it's installed to the system and not in the srcdir), would it be possible for just the headers and libmojoshader.so to be used at buildtime, or does it need to bundle the whole repo too? I just get

  Cannot find source file:

    MojoShader/mojoshader.c

( if you're curious, I'm packaging FNA and its deps for gentoo, and it's nicer for us to have everything unbundled )

Just recording this here:
If you perform uploads to mips of a compressed texture where the base level's size is just so, some of the mips will have sizes that are not multiples of 4, which will produce validator errors from inside FNA3D. From what I can tell, the D3D11 backend internally rounds the width/height up to a multiple of 4 to fix this. I tried doing the same in the Vulkan driver myself but I got new and more exciting validator errors when doing so.

VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (43) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (86) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (21) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (10) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01736(ERROR / SPEC): msgNum: 1409501487 - Validation Error: [ VUID-VkBufferImageCopy-None-01736 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5403492f | vkCmdCopyBufferToImage(): pRegion[0] bufferImageHeight (5) must be a multiple of the compressed image's texel height (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferImageHeight must be a multiple of the compressed texel block height (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01736)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (5) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01736(ERROR / SPEC): msgNum: 1409501487 - Validation Error: [ VUID-VkBufferImageCopy-None-01736 ] Object 0: handle = 0x129e7d0000001ea6, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5403492f | vkCmdCopyBufferToImage(): pRegion[0] bufferImageHeight (10) must be a multiple of the compressed image's texel height (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferImageHeight must be a multiple of the compressed texel block height (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01736)
    Objects: 1
        [0] 0x129e7d0000001ea6, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (42) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01736(ERROR / SPEC): msgNum: 1409501487 - Validation Error: [ VUID-VkBufferImageCopy-None-01736 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5403492f | vkCmdCopyBufferToImage(): pRegion[0] bufferImageHeight (82) must be a multiple of the compressed image's texel height (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferImageHeight must be a multiple of the compressed texel block height (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01736)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (10) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (21) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01736(ERROR / SPEC): msgNum: 1409501487 - Validation Error: [ VUID-VkBufferImageCopy-None-01736 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5403492f | vkCmdCopyBufferToImage(): pRegion[0] bufferImageHeight (41) must be a multiple of the compressed image's texel height (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferImageHeight must be a multiple of the compressed texel block height (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01736)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (170) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (85) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01736(ERROR / SPEC): msgNum: 1409501487 - Validation Error: [ VUID-VkBufferImageCopy-None-01736 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5403492f | vkCmdCopyBufferToImage(): pRegion[0] bufferImageHeight (5) must be a multiple of the compressed image's texel height (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferImageHeight must be a multiple of the compressed texel block height (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01736)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01735(ERROR / SPEC): msgNum: -191671466 - Validation Error: [ VUID-VkBufferImageCopy-None-01735 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xf4935356 | vkCmdCopyBufferToImage(): pRegion[0] bufferRowLength (5) must be a multiple of the compressed image's texel width (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferRowLength must be a multiple of the compressed texel block width (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01735)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-None-01736(ERROR / SPEC): msgNum: 1409501487 - Validation Error: [ VUID-VkBufferImageCopy-None-01736 ] Object 0: handle = 0x768fda0000001eb5, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x5403492f | vkCmdCopyBufferToImage(): pRegion[0] bufferImageHeight (10) must be a multiple of the compressed image's texel height (4).. The Vulkan spec states: If the calling command's VkImage parameter is a compressed image, or a single-plane, "_422" image format, bufferImageHeight must be a multiple of the compressed texel block height (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-None-01736)
    Objects: 1
        [0] 0x768fda0000001eb5, type: 10, name: NULL
VUID-VkBufferImageCopy-bufferOffset-00194(ERROR / SPEC): msgNum: -934325023 - Validation Error: [ VUID-VkBufferImageCopy-bufferOffset-00194 ] Object 0: handle = 0xda655600000011e4, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xc84f54e1 | vkCmdCopyImageToBuffer(): pRegion[0] bufferOffset 0x90e62 must be a multiple of 4. The Vulkan spec states: bufferOffset must be a multiple of 4 (https://vulkan.lunarg.com/doc/view/1.2.141.0/windows/1.2-extensions/vkspec.html#VUID-VkBufferImageCopy-bufferOffset-00194)
    Objects: 1
        [0] 0xda655600000011e4, type: 10, name: NULL

In this case I'm calling SetData without passing a Rect, so everything on my end is default. A 196x196 DXT texture is sufficient to repro this, because its level 1 has a size that isn't a multiple of 4. All the data is there, so the driver seems to be happy to round the size up for us and the upload is successful.

Tested for merging into Wine Mono, but this most likely affects Wine generally. I used One Finger Death Punch to test.

Excerpt of terminal output:

01ac:fixme:d3d11:d3d11_device_CheckFormatSupport iface 02BBD018, format 28, format_support 0060E404 partial-stub!

Unhandled Exception:
Microsoft.Xna.Framework.Graphics.NoSuitableGraphicsDeviceException: Unsupported backbuffer DXGI format
  at Microsoft.Xna.Framework.Graphics.GraphicsDevice..ctor (Microsoft.Xna.Framework.Graphics.GraphicsAdapter adapter, Microsoft.Xna.Framework.Graphics.GraphicsProfile graphicsProfile, Microsoft.Xna.Framework
.Graphics.PresentationParameters presentationParameters) [0x000e8] in <4f068e9dcd4d43d0a8fa447441bae910>:0 
  at Microsoft.Xna.Framework.GraphicsDeviceManager.Microsoft.Xna.Framework.IGraphicsDeviceManager.CreateDevice () [0x000db] in <4f068e9dcd4d43d0a8fa447441bae910>:0 
  at Microsoft.Xna.Framework.Game.DoInitialize () [0x00031] in <4f068e9dcd4d43d0a8fa447441bae910>:0 
  at Microsoft.Xna.Framework.Game.Run () [0x00011] in <4f068e9dcd4d43d0a8fa447441bae910>:0 
  at One_Finger_Death_Punch.Program.Main (System.String[] args) [0x00008] in <3ace895f2277420d87519d83d7f08e21>:0 

So it's probably something with Wine's CheckFormatSupport stub.

Please update the embedded MojoShader to the latest code, to roll in a build fix I pushed upstream to fix building the embedded MojoShader on *BSD OS's.

Probably also need to update the iOS/tvOS docs to include MoltenVK.

This will be useful to have while we figure out the NativeAOT thunk stuff.

I discovered a bug in working on an FNA game on macOS. Switching from windowed mode to full screen would cause everything to render incorrectly (specifically blown up and cropped), but only on macs that have a retina / high DPI display. The bug only occurs when switching from windowed to full screen; starting in full screen mode works correctly, but switching out of full screen and back into it again triggers the bug.

I did some digging and found that the issue stems from FNA/src/Graphics/GraphicsDevice.cs where it calls FNA3D_ResetBackbuffer, followed by setting a new viewport on GraphicsDevice's Viewport property which in turn calls FNA3D_SetViewport. Since this is macOS and it's using OpenGL as the renderer, these call into OPENGL_ResetBackbuffer and OPENGL_SetViewport.

While I'm not sure exactly where, FNA3D_ResetBackbuffer causes the GL viewport to become incorrect when switching to full screen. (It happens somewhere in the logic of OPENGL_INTERNAL_CreateBackbuffer.) And OPENGL_SetViewport doesn't reset the viewport because the renderer's internally stored values for the viewport dimensions hasn't changed, and therefore the if statement on line 1720 of FNA3D_Driver_OpenGL.c fails and it doesn't end up calling renderer->glViewport.

The solution appears to be something like having OPENGL_INTERNAL_CreateBackbuffer appropriately update the renderer's viewport member, at which point OPENGL_SetViewport will update it to the correct viewport, or fixing OPENGL_INTERNAL_CreateBackbuffer so that it doesn't end up changing the viewport. I'm not going to say which because I'm not intimately familiar with this code!

In the meantime, I've found a somewhat silly workaround, which is changing line 686 of GraphicsDevice.cs to:

			// Now, update the viewport
			Viewport = new Viewport(
				0,
				0,
				PresentationParameters.BackBufferWidth+1,
				PresentationParameters.BackBufferHeight
			);
			Viewport = new Viewport(
				0,
				0,
				PresentationParameters.BackBufferWidth,
				PresentationParameters.BackBufferHeight
			);

...which forces it to recalculate the viewport apparently without any other ill effects. So far I haven't tested this on other platforms that use OpenGL.

Required:

• Windows (MSVC)
• Windows (MinGW)
• Linux (can just be ubuntu-latest)
• macOS CMake (TODO: macOS Xcode)
• iOS/tvOS

Optional:

• FreeBSD (take from SDL)

This is something for pretty much everybody: Myself, @TheSpydog, @thatcosmonaut, @bartwe.

We're run into an issue with our pipeline cache where the following can happen:

effect = Content.Load<Effect>("effect");
// Draw...
effect.Dispose();
effect = Content.Load<Effect>("effect");
// Draw, crash!

The reason for this is a reallocation bug: The effect gets freed, then a new one is allocated at exactly the same address as the old effect. Sometimes you get lucky and the pipeline objects work out, most of the time it's a fatal API-level use-after-free. Basically any cache that uses the following types...

• MOJOSHADER_vkShader
• MOJOSHADER_mtlShader
• MOJOSHADER_d3d11Shader

... are either no longer allowed to be part of the cache, or the caches have to be changed in a way that the following can happen:

void RENDERER_AddDisposeEffect(FNA3D_Device *driverdata, FNA3D_Effect *effect)
{
    /* The usual stuff, but then... */
    for (shader in effectdata->large_objects, effectdata->small_objects)
    {
        for (entry in cache)
        {
            if (entry.shader == shader)
            {
                CACHE_Delete(entry);
            }
        }
    }
}

So it'd pretty much be moving the caches to linked lists, which would kind of suck but would mean we aren't just growing the cache infinitely with data that's no longer valid.

• The three non-YUV SetData functions basically do the same thing, we can rewrite them to call an internal function to reduce code duplication.
• There is no reason we need to flush on each upload, we can pack in a bunch of textures until we fill the staging buffer and only flush the texture copy commands if we need to resize the buffer. This would probably reduce loading times.

When running FNA 21.01 (notable difference being the introduction to FNA3D), calls to DrawUserPrimitives crashes via FNA3D with:

System.InvalidOperationException: 'Could not compile input layout! Error Code: The parameter is incorrect. (0x80070057)'

Attached are two simple repros, one is running 20.05, which renders correctly, and one is running 21.01, which seems to crash with the above mentioned error.

The error occurs when VertexPositionTexture is used with a Texture2D. It works when VertexPositionColor is used (DrawCube, in the example, vs. DrawTexturedCube)

humans-20.05.zip
humans-21.01.zip

The SPIR-V emitter for MojoShader is already done, so we just need to write the driver. It's possible that the emitter may need some modifications for uniform/attribute linking, but the bulk of the work was already done for ARB_gl_spirv support.

Some useful links:

• Vulkan Website
• Vulkan 1.0 Specification
• Vulkan 1.0 Quick Reference
• Vulkan Examples

Alpha:

• Finish checklist in cosmonaut's tracker
• Clean up any remaining validation errors in otherwise working tests
• Clean up and squash/merge mojoshader_vulkan
• Clean up and squash/merge initial VulkanRenderer

Beta:

• Threading support
• Proper memory allocator
• Proper SPIR-V module linker for vertexOutput -> pixelInput, PointCoord support
  • glspirv
  • spirv
• Verify MoltenVK support
  • KhronosGroup/MoltenVK#933
  • KhronosGroup/MoltenVK#969
  • Regression, Intel-specific: KhronosGroup/MoltenVK#1205
• Verify Switch support
• Verify Stadia support
  • VK_GGP_frame_token integration

Release Candidate:

• Multithreaded Vulkan commands
• Device check in PrepareWindowAttributes
• Render pass clear optimization
• Resolve all FIXMEs
• Verify performance
  • Compare memory usage with OpenGL
  • Compare with NVIDIA OpenGL
  • Compare with Mesa radeonsi
  • Compare with ANGLE Vulkan
  • Compare with Metal on iOS

Vulkan By Default:

• Defragmenter
• Verify accuracy
  • Full retest of catalog

Pretty sure this is b1c55d7 acting up - basically all you need to do is run a game with Vulkan and inspect a RenderDoc capture; FEZ in particular showed an alarming number of render passes and our barrier system ending render passes appears to be the culprit. We'll probably need to revert this commit and instead add another check to ensure that there's a reason for the barrier (not just the layout, but memory activity as well).

I have a shader which runs correctly under the OpenGL backend, but not under the D3D11 backend with the symptom being a boolean in the uniform buffer appeared to have the wrong value (this was verifed by setting some colours in various branches of the shader).

I have run it against a version of FNA3D.dll with debug in it, and verified:

1. That the output hlsl looks sane.
2. The boolean values are being correctly picked up and set in mojoshader_d3d11.dll | update_uniform_buffer

I then ran it against renderdoc which showed:

that it believed not enough bytes had been provided. (uniforms_bool[4] should be true)

So the problem appears to be that each boolean variable is expecting to be found every 16 bytes :/

So I made, hacky, changes to my local version:

1. Setting the size to 16 in MOJOSHADER_d3d11CompileShader for MOJOSHADER_UNIFORM_BOOL instead of 1.
2. In update_uniform_buffer I had it set the size for MOJOSHADER_UNIFORM_BOOL to 16, and point src at a uint32[4] array with the low int being populated with the boolean uint8 value.

This fixes the problem, as can be seen in the renderdoc screenshot.

uniforms_bool[4] is now true and the shader appears to be working.

I'm hoping the DirectX experts out there :) might be in a position to understand if this diagnosis is correct and the best way of resolving it. I know it's likely a mojoshader issue, however my understanding is that the hlsl implementation originated with this project so this would be the best place to start a discussion on it.

FNA3D uses the SDL_Vulkan_GetDrawableSize to get the physical retina resolution, however that function has a pre-requisite before it will return the correct information. The view has to be created first, otherwise the function punts and just returns the logical viewport dimensions. See explanation in this SDL issue: libsdl-org/SDL#3980

Here is the relevant explanation:

It just happened to incidentally work on macOS+OpenGL because of a quirk in the implementation of OpenGL window surfaces on macOS. But getting the size of a metal or opengl or vulkan drawable surface doesn't make logical sense until the drawable surface is created. The current behaviour of SDL_GL_GetDrawableSize and SDL_Metal_GetDrawableSize on iOS reflects that fact – ie it doesn't return the size of the GL or Metal drawable before creating one, because there is no GL or Metal drawable to query the size of.

I would actually prefer to have those functions return an error in those situations, but the GetDrawable function signatures don't allow that right now.

It sounds like this should be generally corrected for all FNA3D drivers.

The effects of this issue are an incorrectly sized display on iOS devices and ugly low-resolution graphics. This is specifically affecting iOS, but likely would affect any HighDPI supported Vulkan platform.

As discussed on discord I have a few different calls to GraphicsDevice.DrawUserIndexedPrimitives() that throw

System.Runtime.InteropServices.SEHException: 'External component has thrown an exception.'

Enabling native debugging gives us this additional information:

D3D11 CORRUPTION: ID3D11Device::CreateInputLayout: Semantic name cannot be NULL (or pointer is corrupt). Declaration entry [1]. [ MISCELLANEOUS CORRUPTION #13: CORRUPTED_PARAMETER1]
Exception thrown at 0x751143D2 (KernelBase.dll) in jsmarsSamples.exe: 0x0000087D (parameters: 0x00000000, 0x00EFAF94, 0x00EFA3CC).
Exception thrown: 'System.Runtime.InteropServices.SEHException' in FNA.dll

This happens while using custom effects, but also for BasicEffect and the stock VertexPositionColorTexture, hopefully they are at least caused by the same thing.

For the basic effect I've narrowed it down to the following lines:

effect.EnableDefaultLighting();
effect.TextureEnabled = true;

Skipping the last one changes the exception to:

System.InvalidOperationException: 'Could not compile input layout! Error Code: 80070057'

I've attached a sample project that throws the exception.
SemanticCrash.zip

Running the latest DLL, FNA3D crashes with the following message on graphics device creation (in D3D11 mode):

Exception thrown: read access violation.
output was nullptr.

Using a debug version of the DLL, Visual Studio is pointing to the following:
FNA3D.dll!D3D11_PLATFORM_CreateSwapChain(D3D11Renderer * renderer, FNA3D_PresentationParameters * pp) Line 5412 C

It appears to be this block of code:

IDXGIOutput_FindClosestMatchingMode(
    output,
    &swapchainBufferDesc,
    &swapchainDesc.BufferDesc,
    (IUnknown*) renderer->device
);

This problem is occurring on my laptop which has dual GPUs viz. an integrated Intel UHD 620 and an MX150. The graphics driver is set to auto select. If I force the MX150 driver, then things work. If I leave it on auto-select or pick the UHD 620, it crashes.

FYI, the same DLL appears to works on my Dell with only an UHD 620 GPU, so I suspect this issue is somehow related to multi-gpus and picking an adapter.

If I change to using Vulkan, launching the app works fine, however, it crashes on exit when calling FNA3D.FNA3D_DestroyDevice(GLDevice);

I get an "access violation reading location xyz" error, which is pointing to this line:
FNA3D.dll!ShaderResources_DeactivateDescriptorSet(ShaderResources * shaderResources, unsigned int index) Line 5667 C

Note, the Vulkan crash on exit occurs on both the single GPU laptop and the dual GPU laptop.

OS: MacOS Big Sur Beta
Device: MBP2015

FNA3D Driver: Metal
Device Name: Intel Iris Pro Graphics
validateWithDevice:2556: failed assertion `Render Pipeline Descriptor Validation
No valid pixelFormats set.
'

/Library/Frameworks/Mono.framework/Versions/6.12.0/bin/mono-sgen64 /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/FNATemplate.exe
objc[63321]: Class SDLApplication is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67ba18) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924c38). One of the two will be used. Which one is undefined.
objc[63321]: Class SDLAppDelegate is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67ba68) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924c88). One of the two will be used. Which one is undefined.
objc[63321]: Class SDLTranslatorResponder is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bae0) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924d00). One of the two will be used. Which one is undefined.
objc[63321]: Class SDLMessageBoxPresenter is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bb08) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924d28). One of the two will be used. Which one is undefined.
objc[63321]: Class SDL_cocoametalview is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bb58) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924d78). One of the two will be used. Which one is undefined.
objc[63321]: Class SDLOpenGLContext is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bba8) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924dc8). One of the two will be used. Which one is undefined.
objc[63321]: Class SDLWindow is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bbf8) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924e18). One of the two will be used. Which one is undefined.
objc[63321]: Class Cocoa_WindowListener is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bc20) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924e40). One of the two will be used. Which one is undefined.
objc[63321]: Class SDLView is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bc98) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924eb8). One of the two will be used. Which one is undefined.
objc[63321]: Class METAL_RenderData is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bce8) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924f08). One of the two will be used. Which one is undefined.
objc[63321]: Class METAL_TextureData is implemented in both /usr/local/Cellar/sdl2/2.0.12/lib/libSDL2-2.0.0.dylib (0x10e67bd38) and /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libSDL2-2.0.0.dylib (0x112924f58). One of the two will be used. Which one is undefined.
FNA3D Driver: Metal
Device Name: Intel Iris Pro Graphics
validateWithDevice:2556: failed assertion `Render Pipeline Descriptor Validation
No valid pixelFormats set.
'

=================================================================
Native Crash Reporting

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

=================================================================
Native stacktrace:

    0x10afc3779 - /Library/Frameworks/Mono.framework/Versions/6.12.0/bin/mono-sgen64 : mono_dump_native_crash_info
    0x10af5b5be - /Library/Frameworks/Mono.framework/Versions/6.12.0/bin/mono-sgen64 : mono_handle_native_crash
    0x10afc2d42 - /Library/Frameworks/Mono.framework/Versions/6.12.0/bin/mono-sgen64 : sigabrt_signal_handler
    0x7fff20542d7d - /usr/lib/system/libsystem_platform.dylib : _sigtramp
    0x1a - Unknown
    0x7fff20450720 - /usr/lib/system/libsystem_c.dylib : abort
    0x7fff2044f9d6 - /usr/lib/system/libsystem_c.dylib : err
    0x7fff28559914 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : _Z13MTLGetEnvCaseI16MTLErrorModeTypeEbPKcRT_RKSt16initializer_listINSt3__14pairIS2_S3_EEE.cold.1
    0x7fff28547dd2 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : MTLReportFailure
    0x7fff28541b8a - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : _MTLMessageContextEnd
    0x7fff28546ed8 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : _ZL18validateWithDevicePU19objcproto9MTLDevice11objc_objectRK34MTLRenderPipelineDescriptorPrivate
    0x7fff28546418 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : -[MTLRenderPipelineDescriptorInternal validateWithDevice:error:]
    0x7fff2852f005 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : -[MTLCompiler newRenderPipelineStateWithDescriptorInternal:options:reflection:destinationBinaryArchive:error:completionHandler:]
    0x7fff284b36b3 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : -[MTLCompiler newRenderPipelineStateWithDescriptor:options:reflection:error:completionHandler:]
    0x7fff284b2e90 - /System/Library/Frameworks/Metal.framework/Versions/A/Metal : -[_MTLDevice newRenderPipelineStateWithDescriptor:error:]
    0x10e50ef7d - /Users/Kanbaru/OneDrive/Documents/FSOnCSharp/Unnamed.Engine.Template/bin/Debug/libFNA3D.0.dylib : METAL_CreateDevice
    0x1165b5a86 - Unknown
    0x1165afac3 - Unknown

=================================================================
Telemetry Dumper:

Pkilling 0x123145481232384x from 0x4517445120x
Entering thread summarizer pause from 0x4517445120x
Finished thread summarizer pause from 0x4517445120x.
Failed to create breadcrumb file (null)/crash_hash_0x1bdcc2f03

Waiting for dumping threads to resume

=================================================================
External Debugger Dump:

=================================================================
Basic Fault Address Reporting

Memory around native instruction pointer (0x7fff204cf4f2):0x7fff204cf4e2 ff ff c3 90 90 90 b8 48 01 00 02 49 89 ca 0f 05 .......H...I....
0x7fff204cf4f2 73 08 48 89 c7 e9 35 a2 ff ff c3 90 90 90 b8 53 s.H...5........S
0x7fff204cf502 00 00 02 49 89 ca 0f 05 73 08 48 89 c7 e9 1d a2 ...I....s.H.....
0x7fff204cf512 ff ff c3 90 90 90 b8 83 01 00 02 49 89 ca 0f 05 ...........I....

=================================================================
Managed Stacktrace:

      at <unknown> <0xffffffff>
      at Microsoft.Xna.Framework.Graphics.FNA3D:FNA3D_CreateDevice <0x000a5>
      at Microsoft.Xna.Framework.Graphics.GraphicsDevice:.ctor <0x00532>
      at Microsoft.Xna.Framework.GraphicsDeviceManager:Microsoft.Xna.Framework.IGraphicsDeviceManager.CreateDevice <0x002e2>
      at Microsoft.Xna.Framework.Game:DoInitialize <0x00144>
      at Microsoft.Xna.Framework.Game:Run <0x0006a>
      at Unnamed.Engine.UnnamedEngine:Run <0x0005a>
      at Unnamed.Engine.UnnamedEngine:Begin <0x000f2>
      at FNATemplate.Program:Main <0x0035a>
      at <Module>:runtime_invoke_void_object <0x000b0>

=================================================================

Process finished with exit code 6.