Am incercat sa fac un test destul de simplu: Un quad randat cu un pixel shader care pur si simplu returneaza culoarea alb si in spatele lui un alt quad cu cu un shader foarte lung. Am incercat apoi sa schimb tot felul de states sau sa modific depthul in pixel shader si alte lucruri care am citit pe net ca ar dezactiva early z test. Unele despre care am citit ca l-ar dezactiva nu il dezactivau si cateva chestii cum ar fi noul feature din DX 11 Conservative Depth Output totusi il dezactivau.

Si inca ceva ciudat : cu pixel shaderul pentru quadul din spate chiar daca scriu depth manual daca specific atributul [earlydepthstencil] early Z tot functioneaza si da discard la toti pixelii quadului cu toate ca am modificat depthul astfel incat quadul sa fie in fata quadului alb....

Ok sper ca nu il doare pe nimeni capul dupa ce a citit postul acesta.
Problema e ca pe tema asta nu am gasit mai nimic folositor pe net iar in documentatia de la DirectX lipseste total.

Stiu ca este totusi doar o optimizare a celor care fac placile si nu face parte din API. Asa ca rog pe cineva care are idee sa imi explice si mie cum functioneaza totul. ( poate Nekitu ? trebuie sa fi invatat ceva tricks pe la Crytek )


P.S. Am si uitat...Craciun fericit !

In ce ordine desenezi quad-urile ?
Ca sa vezi orice avantaj cu early Z trebuie cel putin ordonat front-to-back. Zic cel putin fiindca poti desena "random", dar daca in exemplul dat tu desenezi back-to-front cu siguranta nu o sa vezi niciun avantaj.

Pai e doar un test sa vad ce operatii dezactiveaza early Z. Asa ca desenez front to back in orice caz. Prima data un quad cu un shader ieftin si a doua oara in spatele primului quad un quad cu un shader foarte scump...Imi dau seama daca early Z merge sau nu in functie de framerate. Am gasit asta : http://www.freepatentsonline.com/y2007/0257905.html. Undeva mai spre sfarsit e intr-un chenar o bucata de pseudocod care spune daca triunghiurile desenate cu shaderul respectiv vor profita de early Z. Iar apoi alte cateva detalii. Patentul e pt Nvidia dar si pe ATI tot cam la fel trebuie sa functioneze.

Probabil trebuia sa specifici asta in postul initial, eu de acolo am inteles ca nu iti dai seama cum functioneaza / ce este.
Masuratorile ar trebui sa le faci in milisecunde nu in fps (fps vs ms nu este un grafic linear) si efectiv pe GPU time, folosind un profiler.

Folosesc ca profiler si debuger Parallel Nsight ( fratele mai mare al lui PerfHud) dar la masuratori nu ma bazez pe el pentru ca imi da rezultate cam ciudate: de exemplu un quad fullscreen deseneaza mai multi pixeli decat are render targetul ( sa fie din cauza pixelilor care sunt pe diagonala quadului si nu pot fi procesati in perechi de cate 4 pentru ca nu apartin aceluiasi triunghi? ).