Dela via

Använda DRED för att diagnostisera GPU-fel

DRED står för Enhets borttagna utökade data. DRED är en växande uppsättning diagnostikfunktioner som hjälper dig att identifiera orsaken till oväntade fel vid borttagning av enheter. På maskinvara som stöder nödvändiga funktioner (enligt definitionen nedan) levererar DRED automatiska spårmarkörer samt GPU-sidfelrapportering.

Automatiska brödsmulor

För att sätta scenen för automatiska sökvägar, låt oss först nämna den manuella varianten. I väntan på möjligheten av en Timeout Detection and Recovery (TDR)kan du använda metoden ID3D12GraphicsCommandList2::WriteBufferImmediate för att placera spårpunkter direkt i GPU-kommandoströmmen för att spåra GPU-förloppet.

Det här är en rimlig metod om du vill skapa en anpassad implementering med låg omkostnader. Men det kan sakna en del av mångsidigheten hos en standardiserad lösning, till exempel felsökningstillägg eller rapportering via Windows Error Reporting (WER) (även kallat Watson).

Dreds automatiska sökvägar anropar därför WriteBufferImmediate för att placera förloppsräknare i GPU-kommandoströmmen. DRED infogar en markör efter varje renderingsoperation—det vill säga varje operation som leder till arbete av GPU:n (till exempel Draw, Dispatch, Copy, Resolveoch andra). Om enheten tas bort mitt under en GPU-arbetsbelastning är DRED breadcrumb-värdet i princip en samling av återgivningsoperationerna som slutfördes före felet.

Ringbufferten för brödsmulhistorik behåller upp till 64KiB av operationer i en viss kommandolista. Om det finns fler än 65536 åtgärder i en kommandolista lagras endast de sista 64KiB-åtgärderna– och skriver över de äldsta åtgärderna först. Räknarvärdet för sökväg fortsätter dock att räknas upp till UINT_MAX. Därför LastOpIndex = (BreadcrumbCount - 1) % 65536.

DRED 1.0 var först tillgängligt i Windows 10, version 1809 (Windows 10 oktober 2018 Update), och det visade rudimentära automatiska spårvägar. Det fanns dock inga API:er för detta, och det enda sättet att aktivera DRED 1.0 var att använda Feedback Hub för att fånga en TDR-återgivning (repro) för Appar & Spel>Spelprestanda och Kompatibilitet. Det främsta syftet med DRED 1.0 var att hjälpa till att rot-orsaka-analysera spelkrascher via kundfeedback.

Varningar

  • Eftersom en GPU är kraftigt pipelinead finns det ingen garanti för att räknaren anger exakt vilken operation som misslyckades. På vissa panelbaserade uppskjutna återgivningsenheter är det i själva verket möjligt att sökvägsräknaren är en fullständig resurs eller UAV-barriär (unordered Access View) bakom den faktiska GPU-förloppet.
  • En visningsdrivrutin kan ordna om kommandon, hämta från resursminnet i god tid innan du kör ett kommando eller rensa cachelagrat minne efter att ett kommando har slutförts. Något av dessa kan generera ett GPU-fel. I sådana fall kan brödsmuleräknarna vara mindre användbara eller vilseledande.

Prestanda

Även om auto-breadcrumbs är utformade för att vara resurseffektiva, är de inte gratis. Empiriska mätningar visar 2-5% prestandaförlust på en typisk AAA Direct3D 12 grafikspelmotor. Därför är automatiska brödsmulor avstängda som standard.

Maskinvarukrav

Eftersom räknarvärdena för sökvägar måste bevaras efter borttagningen av enheten måste resursen som innehåller sökvägar finnas i systemminnet och den måste finnas kvar om enheten tas bort. Det innebär att visningsdrivrutinen måste stödja D3D12_FEATURE_EXISTING_HEAPS. Lyckligtvis är detta fallet för de flesta Direct3D 12-visningsdrivrutiner på Windows 10, version 1903.

Felrapportering för GPU-sida

En funktion som är ny för DRED 1.1 är DRED GPU-sidfelrapportering. Ett GPU-sidfel inträffar vanligtvis under någon av dessa förhållanden.

  1. Ett program kör av misstag arbete på den GPU som refererar till ett borttaget objekt. Detta är en av de främsta orsakerna till en oväntad enhetsborttagning.
  2. Ett program kör av misstag arbete på den GPU som har åtkomst till en borttagen resurs eller en icke-resident panel.
  3. En skuggning refererar till en oinitierad eller inaktuell beskrivning.
  4. En skuggning indexerar bortom slutet av en rotbindning.

DRED försöker åtgärda vissa av dessa scenarier genom att rapportera namn och typer av befintliga eller nyligen frigjorda API-objekt som matchar den virtuella adressen (VA) för det GPU-rapporterade sidfelet.

Varning

Inte alla GPU:er stöder sidfel, även om många gör det. Vissa GPU:er svarar på minnesfel genom att: bit-bucket-skrivningar; läsa simulerade data (till exempel nollor); eller genom att helt enkelt hänga. Tyvärr, i fall där GPU inte omedelbart hänger sig, kan en Timeout Detection and Recovery (TDR) inträffa senare i processen, vilket gör det ännu svårare att hitta grundorsaken.

Prestanda

Direct3D 12-körningen måste aktivt kurera en samling befintliga och nyligen borttagna API-objekt som kan indexeras efter virtuell adress (VA). Detta ökar omkostnaderna för systemminnet och ger en liten försämring av prestanda vid åtgärder för att skapa och förstöra objekt. Därför är det här beteendet inaktiverat som standard.

Maskinvarukrav

En GPU som saknar stöd för sidfelshantering kan fortfarande dra nytta av funktionen för automatiska spårmarkörer.

Konfigurera DRED i kod

DRED-inställningarna är globala för processen och du måste konfigurera dem innan du skapar en Direct3D 12-enhet. Det gör du genom att anropa funktionen D3D12GetDebugInterface för att hämta en ID3D12DeviceRemovedExtendedDataSettings.

CComPtr<ID3D12DeviceRemovedExtendedDataSettings> pDredSettings;
VERIFY_SUCCEEDED(D3D12GetDebugInterface(IID_PPV_ARGS(&pDredSettings)));

// Turn on auto-breadcrumbs and page fault reporting.
pDredSettings->SetAutoBreadcrumbsEnablement(D3D12_DRED_ENABLEMENT_FORCED_ON);
pDredSettings->SetPageFaultEnablement(D3D12_DRED_ENABLEMENT_FORCED_ON);

Obs

Ändringar i DRED-inställningarna påverkar inte enheter som redan har skapats. Men efterföljande anrop till D3D12CreateDevice använder de senaste DRED-inställningarna.

Åtkomst till DRED-data i kod

När enheten har tagits bort (till exempel Present returnerar DXGI_ERROR_DEVICE_REMOVED) använder du metoderna i gränssnittet ID3D12DeviceRemovedExtendedData för att komma åt DRED-data för den borttagna enheten.

Om du vill hämta gränssnittet ID3D12DeviceRemovedExtendedData anropar du QueryInterface på ett ID3D12Device (eller avlett) gränssnitt och skickar gränssnittsidentifieraren (IID) för ID3D12DeviceRemovedExtendedData.

void MyDeviceRemovedHandler(ID3D12Device * pDevice)
{
    CComPtr<ID3D12DeviceRemovedExtendedData> pDred;
    VERIFY_SUCCEEDED(pDevice->QueryInterface(IID_PPV_ARGS(&pDred)));
    D3D12_DRED_AUTO_BREADCRUMBS_OUTPUT DredAutoBreadcrumbsOutput;
    D3D12_DRED_PAGE_FAULT_OUTPUT DredPageFaultOutput;
    VERIFY_SUCCEEDED(pDred->GetAutoBreadcrumbsOutput(&DredAutoBreadcrumbsOutput));
    VERIFY_SUCCEEDED(pDred->GetPageFaultAllocationOutput(&DredPageFaultOutput));
    // Custom processing of DRED data can be done here.
    // Produce telemetry...
    // Log information to console...
    // break into a debugger...
}

Felsökningsprogramåtkomst till DRED

Felsökare har åtkomst till DRED-data via d3d12!D3D12DeviceRemovedExtendedData dataexport.

För WinDbg-användare kan du läsa DirectX-Debugging-Tools GitHub-lagringsplats för ett WinDBG-tillägg som gör det mycket enklare att felsöka Direct3D 12 DRED-tillstånd.

DRED-telemetri

Ditt program kan använda DRED-API:er för att styra DRED-funktioner och samla in telemetri för att analysera problem. Detta ger dig ett mycket bredare nät för att fånga de svåråterskapade TDR:erna.

Från och med Windows 10, version 1903, rapporteras alla händelser där enheter har tagits bort i användarläge till Windows Error Reporting (WER), även kallat Watson. Om en viss kombination av program, GPU och visningsdrivrutin genererar ett tillräckligt antal enhetsborttagningshändelser är det möjligt att DRED tillfälligt aktiveras för kunder som startar samma program i en liknande konfiguration.

Mer information om DRED