Issue: errors collecting GPU counters on NVIDIA driver 471.11Īffected devices: NVIDIA GPUs running drivers of version 471.11 or similar Problem: On AMD, collecting High Frequency Counters will fail and/or crash after collecting Debug Layer Warnings in PIX. Status: Active ⚠️ (AMD are working on a fix) Issue: crash on AMD while collecting High Frequency Counters Note that stopping analysis on the first GPU Capture file is not sufficient.To work around this, please close the first capture file before starting analysis on the second one.If you have two open GPU Capture files (either in the same instance of PIX or in separate instances), you start analysis on one of them and then you start analysis on the other one without closing the first one.To work around this, please use the primary GPU or please disable the primary GPU in Device Manager.If you have two AMD GPUs in your PC, both enabled, and you start analysis on the secondary GPU.Problem: There are at least two known causes for this issue: Status: Active ⚠️ (has workaround, AMD are working on a fix) Issue: error starting analysis on AMD (“PIX was unable to create a D3D12 device”) Workaround: Disable Hardware-accelerated GPU scheduling in the Settings app on your PC, restart your PC, and launch PIX again. Problem: While collecting timing data in PIX, you may hit errors such as “Timing Data Error”, “Not enough ETW passes were completed” or similar errors. Status: Active ⚠️ (has workaround, NVIDIA working on fix)Īffected devices: NVIDIA GPUs running recent drivers with Hardware Scheduling enabled Issue: errors collecting timing data on NVIDIA In the future, we will update this page with any exceptions to this guidance. In general we recommend using the latest available driver for your GPU. Workaround: Click Home->Settings in PIX, check the “Use replay-time ExecuteIndirect argument buffers (experimental)” box, and reopen your capture file. It’s particularly problematic if the argument buffers are generated at the same time as other types of buffers and the application expects the buffers to be consistent with each other: at replay time, PIX will use the capture-time copy of the argument buffer but the replay-time copy of the other buffer, and bad things may happen. This works for older applications, but in recent years it has started causing problems for applications that generate their argument buffers non-deterministically (e.g. By default, PIX will snap a copy of your capture-time ExecuteIndirect argument buffers and use those to perform your ExecuteIndirects at replay time. Status: Active ⚠️ (has workaround for a lot of cases)Įxplanation: This is commonly caused by ExecuteIndirect non-determinism. backbuffer contents) doesn’t match capture-time output If you continue to hit problems after the setting this checkbox, then please contact us and we will be eager to investigate. If you are hitting a problem that isn’t listed below, then please contact us via the “Send Feedback’ button in the top-right corner of the PIX UI, or chat with us on the #pix channel on the DirectX Discord.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |