Nyt kun on tullut näitä useampia huhuja melko kapeista muistiväylistä ja suurista kakuista, niin vähän mietintää asiaan liittyen:
Zen2-CCD-piiriltä (n. 74mm^2) voidaan laskea, että 1 MiB L3-kakkua TAGeineen vie n. 1mm^2 tilaa TSMCn "7nm" prosessilla.
Eli 128 megaa kakkua veisi piiriltä tilaa n. 128mm^2.
Suurin osa raskaasta kaistasta kuluu framepuskuriliikenteeseen z- ja back-puskuriin sekä mahdolliseen kolmio-id-puskuriin jos tehdään deferred-rendausta.
Joten millainen kakku riittäisi (pelkästään) niiden kakuttamiseen? Jos sitten tekstruureille olisi omat kakkunsa tämän lisäksi?
4k-framepuskuri koostuu 8100 kibipikselistä, eli aivan karvan verran alle 8 mebipikseliä.
2560x1440 koostuu 3600 kibipikselistä, eli karvan verran yli 3.5 mebipikseliä.
Jokaisesta pikselistä tyypillisesti tallennetaan:
1) z-arvo (yleensä 32 bittiä eli 4 tavua)
2) backpuskuriin g,r,b-väriarvot sekä alpha-kanava (nykyään usein 16bittisiä kaikki?) eli yhteensä 64 bittiä, 8 tavua.
Eli ilman mitään FSAAta tarvitaan 12 tavua/pikseli eli 4k-resoon 96 mebitavua, 1440p-resoon reilut 42 mebitavua.
Toisaalta, usein nykyään tehdään jotain deferred renderingiä jossa ekalla passilla vaan lasketaan mikä kolmio ruudulle jää päällimmäiseksi, ja sitä varten on joku oma puskurinsa jossa on yksi (todennäköisesti) 32-bittinen identifier/pikseli. Eli tämän kanssa 4k olisi 16 tavua/pikseli, juuri alle 128 mebitavua, 1440p olisi sitten reilut 56 mebitavua.
Eli, asenteella "FSAAta ei enää käytetä koska AA tehdään nykyään jollain reunoja tunnistavalla AA-mekanismilla ja MSAA ei muutenkaan toimi järkevästi deferred-rendauksen kanssa ja SSAA on liian hidas anyway" 128 megaa riittäisi juuri 4k-reson kaikille paljon kaistaa vaativille puskureille, ja 64 megaa gelposti 1440p-reson kaikille paljonkaistaa tarvitseville puskureille.
Toisaalta, en tunne tarkemmin niitä mekanismeja, joilla nämä reunantunnistus-AAt toimii, tarviiko ne omia (koko ruudun) puskureita? Vai voiko ne tehdä joku pieni blokki kerrallaan?
2xFSAA sitten heti tuplaisi framepuskuri-muistin tarpeen, 4xFSAA nelinkertaistaisi.
Toisaalta, silloin kun tehdään deferred rederöintiä, itse backpuskurinkin voisi ehkä jättää piirin omalta muistilta pois, koska sinne lähinnä vaan kirjoitetaan siinä toisessa passissa. Jolloin 2xSSAA:llakin 4k-resolla 128 megaan mahtuisi kaistakriittisimmät puskurit (z-puskuri ja kolmio-identifier-puskuri).
Välimuistin sisällön voisi tietysti yrittää pakata, mutta se on siitä ongelmallista, että häviöttömään pakkaukseen ei voi luottaa että pakkaus onnistuu niin hyvin kuin halutaan (joten pitää olla mekanismi tämän hanskaamiseen), ja toisaalta häviöllinen teoriassa huonontaa kuvanlaatua, ja häviöllistä ei voi käyttää kuin kuvadatalle, piirin/ajurin pitäisi tietää mistä datasta on kyse että saako sitä pakata häviöllisellä pakkauksella.
Ruudun voi toki jakaa useampaan tiileen ja rendata ne kerrallaan, mutta tämä moninkertaistaa työmäärää geometriapuoleen ja kolmioiden alustukseen liittyen, ja/tai tarkoittaa, että rasteroidessakin geometriadata pitäisi tallettaa itse piirin muistiin.
Mutta ehkä esim. 128 MiB kakku "big naville" ja 64 MiB kakku 6700:lle voisi olla ihan mahdollinen, ja mahdollistaa kapeamman muistikaistan järkevästi ja hyvällä suorituskyvyllä. Sellainen vaikutus tällä voisi olla, että 6700n suorituskyky voisi romahtaa muita piirejä enemmän 4k-resolla kun kakku alkaisi loppua kesken ja muistiaccessien määrä kasvaisi suuresti, ja samoin FSAAn(MSAA tai SSAA) kytkeminen päälle voisi kaikilla perheen piireillä sattua suurilla resoilla vielä normaalia enemmän kun tämä saisi kakun loppumaan kesken.
Se, että backpuskuri olisi usein piirin ulkopuolisemmassa "hitaassa" muistissa mutta z-puskuri taas nopeassa sisäisessä muistissa myös osaltaan selittäisi sitä, että render-backendejä on suhteessa vähemmän, JOS jokainen render-backend tekee saman määrän täysiä värioperaatioita alpha blendingin kera, mutta esim. tuplamäärän z-operaatioita ja (vain) 32-bittisiä kirjoituksia ilman mitään alpha-blendausta kuin aiemmin.
