search

LunarG / vktrace

Vulkan vktrace / vkreplay
Other
6 stars 8 forks source link

vktrace: Trim test asserts on return value from QueueWaitIdle #21

Open TonyBarbour opened 6 years ago

TonyBarbour commented 6 years ago

We installed the latest Nvidia driver and now the trim tests get a bad return value from a QueueWaitIdle call and assert. Disabling the trim test in LunarG internal CI until resolved.

davidlunarg commented 6 years ago

Only happens only with a debug build of VulkanTools. An assert after the call to vkQueueWaitIdle fails because vkQueueWaitIdle returns VK_ERROR_DEVICE_LOST. The vkQueueWaitIdle is the last command inserted when trimming is started.

Problem occurs with nVidia driver 416.34. I haven't found a prior version of the driver with which it occurs. I don't think it is a driver issue, it just happens to occur with this driver. I suspect there may be something wrong with the commands inserted at the start of a trim. I tried various versions of VulkanTools all the way back to branch sdk-1.1.82 - the problem occurs, as long as I also use nVidia driver 416.34.

I tried to duplicate the problem on AMD graphics. I wasn't successful.

davidlunarg commented 6 years ago

Some more info...

The command to duplicate the problem is:

vktrace -tr frames-100-200 -a "--c 250"

We have only observed the problem on Windows with a debug build of the vktrace command and trace layer.

The problem was discovered when using an nVidia GeForce GTX950. I have duplicated it on a GeForce GTX660Ti. I haven't tried other nVidia graphics cards.

If you enable standard validation while running the above vktrace command, lots of warnings are displayed, including warnings about invalid bits set in dstAccessMask in calls to vkCmdPipelineBarrier. I debugged this, and found that the dstAccessMask was set to 0xcdcdcdcd, likely an uninitialized value.

Note that no warnings/errors are generated when tracing cube w/o the trim option.