Videomemória kezelés
Ez a téma lezárásra került a moderátor által. A lezárás oka: Végtelen örömmel töltene el bennünket, ha üzemeltetési kérdésekkel a PCForum-ot keresnéd fel (konkrét kérdés esetén ott is a Tudástárat).  Üdv!
Nem tudtam pontosan, hova soroljam be, de jó lesz itt. 
Azért nyitottam ezt a témát, hogy megoszthassuk egymással a videokártyák memóriakezelésével kapcsolatos dolgokat, tévhiteket, stb, stb.
Első körben lenne néhány kérdésem.
Az egyik az, hogy lehet-e legalább kb. pontossággal belőni, hogy a betöltött dolgok, pl. textúrák mennyi videomemóriát emésztenek fel, és ha igen, akkor honnan tudom, hogy az pontosan hol is van tárolva?
A baj az, hogy ha jól gondolom, eg.. |
Gyenge a videokartyad, altalaban a BIOSban lehet tobb memoriat allokalni a videokartyanak, de ez nem segit sokat a sebessegen!  |
| Sziasztok! Tudtok olyan programot, amivel a rendszermemóriából hozzárendelhetek az integrált videókártyához? És/vagy van tippetek, h miért szaggat játékban? A videokártya GMA 3100 ö.:250MB rendszer 64MB +osztott rendszer 186MB Proc. Celeron 3,06GHz 1GBDDR2 800MHz Op. Win7, de XP módban olyan, mint XP-n volt, de ha nagyobb a tömeg a játékban, akkor rettenetesen szaggat... Húztam a procin, de már tömeg nélkül is szaggat. |
| Ne írja meg, ki lett mindkét hozzászólása moderálva és nem véletlenül. Ha egy picit is gondolkodna, akkor rájönne, hogy rossz helyen próbálkozik a kérdés felvetésével. |
| Matoman: írd meg újra! |
Miért tűnik el a hozzászólásom? 2008.04.01.-én 17:04-kor.
|
| up |
Pont ezt nem értem, amit ír, hogy miért annyival nő meg.
Ha 2X-es msaa van, akkor a num_samples == 2, pedig nem 4-nek kéne lennie?
A másik meg az, hogy ha 0, akkor csak a 2 alap bufferrel számol, se z-, se stencil-. Ha 1, akkor van 1 z-, és 1 stencil-, de akkor meg minek +1 front buffer? |
| Nem ertem a kerdest. A doc egyertelmuen azt mondja, hogy msaa eseten a videomemoriaigeny megno a num_samples * (sizeof(Front_buffer) +sizeof(ZS_buffer)) mertekkel... Szerintem ez eleg egyertelmu. |
Köszi!
És tudnál valamit hozzáfűzni az élsimításos dologhoz? |
Én sem értek hozzá, de elvileg úgy van, hogy az MSAA egy élsimítási módszer, MultiSampling AntiAliasing.
Elvileg úgy van, hogy nagyobb bufferbe rajzol, és ez kell is, mert a következő objektumhoz kell az előző objektum eredményének subpixeles szín/mélység adatai, hogy helyes legyen, és a végén átlagol elvileg... vagy már nem tudom. Olvastam leírást, de összezavarodok, mert van másik módszer, a Supersampling, elvileg az is ilyen, de nem értem hogy akkora miben különböznek egészen pontosan. A multisampling gyorsabb, mint a supersampling. |
nagyon nem értek hozzá, de nem úgy van hogy az aa (amúgy mit takar az msaa) csakmagának számolgat több pixelen, és a végeredmény egy pixel lesz csupán? vagy valóban megsokszorozódik a látszólagos felbontás?nem hinném, csak tipp...
:paw: |
Ez nem ilyen egyszeru. Nincs garancia ra, hogy egy 4 pixel szeles textura 4 pixelnyi teruletet foglal el - altalaban 1024 byte hosszu egy pixelsor, es a kovetkezo cimet a pitch-vel tudhattad meg, (d3dlocked_rect), ha lockolod a texturat.
Raadasul a driver bizonyos dolgokat kulonfele helyekre rakhat a tipustol fuggoen (pl. a vertexbuffer ha statikus local vram-ba megy, ha dinamikus, akkor az graphics aperture teruletre (e.g. AGP/PCIe memoria)
Magyarul egy byte nem biztos, hogy egy byte-ot foglal a videokartyan. |
Üdv!
Felélesztem a topicot, hátha valaki tud még valami jót hozzáfűzni.
Újabb kérdésem lenne, konkrétan az, hogy van egy élsimításos technika, a multisampling.
Az olvasottak alapján úgy tudom, hogy ha 2X-es MSAA van, akkor az azt jelenti, hogy 1 pixelhez 4 subpixel tartozik, és minden egyes subpixelhez külön sample buffer, azaz 4 sample buffer lesz, az most mindegy, hogy külön-külön vagy összefésülve. Ekkor 4x annyi memória kéne, nem? Tehát én úgy gondolom, hogy ha MSAA nélkül a framebuffer áll szélesség*magasság*(színmélység+z mélység+stencil mélység)-nyi memóriából, akkor 2X-es MSAA-hoz 4X akkora framebuffer kell, nem? Hisz 1 pixelhez 4 subpixel... javítsatok ki, ha tévedek.
Van egy 2002-es GDC-konferenciás pdf, feltöltöttem, abban az 5. oldalon az van írva, hogy:
Vid_mem = sizeof(Front_buffer) + sizeof(Back_buffer) + num_samples * (sizeof(Front_buffer) +sizeof(ZS_buffer))
Akkor ezek szerint nem értem, mert ez 2X-es MSAA esetén 2x veszi a buffereket... |
Hi!
Azt, hogy mennyi videomemória van legegyszerűbben a DX felületen lehet elérni, lásd. DXdiag (még nem tudom hogyan, ha ezt elolvasom és ...).
A videomemóriában elhelyezett textúrákkal több gond is van. Mindig bent kell lenniük vagy cserebere alapon ekkor viszont a főmemóriába pihennek. Mindkettő helyzet problémás, de a legproblémásabb a shared memória )pl. laptopokon).
p.s.: Gúgli barátom ezt mondta. |
Hmmm... az elméletre azt mondom, hogy jó.
De vajon hogy lehet ezt a gyakorlatba átültetni? Tegyük fel, hogy inicializálásnál meg szeretném tudni a videomemória kb. méretét, mennyi textúra fér el benne. OpenGL-nél van olyan, hogy glAreTexturesResident(), ami meg tudja mondani, hogy adott textúra vagy textúrák benn vannak-e a helyi videomemóriában. Ezzel két probléma is van:
1. - ahány gyártó, annyi GL-implementáció. Olvastam, hogy nem mindenhol van normálisan megcsinálva ez, ahol nincs, ott mindig azt mondja, hogy igen, videomemóriában van.
2. - az előző probléma vonzza maga után ezt. Ciklussal addig generálom a buffereket, amíg lesz olyan, ami nem a videomemóriában helyezkedik el. Mivel sosem lesz olyan rossz implementáció esetében, végtelen ciklust kapok. Erre lehetne megoldás, hogy figyelem mennyi az össz, amit eddig létrehoztam, de hol lehet a határ? A 256 MB-os videokártyák is már középkategória. Állítsam le a ciklust 1 gigánál? Lassan már nagyobb vram is lesz... És különben is, lefoglalgatni lépésenként összesen 1 gigát bármilyen gépen is időigényes... |
Üdv!
egy régebbi játékban láttam azt a megoldást a VRAM méret lekérdezéshez, hogy kipróbálta, mennyi fér a memóriába..
kb úgy képzelem, hogy a progi 1MB bufferból hányat tud létrhozni, ha az csak a VRAM-ban lehet, ezt számolja, majd természetesen kiüríti a mem-et. |
| Ja és láttam olyat is, hogy 32 bites buffer, ebből 24 bit z, 8 bit stencil, ez idáig oké, de láttam olyat is, hogy 32 bites zbuffer, ebből 24 bit a z és ennyi. Ezek szerint, ha 32 bites zbuffert csinálok, akkor az ugyanolyan pontosságú lesz, mint a 24 bites, csak gyorsabb lesz, mert könnyebben el tudja érni a "cellákat"? Arra gondolok, hogy úgy használja ki a 32 bites puffert, hogy 1 pixelhez van 24 bitnyi info, aztán 8 bit üres, aztán megint 24 bit köv. pixelhez tartozó adat, aztán megint 8 bit üres, és így tovább... gondolom így gyorsabb a 2^n címszámítással, mintha 24 bitenként kéne "eltolni" a címet? |
Csak hogy folytassam a topicot:
olvasgatva az msdn-en, érdekes dologra bukkantam, számomra ez új, persze más számára ez biztos nem.
Szóval én eddig úgy gondoltam, hogy a zbuffer és a stencil buffer az 2 külön dolog. Ha pl. van egy 16 bites z-buffer és külön stencil buffer, akkor 640x480-nál ez 640x480x2 byte (zbuffer) + 640x480x1 byte (stencil buffer), ami 614400 B + 307200 B = 921600 B = 0.87 MByte.
Viszont egy oldalon láttam, hogy elég sokféle lehet ezeknek a kialakítása is: pl. D3DFMT_D15S1 formátum, ami 16 bites buffer, 15 bit a z-nek és 1 bit a stencilnek. Ez az előző 640x480-as példával számolva: 614400 B = 0.58 MByte. Nagyobb felbontásnál szignifikánsabb eltérések lehetnek.
Kíváncsi lennék, hogy ezeket hogy választhatom ki... ezeket én is előállíthatom OpenGL-nél, ha megfelelően adom meg a PIXELFORMATDESCRIPTOR struktúrának a bitek számát, és biztos lehetek-e benne, hogy úgy lesz, ahogy én mondtam, vagy valami hasonló kialakítást csinál csak? |
Üdv!
Köszi a hosszú választ! Arra is törekedhetek ezzel, hogy pl meg tudjam határozni adott géphez az optimális beállításokat, pl. textúrák mérete, stb... kár, hogy nincs olyan extension, amivel legalább a videomemória méretét le lehetne kérdezni.
Amúgy tervezem, hogy küldeni fogok 1-1 levelet valahova az nvidiának és atinak (meg talán másnak is, pl sis, intel), hogy őszerintük ezek a bizonyos display listek, arrayok, stb. hogy adhatják a legnagyobb teljesítményt, mert sajnos valószínű, hogy eltérő gyártóként, és nincs nálam 5-5 nvidia-ati kártya, hogy mindeggyikkel teszteljek. Főleg, ha még driverenként is változhat a dolog. Amiket leírtál, azokat én is így tudom. De biztos így van -e ez, tehát hallottam olyat is, hogy nem feltétlenül kerül be a vramba a display listes glbegin-glend kirajzolás. Nem tudom már, kinek és mit higgyek el. |
Hi!
Amennyire en sejtem az opengl memoriakezeleset ->
Minden egyes scene kirajzolasanal torekedni kell arra, hogy az ott felhasznalt cuccok a vga ramon belul maradjanak. Ellenkezo esetben az opengle ugyan ugy fog swappolni a system ram es a vga ram kozott a 'viszonylag lassu' buszon, mint a windows a swapfile es a system ram kozott. Ilyenkor van ugye az, hogy 'elfogyott a vga ram'. Viszont hogy ezt felismerd, a legegyszerubb, ha nezed az FPS-s, mert az drasztikusan le fog ilyenkor csokkenni.
A texturak, a gllist-ek, a vertexbuffer-ek, mind fogyasztjak a vga-ramot, de amig azok elfernek ott bent, nem kell aggodni, mert joval nagyobb a vga-ram savszelessege, mint a system ramé vagy a pcie buszé.
Gondolom arra torekszel, hogy minnel nagyobb legyen az FPS adott minosegu grafika mellet.
Ezzel kapcsolatban, amier en rajottem:
- legjobb mar az elejen, ha valami quality beallitassal lehet beallitani a textura minoseget. (es ez alapjan, ha ez nem maximum, akkor nem is toltod be a legnagyobb mipmap-okat, mindezt azert, hogy az opengl-nek veletlenul se kelljen swappolnia)
- a texturak mindig legyenek tomoritve. Gyorsabban masznak fel a vga-ram ba, és még a gpu is gyorsabban tudja oket felhasznalni, mert 1/6, 1/8 annyi memoriaeleres szukseges hozzajuk
- minden, ami lehet es nem valtozik framenkent, legyen gl-list (legalabbis ati x850xt-n ez igy megy, siman alazza a gldrawbuffers-t)
- minnel kevesebb glbegin-glend legyen. szal ha van 10 negyszoged es 10 haromszoged, inkabb rajzolj 30 haromszoget, mint hogy plusz egyszer kilepj a blbegin-end kozul. (Az a mesh optimizacio sajnos ati x850xt-n nem jott be, hogy egy freeformot 10 quad hosszu stripekre bontottam, a sok begin/end miatt belassult es ahogy hallottam, az nvidia sem szereti ezt tulzottan)
(bocs ha hosszu lett XD) |
| up |
Üdv!
Nem tudtam pontosan, hova soroljam be, de jó lesz itt.
Azért nyitottam ezt a témát, hogy megoszthassuk egymással a videokártyák memóriakezelésével kapcsolatos dolgokat, tévhiteket, stb, stb.
Első körben lenne néhány kérdésem.
Az egyik az, hogy lehet-e legalább kb. pontossággal belőni, hogy a betöltött dolgok, pl. textúrák mennyi videomemóriát emésztenek fel, és ha igen, akkor honnan tudom, hogy az pontosan hol is van tárolva?
A baj az, hogy ha jól gondolom, egy textúra alap esetben, szélesség x magasság x komponensek pixelenként x 1 komponens mérete memóriát foglal, tehát ha van egy 256x256-os textúra RGBA-ban, 1-1 byte R-re, G-re, stb..., akkor az foglal 256 kByte-ot. Ha tömörítem, akkor a választott textúra tömörítési metódustól függően foglalhatja ennek a negyedét vagy a nyolcadát. Azt olvastam régebben valahol, hogy elég bonyolult a GPU memóriafoglalása méretek szempontjából, és elvileg ezt nem lehet "csak" így kiszámolni. Vagy ez nem a textúrákra vonatkozik, hanem más dolgokra, pl. geometria, egyebek?
További kérdés, hogy most hogy is van ez az egész fogalomkör: AGP-/PCI-E-memória, textúra memória, és társai. AGP-s kártyák esetén AGP-memória van, PCI-E-s kártyáknál PCI-E memória. Ez csak elnevezésbeli különbség, elvileg mindkettő ugyanaz, tehát a rendszermemóriában a videokártya részére elkülönített terület, amit sajátként használhat, más nem használja a memória azon részét. Természetesen lassabb az elérés, mintha helyi memóriáról beszélnénk, mivel át kell húzni az adatokat az AGP- vagy PCI-E-buszon keresztül. Miért írják, hogy gyors az elérése? Miért gyors, ha rendszermemóriáról beszélünk?
A Direct3D is tudja, mennyi a szabad videomemória, stb. Ő hogy követi ezt? Szintén becsléses számolásokkal vagy valóban le tudja kérdezni a kártyát? OpenGL esetén hogy lehet ezt? Csak nVidia és ATi specifikus dolgokkal?
Ez az egész azért jött, mert szeretném tudni, hogy jól kalkulálok-e és van egy gDEBugger nevű program, amivel OpenGL-es kódot lehet debuggolni. Ha feltelepítem az nVidia instrumented drivert, az bő infókkal tud szolgálni ennek a proginak, és így futás közben láthatom, hogy mennyi a szabad videomemória, stb... Na itt a baj, érdekes értékek jönnek ki.
Inicializálok egy alap OpenGL appot, 640x480-as viewport, ablakos mód, az asztali felbontás 1280x1024, 32 bites a színmélység, 24 bites a zbuffer mélysége, nincs más buffer. Semmit nem töltök be, se textúra, se geometria, semmi, csak ennyi, meg egy bambi. Dupla pufferelés.
Elvileg így néz ki a számítás: front buffer + back buffer + zbuffer = 2xfront buffer + zbuffer = 2x(640x480x4) + 640x480x3 = 2457600 + 921600 = 3379200. A mértékegységet lustaságból hagytam le, természetesen Byte. Tehát a szükséges pufferek összesen 3379200 B = 3.22 MByte-ot foglalnak...
A gDEBugger a következő információkkal szolgál az említett példánál:
AGP/PCI-E usage: 2387968 B = 2.27 MB.
AGP/PCI-E max: 2147352576 B = 2047 MB.
Vidmem total: 268435456 B = 256 MB.
Vidmem (ez lenne a foglalt): 0 B = 0 MB.
Azt nem értem, hogy ha nem annyi adat van tárolva ott, ahol 2.27 MB adat van, mint amennyinek kéne lennie (3.22MB), akkor mi, hol van tárolva és pontosan mi van 2.27 MB-on tárolva? Olvastam, hogy az AGP/PCI-E memóriában lehet a driver kód is. Oké, de akkor hol van a 3.22 MB-om?
Miután egy sok textúrát használó programot is teszteltem, ugyanezeket az értékeket kaptam, tehát rájöhettem, hogy itt a mérőkkel van baj, legalábbis vagy driverrel vagy a progival. De akkor ismertek valami olyan programot, amivel normálisan lehetne mérni a lefoglalt videomemóriát?
Minden kis infomorzsát megköszönnék!
SZERK.: 2 giga memória van a gépben, gondolom ezért annyi a max. AGP/PCI-E memória nálam... na de ez hülyeség lenne, azért az egészet nem foglalhatja le... |
Ez a téma lezárásra került a moderátor által. A lezárás oka: Végtelen örömmel töltene el bennünket, ha üzemeltetési kérdésekkel a PCForum-ot keresnéd fel (konkrét kérdés esetén ott is a Tudástárat). |
