Videogeheugen berekeningen

[Verwijderd]

Hoi,

Ik zat pas te praten met iemand over videogeheugen-gebruik enzo. Nou dacht ik dat ik het wel redelijk door had, maar ben toch gaan twijfelen. Misschien dat jullie kunnen helpen.

Stel, je hebt een FSAA, quad-buffered stereo 1024x1024 display...
Dan heb je, volgens mijn berekeningen,

1024*1024*4*2 (front buffers WxHxBppxStereo ) +
1024*1024*4 (FSAA resolve buffer WxHxBpp) +
1024*1024*4*4*2 (back buffers WxHxBppxAAxStereo) +
1024*1024*4*4 (Z/stencil WxHx4xAA)
= 8Mb + 4Mb + 32Mb + 16Mb
= 60Mb

nodig voor je hele framebuffer enzo, right?

Nou vroeg ik me dus af: Hoe gaat het nou precies als je twee applicaties opstart?
Hebben die dan allebei (er van uitgaande dat het full-screen applicaties zijn) 60MB, dus bij elkaar 120MB video-memory nodig?

Ik dacht altijd dat dat gewoon overlapte en dat die 60MB dus totaal was voor die visual. Maar nu zit ik toch te twijfelen. Iemand die me kan helpen?

[Turkish]

Volgens mij werkt het zo niet hoor. Volgens jou berekening zou dan mijn server met een 4MB grafisch kaartje niet 1280x1024 kunnen draaien en dat doet hij toch wel

Ik dacht dat videogeheugen vooral van belang was om berekeningen op basis van textures etc noodzakelijk was, maar niet om het beeld fysiek op te bouwen

[GarBaGe]

Video memory is wat je NU op je scherm ziet... Dus 2 apps fullscreen is in die context onmogelijk...
Zodra je switcht van app 1 naar app 2, geeft app 1 al het videogeheugen op en wordt dit aan app 2 gegeven...
Dus 60 MB is genoeg...
Ik weet echter niet hoe het zit met texture geheugen, wat meestal onderdeel uitmaakt van je videogeheugen...

[GarBaGe]

Turkish schreef op 12 augustus 2004 @ 14:37:
Volgens mij werkt het zo niet hoor. Volgens jou berekening zou dan mijn server met een 4MB grafisch kaartje niet 1280x1024 kunnen draaien en dat doet hij toch wel

Dat kan wel in pure 2D.
1280x1024 = 1,2 milj pixels
3 bytes per pixel (24-bit) = 3,6 miljoen bytes < 4 MB

Stencil buffer, Z-buffer en FSAA is alleen nuttig/nodig bij 3D, dus ik ga ervan uit dat ie 3D bedoeld

[Verwijderd]

Ja, het gaat inderdaad om 3D apps. En texture geheugen is normaal apart. Bij hedendaagse kaarten met bijv 256MB geheugen heb je vaak 128MB texture-mem en 128MB voor je andere buffers.

Het leek mij ook dat je alleen maar nodig hebt wat je op dit moment ziet op je scherm en niet voor ieder windowtje zeg maar een aparte set buffers nodig hebt. Maar er waren dus wat engineers die mij anders wilden wijs maken. Eens kijken of ik wat kont kan schoppen bij die afdeling daar

[leuk_he]

Wat MIJ verbaast is dat het video geheugen zoveel uitmaakt. Heel dat AGP is toch juist uitgevonden om je video geheugen uit te breiden met systeem geheugen. Blijkbaar werkt die niet echt efficient

[Verwijderd]

Ja, maar in de praktijk wil je toch zoveel mogelijk on-board hebben. Zeker dingen als je display-buffers enzo moeten zo dicht mogelijk bij je DAC zitten om hoge snelheden te kunnen halen

[Sangurash]

leuk_he schreef op 12 augustus 2004 @ 15:11:
Wat MIJ verbaast is dat het video geheugen zoveel uitmaakt. Heel dat AGP is toch juist uitgevonden om je video geheugen uit te breiden met systeem geheugen. Blijkbaar werkt die niet echt efficient

Videogeheugen is ook veel sneller als gewoon geheugen. En je hebt de bottleneck van de verschillende extra bussen die je over moet niet.

Het berekenen van geheugen is vrij eenvoudig iedere pixel is zoveel bit, bijvoorbeeld 32 bit per pixel. Bij 3d en AA kan je het totaal maal het aantal AA doen bijv 4x. Dus 1600X1200 X32 bit X4 AA = 245760000 bit = 30,7 MB per frame op het scherm getoverd. heb je 100 fps wordt er een slordige 3 gigabyte aan data per seconde op het scherm getoverd