Pixel Trapping når Unity's Frame Debugger ikke fungerer

Pixel Trapping When Unitys Frame Debugger Is Not Working



Fra og med versjon 5 inkluderer Unity et nytt verktøy for visuell rammedebugging, Frame Debugger. Dette verktøyet kan hjelpe deg med å løse mye grafikk problem , Z-slåssing, GPU-status er ikke normal, gjengivende køfeil, blandet operasjonsfeil, overdreven trekningsanrop, ineffektivitet osv. Det gir mer detaljert informasjon enn listen over tilstander i spillvisningen, og du kan lære mye om GPU rørledninger ved å samhandle med og se etter gjengivelse av hendelser / trinn. Virkelig, hver utvikler bør forstå dette verktøyet.

I denne delen vil jeg kort beskrive bruken av Frame Debugger og påpeke manglene og andre verktøy som kan gjøre opp for dem. Jeg skal ikke dekke alt, bare en generell oversikt over innholdet.



1. Bruk rammedebugger



Åpne hovedvinduet ved hjelp av Window-> Frame Debugger-menyen, jeg anbefaler å åpne den samtidig rammedebugger med spillvisning (Spillvisning). For å gjøre dette må du kanskje gjøre noen justeringer i vindusoppsettet. Grensesnittet jeg brukte for å feilsøke den grafiske skjermen, er som følger:





Anbefalt layout (unntatt kategorien Asset Store)

Foreslått vinduslayout (unntatt ressurslagerfanen)



Sett spillet i spill, til det punktet hvor du har hodepine og dårlig humør. I rammedebuggervinduet klikker du på aktiver for å få detaljer om den sist gjengitte rammen.

Den inneholder to hoveddeler: arrangementet og detaljene på høyre side. Arrangementet er i utgangspunktet en kommando sendt av CPU til GPU. Det er ganske enkelt. Tross alt kan ikke API-funksjonen som faktisk kalles, sees her, men hele prosessen pakkes og vises i kronologisk rekkefølge. De fleste av dem er kommandoer for å fjerne og tegne (ugjennomsiktig / gjennomsiktig) geometri, men du kan også legge merke til mer informasjon som GUI-gjengivelse, skyggehåndtering, grafiske effekter og antall tilbakeringinger.

Etter at du har valgt et arrangement, kan du få detaljert informasjon om arrangementet i detaljpanelet. Inkluderer: skyggeomfang og dets flagg, gjengi utdatahendelser og informasjon om skyggeegenskap. Samtidig viser spillvisningen objektene som er gjengitt før hendelsen (inkludert den nåværende hendelsen). Nedenfor er et eksempel



Hendelseseksempel

2. Hvorfor brukes rammedebugger?

Frame debugger gir oss verdifull informasjon. Rekkefølgen som hendelsene tegnes i (det vil si gjengekøen) er viktig for gjengivelsen. Hvis elementene i spillet ikke viser grovt, kan du oppdage at det ikke er riktig plassert i gjengiverkøen. , noe som resulterer i for tidlig eller utsatt gjengivelse, spesielt når du gjør tilpasset skyggeutvikling eller Z-skriving (dybdebufferskriving) parameterinnstilling og testing. Dette verktøyet løste mange problemer for meg: Jeg fant ut at skyboksen dekket skyggeproduksjonen fordi jeg glemte å sette flagget og gjengivelsesrekkefølgen.

For det andre, relativt, kan du også se antall anrop til trekksamtalen her, og indirekte måle gjengivelseskostnaden for scenen etter antall hjørner / indekser. Antall skyggepasseringer er selvfølgelig nyttig, men dens kompleksitet vises ikke her, noe som krever at du har grunnleggende sunn fornuft, som alle kan hjelpe deg med å forbedre ytelsen til scenen, for eksempel: du vil finne ut som forårsaker Noen rutenetttegninger kunne ikke utføre statisk / dynamisk batchbehandling. I mitt tilfelle vil du finne at de to tegningskallene til de to bildesprittene kombineres til ett ved hjelp av materialatlaset.

For det tredje, ved å samhandle med Frame Debugger, kan du raskt lære GPUs arkitektoniske kunnskap og forstå strømmen av Unity-gjengivelsesbehandling. Du kan bruke tastaturet til å hoppe gjennom de forskjellige trinnene for å se gjengivelsesprosessen til scenen. I det forrige eksemplet kan du se at gjengivelsen av scenen starter med opprydding av de tre cachene (farge, z, sjablong), etterfulgt av den ugjennomsiktige geometrien (fra forsiden til baksiden), skyboksen og den gjennomsiktige geometrien (bakfra til front). Gjengivelse.

Til slutt kan du få tilgang til skyggegenskapene for å få mer informasjon om materialet og skyggen, samt en referanse til dataene som brukes av objektet, for eksempel: materiale. De fleste har aldri brukt enhet avanserte visninger Du kan få tilgang til dem i inspektøren ved å klikke på avsnittikonet øverst til høyre og velge 'Feilsøking'.

Shader egenskaper

Shader egenskaper


2. forbehold

I løpet av tiden jeg jobbet for en klient, opplevde jeg også problemer forårsaket av det enkle grensesnittet til Frame Debugger. jeg er her Forene Europa 2016 Jeg snakket med noen av Unitys utvikling, og de visste om det, men de sa ikke om de ønsket å utvide det i fremtiden. Fra min erfaring er de største problemene:


  • Kan ikke få den underliggende informasjonen om API-samtalen etter hendelsen. I dette tilfellet behandler Unity hendelsen som en svart boks, så det vil være vanskelig å forbedre problemet under visse forhold.
  • Den generelle tilstanden til GPU-rørledningen i hver hendelse er ikke tilgjengelig, bare informasjon om geometri og materialer er tilgjengelig, og data på forskjellige stadier, som toppunkt / geometri / fragmentskygge og rasterizer, mangler.
  • Kunne ikke feilsøke skyggeleggere. Enten endre utgangsfargen for å feilsøke koden visuelt (også syndet enn utskrift) eller stole på ekstern programvare som GLSL-feilsøkingsklassen.
  • Det er vanskelig å etablere assosiasjonen av de resulterende pikslene med de tilsvarende hendelsene som skriver ut disse pikslene. Du må trinn for trinn sjekke hvilken hendelse som skriver feil informasjon i pikselet. Denne prosessen kan være ganske tidkrevende når det er et stort antall telefonsamtaler.
  • Det mangler nøyaktige indikatorer som måler effektiviteten til hvert trekkanrop, og antall hjørner / indekser er ikke det beste middelet for å karakterisere gjengivelseseffektivitet. Selv om flere hjørner krever mer båndbredde, kan det være verre å utføre en kompleks toppunktskygge på geometri eller kostbare tilstandsovergangsytelser.

Hvis du fremdeles er villig til å fortsette å se, kan du også lete etter en løsning på problemene ovenfor. Hva med å bruke andre komplementære verktøy?

4. RenderDoc

Etter å ha testet litt programvare, kan jeg absolutt anbefale flere modeller for alle. Det foretrukne valget i verktøykassen må være RenderDoc Et gratis verktøy utviklet av Crytek for å løse det underliggende samtaleinformasjonsproblemet, som bruker den klassiske tilnærmingen til nettverksangripere: det skaper en virtuell grafikkdriver som en mellommann (MITM) -applikasjonsapplikasjon i DX / GL / Vulkan-samtaler og gir detaljert feilsøkingsinformasjon. Den gode nyheten er at verktøyet allerede støtter integrert integrering i Unity, du trenger bare å installere RenderDoc på Windows-maskinen og starte enhetseditoren på nytt.

Målet med denne delen er å gi deg en oversikt over bruken av verktøyet, få interessen din til å begynne, bruke det jevnere og bruke mindre på strøm.

La oss komme i gang. Hvis installasjonen går bra, bør du kunne høyreklikke og velge Load RenderDoc i menyen:

Etter noen sekunder går du inn i avspillingsmodus. Hvis du er interessert i rammen du nettopp har gjengitt, klikker du på det nye ikonet med samme hode på venstre side av knappen for maksimal avspilling:

Bytt deretter til det nylig åpnede RenderDoc-vinduet og dobbeltklikk på den automatisk fangede loggen for å begynne å analysere den:

RenderDoc fanget logg

Rendoc Registreringslogg

Wow, dette er informasjonshavet, jeg skal drukne. Rolig, alt vil gå bra. Nå vil du få alle rammedataene i tusenvis av vinduer, tabellen er bekymret, jeg vil fortsette å forklare det virkelig interessante innholdet nedenfor.


4.1. Hendelsesleser + API-samtaler.

4.1 Event Browser + API Call

Fordelen med dette verktøyet er at det kan få den underliggende informasjonen til hver hendelse. Hendelsesleseren er som en utvidelse av Frame Debugger in Unity. Det inkluderer også tidkrevende (i millisekunder) og annen rask informasjon, som kan hjelpe mye effektivitet. RenderDoc har kontekstsensitive funksjoner, noe som betyr at når du velger en hendelse, vil de fleste andre vinduer og regioner vise informasjon som bare er relevant for hendelsen, og API-anropsvinduet under den viser hendelsene for behandling av hendelsen. Funksjonen ringte.

RenderDoc: Event Browser + API-samtaler

Det er flott å få disse tidkrevende dataene! Selv om de kanskje ikke er helt nøyaktige, er de relativt nøyaktige, det vil si at du kan utlede hvilke operasjoners trekksamtaler som må optimaliseres av tidkrevende.

4.2. Rørledningstilstand.

Rørledningsstatus

Jeg lurer ofte på arbeidsmodus for gjengivelsesrørledningen. Hvordan kommer den geniale geometrien inn i interiøret og konverteres til piksler på en 50-tommers skjerm? Ok, dessverre kan du ikke få en brukervennlig animasjon i dette verktøyet for å vise hvordan det fungerer.

Men det har noen Veldig bra gratis verktøy kan gjøre. I alle fall gir RenderDoc deg imidlertid tilgang til en stor mengde informasjon om rørledningstilstanden i tilfelle: inngangssamler, toppunkt / kropp / domene / geometri / fragment / beregningsskygge, rasterizer og utgangskombiner. Tro på kakerlakkens dom, RenderDoc er navnet sitt verdig.

RenderDoc: Pipelinestate for en pixelskygge

RenderDoc: Eksempel på produksjonssammenslåing


RenderDoc: Rasterizer-tilstand


4.3. Nettingutgang

Rutenettutgang

En annen funksjon ved RenderDoc er at du kan få nettdataene gjengitt i tilfelle gjennom toppunktskyggen: inngangs- og utgangsposisjon, normal, strukturkoordinater og annen informasjon. Faktisk kan du bruke den til å hente og lagre 3D-programmet eller rutenettet som blir gjengitt i spillet, men jeg vil ikke forklare saken i denne artikkelen.

4.4. Teksturer

Teksturer

Dette er min rett, som visualiserer inngangs- og utgangsstruktur i arrangementet. Å inkludere gjengivelse til teksturer eller andre mellomliggende bufferdata kan være veldig interessant når du bruker mellombuffering for bildebehandling, og det sparer også teksturplass.


RenderDoc: Texture viewer

4.5. Pixel feilsøking

Feilsøking på pikselnivå

I rammebufferen er det ikke uvanlig at de dårlige pikslene som er feil gjengitt, dekker de riktige pikslene. De fleste utviklere har opplevd denne typen mareritt. Den rare følelsen av at dårlige piksler er igjen i scenen får oss til å innse at noe har skjedd. Men jeg vet ikke hvorfor, men jeg skynder meg ikke! Hvordan bekrefte vår gjetning og finne ut hvor problemet ligger ...

Ja, her er hvordan du løser dette problemet: velg en piksel, klikk på hitroy (få en sekvens av hendelser for å skrive informasjon til den pikslen i framebufferen) eller feilsøk (for å feilsøke pikselskygeren). Feilsøking av disse problemene krever skikkelig teknisk kunnskap, du må samle kunnskap og ha litt forståelse for den demonterte versjonen av piksler.

RenderDoc: utvalg av piksler

RenderDoc : Pikselvalg

RenderDoc: Pixels historie

RenderDoc: Pikselhistorie

RenderDoc: shader-feilsøking



5. Eksempel

Eksempel

Noen studenter vil tvile på betydningen av ytelsesanalysatoren i selve arbeidet. Jeg vil fortelle deg dette: veldig nødvendig. Når du er usikker på ytelsespåvirkningen til en funksjon, kan du bruke ytelsesanalysatoren til å gjøre neste test, enten det er en rammedebugger, eller om nødvendig, med RenderDoc og andre lignende verktøy vil være til stor fordel for arbeidet ditt.

La oss se på et eksempel. Ikke alle vet at det er forskjell på å få tilgang til materialet i skriptet og få tilgang til rendererens skyggemateriale, men bare noen få mennesker vet at dette vil ha en innvirkning på ytelsen, selv om det i de fleste tilfeller er det samme. Men siden vi har verktøy for hånden, hvorfor ikke finne ut av det?

Vårt testscenario har bare en sprite. Etter å ha brukt den samme transformasjonen gjentatte ganger for 10.000 ganger, opptar den nesten hele synsfeltet, slik at du kan forestille deg at det er mange deler som ikke trenger å tegne. Koden er som følger:

ugyldig Start () {

for (int i = 0 i

{

varsprite = Instantiate (Sprite)

sprite.transform.parent = transform

varsharedMaterial = sprite.sharedMaterial

// Kommenter meg for å lage materialkopi per sprite.

// varmat = sprite.material

}

}

Tilgang til sharedMaterial er jevn, det er bare ett materiale, og det deles mellom alle sprite-forekomster når du får tilgang til materiale, du må lage et eget materiale for hver sprite, slik at du ikke kan batch Tegn anrop, bruk renderDoc for å se analysen resultatet av Render.TransparentGeometry-funksjonen er som følger:

Jeg tror at tiden overhead gitt av RenerDoc ikke er veldig pålitelig. Materiallesingen ser ut til å være unøyaktig i det hele tatt. Jeg vet ikke det faktiske antallet hardware loop-anrop i dette eksemplet. Jeg så også på Unitys prestasjonstester. I begge tilfeller sammenlignes det delte materialet med å instantiere det nye materialet, og den andre implementeringen resulterer i høyere overhead og båndbredde overhead på grunn av manglende evne til å slå sammen trekningsanropene.

Den virkelige kostnaden er statlig overgang i trekkring, ikke antall trekkring selv. Etter å ha satt forskjellige tilfeldige farger for hver sprite ved hjelp av Material.SetColor, la jeg merke til at to FPS-er ble droppet. Denne utgaven kan sendes gjennom nylig utgitt Vulkan API å løse .

6. Konklusjoner

for å konkludere

RenderDoc er verken et perfekt verktøy eller en erstatning for Unity's rammedebugger. Det er bare et komplett verktøy. Du kan enkelt bruke den til å få den underliggende informasjonen du trenger. Det er også morsomt å bruke, men jo lenger du går. Jo mer komplisert problemet er, jo mer må du ha en god forståelse av maskinvarearkitekturen til GPU.

Jeg må innrømme at bruk av renderDoc er en tidkrevende oppgave, så husk: gjør ytelsestesting før du gjør målrettet optimalisering. I 95% av tilfellene kan du bruke Unitys egen framedebugger for å fullføre feilsøking, men for å gjøre 5% av livet ditt umiddelbart ulykkelig må du være forberedt.

Kombiner disse verktøyene med ytelsestesteren. Det er alltid noen trivielle situasjoner i den virkelige verden. Jeg vet ikke hvor flaskehalsen stammer, spesielt når jeg utvikler på en plattform som mangler feilsøking.

Som alltid, takk for tilbakemeldinger og spørsmål!


Opprinnelig lenke:
http://www.gamasutra.com/blogs/R ... nough_RenderDoc.php