CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144

[DaniëlWW2]

@MneoreJ Precies ja.
Komt nog eens bij dat het zo niet hoeft. Shadows en al helemaal reflections zijn vele malen intensiever dan global illumination en zijn redelijk te "faken" met traditionele technieken. Juist goede GI is iets dat je meteen ziet in elke frame, het wow effect geeft en het met RT doen is veel minder intensief. Neem die demo van dat treinstation met Lumen of wat Nvidia laat zien met hun eigen GI SDK. Dat is een gevalletje zodra je het ziet, wil je niet meer zonder.

---

Dan nog iets anders. Ik heb de laatste tijd eens lopen nadenken wat ik vermoed dat AMD voor RT wat gaat veranderen. Dit is dus allemaal hoog speculatief niveau. Noem het MLID niveau, maar dan met enige basale kennis om mee te gokken.

Eerst maar eens de constatering dat we weten dat RDNA3, matrix berekeningen kan gaan uitvoeren. Dat impliceert ook een matrix unit. En ik weet wel hoe ze dat gaan doen als ik naar CDNA kijk.
Geheel toevallig lijken RDNA en CDNA SIMD blokken wel heel veel op elkaar buiten de gebruikte types ALU's.



Ik denk dus al een tijdje dat in RDNA3 er een (kleine) matrix unit aan elke SIMD 32 gehangen zal worden. De functie lijkt me tweedelig. Betere FSR in de toekomst en denoising voor RT.

Blijft over de RT zelf. AMD gebruikt een typische lv2 aanpak waar Nvidia op lv3 zit. Het verschil is dat bij Ampere de BvH en de intersections door de RT core worden gedaan. De data komt uit de shared SM L1 cache en denoising word gedaan door de Tensor Core. Bij RDNA2 zit BvH in de ALU's en de dataopslag zal de Vector Register File zijn. Ray intersections worden door de RA gedaan en denoising zal ook door de ALU's gedaan worden.



Wat ik voor RDNA3 vermoed is dat denoising naar een matrix unit gaat om dit in minder clock cycles af te handelen. Vervolgens is het echt gokken. Ik vermoed dat AMD bij dit systeem en lv2 ondersteuning blijft, maar het systeem capabeler zal worden om twee redenen: Voor Navi 31/32 zou Vector Register File naar 192KB gaan waardoor er meer dataopslag beschikbaar komt. Tweede zou zijn dat ze simpelweg meer rays intersection checks gaan doen per clock met een betere RA.

Het grootste nadeel blijft alleen ook in dat dit bovenop de reguliere shading komt. Uiteindelijk heb je maar zoveel clock cycles per seconde waarbinnen een frame gerenderd moet worden en RT is een enorme impact. Zeker met RDNA2 haar aanpak komen er waarschijnlijk nog meer cycles erbij voor denoising en intersections tests. Daarom vermoed ik dat de focus komt te liggen op meer intersections en efficiëntere denoising.

Hierom is mijn "hoop" ook niet gevestigd op de kwaliteit van de SIMD units, RAs en matrix unit, maar op de kwantiteit. Want uiteindelijk moet je hier ook rekenkracht naar gooien en zo komen we bij de grote verwachte Navi chips. Ik koester niet veel hoop voor Navi 33, maar bij 31 en 32 vraag ik me af hoeveel ze kunnen forceren door botweg meer tegen het probleem aan te aangooien.

[Werelds]

Ludewig schreef op zondag 28 augustus 2022 @ 12:03:
Misschien is het goed om naar de geschiedenis te kijken. AMD net als Intel is ooit begonnen door ingenieurs van Fairchild Semiconductor. Maar waar Intel een pionier was in x86, werd er door AMD slechts de technologie van Intel gekopieerd. AMD liep dan ook constant achter.

Dat veranderde toen AMD een bedrijf overnam met goede x86-technologie, NexGen. Toen ging AMD innoveren ipv kopiëren. De Athlon werd dan ook een groot succes. Op een gegeven moment lieten ze het lopen. Met Zen hebben ze weer echt geïnnoveerd en ging het weer goed.

Volstrekt off-topic, maar: waar haal je dit in vredesnaam vandaan joh?

Ik heb geen idee wat je bedoelt met "een pionier in x86". "x86" is niet eens ontworpen door Intel. Dat komt uiteindelijk bij CTC vandaan - zowel de instructieset als de oorspronkelijke architectuur. De 8008 was 100% hun ontwerp, pas toen het op het zand aankwam schakelden ze Intel en IBM in (het fysieke ontwerp is dus ook niet geheel van Intel). Het succes van de instructieset heeft ook helemaal geen reet met de instructieset zelf te maken. Dat success komt doordat IBM voor de 8088 (niet eens de 8086!) voor hun IBM PC koos. Motorola had hun 68000 nog niet klaar, IBM had zelf geen geschikte producten (het moesten vrij verkrijgbare onderdelen zijn). Intel was vervolgens bereid goedkoper dan TI te leveren én kon dat in grotere aantallen. En waarom was dat? Omdat ze tóen al een overeenkomst met AMD hadden, die toen bekend stonden om hun hoge productiekwaliteit. Instructieset deed er in die tijd geheel niet toe, computers waren nog geen gemeengoed en was juist wat IBM wilde bereiken.

AMD's relatie met Intel is dan ook geheel anders dan jij schetst. De 8080 had AMD wel reverse engineered, maar naar aanleiding daarvan (we hebben het dan over halverwege de jaren '70) zijn de twee ook al onlosmakelijk aan elkaar verbonden met allerlei cross-licensing overeenkomsten. Toen IBM de 8088 wilde afnemen, stelden ze ook de eis dat er een tweede bron voor het ding was. Dat werd dus AMD omdat zij toch al voor Intel produceerden en voilá, zo werd de band tussen de twee nog sterker. Tegen de tijd van de i386 vond Intel dat hun overeenkomst daar niet meer op sloeg en probeerde AMD's AM386 tegen te houden, wat ze ook een jaar of 4 lukte. Die kon namelijk op hogere kloksnelheden draaien door de strakkere pipelines en had een cache ingebakken en was gewoon veel sneller dan Intel's ontwerp (zonder meer te verbruiken, wat er zelfs toen al toe deed...die 2W ). Intussen brachten ze de i486 uit, die geheel toevallig ook veel strakkere pipelines en een cache had. Maar zelfs dan was de AM386 nog steeds ongeveer even snel als de i486. Hun K5 was ook niets mis mee, behalve dan dat hij te laat op de markt kwam door productie problemen. Dat ding had een concurrent voor P5 moeten zijn (Pentium 1), maar kwam pas tegen de tijd van P6 uit. Presteerde wel veel beter dan de P5 waar hij mee had moeten concurreren. Dus nee, ze liepen helemaal niet "constant achter". Tot de 386 waren ze enkel een tweede leverancier van Intel ontwerpen en geen concurrent. Hun 386/486 ontwerpen waren beter dan die van Intel en als K5 op tijd uit was gekomen, had de Pentium ook veel meer concurrentie gehad. Ik durf er ook wel iets op te verwedden dat iedereen hier die oud genoeg is om op een 286/386/486 iets gedaan te hebben, wel een AMD (of Cyrix!) CPU heeft gehad zonder dat echt te beseffen (vooral als je een Compaq ofzo had)

Op dat moment waren microprocessors ook nog steeds bijzaak voor AMD. Hun productie voor Fairchild, Intel en dergelijke was hoe ze in het begin überhaupt geld verdienden (AMD is niet meteen met enkele miljoenen venture capital begonnen zoals Intel). Maar in de jaren 70 en 80 produceerden ze allerlei andere chips; van logic counters (Google AM2501 eens? ) tot RAM, tot EPROM en een hoop embedded processors - en daar waren ze heel succesvol in, daarom was Intel ook met ze in zee gegaan. Veel daarvan is pas een jaar of 20-25 geleden gestopt danwel verkocht aan andere bedrijven.

Het is ook niet alsof Intel geen misstappen heeft gezet. Netburst (Pentium 4) was waardeloos en de Core architectuur is daarom ook een voortzetting van P6, niet Netburst - wat op zijn (Core) beurt uiteraard een sterk staaltje executie was. En dan is er natuurlijk IA-64.

De realiteit is dat veel van die oude halfgeleider bedrijven niet meer zouden bestaan zonder elkaar. En dan zijn vooral ook AMD, Intel en IBM onlosmakelijk aan elkaar verbonden. Het is maar de vraag of IBM's PC zo'n succes was geworden als Intel ze geen goedkope chip had kunnen leveren waardoor dat ding een razend succes werd voor de gewone consument. Intel op hun beurt kon dat enkel doen door hun al bestaande samenwerking met AMD en het ontwerp van CTC, want hun eigen ontwerp (4004) was een mislukking (en te laat). En AMD heeft op hun beurt weer de kans gekregen hun eigen producten te ontwikkelen en produceren (niet de microprocessors, juist alle andere dingen) doordat ze voor bedrijven als Fairchild en Intel produceerden. En kopiëren? Het maakt niet uit welk bedrijf je neemt, in de jaren '70, '80 en zelfs '90 gebeurde dat aan de lopende band (pun intended ). IBM, TI, Intel, AMD, Fairchild, Apple, Motorola, Microsoft - noem ze maar op. Klonen / reverse engineering was hartstikke normaal tussen die bedrijven. Maar als het op AMD en Intel aan komt had AMD gewoon een licentie en waren hun ontwerpen absoluut geen kopie van Intel na de 286.

Met RDNA zijn ze ook weer echt goed aan het innoveren geslagen op GPU vlak, maar Nvidia is veel beter in innovatie en executie dan Intel, dus dan is het veel lastig om een achterstand in te halen. En sowieso is het veel lastiger om op de GPU markt te concurreren, wat Intel nu ook ontdekt heeft.

Nvidia's vermogen tot innovatie en executie valt reuze mee, tenzij je marketing executie bedoelt. Waar ze vooral goed in zijn, is beoordelen wat goed te marketen is en dat vervolgens ook extreem effectief doen. Het eenvoudigste voorbeeld is gewoon T&L, waar ze claims als "world's first hardware T&L" hadden...terwijl dat al dik 5 jaar in arcade machines gedaan werd en ook in een hoop consoles zat (Saturn, PS, N64). Multi-monitor waren ze later mee dan ATI. Later kwam die laatste (inmiddels onder de AMD naam) met Eyefinity en deden ze dat af als "nutteloos", maar vonden het wel nodig om voor hun vertraagde Fermi een software hack in elkaar te flansen om iets soortgelijks op de markt te brengen. Tessellation had al in D3D10 moeten zitten, maar Nvidia was er niet klaar voor dus werd het er uit gelaten...ATI had dat al begin deze eeuw (TruForm), heeft het ergens tussenin 2 generaties niet gehad (R300/R400) en bracht het volgens mij in R520 weer terug (het zat sowieso ook in Xenos, de Xbox 360 chip). Unified Shaders waren ze ook niet de eerste mee, dat had ATI al gedaan voor Xenos. Qua executie hebben ze net als AMD of Intel grote misstappen gemaakt, ik hoef maar naar NV3x en Fermi te wijzen.

AMD is ook nooit gestopt met innoveren. GCN was gewoon een top architectuur, Kepler was zo indrukwekkend niet. Maar door de mindshare die Nvidia met G80 op had gebouwd was het zelfs met Fermi al lastig voor AMD om marktaandeel terug te klauwen. En dan komt Nvidia dus met Kepler, die vergeleken met Fermi inderdaad geweldig was...maar met GCN of zelfs TeraScale 2 was de vergelijking een ander verhaal.

Wat mij betreft is alles terug te leiden naar G80. Die chip en architectuur waren geweldig -- maar bovenal was de timing vlekkeloos, dat had echt niet beter gekund. ATI zat midden in een overname en had dan wel Xenos de deur uit gestampt, maar ze hadden ook R520 moeten vertragen door een fout van TSMC (ze hadden ATI foute GDS templates gestuurd). Gevolg was dat R600 ook vertraagd werd en ze zo al bijna meteen een hele generatie achter lagen. Ze hebben toen vol op de kleine RV770 in gezet en een ander marktsegment aangesproken, maar het is de G80 schade die ze nooit meer in hebben kunnen lopen. Vóór G80 zag je elke paar jaar dat het marktaandeel schommelde tussen de twee, maar met G80 schoot Nvidia naar 65-70% en zelfs Fermi was niet genoeg om de boel weer om te doen slaan. Daarvoor moet AMD echt 3-4 generaties achter elkaar de kroon pakken én zuiniger zijn én goedkoper zijn. Als één van die 3 factoren niet het geval is zal de massa dat als argument vóór Nvidia aangrijpen. Mindshare moet echt niet onderschat worden.

[napata]

DaniëlWW2 schreef op zondag 28 augustus 2022 @ 14:53:
[...]
Nvidia krijgt van mij geen genade omdat ze nu al vier jaar lopen te roepen hoe geweldig RT(X) is. Ze hebben letterlijk de naamgeving van hun producten veranderd voor RT(X). Het is elke marketing event, RT(X) dit, RT(X) dat. Voor een bedrijf dat het alleen maar over RT(X) kan hebben als een basisvoorwaarde voor de aanschaf van een videokaart, is hun hardware knap waardeloos.

Dit is namelijk een Ampere processing block. Er is maar een stukje in een SM dat gedeeld is binnen een SM en dat is meteen het enige stuk dat direct aan L1 cache hangt. De RT core van Ampere is technisch ook capabeler dan wat AMD heeft, wederom dat is pover. Punt is dat zodra de RT core aan de slag gaat, de rest van de SM waarschijnlijk geen toegang meer heeft tot L1 cache. Dat is allemaal voor de RT core. Die zit de reguliere ALU's gewoon in de weg op deze manier. De "oplossing" hier zou zijn dat de RT core haar eigen cache krijgt die data uit de reguliere L1 cache trekt. Maar dan alsnog heb je het probleem dat denoising op de Tensor Core draait waardoor je alsnog pipeline stalls krijgt. En onder de streep is al die extra investering in transistoren en R&D, niet bepaald vertaald in een grote sprong in capaciteiten.
[Afbeelding]

Ben je hier zeker van? Dit is niet hoe ik de whitepaper van Ampere opvat.

The GA10x GPU enhances the Async Compute functionality of prior NVIDIA GPUs with a new
capability that allows RT Core and graphics, or RT Core and compute workloads to be
processed concurrently in each GA10x GPU SM. The GA10x SM can process two compute
workloads simultaneously, and is not limited to just compute and graphics simultaneously as in
prior GPU generations, allowing scenarios such as a compute-based denoising algorithm to run
concurrently with RT Core-based ray tracing work.

Het lijkt me zelfs dat de Tensor cores tegelijk kunnen gebruikt worden. Die worden trouwens niet of ampers gebruikt voor denoising omdat er geen documentatie voor is.

[DaniëlWW2]

napata schreef op maandag 29 augustus 2022 @ 22:53:
[...]

Ben je hier zeker van? Dit is niet hoe ik de whitepaper van Ampere opvat.

[...]


[Afbeelding]

Het lijkt me zelfs dat de Tensor cores tegelijk kunnen gebruikt worden. Die worden trouwens niet of ampers gebruikt voor denoising omdat er geen documentatie voor is.

Ja en nee.
Ja omdat mijn punt blijft staan wat de RT core in Ampere is alsmede de capaciteiten hiervan.

Nee omdat ik zie dat ik te makkelijk heb aangenomen dat de tensor cores het denoising doen. Dat trekt overigens meteen Nvidia hun eigen grafiek wat in twijfel omdat dit betekend dat denoising gedaan word op de reguliere ALU's die vervolgens geen andere rekenopdracht kunnen uitvoeren. Dan is het dus niet dat RT de reguliere ALU's in de weg zit als die tegen een instructie in een thread aanlopen waarbij ze een stukje data nodig hebben terwijl SM L1 cache helemaal vol zit met data voor RT. Nee die zitten ook aan RT workload namelijk het denoisen.

Ik vind het eigenlijk wel een goede omdat dit voor mij ook beter verklaard waarom Ampere niet zoveel beter in RT is dan RDNA2. Immers hangt je BvH structuur niet in shaders en ik nam per abuis aan dat denoising op tensor cores draaide en hiermee een flinke versnelling had. Onder de streep zijn de Ampere RT cores zelf dan iets capabeler dan ik dacht, maar de impact van RT op de rest van de SM is ook groter.

[Paprika]

DaniëlWW2 schreef op maandag 29 augustus 2022 @ 23:32:
[...]
...

https://www.reddit.com/r/...being_used_for_denoising/
https://www.nvidia.com/en...ay-tracing-available-now/

Tensor cores go .

[DaniëlWW2]

Paprika schreef op dinsdag 30 augustus 2022 @ 09:19:
[...]

https://www.reddit.com/r/...being_used_for_denoising/
https://www.nvidia.com/en...ay-tracing-available-now/

Tensor cores go .

Bedankt dat je de chaos compleet maakt met tegenstrijdige berichten.

---

Ik ben dus maar in de Ampere whitepaper gedoken. Het lijkt erop dat het beiden kan zijn.
Tensor cores doen AI denoising, maar het lijkt per game te verschillen of ze ook gebruikt worden.

[Paprika]

In 2020 ergens gaf Nvidia aan dat ze meer met de Tensor cores wilden gaan doen, maar in welke mate dat is gelukt valt nergens te vinden. Maar goed, het enige waar ik iets om geef is DLAA (dat zeg ik al sinds 2018) en laat die lijst nou net super kort zijn en ook nog eens niet bepaald de meest relevante lijst aan spellen:

• Chorus
• Deep Rock Galactic
• Farming Simulator
• Jurassic World Evolution 2
• No Man’s Sky
• The Elder Scrolls Online

Waarbij ESO de eerste was met ondersteuning, september vorig jaar . Ik heb het dan ook al lang opgegeven en heb volgens mij nog nooit de tensor cores gebruikt in een game(!). Alleen wat licht effecten in benchmarks en een techdemo.

Hopelijk heb je gelijk wat AMD betreft en hun aankomende GPU release.

[ Voor 11% gewijzigd door Paprika op 30-08-2022 10:01 ]

[DaniëlWW2]

Paprika schreef op dinsdag 30 augustus 2022 @ 10:00:
In 2020 ergens gaf Nvidia aan dat ze meer met de Tensor cores wilden gaan doen, maar in welke mate dat is gelukt valt nergens te vinden. Maar goed, het enige waar ik iets om geef is DLAA (dat zeg ik al sinds 2018) en laat die lijst nou net super kort zijn en ook nog eens niet bepaald de meest relevante lijst aan spellen:

• Chorus
• Deep Rock Galactic
• Farming Simulator
• Jurassic World Evolution 2
• No Man’s Sky
• The Elder Scrolls Online

Waarbij ESO de eerste was met ondersteuning, september vorig jaar . Ik heb het dan ook al lang opgegeven en heb volgens mij nog nooit de tensor cores gebruikt in een game(!). Alleen wat licht effecten in benchmarks en een techdemo.

Hopelijk heb je gelijk wat AMD betreft en hun aankomende GPU release.

Spiderman heeft het ook.
Maar als ik DLAA tegenover TAA zie, tja dan begrijp ik het wel.

---

Ik hoop uiteraard ook dat ik gelijk heb.
Mijn vermoeden is alleen sterker geworden na vannacht met Zen 4. Want https://www.angstronomics.com/p/ryzen-7000-desktop-preview zat correct hiermee en heeft waarschijnlijk meer details vermeld dan AMD ons heeft gezegd. Het sterkt het idee dat deze ook goed zit met RDNA3.

Het beeld dat zich dan ook vormt is vrij indrukwekkend. Het is misschien niet GCN5 naar RDNA ingrijpend, maar het lijkt alsnog fors te zijn. Omdat de focus zo enorm ligt op transistoren reduceren voor productie en kostentechnische redenen, net zoals bij Zen 4 het geval is, vermoed ik dus ook dat AMD doorgaat met RT zoals ze het in RDNA2 deden.

De twee alternatieven die ik voorzie, zouden een Nvidia stijl aanpak zijn waarbij ze een RT unit per WGP gaan introduceren. Het probleem daarmee is extra transistoren alsmede de vraag uit welke cache die unit haar data moet halen. In RDNA zitten de relevante caches namelijk erg dicht op de rekeneenheden en zijn die ook exclusief voor die eenheden. Dat zou al snel vragen om nog een cache systeem wat het doel van een kleinere chip ondermijnd. Tweede alternatief is een grote RT unit per Shader Array, meer richting wat Intel doet. Voordeel is dat je hiermee veel verder kan gaan in hardwarematige ondersteuning van RT berekeningen los van de shader pipeline. Nadeel is dat het veel, veel meer transistoren kost. Een ander nadeel dat ik vermoed, is dat de Shader Array in RDNA3 waarschijnlijk veel meer ALU's gaat bevatten. Je gaat dus ook veel meer data moeten verplaatsen. Je krijgt zo nog meer druk op Shader Array L1 cache (die toch al veel te klein en langzaam zal zijn hiervoor) of moet hier weer een aparte cache voor introduceren.

Ik vermoed dus dat het local blijft. De versnelling komt dan hopelijk uit betere RA units en veel snellere denoising met een matrix unit.

[Dennism]

CMT schreef op zondag 28 augustus 2022 @ 10:04:


Het zal mij ook erg benieuwen wat zometeen de kwartaalcijfers worden en waarbij we de daadwerkelijk impact van de miners gaan zien. Al eind 2020 gaf ik in reacties op nieuwsartikelen aan dat de cryptominers waarschijnlijk voor een groot deel de schaarste (voor gamers) veroorzaakten.
Mijn redenering was, het beetje aanbod dat er was werd weggekaapt door miners.
Maar dat werd door de meeste afgedaan als niet significant. Zullen we zien wie er zometeen gelijk had ^^.

Q2 2022 marketshare cijfers zijn vandaag toevallig bekend geworden, hier zou gezien Nvidia's kwartaal cijfers voor Q2 (-30% omzet in gaming QoQ) zeker een deel crypto impact in moeten zitten, maar die blijft beperkt zo te zien. Nvidia verliest 3% share, AMD pakt 1%, Intel pakt de overige 2 procent.



dGPU alleen lijkt nog achter de paywall te zitten, die zal mogen wel ergens te vinden zijn.

[ Voor 6% gewijzigd door Dennism op 30-08-2022 22:05 ]

[XWB]

Het slechte nieuws is natuurlijk vooral dat de PC-markt alweer gekrompen is, voor het derde kwartaal op een rij.

PC GPU market shipments decreased by -12.7% sequentially and decreased by -32% year to year.

Desktop graphics add-in boards (AIBs that use discrete GPUs) decreased by -22.6% from the last quarter.

The overall PC CPU market decreased by -7.0% quarter to quarter and decreased -33.7% year to year.

[ Voor 35% gewijzigd door XWB op 30-08-2022 23:17 ]

[Dennism]

XWB schreef op dinsdag 30 augustus 2022 @ 22:56:
Het slechte nieuws is natuurlijk vooral dat de PC-markt alweer gekrompen is, voor het derde kwartaal op een rij.


[...]


[...]


[...]

Ik had eigenlijk niet anders verwacht, ik de cijfers zo even niet paraat, maar was die markt eigenlijk al niet bijna zeker 10 jaar aan het krimpen met hier en daar een opleving, totdat corona kwam en ineens iedereen en zijn moeder een desktop / laptop, thuiswerkplek en game pc nodig had, waardoor je een 'mega' opleving kreeg van meerdere kwartalen op rij.

[ Voor 6% gewijzigd door Dennism op 30-08-2022 23:36 ]

[Ludewig]

XWB schreef op dinsdag 30 augustus 2022 @ 22:56:
Het slechte nieuws is natuurlijk vooral dat de PC-markt alweer gekrompen is, voor het derde kwartaal op een rij.

Dat zie ik eerder als goed nieuws. De chipmarkt was heel erg oververhit en nu kan men een beetje op adem komen. Voor de industrie is het ook beter dat het nu gebeurd en ze de opschaling van nieuwe fabrieken kunnen vertragen, dan dat het straks gebeurd als al die fabrieken online komen.

Gezien al de plannen voor nieuwe fabrieken leek me een overschot sowieso vrijwel zeker, waarbij het vooral de vraag was hoe groot het overschot zou worden. Als ze nu minder snel opschalen, zijn ze straks niet de pineut met echt grote verliezen.

Ik begrijp de strategie van Nvidia trouwens niet. Ze lijken te denken dat ze nog tijd genoeg hebben om de rest van de voorraad tegen relatief hoge prijzen weg te werken, maar met een verwachte influx van miningkaarten op de 2e hands markt, een vermoedelijk nog veel verder afnemende vraag, vermoedelijk erg sterke concurrentie van AMD 7000 en wellicht zelfs nog concurrentie van Intel Arc, zou ik als ik hen was al veel eerder stevige kortingen hebben gegeven. Zoals AMD dat doet.

Wellicht komen komen er vanaf oktober maandenlang grote aantallen miningkaarten de tweedehands markt op, voor dumpprijzen waar Nvidia niet mee kan concurreren. Tegen de tijd dat die influx ophoudt komt AMD dan met hun nieuwe kaarten. AMD lijkt hun voorraad veel sneller weg te werken. AMD kan straks ook voor een lage prijs extra wafercapaciteit inkopen bij TSMC. Dus dan kunnen ze vrij snel de hele reeks uitbrengen, van 7900 tot en met 7600. Hun productiekosten lijken relatief laag, dus ook bij een ingestorte markt kunnen ze met relatief lage prijzen veel mensen verleiden tot een upgrade en toch nog winst maken.

En dan komt Nvidia vrolijk met een bak 3060 Ti's aankakken die in de pan gehakt worden door 7600's en waarvoor ze flinke prijzen moeten vragen om geen verlies te lijden.

[CMT]

Dennism schreef op dinsdag 30 augustus 2022 @ 22:04:
[...]


Q2 2022 marketshare cijfers zijn vandaag toevallig bekend geworden, hier zou gezien Nvidia's kwartaal cijfers voor Q2 (-30% omzet in gaming QoQ) zeker een deel crypto impact in moeten zitten, maar die blijft beperkt zo te zien. Nvidia verliest 3% share, AMD pakt 1%, Intel pakt de overige 2 procent.

[Afbeelding]

dGPU alleen lijkt nog achter de paywall te zitten, die zal mogen wel ergens te vinden zijn.

Het is jammer dat er aan dit soort cijfers geen spelt aan vast te knopen is. Relatief kan er verlies zijn, terwijl in absolute aantallen toch een stijging was. Ik ben benieuwd naar de dGPU cijfers zo meteen .

Ik heb nog wel wat gevonden dat ook leuk is voor wat perspectief.
Nvidia heeft in de tijd van de 2e Cryptoboom, ca. 4x zoveel kaarten verscheept dan AMD.
En het dGPU marktaandeel is in die tijd gekrompen?
Nu betekent verschepen niet automatisch dat alles verkocht wordt, maar waar blijven al die kaarten dan?
In dezelfde periode waren Nvidia kaarten zo goed als niet verkrijgbaar of je mocht €1500-€2500 neerleggen.
Misschien toch heel veel dat niet in de retail beland is.
*Brainfart moment*

https://www.tomshardware....op-discrete-gpu-shipments

[ Voor 3% gewijzigd door CMT op 31-08-2022 13:21 ]

[haarbal]

Ludewig schreef op woensdag 31 augustus 2022 @ 01:03:
Ik begrijp de strategie van Nvidia trouwens niet. Ze lijken te denken dat ze nog tijd genoeg hebben om de rest van de voorraad tegen relatief hoge prijzen weg te werken, maar met een verwachte influx van miningkaarten op de 2e hands markt, een vermoedelijk nog veel verder afnemende vraag, vermoedelijk erg sterke concurrentie van AMD 7000 en wellicht zelfs nog concurrentie van Intel Arc, zou ik als ik hen was al veel eerder stevige kortingen hebben gegeven. Zoals AMD dat doet.

Ik zie die stevige kortingen anders niet. Je hebt een asrock 6800 die vrij goedkoop is, maar verder valt het tegen, en een 6700xt is duurder dan een 3060ti.

[Dennism]

CMT schreef op woensdag 31 augustus 2022 @ 04:37:

Nvidia heeft in de tijd van de 2e Cryptoboom, ca. 4x zoveel kaarten verscheept dan AMD.
En het dGPU marktaandeel is in die tijd gekrompen?

Zo vreemd dat niet, het gaat immers om marktaandeel, en dus gpu dies verscheept door deze partijen in een bepaald tijdvak, in dit geval is verschepen als het goed is gelijk aan verkopen, want deze cijfers duiden voor zover mij bekend niet de retail verkopen, maar de verkopen van AMD, Nvidia en Intel naar hun afnemers ongeacht wie dat zijn.

Voorbeeld, stel dat in Q1 2022 Nvidia 8 miljoen chips verscheept en AMD 2 miljoen (Intel doet even niet mee voor de eenvoud. Het markt aandeel voor dat kwartaal is dan 80% Nvidia, 20% AMD.

Het kwartaal erna verkoopt Nvidia 7.9 miljoen en AMD 2.1 miljoen kaarten. Het marktaandeel is nu 79% om 21%, Nvidia verscheept dus nog altijd bijna 4 units voor iedere unit die AMD verscheept, maar ze verliezen toch 1% marktaandeel .

[XWB]

Inderdaad, het gaat om kwartaalverkopen.

Boeing en Airbus drukken hun marktaandeel uit in de hoeveelheid vliegtuigen die actief zijn. Dus als je een andere metric wil zou je kunnen opzoeken hoeveel computers in de wereld actief zijn met Nvidia en AMD videokaarten.

[Dennism]

XWB schreef op woensdag 31 augustus 2022 @ 11:26:
Inderdaad, het gaat om kwartaalverkopen.

Boeing en Airbus drukken hun marktaandeel uit in de hoeveelheid vliegtuigen die actief zijn. Dus als je een andere metric wil zou je kunnen opzoeken hoeveel computers in de wereld actief zijn met Nvidia en AMD videokaarten.

Dat wordt echter in veel markten (waaronder IT) niet als marktaandeel gezien, maar als de metric installed base, wat inderdaad een volledig andere metric is.

Wikipedia: Installed base

Installed base (also install base, install[ed] user base or just user base) is a measure of the number of units of a product or service that are actually in use, as opposed to market share, which only reflects sales over a particular period.

Een relatief betrouwbare bron voor install base data onder gamers is bijvoorbeeld de Steam Survey, betrouwbare data voor install base over de gehele markt ken ik echter niet.

[ Voor 8% gewijzigd door Dennism op 31-08-2022 11:41 ]

[CMT]

@Dennism
Je hebt helemaal gelijk, ik was in de war vanochtend. In de alinea daarvoor, nota bene zelf over relatieve en absolute getallen gesproken ><.
Maar wat Tomshardware noteert klopt dus ook niet? In de titel worden aantallen discrete desktop kaarten genoemd niet chip's/die's.

[Ludewig]

haarbal schreef op woensdag 31 augustus 2022 @ 11:00:
[...]

Ik zie die stevige kortingen anders niet. Je hebt een asrock 6800 die vrij goedkoop is, maar verder valt het tegen, en een 6700xt is duurder dan een 3060ti.

De prijzen verschillen soms wel erg per regio. In de VS is de laagste prijs voor een 6700 XT vrijwel identiek aan de laagste prijs voor een 3060 Ti, terwijl de 6700 XT sneller is en meer geheugen heeft.

[Dennism]

CMT schreef op woensdag 31 augustus 2022 @ 12:36:
@Dennism
Je hebt helemaal gelijk, ik was in de war vanochtend. In de alinea daarvoor, nota bene zelf over relatieve en absolute getallen gesproken ><.
Maar wat Tomshardware noteert klopt dus ook niet? In de titel worden aantallen discrete desktop kaarten genoemd niet chip's/die's.

Ik vermoed eigenlijk van niet, kijkende naar de bron (die Tom ook gebruikt):

https://www.jonpeddie.com...ents-quarter-to-quarter-a

Staat daar bijv.

Overall GPU unit shipments decreased by -14.9% from last quarter. AMD’s shipments decreased by -7.6%, Intel’s shipments decreased by -9.8%, and Nvidia’s shipments decreased by -25.7%.

Dat zal toch echt om de chips gaan en niet om kaarten, aangezien daar ook APU's e.d. inzitten.

Misschien dat Tom (door te betalen), maar ook dat weet ik niet.

Tom benoemd bijv. als grafiek titel 'Shipments of Desktop Discrete Graphic Cards by AMD and Nvidia', volgens mij zijn die getallen echter de verscheepte dies, AMD en Nvidia shippen immers maar een klein deel van de kaarten zelf, de rest verkopen ze als chip of als chip + memory kit aan AIB's en OEM's. Nvidia verscheept bijv. echt geen 10 miljoen FE kaarten per kwartaal, als de totale markt maximaal zo'n 13 miljoen dGPU's is in dat kwartaal zoals Sunsmountain enkele dagen geleden liet zien.

[ Voor 7% gewijzigd door Dennism op 31-08-2022 12:59 ]

[sunsmountain]

Er viel me trouwens op dat Lisa Su weer zei: Navi 3, using N5 chiplets, meervoud.

Ze zal N5+N6 chiplets bedoelen, maar tegelijkertijd, als AMD toch voor een Zen Epyc server approach is gegaan, dat zou de verrassing van het jaar zijn.

[Ludewig]

sunsmountain schreef op woensdag 31 augustus 2022 @ 13:15:
Er viel me trouwens op dat Lisa Su weer zei: Navi 3, using N5 chiplets, meervoud.

Ze zal N5+N6 chiplets bedoelen, maar tegelijkertijd, als AMD toch voor een Zen Epyc server approach is gegaan, dat zou de verrassing van het jaar zijn.

Ik zou er niet teveel achter zoeken. Su denkt in principe in honderdduizenden of miljoenen units van Navi 3 en in vergelijkbare aantallen wanneer het gaat om de chipbestellingen bij TSMC.

Vanuit het perspectief als consument denken we veel meer in wat er op 1 kaart zit, maar vanuit het perspectief van de top van AMD gaat het veel meer om de grote aantallen.

[Sp3ci3s8472]

Paprika schreef op dinsdag 30 augustus 2022 @ 10:00:
In 2020 ergens gaf Nvidia aan dat ze meer met de Tensor cores wilden gaan doen, maar in welke mate dat is gelukt valt nergens te vinden.

Ik vermoed dat dat meer op Tensor cores pas wat gaat worden als de consoles/AMD en Intel een vergelijkbare optie hebben. Tot die tijd zal Nvidia per game er een zak geld tegenaan moeten gooien. Hetzelfde zag je met tesselation daar werd pas echt gebruik van gemaakt toen Nvidia het ook had.

Jammer want vooruitgang is daardoor trager; Aan de andere kant ook wel goed want vaak als Nvidia iets zou implementeren dan is het vaak als gesloten standaard en wordt het pas open als er geen interesse meer in is.

[sunsmountain]

Ludewig schreef op woensdag 31 augustus 2022 @ 13:26:
[...]


Ik zou er niet teveel achter zoeken. Su denkt in principe in honderdduizenden of miljoenen units van Navi 3 en in vergelijkbare aantallen wanneer het gaat om de chipbestellingen bij TSMC.

Vanuit het perspectief als consument denken we veel meer in wat er op 1 kaart zit, maar vanuit het perspectief van de top van AMD gaat het veel meer om de grote aantallen.

Ja als CEO begrijp ik dat wel, maar als ingenieur, wat haar achtergrond is, snap ik het niet zo goed. Het zal wel niks zijn, gezien de nauwkeurig lijkende leak van Angstronomics (die trouwens niet zo positief is over de competitiviteit van Zen4, iets wat je van een insider juist wel zou verwachten).

[Dennism]

Even een crosspost vanuit het Nvidia topic:

Wat ander nieuws: https://edition.cnn.com/2...block-intl-hnk/index.html

En wat hoort daar dan voor (schrik) reactie bij: https://www.nasdaq.com/market-activity/stocks/nvda
AMD idem: https://www.nasdaq.com/market-activity/stocks/amd

[sunsmountain]

DaniëlWW2 schreef op zondag 28 augustus 2022 @ 14:53:
[...]

Incorrect.

Dit is wat Navi 21 en GA102 doen. Beiden zijn veel te langzaam voor een CPU. GA102 haar L2 cache alleen al gaat al behoorlijk richting het dubbele van wat een CPU naar DRAM doet.
[Afbeelding]

Ondertussen was AMD er terecht trots op dat met Zen 2, sub 70ns haalden naar DRAM met een chiplet architectuur.
[Afbeelding]

Of als ik het in een tabel zet, tja L1 cache voor zowel Navi 21 als GA102 is al langzamer dan L3 voor Zen 3 of Alder Lake.
[Afbeelding]
https://chipsandcheese.com/memory-latency-data/

Een GPU is dan ook min of meer de lopende bandfabriek onder de ICs. Het hele punt is dat je een input hebt, langs alle stations van de pipeline gaat die telkens een volgende stap doen en er iets uitkomt. Constant wachten op andere inputs van buiten de lopende band, verstoort het proces enorm.

Dit is ook het fundamentele probleem met RT. Opeens is er een workload geïntroduceerd die juist al die data die normaal gesproken doorgeduwd werd naar VRAM en dan je beeldscherm, moet kunnen gebruiken. Vervolgens is er heel weinig gedaan om dit probleem op te lossen. Wat je namelijk nodig hebt is enorm capabele RT units met hun eigen caches die compleet onafhankelijk van de rest van de GPU pipeline, deze berekeningen gaan uitvoeren.

Dat is er niet. Intel komt nog een beetje in de buurt en ik vermoed dat dit een van de redenen is waarom Alchemist zo groot uitvalt voor de prestatiepunten. AMD heeft een zeer simplistische implementatie gedaan omdat ze waarschijnlijk geen interesse/transistorbudget/R&D middelen hadden om dit goed te doen naast de rest. Ondanks dat het zeer pover is, presteert het alsnog rond Turing niveau.

Nvidia krijgt van mij geen genade omdat ze nu al vier jaar lopen te roepen hoe geweldig RT(X) is. Ze hebben letterlijk de naamgeving van hun producten veranderd voor RT(X). Het is elke marketing event, RT(X) dit, RT(X) dat. Voor een bedrijf dat het alleen maar over RT(X) kan hebben als een basisvoorwaarde voor de aanschaf van een videokaart, is hun hardware knap waardeloos.

Dit is namelijk een Ampere processing block. Er is maar een stukje in een SM dat gedeeld is binnen een SM en dat is meteen het enige stuk dat direct aan L1 cache hangt. De RT core van Ampere is technisch ook capabeler dan wat AMD heeft, wederom dat is pover. Punt is dat zodra de RT core aan de slag gaat, de rest van de SM waarschijnlijk geen toegang meer heeft tot L1 cache. Dat is allemaal voor de RT core. Die zit de reguliere ALU's gewoon in de weg op deze manier. De "oplossing" hier zou zijn dat de RT core haar eigen cache krijgt die data uit de reguliere L1 cache trekt. Maar dan alsnog heb je het probleem dat denoising op de Tensor Core draait waardoor je alsnog pipeline stalls krijgt. En onder de streep is al die extra investering in transistoren en R&D, niet bepaald vertaald in een grote sprong in capaciteiten.
[Afbeelding]

CJ's AMD Radeon topic: hèt topic waar we dingen leren. Inderdaad en ik wist het niet, CPU latency is stukken lager. Maar. De gevoeligheid voor wijziging in latency is bij GPU daardoor nog steeds stukken groter. Wat het eerste deel van mijn uitspraak was. Alleen heb je voor GPUs niet een lagere geheugentoegang snelheid nodig. Dat deel was fout.

Vertragingen in de GPU berekening (en dus latency van de berekening, loops, conditional branches, etc. niet zo zeer de geheugen toegang zelf) leiden tot frame stutter en zijn goed merkbaar. Vertragingen in de CPU merk je waarschijnlijk niet eens 99/100 keer. En die keer dat je het merkt is het waarschijnlijk gewoon een BSOD.

In wezen bevestig je dat ook door te zeggen:

Constant wachten op andere inputs van buiten de lopende band, verstoort het proces enorm.

Dat is wat ik probeerde te zeggen en te benadrukken dat latency voor deze inputs funest is!

[DaniëlWW2]

sunsmountain schreef op zondag 4 september 2022 @ 23:41:
[...]


CJ's AMD Radeon topic: hèt topic waar we dingen leren. Inderdaad en ik wist het niet, CPU latency is stukken lager. Maar. De gevoeligheid voor wijziging in latency is bij GPU daardoor nog steeds stukken groter. Wat het eerste deel van mijn uitspraak was. Alleen heb je voor GPUs niet een lagere geheugentoegang snelheid nodig. Dat deel was fout.

Vertragingen in de GPU berekening (en dus latency van de berekening, loops, conditional branches, etc. niet zo zeer de geheugen toegang zelf) leiden tot frame stutter en zijn goed merkbaar. Vertragingen in de CPU merk je waarschijnlijk niet eens 99/100 keer. En die keer dat je het merkt is het waarschijnlijk gewoon een BSOD.

In wezen bevestig je dat ook door te zeggen:

[...]

Dat is wat ik probeerde te zeggen en te benadrukken dat latency voor deze inputs funest is!

Het punt van de GPU is juist dat ze veel minder problemen hebben met data terughalen naar rekeneenheden, omdat het relatief minder vaak voortkomt dan met CPU's. CPU's zijn dan ook seriële rekenmachines waar GPU's parallelle rekenmachines zijn. Compleet ander type workload met zo haar eigen eigenaardigheden. Er is verder een reden waarom de nieuwste trend in CPU land het vergroten van L2 cache is. L1 is altijd een "ik moet het nu hebben" cache. Een cache groter maken betekend meestal ook dat toegang meer clock cycles kost en met L1 wil je dat niet. L2 is grotere een per core cache waar tegenwoordig een of een paar clock cycles worden uitgeruild voor veel groter formaat zodat meer data direct beschikbaar is voor die core.

Omdat GPU's hier veel minder problemen of noodzaak aan hebben, komen ze ook weg met relatief weinig en alsmede relatief kleine caches. RDNA is hier eigenlijk de vreemde uitzondering omdat AMD hier iets meer richting het denken van CPU's lijkt te zijn gegaan. De reden lijkt me overduidelijk als je weet dat een aantal belangrijke mensen van het oorspronkelijke Zen team naar de Radeon afdeling zijn overgeplaatst om daar ook orde op zaken te stellen. Het werkt overigens ook behoorlijk goed.

De beperkte noodzaak voor caches is ook het fundamentele probleem met RT. Opeens is er een workload die niet erg fijn in de "lopende band" past. Nee dit er er eentje juist zeer data-intensief en verstorend is. De uiteindelijke oplossing is heel veel transistoren tegen het probleem aangooien en dat blijkt lastig omdat de kosten per node zo explosief stijgen alsmede het verbruik. Dat is uiteindelijk ook het grootste voordeel van RDNA2 haar aanpak. Het is zeker niet de beste RT implementatie, maar deze zal ook erg weinig ruimte innemen op de GPU.

[sunsmountain]

Hey, dit is wel interessant:
https://wccftech.com/amd-...ompute-unit-shader-array/

L0 Vector Register File per SIMD:
192KiB vs 128KiB

L0 Vector Data (per CU) 32KiB vs 32KiB
L1 Scalar Inst. (per WGP) 32KiB vs 32KiB
L1 Scalar Data (per WGP)16KiB vs 16KiB

GL1 Date (per SA):
256KiB vs 128KiB

L2 Data:
2048KiB (2MiB) vs 4096KiB

Meer Register File voor de 8 SIMDs per WGP en meer GL1 data...
Maar minder L2 data, interessant...

[ Voor 56% gewijzigd door sunsmountain op 08-09-2022 00:17 ]

[Werelds]

sunsmountain schreef op woensdag 7 september 2022 @ 22:52:
Hey, dit is wel interessant:
https://wccftech.com/amd-...ompute-unit-shader-array/

L0 Vector Register File per SIMD:
192KiB vs 128KiB

L0 Vector Data (per CU) 32KiB vs 32KiB
L1 Scalar Inst. (per WGP) 32KiB vs 32KiB
L1 Scalar Data (per WGP)16KiB vs 16KiB

GL1 Date (per SA):
256KiB vs 128KiB

L2 Data:
2048KiB (2MiB) vs 4096KiB

Meer Register File voor de 8 SIMDs per WGP en meer GL1 data...
Maar minder L2 data, interessant...

Logische wijzigingen als het 256 ALU per WGP wordt - of dat daadwerkelijk 8 sets registers wordt laat ik even in het midden. Ik ben er nog niet van overtuigd dat er 8 SIMD's met hun eigen sets registers komen, daar zou AMD best wel eens iets anders kunnen verzinnen

Waarom WCCF de scalar caches L1 noemt weet ik niet, dat is gewoon L0, het zit binnen een WGP. En aangezien er qua scalars niets veranderd lijkt te worden, hoeft daar ook niets anders qua opslag.

L1 wordt verdubbeld om er voor te zorgen dat ze even veel data in een SA kunnen houden als voorheen. Doen ze dat niet, hebben ze ineens dubbel zo veel ALU's die op hetzelfde stukje geheugen zitten. Tegelijkertijd is die verdubbeling waarschijnlijk meer dan ze nodig hebben, omdat de ALU's nu al veel op dezelfde data werken.

Qua L2 moet je echter niet vergeten dat dat over Navi 33 gaat, niet 31. Dus dat zakt niet van 4 MB naar 2, dat blijft 2 MB ten opzichte van Navi 23. Met meer shader engines zal er vrijwel zeker ook meer L2$ komen, omdat je anders te veel druk op de L2 gaat zetten. Ik geloof er dus niets van dat N32 het met 2 MB moet gaan doen, laat staan N31. Dat zal eerder 4 en 6 worden. Wellicht zelfs meer omdat het ná de L2 iets verder weg zit.

[DaniëlWW2]

Werelds schreef op donderdag 8 september 2022 @ 12:45:
[...]

Logische wijzigingen als het 256 ALU per WGP wordt - of dat daadwerkelijk 8 sets registers wordt laat ik even in het midden. Ik ben er nog niet van overtuigd dat er 8 SIMD's met hun eigen sets registers komen, daar zou AMD best wel eens iets anders kunnen verzinnen

Er veranderd in ieder geval iets. Paar maanden geleden werd uit die Linux patches al duidelijk dat RDNA3 een single issue wave64 mode heeft. Een SIMD64 die ook 2x SIMD32 kan doen, lijkt ergens de meest logische aanname. Een aanname die ook ondersteund lijkt te worden. Ook lijkt Navi 33 juist geen uitbreiding van vector register file te krijgen.

Waarom WCCF de instructie/data caches L1 noemt weet ik niet, dat is gewoon L0, het zit binnen een WGP. En aangezien er qua scalars niets veranderd lijkt te worden, hoeft daar ook niets anders qua opslag.

L1 wordt verdubbeld om er voor te zorgen dat ze even veel data in een SA kunnen houden als voorheen. Doen ze dat niet, hebben ze ineens dubbel zo veel ALU's die op hetzelfde stukje geheugen zitten. Tegelijkertijd is die verdubbeling waarschijnlijk meer dan ze nodig hebben, omdat de ALU's nu al veel op dezelfde data werken.

Qua L2 moet je echter niet vergeten dat dat over Navi 33 gaat, niet 31. Dus dat zakt niet van 4 MB naar 2, dat blijft 2 MB ten opzichte van Navi 23. Met meer shader engines zal er vrijwel zeker ook meer L2$ komen, omdat je anders te veel druk op de L2 gaat zetten. Ik geloof er dus niets van dat N32 het met 2 MB moet gaan doen, laat staan N31. Dat zal eerder 4 en 6 worden. Wellicht zelfs meer omdat het ná de L2 iets verder weg zit.

Komt nog bij dat L3 cache waarschijnlijk op de aparte MCD chiplets zitten. De druk op L2 zal dus eerder nog iets groter gaan worden zelfs als je de sterk vermoedde toename in aantal ALU's negeert.

[dutchnltweaker]

Wat ik me afvraag, prijzen dalen van de RDNA2 videokaarten. Gaan die van de RDNA3 niet stijgen in prijs door de koers van de euro ten op zichten van de dollar en gaan die kaarten wel een hele verbetering zijn? ik miste de boot al eens door de hoge prijzen, maar nu kan je de 6700xt bijvoorbeeld voor een nette prijs kopen.

[Snowdog]

dutchnltweaker schreef op donderdag 8 september 2022 @ 14:16:
Wat ik me afvraag, prijzen dalen van de RDNA2 videokaarten. Gaan die van de RDNA3 niet stijgen in prijs door de koers van de euro ten op zichten van de dollar en gaan die kaarten wel een hele verbetering zijn? ik miste de boot al eens door de hoge prijzen, maar nu kan je de 6700xt bijvoorbeeld voor een nette prijs kopen.

Die koers van de euro ten opzichte van de dollar is voor RDNA2-kaarten niet anders. Ze hebben die kaarten voor lange tijd voor veel te veel geld kunnen verkopen, die prijsverlagingen nu zijn nog niet eens zo enorm en dat is dan ook niet zo verrassend.

Ik heb natuurlijk geen idee wat de RDNA3-kaarten gaan kosten, maar als ze willen, kunnen ze die nog altijd tegen vrij "redelijke" (tov vorig jaar) in de markt zetten. Wat ze ook gaan kosten, dat hangt vooral af wat ze ervoor denken te kunnen vragen. Denk niet dat ze uitzonderlijk duur gaan zijn met de afnemende vraag, maar who knows.

[DaniëlWW2]

dutchnltweaker schreef op donderdag 8 september 2022 @ 14:16:
Wat ik me afvraag, prijzen dalen van de RDNA2 videokaarten. Gaan die van de RDNA3 niet stijgen in prijs door de koers van de euro ten op zichten van de dollar en gaan die kaarten wel een hele verbetering zijn? ik miste de boot al eens door de hoge prijzen, maar nu kan je de 6700xt bijvoorbeeld voor een nette prijs kopen.

Niemand inclusief AMD weet de precieze prijzen in dollars nu al. Prijzen worden meestal pas op het laatste moment vastgesteld. Laat staan dat iemand een idee heeft wat de euro precies gaat doen. Komt bij dat de productiekosten waarschijnlijk hoger zullen zijn dan RDNA2 voor in ieder geval Navi 31/32. Staat tegenover dat de markt aan het inzakken is vanwege de wereldwijde problemen.

Niemand weet het dus voor N31/32. Navi 33 kan je wat meer over inschatten omdat die waarschijnlijk met vergelijkbare productiekosten als Navi 23 te maken heeft. Verder is het de laagste chip dus tenzij AMD helemaal doorslaat en bij $500 hun lijn begint, zal die waarschijnlijk niet al te duur uitvallen. Kan zomaar vergelijkbaar worden met de RX6600 series nu.

[dutchnltweaker]

@Snowdog @DaniëlWW2 Dank, deels duidelijk!
Als ik het goed begrijp komt de nieuwe serie eind dit jaar beschikbaar? Twijfel nog, wachten of nu de huidige series kopen. Als het werkelijk zo een vooruitgang is zoals ze zeggen dan is het misschien interessant om te wachten.

[DaniëlWW2]

dutchnltweaker schreef op donderdag 8 september 2022 @ 14:42:
@Snowdog @DaniëlWW2 Dank, deels duidelijk!
Als ik het goed begrijp komt de nieuwe serie eind dit jaar beschikbaar? Twijfel nog, wachten of nu de huidige series kopen. Als het werkelijk zo een vooruitgang is zoals ze zeggen dan is het misschien interessant om te wachten.

offtopic:
De volgende generatie zal altijd beter zijn, tenminste dat is wel het idee.
Nu lijkt met name RDNA3 ook daadwerkelijk heel wat nieuwe dingen te krijgen waardoor het fors sneller zou moeten zijn. Maar weten doen we dat niet zeker. Punt is dan ook niet wat de toekomst brengt, maar of je wil/kan wachten. Want op het moment is nog steeds bijna alles te duur.

[Apoca]

It’s time to upscale FSR 2 even further: Meet FSR 2.1

Ze zijn lekker bezig, zou mooi zijn als je net als met DLSS een file drop update kunt doen in de toekomst



https://gpuopen.com/meet-fidelityfx-super-resolution-2-1/

[ Voor 55% gewijzigd door Apoca op 08-09-2022 15:37 ]

[Ludewig]

Apoca schreef op donderdag 8 september 2022 @ 15:31:
It’s time to upscale FSR 2 even further: Meet FSR 2.1

https://gpuopen.com/meet-fidelityfx-super-resolution-2-1/

Ze zijn lekker bezig, zou mooi zijn als je net als met DLSS een file drop update kunt doen in de toekomst

Oh, ik wist niet dat dit kon. Dat zou inderdaad mooi zijn.

Zo te zien hebben ze vooral de ghosting verbeterd, wat je ook kunt zien in het voorbeeld.

[Apoca]

Ludewig schreef op donderdag 8 september 2022 @ 15:40:
[...]
Oh, ik wist niet dat dit kon. Dat zou inderdaad mooi zijn.

https://github.com/beeradmoore/dlss-swapper

[Ludewig]

Apoca schreef op donderdag 8 september 2022 @ 15:47:
[...]
https://github.com/beeradmoore/dlss-swapper

Ik vraag me wel af of je in bepaalde spellen dan niet gebanned gaat worden vanwege het hacken van de dll's.

[MneoreJ]

Ludewig schreef op donderdag 8 september 2022 @ 15:50:
Ik vraag me wel af of je in bepaalde spellen dan niet gebanned gaat worden vanwege het hacken van de dll's.

Goed mogelijk. Een lijst maken van welke games wel en niet veilig zijn is een open issue. Dit soort dingen zijn natuurlijk altijd voor eigen risico. Als je het op safe wil spelen moet je de grafische pracht en praal en modderij maar bij de single player games laten en voor MP je ultra low 720p 400 FPS instellingen uit de kast trekken zodat je hopelijk geen upscaling nodig hebt.

[DaniëlWW2]

Apoca schreef op donderdag 8 september 2022 @ 15:31:
It’s time to upscale FSR 2 even further: Meet FSR 2.1

Ze zijn lekker bezig, zou mooi zijn als je net als met DLSS een file drop update kunt doen in de toekomst

[Afbeelding]

https://gpuopen.com/meet-fidelityfx-super-resolution-2-1/

[YouTube: Farming Simulator 22 | 4K AMD FSR 2.1 Comparison]

Dat is sneller dan ik had verwacht. En meteen ook het grootste nadeel van FSR aanpakken in ghosting.
Nu kijken of je makkelijk bestanden kan wisselen.

[Sp3ci3s8472]

FSR 2.1 is uit!
https://www.phoronix.com/news/AMD-FidelityFX-FSR-2.1

Nu ff rondkijken of er al reviews zijn.

Ghosting lijkt een stuk minder te zijn als ik dat plaatje zo bekijk:
https://gpuopen.com/meet-fidelityfx-super-resolution-2-1/

[ Voor 36% gewijzigd door Sp3ci3s8472 op 08-09-2022 17:33 ]

[sunsmountain]

dutchnltweaker schreef op donderdag 8 september 2022 @ 14:42:
@Snowdog @DaniëlWW2 Dank, deels duidelijk!
Als ik het goed begrijp komt de nieuwe serie eind dit jaar beschikbaar? Twijfel nog, wachten of nu de huidige series kopen. Als het werkelijk zo een vooruitgang is zoals ze zeggen dan is het misschien interessant om te wachten.

Als je nog 1-2 maanden kan wachten, komen er aardig wat miner kaarten op de markt. Die zullen de prijzen van zowel oud als nieuw sterk naar beneden drukken.

[Snowdog]

Sp3ci3s8472 schreef op donderdag 8 september 2022 @ 17:31:
FSR 2.1 is uit!
https://www.phoronix.com/news/AMD-FidelityFX-FSR-2.1

Nu ff rondkijken of er al reviews zijn.

Ghosting lijkt een stuk minder te zijn als ik dat plaatje zo bekijk:
https://gpuopen.com/meet-fidelityfx-super-resolution-2-1/

Nice! Maar ghosting was met FSR 2 eigenlijk sowieso niet zo'n probleem toch? Op dat gebied leek FSR 2 sowieso al voor te lopen op DLSS, ik hoop dat ze de andere probleempjes waarmee DLSS toch ver voorliep op FSR 2 wat hebben weten te verbeteren.

[DaniëlWW2]

Snowdog schreef op vrijdag 9 september 2022 @ 09:30:
[...]


Nice! Maar ghosting was met FSR 2 eigenlijk sowieso niet zo'n probleem toch? Op dat gebied leek FSR 2 sowieso al voor te lopen op DLSS, ik hoop dat ze de andere probleempjes waarmee DLSS toch ver voorliep op FSR 2 wat hebben weten te verbeteren.

Het verschilt erg per game, per type textures en ook per implementatie.
Maar ze pakken meteen wel de grotere probleemgevallen aan. Beetje jammer alleen dat RDR2 net een dag voor FSR2.1, met 2.0 komt. Overigens krijgen Cyberpunk en MFS2022 ook FSR2.1.

edit: Vergelijking met gemodde 2.1 versies beginnen op te duiken. Je kan het zeker zien in RDR2.

Of deze. Let op rechtsboven de rook uit de schorsteen, het glazen afdak of wat extra scherpte of details. Het is minder dan RDR2, maar nog steeds.
https://imgsli.com/MTI0NjU5/0/1

[ Voor 26% gewijzigd door DaniëlWW2 op 09-09-2022 19:59 ]

[sunsmountain]

Werelds schreef op donderdag 8 september 2022 @ 12:45:
[...]

Logische wijzigingen als het 256 ALU per WGP wordt - of dat daadwerkelijk 8 sets registers wordt laat ik even in het midden. Ik ben er nog niet van overtuigd dat er 8 SIMD's met hun eigen sets registers komen, daar zou AMD best wel eens iets anders kunnen verzinnen

Waarom WCCF de scalar caches L1 noemt weet ik niet, dat is gewoon L0, het zit binnen een WGP. En aangezien er qua scalars niets veranderd lijkt te worden, hoeft daar ook niets anders qua opslag.

L1 wordt verdubbeld om er voor te zorgen dat ze even veel data in een SA kunnen houden als voorheen. Doen ze dat niet, hebben ze ineens dubbel zo veel ALU's die op hetzelfde stukje geheugen zitten. Tegelijkertijd is die verdubbeling waarschijnlijk meer dan ze nodig hebben, omdat de ALU's nu al veel op dezelfde data werken.

Qua L2 moet je echter niet vergeten dat dat over Navi 33 gaat, niet 31. Dus dat zakt niet van 4 MB naar 2, dat blijft 2 MB ten opzichte van Navi 23. Met meer shader engines zal er vrijwel zeker ook meer L2$ komen, omdat je anders te veel druk op de L2 gaat zetten. Ik geloof er dus niets van dat N32 het met 2 MB moet gaan doen, laat staan N31. Dat zal eerder 4 en 6 worden. Wellicht zelfs meer omdat het ná de L2 iets verder weg zit.

Eens, de verdubbeling van L1 zou kunnen zijn om de texture mapping of filter units meer gelijktijdig te kunnen laten raytracen op dezelfde data set, simultaan of concurrently met de SIMD ALU's.

Bedenk bij L2 dat kleinere L2 caches (net als L3) sneller kunnen zijn dan grotere L2 caches.
Huidig L2 RDNA2: Navi23 = 2MB , Navi22 = 3MB, Navi21 = 4MB.

Toekomstig L2 RDNA3: Navi33 = 2MB, Navi32 = 4MB, Navi33 = 6MB?
Of denk je L2 RDNA3: Navi33 = 4MB, Navi32 = 8MB, Navi33 = 12MB?

(WGP van 16 naar 30 naar 48 max).

[Werelds]

sunsmountain schreef op zaterdag 10 september 2022 @ 00:48:
Bedenk bij L2 dat kleinere L2 caches (net als L3) sneller kunnen zijn dan grotere L2 caches.
Huidig L2 RDNA2: Navi23 = 2MB , Navi22 = 3MB, Navi21 = 4MB.

Snelheid heeft minder met grootte te maken dan met de manier waarop het allemaal aan elkaar hangt; het is eerder zo dat de impact van de grootte juist af hangt van hoe het in elkaar hangt. Het is wel X MB L2$ in totaal, maar als puntje bij paaltje komt zijn het alsnog kleine blokjes die aan een bus hangen. Elk stuk L1 hangt in RDNA 1/2 aan een groep van 4x256 KB L2$ en kan 4x32B per clock versturen. De latency als er meer data in de L2 zit komt doordat het verder de bus in moet als het niet in die eerste 4 blokjes zit. Dus hoewel de L1 de hele L2 aan kan spreken, komt dat wel op een specifieke plek binnen. Dat is waarom die cache latency grafieken van een tijd terug niet 100% horizontaal zijn binnen een cache groep.

Met Navi 23 (of 33 dus) heb je stiekem dus met zoiets te maken vanuit latency bekeken:

code:

L1         L1
├─ L2 ┬ L2 ─┤
├─ L2 ┼ L2 ─┤
├─ L2 ┼ L2 ─┤
└─ L2 ┴ L2 ─┘

Nu kunnen ze daar wel wat mee spelen; zo heeft Navi 22 bijvoorbeeld 4 extra stukjes L2 (daar komt die extra MB vandaan; verder wel nog steeds 4x64B per clock van L1 naar L2), wat het een apart beestje maakt. Maar L2 wég halen gaat bandbreedte kosten.

Groter maken kost in principe dus ook wat latency, tenzij je gaat spelen met hoe dat aan elkaar hangt. Die 256 KB L1$ zouden ze bijvoorbeeld 8x64B kunnen geven, waarmee je dus meteen het dubbele aan L2$ krijgt als je daar ook blokjes van 256 KB blijft gebruiken. Dan gaat de maximale latency alsnog omhoog als iets helemaal aan de andere kant van de L2 zit, maar de gemiddelde latency zal niet of nauwelijks veranderen. Dat is een compromis dat je dan sluit. Ze kunnen ook een andere fysieke indeling gebruiken waarbij die paden korter worden.

Dit is ook allemaal waarom je bij AMD zo veel vaste verhoudingen ziet. Ze willen gewoon X bytes per clock kunnen versturen van deel L1 -> L2 -> IC, wat betekent dat als ze één van van die variabelen wijzigen, ze de rest ook beïnvloeden in de zin dat er een minimum is. Het maakt het geheel lekker voorspelbaar (/betrouwbaar) qua performance.

Toekomstig L2 RDNA3: Navi33 = 2MB, Navi32 = 4MB, Navi33 = 6MB?
Of denk je L2 RDNA3: Navi33 = 4MB, Navi32 = 8MB, Navi33 = 12MB?

(WGP van 16 naar 30 naar 48 max).

Nee, ik denk dat 33 gewoon op 2 MB blijft. Alles zit nog steeds binnen een enkele die, de verhoudingen van bovenaf zijn niet veranderd (32 MB IC aan een 128-bit geheugen bus), het is enkel dat er meer L1 aan de L2 komt te hangen. Ik denk wel dat de data lijntjes iets anders zullen zijn, ik weet niet of 4x64B genoeg is als er 256 KB gevoed moet worden. Áls de L2 daar omhoog gaat zal dat vooral te maken hebben met dat voeden dan iets anders.

Navi 32 en 31 denk ik dat een geheel andere indeling krijgen. Volgens die geruchten is 32 pakweg Navi 21 (4 SE's, 256-bit bus), maar met minder IC dan Navi 22. Voor die 4 SE's willen ze ook genoeg bandbreedte behouden vanuit de L1, dus die 4 MB van 21 blijft op z'n minst behouden. 32/31 krijgen mínstens respectievelijk 2 en 3 keer de hoeveelheid L2 van 33 (dus 4 en 6), omdat ze anders minder over houden vanuit de SE's - die verhouding gaat niet minder worden, zeker niet als de L1 dubbel zo groot wordt. Daarnaast komt de IC verder weg te zitten, waardoor ze wellicht nóg meer L2 willen hebben.

Dus jouw eerste voorbeeld zou best kunnen, maar het tweede denk ik dat overkill is voor 33. Het zou wellicht zelfs 2-6-8 of 2-6-12 kunnen worden. 33 wordt denk ik gewoon een ander verhaal dan de andere twee, met andere verhoudingen. Cru gesteld is het is gewoon Navi 23, maar met dubbel zo veel ALU's en L1. Ik weet niet of meer L2 überhaupt zou helpen. Het zou ook zomaar een hele interessante chip kunnen worden voor 1080p.


Edit: totaal aantal WGP's is overigens niet zo boeiend, het gaat vooral om hoe veel stukken L1 er zijn en dus om hoe de SE's in elkaar zitten. We hebben al gezien dat ze best meer WGP's aan een stuk L1 willen hangen binnen een SE. Die 30 WGP's van 32 is ook volstrekt onlogisch met 4 SE's, de volle chip moet daar gewoon een veelvoud van 4 hebben (waarschijnlijk dus 32). Anders moet de term Shader Engine ook de deur uit. 31 heeft in hun tabel 8 WGP's per SE, net als 33; 32 is dus 99% zeker ook 8 WGP per SE, wat hem 32 WGP's geeft.

Veel cijfertjes

[ Voor 8% gewijzigd door Werelds op 10-09-2022 15:00 ]

[DaniëlWW2]

sunsmountain schreef op zaterdag 10 september 2022 @ 00:48:
[...]


Eens, de verdubbeling van L1 zou kunnen zijn om de texture mapping of filter units meer gelijktijdig te kunnen laten raytracen op dezelfde data set, simultaan of concurrently met de SIMD ALU's.

Nee daar is L1 niet voor.
L1 is de Shader Array cache voor vier of vijf WGP's. Omdat de WGP's in aantal ALU's lijken te verdubbelen, verdubbelt L1 cache ook. RT doet AMD met Vector Register File + ALU's + RA unit en zoals ik laatst al zei, verwacht ik niet dat het gaat veranderen.

Bedenk bij L2 dat kleinere L2 caches (net als L3) sneller kunnen zijn dan grotere L2 caches.
Huidig L2 RDNA2: Navi23 = 2MB , Navi22 = 3MB, Navi21 = 4MB.

Toekomstig L2 RDNA3: Navi33 = 2MB, Navi32 = 4MB, Navi33 = 6MB?
Of denk je L2 RDNA3: Navi33 = 4MB, Navi32 = 8MB, Navi33 = 12MB?

(WGP van 16 naar 30 naar 48 max).

L2 hangt waarschijnlijk aan het aantal Shader Engines, dus twee Shader Array's. Omdat Navi 33 twee SE heeft, lijkt het dus 2MB aan L2 te worden. Een Navi 33 SA lijkt vervolgens te bestaan uit 4x WGP.

Navi 32 zou heel anders zijn. Drie SE's en zes SA die elk bestaan uit elk vijf WGP's. De logica hier zou dan 3MB L2 cache zijn, maar dat is waarschijnlijk te weinig. Dit ding zou high end zijn, geheugencapaciteitsvereisten zijn eerder exponentieel dan linear (om cache misses te reduceren) en er is al meer druk op L1 vanwege de extra WGP. Ergo minstens 4MB L2 is hier waarschijnlijk te verwachten.

Navi 31 zou vervolgens zes SE's en twaalf SA's zijn. Navi 31 gaat dus terug naar 4x WGP per SA. Je hier zeker rekenen op minstens 6MB L2 (1MB per SE).

[sunsmountain]

DaniëlWW2 schreef op zaterdag 10 september 2022 @ 12:37:
[...]

Nee daar is L1 niet voor.
L1 is de Shader Array cache voor vier of vijf WGP's. Omdat de WGP's in aantal ALU's lijken te verdubbelen, verdubbelt L1 cache ook. RT doet AMD met Vector Register File + ALU's + RA unit en zoals ik laatst al zei, verwacht ik niet dat het gaat veranderen.

Dat is precies wat de leak wel vermeldt:

L0 Vector Register File per SIMD:
192KiB vs 128KiB

Maar ray tracing is dan geen verklaring voor de L1 cache, inderdaad.

DaniëlWW2 schreef op zaterdag 10 september 2022 @ 12:37:

[...]

L2 hangt waarschijnlijk aan het aantal Shader Engines, dus twee Shader Array's. Omdat Navi 33 twee SE heeft, lijkt het dus 2MB aan L2 te worden. Een Navi 33 SA lijkt vervolgens te bestaan uit 4x WGP.

Navi 32 zou heel anders zijn. Drie SE's en zes SA die elk bestaan uit elk vijf WGP's. De logica hier zou dan 3MB L2 cache zijn, maar dat is waarschijnlijk te weinig. Dit ding zou high end zijn, geheugencapaciteitsvereisten zijn eerder exponentieel dan linear (om cache misses te reduceren) en er is al meer druk op L1 vanwege de extra WGP. Ergo minstens 4MB L2 is hier waarschijnlijk te verwachten.

Navi 31 zou vervolgens zes SE's en twaalf SA's zijn. Navi 31 gaat dus terug naar 4x WGP per SA. Je hier zeker rekenen op minstens 6MB L2 (1MB per SE).

2MB per SE in Navi33, dat zou dan 4MB worden met 2 SE.
Navi32 zou 6MB ipv 3MB worden (waarom een rare 4MB, 3x1,3333 MB?) met 3 SE.
Navi33 kan dan de 12 MB halen met 6 SE.

Navi 33 - 32 - 31
4 - 6 - 12 MB L2 cache

klinkt logisch.

[DaniëlWW2]

sunsmountain schreef op zaterdag 10 september 2022 @ 14:50:
[...]

Dat is precies wat de leak wel vermeldt:

L0 Vector Register File per SIMD:
192KiB vs 128KiB

Maar ray tracing is dan geen verklaring voor de L1 cache, inderdaad.

Het gaat dan dan ook al iets van een maand rond.

2MB per SE in Navi33, dat zou dan 4MB worden met 2 SE.
Navi32 zou 6MB ipv 3MB worden (waarom een rare 4MB, 3x1,3333 MB?) met 3 SE.
Navi33 kan dan de 12 MB halen met 6 SE.

Navi 33 - 32 - 31
4 - 6 - 12 MB L2 cache

klinkt logisch.

Nee het is 1MB L1 per SE.
Verder is het hele punt juist dat qua structuur, Navi 33 op Navi 23 zou lijken. Het grootste verschil is dat ze de WGP's in ALU's verdubbelen en dus ook L1 cache per SA. Uiteraard zullen ze backend dan ook aanpakken, maar daar lijken toch al dingen te veranderen voor RDNA3.

Kom je dus uit op 2MB L2 voor twee SE.

Er zijn zelfs de vermoedens dat een Navi 33 chip best direct op een Navi 23 PCB geplaatst zou kunnen worden. Iets waar ik ook op hoop omdat dit betekend dat we vanaf dag een de partnermodellen hebben.

[ Voor 5% gewijzigd door DaniëlWW2 op 10-09-2022 15:21 ]

[sunsmountain]

Werelds schreef op zaterdag 10 september 2022 @ 12:10:
[...]

Snelheid heeft minder met grootte te maken dan met de manier waarop het allemaal aan elkaar hangt; het is eerder zo dat de impact van de grootte juist af hangt van hoe het in elkaar hangt. Het is wel X MB L2$ in totaal, maar als puntje bij paaltje komt zijn het alsnog kleine blokjes die aan een bus hangen. Elk stuk L1 hangt in RDNA 1/2 aan een groep van 4x256 KB L2$ en kan 4x32B per clock versturen. De latency als er meer data in de L2 zit komt doordat het verder de bus in moet als het niet in die eerste 4 blokjes zit. Dus hoewel de L1 de hele L2 aan kan spreken, komt dat wel op een specifieke plek binnen. Dat is waarom die cache latency grafieken van een tijd terug niet 100% horizontaal zijn binnen een cache groep.

Met Navi 23 (of 33 dus) heb je stiekem dus met zoiets te maken vanuit latency bekeken:

code:

L1         L1
├─ L2 ┬ L2 ─┤
├─ L2 ┼ L2 ─┤
├─ L2 ┼ L2 ─┤
└─ L2 ┴ L2 ─┘

Nu kunnen ze daar wel wat mee spelen; zo heeft Navi 22 bijvoorbeeld 4 extra stukjes L2 (daar komt die extra MB vandaan; verder wel nog steeds 4x64B per clock van L1 naar L2), wat het een apart beestje maakt. Maar L2 wég halen gaat bandbreedte kosten.

Interessant, impliceert dat L2 gelijk houden (in verhouding tot de andere ondelen) het verstandigste is.

Werelds schreef op zaterdag 10 september 2022 @ 12:10:
Groter maken kost in principe dus ook wat latency, tenzij je gaat spelen met hoe dat aan elkaar hangt. Die 256 KB L1$ zouden ze bijvoorbeeld 8x64B kunnen geven, waarmee je dus meteen het dubbele aan L2$ krijgt als je daar ook blokjes van 256 KB blijft gebruiken. Dan gaat de maximale latency alsnog omhoog als iets helemaal aan de andere kant van de L2 zit, maar de gemiddelde latency zal niet of nauwelijks veranderen. Dat is een compromis dat je dan sluit. Ze kunnen ook een andere fysieke indeling gebruiken waarbij die paden korter worden.

Dit is ook allemaal waarom je bij AMD zo veel vaste verhoudingen ziet. Ze willen gewoon X bytes per clock kunnen versturen van deel L1 -> L2 -> IC, wat betekent dat als ze één van van die variabelen wijzigen, ze de rest ook beïnvloeden in de zin dat er een minimum is. Het maakt het geheel lekker voorspelbaar (/betrouwbaar) qua performance.

Ja, dat was mij ook opgevallen, ik vermoed dat de AMD ingenieurs daar een sterke voorkeur voor hebben.

Werelds schreef op zaterdag 10 september 2022 @ 12:10:
Nee, ik denk dat 33 gewoon op 2 MB blijft. Alles zit nog steeds binnen een enkele die, de verhoudingen van bovenaf zijn niet veranderd (32 MB IC aan een 128-bit geheugen bus), het is enkel dat er meer L1 aan de L2 komt te hangen. Ik denk wel dat de data lijntjes iets anders zullen zijn, ik weet niet of 4x64B genoeg is als er 256 KB gevoed moet worden. Áls de L2 daar omhoog gaat zal dat vooral te maken hebben met dat voeden dan iets anders.

Navi 32 en 31 denk ik dat een geheel andere indeling krijgen. Volgens die geruchten is 32 pakweg Navi 21 (4 SE's, 256-bit bus), maar met minder IC dan Navi 22. Voor die 4 SE's willen ze ook genoeg bandbreedte behouden vanuit de L1, dus die 4 MB van 21 blijft op z'n minst behouden. 32/31 krijgen mínstens respectievelijk 2 en 3 keer de hoeveelheid L2 van 33 (dus 4 en 6), omdat ze anders minder over houden vanuit de SE's - die verhouding gaat niet minder worden, zeker niet als de L1 dubbel zo groot wordt. Daarnaast komt de IC verder weg te zitten, waardoor ze wellicht nóg meer L2 willen hebben.

Dus jouw eerste voorbeeld zou best kunnen, maar het tweede denk ik dat overkill is voor 33. Het zou wellicht zelfs 2-6-8 of 2-6-12 kunnen worden. 33 wordt denk ik gewoon een ander verhaal dan de andere twee, met andere verhoudingen. Cru gesteld is het is gewoon Navi 23, maar met dubbel zo veel ALU's en L1. Ik weet niet of meer L2 überhaupt zou helpen. Het zou ook zomaar een hele interessante chip kunnen worden voor 1080p.

De Navi33 met 2 MB L2 cache in totaal zou wel weinig zijn voor een "6800XT/6900XT" level performance, maar past op zich bij de Navi23 indeling en de 128-bit bus. Dat is dan 1MB L2 cache per SE.

Navi32 krijgt volgens RGT en Angstronomics 3 SE's ipv 4 SE's, dan ook 3MB ipv 4MB.

Navi31 is inderdaad 3 keer Navi33, dus dan 6MB.

Als dat voor Navi31/32 te weinig is door de grotere L1, lijkt L2 best wel eens 2-6-12 te kunnen worden.

Werelds schreef op zaterdag 10 september 2022 @ 12:10:

Edit: totaal aantal WGP's is overigens niet zo boeiend, het gaat vooral om hoe veel stukken L1 er zijn en dus om hoe de SE's in elkaar zitten. We hebben al gezien dat ze best meer WGP's aan een stuk L1 willen hangen binnen een SE. Die 30 WGP's van 32 is ook volstrekt onlogisch met 4 SE's, de volle chip moet daar gewoon een veelvoud van 4 hebben (waarschijnlijk dus 32). Anders moet de term Shader Engine ook de deur uit. 31 heeft in hun tabel 8 WGP's per SE, net als 33; 32 is dus 99% zeker ook 8 WGP per SE, wat hem 32 WGP's geeft.

Veel cijfertjes

We zagen met Navi2x al verschillen tussen de SE's, Navi23 met 2x2x8 CU SE's, en Navi22 met 2x2x10 CU SE's. De ene SE is de andere niet
Dan zou het verdubbelen van L2 voor Navi31/32 ook logisch zijn, om de verschillen in SE op te vangen.

[Werelds]

sunsmountain schreef op zaterdag 10 september 2022 @ 15:25:
De Navi33 met 2 MB L2 cache in totaal zou wel weinig zijn voor een "6800XT/6900XT" level performance, maar past op zich bij de Navi23 indeling en de 128-bit bus. Dat is dan 1MB L2 cache per SE.

Voor Navi 21 had dat dus vooral met data lijntjes te maken, niet zo zeer met wat er nodig was. Zij kunnen meer zien dan wij, dus ik zou er helemaal niet raar van opkijken als N33 inderdaad 2 SE/16 WGP/4096 ALU wordt met 2 MB L2$ en dan daadwerkelijk N21 evenaart...op 1080p. Want ik denk dat dat de clou is.

Vergelijk Navi 23 maar eens met Navi 10: vergelijkbare FP32 performance op papier, (23 compenseert de 20% minder ALU's met kloksnelheid), maar 23 heeft slechts de helft aan geheugen bus en de helft aan L2$. IC compenseert dat eerste, maar dat laatste niet helemaal. En toch verslaat hij Navi 10 ruim op 1080p. Op 1440p kruipt Navi 10 iets dichterbij, maar is 23 nog steeds ruim sneller. En dan kom je op 2160p en slaat het keihard om. Dat is waar je ineens zo veel pixels hebt dat de L2 veel zwaarder belast wordt en meer L2 dus wel helpt.

Navi32 krijgt volgens RGT en Angstronomics 3 SE's ipv 4 SE's, dan ook 3MB ipv 4MB.

[...]


We zagen met Navi2x al verschillen tussen de SE's, Navi23 met 2x2x8 CU SE's, en Navi22 met 2x2x10 CU SE's. De ene SE is de andere niet

Ik richtte me volledig op die tabel van WCCF (waar 4 SE/30 WGP staat), om maar weer eens te demonstreren hoe weinig die knakkers achter die site er van snappen

3 SE kan best, hoewel dat dan ook wel een interessant verhaal wordt qua floorplan

[DaniëlWW2]

Werelds schreef op zaterdag 10 september 2022 @ 15:53:
3 SE kan best, hoewel dat dan ook wel een interessant verhaal wordt qua floorplan

Nou de bron daarvoor is uiteraard:
https://www.angstronomics.com/p/amds-rdna-3-graphics

En die zei ook even doodleuk dit:

The reference card appears to have an updated 3-fan design that is slightly taller than the previous generation, with a distinctive 3 red stripe accent on a section of the heatsink fins near the dual 8-pin connectors.

Dat is laten we zeggen, wat opvallend.

---

Maar ik denk dat het best kan en ik vermoed zo. De logica voor dit verschrikkelijke paint plaatje is dat je dit kan verdubbelen met nog 6x SE erboven en dan heb je Navi 31. Eigenlijk wat AMD dus al twee generaties doet.

[Werelds]

DaniëlWW2 schreef op zaterdag 10 september 2022 @ 19:16:

---

Maar ik denk dat het best kan en ik vermoed zo. De logica voor dit verschrikkelijke paint plaatje is dat je dit kan verdubbelen met nog 6x SE erboven en dan heb je Navi 31. Eigenlijk wat AMD dus al twee generaties doet.
[Afbeelding]

Maar hoe gaan ze de L1 dan aan de L2 hangen? Want jij tekent hier de 6 Shader Arrays, niet de Engines. De L1 in de SE wordt door alles binnen de SE's gebruikt, dus je wilt niet dat het ene blok L1 aan de linkerkant aan de L2 hangt en het andere blok aan de rechterkant. Dan ga je afwijkende latencies tussen de twee blokken krijgen.

Het zal dan eerder iets worden zoals Nvidia het doet, met de L2 tussen alle SE's in en de GCP en ACE's verder naar buiten.

[DaniëlWW2]

Werelds schreef op zaterdag 10 september 2022 @ 22:20:
[...]

Maar hoe gaan ze de L1 dan aan de L2 hangen? Want jij tekent hier de 6 Shader Arrays, niet de Engines. De L1 in de SE wordt door alles binnen de SE's gebruikt, dus je wilt niet dat het ene blok L1 aan de linkerkant aan de L2 hangt en het andere blok aan de rechterkant. Dan ga je afwijkende latencies tussen de twee blokken krijgen.

Het zal dan eerder iets worden zoals Nvidia het doet, met de L2 tussen alle SE's in en de GCP en ACE's verder naar buiten.

Ik doe gewoon zeer lui en neem niet eens de moeite om de SE's ook te tekenen.
Ik twijfel er namelijk niet aan dat gehandhaafd blijven omdat het zo'n elementair onderdeel van RDNA is.

Het gaat mij er meer om dat Navi 31/32 waarschijnlijk net zoals Navi 21/22 en Navi 10/14, vrij makkelijk arrays/engines kunnen verdubbelen. En zeker omdat we nu naar N5 kijken, is dat ook meteen een forse kostenbesparing als je een groot deel van het vloerplan kan overnemen tussen twee chips. Voor Navi 31 verliest elk array waarschijnlijk een WGP, krijgt meer L2 cache en zal de I/O elders geplaatst worden. Voor de rest veranderd er waarschijnlijk niet veel.

Ik zou ook echt niet verbaast zijn als we hetzelfde scenario als Navi 21/22, nog iets verder uitgediept krijgen. We zien met N22/N23 eigenlijk dat vier WGP diep met minder cache, beter is dan vijf me extra cache. Het scheelt zoveel transistoren voor relatief weinig verlies in framerate. Je moet naar 4K voordat je het verschil een beetje gaat zien.

Hierom zijn N31/N33 arrays waarschijnlijk ook vier WGP diep. N32 zit waarschijnlijk op vijf om die dichterbij N31 te brengen. Hierbij nemen ze de extra transistoren en dus kosten voor lief. Ik vermoed dat ze hier het ook willen compenseren met kleine verbeteringen. Ik denk dan aan hogere clock speeds alsmede relatief meer L2 en L3 cache. Eigenlijk het N22 recept. Hierom zei ik ook dat ik 4MB L2 cache vermoed terwijl 3MB de logische stap zou zijn. Verder is er natuurlijk het toch wel sterke gerucht dat N32 met 64MB aan L3 komt terwijl N31 met 96MB zit. Mijn aanname hierbij is ook dat AMD met hogere clock speeds meer throughput wil halen (duh ) en met de caches de kans op een cache mis wil reduceren alsmede de effectieve latency in cache cycles iets wil verlagen omdat die caches nu eenmaal aan dezelfde frequentie hangen.

N31 maken ze bewust vier WGP per SA diep omdat die chip zo breed is en zoveel ALU's heeft dat ze waarschijnlijk weten dat de vijfde WGP/SA niet transistor/perf en perf/watt effectief meer is. Als ze die ook goed mee willen krijgen, dan moeten ze waarschijnlijk zoveel met caches en andere zaken doen dat de chip te groot word. En laten we wel wezen, 12288ALU's/48WGP/12SA/6SE is best een aardige chip.

Het verklaard voor mij ook beter waarom N22 en N23 zo dicht op elkaar zitten qua ontwerp. Ik vermoed dat AMD heeft lopen experimenteren met vier vs. vijf WGP alsmede de impact van grotere L2 en L3 caches. Het kan namelijk goed dat AMD intern met verschillende configuraties bezig is geweest en uiteindelijk na de feedback van RDNA2 pre production samples heeft gekozen voor een optie die naar de afdeling "productieontwerp" is gestuurd voor de tape-out.

Dat is denk ik ook niet zo vreemd omdat er de laatste jaren wel meer rare dingen naar buiten zijn gekomen uit AMD. Bijvoorbeeld Vega 12 of Navi 12, beiden met HBM2. Ik vermoed eigenlijk ook dat er een HBM2 variant op Navi 21 is geweest die ze voortijdig hebben gestaakt omdat simulaties aangaven dat de L3 cache waarschijnlijk zou werken. Een 384bit bus Navi 21 ontwerp zou me ook niks verbazen. Uiteindelijk is die L3 cache waarschijnlijk ook een enorme gok geweest die heel goed uitpakte. En als ik zie dat RDNA3 blijkbaar relatief minder L3 cache krijgt, dan vermoed ik dat ze bij AMD na het testen van RDNA2 test samples tot de conclusie kwamen dat ze het met minder af konden en nog net op tijd waren om voor een mindere hoeveelheid te kiezen in hun MCD ontwerp. Immers zit L3 cache waarschijnlijk daarop en niet op de GCD.

[sunsmountain]

Wat betreft de aparte Navi32 configuratie met 3x10 WGP, die wordt waarschijnlijk pas logisch met Navi30 = 2x Navi32 = 6 SEs.

Navi31 is 3x Navi33 (2SE) en dan ook 6 SEs. Vermoed ik.

[Sp3ci3s8472]

AMD zit nu met H264 met offline encoding nu net boven onder Intel en Nvidia door een extra analyse stap.
AMD improves video encoding yet again! This time with Pre-Analysis

[DaniëlWW2]

Sp3ci3s8472 schreef op maandag 12 september 2022 @ 16:02:
AMD zit nu met H264 met offline encoding nu net boven Intel en Nvidia door een extra analyse stap.
AMD improves video encoding yet again! This time with Pre-Analysis

Net voordat AV1 encoding echt gaat komen, hebben ze het voor elkaar.
Maar het maakt voorlopig niks uit omdat dit staat op Twitch.
https://stream.twitch.tv/encoding/

Ze zeggen eigenlijk gewoon dat je maar een Turing based of beter van Nvidia moet kopen. Dat gaat pas veranderen als ze AV1 breder gaan ondersteunen. Doen ze op de achtergrond waarschijnlijk allang, maar de encoding hardware is er nog niet. Het verschil in bandbreedte is zo enorm dat het echt niet lang gaat duren voordat ze die optie aan gaan zetten. Scheelt ze zo enorm veel geld.

[ Voor 4% gewijzigd door DaniëlWW2 op 12-09-2022 16:18 ]

[Sp3ci3s8472]

DaniëlWW2 schreef op maandag 12 september 2022 @ 16:16:
[...]


Net voordat AV1 encoding echt gaat komen, hebben ze het voor elkaar.
Maar het maakt voorlopig niks uit omdat dit staat op Twitch.
https://stream.twitch.tv/encoding/

Ze zeggen eigenlijk gewoon dat je maar een Turing based of beter van Nvidia moet kopen. Dat gaat pas veranderen als ze AV1 breder gaan ondersteunen. Doen ze op de achtergrond waarschijnlijk allang, maar de encoding hardware is er nog niet. Het verschil in bandbreedte is zo enorm dat het echt niet lang gaat duren voordat ze die optie aan gaan zetten. Scheelt ze zo enorm veel geld.

Het maakt sowieso voor Twitch vrij weinig uit omdat het om offline encoding gaat, niet om online encoding (bijv. een Twtich stream). Misschien gebruik ik de verkeerde terminologie .

[Dennism]

DaniëlWW2 schreef op maandag 12 september 2022 @ 16:16:
[...]


Net voordat AV1 encoding echt gaat komen, hebben ze het voor elkaar.
Maar het maakt voorlopig niks uit omdat dit staat op Twitch.
https://stream.twitch.tv/encoding/

Ze zeggen eigenlijk gewoon dat je maar een Turing based of beter van Nvidia moet kopen. Dat gaat pas veranderen als ze AV1 breder gaan ondersteunen. Doen ze op de achtergrond waarschijnlijk allang, maar de encoding hardware is er nog niet. Het verschil in bandbreedte is zo enorm dat het echt niet lang gaat duren voordat ze die optie aan gaan zetten. Scheelt ze zo enorm veel geld.

Voor Twitch of andere vormen van game streaming of capturing maakt dit sowieso niet uit, zie ook het bron artikel:

This will not help with real time streaming or game capture. It’s too slow to use for that, only available for VBR mode, and you need future knowledge of frames for the appropriately named “Pre-Analysis”. Some software may chose to add it with a large frame buffer, but I doubt it will be a standard feature anytime soon for those cases.

[sunsmountain]

Ik zat ook te denken: Waardoor beperkt Nvidia de 4090 tot 128 SMs ipv 144 SMs? Kan natuurlijk yields zijn, maar als de yields van Navi31 7900XT goed zijn met 48 WGP (192 oude CUs), en beide kaarten 3 GHz halen, best kans dat AMD de performance crown gaat pakken en Nvidia dat al weet.

De 4090 probeert dan alleen te winnen van Navi32 (30 WGP, 120 oude CUs) die pas volgend jaar op de markt komt. En Navi33, die er later dit najaar al zou zijn.

[XWB]

Omdat de volledige AD102 chip wordt achtergehouden voor een latere RTX 4090 Ti.

[Dennism]

XWB schreef op maandag 12 september 2022 @ 17:07:
Omdat de volledige AD102 chip wordt achtergehouden voor een latere RTX 4090 Ti.

Dat, en waarschijnlijk RTX Axxxx GPU's in de zakelijke range, bijv. de RTX A6000 was er bij Ampere ook vlak na de RTX3090 release al, terwijl de RTX 3090 Ti best even op zich liet wachten.

[sunsmountain]

@XWB @Dennism eens, maar wat verwachten jullie qua performance dan van Navi31? Greymon55 leek een TSE score van 19k+ te bevestigen, maar dat zou nog een 7800 XT kunnen zijn (de 42 WGP variant).

Over kloksnelheden en performance van RDNA3 is trouwens vrijwel niks gelekt, mijn 3 GHz was een aanname gegeven TSMC N5/N4.

[DaniëlWW2]

sunsmountain schreef op maandag 12 september 2022 @ 17:30:
@XWB @Dennism eens, maar wat verwachten jullie qua performance dan van Navi31? Greymon55 leek een TSE score van 19k+ te bevestigen, maar dat zou nog een 7800 XT kunnen zijn (de 42 WGP variant).

Over kloksnelheden en performance van RDNA3 is trouwens vrijwel niks gelekt, mijn 3 GHz was een aanname gegeven TSMC N5/N4.

Als ik dat zou weten, tja ik zou dergelijke informatie verkopen aan de hoogste bieder, Jensen Huang dus. Heb ik waarschijnlijk eens levenslange voorraad aan leren jasjes.
Ga er gerust vanuit dat N31 best snel zal zijn.

Maar er kan nog een reden zijn om de volle AD102 achter te houden. Wie zegt dat die veel sneller is dan een cut down chip met de vermoede 450W? Kan zomaar dat die gewoon nog meer nodig heeft in gaming workloads net zoals de RTX3090/RTX3090Ti, om echt beter te presteren...

[Ludewig]

Sp3ci3s8472 schreef op maandag 12 september 2022 @ 16:02:
AMD zit nu met H264 met offline encoding nu net boven Intel en Nvidia door een extra analyse stap.

Net onder. Een hogere score is beter.

In elk geval mooi om te zien dat ze er werk van maken.

[raymondw]

Dennism schreef op maandag 12 september 2022 @ 17:19:
[...]
Dat, en waarschijnlijk RTX Axxxx GPU's in de zakelijke range, bijv. de RTX A6000 was er bij Ampere ook vlak na de RTX3090 release al, terwijl de RTX 3090 Ti best even op zich liet wachten.

Of een A40
Er gaan massa's chips naar Enterprise VDI oplossingen a 8000,- p/s
Daarbij ook nog eens 500,- software licentie p/u/p/y

3090 Ti -> A6000 -> A40 is allemaal dezelfde chip
Alleen voor consumer betaal je de HW, voor Enterprise betaal je de HW en software

[aminam]

raymondw schreef op dinsdag 13 september 2022 @ 09:00:
[...]

Of een A40
Er gaan massa's chips naar Enterprise VDI oplossingen a 8000,- p/s
Daarbij ook nog eens 500,- software licentie p/u/p/y

3090 Ti -> A6000 -> A40 is allemaal dezelfde chip
Alleen voor consumer betaal je de HW, voor Enterprise betaal je de HW en software

Ja, de enterprises balen er behoorlijk van dat AMD hun mxgpu lijn niet een stuk harder gepushed heeft want die nvidia vpc en vooral vws licenties zijn erg duur.

[computerjunky]

DaniëlWW2 schreef op vrijdag 9 september 2022 @ 10:28:
[...]


Het verschilt erg per game, per type textures en ook per implementatie.
Maar ze pakken meteen wel de grotere probleemgevallen aan. Beetje jammer alleen dat RDR2 net een dag voor FSR2.1, met 2.0 komt. Overigens krijgen Cyberpunk en MFS2022 ook FSR2.1.

edit: Vergelijking met gemodde 2.1 versies beginnen op te duiken. Je kan het zeker zien in RDR2.
[YouTube: Red Dead Redemption 2 FSR 2.1 Update | 1440p FSR 2.0 vs FSR 2.1 vs DLSS 2.4 Comparison | RTX 3080]

Of deze. Let op rechtsboven de rook uit de schorsteen, het glazen afdak of wat extra scherpte of details. Het is minder dan RDR2, maar nog steeds.
https://imgsli.com/MTI0NjU5/0/1

Op 1:13 zie je in de hoogspanning kabels toch een voordeel van 2.0 ja de kabels zijn dikker maar bij DLSS en FSR 2.1 zie je ze na de eerste sectie helemaal niet meer en dat is gewoon een fout wat mij betreft. Ze worden gewoon weg gefilterd en poppen dan ineens in beeld als je dichterbij komt.
Minder shimmering is leuk maar als je daardoor elementen uit het beeld filtert is het misschien wat te agressief.

[DaniëlWW2]

computerjunky schreef op dinsdag 13 september 2022 @ 14:06:
[...]


Op 1:13 zie je in de hoogspanning kabels toch een voordeel van 2.0 ja de kabels zijn dikker maar bij DLSS en FSR 2.1 zie je ze na de eerste sectie helemaal niet meer en dat is gewoon een fout wat mij betreft. Ze worden gewoon weg gefilterd en poppen dan ineens in beeld als je dichterbij komt.
Minder shimmering is leuk maar als je daardoor elementen uit het beeld filtert is het misschien wat te agressief.

En dat is dus precies het punt dat ik al zo vaak heb proberen te maken.
Het maakt niet uit of het FSR 1/2/2.1 of DLSS 1/1.9/2.x is. Het gaat geen native zijn. Je hebt altijd wel iets en de truc is om het niet echt op te laten vallen. DLSS 2.x en FSR2.x zijn daar behoorlijk goed in aan het worden. Maar of het nu ghosting, shimmering, wegvallen van detail of iets anders is, er zal iets zijn. Daarom is het ook iets dat pas aangezet zou moeten worden als je naar de mening van de gebruiker, niet afdoende fps haalt. DLSS/FSR is het eerste dan je dan aanzet. Dat is ook het enorme voordeel van FSR2.x. het werkt op oudere hardware waar je het veel eerder aan zou willen zetten. Het is alleen niet een "magische" fps verbetering zonder nadelen. Die bestaat niet.

---

Oh en daar gaan we hoor. AMD marketingtype die op twitter loopt te trollen. Die oude grap kennen we hopelijk nog. Voor zijn verdere reputatie hoop ik maar dat Navi 31 inderdaad AD102 dood knuppelt.

bigger doesn't necessarily mean better

— Saša Marinković (@SasaMarinkovic) 14 september 2022

[Sp3ci3s8472]

DaniëlWW2 schreef op woensdag 14 september 2022 @ 21:16:
En dat is dus precies het punt dat ik al zo vaak heb proberen te maken.
Het maakt niet uit of het FSR 1/2/2.1 of DLSS 1/1.9/2.x is. Het gaat geen native zijn. Je hebt altijd wel iets en de truc is om het niet echt op te laten vallen. DLSS 2.x en FSR2.x zijn daar behoorlijk goed in aan het worden. Maar of het nu ghosting, shimmering, wegvallen van detail of iets anders is, er zal iets zijn. Daarom is het ook iets dat pas aangezet zou moeten worden als je naar de mening van de gebruiker, niet afdoende fps haalt. DLSS/FSR is het eerste dan je dan aanzet. Dat is ook het enorme voordeel van FSR2.x. het werkt op oudere hardware waar je het veel eerder aan zou willen zetten. Het is alleen niet een "magische" fps verbetering zonder nadelen. Die bestaat niet.

Inderdaad, de enige reden dat ik enthausiast hierover ben is dat ik zo meteen VSR + FSR kan doen omdat niet elk spel op 6880x2880 draait.

Ik zou overigens eerder andere settings lager zetten; er zijn er een aantal die nauwelijks iets toevoegen en als je die uitzet kan je vaak wel op native resolutie spelen. Op resolutie inleveren geeft met name op lagere resoluties en op schermen met een lage DPI (zoals de meeste UWD schermen) kartels (aliasing). Op 34" gaat 3440x1440 nog net; ik zou best graag iets van 36-38" willen met 5120x2160. Beter wacht ik op QD Oled op dat formaat want ik ga geen IPS meer kopen nu dat op de markt is.

[sunsmountain]

DaniëlWW2 schreef op woensdag 14 september 2022 @ 21:16:
[...]


En dat is dus precies het punt dat ik al zo vaak heb proberen te maken.
Het maakt niet uit of het FSR 1/2/2.1 of DLSS 1/1.9/2.x is. Het gaat geen native zijn. Je hebt altijd wel iets en de truc is om het niet echt op te laten vallen. DLSS 2.x en FSR2.x zijn daar behoorlijk goed in aan het worden. Maar of het nu ghosting, shimmering, wegvallen van detail of iets anders is, er zal iets zijn. Daarom is het ook iets dat pas aangezet zou moeten worden als je naar de mening van de gebruiker, niet afdoende fps haalt. DLSS/FSR is het eerste dan je dan aanzet. Dat is ook het enorme voordeel van FSR2.x. het werkt op oudere hardware waar je het veel eerder aan zou willen zetten. Het is alleen niet een "magische" fps verbetering zonder nadelen. Die bestaat niet.

---

Oh en daar gaan we hoor. AMD marketingtype die op twitter loopt te trollen. Die oude grap kennen we hopelijk nog. Voor zijn verdere reputatie hoop ik maar dat Navi 31 inderdaad AD102 dood knuppelt.

[Twitter]

Sommige beelden zien er met DLSS FSR of XeSS beter uit dan Native. Zie de laatste paar videos van Digital Foundry. Maar elke modus heeft inderdaad wel wat qua nadeel / agressieve filtering, etc.

---

Man man man, AMD en dan vooral Radeon marketing. Net als je denkt, dat kan niet lager zakken qua dieptepunt, ja hoor. Gelukt. "Jebaited" (en dan je prijzen moeten verlagen).

[DaniëlWW2]

En daar is Igor.

Dit is ongeveer het Navi 31 PCB.

-Ja een GCD + zes MCD.
-Driemaal 8 pin
-Verder houdt Igor uiteraard dingen achter. Doet hij wel vaker. Ook waarschuwt hij terecht voor Twitter waar ze nogal aan het roepen zijn.

[ Voor 28% gewijzigd door DaniëlWW2 op 15-09-2022 09:22 ]

[sunsmountain]

https://www.coindesk.com/...erge-is-done-did-it-work/

cross post

[Help!!!!]

AMD Radeon RX 7900XT – Possible board design and new findings | Exclusive

[CMT]

Het is jammer dat i.i.g. de 7900 kaart ca. 2cm breder wordt. Ik vond de RX6000 serie zo mooi compact.
Maar gelukkig zo goed als geen 12HPWR stekker, dat zullen de modders ook wel leuk vinden .
Het is de 1e keer dat ik solid state condensators zie bij de ingangsfilter. Ik vraag mij af waarom de keuze daarop gevallen is, qua capaciteit dichtheid zijn deze een stuk slechter dan reguliere polymeer cilindertjes.

[Ludewig]

@CMT

Als je z'n uitleg leest is de stekker grotendeels speculatie. Sowieso lijkt het hele ontwerp speculatie en heeft hij helemaal geen kaart in z'n handen gehad. Dus ik zou er niet teveel op vertrouwen.

[CMT]

Dat is ook wel zo, maar Igor is wel jarenlang aktief geweest voor TomsHardware en heeft er genoeg contacten uit de 'industrie' aan over gehouden. Ik vertrouw zijn info / inschattingen, veel meer dan die zogenaamde incontinente mensen op twitter e.d.
Juist omdat Igor wat terughoudend is en ook aangeeft niet alles prijs te geven om zijn bronnen te beschermen, dan wel fabrikanten op zijn dak te krijgen.

[Help!!!!]

Ludewig schreef op vrijdag 16 september 2022 @ 17:25:
@CMT

Als je z'n uitleg leest is de stekker grotendeels speculatie. Sowieso lijkt het hele ontwerp speculatie en heeft hij helemaal geen kaart in z'n handen gehad. Dus ik zou er niet teveel op vertrouwen.

Dan heb je niet goed gelezen

"I admit that my drawn “artwork” is based on real circuit boards and blueprints, but they are not for public consumption. But I can sleep at night with a clear conscience, because without publishing genuine originals, on the one hand I can protect my sources well, and on the other hand I don’t hurt the manufacturers too much, but only satisfy the information needs of my readers.

The following graphic shows the board of a Radeon RX 7900XT as a possible board design very close to the reference. I changed the dimensions and aspect ratios a bit, compared different designs, and only adopted what proved to be constant. Most of the holes vary greatly in the individual designs, so I deliberately omitted them. However, many details are congruent and recurring, so they can be considered set. And for those who remember my drawings of Turing and Ampere, they ended up being almost photographically accurate."

[Ludewig]

Ok, mijn fout.

[Help!!!!]

no worries, het duurt niet heel lang meer voordat we weten hoe het echt zit

[DaniëlWW2]

CMT schreef op vrijdag 16 september 2022 @ 17:48:
Dat is ook wel zo, maar Igor is wel jarenlang aktief geweest voor TomsHardware en heeft er genoeg contacten uit de 'industrie' aan over gehouden. Ik vertrouw zijn info / inschattingen, veel meer dan die zogenaamde incontinente mensen op twitter e.d.
Juist omdat Igor wat terughoudend is en ook aangeeft niet alles prijs te geven om zijn bronnen te beschermen, dan wel fabrikanten op zijn dak te krijgen.

Het gaat denk ik nog iets verder.
Igor komt de afgelopen jaren wel vaker met zulke technische informatie die hij overduidelijk van AIB partners heeft gekregen. Het is ook een publiek geheim dat die werkelijk niks geheim kunnen houden. Hierom gaat er waarschijnlijk ook een deel van de onzin rond. Simpelweg misinformatie.

Belangrijker nog is dat hij wel weet waar hij het over heeft en dus beter kan inschatten wat onzin is, wat twijfelachtig en wat zal kloppen. Het is ook belangrijk om te onthouden wat je eventueel kan geloven van wie. Bij Igor geloof ik PCB zaken meestal wel alsmede TDP/VRAM configuraties.

Bij hem komen er wel vaker dingen voorbij die ook klopte zoals:
https://www.igorslab.de/e...-the-search-for-the-leak/

[Ludewig]

DaniëlWW2 schreef op vrijdag 16 september 2022 @ 18:44:
[...]
Het gaat denk ik nog iets verder.
Igor komt de afgelopen jaren wel vaker met zulke technische informatie die hij overduidelijk van AIB partners heeft gekregen. Het is ook een publiek geheim dat die werkelijk niks geheim kunnen houden. Hierom gaat er waarschijnlijk ook een deel van de onzin rond. Simpelweg misinformatie.

Daarom krijgen de AIB ook niet meer te horen wat de prijzen zullen zijn totdat Jensen dat publiekelijk verteld. Asus zit straks net zo gespannen als wij de GTC keynote te kijken.

Het lijkt er ook op dat de AIBs expres iets verschillende reference kaarten aangeleverd krijgen en op basis daarvan hun eigen boards moeten ontwikkelen. Dan krijgen ze pas laat de exacte details te horen en moeten ze alsnog dingen aanpassen. Dat is misschien ook een deel van de frustratie van EVGA. Ze hebben dan heel veel extra en last-minute werk. Dat komt dan nog bovenop de verplichte afname van kaarten, ipv dat de AIB vrijelijk een bestelling mogen plaatsen van wat ze zelf willen.

[raymondw]

*knip* off topic

[ Voor 93% gewijzigd door br00ky op 17-09-2022 11:50 ]

[Damic]

Mmmh 27ste is het launch. Vervalt de NDA dan het weekend van de 24ste of pas de 26ste?

*verkeerd topic, moest in het AMD cpu nieuws zijn

[ Voor 26% gewijzigd door Damic op 18-09-2022 20:14 ]

[DaniëlWW2]

Dus dit heb ik ook helemaal gemist. Was uit begin juni bij hun 2022 Financial Analyst Day.
Paar kleine dingetjes vanuit AMD zelf.

It (RDNA 3) is also our first gaming GPU architecture that will leverage the enhanced 5nm process and an advanced chip packaging technology. And another innovation includes a architected compute units with enhanced ray-tracing capabilities and an optimized graphics pipeline with even faster clock speeds and improved power efficiency.

And to bring more photorealistic effects into the domain of realtime gaming, we are developing hybrid approaches that takes the performance of the rasterization combined with the visual fidelity of raytracing, to deliver the best realtime imerssive experiences without comprising performance.

Lastly, our next-generation multimedia, we will support advanced video codecs such as AV1 to deliver high-quality video streaming and reduce latencies and bitrates. We will also improve our display capbilities with the new DisplayPort 2.0 standard to support upcoming HDR displays with high resolutions and refresh rates.

https://wccftech.com/amd-...locks-av1-dp-2-0-support/

Halen we dus een paar dingen uit.
-CU's blijven dus wel bestaan in een hoedanigheid.
-RT lijkt dus zoals ik al vermoede inderdaad binnen de CU te blijven (SIMD unit + RA die onderdeel van de CU structuur is)
-AV1 maar dat was ook wel duidelijk.

[DJvL]

4Ghz?

https://wccftech.com/amd-...infinity-cache-confirmed/

[CMT]

Nee, weer een of andere twittertroll die zonder onderbouwing iets roept.
AMD heeft nergens gerept over hogere kloksnelheden, alleen dat performance/watt flink verbeterd zal worden tot aan 50%.

Over Zen4 werd men ook lyrisch toen 3000MHz FCLK werd geopperd als mogelijkheid. Dat bleek dus gebaseerd te zijn op een beschikbare bios optie .

Ik ga ervan uit dat de kloksnelheden eerder gelijk of minder zullen zijn t.o.v. RNDA2.
Het aantal cores neemt flink toe & het wordt anders moeilijk om aan de 50% toegenomen performance/watt te voldoen.

[DaniëlWW2]

AMD is vol in de trol modus gegaan. Gewoon even een blogpost online gezet over het belang van Perf/watt voor gamers en hoe AMD hier beter in is.
https://community.amd.com...enefit-gamers/ba-p/545586

Maar hier zit weer wat tussen. Grappig dat ze het weer over gate switching en aangepaste caches hebben. Want zeker die laatste kwam ook voorbij in waarschijnlijk de leak die wel meer goed gehad lijkt te hebben.

What’s Next?

Looking ahead, we’re continuing our push for more efficient gaming with AMD RDNA™ 3 architecture. As the first AMD graphics architecture to leverage the 5nm process and our chiplet packaging technology, AMD RDNA™ 3 is on track to deliver an estimated >50 percent better performance per watt than AMD RDNA™ 2 architecture[6] – truly bringing top-of-the-line gaming performance to gamers in cool, quiet, and energy-conscious designs.

Contributing to this energy-conscious design, AMD RDNA™ 3 refines the AMD RDNA™ 2 adaptive power management technology to set workload-specific operating points, ensuring each component of the GPU uses only the power it requires for optimal performance. The new architecture also introduces a new generation of AMD Infinity Cache™, projected to offer even higher-density, lower-power caches to reduce the power needs of graphics memory, helping to cement AMD RDNA™ 3 and Radeon™ graphics as a true leader in efficiency.

We’re thrilled with the improvements we’re making with AMD RDNA™ 3 and its predecessors, and we believe there’s even more to be pulled from our architectures and advanced process technologies, delivering unmatched performance per watt across the stack as we continue our push for better gaming.

[MneoreJ]

Dat zijn van die dingen... perf/watt doet er nooit toe tenzij men de performance crown niet heeft, dan is het ineens de belangrijkste metric. Heeft men daarentegen de performance crown dan moeten mensen juist niet zeuren over perf/watt want het gaat om perf en anders koop je maar een wat zwaardere voeding, pauper. Allemaal zo lekker voorspelbaar altijd. Ik vraag me af wat dat schuift, werken voor de marketing bij een GPU-bakker, want volgens mij is het best een relaxte baan.

[DaniëlWW2]

MneoreJ schreef op dinsdag 20 september 2022 @ 10:11:
Dat zijn van die dingen... perf/watt doet er nooit toe tenzij men de performance crown niet heeft, dan is het ineens de belangrijkste metric. Heeft men daarentegen de performance crown dan moeten mensen juist niet zeuren over perf/watt want het gaat om perf en anders koop je maar een wat zwaardere voeding, pauper. Allemaal zo lekker voorspelbaar altijd. Ik vraag me af wat dat schuift, werken voor de marketing bij een GPU-bakker, want volgens mij is het best een relaxte baan.

Relaxed totdat het product er is en ze geflambeerd worden door hordes aan fanboys omdat ze weer eens "creatief met waarheden waren". Zoals ik al eerder zei, hoop ik voor hun dat RDNA3 het inderdaad gaat winnen. Want anders krijgen ze het weer over zich heen, en terecht.

[MneoreJ]

DaniëlWW2 schreef op dinsdag 20 september 2022 @ 10:43:
Relaxed totdat het product er is en ze geflambeerd worden door hordes aan fanboys omdat ze weer eens "creatief met waarheden waren". Zoals ik al eerder zei, hoop ik voor hun dat RDNA3 het inderdaad gaat winnen. Want anders krijgen ze het weer over zich heen, en terecht.

Nou is de marketingafdeling van AMD legendarisch goed met zichzelf in de voet schieten, maar als je ziet wat Nvidia alvast van stal heeft moeten halen qua power en waar ze de mensen op voorbereiden, dan denk ik dat ze op zich wel goede kaarten hebben (no pun intended). De perf/watt verbetering hoeft relatief met de vorige generatie nog niet eens echt goed te zijn, als ze maar beter zijn qua verbruik van NV komt de boodschap vast goed aan, en dat gaat denk ik wel lukken -- niet met spectaculaire marges maar toch.

Slag om de arm, we gaan het zien, etc. Ik ben praktisch in winterslaap tot volgend jaar, wanneer de midrange kaarten voorzichtig hun gezicht gaan laten zien. Het geweld van de high end is me iets te episch geworden qua prijs en verbruik.

[Dennism]

DaniëlWW2 schreef op dinsdag 20 september 2022 @ 10:43:
[...]


Relaxed totdat het product er is en ze geflambeerd worden door hordes aan fanboys omdat ze weer eens "creatief met waarheden waren". Zoals ik al eerder zei, hoop ik voor hun dat RDNA3 het inderdaad gaat winnen. Want anders krijgen ze het weer over zich heen, en terecht.

Ooit moet het lukken toch?

En dan lijkt dit toch wel 'het' moment.

[Ludewig]

@MneoreJ

Dit is altijd zo wanneer concurrenten een product uitbrengen met verschillende eigenschappen, waardoor product A beter is in situatie 1 en product B in situatie 2. Dan zal de fabrikant van product A altijd doen alsof alleen situatie 1 belangrijk is en andersom.

Uiteindelijk hoop ik dat de mensen hier wat slimmer zijn dan de gemiddelde consument die 'gewoon wil weten welke beter is' en geen zin heeft in nuance. Een slimme meid consument kent zijn eigen use case en zoekt uit welk product daar beter bij aansluit.

Overigens denk ik dat performance/watt wel steeds belangrijker wordt. Ik hoor pas sinds deze generatie echt hordes mensen klagen dat hun high-end 3000 kaart teveel warmte produceert naar hun zin. Dus best kans dat ze straks een wattage-limiet hanteren bij hun aankopen. Dan kan het zo zijn dat de snelste kaart die onder die limiet blijft een AMD kaart is, ook al heeft Nvidia de allersnelste kaart, met een gigantische overclock op de 4090 Ti Super Extreme OC.

[Dennism]

Ludewig schreef op dinsdag 20 september 2022 @ 12:18:

Overigens denk ik dat performance/watt wel steeds belangrijker wordt. Ik hoor pas sinds deze generatie echt hordes mensen klagen dat hun high-end 3000 kaart teveel warmte produceert naar hun zin. Dus best kans dat ze straks een wattage-limiet hanteren bij hun aankopen. Dan kan het zo zijn dat de snelste kaart die onder die limiet blijft een AMD kaart is, ook al heeft Nvidia de snelste kaart, met een gigantische overclock op de 4090 Ti Super Extreme OC.

Het zal ook niet alleen dat zijn, denk ook aan de gestegen energie tarieven, tot een jaar geleden vonden veel mensen verbruik ook vanwege de lagere tarieven niet heel erg interessant. Dit zie je nu ook veranderen, zeker bij huishoudens zonder zonnepanelen of huishoudens met panelen maar zonder overschot merk ik dit best wel dat verbruik (niet alleen voor GPU's) veel meer begint te leven.

En inderdaad, ook zeker niet iedere gamer zal meer vermogen willen in de gameroom, om ook zomers de temperaturen aangenaam te houden. Lang niet iedereen heeft airco, en als je dat hebt, komt ook daar 'verbruik' tegenwoordig weer kijken.

Voor een 90 class kaart is verbruik denk ik wel iets minder belangrijk, in ieder geval in mijn omgeving zie ik die kaarten (of de zakelijke variant) eigenlijk alleen gebruikt worden door de mensen die de performance nodig hebben om geld te verdienen. Die zullen het vaak minder erg vinden wanneer de hardware meer verbruikt, zolang er maar een efficiëntie slag gemaakt wordt en ze aan het eind van de dag dus meer productie hebben kunnen draaien dan voorheen zonder dat de energie kosten evenredig meestijgen.

[Werelds]

@DaniëlWW2 ik ben benieuwd hoe dat "refines the adaptive power management" zich gaat uiten. Met RDNA2 kunnen ze al delen van de GPU op andere kloksnelheden laten lopen (of wellicht is het gewoon een harde gate, aan/uit - ze hebben er volgens mij nooit uitgebreid over gepraat ), ik vraag me af of ze dat nu op een kleiner niveau doen (dus RDNA2 is misschien per SA, RDNA3 per WGP, of iets in die trant) of dat dit wellicht over daadwerkelijke toevoer gaat en dat ze de spanning kunnen laten variëren?

[DaniëlWW2]

Dennism schreef op dinsdag 20 september 2022 @ 11:56:
[...]


Ooit moet het lukken toch?

En dan lijkt dit toch wel 'het' moment.

Dit zou het ook moeten zijn. Van alle kanten blijft maar 1GCD/12288ALU's + 6MCD/384bit bus komen. Dat is 140% meer dan Navi 21. Zeker omdat steeds duidelijker aan het worden is dat Lovelace niet iets fundamenteel nieuws gaat zijn, moet AMD eigenlijk forse clockspeed en/of occupency regressie hebben om niet te winnen in rasterisation. N31 lijkt gewoon te groot.

Ik kijk dan eigenlijk meer naar RT. Tot dusver was RDNA2 RT niet veel, Turing net zo slecht en Ampere niet veel beter De voornaamste verbetering lijkt het concurrent kunnen uitvoeren van RT en denoising te zijn. Dat kon Turing niet.

Hoe ik het zie en ook vaker heb beschreven, is het uiteindelijk een probleem van tijd om een frame te renderen. Wat je waarschijnlijk nodig hebt is een erg brede GPU met veel rekenclusters en een zeer, zeer hoge clock speed om de RT workloads na de reguliere rasterisation te verrichten. Dit voornamelijk omdat je zoveel extra tijd per frame nodig hebt voor RT.

Stel je hebt een GPU met 5210ALU's/160 SIMD32 eenheden die op 2,3GHz draait*. Je wilt 70fps halen met RT. Dat betekent dat je ongeveer 33 clock cycles per frame hebt/14ms. Het probleem is dat je nu al snel 15ms nodig gaat hebben voor alleen de RT. Begrijpelijkerwijs trekt die GPU dit gewoon niet.
*Totaal niet de RX6900XT.

Vervolgens komt er een nieuwe 7680 ALU GPU die op 3GHz loopt met betere RT die een paar ms van de tijd eraf schaven. Vervolgens verdeel je de workload nu over 240 SIMD32 eenheden, 50% meer en heb je 30% extra clock speed**. Nu heb je ongeveer 43 clock cycles per frame en 50% meer SIMD32 eenheden om alles te berekenen. Als de verdeling van workloads goed blijft schalen, dan kom je in een scenario terecht waar de meeste rasterization voor een frame in een paar ms berekend kan zijn en de GPU opeens tijd heeft voor RT toepassing op objecten. Dat is het doel en dat mist nu.
**Zeker ook niet een inschatting voor N32.

Dat is voor mij uiteindelijk de grootste vraag. AMD gaat iets verbeteren aan RT, ik vermoed dat dezelfde methodiek aanhouden als nu maar dan sneller. De vraag is hoeveel sneller kunnen ze nu werkelijk een frame berekenen met zoveel extra spul alsmede clocks (met andere RDNA3 verbeteringen) en hoeveel extra tijd winnen ze voor RT? Dit was namelijk een vrij grove gesimuleerde N32. Het echte monster is alleen N31.

Werelds schreef op dinsdag 20 september 2022 @ 13:05:
@DaniëlWW2 ik ben benieuwd hoe dat "refines the adaptive power management" zich gaat uiten. Met RDNA2 kunnen ze al delen van de GPU op andere kloksnelheden laten lopen (of wellicht is het gewoon een harde gate, aan/uit - ze hebben er volgens mij nooit uitgebreid over gepraat ), ik vraag me af of ze dat nu op een kleiner niveau doen (dus RDNA2 is misschien per SA, RDNA3 per WGP, of iets in die trant) of dat dit wellicht over daadwerkelijke toevoer gaat en dat ze de spanning kunnen laten variëren?

Ik betwijfel ergens of AMD hier ook al te veel over wil zeggen.

Ik heb eigenlijk een andere, meer fundamentelere vraag.
De auteur van die blogpost was een tijdje terug ook langs wat media gegaan waarin hij ging vertellen over RDNA2 haar efficiëntiewinst en clock speed die via "zijn" afdeling vanuit de Zen teams kwamen. Ook liep die toen al een beetje te trollen over perf/watt met Nvidia.

We hebben inmiddels gezien dat AMD met Zen 4 met een gigantische sprong in clock speeds gaat komen. De vraag bij mij is eigenlijk of ze die verbeteringen niet voor zowel Zen 4 als RDNA3 hebben weten toe te passen? Zo ja, tja dan klinkt "richting 4GHz" misschien niet eens helemaal zo gestoord meer. Ergens nog steeds compleet gestoord voor een GPU, maar toch.

[rapture]

MneoreJ schreef op dinsdag 20 september 2022 @ 10:52:
Slag om de arm, we gaan het zien, etc. Ik ben praktisch in winterslaap tot volgend jaar, wanneer de midrange kaarten voorzichtig hun gezicht gaan laten zien. Het geweld van de high end is me iets te episch geworden qua prijs en verbruik.

Je zegt het zelf al dat het verbruik te gortig wordt. Een PC is geen verwarmingstoestel en in de zomer wordt de kamer warm gestookt.

Ergens trekken de mensen een lijn. 350, 300, 250,... W grafische kaart? De voeding op 850, 750,... W? Van 850W naar 1000W voeding is de helft duurder.

Als AMD met 300W de performance van een 450W GPU kan verslaan, dan zal de AMD GPU in het power budget van meer mensen passen. AMD hoeft niet op prijs te concurreren.

[DaniëlWW2]

Join us on November 3rd as we launch RDNA 3 to the world! More details to come soon! #RDNA3 #AMD pic.twitter.com/oftq1Fjrgt

— Scott Herkelman (@sherkelman) 20 september 2022

Ja ze zijn echt aan het trollen nu.

[Ludewig]

DaniëlWW2 schreef op dinsdag 20 september 2022 @ 15:45:
[Twitter]
Ja ze zijn echt aan het trollen nu.

Slimme actie. Even mensen eraan herinneren dat Nvidia niet de enige keuze is.