Eram curios cum as putea contoriza timpul unor operatiuni de randare.
Sa zicem ca nu vreau ca sa ma uit pur si simplu la FPS sa vad daca creste sau nu performanta. Adica sa nu stau sa vad daca a mai crescut un frame per second si defapt e de la altceva (un thread din Windows) etc..

Sa zicem ca am un copac. Sa vad daca mici schimbari la el aduce putina performanta. Am citit intr-un documentar (MS - Accurately Profiling Direct3D API Calls) si am vazut ca trebuie sa golesc bufferul de comenzi (cu query mechanism ala) ca sa trimita comanda mai departe si sa faca toate conversiile de comenzi si alte chestii sa masoare cat dureaza pe CPU.
Dar pe GPU cica nu imi spune. Acuma daca ii dau la present sa vad daca e gata GPU-ul reusesc sa am un timp real aproximativ? Adica dupa treaba cu CPU-ul sa verific in continuare daca e gata munca pe GPU verificand Present ala.
Acuma si chiar daca GPU-ul inca proceseaza alte chestii in timp ce ii dau alte comenzi tot o sa am un sfarsit in care verific daca totul e gata.
Alfu asa vreoceva ?


Mi-ar trebui chestiile astea ca sa stiu spre exemplu cat de multi cicli consuma diverite verificari pe CPU ca sa scap GPU-ul de procesare. Adica sa nu sar din lac in put si sa frec CPU-ul prea tare ca sa trimit mai putin sau in alt fel si sa nu se merite. Si daca stiu si exact munca in total e bine.

+

As putea sa vad cum reactioneaza diferite schimbari pe hardware diferit. Poate alte placi reactioneaza altfel si fac un mic test la loading care metoda proceseaza mai repede si o folosesc pe aia. Desi suna cam stupid.

Tot in documentarul acela trebuie sa fie flagurile de DirectX care iti permit sa interoghezi sistemul, incluzand GPU, pentru a afla in ce stare se afla. In mod cert poti afla daca GPU asteapta dupa CPU in momentul respectiv, probabil mult mai mult, dar nu ma pricep nici eu ca sa te indrum mai mult de atat.

Driverele instrumentate de la NVidia si PerfKit/SDK sunt f. utile pentru ca de ex poti vedea realtime timpii de procesare la diverse chestii, inclusiv pe stagii de randare ale scenei tale.

perfHud il folosesc foarte des. Insa ideea este ca vream sa am o contorizare generala a unui anumit proces. Spre exemplu:
Fac anumite calcule pe CPU independente de placa video, sa zicem diferite verificari (geometrice: daca un ray atinge un obiect etc etc.. daca se afla in frusum un anumit obiect, intersectii intre geometrie) care nu imi sunt contorizare in perfHUD si devine greu sa am o parere generala daca sa zicem am modificat doar o parte din cod si am sau nu performanta in plus.

Atata timp cat schimbarile tale nu introduc placa video in ecuatie, ar trebui sa te poti descurca cu un profiler simplu sau chiar cu un logger bazat pe QueryPerformanceCounter.

Aici ai gasit documentarul despre care vorbeai: http://msdn.microsoft.com/en-us/library/bb172234 (VS.85).aspx ?

Chiar si la schimbari de randare, un logger facut cu cap te poate lamuri. Desigur, pt. schimbari mici trebuie sa ai un sistem cat mai curat si sa rulezi cat mai multe teste ca sa elimini erorile provenite din zgomot (threaduri etc).

Pe de alta parte, ar trebui sa te ocupi prima data de lucrurile care au impact major asupra performantei, la nivel algoritmic preferabil, si sa lasi performance optimization (de tipul: sa mai taiem 2 frunze / triunghiuri din copac ca sa mai creasca FPS-ul) dupa versiunea alfa sau chiar beta a programului.

Acuma..ma gandeam ca daca am multe variabile de trimis la shader (texturi, matrici, valori cu materiale si alte minuni) sa fac o structura cu toate astea, apoi un obiect care sa contina toate astea sa le trimit odata. Ma ajuta asta sa mai cresc perfomanta putin? Daca da ma gandeam sa fac mai multe structuri, una sa fie sa zicem fara componente de textura, doar cu matrici de transformare etc..

Sau verific daca lumina isi schimba directia (cu o simpla verificare pe CPU) si daca nu, trimit la shader un obiect facut cu o structura care nu contine directia luminii. Asta bineinteles avand multe obiecte de randat. (faza cu lumina doar un exemplu nu ca ar avea utilitate doar pentru variabila asta)

Acuma nu stiu cat de mult se streseaza driverul pentru fiecare apel de trimitere a unei variabile la shader, si daca merita efortul asta.

Spre exemplu..

la inceput trimit multe variabile la shader care poate nu se schimba unele la randarea urmatoarelor 100 de obiecte sa zicem

if(blabla) {
effect->SetValue(structura_cu_10_componente....


(daca aici nu-mi trebe sa trimit 2 texturi si directia luminii, si nustiu care materiale)
if(blabla) {
effect->SetValue(structura_cu_3_componente....

A, si de ce nu pot sa fac o textura ca membru unei structuri?

Apelurile individuale spre diversele forme ale lui SetShaderConstant sint costisitoare. Cel mai bine e sa comasezi totul intr-o structura si sa trimiti de-odata. Exista o penalitate si daca trimiti mai mult decit ai nevoie (de exemplu daca doar jumate din structura se schimba de la frame la frame), dar e mai mica decit daca faci jdemii de apeluri separate spre functia aia. Daca ai parametri care se schimba cu frecvente diferite poti incerca sa-i grupezi in 2-3 structuri separate, dar de obicei nu merita efortul.

Cum sa pui texturi in structuri? Lasa prostia aia de FX framework sau ce folosesti acolo, ca daca pui intrebarea asta inseamna ca n-ai prins bazele. Uite-te mai low-level, la functiile din device. Samplerele nu-s tot aia cu constantele pentru shader. Constantele sint pur si simplu un bloc de memorie din care citeste shaderul, un sampler e un obiect mai complicat, cu filtrare, wrapping, mip chain etc. Ce din textura ai putea sa bagi in structuri?

Problema este ca nu imi da nici o diferenta. Sau prea mica diferenta.
Am 6 setConstant (matrici, vectori, si niste valori) la meshul care il randez.

- Cand bag intr-un for de 100 ori, adica 600 se constante pe frame, FPS-ul e acelasi cu 100 de setValue (structura care contine cele 6 componente). Deci daca apelez API-ul de 600 ori sa trimit constante am aceeasi performanta daca il apelez de 100 ori sa trimit in pachete.

- Daca bag mai putin, 50*6 = 300 de constante pe frame, mai scade doar cu 1FPS fara de SetValue care se trimite de 50 ori pe frame.

Procul e Duron 1800Mhz, placa video Geforce6600 (300mhz core, 500Mhz memoria). Oare inca nu e un botleneck cu constantele alea la valorile astea ?

Testele astea sintetice nu inseamna mai nimic de obicei. SetConstant() te costa CPU. E posibil ca in testul ala sa fii GPU-bound si atunci poti sa faci o groaza de prostii cu CPU-ul fara sa se simta nimic in frame rate. In jocul real o sa ai nevoie de CPU-ul ala pentru alte chestii, si abia atunci se va simti.

Cind esti CPU-bound (si majoritatea jocurilor sint cu FSAA/aniso off), o utilizare excesiva a lui SetConstant() te costa 5-10% din frame. Evident difera in functie de CPU, OS, cine face placa, versiunea de driver etc., da' cam asta-i numarul la care trebuie sa te astepti daca trimiti cite un parametru cu fiecare apel, in loc sa dai totul dintr-un foc. Nu-i mult, da' se aduna cu alte chestii. Cind n-ai nici un spike mare de optimizat trebuie sa incepi sa razi din chestiile astea mai mici, si atunci conteaza sa-ti iei inapoi 5% haliti de abuzul de SetConstant().

Cum adica functiile din device ? Clar mi-ar placea sa invat mai low level dar nu stiu de unde. In toate cartile care le-am citit mai level de atat nu se duc. Adica imi ofera explicatii cum datele se duc la vertex shader, ca se proceseaza per vertex, cum se duce mai departe la pixel shader si cam atat. Restul is diferite efecte.

http://msdn.microsoft.com/en-us/library/bb174467 (VS.85).aspx
IDirect3DDevice9::SetVertexShaderConstantF()

http://msdn.microsoft.com/en-us/library/bb174452 (VS.85).aspx
IDirect3DDevice9::SetPixelShaderConstantF()

http://msdn.microsoft.com/en-us/library/bb174461 (VS.85).aspx
IDirect3DDevice9::SetTexture()

http://msdn.microsoft.com/en-us/library/bb174465 (VS.85).aspx
IDirect3DDevice9::SetVertexShader()

si asa mai departe. FX framework ala e un wrapper peste functiile astea din IDirect3DDevice9:

http://msdn.microsoft.com/en-us/library/bb174336 (VS.85).aspx