Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vulkan memory access violation - handling. #19

Open
philstopford opened this issue Jun 8, 2020 · 1 comment
Open

Vulkan memory access violation - handling. #19

philstopford opened this issue Jun 8, 2020 · 1 comment

Comments

@philstopford
Copy link
Contributor

CommandList.SetVertexBuffer(0, LinesVertexBuffer);

can yield an exception under certain drivers, it seems:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

Under .NET Framework, this kind of violation can be caught with some extra work (try/catch is not enough by itself - the runtime defaults to managing these exceptions) and with some configuration, it may allow for recovery. .NET Core lacks the ability to manage these exceptions : the runtime catches and silently exits the application.

This looks like an issue within Veldrid itself in terms of driver handling and may well be intentional and/or a bug.

Noting here because I run into this primarily with intel drivers and only ever with Vulkan.

@philstopford
Copy link
Contributor Author

I figured out part of the problem and a workaround. It looks like Veldrid's Vulkan approach gets into trouble if something like this :

			updateBuffer(ref LinesVertexBuffer, lineArray, VertexPositionColor.SizeInBytes, BufferUsage.VertexBuffer);

involves lineArray having no entries. This should be harmless, one would think, with appropriate sanity checking in Veldrid, but it triggers a no valid memory exception (which I was catching).

Later, when the SetVertexBuffer command is used, things explode.

I worked around it in my code by explicitly setting the LinesVertexBuffer to null in the catch block. I check for null in an outer check for Command.SetVertexBuffer.

Oddly, the previous approach never seemed to yield these problems under nVidia. Might be driver related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant