Corner Case: vkCreateDevice access violation when device is lost

[candid laurel]

Steps I took in Windows 10:

• Create an instance
• pick a physical device
• Disable that device (simulating a device lost)
• Attempt to create a device using that physical device

The result is an access violation.

Does this really matter? Probably not. The only situation where I can see this being an issue is for, say, a server which creates temporary devices for GPU work for clients, and maintains a single instance.

Ideally, I feel vkCreateDevice should return VK_ERROR_DEVICE_LOST in this odd corner case.

[terse parcel]

Disable that device (simulating a device lost)
What does that mean? Going into windows settings?

This is a driver bug, so should be reported to whichever driver vendor you are using

[candid laurel]

What does that mean? Going into windows settings?
Exactly right
I get the physical device for my 970 here, then I disable it from the windows device manager, then I attempt to vkCreateDevice using the vkPhysicalDevice which represented my 970.

It's a driver bug?

[terse parcel]

its most certainly user error as well - drivers are not expecting you to do that which probably violates some assumption they make.

VK_ERROR_DEVICE_LOST is used for when the physical hardware is removed, say for an external GPU. It's also used for when the driver/hardware can no longer continue running, and needs to be reset. Disabling the adapter from device manager is not a use case I would worry about in my driver (if I were writing one).

Although, it is worth asking if there is a recommended way to simulate device lost without incurring permanent hardware damage.

[candid laurel]

Although, it is worth asking if there is a recommended way to simulate device lost without incurring permanent hardware damage.

Disabling it from device manager was the solution I found to this. I correctly get VK_ERROR_DEVICE_LOST on any other vk functions once the device is created.

[terse parcel]

Ah okay then driver bug it is

[candid laurel]

Ah so I guess I should report to nvidia that this happens.

It's hard to know with stuff like this, since vulkan and everything it encapsulates are all just one giant black box to me.

Are there any resources that give a semi-detailed overview on what vulkan is actually doing under the hood? I imagine it's an absolute monolith of work, but obviously the knowledge must exist, right?

[terse parcel]

I mean, mesa is open source

so you can read driver source code without any special privileges. Granted its a bunch of driver source code, so good luck just 'reading it'.

The "a trip through the graphics pipeline" from 2011 is semi accurate, but misses a lot of details about hardware since it was written 13 years ago

[candid laurel]

thanks. Appreciate it. I just want to build my understanding.

[candid laurel]

I was more interested in what internal resources vulkan is creating/managing during certain steps. I'll likely leave the driver stuff alone, as yes, it's a lot of pain to read

[candid laurel]

@terse parcel was this how you were certain that this was a driver bug?

[terse parcel]

yeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeep