Hirdetés
-
Csinált valamit a Nokia: megváltoznak a telefonhívások
it Végrehajtotta a világ első „magával ragadó” telefonhívását a Nokia vezérigazgatója. 3D-s hangélményt ígér.
-
A hátsó raktárból érkezhet a Galaxy S24 FE főkamerája
ma A Samsung nem gondolja újra a kamerarendszert és bejáratott alapokra építkezhet.
-
Olcsó USB WiFi AC adapter
lo Egy olcsó WiFi AC USB adapter jó szolgálatot jelenthet, ha az új router csak elvileg támogatja a 2,4 GHz-es átvitelt.
-
PROHARDVER!
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
most az nVidiával szembeni időtállóság a téma. persze, jó az 5850 / 5870, de semmivel nem időtállóbb, mint a 470 / 480.
ezt a 2GB / 3GB kérdést én annyira nem tudom átélni, nekem is 2GB (sőt 1.5GB) VRAM-om van, és még sosem volt emiatt olyan beállítás mellett gondom, amire elég volt a GPU. a 680 gyorsabb kb. 30-40%-kal, ami sokat számít, de nem sorsfordító.
másrészt, mivel van 4GB-os verzió, ez nem technológiai kérdés, hanem kereskedelmi.a DX12-től való félelem kérdése jelen pillanatban zéró érvértékkel bír. majd beszéljünk róla akkor, amikor lesz rá játék.
a G-Sync-kel kapcsolatos personaljihadot most tegyük félre - a variable sync feature-ről beszélünk, ami a Tahiti tulajoknak nem áll rendelkezésére, a GK104-eseknek meg igen. megjegyzem a 200 USD-s kütyü kapcsán, hogy az A-Sync monitorok sem ígérkeznek olcsónak.
Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
#12146
Malibutomi
nagyúr
Malibutomi
nagyúr
980toi review vegszavak:
Anandtech:
As for this moment, the high-end video card market is essentially in a holding pattern. The GeForce GTX 980 Ti is a fine card for the price – a GTX Titan X for $649 – however with AMD’s new flagship card on the horizon buyers are likely better off waiting to see what AMD delivers before making such a purchase, if only to see if it further pushes down video card prices.Hexus:
Within two weeks we'll bear witness to partner-clocked cards that tease the most out of the second-generation Maxwell architecture, and we fully expect the cream of this crop to be faster than the reference Titan X in every regard. Whether such speed will be good enough to hold on to the single-GPU crown in the face of imminent upcoming competition from the Fiji-infused Radeon R9 390X is one of the more interesting debates in the premium PC graphics space.Bit/tech:
With the R9 390X expected by the end of June, there's little reason to part with your cash right now if you're shopping for a high-end GPU. This is clearly an awesome card, but nonetheless our advice is to take note of the various GTX 980 Ti cards that come out and then see what AMD brings to the table before making your choice.TPU:
And then there is the big unknown variable in form of AMD's upcoming Fiji cards, which could change things dramatically, so definitely wait on purchase until those cards are released.Lehet tudnak mar valamit
vagy nem...de majd kiderul -
Z_A_P
addikt
NEM.
Minap olvastam errol: driver cheat-ek miatt dinamikusan valtozik a terep benchmark alatt.The developers intentionally made each run slightly different to avoid driver cheats. Just tweaking a few variables (ie, ambient lighting) up and down shouldn't have any effect on benchmark scores, but will make the images look different.
In general, the Ashes benchmark is not the same between 2 different runs because they use procedural generation based on the time for the terrain assets
[ Szerkesztve ]
OK
-
Z10N
veterán
AMD_Robert Technical Marketing
Q: "Why weren't any single card benchmarks released?"
A: "Because that is what we sample GPUs to reviewers for. Independent third-party analysis is an important estate in the hardware industry, and we don't want to take away from their opportunity to perform their duty by scooping them."
Q: "Wait so you won't say single GPU performance because reviewers are going to do it but you will say dual GPU? I don't follow the logic."
A: "There are considerably fewer dual GPU users in the world than single GPU users, by an extremely wide margin. If my goal is to protect the sovereignty of the reviewer process, but also give people an early look at Polaris, mGPU is the best compromise."
Q: "So, as someone with no dual GPU experience, I have to ask a seemingly stupid question, what was holding the dual 480s back?"
A: "Tuning in the game. The developer fully controls how and how well multi-GPU functions in DX12 and Vulkan."
Q: "Ty, If I can ask another stupid question, what does this stuff mean?
Single Batch GPU Util: 51% | Med Batch GPU Util: 71.9 | Heavy Batch GPU Util: 92.3%
In the first post you mentioned 151% performance of a single gpu."A: "This is a measurement of how heavily the GPU is being loaded as the benchmark dials up the detail. Batches are requests from the game to the GPU to put something on-screen. More detail = more batches. These numbers indicate that GPU utilization is rising as the batch count increases from low, to medium to high. This is what you would expect."
Q: "Do you know of any plans of how some engines are going to implement that? Unreal 4 or unity for example? Is there a possibility that multi adapter is going to see widespread use through those engines? "
A: "I hope so. Some engines already support DX12 multi-adapter. The Nitrous engine from Oxide, the engine from the Warhammer team (forget name), and a few others. I personally in my own 100% personal-and-not-speaking-for-AMD opinion believe that the mGPU adoption rate in games will pick up over time as developers become more broadly familiar with the API. Gotta get yer sea legs before you can sail the world and stuff.
"Q: "Think about it this way. Each card represents 100% under full load. since they said that the cards are at 51% this would mean that it's running at roughly 1.5 cards load. 151% would be about 75.5% GPU load on each card. That is, IF I understand correctly."
A: "Pretty spot-on."
Q: "Are there any incentives for developers to make future games (or updates for existing ones) better utilize multiple GPUs? Even if, just like you stated, the number of users with more than one GPU is vastly smaller than single users?"
A: "Sure. The multi-GPU users are the early adopters, the influencers, the "first 10%ers." They produce a disproportionate amount of discussion relative to their population, which makes them very influential on the rest of the PC gaming community downstream. Developers like CDPR have proven the value of this approach, as has the team at Oxide Games for aggressively pursuing advanced DX12 functionality.
I'm sure both devs would have done just fine with less outsized investment in the bleeding edge, but it's been really valuable for them because gamers appreciate the respect. That's incentive enough, imo."Q: "I still don't follow. Reviews are going to say dual and single performance anyway."
A: "I don't know how to explain it another way. Posting sGPU numbers hurts their reviews and their traffic. mGPU sort of doesn't. That's it."
Q: "I saw it as X being a roman numeral, meaning it's like an R10. This would imply they could still have R7 and R9, and just no ***X cards."
A: "Ask me again after launch."
Q: "Ok I got some questions, if you're not using vsync or locked fps why is the GPU usage so low and not at 100% pushing maximum FPS? You're running a beast CPU so it shouldn't be bottlenecked.
Why only showcase multi-GPU and only Ashes benchmark? I know it's cherry-picking but it would be nice with other benchmarks as well as they will probably tell
Third. Please release Vega soon I want a card that can push 144FPS+ in 1440P."A: "DX12 uses Explicit Multi-Adapter. The scaling depends on how mGPU is implemented into the engine, and future patches could boost scaling more for any vendor or any GPU combination that works. Besides that, migrating to full production-grade drivers would help. But as you can image, the drivers are still beta. I'm not promising earth-shattering improvements, here, but there are many variables in play that wouldn't be present with GPUs that have been released for 12+ months."
Q: "Thanks alot for the great info on clafication of the whole AOTS issue.
I have one question that you may or may not be able to answer.
I play at triple 1440P (dell U2711 x3) with eyefinity. im currently running triple crossfire 5870 1GB and finding alot of games struggle so even on 1 screen i can play games like BF4.
Would the RX480 be a upgrade..
"A: "I can't really answer your question, but I can give you some food for thought that might be enlightening: the Radeon R7 360 is faster than the 5870."
Q: "Hi, only just noticed this thread and love that you took the time to clarify all this. But I was somewhat wondering if I can get an official comment (or nod) on me comparing the x2 480 vs 1080 comparison and it's introduction of explicit multi-adapter in DX12 to this- https://www.youtube.com/watch?v=6JARVfb-FBg
Now it may not be obvious for those who are not familiar with the show, but theres also some serious foreshadowing going on with this particular video and what I expect will happen much later on. "
A: "1) Garnet is best gem.
2) We're not really foreshadowing anything. We just wanted to point out that it's possible to get $700 worth of performance for <$500."Q: "Hey /u/AMD_Robert, thanks for clearing things up, but don't you think it's a bit early to say things like;
even with fudgy image quality on the GTX 1080 that could improve their performance a few percent
Maybe I'm just misreading you here, but I don't really think we can say for certain this was intentional yet. Shader errors are a thing, and it may end up being fixed in a driver patched for Pascal and just somehow slipped through the filters. After all, it was fairly hard to notice anyways."
A: "I never said it was intentional. I simply stated the fact that the image quality is a bit fudgy, and it could improve perf by a few percent. There was no implication of malice."
[ Szerkesztve ]
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
#25131
Malibutomi
nagyúr
Malibutomi
nagyúr
WCCF Vega hirek (szoval nemi fenntartassal kezelni) [link]
AMD’s Vega 10 Debuting Before Year’s End – Features New V9 GCN Architecture
Moving on to Vega 10, the GPU that most of you reading this are probably interested in. Vega 10 will be the very first GPU based on the company’s brand new GCN graphics architecture and 9th generation collection of visual IP.
Completely Redesigned V9 GCN Architecture With Significant AdvancesThe V9 nomenclature refers to AMD’s 9th graphics architecture. Which represents a significant departure from the previous 8th generation GCN architecture of Polaris ,RX 400 series, and AMD’s “Islands” family of R9 200 & HD 7000 graphics cards.
The structure and configuration of SIMD units is entirely new. Each SIMD is now capable of simultaneously processing variable length wavefronts. It also includes clever new coherency features to ensure peak stream processor occupancy in each compute unit at all times and reduce access times to cache and HBM. Memory delta color compression has also been improved. We’ll talk about the new architecture a lot more in-depth in a forthcoming articleAMD’s Vega 11 Coming Early 2017, Faster & More Power Efficient Than Polaris 10
Vega 11 will feature 8GB of HBM2 and is aimed at delivering the highest possible performance in notebook devices as well as replacing Polaris 10 in the midrange on the desktop. The GPU will be faster than Polaris 10 and use less power. Vega 11 will come in mini-ITX SFF and standard PCIe form factors. Most of the GPU’s extra oomph comes from the updated graphics architecture in addition to higher clock speeds compared to the RX 480 and RX 470. Vega 11 based cards will target the same ~$250 mid-range target that’s currently occupied by Polaris 10 and Nvidia’s GTX 1060.
Kivancsi vagyok mi jon be ezekbol.
-
#26018
Yutani
nagyúr
Szeszkazán
#26016
Yutani
nagyúr
válasz
Szeszkazán
#26016
üzenetére
AMD's biggest problem with GCN is the inability of most game engines fully utilizing it's shaders. We've seen what can happen with good programmers with Doom Vulkan, using Shader Intrinsics and Async Compute to max out GCN, RX 480 ~20% faster than 1060, which actually matches it's paper TFlops specs. In most games for GCN, there's a lot of SIMDs with idling ALUs doing nothing so in effect, it's not a 5.8 TFlop GPU since that rating is the max theoretical perf assuming all ALUs are working.
Going with NCU's variable width SIMD layout will solve this issue, so we should get a more closer and truer comparison of paper spec TFlops to gaming performance. ie. A Vega of 12.5 TFlops will absolutely wreck Fury X.Jobb később megtudni, mint soha. Most már értem az eddig érthetetlen túlfogyasztást az Nvidia GPU-khoz képest.
#tarcsad
-
#26020
Petykemano
veterán
Yutani
#26018
-
#26021
Malibutomi
nagyúr
Yutani
#26018
-
#26258
Petykemano
veterán
gyiku
#26252
Petykemano
veterán
Biztos megy oda kábel?
Nem tudom, 6 vagy 8 pines kábeleket felesleges lenne takargatni. 6+8-et igen, de az nagy baj. Vagy azt, ha nincs kábel.<on the hype train>
Végy egy fury x-et
- tudvalevő, hogy minden magasabb speckó ellenére visszafogja a geometria.
- utoljára azt olvastam, hogy egy bug miatt nem is jön ki belőle az 512GB/s, csak kB 370
Így tud a doomban mennyit? 45fps
Igazából tényleg alig jön ki belőle több, mint a 390xNamost tegyük fel, hogy javítják a hibákat:
- geometria 4 -> 11
- memória sávszélesség bug javítása + továbfejlesztett DCC
Ezzel minimum elimináltad a szűk keresztmetszeteket. Az persze kérdés, hogy így többet fogyasztana-e. De tételezzzük fel, hogy nem, mert ha van dolga, csak erőforrásra vár, akkor mondjuk nem kapcsol le...
Így kijönne +25-30%, amit a 390x-től 40%-kal több shader indokolna.Ha semmi más nem változna, akkor csak +25% órajel kellene a 70fps-hez.
- induljunk ki abból az xfx 480 gtrből, ami 1288mhz-et tudott 90-100w-ból. Ha ezt a 90w asic powert arányosítom 2304 shaderről 4096 shaderre, akkor 160w.
- ha levonjuk a memóriavezérlőket (4 csoport gddr helyett 2 csoport hbm2), figyelembe vesszük a variable length simd unitkat, valamint azt, hogy az architektúrát a korábbiakhoz képest magasabb órajelre tervezték, és további újítások, bár meredeken hangzik, de nem elképzelhetetlen, hogy becsússzanak 75w alá beleértve ebbe a 5-10w hbm2 fogyasztást is.Találgatunk, aztán majd úgyis kiderül..
-
#27039
Petykemano
veterán
Petykemano
veterán
Most már azt is tudhatni vélhetjük, hogy a kis Vega 44CUt tartalmaz.
Az RX 480-hoz képest 2x teljesítményre van az 1080, amivel nagyjából megegyező eredményű vegát demóztak.
44/36 = 1.22
1600/1266 = 1.26Ezek persze csak feltételezések és a MI25-höz képest az 1600 kicsit merész, de ezen túl csak további 30%-ot kell találni:
- memória rendszer hatékonyságból
- geometriai rendszer hatékomyságából
- packed mathból, és egyéb primitive shader cuccból.
- variable length simd unitokból
- tiled based renderingből és Unified l2$ ből.
- esetleges további extra frekvencia kisajtolásából.Ha itt ott találnak 5-6%-ot és persze lehetséges az 1600mhz, (ami az 1500mhz polaris után miért is ne lenne lehetséges?) akkor könnyen lehet, hogy a demózott Vega tényleg nem a fury utódként várt vega10 volt.
Ugyanakkor a 64/44 csak 45%, amivel épp csak meglépné az 1080ti-t.
És az is fury, hogy egy ilyen kártyát miért neveznének esport piacra szánt kárytának?
Találgatunk, aztán majd úgyis kiderül..
-
#27657
Petykemano
veterán
Petykemano
#27656
Petykemano
veterán
válasz
Petykemano
#27656
üzenetére
Kiegészítés a bázis polarishoz:
Az ugye tudvalevő, hogy míg a keplernél (290x vs 780ti) nem, vagy alig, a Maxwell óta nagyonis megfigyelhető, hogy mennyivel jobban hasznosul az nvidia kártyákban rejlő elméleti számítási teljesítmény, vagyis frekvenciából és shader számból számolható tflops érték.
390x vs 980: az amdnek 30+% magasabb a tlops érték
480 vs 1060: 5.83. Vs 4.4 vagyis 30+%-kal magasabb
Furyx vs 980ti: 8.6 vs 5.6, vagyis brutális 50+%Ez ugye nem jön ki. Mondjuk ebből akár számolható is lenne hogy a fiji pont annyira lenne bottleneckes, mint a Hawaii, akkor 6.45tlops jönne ki belőle az 5.6 helyett, és akkor pont 15%-kal mozdulna el a 980ti-től.
Szóval ez a 30%/50% többlet az elméleti számítási kapacitásból nem jön ki. Ennyivel rosszabb hatásfok, vagy a gcn ennyivel jobban bottleneckes.
A számítási kapacitás ott van, ezt a Doom benchmarkban láthattuk.
Ha a Vega ezt fel tudja oldani....
1) elképzelhető, hogy a variable lemgth simd és cun belül lekapcsolható Simd megoldja, és a nyert erőforrást a működő, adott esetben rövidebb hosszú simd egység frekvenciájára lehet költeni. Ebben az esetben az eredménye nyilván benne van az 1525mhz pletykált frekvenciában.
2) de elképzelhető, hogy más részegységek, a frontend, vagy uncore, pl a tile based raszterizáció, vagy a geometriai processzor felújítása révén növekedhet a hatásfok. Ebben az esetben realizálható további növekmény is.Találgatunk, aztán majd úgyis kiderül..
-
#28420
Petykemano
veterán
Armando_19
#28419
Petykemano
veterán
válasz
Armando_19
#28419
üzenetére
Szerintem olyan polarisos soft launchra lehet számítani, ahol bemutatják a kártyát, ellőnek majd pár összehasonlítást a 390X (léghűtéses, vágott, stb) és talán a Fury X (vizes) ellen, és 1 hónap múlva a boltokban.
A ryzen hard launch esetén ilyenkor már azért szivárogtak az infók a boltokba érkezett dobozokról.Hogy teljesítmény tekintetében mire lehet számítani, azt már sokan sokféle módon elmondták. Vannak, akik arra szákítanak, hogy a Vega csupán a fiji 14nm-re portolt változata, és magasabb órajelen is csupán néhány százalékkal lesz gyorsabb, mint a fury x, az vízes hűtő pedig azért kell, mert annyit is fog fogyasztani. Ez persze teljes hülyeség.
A legegyszerűbb megfogni egy rx 470-et és duplázni a csíkjait, majd felszorozni a várt 1525-ös órajellel.
De azért nem ilyen egyszerű
Az ocnet fórumon utoljára mahigan foglalta össze, mi várható: geometria kikupálása, ami az összes gcnt sujtotta eddig. Alacsonyabb felbontáson, ahol kevesebb a pixel, de ugyanannyi a háromszög a gcn gyengélkedett. Ezen a polaris primitive discard acceleratora némileg segített, de lehet, hogy még mindig limitált sok esetben.
A Vega erre mindenképpen megoldást fog hozniThe stilt az AT raven ridge fórumán említette, hogy a korábbi apu példák alapján valószínűleg még a polaris is sávszél limites. A draw bin rasterizer ezen segít. Ugye ez is olyan dolog, hogy ha folyamatosan a mémóriához kell nyúlni valamilyen művelet során, akkor a magas fps eléréseben a memória rendszer elérésének késleltetése is gátat fog szabni. Azonkívül fogyaszt.
Fentiek mind olyan problémák, amelyek magyarázhatják azt a jelenséget, amiért ugyanazt az fpst az nvidia kártya kevesebb tflopsból ki tudja hozni. A gcnben belső buborékok keletkeznek különböző késleltetések miatt. Eközben persze a számolóegységek is fogyasztanak mind a sok terflops, meg a túlterhelt memóriarendszer is fogyaszt. Tehát emiatt nem csak a kihasználtság volt rosszabb a névleges teljesítményhez képest, hanem a fogyasztás is magasabb. Ezért jött az aszinkron compute ötlete, amivel be lehet fogni az üresjáratban ketyegő számítási kapacitást. Lásd doom, ahol befogták a buborékokat és látványos javulást értek el.
Amire én még számítok az a variable wavelenght, ami a változó simd méreteket jelenti. Ez szintén jelentős energiamegtakaítással járhat, mert kevesebb tényleges munkavégzés nélküli számolóegységet kell pörgetni.
A magam részéről 1080ti teljesítményre számítok
Találgatunk, aztán majd úgyis kiderül..
-
#29263
Petykemano
veterán
Raymond
#29230
Petykemano
veterán
válasz
Raymond
#29230
üzenetére
A 2x szorzót simán megugorják: levezetés
A fogyasztásra is komoly javítások jönnek:
- TBR => enyhíti a memória alrendszer terhelésété
- közvetlen L2$ kapcsolat => enyhíti a memória alrendszer terhelését
- NCU + variable length SIMD (variable wavefront) => csökkenti a számolóegységek üresjáratát és üresjárati fogyasztását
- NCU - magasabb órajelre optimalizált designNem érdemes a polarosból kiindulni. A polaris GFX8.1, vagyis ugyanazokra a GCN alapora épít, mint a tonga vagy a fiji. És mivel tudjuk, hogy az elérhető órajel ma már főképp design kérdés, így sejthető, hogy a polaris optimális, design közben megcélzott órajele jóval az alatt van, amin üzemeltetik.
Találgatunk, aztán majd úgyis kiderül..
-
HSM
félisten
"Preempció GPU-ban akkor kell, amikor jelentős előny realizálható a műveletek csereberéjéből."
Na, ezaz, amire általánosan nincs szükség egy GPU-nál, hiszen a GPU alapból nem egy késleltetésre kihegyezett eszköz alapvetően, hanem éppen abból gazdálkodik, hogy átlapol képkockákat, és ezzel igyekszik folyamatosan munkával feltöltve tartani magát. A műveletek csereberéje az out of order végrehajtás, ezt tudtommal alapból megteszik a driverek, illetve a GPU ütemezője, ahol lehet.
A preempció akkor válik szükségessé, amikor egy művelet valamiért fontosabb, mint a többi, vagy valamilyen idő korlátba ütközik, mint pl. az audio számítások, VR, vagy megvalósíthatóak olyan effektek, vagy technológiák, amikre enélkül nem lenne lehetőség. Nyilván egyhamar ezekre nem érdemes számítani, mivel a piaci részesedése a modern, preempció képes GCN-eknek nokedli, és nem hiszem, hogy ez drámaian megváltozna hirtelen fél-egy éven belül.Az üres buborékokra a Vega variable width SIMD lehet a megoldás, bár elég kevés még erről az infó. Előbetöltés alapesetben azért nem szükséges a buborékok ellen, mert alapból el van árasztva a GPU munkával, és így nem okoz gondot, ha valami picivel később áll csak rendelkezésre. Ugye, amit írtam, előbetöltés akkor kell, ha egy wavefront dolgozik, azaz a GPU nincs "elárasztva" munkával, így kritikus, hogy az adott wave-hez minden rendelkezésre álljon, mire végrehajtásra kerül. Ugye, itt megint az a helyzet, hogy nincs ebből profitálás, amíg nincs szükség arra, hogy sorrend helyesen, azaz elárasztás nélkül futtasunk bizonyos kódokat a GPU-n. Márpedig ugye itt előbetöltés nélküli GPU-k szörnyű kínok elé néznének, tehát ezzel is csínján fognak egy ideig biztosan bánni a fejlesztők, amíg nincs komolyabb user-base, és hacsak nem hozzák át konzolról.
Ami a perf/watt elmaradást illeti, szvsz arra a kulcs amit korábban írtam, hogy az Nv nagyon rágyúrt arra, hogy az API-k csak részhalmazát valósítják meg, de azt hatékonyan, míg az AMD részéről sokkal inkább azt látom, hogy egy általános GPU-t építettek, amiben sokkal jobban ügyeltek arra, hogy mindent tudjon, amire az aktuális API-ban és a nagyon közeli jövőben számítani lehet, vagy akár itt-ott kicsit többet is. Viszont nagyon érdekes lehet, hogy az új Volta mit és merre fog lépni, és hogyan fog alakulni a perf/watt arány, mert a jelenlegi zöld architektúrával ezen a téren a verseny szerintem teljesen irreális gondolat, viszont előbb utóbb a zöldeknek is lpniük kellene, ha valóban ez lesza z irány, hogy a konzolokról újfajta kódok fognak átszivárogni PC-re. A Vega is ezt az irányát viszi tovább az AMD-nek, ami szerintem igen jó hír, immáron magas órajelen, nekem összességében nagyon tetszik.
[ Szerkesztve ]
-
#30629
Petykemano
veterán
Yany
#30625
Petykemano
veterán
Én ezt (1080@300w) azért nem tartom valószínűnek, mert ezt a polaris megfelelő méretűre skálázásával is elérték volna. (Figyelmen kívül hagyva a geometria számítás korlátosságát.)
Sőt, valójában a 1080 és 480 között már csak 60% különbség van, így ez az eredmény 1150mhz-cel is Bíztató lett volna. Az hogy mégse jön a furyx-ből ez ki az pont a benne található szűk keresztmetszetek miatt van.Ha feltételezzük, hogy kikalapálták az összes szűk keresztmetszetet és tökéletesen tud skálázódni, akkor matek szerint az 1080ti-t is elérné. (4096, 1400mhz)
Persze a fogyasztás valóban 300 körül lehetne, főleg ha abból indulunk ki, hogy az rx 580 hogy éri el a 1300+-os órajelet.
És akkor ebből vesz le harmadot sayinpety szerint a DBSR. És ha lesz ilyen fícsör, akkor a variable length simd.Azt gondolom, hogy az így felszabaduló 100-150w-ot használják fel a frekvencia tipikus 1400-ról 1600ra turbóztatására,amiről ugye tudjuk, milyen rosszul skálázódik. (Durván emelkedik a fogyaztás) És így kap majd tdp-t.
Tehát én 10-20%-kal a 1080ti fölé várnám végül.
[ Szerkesztve ]
Találgatunk, aztán majd úgyis kiderül..
-
#35500
Petykemano
veterán
#45185024
#35496
Petykemano
veterán
válasz
#45185024
#35496
üzenetére
Ez jó. Hihető.
Eddig azt gondoltuk, hogy biztos a tile based rasterizer és hogy kevesebb memóriasávszélesség is elég, a GCN meg memóriaéhes. nvidiának elég a szívószál. Na meg a DElta color compression.
Meg azt is gondoltuk, hogy a geometria, hiszen az nvidia sokat szivatta a tesszelációval az amd-tDe most újragondoljuk és a kabátot is újragomboljuk.
Átmentek a Zenes tervezők a radeon divízióba és rögtön falhoz vágta őket: ÚRISTEN, TI MÉG AZ IN ORDER EXECUTION-nél TARTOTOK??? (jó, persze kicsit csúsztatok)Mert ugye valami olyasmi történhetett még a régmúltban, hogy rájöttek, hogy nem hatékony a VLIW, mert - konyhanyelven - sokasodik az utasítások számossága, és nincs kihasználva a széles szó. Nem jön két ugyanolyan adatcsomag. Tudjátok, mint a tetrisben.
Aztán jött a GCN meg a SIMD és most már hatékony az utasításváltás, programozható, szuperskalár. De még így se jó.
Most tehát azt gondoljuk, azért jobb az Nvidia, mert nem "in-order" egy utasítással hajt végre annyi műveletet, amennyi adat rendelkezésre áll, hanem megfogja az adatot és annyi utasítást hajt végre rá, amennyit csak tud.
Najó, nem akarom viccesen túlokoskodni, de a lényeg, hogy megjött az új csoda-feature, amivel az AMD behozza a lemaradást.
(pont úgy, mint a primitive shader, compute shader, a dsbr, a variable length simd, async compute)
Na várjunk csak. Tulajdonképpen ez nem arról szól, hogy hát eddig is tudtak az ALU-k többmindent számolni, de csak akkor, ha külön szálon ment. Lehet, hogy mégse lőttem olyan távol az in-order - out-of-order hasonlattal? Hiszen képzeljünk csak el egy 4096 magos in-order végrehajtású processzort, amiben van mondjuk 4 ALU. Jönnek az utasítások és néha 1, néha 3, néha 4, néha 2 ALU kap egy-egy ütemre ténylegesen feladtot. Az async compute pont úgy működött, mint a processzorokban az SMT. Egy teljesen külön szál tudja hasznosítani a 4096 mag használaton kívüli ALU kapacitását.
De ha átalakítjuk a a procit ilyen spekulatív out-of-order végrehajtásúra, akkor ugye hirtelen több feladattal lehet egy ütemre feltölteni a 4 ALU-t.
Nem azt mondom, hogy pont ez történik, de illusztrációnak jó.
Találgatunk, aztán majd úgyis kiderül..
-
#37145
Petykemano
veterán
lezso6
#37138
Petykemano
veterán
válasz
lezso6
#37138
üzenetére
gbors korábbi megállípítása az volt, hogy az amd ott rontotta el, hogy össze-vissza kapálózva hozta az architektúrákat, néha többet is mint kellett volna, aztán ezeket nem vezette ki, hanem átnevezgette. TEhát többet is csinált, mint talán szükséges lett volna és több is volt neki egyszerre aktívan üzemben/fókuszban.
Ehhez képest most azt mondtad el, hogy az nvidia az elmúlt néhány évben össze-vissza változtatta az architektúra felépítését, míg az AMD-é alig változott, hozta a "szokásosat". És ennek ellenére sikerült mindig az nvidiára jól optimalizálni, az AMD-re sok-sok éves változatlanság ellenére sem.
Ezzel együtt persze értem, hogy a mondandód lényege az volt, hogy a hardveres vezérlés volt a keplertől-paxwellig nagyjából bezárólag az nvidia előnye.
Én azon gondolkodtam el azon, amit mondtál, hogy a maxwell 4x32 ALU (Turingnál 4x16), az AMD esetén pedig 64ALU/CU. Ha jól emlékszem ezt a témát nagyjából fedi a korábban variable length SIMD ötlet
(Amit én kétlek, hogy a vega tudna)
Valószínűleg innen jöhetett az ötleted: https://en.wikipedia.org/wiki/Pascal_(microarchitecture)#Overview
What AMD calls a CU (compute unit) can be compared to what Nvidia calls an SM (streaming multiprocessor). While all CU versions consist of 64 shader processors (i.e. 4 SIMD Vector Units (each 16-lane wide)= 64), Nvidia (regularly calling shader processors "CUDA cores") experimented with very different numbers:
és akkor itt elsorolják, hogy egy SM-ben hány multiprocesszor van az egyes architektúrákban összesen, de azt, hogy azoknak van-e hossza, az nem.
Fenti ábrán látszik, hogy ennek milyen jelentősége lehet. Ha igazad van, akkor az elméleti teraflopsok az nvidina esetén jobb hasznosulásának oka lehet az, hogy a fenti ábrán szereplő "4x16 SIMD vector unit"-nál az nvidia architekturáinak granularitása legalább a maxwelltől nagyobb.
Egyébként mindenazonáltal érdekes, hogy szoftveres vezérléssel az nvidia jobb eredményeket ért el.
Találgatunk, aztán majd úgyis kiderül..
-
Szó sincs őrületes nagy ugrásokról. A legtöbb játék elég széles FPS-tartományban működik, pályák vagy akár jelenetek között simán lehet 2x különbség. Ha belövöm az átlagot 60-70 FPS környékére, akkor simán lesznek részek 40-50 FPS-sel és 80-90 FPS-sel is. A variable sync megoldásnak ezeket nagyon is feladata kezelni - akkor is, ha a saját igényeid ennél megengedőbbek.
(#38324) HSM: ha adaptív sync alatt arra gondolsz, hogy refresh rate felett vsync on, akkor noplease
De amúgy ha a chill és a custom resolution kombinálásával meg lehet oldani a dolgot, az frankó - miután én sosem hittem abban, hogy az async megoldások ingyen lesznek és mindent fognak tudni, az olcsó monitor és az olcsó kártya mellett van létjogosultsága némi hackelésnek Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...
-
#40050
Petykemano
veterán
Petykemano
veterán
Formerly Nvidia-only
Valami.hasonlót kitalálhattak volna a víz alatti tesszelációra.
[ Szerkesztve ]
Találgatunk, aztán majd úgyis kiderül..
-
#40051
Raymond
félisten
Petykemano
#40050
Raymond
félisten
válasz
Petykemano
#40050
üzenetére
"Formerly Nvidia-only"
Meg most is az:
"VRS support exists today on in-market NVIDIA hardware and on upcoming Intel hardware.
Intel’s already started doing experiments with variable rate shading on prototype Gen11 hardware, scheduled to come out this year."
Privat velemeny - keretik nem megkovezni...
-
#44077
Tyrel
őstag
Petykemano
#44076
Tyrel
őstag
válasz
Petykemano
#44076
üzenetére
Na vééégre valami... mondjuk februárra így nem lesz ebből semmi, kb. szerencse lesz ha nyár előtt eljut hozzánk, akkor meg már jön az Ampere is és megette a rosseb.
Visszatérve a cikkre, az elég falsnak tűnik hogy ez szerintük már RDNA-2 lehet RT hardverrel, nem tudom honnan szedték... Erősen kétlem hogy 2020Q4 előtt találkozhatnánk RDNA-2-vel.
Más:
Variable Rate Shading-ről megint beszélik hogy jön AMD oldalra is, de szerintem itt elsősorban nem is az érdekes most, hogy jön-e... hanem hogy nVidia oldalon ez performance-trükközés így by default mindig aktív a támogatott játékokban, vagy kapcsolgatható??
Arra célzok, hogy az eddigi game benchmarkokban ahol pl. az RTX 2070 és az 5700XT fej-fej mellett voltak, ott azt az azonos teljesítményt az nVidia kártya vajon VRS-el hozta-e, vagy nélküle?...[ Szerkesztve ]
Turenkarn
-
Tyrel
őstag
Nekem a Chill minden játékban jól működik amikhez egyébként jár Chill kapcsoló. Úgy emlékszem az utóbbi időben amikkel játszottam, egyedül Life is Strange 2-nek nem volt Chill kapcsolója, de nem tudom mi az oka. Talán DX11 alatti API-t használ még, vagy fogalmam sincs. Abu biztos tudja...
Erre a Boost-ra én is nagyon kíváncsi vagyok, hogy milyen játékok alatt lehet majd bekapcsolni... de szerintem nem csak az APU-sokat célozza (ha egyáltalán működni fog APU-kon) hanem a 4K vagy még nagyobb felbontású megjelenítővel játszani óhajtókat is. Feltéve hogy nem olyan lesz mint a DLSS, hogy magának a játéknak kell támogatnia, mert ha igen akkor (AMD marketing erejét figyelembe véve) nagyjából semmi sem fogja támogatni.
#44644
Szerintem elég sokan várják ettől a drivertől az Integer Scaling és Variable Rate Shading támogatást, azok pl. nem csak tech-buziknak szólnának... Most már egy héten belül csak kiderül...
#44642
Maga a Radeon Software GUI szerintem sokkal jobb mint az nVidia megoldása (mondom ezt úgy hogy pár hete még 1070Ti-m volt), már design és funkcionalitás szempontjából, meg gyorsabb is (pl. nVidiás cumó némelyik kapcsoló átbillentése után egész sokat tudott gondolkodni). Ja meg persze nem kell külön az Experience meg nem kell regisztrálgatni meg ilyen marhaságokat, csak ott van egyben az egész és megy, ill. vannak olyan funkciói amik a nVidia Control Panelnek és az Experience-nek együttesen sem voltak, és még külön kellett használnom mellette egy nVidia Inspector nevű cuccot is.
Radeon Software-vel nincs ilyen gond, egymagában megold nekem mindent amire szükségem van.Egy baj van valóban a GUI-jával, az a menürendszer struktúrája. Ha nem is épp logikátlan, de nem felhasználóbarát, bizonyos funkciókat elég sok lépésen keresztül érsz csak el, és bizonyos kapcsolók (pl. RIS) is rossz helyen vannak. Nem mintha az nV Control Panel olyan áttekinthető és logikus lenne, de az hogy a zöldeknek sz*r nyilván nem mentség rá hogy akkor a pirosaké is sz*r lehet.
[ Szerkesztve ]
Turenkarn
-
Tyrel
őstag
Hm, ide még nem is volt linkelve az új driver?
Röviden, az új UI biztos tök jó, de nagy optimalizálások ezúttal se voltak, mert a +12% sebességtöbbletet nem az előző, hanem a legelső Navi driverhez merik csak viszonyítani...
RIS-t végre rendbe tették, jött mellé Integer Scaling is, de Variable Rate Shading nem.
DirectML media filters - ezt miben/hogyan lehet használni?
[ Szerkesztve ]
Turenkarn
-
#44939
Tyrel
őstag
Petykemano
#44938
Tyrel
őstag
válasz
Petykemano
#44938
üzenetére
Jelenlegi konzolokról portolt játékoknál se számított, nem futnak jobban AMD videokártyákon (max. 1-1 ritka kivétel, amikre ugyan úgy vannak ellenpéldák is)
Egyébként RDNA2-ben lesz Variable Rate Shading és RayTracing, új konzolokban is lesz mindkettő... innen nézve szerintem elég egyértelmű melyik RDNA generációhoz állnak közel az új konzolok, pláne hogy a leak factory is jó ideje az RDNA2-höz társítja őket.
VRS-en egyébként csodálkozom hogy most a 2020-as driverrel nem hozták ki a Navi-khoz, lehet valami hardveres akadálya van ami miatt csak RDNA2-vel jöhet majd... ez tovább erősíti a konzolos rokonságot. (ok, értem, nem 1:1-ben ugyan az a két GPU, de közös alapokra építkeznek, csak aztán customizálják őket a célplatformnak megfelelően)
Vicces amúgy hogy pár éve még az AMD mennyire elöl járt az újabb API-k támogatásában, akár új Shader Model-ekről, akár DirectX feature level-ekről vagy bármi más nagyon új vagy nagyon experimental cuccról volt szó, ők mindig hozták a támogatást. Most meg messze lemaradva kullognak nVidia mögött...
Gyönyörűen végig aludták ezt a pár évet... [ Szerkesztve ]
Turenkarn
-
#82819712
törölt tag
HÍRCSOKOR:
Na akkor a Popularhardver felé nyitás keretében a többieknek is.
NV megvásárolta a Mellanox nevű céget 7 milliárd dollárért, ami nem kis pénz, hát még jó hogy nem az AMD jutott eszébe
Tudom ez így elsőre OFF-nak tűnik itt, de hogy nem az az biztos mert rengeteg hatása lesz AMD-re ezeket már szépen lehetne is kezdeni kielemezni itt.
A cégről nagyon röviden annyit kell tudni hogy sok licensszel rendelkezik, és a b. által felsoroltakon kívül a nagy fürtös szuperszámítógépes összekapcsolások mestere. Itt meg mást se hallunk hogy fine wine, fine wine.
Azt majd NV fórumon kibeszélik mi mindenre jó ez nekik, ami engem ebben nagyon birizgál az a birtokolt licenszek.
Mondhatja e azt egy cég hogy ezt Te NEM használhatod pl ha tudja hogy pl épp most tetted bele az EL CAPITAN-ba.
Vagy menjünk tovább a gondolatmeneten mondhatja e azt hogy olyan árat mondok ami elképzelhetetlenül magas érte?
A konzol is jó példa erre mert az AMD CPU- GPU szentélybe az SSD NVME csatolós pedig van AMDnek szabadalma gyors adatösszeköttetésre.Haladjunk tovább.
Hamarosan ITT az első RDNA2 GAMEPLAY !!!!
Bezony kiderül mit tud.
Remélem mindenki látta tegnap az Assassin's Creed Valhalla demót
Na ez mégjobb lesz
és ha már itt vagyunk a RT mellé jön a VRS (Variable Rate Shading).
kedves NV-s olvasóink most ne figyeljenek ide
és ha jön ez az "újdonság" akkor már nézzünk meg róla egy friss analízist a Digital Foundry tollából.már csak egy gondolatom van, nyugi mindjárt jön a szünet és mehetsz a hűtőhoz
de a reklámot előtte mindig meg kell nézni ez a szabály nézzük meg a PH reklámot a lap tetején.
Váltsunk a felhőre! mondja.Remélem nem használtok reklám blokkolót rosszcsontok. Hogyan tudnánk játékokkal a felhőre váltani ? Háát mi lenne ha segítséget kérnénk? és megbíznánk mondjuk egy közepesen ismert céget hogy grafikus technológiákat fejlesszenek ki a növekvő felhőalapú játékpiac számára.
Ha azt mondom Star Swarm nem biztos hogy mindenkinek beugrik
de ha azt mondom hogy a NITROUS motorral akarják ezt megcsinálni akkor már sokaknak bevillan az oxidegames neve.
LINK[ Szerkesztve ]
-
#46512
Petykemano
veterán
Robi BALBOA
#46511
Petykemano
veterán
válasz
Robi BALBOA
#46511
üzenetére
Én nem bánom, hogy az Alternate frame rendering eljárást elengedik. Én ugyan nem próbáltam sose, de a negatív oldalon a megnövekvő frame time áll.
Szerintem a képernyő felosztása jobb megoldás.
Nyilván itt meg az a kérdés merül föl, hogy hogy ossza el a képernyőt a rendszer a két akár különböző kapacitású gpura és mi van, ha a képernyő bizonyos részein más jelentőségű esemény történik.
De. Azon gondolkodtam el, hogy ha már van variable rate shading, ami ugye arról.szól, hogy a kép bizonyos részeit valamilyen szabály alapján felosztja részletesen és kevésbé részletesen renderelt részekre, akkor vajon nem oldható-e meg ezek multigpu-s kiszervezése. Mondjuk akár IGP-re.
Persze ez továbbra is szoftveres megoldás.
Azt gondolom, valamilyen megoldás biztosan lesz. Szerintem az a terv, hogy a 8k raytracing felhőben valósul meg, mivel ehhez még nincs elég erős kártya. Viszont a cloudban egy 30+ magos gépben van 4 erős gpu is. Az bármit elfuttat, csak kell hozzá szoftver. Tehát meg fog sztem valósulni az a skálázódás is, hogy egy játék több gpun. Ráadásul úgy, hogy igény szerint. Nyilván ahogy most futtathat egy gpu több játékot, mert nem minden kliensnek kell a gpu minden erőforrása minden időpillanatban, többgpu rendszerben is bizonyos képkockákhoz kellhet 3 gpura való skálázódás, másikra elég lehet csak 2.
Találgatunk, aztán majd úgyis kiderül..
-
#48617
Petykemano
veterán
Jack@l
#48616
Petykemano
veterán
válasz
Jack@l
#48616
üzenetére
fogalmam sincs, hogy honnan van az a táblázat, de remek hamisítvány.
Elméletben a Game/oo Cache kompenzálja az alacsonyabb memória adatátviteli sebességet
Furcsa és egyben egyedi, hogy ebben a táblázatban másfélszerezték a SP/CU számot az eddigiekhez képest. Eddig ugyanis a 40CU 2560 Stream processzort jelentett, itt meg 3840-et. Ez mondjuk megmagyarázná, hogy miképp érheti el a 2080Ti szintjét a 40CU(Pár poszttal feljebb meg egy olyan blokk diagram volt, amin 160CU volt.)
Vajon ezt hogy jöhetne ki?
[link]egy CU-ban 3db SIMD32 lehetne?
Vagy variable width SIMD units lehetne?(Persze csak lehetne, mert a táblázat nyilvánvalóan fake.)
Találgatunk, aztán majd úgyis kiderül..
-
#50603
Petykemano
veterán
Mumee
#50599
Petykemano
veterán
A DLSS-ben ha jól tudom, már most is van olyan funkció, vagy jellegzetesség, hogy ha mozog a képernyő, akkor azért gyengébb a minőség, de amikor megáll, akkor kitisztul, kiélesedek.
bocs, ha kicsit pongyolán fogalmazom meg.
Van egy másik érdekes fícsör, a Variable Rate Shading, ami ha jól tudom, szintén érkezik az új konzolokkal és biztos az RDNA2 alapú AMD gpu-k is tudni fogják.
Ez valami olyasmiről szól, hogy a frame bizonyos részeit, ami kevésbé látványos, kevésbé változik, kevésbé látható, távolabbi, stb, lényegében alacsonyabb felbontással rendereli.
Már a VRS-t össze lehetne kötni a DLSS-szel úgy, hogy a frame célfelbontása állandó, viszont a frame bizonyos részeit alacsonyabb, a fontos részeit magasabb felbontásról skálázza fel, szükség esetén akár natív felbontáson is megjeleníthet, ha a minőségi igény megkívánja.
Az jutott eszembe, hogy vajon össze lehetne ezt még kapcsolni a Radeon Chill-lel. Tudom, azt sokan nem szeretik, mert ki az a lökött, aki mondjuk 60fps-sel akarna játszani, amikor játszhatna 90-nel, vagy akár 144-gyel is?
De valahogy a chill is elemzi, hogy mozog-e a játékos, vagy van-e user input, és vissza tudja venni az fps-t. ha egyébként nem történik semmi és így energiát takarít meg valamint hőpuffert képez.Ezt tovább lehet fokozni azzal, hogy chill nem csak a frekvenciát veszi vissza, hanem a felskálázás forrásfelbontását is lejjebb tolja. Bár természetesen a Chill a user inputra figyel, a működése az, hogy lecsökkenti az fps-t, úgy is fogalmazhatnánk, hogy kihagy komplett képkockák renderelését.
És itt most megpróbálom összerakni a hármat.
Vajon megoldható-e az, hogy a frame kevésbé fontos, vagy háttérben levő, stb részeit (amit a VRS alacsonyabb felbontáson renderelne), egyszerűen ne is renderelje még akár alacsony felbontáson se (amit DL upscaling technikával lehetne a kívánt célfelbontásra skálázni), hanem a frame-nek azt a részének renderelését hagyja ki és bízza rá a DL upscaling technikára, hogy az előző képkocka alapján töltse ki?Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
World of Warcraft: Shadowlands végleges verziójában az új leképező shadow RT-t és variable rate shadinget fog kínálni. A réjtrészing DXR 1.1-gyel lesz megoldva. Emellett a fejlesztők új SSAO-t is bevetnek. Úgy tudom, hogy ez a FidelityFX-féle CACAO. Azt nem tudom, hogy ez leváltja-e a mostani HBAO-t, vagy csak kiegészíti extra opcióként.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Z10N
veterán
válasz
GeryFlash
#56237
üzenetére
"A GPU viszont kb egy RX560 szint lesz (ugye annak nagyobb TFLOPS de RDNA-nel visszavagtak a TFLOPSbol ergo 2TFLOPS az kb Polaris 2,6). Hat az kb arra lesz jo hogy 576p-720-ben futassa a jatekokat, de talan majd FSR segiteni fog hogy meglegyen az a varazslatos 1280 X 720 nativ felbontas"
RX560 16CU ~1200-1300MHz (max 2,6624 TFLOPS)
ez manapsag 720p high-ra eleg AAA-nal (4GB, 2GB medium)
esetleg 1080p low-ra, esport/kazual 60FPS-reRDNA2 8CU ~1600 1,6384 TFLOPS, szoval nincs 2TFLOPS
Ezek pariban vannak:
5500XT (RDNA1) 22CU ~1800 5,0688 TFLOPS (4835-5196 GFLOPS)
RX580 36CU ~1300 5,9904 TFLOPS (5792-6175 GFLOPS)Az RDNA1 ~18%-t hoz a Polarison (effektive orajel+ipc). TFH az RDNA2 ennek a duplajat 36%-t hoz ebben az osszeallitasban.
1,6384 x 1,36 = 2,228224
RX560 2,6624Meg mindig el van maradva ~19,48%-kal
Szoval 720p high-ra eppen eleg lesz AAA-nal.
Ahogy mondod 576p + FSR is elkepzelheto kesobbre.
Tehat ki lett centizve. Inkabb 12CU kellett volna, hogy par ev mulva is hasznalhato legyen.Oszinten szolva a proci 720p/60-ra 3.5GHz turboval nem nagyon kell. Eleg lett volna 2-3GHz. Igy maradt volna egy kis hely a 12CU TDP-hez. Persze igy olcsobb es inkabb marad az FSR.
Hivatalosan:
RDNA 2 with 8 CUs,
variable frequency @ 1.0–1.6 GHzZen 2, 4-core, 8-threads,
variable frequency @ 2.4–3.5 GHzBar a Zen2 es az RDNA2 is 7nm, a gpu orajel 14nm szint. Nalam konkretan a 2200G-ben fut 1600-n a Vega8. A mostani APUkban az igp olyan 2GHz korul ketyeg, ahogy latom tuninngal 2,5GHz. Persze ezt sokkal nagyobb TDP-vel. Szoval ez az steam deck igp CU-ban es orajelben is elegge vissza lesz fogva, hogy eppen eleg legyen 720p-re.
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
- New rasterizer control fields (Lightning accel.)
- 6 Shader Engines for RDNA3 (8 in another place)
- Variable Rate Shading (VRS) with 4 pixel supported, not only 2
- New Oreomode
- Removed Enhanced Quality Anti-Aliasing EQAA"A számítógépek hasznavehetetlenek. Csak válaszokat tudnak adni." (Pablo Picasso) "Never underrate your Jensen." (kopite7kimi)
-
S_x96x_S
őstag
Raytracing on AMD’s RDNA 2/3, and Nvidia’s Turing and Pascal
https://chipsandcheese.com/2023/03/22/raytracing-on-amds-rdna-2-3-and-nvidias-turing-and-pascal/
"AMD takes a more conventional approach that wouldn’t be out of place on a CPU, and uses a rigid BVH format that allows for simpler hardware. AMD’s RT accelerators don’t have to deal with variable length nodes. However, AMD BVH makes it more vulnerable to cache and memory latency, one of a GPU’s traditional weaknesses. RDNA 3 counters this by hitting the problem from all sides. Cache latency has gone down, while capacity has gone up. Raytracing specific LDS instructions help reduce latency within the shader that’s handling ray traversal. Finally, increased vector register file capacity lets each WGP hold state for more threads, letting it keep more rays in flight to hide latency. A lot of these optimizations will help a wide range of workloads beyond raytracing. It’s hard to see what wouldn’t benefit from higher occupancy and better caching.
Nvidia takes a radically different approach that plays to a GPU’s advantages. By using a very wide tree, Nvidia shifts emphasis away from cache and memory latency, and toward compute throughput. With Ada, that’s where I suspect Nvidia’s approach really starts to shine. Ampere already had a staggering SM count, with RT cores that have double the triangle test throughput compared to Turing. Ada pushes things further, with an even higher SM count and triangle test throughput doubled again. There’s a lot less divide and conquer in Nvidia’s approach, but there’s a lot more parallelism available. And Nvidia is bringing tons of dedicated hardware to plow through those intersection tests.
But that doesn’t mean Nvidia’s weak on the caching front either. Ada has an incredible cache hierarchy. I suspect Nvidia’s bringing that together with the factors above to stay roughly one generation ahead of AMD in raytracing workloads. With regards to raytracing strategy, and how exactly to implement a BVH, I don’t think there’s a fundamentally right or wrong approach. Nvidia and AMD have both made significant strides towards better raytracing performance. As raytracing gets wider adoption and more use though, we may see AMD’s designs trend towards bigger investments into raytracing.
"""Mottó: "A verseny jó!"
-
PuMbA
titán
válasz
T.Peter
#64069
üzenetére
Render time-ra mínusz 50%-ot, a GPU time-ra mínusz 25%-ot mondtak
Utóbbi amiatt, hogy gyorsabb lett a Lumen, árnyékok és az RT. Valamint megérkezett a variable rate shading Nanite-ra és javítottak az instance culling sebességen is.Hubba12: Csak ha majd váltanak UE5.4-re.
[ Szerkesztve ]
vagy nem...de majd kiderul
"
"
), meg gondolom szokás szerint a streamerek is kapnak valami újabb gimmick-et ReLive-ba... ezen felül kéne számítani még bármire? 
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- BMW topik
- Tudományos Pandémia Klub
- Kínai, és egyéb olcsó órák topikja
- Kerékpárosok, bringások ide!
- Windows 11
- Aliexpress tapasztalatok
- BestBuy topik
- Milyen légkondit a lakásba?
- iRacing.com - a legélethűbb -online- autós szimulátor bajnokság
- További aktív témák...
- ASUS ROG STRIX 3080 10GB V2 White/fehér LHR
- MSI GeForce GTX 1050 Ti 4GB GDDR5 128bit videókártya
- 2025.11.04. Garancia! MSI RTX 3080 12GB GDDR6X TRIO PLUS Videokártya! BeszámítOK
- EVGA RTX 3070 8GB GDDR6 FTW3 ULTRA GAMING Eladó! 125.000.-
- ASRock Challenger D RX 6600 8GB - garancia 2024 november - eladó!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen