AMD-spekulaatioketju (RDNA:n ja CDNA:n tulevat sukupolvet)

Ja ilmeisesti nvidialla itsellään ei ole täyttä luottoa noihin muisteihin kun ilmeisesti quatroihin on tulossa tavallista GDDR6 muistia. Riittävän hyvää harrastekortteihin, mutta ei tarpeeksi luotettavaa taikka testattua ammattikortteihin.
Sehän on puhtaasti sen takia, että Quadrossa sitä tulee olemaan 48GB. Ei mahdollista GDDR6X:llä vielä.
 
Ainakin tyypin tweetit mitä tuosta näin sanoivat, että rajatonta korttitulvaa ei ole tulossa vaikka osa lukijoista näin tulkitsikin aiemman twiitin. Ja jos se ei ole rajaton, niin se on selvästi rajallinen. Tosin kukaan ei tiedä niitä rajoja etukäteen AMD:n lisäksi. Määrä on joko suuri, pieni tai jotain siltä väliltä.
Tuskin riittävä kuitenkaan. Mielenkiintoiseksi menee, onneksi ei ole tarvetta saada heti. Katsotaan tarjonta loppuun asti. Toivottavasti näitä tulee muilta valmistajilta omilla tarroilla varustettuna niin voi blokin laittaa.
 
Sehän on puhtaasti sen takia, että Quadrossa sitä tulee olemaan 48GB. Ei mahdollista GDDR6X:llä vielä.

Niin sehän riippuu siitä milloin se quatro on ajateltu tuoda markkinoilla kun micron on tainnu ilmoittaa että 16Gb lastut tulee ens vuoden alussa. Nyt varmaan kerätään piirejä vielä joku kuukausi varastoon quatrojen julkaisua varten ja roskat myydään leikattuna 3080 muodossa pois.
 
Ainakin tyypin tweetit mitä tuosta näin sanoivat, että rajatonta korttitulvaa ei ole tulossa vaikka osa lukijoista näin tulkitsikin aiemman twiitin. Ja jos se ei ole rajaton, niin se on selvästi rajallinen. Tosin kukaan ei tiedä niitä rajoja etukäteen AMD:n lisäksi. Määrä on joko suuri, pieni tai jotain siltä väliltä.

Gamers nexusessa oli hyvää juttua pari kuukautta sitten miten AMD: radeon porukka yrittää kampittaa julkaisuja, epäselvillä illmoituksilla=) tässä on mielestäni hyvä esimerkki, olisi vaan "olen Cool ja mystinen ja pähee" twiittauksen sijaan sanonut mitä oikeesti tarkoitti.
 
Gamers nexusessa oli hyvää juttua pari kuukautta sitten miten AMD: radeon porukka yrittää kampittaa julkaisuja, epäselvillä illmoituksilla=) tässä on mielestäni hyvä esimerkki, olisi vaan "olen Cool ja mystinen ja pähee" twiittauksen sijaan sanonut mitä oikeesti tarkoitti.
Eipä tarvitse enää kampittaa mitään, se on jo hoidettu. Tuo vaan niitä omia kortteja saataville riittävästi.
 
AMD:n pomojen twiittailu on kyllä huvittavaa. Ei paljoa enempää voisi sahata omaa oksaa kuin antamalla pieniä vihjauksia jotka ei välttämättä pidä edes paikkaansa. Pitäis kyl AMD:llä olla joku viestintä osasto jonka läpi nuo twiitit menee.
Kovat on odotukset AMD:n korteilta, toivotaan että pitää paikkansa ja vähän suurempi osuus kortin haluavista saa omansa verrattuna nvidian julkaisuun.
 
Itse taas pidän tästä nykyisestä tavasta paljon enemmän kuin vanhasta. Teaserit yms. toteutetaan kuvalla ja pelin sisällä voi malleja mennä ihmettelemään jos haluaa. Tämä muu Twitter pöhinä ja erilaiset vuodot sitten taas ovat sellaista tavaraa joka vähän tulee nykymaailman mukana.

Mitä faktoihin tulee niin tuskin Frankilla? (AMD:n heppu) tuskin on lupa sanoa asioita joiden todenperää ei pysty takaamaan tai mihin ei ole saanut lupaa. Ja mitä PC Worldin haastiksesta aiemmin on voinut päätellä niin hän on hardikseen rakastunut heppu vaikka markkinapäällikkö? tms. onkin, niin totta kai pahimpia pelkoja voi hälventää (Radeon VII) saatavuuden osalta vaikka tarkkoja lukuja ei olekaan antaa.

Parempi tämä nykyinen on kuin se vanha jossa luvattiin enemmän kuin pystyttiin toteuttamaan.

Meillä on kuitenkin päivä jolloin kortti nähdään, joten sillä mennään.
 
Parempi tämä nykyinen on kuin se vanha jossa luvattiin enemmän kuin pystyttiin toteuttamaan.

Meillä on kuitenkin päivä jolloin kortti nähdään, joten sillä mennään.

Niin no sitä pystytään sitten arvioimaan vasta jälkikäteen. Mutta vaikea minun on uskoa, että JOS AMD pystyy tekemään jytkyn kortin, niin hekään pystyisi yhtään paremmin vastaamaan massiiviseen kysyntään, vaikka Nvidia on jo pahinta kysyntäpiikkiä tasoittanut.

Kyllä noissa Frankin puheissa minusta selkeästi luvataan, että tavaraa olisi paremmin kuin Nvidian julkaisussa. Vai mistä se muka löi vetoa. Mutta se tavaran riittäminenhän riippuu ihan kysynnän määrästä. Se taas riippuu perf ja hinta/perf toteutumasta. Jos nyt tulisi maagisesti 3070 tasoinen kortti 400 eurolla, 3080 tasoinen 600 eurolla tai 3090 tasoinen kortti tonnilla, niin ei helvetissä AMD pystyisi sen paremmin kysyntää täyttämään ellei koneet ole piirejä tässä jo paria kuukautta jauhaneet. Eli strategisesti AMD:n kannattaisi hinnoitella suunnilleen samalle hinta/perf tasolle tai jopa vähän huonommalle, jos ei kortteja ole paljon varastossa.
 
Kyllä noissa Frankin puheissa minusta selkeästi luvataan, että tavaraa olisi paremmin kuin Nvidian julkaisussa. Vai mistä se muka löi vetoa. Mutta se tavaran riittäminenhän riippuu ihan kysynnän määrästä. Se taas riippuu perf ja hinta/perf toteutumasta.

Sehän lupasi, ettei kyseessä ole paperijulkaisu. Gamersnexus yms selvittelivät 3080:aa, jälleenmyyjät ilmoitti saaneensa about normaalin julkaisuerän. Covidin takia kysyntä on ollut normaalia kovempaa koko vuoden ja botit viimeistelivät tuhon. Eli ei sekään ollut paperijulkaisu, vaikka kortteja ei saa oikein mistään. Paperijulkaisuhan on sitä, että julkaistaan kortti ja arvostelijoita lukuunottamatta kukaan ei näe koko rautaa.

Edit: tarkemmin luettuna se joku käyttäjä väittää 3080:n olleen paperijulkaisu ja AMD tekevän samanlaisen, johon Frank näpäyttää takaisin. Eli sen perusteella saatavuus olisi parempi, mutta 3080 ei edelleenkään surkeasta saatavuudesta huolimatta ollut paperijulkaisu.
 
Sehän lupasi, ettei kyseessä ole paperijulkaisu. Gamersnexus yms selvittelivät 3080:aa, jälleenmyyjät ilmoitti saaneensa about normaalin julkaisuerän. Covidin takia kysyntä on ollut normaalia kovempaa koko vuoden ja botit viimeistelivät tuhon. Eli ei sekään ollut paperijulkaisu, vaikka kortteja ei saa oikein mistään. Paperijulkaisuhan on sitä, että julkaistaan kortti ja arvostelijoita lukuunottamatta kukaan ei näe koko rautaa.

Edit: tarkemmin luettuna se joku käyttäjä väittää 3080:n olleen paperijulkaisu ja AMD tekevän samanlaisen, johon Frank näpäyttää takaisin. Eli sen perusteella saatavuus olisi parempi, mutta 3080 ei edelleenkään surkeasta saatavuudesta huolimatta ollut paperijulkaisu.

Veikkaan osittain "paperijulkaisukommenttien" liittyvän tähän nvidian omaan sivuston malliin. Niitähän jälleenmyyjät ei myy yhtään.
Kun ei kuulemma edes botteja käyttäneet saaneet tilausta lyötyä sisään nvidian omilta sivuilta, kuten esim. se wendell tech youtubesta.
Myönsi käyttäneensä ostobotteja jo useammin, että saisi oman tuotteen reviewiin asti (ei kuitenkaan siis trokaukseen). 3080:n kohdalla ei kuulemma onnistunut sekään.

Toki miksi nvidia sitä omaa malliaan haluisikaan niin järkyttävästi valmistaa, kun paremmat katteet saadaan AIB:n korteilla, kun se nvidian oma malli maksaa jäähyn valmistuksen osalta vissiin aika paljon.

Selkeästi kuitenkin rushattu launchi nvidian puolelta, ehkä pelko juuri AMD:n vastinetta kohtaan.
Pitää vaan toivoa, ettei tuon kohdalta saatavuussirkus sitten jatku myös AMD:n puolella, vaan että useampaa mallia voisi saada jo samalla julkaisupäivällä.

Mikäs sen pahempaa kun joulumarkkinoilla molempien tuotteet myy ei-oota sitten jos pitäisi korttia saada. Saati sitten uusien konsolien saatavuus samaan aikaan.
 
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.
 
Viimeksi muokattu:
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?
Käsittääkseni voi tehdä myös blokki kerrallaan, mutta koska z-puskurista löydetyt reunat voidaan tallentaa omana esim. 1-2 bittisenä framepuskurina, niin ei se vie tilaa kovin merkittäviä määriä.
 
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?

Nvidia ainakin jakaa geometriaa pienempiin tiiliin ja piirtää tiilet käyttäen piirin sisäistä muistia, jolloin säästyy muistikaistaa: Tile-based Rasterization in Nvidia GPUs Nvidia on myöhemmin vahvistanut tuon sisäisen muistin ja tiilien käytön, mutta en muista missä yhteydessä. Google on aika tyhjä arpa, olisikohan ollut jossain gdc/siggraph youtube videossa tms.

Jos en väärin muista niin amd toteutti samankaltaisen tiilissä piirron naviin.

Isoakin isompi sisäinen muisti auttaisi tiilien kanssa vaikka sinne ei kaikki mahtuisikaan kerralla.

Post prosessoinnit ryynättäneen läpi g-buffer+z-buffer+,... rakenteet läpikäymällä. Hyvän idean tästä saanee, kun katsoo alla olvan nvidian dlss presentaation. Vaikka esitys on dlss spesifinen niin siitä saa melko hyvän kuvan siitä miten moderni peliengine piirtää ja post prosessoi pikseleitä.



edit. Muistin väärin, tuli vegassa tiilitetty renderöinti: The curtain comes up on AMD's Vega architecture - The Tech Report
AMD is significantly overhauling Vega’s pixel-shading approach, as well. The next-generation pixel engine on Vega incorporates what AMD calls a “draw-stream binning rasterizer,” or DSBR from here on out. The company describes this rasterizer as an essentially tile-based approach to rendering that lets the GPU more efficiently shade pixels, especially those with extremely complex depth buffers. The fundamental idea of this rasterizer is to perform a fetch for overlapping primitives only once, and to shade those primitives only once. This approach is claimed to both improve performance and save power, and the company says it’s especially well-suited to performing deferred rendering
 
Viimeksi muokattu:
Käsittääkseni voi tehdä myös blokki kerrallaan, mutta koska z-puskurista löydetyt reunat voidaan tallentaa omana esim. 1-2 bittisenä framepuskurina, niin ei se vie tilaa kovin merkittäviä määriä.

Kutalan kirjoitus oli kyllä hyvä. Itseä vain mietityttää miksi? Voiko tuo olla nopeampi ratkaisu, mitä perinteinen leveä väylä?

Jos tuo cache veisi sen 128mm^2, niin se olisi noin puolet 5700XT:n pinta-alasta. Siitä piirikuvaa käyttämällä ja nopeasti silmämääräisesti vilkaisten (eli suht iso virhemarginaali) noin 1/7 meni muistiohjaimiin ja gddr6 phy osiin. Eli cache lisää paljon enemmän piirin valmistuskustannuksia, mitä muistiohjaimet. Muistiohjaimet toisaalta nostavat PCB:n hintaa ja muistimodulien määrä nyt vaihtelee konffin mukaan. Maalikkona silti kuvittelisi tuon cachen olevan se kokonaisuutena kalliimpi ratkaisu.

Apu:t voi kyllä hyödyntää tuota tekniikkaa jatkossa ja siten vallata markkinoita kannettavilta, siinä suhteessa olisi kyllä liiketoiminnan kannalta yksi peruste ajaa tekniikkaa eteenpäin.
 
Kutalan kirjoitus oli kyllä hyvä. Itseä vain mietityttää miksi? Voiko tuo olla nopeampi ratkaisu, mitä perinteinen leveä väylä?

Jos tuo cache veisi sen 128mm^2, niin se olisi noin puolet 5700XT:n pinta-alasta. Siitä piirikuvaa käyttämällä ja nopeasti silmämääräisesti vilkaisten (eli suht iso virhemarginaali) noin 1/7 meni muistiohjaimiin ja gddr6 phy osiin. Eli cache lisää paljon enemmän piirin valmistuskustannuksia, mitä muistiohjaimet. Muistiohjaimet toisaalta nostavat PCB:n hintaa ja muistimodulien määrä nyt vaihtelee konffin mukaan. Maalikkona silti kuvittelisi tuon cachen olevan se kokonaisuutena kalliimpi ratkaisu.

Apu:t voi kyllä hyödyntää tuota tekniikkaa jatkossa ja siten vallata markkinoita kannettavilta, siinä suhteessa olisi kyllä liiketoiminnan kannalta yksi peruste ajaa tekniikkaa eteenpäin.
Kukaan ei taida tietää vastausta tuohon, ellei pääse simuloimaan noita näyttisten muistihakuja järjellisellä tarkkuudella, johon taas löytynee työkalut vain parilta eri firmalta. Jos AMD moiseen on lähtenyt, niin ne varmasti esittelevät teknologiaa ihan kunnolla tossa kuukauden kuluttua.
 
256-bit GDDR6 väylä haukkaa noin 32mm2 joten 512-bit veisi noin 64mm2. Jos toi oletettu kakku tosiaan haukkaa 128mm2 niin aika paljon siinä kyllä siru kasvaa. 256-bit väylä + kakku tekee yhteensä siis noin 160mm2. Jos huhuiltu noin 500mm2 sirun koko pitää paikkaansa niin toi kikotin veisi siis kokonaisuutena kolmanneksen koko piirin pinta-alasta.
1024-bit HBM2 ohjain vie noin 11mm2, eli kahdella ohjaimella se olisi noin 22mm2.

Kuvitellaan että 400mm2 olisi kaiken muun viemä pinta-ala, niin:
256-bit GDDR6 + cache veisi noin 29% piirin ollessa kooltaan noin 560mm2
512-bit GDDR6 veisi noin 14% piirin ollessa kooltaan noin 464mm2
2048-bit HBM2 veisi noin 5% piirin ollessa kooltaan noin 422mm2

Mielestäni aika suurista eroista kyllä kyse niin hiukan ihmettelen että AMD lähtisi moiseen suuntaan arkkitehtuuria kehittämään kun tuohon lisätään se että TSMC:n 5nm prosessilla on pizzapohjien hinta huhujen mukaan nousemassa aika huimasti ja per chip hinta on nousemassa aiemman laskusuunnan sijaan.

Näin maallikkona asiaa ihmetellessä tuntuisi tuohon HBM2 aikaan siirtyminen aika loogiselta ratkaisulta tulevaisuutta ajatellen. Vai onko se piikieken pinta-ala sitten kuitenkin vielä riittävän halpaa että sitä kannattaa polttaa ennemmin kuin alkaa turaamaan interposerin kanssa taikka monimutkaisen levysuunnittelun kanssa jotta 512-bit väylä saataisiin toteutettua?
 
256-bit GDDR6 väylä haukkaa noin 32mm2 joten 512-bit veisi noin 64mm2.

Taitaa 256-bittinen väylä viedä pikemminkin luokkaa 50 mm^2. Kuvassa navi10 (n. 250mm^2).

Navi%2010%20die%20annotation.webp


Jos toi oletettu kakku tosiaan haukkaa 128mm2 niin aika paljon siinä kyllä siru kasvaa. 256-bit väylä + kakku tekee yhteensä siis noin 160mm2. Jos huhuiltu noin 500mm2 sirun koko pitää paikkaansa niin toi kikotin veisi siis kokonaisuutena kolmanneksen koko piirin pinta-alasta.

Kunnollinen muistijärjestelmä nyt vaan on PAKKO OLLA jos halutaan tehdä nopea piiri. Sen hinta on vaan maksettava. Paljon fiksumpaa siellä on olla hyvä muistijärjestelmä siten että muu piiiri saadaan työllistettyä kuin että siellä on teoriassa ziljoona petaflopsia jotka idlaa kun niille ei saada dataa ruokittua. Grafiikkaworkloadit nyt vaan tarvitsevat paljon kaistaa.

Ja tämä välimuistien + muistiohjaimien pinta-aaln osuus on silti paljon vähemmän kuin CPUissa; Esim. zen2lla (Matissa) pelkkä L3 vie selvästi enemmän pinta-alaa kuin ytimet jos ytimiin lasketaan L2 mukaan, ja L2+L3 vievät yhdessä (melkein?) tuplasti enemmän pinta-alaa kuin itse ytimet(ilman L2sta). CPUilla suuret kakut toki ei ole kaistan vaan viiveen takia.

1024-bit HBM2 ohjain vie noin 11mm2, eli kahdella ohjaimella se olisi noin 22mm2.

Kuvitellaan että 400mm2 olisi kaiken muun viemä pinta-ala, niin:
256-bit GDDR6 + cache veisi noin 29% piirin ollessa kooltaan noin 560mm2
512-bit GDDR6 veisi noin 14% piirin ollessa kooltaan noin 464mm2
2048-bit HBM2 veisi noin 5% piirin ollessa kooltaan noin 422mm2

Mikäli käytössä ei ole EMIB:iä, se HBM2 vaatii myös n. 650mm^2 verran interposeria (joka voidaan tehdä muinaisella valmistusprosessilla, mutta maksaa silti)

Ja 2 kanavaa HBM2:sta ilman järeää välimuistia ei riitä kaistan puolesta, pitäisi olla 2 kanavaa HBM2e:tä tai 3-4 pinoa HBMää että kaistaa olisi tarpeeksi. (ja 3-4 pinoa nostaa sen interposerin koon jonnekin n. 800mm^2 luokkaan)

HBM2e-PHYiden koosta ei myöskään ole tietoa.

Mielestäni aika suurista eroista kyllä kyse niin hiukan ihmettelen että AMD lähtisi moiseen suuntaan arkkitehtuuria kehittämään kun tuohon lisätään se että TSMC:n 5nm prosessilla on pizzapohjien hinta huhujen mukaan nousemassa aika huimasti ja per chip hinta on nousemassa aiemman laskusuunnan sijaan.

Näitä piirejä ei tehdä "5nm" prosessilla vaan TSMCn "7nm" prosessilla. Siitä, onko kyseessä N7P vai N7+ ei ole varmuutta.

Ja siinä vaiheessa kun siirrytään tiheämpään valmistustekniikkaan, se SRAMilla toteutettu välimuisti kutistuu oikein kivasti prosessin mukana.

Näin maallikkona asiaa ihmetellessä tuntuisi tuohon HBM2 aikaan siirtyminen aika loogiselta ratkaisulta tulevaisuutta ajatellen. Vai onko se piikieken pinta-ala sitten kuitenkin vielä riittävän halpaa että sitä kannattaa polttaa ennemmin kuin alkaa turaamaan interposerin kanssa taikka monimutkaisen levysuunnittelun kanssa jotta 512-bit väylä saataisiin toteutettua?

(pienen ei-IO-)transistorin (ja sen myötä SRAM-muistin) hinta laskee edelleen selvästi, ei toki enää puolitu kahden vuoden välein mutta puolittuu nykyisin n. neljän vuoden välein.

Ja siinä SRAMilla tehdyssä kakussa on muita oleellisia hyötyjä:

1) Sillä piirin sisäisellä SRAM-muistilla saadaan paljon suurempi kaista ja paljon pienempi viive. NIin kauan kun operoidaan sieltä kakusta, kaikki toimii paljon nopeammin => parempi suorituskyky (toki haittana on sitten, että jos kakusta tila loppuu efektiiviselle worklong setille, suorituskyky putoaa alemmas)

2) Se piirin sisäinen SRAM-muisti on paljon energiatehokkaampaa kuin ulkoinen GDDR6 tai HBM2(e), eikä HD-SRAM aiheuta merkittävästi vuotovirtaa. Kun muistiaccesseihin ei käytetä niin paljoa sähköä, voidaan tehobudjetti käyttää esim. itse ytimen ajamiseen suuremmalla kellolla.

3a) Leveämpi muistiväylä PCBllä olevaan (GDDR6-)muistiin vaatii kalliimman monikerroksisen PCBn, sekä suuremman määrän muistipiirejä. Itse kortin hinta kasvaisi mikäli laitettaisiin leveämpi muistiväylä.

3b) HBM2(e) vaatii sen interposerin (n. 650-800mm^2 lisää pinta-alaa) tai EMIBin tai vastaavan. EMIB-paketointitekniikkaa tai mitään vastaavaa AMDllä ei tietääkseni ole käytössään.
 
Viimeksi muokattu:
Näin maallikkona asiaa ihmetellessä tuntuisi tuohon HBM2 aikaan siirtyminen aika loogiselta ratkaisulta tulevaisuutta ajatellen. Vai onko se piikieken pinta-ala sitten kuitenkin vielä riittävän halpaa että sitä kannattaa polttaa ennemmin kuin alkaa turaamaan interposerin kanssa taikka monimutkaisen levysuunnittelun kanssa jotta 512-bit väylä saataisiin toteutettua?

Tuota tsmc vuotoon perustuen kuvitteellinen 600mm^2 siru maksaa 233$, suoralla jakolaskulla huhuttu 505mm^2 olisi 196$ (oikeastihan se olisi vähän eri, koska pienemmissä on paremmat saannit). Nykyisiä HBM2 hintoja en bongannut, mutta niiden pitäisi olla kalliimmat mitä gddr6. Ainakin tämän jutun mukaan gddr6 16gbs 11 -> 24Gb päivitys olisikin 60-80$.

Fudzillan vega vii bill of materials antaa vähän suuntaviivoja:
HBM 2 $320
Packaging $100 (mukana interposer)
cooler and PCB $75

Joten siitä tuo fiilis, että HBM versiot olisi joko ammattikortteja, tai sitten ihan puhdas halotuote huipulle 3090:n hintaluokkaan. 512bit bus vaikuttaa budjettiratkaisulle siihen verrattuna. Eikä tuo teoreettinen iso cache ytimen yhteydessä vaikuta sekään halvalle ratkaisulle. Halvalla prosessilla tehty edram, joka on paketoitu gpu:n viereen saattaisi olla yksi vaihtoehto.

No kuukauden kuluttua ollaan aikalailla viisaampia.
 
Siinä SRAMilla tehdyssä kakussa on muita oleellisia hyötyjä:

1) Sillä piirin sisäisellä SRAM-muistilla saadaan paljon suurempi kaista ja paljon pienempi viive. NIin kauan kun operoidaan sieltä kakusta, kaikki toimii paljon nopeammin => parempi suorituskyky (toki haittana on sitten, että jos kakusta tila loppuu efektiiviselle worklong setille, suorituskyky putoaa alemmas)

Tuo on ehkä se oleellisin. Vaikka tuo teoreettinen cache vie järkyttävästi tilaa piiristä, niin sitä pitäisi verrata enemmänkin vielä vastaavan kokoiseen piiriin isommalla ydinmäärällä ja leveämpään väylään. Eli jos vaikka 64 ydintä ja cache pääsevät samaan suorituskykyyn, mitä 80 ydintä ja leveämpi väylä, niin se alkaakin olla valmistuskustannuksiltaan aika neutraali vaihtoehto.


3) Leveämpi muistiväylä vaatii kalliimman monikerroksisen PCBn, sekä suuremman määrän muistipiirejä. Itse kortin hinta kasvaisi mikäli laitettaisiin leveämpi muistiväylä.

PCB:n hinnannousu on selviö ja tuo Vega VII on kyllä siihen huono esimerkki, kun muistit on samalla interposerilla, niin pcb muuttuukin todella yksinkertaiseksi ja sitä kautta halvemmaksi. Gddr6 muisteilla olevat PCB:t ovat kalliimpia ja leveämpi väylä vaatii lisää kerroksia. Eikös tuo PCB vaikutus ole luokkaa kymmeniä dollareita?
 
Taitaa 256-bittinen väylä viedä pikemminkin luokkaa 50 mm^2. Kuvassa navi10 (n. 250mm^2).

No joo se oma laskeskelu perustui tähän kuvaan.
up8nxtuka4651.jpg


Ja tuossahan on tosiaan PHY ainoastaan kyseessä. Mutta toi PHY nimenomaan taitaa olla se osa jota ei pystytä kutistamaan, ketjusta josta toi on otettu.

Ea-3KleWkAAWf-U


Siinä vielä Vega 20, joten aikalailla samassa pysynyt.

Mikäli käytössä ei ole EMIB:iä, se HBM2 vaatii myös n. 650mm^2 verran interposeria (joka voidaan tehdä muinaisella valmistusprosessilla, mutta maksaa silti)

Kaitpa se AMD voisi CoWoS käyttää tähän?

HBM2e-PHYiden koosta ei myöskään ole tietoa.

Juu ei ole, mutta se mitä on tapahtunut HBM hypystä HBM2 eli ei oikeastaan mitään muutosta niin tuskin siinäkään mitään mullistavaa muutosta on. Miten muuten noi itse muistiohjaimet? Onko ne kutistuvaa kamaa vai myös sellaista tavaraa joka ei kutistu?

Näitä piirejä ei tehdä "5nm" prosessilla vaan TSMCn "7nm" prosessilla. Siitä, onko kyseessä N7P vai N7+ ei ole varmuutta.

Ei tehdä ei, siksi sanoinkin että tuntuisi kummalliselta että AMD alkaisi viemään arkkitehtuuria moiseen suuntaan kun tulevaisuudessa se pinta-ala on vain tulossa kalliimmaksi. Ja juu se cache kutistuu kun siirrytään 5nm, mutta niin todennäköisesti tulee kasvamaan myös GPU:n tehot jos historiaa tarkastellaan joten jos se 128 megan kakku piisaa nyt juuri ja juuri, niin se ei piisaa enää tulevaisuudessa vaan sitä tarttee kasvattaa tai sitten tarttee kasvattaa muistiväylää.
Sitä siis meinasin että tuntuu kummalliselta viedä arkkitehtuuria moiseen suuntaan kun yleensä kun jotain arkkitehtuuriin tuodaan niin ei siitä heti olla luopumassa. Eli todennäköisesti jos tällainen cache ratkaisu nyt tulee, niin se sitten todennäköisesti tulee olemaan myös jatkossa esim. Navi 3x:ssä.

Mitäs luulet että voisiko sitten olla niin että tällainen iso cache ratkaisu voisi olla se graalin malja siihen että GPU:ssa voitaisiin myös siirtyä chiplet ratkaisuun?

Tuolla toki on juttua jotta 5nm prosessilla olisi mahdollista saada jonkin verran pienempään pinta-alaan menemään noi PHY:t, jos lähes 20% saadaan säästettyä niin onhan se toki aika hyvä siivu.

1) Sillä piirin sisäisellä SRAM-muistilla saadaan paljon suurempi kaista ja paljon pienempi viive. NIin kauan kun operoidaan sieltä kakusta, kaikki toimii paljon nopeammin => parempi suorituskyky (toki haittana on sitten, että jos kakusta tila loppuu efektiiviselle worklong setille, suorituskyky putoaa alemmas)

Niin ja se sakkaaminen voi sitten olla aika dramaattista kun se tapahtuu..

3a) Leveämpi muistiväylä PCBllä olevaan (GDDR6-)muistiin vaatii kalliimman monikerroksisen PCBn, sekä suuremman määrän muistipiirejä. Itse kortin hinta kasvaisi mikäli laitettaisiin leveämpi muistiväylä.

Tasapainoiluahan se on että mikä on paras vaihtoehto johon sisältyy saannot jne. Ja kun se suunnittelu alkaa vuosia ennen kuin fyysisiä kortteja alkaa pukata liukuhihnalta niin se minkä pohjalta on suunniteltu se optimaalinen tuote ei välttämättä ole enää optimaalinen kun tuotetta aletaan valmistaa. Että siinä mielessä toki pitää antaa siimaa tehdyille ratkaisuille.

3b) HBM2(e) vaatii sen interposerin (n. 650-800mm^2 lisää pinta-alaa) tai EMIBin tai vastaavan. EMIB-paketointitekniikkaa tai mitään vastaavaa AMDllä ei tietääkseni ole käytössään.

Eiköhän sillä AMD:llä siihen CoWoS:n ole pääsy jota TSMC asiakkailleen tarjoilee.

Fudzillan vega vii bill of materials antaa vähän suuntaviivoja:
HBM 2 $320
Packaging $100 (mukana interposer)
cooler and PCB $75

Eli Vega 64 tapauksessa jos noilla hinnoilla mennään niin 160+100+75=335 ja siihen sitten vielä GPU:n hinta päälle niin aika vähiin jää kyllä tuotot. Tosin artikkelilla on jo ikää yli 1,5v joten hinnatkin on jo voinu muuttua tuosta.
 
Siinä onkin sitten fanipojilla loputtomasti väännettävä ja takkia käännettävää, jos AMD jytkyttää 3080 yli pienemmillä resoilla, mutta tukehtuu 4K...

Muutamien viherlasikavereiden kanta kun on viimeajat tällä foorumilla vahvasti ollut että 3080 tulee kyllä menemään monella jopa 1080p käyttöön ja toinen jengi on sit vastannut että 4K korttejahan nämä on vain, muille järjettömiä :D

Itsehän uskon vasta kun näen, tulee mitä tulee. Navi 20 nimisen piirin puute eniten ihmetyttää kun Polaris ja Vega ainakin on tullut 10 ja 20 nimillä, nyt sitten Navi 10 seuraaja olisi Navi 21. En osta, edelleen arvaan että 96CU kortti 384-bit väylällä on tulossa. Vuodot on vuotoja, vuotoja voi hallita todistetusti.
 
Itsehän uskon vasta kun näen, tulee mitä tulee. Navi 20 nimisen piirin puute eniten ihmetyttää kun Polaris ja Vega ainakin on tullut 10 ja 20 nimillä, nyt sitten Navi 10 seuraaja olisi Navi 21. En osta, edelleen arvaan että 96CU kortti 384-bit väylällä on tulossa. Vuodot on vuotoja, vuotoja voi hallita todistetusti.

Suurimmaksi osaksi noi vuodot on tullu tuolta linux puolelta kun tuki pitää sinne saada hyvissä ajoin jotta tuki ehtii kerneliin mukaan, joten jos Navi 20 vielä isommalla sirulla on tulossa, niin se menee kyllä sitten jonnekin ens kesään sen tulo kun ei siitä ole ollut mitään vitteitä missään vielä.
 
Eiköhän sillä AMD:llä siihen CoWoS:n ole pääsy jota TSMC asiakkailleen tarjoilee.

CoWoS tarkoittaa juuri sellaista kaikkien muiden piilastujen alle tulevaa interposeria, jolle sitä pinta-alaa tulee tuollaisessa piriissä se 650-800mm^2.

graph_CoWoS.png
 
Ei jaksais kyllä teasereitä taas Nvidian löylytyksen jäljiltä, miks ne ei vaan sano suoraan :)
 
Mä näkisin tehoja isommaksi ongelmaksi sen miten vastaa DLSS:ään. Esim MSFS kun ei pyöri edes 3090:lla kunnolla ja siihenkin tulossa DLSS. Miten siinä lyö mitenkään kampoihin ”3080 tasoisella kortilla”, jos ei ole jotain vastaavaa.
 
Ei jaksais kyllä teasereitä taas Nvidian löylytyksen jäljiltä, miks ne ei vaan sano suoraan :)

Mitähän mahtaisi tapahtua jos sanottaisiin näin lähes kuukausi ennen julkistusta vaikka:
- Samat tehot kuin 3080 mutta 10% halvempi hinta, odottakaa kuukausi. Tavaraa tulee kaupan hyllylle 1.11 myyntiin reippaasti.

Uskallan väittää että Nvidia leikkaisi hintoja ja esim. 30.10 3080 hinnasta lähtisi pois 15% minkä johdosta kaikki uutisoisivat siitä ja testeissäkin puhe kääntyisi "AMD:n korteissa samaa tehoa mutta noin 5% kalliimpi kortti kuin kilpailijalla".

Eli ihan fiksusti toimivat kun eivät kerro etukäteen liikoja juttuja. Toki joillakin saattaa lähteä mopo käsistä kuten Zen2 julkaisua ennenkin (16-ydin joka varmasti kellottuu 5GHz+ kaikilla ytimillä jne) mutta perättömille huhuille nyt ei mitään voi. Kyllä se jo jotain kertoo että Nvidia tipautti hintoja käytännössä puolet. Odottavat siis oikeasti jos eivät suoraan häviävänsä niin ainakin saavansa tällä kertaa kilpailua vs heidän 2000-sarjansa.
 
Mä näkisin tehoja isommaksi ongelmaksi sen miten vastaa DLSS:ään. Esim MSFS kun ei pyöri edes 3090:lla kunnolla ja siihenkin tulossa DLSS. Miten siinä lyö mitenkään kampoihin ”3080 tasoisella kortilla”, jos ei ole jotain vastaavaa.
MSFS on todella prossuintensiivinen, joten jännä nähdä miten siinä DLSS tai vastaavat ratkaisut auttavat.

Itseäni mietityttää DLSS:ää enemmän tuo RT-suorituskyky ja tässä näytönohjaimen vaihtoa pohtivana se saattaa ratkaista seuraavaa korttia enemmän kuin raaka teho, kunhan erot eivät ole kymmeniä prosentteja.
 
Mä näkisin tehoja isommaksi ongelmaksi sen miten vastaa DLSS:ään. Esim MSFS kun ei pyöri edes 3090:lla kunnolla ja siihenkin tulossa DLSS. Miten siinä lyö mitenkään kampoihin ”3080 tasoisella kortilla”, jos ei ole jotain vastaavaa.

AMDllä ON "jotain vastaavaa", tai oikeastaan parempaa, Radeon Image Sharpening.

 
AMDllä ON "jotain vastaavaa", tai oikeastaan parempaa, Radeon Image Sharpening.


Tuo oli ajalta ennen DLSS 2.0 painosta. Nyt sanoisin, että erot on tässä:
- DLSS2.0 vaatii edelleen erillisen pelituen, mutta laadultaan on parempi. Sen pohjalla oleva AA ratkaisu on parempi, mitä TAA ja temporal kikat upskaalauksessa säilyttää detaileja todella hyvin. Toisaalta sen terävöinti on vedetty vähän yli. Eli haloja, artefakteja ja partikkeliefektit bugaa verrattuna alkuperäiseen.
- Radeon image sharpening tekee parempaa jälkeä mitä DLSS1.0 ja on yhteensopiva about kaikkien pelien kanssa. Pohjalla on vain yleensä aika kovan blurrin tuottava TAA ja temporal kikkojen puutteen takia ei tule niin hyvää skaalausta.

Jos haluaa spekuloida, niin xbox esityksen perusteella tehot otettaisiin enemmänkin variable shading raten avulla isoilla resoluutioilla. Eli valtaosa kuvasta piirretäänkin matalalla tarkkuudella ja ääriviivat yms vedettäisiinkin tarkasti. Toisaalta DLSS tuki alkaa ilmestyä vielä peliengineihin, jolloin sen impelementointi on helpompaa. Tietty samat enginet saavat myös omat dynaamiset resoluutiot ja skaalaukset, kiitos konsoleiden ja ei nvidia raudan.
 
Lisäksi DLSS:n tapainen ihan suoraankin voi jossain vaiheessa olla mahdollinen. Omaa ratkaisua tuskin AMD:llä on varaa tehdä, mutta esim. joku Openml:n pohjalta toimiva ratkaisu voisi esim. Microsoftin kanssa yhdessä toteuttaen tms. olla ihan mahdollinen.
Voisi kuvitella että AMD jotain vastaavaa tekniikkaa on valmistellut jo hetken, mutta koska tämä tulisi käyttöön on sitten eri asia.

Siksikin noi julkaisut kiinnostaa, että tuleeko sieltä itse korttien lisäksi myös avoimia tekniikoita joita voidaan ottaa käyttöön. Avoimet ratkaisut sekä RT että DLSS tekniikoille olisi itsellä ainakin toiveissa. Ensimmäinen taitaa tulla MS DirectX:n rt apin kautta(käsittääkseni Vulcanilla toimii myös, myös linuxilla) ja jälkimmäinen toivottavasti mahdollisimman pian tulee myös. Toinen kysymys tietty näissä aina on, että kuinka tiukasti RTX toteutukseen nykyiset RT ratkaisut tukeutuvat, eli vaativatko pelintekijöltä kuinka aktiivista päivittämistä että toimivat AMD:n ratkaisuilla myös. Tulevat pelit todennäköisesti tukevat AMD:n kortteja hienosti, mutta vanhemmista peleistä ei mitään käsitystä toistaiseksi miten toimivat.
 
- Radeon image sharpening tekee parempaa jälkeä mitä DLSS1.0 ja on yhteensopiva about kaikkien pelien kanssa. Pohjalla on vain yleensä aika kovan blurrin tuottava TAA ja temporal kikkojen puutteen takia ei tule niin hyvää skaalausta.

Pelkkä RIS kait oli about DLSS tasoa, mutta CAS + RIS sitten huomattavasti parempi kuin DLSS mutta ei ihan pärjää DLSS 2.0:lle. Ja CAS ongelma on sama kuin DLSS eli vaatii pelin tekijältä tuen toteuttamisen, siksi ei monesta pelistä löyty.
 
AMDllä ON "jotain vastaavaa", tai oikeastaan parempaa, Radeon Image Sharpening.


Joka vastaa suunnilleen Nvidian freestyle sharpen filteriä. Ja kuten sanottu tuo on jo vanha artikkeli, jonka päivittelyt voit lukea jatkoartikkeleista.

RIS vs Freestyle vs DLSS 1.0:

DLSS 2.0:

Sinällään toimiva DirectML toteutus DLSSää vastaavasta olisi mielenkiintoinen. En oikein vain odota että AMD itse tuota kehittäisi. Microsoft ja Sony ehkä konsoleilleen ja MS:n puolelta voisi jotain vuotaa PC puolellekkin.
 
AMDllä ON "jotain vastaavaa", tai oikeastaan parempaa, Radeon Image Sharpening.

Ei ole kyllä todellakaan ole vastaavaa tai parempi. NVIDIAlla tosin on myös tuo kuvan terävöitys ja GPU skaalaus, jos sitä haluaa käyttää. Aivan sama homma (ja ollut ajureissa suoraan jo todella kauan).
 
Joo Nvidia kopioi tuon RIS:n kun AMD sai siitä paljon kehuja.

Löytyy siis vastaava molemmilta.
 
Mitähän mahtaisi tapahtua jos sanottaisiin näin lähes kuukausi ennen julkistusta vaikka:
- Samat tehot kuin 3080 mutta 10% halvempi hinta, odottakaa kuukausi. Tavaraa tulee kaupan hyllylle 1.11 myyntiin reippaasti.

Uskallan väittää että Nvidia leikkaisi hintoja ja esim. 30.10 3080 hinnasta lähtisi pois 15% minkä johdosta kaikki uutisoisivat siitä ja testeissäkin puhe kääntyisi "AMD:n korteissa samaa tehoa mutta noin 5% kalliimpi kortti kuin kilpailijalla".

Eli ihan fiksusti toimivat kun eivät kerro etukäteen liikoja juttuja. Toki joillakin saattaa lähteä mopo käsistä kuten Zen2 julkaisua ennenkin (16-ydin joka varmasti kellottuu 5GHz+ kaikilla ytimillä jne) mutta perättömille huhuille nyt ei mitään voi. Kyllä se jo jotain kertoo että Nvidia tipautti hintoja käytännössä puolet. Odottavat siis oikeasti jos eivät suoraan häviävänsä niin ainakin saavansa tällä kertaa kilpailua vs heidän 2000-sarjansa.
Hemmetin realistit pois mun fantasialinnoista! :D
 
Ei ole kyllä todellakaan ole vastaavaa tai parempi. NVIDIAlla tosin on myös tuo kuvan terävöitys ja GPU skaalaus, jos sitä haluaa käyttää. Aivan sama homma (ja ollut ajureissa suoraan jo todella kauan).
No yleisesti silloin kun se toimii niin DLSS2.0 on ehdottomasti parempi kuvanlaadultaan. Eri asia sitten että miten noita erilaisia artefakteja painottaa, että kumpi on parempi. CAS+RIS ei tuota mitään temporaalisia artefakteja ja halot voi säätää haluamalleen tasolle. Tilanne melko lailla 50/50 tällä hetkellä omasta mielestäni (sillä en voi sietää artefakteja), mutta DLSS menee suurella varmuudella edelle kunhan saavat halot ja temporaaliset artefaktit ulos seuraavassa versiossaan.
 
No yleisesti silloin kun se toimii niin DLSS2.0 on ehdottomasti parempi kuvanlaadultaan. Eri asia sitten että miten noita erilaisia artefakteja painottaa, että kumpi on parempi. CAS+RIS ei tuota mitään temporaalisia artefakteja ja halot voi säätää haluamalleen tasolle. Tilanne melko lailla 50/50 tällä hetkellä omasta mielestäni (sillä en voi sietää artefakteja), mutta DLSS menee suurella varmuudella edelle kunhan saavat halot ja temporaaliset artefaktit ulos seuraavassa versiossaan.
Eihän se terävöitys tietenkään mitään virheitä tuota, kun on pelkkä terävöitysfiltteri. DLSS2.0 hoitaa samalla reunanpehmennyksen ja on temporaalisesti stabiili. Jos pelissä on hyvä reunanpehmennysimplementaatio, niin silloin voi ehkä hieman kompensoida, mutta yleisesti ottaen minkä tahansa kuvan "tyhmä" skaalaus ylös ja siihen lätkäisty terävöitys on aika meehh.

Pikemminkin näen hyödyn tuossa vain niissä peleissä natiivilla resoluutiolla, joissa TAA tuottaa pehmeetä mössöä.
 
Tuolla oli nyt huhua, että Big Navi olisi 536mm^2. Tossa olisi ihan hyvin tilaa kyllä laittaa kakkua ja 80CU...
 
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.
Tuli muuten vielä näistä pohdinnoista mieleen, että onkohan nvidia ajanut "8k gaming" mantraansa medialle juuri tämän takia? Eli ovat kehittäneet jonkun kategorian, jossa tietävät varmasti olevansa vielä nopeampia ja sitten yrittävät 100 lasissa pumpata kyseisen kategorian merkityksellisyyttä ylöspäin kaiken maailman influenssereiden kautta. Ketään ei luulisi oikeasti kiinnostavan 8k pelaaminen, niin ei tolle nvidian PR sekoilulle mitään muutakaan syytä oikein keksi.

Sampsaltakin taitaa tulla nvidia yhteistyövideo 8k pelaamisesta tässä lähiaikoina. :whistling:




Siinä ehkä kuvassa big navi

Joku tais tan laskea olevan n. 536mm^2, tosin verrattaen epätarkoin menetelmin, joten voisi kuvitella että 256 bittisen muistikaistan kanssa sinne jäisi hyvin tilaa 80 CU:n lisäksi tolle 128MB kakullekkin.
 
Joku tais tan laskea olevan n. 536mm^2, tosin verrattaen epätarkoin menetelmin, joten voisi kuvitella että 256 bittisen muistikaistan kanssa sinne jäisi hyvin tilaa 80 CU:n lisäksi tolle 128MB kakullekkin.

Kuvassa taitaa olla photoshopattu 5700XT. Muistaakseni tuossa tarina oli, että coreteks sai kuvan big navista. Lähteitä suojaktakseen käytettiin paljon photoshoppia. Joten tuossa taitaa olla vain mitat saadusta vuotokuvasta ja sitten on photarissa vedetty 5700XT muistuttamaan sitä. Jonka jälkeen voi jo toteta, että onkohan alkuperäistä kuvaakaan ollut edes olemassa.
 


Siinä ehkä kuvassa big navi

Ehkä on ehkä ei, tää kaveri ei ole millään tasolla osoittanut olevansa luotettava lähde millekään vuodoille ja on itseasiassa asettanut koko tietotaitonsa vähintään kyseenalaiseksi vannommalla sen nvidian "erillisen rt co-processorin" nimeen missä ei ollut ikinä mitään päätä eikä häntää
 
Joku tais tan laskea olevan n. 536mm^2, tosin verrattaen epätarkoin menetelmin, joten voisi kuvitella että 256 bittisen muistikaistan kanssa sinne jäisi hyvin tilaa 80 CU:n lisäksi tolle 128MB kakullekkin.

Se oli toi coretex joka sen laski ja kuten hese jo mainitsi niin on "lähteitä suojatakseen" photoshopannu tuon kuvan kasaan. Kuulemma konkkien sijoittelu suurelta osin otettu rx5700xt:stä ettei vuotaja paljastu.
Voi olla että koko kuva on ihan vain hänen kuvitelmaa.
 
Ehkä on ehkä ei, tää kaveri ei ole millään tasolla osoittanut olevansa luotettava lähde millekään vuodoille ja on itseasiassa asettanut koko tietotaitonsa vähintään kyseenalaiseksi vannommalla sen nvidian "erillisen rt co-processorin" nimeen missä ei ollut ikinä mitään päätä eikä häntää

On sillä nyt muutenkin haulikko käytössä uutisten suhteen:

"Youtuber Paul Kelly from the PC enthusiast channel “Not an Apple Fan” today dropped a bombshell regarding the upcoming AMD RDNA2 gpus, revealing that the top GPU will indeed be the 6900XT which will probably compete directly with NVidia’s Flagship RTX 3090. "

Samassa uutisessa missä kehutaan 3090:n tasoisesta kortista se vain vahvistaa oman 2kk vanhan arvion:

"It’s important to note that my own sources have consistently said that Navi21 will top out at “2080ti performance + 15%” and haven’t deviated from that even after pressed with Paul’s information. "
 
Tuohan voi olla vaikka joku parempi nimitys Ryzenin "game cachelle" tai ihan huvin vuoksi vaan rekisteröineet. En vielä pitäisi vahvistettuna.
 
Jos oikein ymmärsin noista twitter keskusteluista. Niin tämän pitäisi olla kyseisen infinity cachen toimintamallin patentti:

Tuo kuvailee L1:n toimintaa, RDNA:ssa on aina jaetut L1:t, tuo antaa mahdollisuuden olla privaatti tai jaettu, epäilty että CDNA:ssa olisi käytössä.
Jos "Infinity Cache" on iso kuten on ehdotettu sillä tuskin on mitään tekemistä L1:n kanssa.
edit:
Tosin monet ovat veikkailleet Infinity Cachea next gen Infinity Fabricin osaksi prossujen päähän
 
Viimeksi muokattu:
AMDllä ON "jotain vastaavaa", tai oikeastaan parempaa, Radeon Image Sharpening.


Laadultana tuo AMD:n toteutus ei vedä vertoja lähekkellään DLSS:n uusimman version toteutuksille. Nvidia johtaa tällä saralla valovuoden AMD:tä ja ei hyvältä näytä jos AMD:n kannalta jos ei saa tuota tekniikkaansa parannettua huomattavasti.
 

Statistiikka

Viestiketjuista
258 314
Viestejä
4 491 022
Jäsenet
74 194
Uusin jäsen
Juhisti

Hinta.fi

Back
Ylös Bottom