"2048 MB framebuffer"

[bukva]

Mohl byste mi prosím někdo vysvětlit, kdo v poslední době zpopularizoval nazývání grafické paměti jako "framebuffer"?
Co já pamatuju, tak framebuffer byla odvždycky část paměti, do které se ukládaly už vyrenderované snímky (obvykle tak 3) a to rozhodně nezabírá víc než pár (desítek) MB i v 3600x1920, určitě ne půl giga nebo víc (navíc kam by se pak ukládaly textury a geometrie, kdyby celou paměť sežral framebuffer?).
Rozhodně to ani není žádný "tradiční název", před pár rokama by o to člověk ani nezakopl.
A já se ptám kdo a proč ...

[Fox_25]

A kde jsi se s tím setkal? FrameBuffer znám ale že by to měla být paměť GK to ne.

Asi je to holt nová doba, to co se dřív ovládalo slušně dnes ovládat nejde protože ovládání je nelogicky zpřeházeno(XP vs 7). Přizpůsobují se tomu všude.

[no-X]

Taky mě překvapilo, když jsem na tenhle způsob označení grafické paměti před pár lety narazil... ono to ale bude mít složitější souvislosti - první je, že od jisté doby může být frame-buffer jak v onboard, tak v systémové paměti. Takže ten termín byl možná zvolen právě proto, aby ho bylo možné používat i pro tahle řešení a obsáhl celou kapacitu paměti, kterou pro tento účel dokáže grafický čip využít (protože v takovém případě může být frame-buffer teoreticky větší než fyzická VRAM).

Co se kapacity týká, pár desítek megabajtů to už dost dlouho není. Vezmi si, že se dnes používá několik frame-bufferů, ty jsou ještě FP16, na ně post-processing, MSAA, takže mohou snadno dost narůst.

příklad...

1920*1200, FP16, MSAA 8x

frame buffer = front buffer + back buffer + z buffer

back buffer = 1920*1200*8*64 = 144MB (to ještě dál násobí počet render-targets - liší se hru od hry)
front buffer = 1920*1200*24 = 7MB (může být víc, pokud hra používá vyšší preciznost - třeba 10 bitů na kanál)
z-buffer = 1920*1200*8*32 = 72MB

To jsme v základu na cca 220-230MB. Pokud hra používá multiple render targets (což je dnes běžné), můžeš se dostat na hodnotu kolem půl giga. To už je ale trochu netypický číslo pro 1920*1200.

Nově ale přibylo eyefinity, které nároky na frame-buffer zvyšuje 3x, případně 6x, takže hodnota kolem 1GB fakt není nereálná.

Pokud jsem nějakou hodnotu opoměl, tak mě klidně opravte, tohle už jsem nepočítal hodně dlouho a poslední roky dost přibývají vlivy, které je třeba započítat

[bukva]

1920*1200, FP16, MSAA 8x

frame buffer = front buffer + back buffer + z buffer

back buffer = 1920*1200*8*64 = 144MB (to ještě dál násobí počet render-targets - liší se hru od hry)
front buffer = 1920*1200*24 = 7MB (může být víc, pokud hra používá vyšší preciznost - třeba 10 bitů na kanál)
z-buffer = 1920*1200*8*32 = 72MB

Tak to moc nechápu, jak byly vytvořeny tyto výsledky.
Front buffer, to je jasný. U zbytku vůbec nechápu čím a proč jsi to násobil.
Ve framebufferu se imho drží pouze "raw" data, který se budou posílat na vykreslení, čili na to hodnota AA vůbec nemá žádný vliv ... a posílat budeš maximálně 8b/kanál (nebo 10b/kanál po DP) a určitě nebudeš posílat z-depth, k čemu by to monitoru bylo?

[no-X]

Monitoru se posílají jen data z front bufferu

Frame buffer je úsek paměti, který se používá k vykreslování obrazu.

potřebuješ tři části:

back-buffer - s tím se pracuje, do toho se vykresluje... jeho kapacita: rozlišení (počet pixelů) x počet bitů na pixel (při FP16 je to 64) x úroveň FSAA (každý vzorek může mít vlastní barevnou hodnotu)

front-buffer - do toho se překlopí obraz z back bufferu (nebo back-bufferů), to už je po AA resolve, HDR efektech atd. a obvykle převedený na Int8 (8 bitů na kanál)... v téhle fázi je to obraz v té podobě, jak ho vidíme na monitoru

z-buffer jsou data o hloubce scény a využívá se jich primárně k určení toho, co je blíž a co je dál (když je vykreslený pixel blíž hráči, než jiný, který je na jeho místě, přepíše se jím - nebo opačně)

[Herkis]

To si ale zapomněl na kompresi. Ta se používá u Z snad už 10 let. A MSAA vzorky se komprimují přímo parádně.

[no-X]

Ale, ale... začátečnická chyba Komprese funguje pouze pro přenosy, šetří BW, nikoli kapacitu paměti. Paměť se alokuje v plném rozsahu, protože nelze předem říct, jakého kompresního poměru bude dosaženo. Při kompresi se vychází z toho, že většina pixelů neleží na rozhraní polygonů a stačí pro ně zapsat jen jeden údaj místo čtyř (při MSAA 4x). Jenže nikdy se předem neví, kolik pixelů skutečně bude na hranách, nebo jestli scéna nebude složena z takového množství polygonů, že jich bude více než vzorků (a výsledná komprese nebude nulová). Z toho důvodu se vždy alokuje plný rozsah.

Výjimkou je CSAA, kdy je použito nižší množství barevných vzorků a adekvátně tomu lze snížit množství alokované paměti.

[Herkis]

Být tebou, tak bych si tak jistý nebyl. Pohrabej se v patentech, najdeš tam sbírku různých metod, jak paměť ušetřit. Obvykle to funguje na principu virtuálního frame bufferu, který odkazuje na bloky komprimovaných nebo nekomprimovaných dat. Tyhle bloky se dynamicky alokují/uvolňují podle potřeby, stará se o to memory managment (HW a ovladač). Tak tě též zdravím, začátečníku!

[bukva]

Zrovna dneska na to u konkurence někdo upozornil: http://www.extrahardware.cz/dva-gigabaj ... o-vabnicka

Tak jako tak (ať se to počítá jakkoliv) je "framebuffer" jen nějakou částí paměti grafické karty (protože ještě někam potřebuju nacpat geometrii a textury, ty asi tak v 99% případů budou zabírat mnohem víc než framebuffer) a není to synonymum pro celkovou paměť karty.

[no-X]

Herkis: Nevím, proč bych si neměl bejt jistej. Pokud mi nevěříš, je na tobě, aby sis zjistil, jestli mám nebo nemám pravdu. Zeptej se někoho, kdo pracuje/pracoval u ATi nebo nVidie, po fórech se takových lidí pohybuje poměrně dost a pokud je slušně požádáš, rádi ti to vysvětlí

Back-buffer se alokuje vždycky v plné velikosti. A právě proto se pro vyšší režimy AA v současné době nepoužívá MSAA, byť by to bylo nejsnazší, ale metody, které nezvyšují počet barevných vzorků na pixel (CSAA, filtry), aby nároky na paměť tak extrémně nenarůstaly.

Kdyby to fungovalo, jak tvrdíš, neznamenalo by zapnutí MSAA prakticky žádné zvýšení nároků na paměť, protože hrany polygonů v běžných hrách pokrývají pouze 5-10% plochy, což by po kompresi navyšovalo nároky na paměť na úrovni jednotek procent... Ale takhle to nefunguje

[Ssnake]

... v téhle fázi je to obraz v té podobě, jak ho vidíme na monitoru

nebylo u 3dfx karet jeste neco co tenhle obraz upravovalo jeste pred presunutim na monitor? nejsem si jisty, ale nekde jsem cetl ze "printscreen" na 3dfx ulozi jiny obraz nez jaky vidime na monitoru, protoze ho bere prave z framebufferu pred nekterymi efekty, ktere se pridaji az primo na vystupu a nikde se neukladaji (kdo jiny by to tady mohl vedet...)

[Herkis]

Zeptej se někoho, kdo pracuje/pracoval u ATi nebo nVidie, po fórech se takových lidí pohybuje poměrně dost a pokud je slušně požádáš, rádi ti to vysvětlí

Čím si starší, tím si naivnější. Já se taky pohybuju po forech, kdyby se mě někdo zeptal na něco, co souvisí s mou prací, tak mu též odpovím něco jiného.
Je úplně jedno, jakou porci frame bufferu si alokuješ - je to virtuální frame buffer, jakou část fyzické paměti to zabere - o to se stará memory managment.

Edit: A nemusím se ani nikoho ptát. Ty se ptáš na každou věc? - Zkus použít mozkové závity: Když už ty buffery komprimuješ kvůli rychlosti přenosu, je škoda neušetřit při tom paměť. Jak ji můžeš ušetřit, ti napoví různé patenty. Komprimované vzorky stejně nemůžeš načítat přímo, ale musíš přes převodní tabulku s odkazy - virtuální framebuffer. Chceš nepřímý důkaz? Nezamyslel si se někdy nad tím, proč některá nová verze ovladače přinese navýšení výkonu nebo odstranění propadu fps při vyšších rozlišeních a větších AA obecně nebo pro některé konkrétní hry? Je to většinou tím, že vývojáři optimalizovali memory managment (MM), příp. přidali profily pro některé hry, které ovlivňují práci MM. Laicky řečeno: Když budu vědět, že např. v dotyčné hře nebudou komprimované vzorky zabírat více než xx MB fyzické paměti, je zbytečné, aby MM na ně vyhradil větší fyzickou paměť.
Na tyhle optimalizace mají vývojáři své recepty a pochybuji, že je budou poskytovat kdekomu na fóru, ale jestli chceš a nevěříš tomu, co jsem napsal, zkus to.

Edit2: Hele, no-X, ty si kdysi dávno psal, že 3dfx podporuje ztrátovou kompresi frame bufferu, tak proč se teď tomu tak vehementně bráníš?

[no-X]

Ssnake: jj, ale to je trochu jiná věc... 3Dfx renderovalo interně 24-bitově, ale frame-buffer byl 16-bitový. Takže se provedl dithering 24->16bit (čímž se šetřila kapacita paměti a propustnost sběrnice) a před zobrazením RAMDAC provedl jednoduchou filtraci v rámci matice 4x1 nebo 2x2. Pokud měly všechny 4 pixely barvu posunutou o jedenu hodnotu 16bit palety, bylo jasné, že je to výsledek ditheringu a filtrace byla provedna (pokud byly rozdílné, bylo jasné , že je to kresba v textuře nebo hrana a filtrace se neprováděla). Výsledkem byl 22bit výstup. Z hlediska frame-bufferu šlo o standardní 16bit - vše ostatní probíhalo na úrovni grafického čipu a RAMDACu.

Je úplně jedno, jakou porci frame bufferu si alokuješ - je to virtuální frame buffer, jakou část fyzické paměti to zabere - o to se stará memory managment.

Máš dost špatnou představu o tom, jak to funguje, cizí názor ignoruješ, u jiného zdroje si to ověřit nechceš... To pak veškerá diskuse postrádá smysl. Přestaň alespoń svůj špatný názor prezentovat jako holý fakt a něco si o tom zjisti. Protože takhle akorát šíříš mezi lidi dezinformace.

Uvědom si, že kdyby to fungovalo, jak si představuješ, nebude mít MSAA prakticky žádné požadavky na paměť. A právě, protože to neufnguje, jak píšeš, nVidia přišla s CSAA, připadně Matrox před lety s FAA.

[Herkis]

A můžeš mi tedy popsat, jak budeš adresovat komprimované vzorky ve fyzické paměti bez alokační tabulky a tedy bez virtuálního framebufferu, když tu komprimaci provádí HW nezávisle na aplikaci?

Ta tvoje argumentace je taky mimo, nikde jsem netvrdil, že MSAA nebude mít (prakticky) žádné požadavky na paměť, to tvrdíš pouze ty!
Psal jsem jen, že je možné paměť ušetřit díky komprimaci framebufferu a jak se to dá udělat ti napovědí patenty. Začni třeba tím od Microsoftu, co je cca 10 let starý.
Podívej se také, jaký je rozdíl mezi HD5870 s 1GB a se 2 GB paměti. Kdyby to bylo, jak píšeš, byl by ten rozdíl v rozlišení 25x16 (4x nebo 8x MSAA) mnohem výraznější než téměř nulový. Ten malý rozdíl u většiny her je způsoben jen častější dynamickou realokací u karty s menší pamětí - dochází pak k většímu propadu fps (nižší min. fps).

[Harun]

akoze hrat sa na machrov a pritom byt nasmiech je vazne dnes asi u urcitej vzorky ludi na fore in ) to ze slovko virtual frame buffer existuje ti nedava pravo si ho predefinovat na lubovolny vlastny blud. Tak aby som radsej uviedol herkisove mystifikacie na pravu mieru, virtual frame buffer nema co docinenia s grafickou kartou praveze je to uplne naopak, virtual FB je otazka operacneho systemu presnejsie sa to tyka unixovych systemov a pristupu na konzolu cez seriovy port(pocitac bez grafickej karty). Kedze tam nieje grafika karta, tak tam nieje ani framebuffer a monitor by nevedel co zobrazovat. OS alokuje urcite miesto na ramke a pouzije ju ako virtualny FB, cez ktory sa posielaju data na seriovy port a monitor ich zobrazi. A z toho vypliva aj komprimacia dat vo FB, to je totalny blud, co by monitor robil s komprimovanymi datami vo FB? ma v sebe nejake dekomprimacne algoritmy? funguje nam 30 rocny monitor splnajuci VGA standard na lubovolnej sucasnej grafike(s prislusnou redukciou)? snad nema v sebe vestecku gulu, aby vedel odhadnut vsetky sucasne pokrocile komprimacne metody..... proste vo FB ako uz povedal no-x je ulozena cisto bitova mapa obrazu*farebna hlbka, ktory ma zobrazit na monitore a nic ine tam z logickych pricin ani byt nemoze, kedze by sa nam na monitore pravdepodobne zobrazovali bludy, keby tam nebol ulozeny ocakavany vystup.

[Herkis]

Myslím, že ty zrovna nejsi odborník, který dokáže posoudit, co je správné a co jsou bludy. Pokud tě zajímá, jaký jiný virtual frame buffer může existovat než ten jediný, který ty znáš, podívej se sem:
http://www.patentstorm.us/patents/6366289.html.
Zrovna v tomto patentu je uveden význam a funkce virtual frame bufferu, který bohužel pro tebe, "skutečného odborníka na UNIX", nemá se sériovým portem a konzolí nic moc společného, ale kupodivu má něco společného s tímto tématem.

Že jsou některá data ve fyzické paměti komprimována, to tady samozřejmě nepopírá ani no-X. Říká ti něco např. komprese Z-bufferu?

Napsal si tu hezké bludy a no-X ti pravděpodobně poděkuje za to, že mu tady tak "odborným" způsobem pomáháš prosadit jeho názor.

Edit:
Napsal jsem to příliš zkráceně. Ta tvoje představa, že monitor je schopen přímo číst paměť na grafické kartě je úplně špatná. Komprimace a dekomprimace paměti je samozřejmě záležitost GPU, GPU (to je čip - grafický procesor - na grafické kartě) též obsahuje výstupy (analogové, digitální, podle různých standardů), na které se dá připojit zobrazovací zařízení. Je vidět, že tuto problematiku nechápeš.

Tvoje představa, že frame buffer obsahuje pouze bitmapu, která se zobrazuje, a nic jiného, svědčí o tom, že si předchozí příspěvky (všechny i ty no-Xovi) vůbec nečetl.

Z toho důvodu tvé nařčení, že tu píšu bludy a mystifikuji je úplně mimo a porušuje pravidla fora. Doporučuji ti k příspěvku přidat omluvu.

[Herkis]

no-X: Zatím tady jenom tvrdíš, že můj názor je špatný, ale nic, co by podpořilo tvé tvrzení si nedodal (jenom se tě zastal někdo, kdo tomu evidentně nerozumí ).

Abys měl nějakou duševní stravu, mám tu pro tebe jeden patent ještě od bývalé ATI, který se dá velmi jednoduše použít pro úsporu framebufferu (možná se to použilo už na R600). Původně byl pravděpodobně zamýšlen pro R500 a EDRAM. EDRAM totiž není dost velká na to, aby pojala i nekomprimované AA vzorky.

http://patft.uspto.gov/netacgi/nph-Pars ... er=6614449

[no-X]

no-X: Zatím tady jenom tvrdíš, že můj názor je špatný, ale nic, co by podpořilo tvé tvrzení si nedodal (jenom se tě zastal někdo, kdo tomu evidentně nerozumí ).

Vidím, že se dobře bavíš.

Jistě nám zvládneš vysvětlit, proč zvýšení úrovně MSAA často znamená propad výkonu na kartách s 512-768MB paměti.

předpokládejme, že hrany v dané hře pokrývají 10% pixelů
předpokládejme rozlišení 1920*1080
standardní 32-bit frame/z-buffer = 15,8MB
+ MSAA 4x = 63,3MB (bez započtené komprese)
+ MSAA 8x = 126,6MB (bez započtené komprese)

Ty tvrdíš, že se skutečný požadavek na kapacitu paměti zvýší přesně o objem zkomprimovaných dat. Můžeme si to přibližně spočítat. Pro pixely, které nejsou na hranách, by byl požadavek na paměť stejný, protože komprese funguje 100% efektivně.

Zapnutím MSAA 8x tedy zvýší objem pouze u těch zbývajících 10%. Tam je dosažitelná z-komprese 16:1, barevná (tuším) 4:1. Takže pro těchto 10% obrazu by zapnutím MSAA 8x vzrost objem Z dat o 0,4MB (6,33MB nekomprimovaně) a barevných dat o 1,6MB (6,33MB nekomprimovaně).

Jinak řečeno, zapnutím MSAA 8x při rozlišení 1920*1080 se podle tvé teorie zvýší požadavek na paměť o 2MB. To je celkem zanedbatelná hodnota, která se v nějakých 512 nebo 768MB úplně ztratí. Jak je teda možné, že to v praxi způsobuje tak velké propady výkonu?

Až tohle vysvětlíš, budu se s tebou klidně dál bavit o tvé zvláštní teorii.