Pitanja u vezi bafera (MANAGED, DEFOULT...)

Jel moze neko da mi pojasni D3DPOOL_MANAGED bafere? Jedino što mi je jasno je da imaju kopiju u ram-u tako da ih ne treba ponovo kreirati posle gubljenja device-a.
Dali su ovi baferi uvek smešteni u memoriji grafičke kartice ili mogu biti i u ram-u?
Dali je managed bafer sporiji ukoliko se u toku rada redovno menja njegov sadržaj (jer mora da čuva kopiju)? Dali to znači da treba za takvu upotrebu bafera treba da koristim systemmem (ili D3DPOOL_DEFAULT jer koristim discard fleg)?

Gde zapravo idu podatci kada kreiram verteks bafer sa flegom D3DPOOL_SYSTEMMEM? Dali idu u ram i u čemu je razlika u odnosu na D3DPOOL_SCRATCH? Konkretno nejasna mi je sledeća rečenica iz dxsdk help-a.


I dali prilikom menjanja sadržaja bafera koji je označen sa DISCARD i D3DPOOL_DEFAULT ima ikakve veze dali lokujem ceo bafer ili samo deo koji se menja?

D3DPOOL_MANAGED bafer stoji stalno u RAM-u i ucitava se u video memoriju po potrebi - to radi neki directx-ov manager. Ako imas 64mb na grafickoj, a ucitao si 200mb managed tekstura, primetices da ce, kad prikazes teksture koje nisi dugo prikazivao, rendering malko da se zakoci dok directx ne uploaduje to u video memoriju (mada na brzom kompjuteru to verovatno i neces primetiti).
Kada se device unisti (DeviceDestroyed->DeviceCreated) _moras_ rekreirati i managed resurse.
Kada se device izgubi (DeviceLost->DeviceReset - npr resize) _ne moras_ rekreirati managed resurse.

D3DPOOL_DEFAULT je vise low level i stoji uglavnom samo u video memoriji (i ne zauzima RAM tada!) ili u agp memoriji. Moras da rekreiras bafere i na destroyed i na lost. To je cini mi se i jedini pool sa kojim mozes optimizovano da dinamicki citas/menjas sadrzaj.

U praksi - koristis managed uvek, dok ti default bas ne zatreba za neki konkretni slucaj (znaces jer npr neces moci da lockujes), i koristis debug directx runtime i pratis debug output jer ce ti tu objasniti detalje, i takodje prijaviti performance-related issues. Takodje, default moras koristiti ako imas svoj manager za resurse (npr rucni streaming).

_Mozda lupam_, ali cini mi se da je razlika izmedju D3DPOOL_SYSTEMMEM i D3DPOOL_SCRATCH u tome sto za scratch ne vaze ogranicenja device-a (velicina teksture, formati, itd) a za sysmem vaze, ali sa scratch-om imas manje/ni malo mogucnosti oko kopiranja sa/na managed/default, dok systemem mozes koristiti realtime za npr rucno crtanje efekata i upload na texturu koju trenutno iscrtavas.
Ja koristim scratch za utilityje i slicno, kada mi treba samo neka funkcionalnost directxa (npr kompresija textura) bez device-related ogranicenja, dok systemmem nikad nisam imao potrebe da koristim.
A sta im znaci to D3DPOOL_SYSTEMMEM: 'This memory allocation consumes system RAM but does not reduce pageable RAM.' nemam pojma, mogu samo da pretpostavim da ga mozda directx alocira iz nekog svog procesa pa ti ne smanjuje pagable ram tvojeg, pa ako imas mnogo RAM-a, a trenutna verzija XP-a ti podrzava 2gb pagefile-a, onda mozes da ucitas 1 gb systemmem tekstura i da ti i dalje ostane za koriscenje 2gb memorije iz pageable space-a tvog procesa :)

Filip je u pravu, koristi D3DPOOL_MANAGED kada god mozes (drugim recima, stavi sve u MANAGED na pocetku). Uvek posle mozes da izbacis resurse u DEFAULT ako treba. Kada izgubis device, resursi koji su ucitani u MANAGED ne nestaju, sto celu stvar cini mnogo laksom.

I za kraj, MANAGED behavior odgovara modelu virtualizovane video kartice sto je buducnost D3Da, tako da ako vec mozes, koristi MANAGED.

Ok. Pohvatao sam stvari.
Ono sa čim sam radio je verteks bafer koji menjam u svakom frejmu. Koristio sam ga za prikazivanje sprajtova (tj. kvadrata). Znači D3DPOOL_DEFAULT.

Ono što me još interesuje dali ima nekakvog uticaja na performanse veličina memorije koju lokujem. Dakle ima li uticaja dali lokujem ceo bafer ili samo deo koji će biti promenjen (lokujem sa DISCARD flegom).

Dali su "performance-related issues" vidljivi kada debag output nije podešen na maksimum. Na maksimumu mi je gotovo nemoguće da pratim program jer se zaguši slanjem poruka kako sam postavio teksturu koja je već uključena i sl.

I još jedno pitanje:
Negde sam pročitao da na performanse loše utiče ako neki bafer (podatke) menjam pa odmah zatim šaljem na rendering jer d3d zastane dok ne pošalje podatke do grafičke kartice. Ipak ako koristim D3DPOOL_DEFAULT i D3DUSAGE_DINAMIC, onda su podatci u AGP memoriji (?) pa ih d3d svakako neće slati do kartice dok ih ne upotrebim. Dakle mislim da u ovom slučaju neće biti uticaja na performanse. Jesam li u pravu?

Sigurno da ima, samo u kojoj kolicini to moras sam da otkrijes. Moguce je da je razlika u brzini izmedju lokovanja 100 i 200 bajtova zanemarljiva, a za vece bafere nije, a gde je granica to moras izmeriti.



Ne! ako meris performanse, iskljucivo compile release i release dx :)
Inace ces dobiti ne samo sporije nego i potpuno drukcije rezultate.



Ako ti je stvarno bitno: isprobaj, pa javi rezultate!
Evo ja sam sad pomerio jedan big vb update na posle renderinga i ne vidim nikakvu razliku, mada nije neki naucni test :)
D3D ionako pooluje sve komande za graficku, i ne bi trebao uopste da zastaje na DrawPrimitive nego samo na odredjene pozive (Present() ili nesto slicno).

Ali sto ti je to uopste bitno? :)

E hvala na odgovoru, taman sam pomislio da me ljudi ovde ignorišu...


Nisam mislo na merenje performansi već na poruke koje šalje direct3d debag. Spominjali su gore... Ma nije ni bitno.



Pa bitno mi je:) Kada već učim da radim neke stvari onda da naučim kako treba. Na jednom stranom forumu sam čitao nešto oko modifikacije bafera i neko je napisao baš to. Sad ako sve bafere koje neprekidno menjam strpam u d3dpool_defoult onda mi nije bilo logično zašto bi to neko pominjao (dakle to da ne treba ići na rendering, a uzgred totalno sam smetnuo sa uma da d3d baferuje komande).

E i možda sam stvarno davež ali interesuje me još jedna stvar: Kažeš da ima uticaja veličina bafera(d3dpool_defoult, d3dusage_dynamic, d3dlock_discard) koju lokujem (dakle menjam isti deo bafera a lokujem nešto veći). Ali ako je on u AGP memoriji (dakle RAM) onda ne vidim razlog!? Da je u pitanju managed bafer, tj. da su podatci i u memoriji grafičke kartice onda bi d3d morao da obnovi deo bafera koji sam lokovao, a ovako podatke šalje samo posle DrawPrimitive.

Znaci ne mogu da verujem, upravo mi je es izbrisao ispisanu poruku jer se radi backup baze... e dodjavola..

Evo onda ukratko:

1.) Ah sad kontam, imas brdo debug poruka! Ako ti nisu bitne, idi na dx control panel, i smanjuj Debug Output Level dok ti se ne budu prikazale samo one koje su ti bitne.

2.) Kad lockujes default buffer sa discard flagom (najbrze) onda ti dx da pointer na neki novi bafer koj on tek nakon tvog Unlock()-a upise tamo gde treba i kad treba, jer do tada mozda iscrtava neke zaostale stvari koristeci stari!


Sretan rad :)