Zavisi od komplikovanosti "obrade" vertexa i kolicine vertexa. Sve dok su u pitanju proste transformacije treba ostati na hw procesiranju. Kada vrsis komplikovanije "obrade" to bi mogao da izvedes na CPU i svedes problem na prethodni. Ukoliko je brzina CPU pocesiranja + vreme za transfer vertexa u GPU memoriju manje od GPU procesiranja imas ubrzanje.

U multipass resenjima procesiranje na CPU zaista donosi vidljivu prednost ako je kolicina vertexa prilicno velika a CPU brz.

I jos nesto... Nisam expert za d3d, ali mi se cini da ako postavis vertrex shader i pozoves ProcessVertices, ceo posao ce biti obavljen na CPU.

Evo primera... U jednom programu koji pisem, napravio sam skinning 3d charactera na GPU sa malo komplikovanijim vertex shaderom. Posto imam multipass rendering, 3d character se "skinovao" u svakom rendering pass-u na isti nacin. Radilo je dosta dobro, ali nisam bio zadovoljan brzinom. Zato sam napravio sve to na CPU i kopirao skinovane vertexe u GPU memoriju. Ubrzanje je bilo drasticno.

Postoji jos jedan nacin (experimantalan) koji je jos brzi, a to je da iskoristis pixel shadere za procesirajne vertexa. Prvo napuni vertexe u rgba32f texturu, postavi filtering na nearest, kreiraj rgba32f render target koji je iste velicine kao textura, napisi pixel shader koji ce da transforimes vertexe i renderuj quad preko celog render targeta. Rezultat koji se nalazi u render targetu su tvoji transformisani vertexi. Sada je potrebno da iskopiras te podatke u neki vertex bufer i dalje renderujes kao i pre. Ovo je za sada moguce samo na nvidia hw (FX i noviji) zbog 32bitne preciznosti u pixel shaderima.

yooyo

I ja se nesto mucim sa sporim vertex procesiranjem - izgleda da je na modernim GPUovima vertex processing prilicno zanemaren?

Makar ce oni unified shaderi resiti (valjda) taj problem.

Do USA (Unified Shader Architecture) ima vise od godinu dana da cekas. Danasnji GPU su optimalno balansirani, tako da imaju dobar odnos izmedju vertex i pixel pipelinea.
A tada ce se pojaviti i geometry shaderi :)

Takodje, postoji i vertex cache koji ti omogucava da se ne mucis mnogo sa optimizacijom index buffera, i brzina triangle stripa i triangle liste je priblizno ista.

U svakom slucaju, na danasnim prosecnim karticama (NV 6200, NV 6600, ATi x300, ATi x600) mozes racunati na 500.000 poligona po frejmu sa dobrim framerate-om. Ako ti to ne polazi za rukom ili negde gresis ili zaista imas mnogo vertexa za render.

yooyo

Ma imam mnogo vertexa, ali u sustini u pravu si, ni nemam problem nego se tripujem - kontam da je oko 60mil trouglova po sekundi na ATI 9600 sasvim ok sto se vertex output-a tice?

Sta ti to znaci 500k pol/frejm, u kolko fps, 20, 30, 60, 90? :)

Slazem se za kesheve - odavno sam odustao od nvtristrippera i slicnih optimizatora, koristim obicne indexe jer sam isprobao sve varijante optimizacija, bez bitne promene performansi - ocigledno keshing radi perfektno, i to ne na nivou 'cuvam poslednja 24-32 vertex proracuna' kao na starim grafickim nego cini mi se na preko hiljadu.

Sve zavisi koliko opterecujes pixel pipeline (PP), jer ako ti je PP usko grlo, povecanjem ili smanjenjem broja poligona neces puno postici. Obzirom da imas ogromnu kolicinu vertexa (teren rendering pretpostavljam) i nisi zadovoljan brzinom onda moras smanjiti njihov broj.

btw... 60 miliona je solidna cifra. Verovatno ih racunas na CPU i posle saljes grafickoj na crtanje. Da li si mozda napravio pametan streaming, tako da dok GPU renderuje CPU salje ili racuna nove vertexe?

Generalno.. provali ko limitira fps (CPU, GPU-Vertex pipeline ili GPU-Pixel pipeline) i u zavisnosti od toga sredi taj deo programa. Uradi sto bolji cullling na CPU (nemoj da saljes na rendering ono sto se nevidi).

yooyo

da, da, patim se sa terenom i dalje...
ma ne znam dal sam zadovoljan brzinom, ali cini mi se da tu nemam problema.
nemam racunanja nicega na CPU-u, sve je pregenerated, pa se streamuje sa diska, otpakuje (to jedino jede cpu) i renda. sastavicu neki demo uskoro, mada nesto ne stizem da radim na tome u poslednje vreme, imam puno drugog posla :)