Promena stanja za rendering, redundantni pozivi.

Na raznim mestima čitao da u principu treba imati što manji broj promena stanja rendera. Ali šta je sa redundantnim pozivima? Dakle recimo već mi je uključen z bafer ali ja ga ponovo uključim ili ponovo postavim istu teksturu. Da li d3d filtrira ovakve promene stanja?

Ovo me interesuje za pozive:
SetRenderState
SetTexture
SetTextureStageState
SetStreamSource
SetIndices
SetFvf
SetTransform
SetVertexShader
SetPixelShader

Šta se dešava ukoliko koristim d3d efekte?

Koliko se secam, neko filtriranje postoji, mada se ne treba previse oslanjati na to.
Verujem da je u medjuvremenu slicna optimizacija uradjena i na nivou drajvera.
Ovo ce ti bolje dogovoriti reljam, "njegovi" prave DX ;)
Sve jedno, uvek mozes da probas PIX i da vidis tacno koliko promene stejtova
"jedu" u odnosu na, recimo, drawprimitive.

Ja bih najradije sacekao Shader Model xxx i sve to radio rucno, kao nekada
software renderer ;)

Hvala na odgovoru. Umeđuvremenu, sam uspeo da isčeprkam nešto na gamasutri, članak je mator i tvrdi baš to da se ne treba oslanjati na drajvere.
http://www.gamasutra.com/features/19971205/mitchell_01.htm

Ipak stvar je u ovome:
D3DCREATE_PUREDEVICE za kreiranje device-a bez filtriranja, navodno tada brže radi jer ne pamti stanja.
A za filtriranje stanja za efekte se koristi interfejs ID3DXEffectStateManager.

Ali najzanimljivije mi je da je sve to urađeno u StateManager sample-u koji dolazi uz sdk i navodno trebao bih da primetim promene u brzini ako recimo prebacim na pure device bez filtriranja sa EfffectStateManager-om ali nema ama baš nikakve promene. Tako da je verovatno da moja nevidija ima drajvere koji filtriraju ova promene, a pure device ne donosi primetno ubrzanje.

Najviše me je interesovalo zbog efekata, jer u tom slučaju su mi sve promene upisane u efekat i ne mogu da izbacujem redundantne pozive.

Uzgred, za pix http://msdn.microsoft.com/libr...ofiling_Direct3D_API_Calls.asp. Izgleda da vreme za promenu stanja se ne meri tačno, jer ih d3d grupiše. Ovo je poprilično iznad mog nivoa znanja, tako da se time nisam zamarao. Samo sam hteo da mi sortiranje objekata bude efikasno a da ujedno koristim i efekte.

Isto tako, ukoliko prebacis DirectX runtime u debug mod, moci ces da vidis tokom
izvrsavanja gomilu warning-a svaki put kada bind-ujes neki efekat. Vecina tih warninga
(ako ne svi) predstavljaju "upozorenje" da je state vec postavljen u stanje koje se
trazi - redundantnost.
To ce tragicno spustiti performanse u debug modu zbog silnih konzolnih output-a,
ali u release modu ne bi trebalo da utice ni malo (procitao na DirectX mailing listi).
Nisam mnogo analizirao to oko render state-ova, posto bilo kakvim menjanjem efekata
nisam video neke bitne promene u brzini. Cak sam isao do te mere da izbacim sve
promene state-ova, bez obzira na vizuelni efekat, da bih video da li ce to uticati
na brzinu. Taj metod, naravno, i nije najbolji - posto zbog razlicitog koriscenja
Z-buffer-a brzina sve jedno nece biti ista.
Ukratko, moj utisak je da smanjenjem broja DrawPrimitive poziva, makar za jedan (;)),
anuliras sve efekte menjanja state-ova sto se performansi tice.