32 bit NeoDemo causes access violation in native DotNet Core helper function

[SamVanheer]

When running NeoDemo as 32 bit an access violation occurs in the native DotNet Core helper function StubHelpers::SetLastError

This is the complete call stack: https://pastebin.com/hzr5C2LG

This is the exception:

Unhandled exception at 0x0FD9372E (coreclr.dll) in dotnet.exe: 0xC0000005: Access violation writing location 0x0FD9380E.

The Veldrid codebase is completely unmodified aside from the ImGui renderable code and the menu code being disabled in the NeoDemo program, as well as the backend being set to OpenGL. I ran it with the 32 bit dotnet executable and used the 32 bit SDL2 library provided in the Veldrid repository.

I have experienced similar issues when using Veldrid in my own 32 bit program, where it causes a managed stack frame cookie corruption. I think it may be caused by some OpenGL calls passing the wrong size to native code somewhere, but i can't be sure.

I tried to run the 32 bit version with the Vulkan backend; while the 64 bit version works just fine, the 32 bit one fails with this error: https://pastebin.com/QkyKwuSG

I also tried the DX11 backend: https://pastebin.com/GL3Ceyxp

I assume this is failing because the Veldrid.SPIRV library relies on a 64 bit native library that it can't find. The NuGet package directory only contains 64 bit libraries.

I'm not sure if this is related or not.

[mellinoe]

You're right, there is some problem with using the OpenGL backend in a 32-bit application. The fact that Veldrid.SPIRV doesn't contain a 32-bit Windows binary has been fixed in a newer beta version of the package, but the one referenced here doesn't yet. On my machine, the Vulkan backend works fine in a 32-bit mode -- what drivers do you experience that crash on?

I'm not sure yet why the OpenGL backend fails on 32-bit. I'm going to try to isolate some different chunks of code and see if I can identify any problems.

[mellinoe]

The problem seems to be pretty simple: OpenGL actually uses the standard calling convention, rather than the C calling convention. I'm going to push a fix that will correct the function declarations so that they use the correct calling convention. This fixes everything that I'm seeing with regards to OpenGL.

Running Veldrid under 32-bit .NET Framework gives a much more descriptive error message for this, which made it easier to find out.

By the way, I actually tried 32-bit NeoDemo under Vulkan again, and I see the same validation error that you do. When I turn off the validation layers (GraphicsDeviceOptions.Debug == false), everything still renders correctly. I think this may be caused by a driver error, so I'm updating my Nvidia drivers and checking again. I don't see why a shader would compile correctly in a 64-bit app and fail to compile in a 32-bit app (since they are identical).

[mellinoe]

Well, the latest Nvidia drivers seem really unstable (I was crashing in Visual Studio alone), but I went back a couple versions and the error about shader compilation no longer occurs, and everything renders properly. I will merge the change to fix 32-bit OpenGL, and bump the version of Veldrid.SPIRV so it includes 32-bit binaries.

[mellinoe]

This should be fixed now, let me know if you're able to test against the latest code from the master branch.

[SamVanheer]

I ran the latest code and the OpenGL and Vulkan backends work in 32 bit mode. The D3D11 backend terminates with this exception: https://pastebin.com/0GteuRzh

I'll see if i can get my own program to run with these assemblies, since the beta hasn't been published in NuGet yet.

EDIT: using assemblies compiled from the master branch allows it to run without crashing.

[mellinoe]

@SamVanheer That should be fixed now.

[SamVanheer]

I can confirm that the D3D11 backend now works in both 64 and 32 bit builds.

[mellinoe]

Thanks for the confirmation. These fixes will be in the next release, so I'm closing this out.