CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 143

[foppe-jan]

medunkt moeten we maar eens een petitie starten voor de Vega56 en 64 met alternatieve voltagecurves.. Dat je gewoon beetje kunt testen, en dan degene installeren die werkt.

[Phuncz]

Dat gaat niet gebeuren, om meerdere redenen waaronder support en logistiek. Het enige dat je kan hopen is dat ze in de toekomst "geoptimaliseerde" Vega-based kaarten uitbrengen. AMD gaat heus ook niet toegeven dat ze een grote flater begaan hebben en dat wat willekeurige enthousiasten het beter kunnen dan hen.

[Verwijderd]

De AIC-partners moeten zich gewoon richten op een goede actieve en passieve koeling: met zo weinig mogelijk lawaai zo goed mogelijk koelen zodat je een hoge boost vasthoudt (het grootste probleem voor de referentiekaart en deze Asus Strix zoals Jay het testte, het vasthouden van de boost).

[Lord_Dain]

Astennu schreef op dinsdag 26 september 2017 @ 15:41:
[...]Als refferenced kaarten hoger clocken lijkt mij niet.
Ik haal met 900mv al 1480MHz game stable. Dus hij heeft een niet al te best model. Ik kan met max fan speeds en 1150mv voltages bijna 1700 halen. (piek haalt hij 1700+ maar sustained er net iets onder) wel bensh stable maar dat haalt hij niet eens.

Hmm, ik had het nog niet geprobeerd maar ja ik haal 1125mv makkelijk 1660Mhz en het is ook nog eens retestabiel. Wel een vliegtuig onder het buro op dat moment... Alleen lijkt het niet veel te doen voor de fps in de benchmark, ik blijf dan gewoon onder 4200 punten steken in Superposition 1080p Extreme. Met bijna 30% minder verbruik haal ik die score ook al bijna.

[foppe-jan]

omgwtf: https://www.phoronix.com/...px=AMDGPU-DC-PULL-REQUEST

[aminam]

foppe-jan schreef op woensdag 27 september 2017 @ 15:10:
omgwtf: https://www.phoronix.com/...px=AMDGPU-DC-PULL-REQUEST

Wat betekend dat precies in jip en janneke taal? Gedeelde amd driver code tussen Linux en windows?

[Help!!!!]

Niet onverwacht:

GIGABYTE Has No Plans to Release a Custom Radeon RX Vega 64

[ Voor 24% gewijzigd door Help!!!! op 27-09-2017 19:42 ]

[Apoca]

AMD Radeon Software Crimson ReLive 17.9.3

http://support.amd.com/en...17.9.3-Release-Notes.aspx

[Verwijderd]

Help!!!! schreef op woensdag 27 september 2017 @ 19:42:
Niet onverwacht:

GIGABYTE Has No Plans to Release a Custom Radeon RX Vega 64

https://nl.hardware.info/...-komen-vanaf-eind-oktober

ehm tja

[Help!!!!]

^
LOL. Geloof nooit wat je in de kranten leest !

[aminam]

Verwijderd schreef op donderdag 28 september 2017 @ 12:56:
[...]


https://nl.hardware.info/...-komen-vanaf-eind-oktober

ehm tja

Ja die ongelijke chips is echt een ongelofelijke kansloze fail van amd, misschien was het nooit in hun bedoeling om een uitgebreid partner aanbad aan vega kaarten te hebben. Met dit gedoe kunnen ze de gamemarkt wel gaan vergeten op de lange termijn.

[DaniëlWW2]

Ik vraag me eigenlijk af of AMD niet in een transitie zit. Ze lijken eerst een fabriek te hebben gehad, en zijn toen overgestapt naar een tweede omdat de eerste er echt een potje van maakte en veel chips kapot gingen in het stadium van de chip en HBM2 op de interposer zetten. Als AMD overgaat naar een fabrikant, dan zou het probleem zichzelf moeten oplossen.

[flessuh]

DaniëlWW2 schreef op donderdag 28 september 2017 @ 14:48:
Ik vraag me eigenlijk af of AMD niet in een transitie zit. Ze lijken eerst een fabriek te hebben gehad, en zijn toen overgestapt naar een tweede omdat de eerste er echt een potje van maakte en veel chips kapot gingen in het stadium van de chip en HBM2 op de interposer zetten. Als AMD overgaat naar een fabrikant, dan zou het probleem zichzelf moeten oplossen.

Tja, laten we hopen dat ze hier in ieder geval van leren voor een Die-shrink en/of voor Navi

[DaniëlWW2]

flessuh schreef op donderdag 28 september 2017 @ 15:02:
[...]


Tja, laten we hopen dat ze hier in ieder geval van leren voor een Die-shrink en/of voor Navi

Ze hebben Fiji al gehad met vier HBM chips en een nog grotere die, dus ik denk niet dat het een probleem is dat ze aan zagen komen, en hadden kunnen voorkomen. Voor Navi moet het wel allemaal werken als ze modulair gaan doen ja.

[Verwijderd]

aminam schreef op donderdag 28 september 2017 @ 13:09:
[...]


Ja die ongelijke chips is echt een ongelofelijke kansloze fail van amd, misschien was het nooit in hun bedoeling om een uitgebreid partner aanbad aan vega kaarten te hebben. Met dit gedoe kunnen ze de gamemarkt wel gaan vergeten op de lange termijn.

Slechts op de korte termijn, bij Navi beginnen ze weer van voor af aan en ondertussen krijgen we nog de refresh van Navi die een iets (10%?) betere performance zal geven. Als de geruchten kloppen dat de refresh van Ryzen in februari in de winkel ligt dan zal de refresh van Vega ook wel rond die tijd uitkomen. AMD doet iets wat nieuw is, je kan niet anders verwachten dan dat er wat probleempjes zijn, zeker als 1 bedrijf wat HBM levert 'faalt' en daarom HBM van 2 bedrijven wordt gebruikt. Al hadden ze misschien dit kunnen voorkomen door strengere specificaties op te stellen maar wij kunnen niet inschatten hoe realistisch het is dat die bedrijven hieraan kunnen voldoen, om dat in te schatten hebben wij veel meer kennis nodig over het fabricageproces.

Ik leg ook een beetje de fout bij Gigabyte. Misschien zie ik het verkeerd, naar mijn mening staren ze zich te veel blind op het "we moeten een hogere klokfrequentie op de doos kunnen zetten". Is dat echt alles waar het om gaat bij AIC-kaarten of zouden veel mensen niet zo geïnteresseerd zijn in 100 MHz meer of minder en vooral zo'n kaart kopen omdat het beter de warmte afvoert en hierdoor beter de boost vasthoudt en minder lawaai maakt bij dezelfde performance? Misschien moeten ze hun focus wat verschuiven van maximale klokfrequentie naar thermals en geluidsniveau.

[Verwijderd]

aminam schreef op woensdag 27 september 2017 @ 16:59:
[...]


Wat betekend dat precies in jip en janneke taal? Gedeelde amd driver code tussen Linux en windows?

Mijn vermoeden, aangezien code vooral wordt geoptimaliseerd voor Windows (aangezien dat met afstand het meest wordt gebruikt) krijg je een betere performance onder Linux als de code die voor Linux wordt gebruikt zoveel mogelijk overeen komt met de code die voor Windows wordt gebruikt en hebben ze daarom de code voor Linux zoveel mogelijk gelijk gemaakt en is de Linux-gemeenschap hier blij mee.

Iets wat mogelijk in de toekomst meer gebruikelijk gaat worden voor Linux is dat je Windows virtueel draait onder Linux (eventueel in een container). Om dat mogelijk te maken moeten AMD, Nvidia en Intel SR-IOV toestaan. Sommige moederborden ondersteunen het (een ITX B350 van AS Rock ) maar AMD ondersteunt het helaas nog niet voor Vega terwijl het wel aangaf dit te overwegen voorat het uitkwam. Bij SR-IOV kunnen meerdere apparaten - echt of virtueel (virtuele machine) - dezelfde hardware benutten met een directe verbinding (geen extra laag software die in de weg zit) en zonder beperkingen. Wendell van Level1Techs, hij werkt als consultant met servers en grote systemen, verwacht dat we in de komende 10 jaar ook bij de gewone desktops de transitie zullen zien dat code in containers wordt uitgevoerd terwijl SR-IOV werkt en dat we hierdoor niet langer vast zitten aan een besturingssysteem omdat het dan praktisch weinig tot niets uitmaakt of dat je programma X wat voor BS Y is gecompileerd draait onder BS Y of onder een ander BS. Dit verwacht hij omdat hij dit bij meer professionele hardware-configuraties al gebeurt en omdat het om praktische redenen noodzakelijk wordt om ervoor te zorgen dat je alle software kan draaien onder alle besturingssystemen, ook bijvoorbeeld omdat je software wat werd gecompileerd voor oudere versies van hetzelfde besturingssysteem wil kunnen blijven draaien.

[ Voor 9% gewijzigd door Verwijderd op 28-09-2017 16:16 ]

[foppe-jan]

offtopic:
totale hashrate begint te dalen: https://etherscan.io/chart/hashrate

[DaniëlWW2]

In other news...


https://www.computerbase....iagramm-forza-7-1920-1080

WTF just happened?
Had iemand al eens opgemerkt dat RX Vega best aardig schijnt te zijn met DX12? Zo nee, dan dibs.

---

edit: Ik vraag me toch af hoe dit kan. Ik vermoed eigenlijk dat de GTX1080Ti hier tegen een drawcall bottleneck aanloopt, aangezien de resolutie zo weinig effect heeft op de prestaties. Bij 1440P is de GTX1080Ti de RFX Vega 56 net voorbij, en bij 4K ook de RX Vega 64.

Ondertussen lijkt RX Vega absoluut geen enkel probleem te hebben om alle CU's goed te belasten. Dit roept bij mij wel een belangrijke vraag op. Is RX Vega wel ROP bottlenecked zoals we eigenlijk vermoeden? Zou het niet kunnen dat het probleem draw calls is? Dit is een DX12 titel, de CPU is een 6850K, en er draait 8xMSAA wat ook behoorlijk zwaar op de ROP's lijkt te zijn bij DX11 titels. Daar zakken de prestaties nog wel eens in, hier lijkt het niks wezenlijks te doen. Ook is Vega flink sneller dan Fiji, en Fiji zakt ook keihard weg bij 4K, bij wat een vram bottleneck lijkt. Als laatste blijft RX Vega ook zeer goed in minimale framerates, toch belangrijk oor een racing game.

[ Voor 63% gewijzigd door DaniëlWW2 op 29-09-2017 18:24 ]

[foppe-jan]

En dat allemaal op 8x msaa? tjonge. Maar apart hoe het 'normaliseert' in 1440 en 2160p.

[Dennism]

DaniëlWW2 schreef op vrijdag 29 september 2017 @ 17:22:
In other news...

Was er ook niet ook een ander racespel waar Vega zeer vreemd hoge FPS haalde t.o.v. Nvidia? Meen ik iig ergens in wat reviews voorbij hebben zien komen (zit totaal niet in dat genre).

[ Voor 5% gewijzigd door Dennism op 29-09-2017 23:52 ]

[DaniëlWW2]

Dennism schreef op vrijdag 29 september 2017 @ 23:49:
[...]


Was er ook niet ook een ander racespel waar Vega zeer vreemd hoge FPS haalde t.o.v. Nvidia? Meen ik iig ergens in wat reviews voorbij hebben zien komen (zit totaal niet in dat genre).

Dat was Dirt 4 met CSAA in plaats van MSAA. MSAA was uitermate zwaar voor Vega, en dat leek op ROP's te wijzen. Dit is heel wat anders dan ROP's, en lijkt veel meer op draw calls te wijzen als het probleem van RX Vega.

[enchion]

DaniëlWW2 schreef op zaterdag 30 september 2017 @ 08:12:
[...]
Dat was Dirt 4 met CSAA in plaats van MSAA. MSAA was uitermate zwaar voor Vega, en dat leek op ROP's te wijzen. Dit is heel wat anders dan ROP's, en lijkt veel meer op draw calls te wijzen als het probleem van RX Vega.

Maar drawcalls heeft toch alles te maken met hoe efficient/snel de CPU de taken naar de GPU krijgt.

Maw dan hadden ze deze test eigenlijk ook met andere CPU`s moeten testen, andere Intel`s en ook AMD cpu`s.

[DaniëlWW2]

enchion schreef op zaterdag 30 september 2017 @ 14:35:
[...]


Maar drawcalls heeft toch alles te maken met hoe efficient/snel de CPU de taken naar de GPU krijgt.

Maw dan hadden ze deze test eigenlijk ook met andere CPU`s moeten testen, andere Intel`s en ook AMD cpu`s.

Oke, ik heb hier een beetje te lang over gedaan. Te veel opgezocht en damn you internet met je afleiding.

Niet noodzakelijkerwijs. Het is een theorie van mij, maar wel eentje die het zou verklaren wat we zien.
Dit is een DX12 titel, en het is Forza. Dat is een MS game en MS gebruikt DX12 op hun XBONE, met AMD hardware. Ik maak er echt geen illusies over, het zal gewoon een port zijn waar ze wat optimalisaties door hebben gevoerd voor AMD hardware omdat het vrij makkelijk was om te doen. Het is een beetje best case scenario maar toch opvallend en leerzaam.

Het grote verschil tussen DX12 en Vulkan aan de ene kant, en DX11 en lager aan de andere kant is hoe de hardware aangesproken moet worden door de developers. Bij DX11 is de toegang tot de hardware minder diepgaand, en moet de driver van de GPU fabrikant veel meer taken verrichten tussen de API, die instructies van de game doorgeeft aan de driver, en vanuit de driver naar de hardware. Dat is een tijdrovend, duur en inefficiënt proces. Tijdrovend en duur voor de GPU fabrikant omdat die elke game moeten optimaliseren. Inefficiënt omdat je tegen limieten van dit model aanloopt, en omdat game developers, eigenlijk publishers een excuus krijgen om niks te doen aan optimalisaties. Het is aan de GPU fabrikanten om vaak zeer brakke code enigszins werkbaar te maken. Nvidia gooit hier bakken met geld tegenaan, en is hier vaak wat beter in dan AMD. Nvidia heeft haar GPU achitectuur ook zo opgezet dat ze dit makkelijker kunnen doen. Het nadeel is dat Nvidia eens in de zoveel tijd een absolute baggerdriver uitbrengt, en weer eens wat GPU's sloopt.

AMD heeft het geld niet voor een groot driverteam, en echte baggertitels draaien dan ook niet op AMD kaarten. Maakt mij niet uit want ik vermijd die toch, maar voor velen is het wel minder, en het helpt AMD hun reputatie niet. Dan is er nog Gameworks waar ik echt geen zin in heb hier alweer over te beginnen. Verder zijn AMD kaarten vaker iets meer afhankelijk van hun grotere theoretische rekenkracht om redelijk bij blijven met Nvidia kaarten.

Bij DX12/Vulkan verandert de situatie volledig. Een driver bij DX12 is een stukje software tussen de API en de hardware die gegevens doorzet. Dat is het ook, geen optimalisaties, niks. Hiermee is de toegang tot de hardware "low level" geworden, vandaar ook low level API. Het verschil tussen AMD en Nvidia hardware is hier behoorlijk.

Nvidia ondersteunt de fundamentele implementaties van DX12/Vulkan botweg niet. Ja, je kan games met DX12/Vulkan draaien op Nvidia hardware, maar in de regel is DX11 beter. Of het nu Fermi is waar Nvidia doodleuk DX12 "enabled" heeft, zonder enige feature van DX12 zelf te activeren, tot de matige ondersteuning van Maxwell/Pascall. Het probleem is dat Nvidia geen hardware scheduler meer gebruikt op hun chips, en scheduling softwarematig gebeurd. Er is dus geen low level acces op deze hardware. Het is allemaal nog steeds high level API, maar nu met wat DX12 features. Ook distribueert de driver, draw calls naar de CPU. Dit is een slim, maar complex trucje van Nvidia. Een API zoals DX11 is in principe gelimiteerd tot een CPU core voor haar draw calls. Draai maar eens een willekeurige game met MSI afterburner de statistieken aan. Altijd een core die net even wat meer load trekt. Nvidia heeft hier met software een weg omheen gevonden, waardoor een klein deel van de berekeningen op andere cores uitgerekend kunnen worden. Dat levert extra draw calls op, ontlast de main CPU core en zorgt in met name slecht geoptimaliseerde titels voor wat prestatiewinst. Het werkt ook voor DX12/Vulkan.

https://www.anandtech.com...ulkan-3dmark-api-overhead

Nu AMD. Elke GCN chip ondersteunt low level acces, en Vega ondersteunt eindelijk de gehele DX12 API, met alle features van de API. Uit mijn hoofd staat DX12 een maximum van zes CPU cores toe voor draw calls, en Vulkan was dacht ik nog meer. Een AMD GPU kan dit gewoon aanspreken als het moet. De verschillen zijn enorm.

Waarom? Nou omdat het sterk op lijkt dat AMD kaarten veel, en veel meer draw calls nodig hebben om optimaal te presteren dan Nvidia. Een enkele core kan die niet leveren, zelfs niet als dit een 7700K @5GHz is. Er zijn nu zoveel games geweest waar de verhouding theoretische FP32 prestaties/ingame prestaties veel meer gelijk werden getrokken bij DX12/Vulkan. Dat zijn dus de games waar een RX580, een GTX1060 ruim verslaat, en in de buurt komt van de GTX1070.

Hier zie je het weer gebeuren. Een GTX1080Ti heeft ongeveer 11,3TFLOPs FP32, waar een RX Vega 64 over 12,5TFLOPs beschikt. Toch loopt de RX Vega 64, en dit keer zelfs meer dan het theoretische verschil bij 1080P. 1440P is ongeveer wat je op theoretische basis zou mogen verwachten, en 4K begrijp ik niet helemaal.

[Nature]

Ik heb gelezen dat Forza 7 maar een core gebruikt en dat Nvidia daar meer last van heeft dan AMD.

[Sp3ci3s8472]

Nature schreef op zaterdag 30 september 2017 @ 22:48:
Ik heb gelezen dat Forza 7 maar een core gebruikt en dat Nvidia daar meer last van heeft dan AMD.

Een core voor het maken van draw calls? Dan is Nvidia inderdaad in het nadeel, ze hebben meer driver overhead dan AMD, omdat ze zoals DaniëlWW2 zegt ze proberen meer cores in DX11 in te zetten voor het maken draw calls. Als ze meer cores kunnen gebruiken dan valt dat nadeel weg. Dit is tenminste het geval in DX11, aangezien Forza 7 DX12 is lijkt me dat dit niet speelt.

[ Voor 9% gewijzigd door Sp3ci3s8472 op 01-10-2017 03:20 ]

[DaniëlWW2]

Sp3ci3s8472 schreef op zondag 1 oktober 2017 @ 03:18:
[...]


Een core voor het maken van draw calls? Dan is Nvidia inderdaad in het nadeel, ze hebben meer driver overhead dan AMD, omdat ze zoals DaniëlWW2 zegt ze proberen meer cores in DX11 in te zetten voor het maken draw calls. Als ze meer cores kunnen gebruiken dan valt dat nadeel weg. Dit is tenminste het geval in DX11, aangezien Forza 7 DX12 is lijkt me dat dit niet speelt.

Nvidia kan ook meer draw calls ophalen in DX12 hoor. Enkele tientallen miljoenen meer.
Het verschil is toegang tot de hardware zelf. Bij Nvidia blijft het meer een emulatie modus, maar bij DX12 zonder specifieke driver optimalisaties die ze bij DX11 wel kunnen doorvoeren. Dat lijkt er behoorlijk in te hakken.

Wederom linkje.
https://www.anandtech.com...ulkan-3dmark-api-overhead

Bij DX11 heeft een GTX1060 gewoon een ruim voordeel op een RX480/580. Bij DX12/Vulkan heeft de GTX1060 een licht voordeel, wat niet bijzonder relevant meer is, terwijl bij DX12 de RX480 beduidend beter is.

Ik zou graag mijn RX Vega eens testen om te zien wat die kan, maar deze benchmark is alleen in de betaalversie van 3D Mark.

[Sp3ci3s8472]

DaniëlWW2 schreef op zondag 1 oktober 2017 @ 12:31:
[...]


Nvidia kan ook meer draw calls ophalen in DX12 hoor. Enkele tientallen miljoenen meer.
Het verschil is toegang tot de hardware zelf. Bij Nvidia blijft het meer een emulatie modus, maar bij DX12 zonder specifieke driver optimalisaties die ze bij DX11 wel kunnen doorvoeren. Dat lijkt er behoorlijk in te hakken.

Wederom linkje.
https://www.anandtech.com...ulkan-3dmark-api-overhead

Bij DX11 heeft een GTX1060 gewoon een ruim voordeel op een RX480/580. Bij DX12/Vulkan heeft de GTX1060 een licht voordeel, wat niet bijzonder relevant meer is, terwijl bij DX12 de RX480 beduidend beter is.

Ik zou graag mijn RX Vega eens testen om te zien wat die kan, maar deze benchmark is alleen in de betaalversie van 3D Mark.

Met miljoenen meer kijk je wel naar de GTX 1080Ti, dat kan je niet redelijk vergelijken met de RX 480 . Vega zal ongetwijfeld hoger scoren daar dan de RX 480.

Ik zit 3dmark nu te downloaden over mijn trage verbinding.... Zal even testen hoe een Vega64 scored met de api overhead test aangezien ik geen review met die info kon vinden.
Let wel dat mijn Vega maar op 1400Mhz loopt .

[DaniëlWW2]

Sp3ci3s8472 schreef op zondag 1 oktober 2017 @ 14:15:
[...]


Met miljoenen meer kijk je wel naar de GTX 1080Ti, dat kan je niet redelijk vergelijken met de RX 480 . Vega zal ongetwijfeld hoger scoren daar dan de RX 480.

Nee, jij zit niet goed te kijken hoor.

Ik zit 3dmark nu te downloaden over mijn trage verbinding.... Zal even testen hoe een Vega64 scored met de api overhead test aangezien ik geen review met die info kon vinden.
Let wel dat mijn Vega maar op 1400Mhz loopt .

Die van mij op 1430MHz dus.

[Sp3ci3s8472]

DaniëlWW2 schreef op zondag 1 oktober 2017 @ 14:33:
[...]

Nee, jij zit niet goed te kijken hoor.

[...]

Die van mij op 1430MHz dus.

Ik kijk nog steeds goed, Vulkan heeft de RX 480 inderdaad 2 miljoen minder. Bij DX12 6 miljoen, dat is inderdaad meer.

Maar dan nog ga je dit verschil nooit merken in games.

Je moet blijkbaar 3dmark kopen om die overhead test te draaien.... laat maar zitten. Had graag de GTX 1080 en Vega64 als resultaat willen zien, maar die worden nergens in een review met deze test getest.

Eindelijk, google is echt bagger aan het worden. Verbetering in DX12 ten opzichte van de RX 480, maar dat kan ook driver gerelateerd zijn, verder niet echt sneller:

[ Voor 18% gewijzigd door Sp3ci3s8472 op 01-10-2017 18:00 ]

[DaniëlWW2]

Sp3ci3s8472 schreef op zondag 1 oktober 2017 @ 17:54:
[...]


Ik kijk nog steeds goed, Vulkan heeft de RX 480 inderdaad 2 miljoen minder. Bij DX12 6 miljoen, dat is inderdaad meer.

Maar dan nog ga je dit verschil nooit merken in games.

Je moet blijkbaar 3dmark kopen om die overhead test te draaien.... laat maar zitten. Had graag de GTX 1080 en Vega64 als resultaat willen zien, maar die worden nergens in een review met deze test getest.

Dat had ik ook allemaal al gezegd hoor.

Eindelijk, google is echt bagger aan het worden. Verbetering in DX12 ten opzichte van de RX 480, maar dat kan ook driver gerelateerd zijn, verder niet echt sneller:
[afbeelding]

Ah er bestaat dus toch een benchmark. Weten we in ieder geval dat 20+ miljoen draw calls een puur theoretische exercitie is.

[Sp3ci3s8472]

DaniëlWW2 schreef op zondag 1 oktober 2017 @ 18:05:
[...]

Dat had ik ook allemaal al gezegd hoor.

[...]


Ah er bestaat dus toch een benchmark. Weten we in ieder geval dat 20+ miljoen draw calls een puur theoretische exercitie is.

Ben nog niet helemaal wakker vandaag .

[Verwijderd]

DaniëlWW2 schreef op zondag 1 oktober 2017 @ 12:31:
Bij DX11 heeft een GTX1060 gewoon een ruim voordeel op een RX480/580.

Ja en nee. Er zijn genoeg spellen die DX11 gebruiken waarbij de 580 een hogere FPS haalt. Dat kan natuurlijk met optimalisatie van het spel en de drivers te maken hebben maar ik zie een andere mogelijke oorzaak: niet alle spellen geven een even hoge single core CPU-load. De laatste tijd vallen twee dingen mij vooral op bij alle AMD/Nvidia benchmarks:
- AMD presteert beter bij hogere resoluties. Dit lijkt zowel voor Ryzen als voor de GPU's te gelden, ik heb geen idee wat het verschil bij de CPU veroorzaakt maar ook bij de CPU zie je dit bij een meerdere spellen en andersom zelden.
- Vooral bij die spellen die een hoge single core CPU load geven, hetzij DX11 hetzij DX12, zie je de AMD-kaarten onderpresteren.
We mogen hiervoor wellicht denken aan wat Nerdtechgasm uitlegde: de DX11-drivers van Nvidia die softwarematig de load verdelen over de kernen vs. de DX11-drivers van AMD die hardwarematig alle load die via DX11 wordt geregeld bij die ene arme CPU-kern terecht komt.

Nature schreef op zaterdag 30 september 2017 @ 22:48:
Ik heb gelezen dat Forza 7 maar een core gebruikt en dat Nvidia daar meer last van heeft dan AMD.

Epic LOL
Doordat het nog slechter geoptimaliseerd is dan de meeste spellen verandert het voordeel van Nvidia en het nadeel van AMD in het nadeel van Nvidia en het voordeel van Nvidia. Species geeft hier precies dezelfde verklaring als die Daniël en ik zouden geven. Voor zo ver wij weten verdeelt Nvidia via de drivers - met een handige hack - de load over de CPU-kernen maar dit gaat natuurlijk wel ten koste van CPU-overhead die AMD niet heeft. Bij Nvidia ligt de totale CPU-load dus hoger maar is die beter verdeeld over de kernen, tenzij slechts 1 kern wordt gebruikt, dan valt het voordeel weg.

Sp3ci3s8472 schreef op zondag 1 oktober 2017 @ 03:18:
[...]


Een core voor het maken van draw calls? Dan is Nvidia inderdaad in het nadeel, ze hebben meer driver overhead dan AMD, omdat ze zoals DaniëlWW2 zegt ze proberen meer cores in DX11 in te zetten voor het maken draw calls. Als ze meer cores kunnen gebruiken dan valt dat nadeel weg. Dit is tenminste het geval in DX11, aangezien Forza 7 DX12 is lijkt me dat dit niet speelt.

Maar goed, het is natuurlijk tragisch dat dit in 2017 nog gebeurt want zowel met Nvidia-kaarten als met AMD-kaarten haal je hierdoor bij lange na niet alles uit het spel en helaas lijkt dit een chronisch probleem te zijn bij MS, denk aan de slechte optimalisatie van Quantum Break en tal van spellen waarbij je in eerste instantie niet eens VSync kon uitschakelen en meer dan 60 FPS kon krijgen. Zou MS denken dat de spellen toch wel verkoopt of zou MS juist niet willen dat de spellen al te veel beter draaien op de PC omdat ze bang zijn dat minder mensen die console kopen? Offtopic voor hier maar interessant.
MS geeft echter wel leuke 2D-spellen uit met Ori and the Blind Forest en nu Cuphead. Kijk naar dat laatste spel als je het nog niet kent, het zal vast vroeg of laat ook buiten de MS store verkrijgbaar gaan zijn.

[ Voor 51% gewijzigd door Verwijderd op 01-10-2017 22:51 ]

[Verwijderd]

-

[ Voor 99% gewijzigd door Verwijderd op 01-10-2017 22:45 ]

[DaniëlWW2]

Ondertussen is die review van Computerbase.de uitgebreid.
Nou, de RX Vega 64 loopt nog sneller met Ryzen of Kaby Lake dan met de 6850K. De 1800X zit zelfs bijna op 7700K niveau. Qua minima wint Ryzen ruim. De game is dus behoorlijk multithreaded, en heeft geen last van onderpresteren met Ryzen, verre van. Hyperthreading lijkt ook niks te doen, extra fysieke cores doet zeker wel wat.

https://www.computerbase....amd_bei_frametimes_update

[Sp3ci3s8472]

DaniëlWW2 schreef op dinsdag 3 oktober 2017 @ 21:44:
Ondertussen is die review van Computerbase.de uitgebreid.
Nou, de RX Vega 64 loopt nog sneller met Ryzen of Kaby Lake dan met de 6850K. De 1800X zit zelfs bijna op 7700K niveau. Qua minima wint Ryzen ruim. De game is dus behoorlijk multithreaded, en heeft geen last van onderpresteren met Ryzen, verre van. Hyperthreading lijkt ook niks te doen, extra fysieke cores doet zeker wel wat.

https://www.computerbase....amd_bei_frametimes_update

Mensen die daarom zeggen dat meer cores weinig toevoegen zitten met nieuwere games fout (en met een aantal oudere games ook). Je hebt weinig aan hoge max fps en avg fps (wat Intel vooral heeft), ik zie liever hogere minima, minder last van stuttering.
Hyperthreading van Intel is sowieso nog steeds subpar, dat van AMD lijkt beter te presteren.

[sdk1985]

@Sp3ci3s8472 Je linkt nu twee dingen aan elkaar waarbij de ene statement niet klopt en de andere wel. Inderdaad heb je liever een stabiele framerate en goede frametimes. Echter die moderne games waar je ineens wel iets hebt aan extra cores zijn maar niet te vinden. De zojuist gelinkte Forza onderschrijft dat toch?

Bij AMD 97,5 fps voor 4 cores naar 120 fps voor 6 cores genoteerd als 123%. Je verwacht 150% en je krijgt 123%, dus niet top. De 8 core gaat naar 127 fps wat staat genoteerd als 130% (tov de 4 core). Die extra 2 cores voegen dus slechts 7% relatief toe. Wat net zo goed verklaard kan worden door het clock verschil. Immers de 1800X heeft een veel hogere base clock dan de 1600X. Hetzelfde geldt eigenlijk ook voor de frame times (115>125). Wil je iets kunnen zeggen over de multithreading dan moet je die test uitvoeren met een 1800X en dan steeds een extra core uitschakelen. Als ik zelf een 8 core had dan zou ik het zo doen.

Dit alles wordt bevestigd door de teleurstellende resultaten van de 6850K waarbij weer eens blijkt dat een beetje meer mhz het wint van twee extra cores. Ook in Forza. Ik moet de eerste game die een beetje normaal schaalt naar 6, laat staan 8, cores nog tegenkomen.

Begrijp met niet verkeerd het gaat tegenwoordig steeds beter maar der is snel sprake van een perceptie probleem. Pak maar eens een oudere game waarvan je weet dat je aan 2 cores genoeg hebt en halveer dan de Mhz van je cpu. Ineens gaat die game wel "schalen" naar je andere cores. Echter je haalt natuurlijk lagere fps. Heb jij dus een zwakke multi core cpu dan lijkt het dat al je games schalen. Alleen met een krachtigere processor kun je zien hoe de vork echt in de steel zit.

Wat dat betreft komt Intel over twee dagen met de 5.1 GHz 6 cores in de vorm van de i5 8600K. Als je dat gekoeld krijgt dan heb je zowel de vereiste single threaded performance als 2 extra cores. Het beste van twee werelden. Kunnen we ook meteen goed zien hoe goed games anno 2017 schalen naar 6 cores. (Nou ja, er staan al wat plaatjes in het Intel topic. De 8700K ziet er stock erg goed uit).

[ Voor 96% gewijzigd door sdk1985 op 04-10-2017 03:09 ]

[-The_Mask-]

Er zijn juist best wel veel games welke duidelijk beter schalen. Er zijn zelfs genoeg games die met vier cores en threads niet genoeg hebben. Er zijn echter nog veel meer reviewsites die dit niet goed testen. De belasting in een game op de CPU is niet overal hetzelfde, sommige momenten zijn duidelijk zwaarder dan anderen. Vooral multiplayers kunnen erg zwaar voor de CPU zijn.

Er zijn echter genoeg mensen die het kunnen bevestigen in de praktijk. Dus die gewoon games uren spelen in plaats van een benchmark van enkele seconden. Dat er genoeg games zijn die schalen.

Dat betekend echter niet dat als je van 12 threads naar 16 threads gaat je de perfecte schaling krijgt, maar kan wel betekenen dat je winst ziet zoals hier. Ryzen 5 1600X en Ryzen 7 1800X hebben dezelfde frequentie in tegenstelling in wat jij beweert. Als er al een voordeel in frequenties is dan is het de 1600X omdat beide max 95W mogen verbruiken, maar de 1600X twee cores minder heeft die stroom verbruiken.

Waarom je geen perfecte schaling hebt is omdat je ook te maken hebt met andere onderdelen. Kan ook zoiets simpel als een videokaart bottleneck zijn.

[DaniëlWW2]

Sp3ci3s8472 schreef op woensdag 4 oktober 2017 @ 00:18:
[...]


Mensen die daarom zeggen dat meer cores weinig toevoegen zitten met nieuwere games fout (en met een aantal oudere games ook). Je hebt weinig aan hoge max fps en avg fps (wat Intel vooral heeft), ik zie liever hogere minima, minder last van stuttering.
Hyperthreading van Intel is sowieso nog steeds subpar, dat van AMD lijkt beter te presteren.

Allemaal eens. Ik ga er ook nauwelijks meer op in omdat. Dit het "minder cores argument" in de regel ook wordt verbonden met Intel. Nu Coffee Lake eraan zit te komen zijn meer cores opeens wel relevant geworden. Dan wel zes, en niet acht. Het zal wel. Er zijn nog meer dan genoeg voorbeelden voorbij gekomen die voordelen al jaren laten zien.

[Help!!!!]

sdk1985 schreef op woensdag 4 oktober 2017 @ 02:37:

Wat dat betreft komt Intel over twee dagen met de 5.1 GHz 6 cores in de vorm van de i5 8600K.

Intel komt met een 8600K wat een 3.6 Base / 4.3 Turbo CPU is. Die 4.3 is volgensmij ook geen all core turbo. Dus niks geen 5.1 (all core turbo) CPU.

Je schept het beeld alsof dat voor iedereen makkelijk te halen is en dat lijkt me nogal een premature bewering voor een chip die nog niet eens uit is.

Ik twijfel er overigens verder niet aan dat de nieuwe intel chips goed gaan presteren.

[enchion]

Daarom wil ik ook graag bv flightsims en physics based games zien bij de benchmarks.

Flightsims schalen vaak een stuk beter met meer cores, en sommige physics based games ook.

Al die zogeheten "triple A" games zijn vaak precies de type games die dat juist niet doen of waarbij het eigenlijk te moeilijk is om te doen.
Maar dat zijn eigenlijk altijd uitsluitend de type games die getest worden.

[Xentor]

DaniëlWW2 schreef op zondag 1 oktober 2017 @ 12:31:
[...]

Ik zou graag mijn RX Vega eens testen om te zien wat die kan, maar deze benchmark is alleen in de betaalversie van 3D Mark.

https://www.3dmark.com/aot/232726

Alstu .

Dit is trouwens een VEGA56 met 64 Bios die rond 1550mhz draait met 1100mhz mem.

[DaniëlWW2]

Xentor schreef op woensdag 4 oktober 2017 @ 12:38:
[...]


https://www.3dmark.com/aot/232726

Alstu .

Dit is trouwens een VEGA56 met 64 Bios die rond 1550mhz draait met 1100mhz mem.

Ah, nog eentje. Het is nog steeds opvallend minder dan wat Nvidia lijkt te bereiken, maar voor Forza 7 lijkt dat weinig uit te maken.

enchion schreef op woensdag 4 oktober 2017 @ 11:47:
Daarom wil ik ook graag bv flightsims en physics based games zien bij de benchmarks.

Flightsims schalen vaak een stuk beter met meer cores, en sommige physics based games ook.

Al die zogeheten "triple A" games zijn vaak precies de type games die dat juist niet doen of waarbij het eigenlijk te moeilijk is om te doen.
Maar dat zijn eigenlijk altijd uitsluitend de type games die getest worden.

Clickbait, clickbait, en clickbait.
Maar ik zou ook wel eens wat meer diversiteit willen zien, zeker ook voor GPU's. Eens in de zoveel tijd komt er weer eens een game langs die echt voor geen meter draait op Nvidia hardware, totdat Nvidia de boel enorm verbeterd met een nieuwe driver. Dit terwijl AMD aardig loopt out of the box. De CoD WW2 Beta lijkt daar ook een voorbeeld van te zijn geweest. Overigens draaide die waardeloos op quadcore CPU's.

[Verwijderd]

Help!!!! schreef op woensdag 4 oktober 2017 @ 09:51:
[...]


Intel komt met een 8600K wat een 3.6 Base / 4.3 Turbo CPU is. Die 4.3 is volgensmij ook geen all core turbo. Dus niks geen 5.1 (all core turbo) CPU.

Je schept het beeld alsof dat voor iedereen makkelijk te halen is en dat lijkt me nogal een premature bewering voor een chip die nog niet eens uit is.

Ik twijfel er overigens verder niet aan dat de nieuwe intel chips goed gaan presteren.

@sdk1985
Je gaat mogen delidden als je ook maar in de buurt wil komen van 5,1 GHz en het is twijfelachtig dat 5,1 GHz haalbaar is voor alle samples als je delidt. Dat neemt niet weg dat de 8600k een goede tegenzet is van Intel, een die rijkelijk laat komt en die Intel ook eerder had kunnen doen door de hexacore van Kabylake in prijs te verlagen, ongeacht of dat het wel of niet mogelijk is om die te laten draaien op een Z270 moederbord (wij weten niet of dat het enkel om een softwarelock gaat of dat er ook echt hardwarematige beperkingen zijn om die te laten draaien op zo'n moederbord). Ongetwijfeld zal AMD dit counteren met een prijsverlaging van de Ryzen-CPU's in het middensegment (1600-1700 en als gevolg hiervan waarschijnlijk ook onder de 1600 om een prijsverschil te houden) en zal AMD zo snel mogelijk met de '12 nm'-variant komen, naar verluidt in februari. Goed nieuws voor iedereen die een nieuwe CPU wil kopen.

[Foritain]

DaniëlWW2 schreef op woensdag 4 oktober 2017 @ 13:13:
Clickbait, clickbait, en clickbait.

Ieder zn ding, maar voor mijzelf telt maar één ding: het gemak. Als ze nu gewoon benches inbouwen in hun games (of reviewers laten weten dat dat het geval is), dan pakken reviewers het vanzelf op. Zeker met zo veel directe concurrenten is het maken van opnames 1) minder eerlijk 2) meer moeite.

Interessante content sure, maar het gaat altijd ten koste van iets.

Overigens ook gratiz reclame natuurlijk als je game een bench heeft.

[sdk1985]

Help!!!! schreef op woensdag 4 oktober 2017 @ 09:51:
[...]


Intel komt met een 8600K wat een 3.6 Base / 4.3 Turbo CPU is. Die 4.3 is volgensmij ook geen all core turbo. Dus niks geen 5.1 (all core turbo) CPU.

Je schept het beeld alsof dat voor iedereen makkelijk te halen is en dat lijkt me nogal een premature bewering voor een chip die nog niet eens uit is.

Ik twijfel er overigens verder niet aan dat de nieuwe intel chips goed gaan presteren.

Wellicht iets te voorbarig. Met een luchtkoeler is het gehaald: sdk1985 in "Intel Nieuwsdiscussietopic"

Maar goed 4.5 Ghz op alle cores is wat dat betreft ook voldoende om het nadeel van de lagere standaard clocks te compenseren. Gezien de 5.1 Ghz bestaat er bij mij geen twijfel dat dit makkelijk haalbaar is.

[DaniëlWW2]

Astennu schreef op woensdag 4 oktober 2017 @ 15:55:
Tja de vraag is wat die drawcalls afhandelt. Driver + cpu ? Of heeft de gpu daar ook nog een groot aandeel in? Ben daar op technisch vlak niet van op de hoogte hoe dat precies werkt.

Aangezien ik toch veel te veel tijd op handen heb.

Eerst even de basis wat het precies is.
https://www.pcper.com/rev...w-Call-and-What-Can-It-Do

Draw calls zijn instructies die worden gegeven aan GPU's om primitives te creëren, rasterisation en dan omzetten in pixels op je scherm. Kennelijk vraag een frame van een beetje game iets van 10.000 a 20.000 draw calls. Maal het aantal frames en dan zit je al snel over de miljoen als je een beetje framerate wil hebben.

Met dank aan @Xentor voor de RX Vega draw call test weten we nu wat een RX Vega ongeveer kan trekken.
https://www.3dmark.com/aot/232726

Anandtech geeft ons wat meer inzicht voor meer chips.
https://www.anandtech.com...ulkan-3dmark-api-overhead

Het moet toch opvallen dat een GTX1060 een ruim voordeel heeft, op zowel een RX480 als RX Vega 56. De RX Vega haalt wat meer, en de GTX1080Ti zit op hetzelfde niveau als de GTX1060. Dat lijkt met DX11 een limiet voor de Pascal architectuur, gezien het enorme verschil in theoretische rekenkracht tussen GP102 en GP106. De RX480 blijft steken op 1,4 miljoen, een miljoen minder. RX Vega is iets beter, daar lijken dus verbeteringen te zijn aangebracht ten opzichte van Polaris.

Nu kan je theoretische rekensommetjes los laten op waar je tegen een limiet aanloopt, en de GPU gewoon geen extra frames meer kan produceren. Gezien de vergelijkbaarheid van de GTX1060 en RX480 in prestaties, zal de 1,4 miljoen geen bijzonder zware limitering zijn voor de RX480. De GTX1080Ti en de RX Vega, daar lijkt wel wat te spelen.

Even snel ter demonstratie wat sommetjes:
10.000 calls x 140 frames = 1.400.000, de limiet dus voor de RX480.
15.000 calls x 93,33 frames = 1.400.000, de limiet dus voor de RX480.
20.000 calls x 70 frames = 1.400.000, de limiet dus voor de RX480.

Dus die 10.000 a 20.000 per frame die werd gesteld in het artikel van PCPerspective klopt zo wel aardig. Vrij typische, maximale prestaties voor 1080P. Bij hogere resoluties loop je natuurlijk nooit tegen deze limiet aan, want de GPU zelf is al gelimiteerd. Voor de GTX1060 betekent dit dat deze eigenlijk nooit tegen een limitering aan zal lopen. Een GTX1080Ti dan, waar loopt die tegen een limiet?

150fps = 2.400.000 : 16.000 calls
100fps = 2.400.000 : 24:000 calls

Wederom redelijk in de lijn der verwachtingen van wat een GTX1080Ti kan pushen qua frames bij 1080P. Tenzij een game brak is gecodeerd met onnodig complexe geometrie zie ik een RX480 dus niet zo snel tegen een forse limiet aanlopen, zoals Fiji deed. Ook zie ik een GTX1060 geen groot voordeel hebben uit het theoretische maximum gezien de beperkingen van die chip. Wat eventueel wel kan zijn enorme drawcall loads per frame met een game die gewoon brak is gecodeerd. Daar kan Nvidia voordelen halen. Insert Nvidia Gameworks. Ja, dat moest natuurlijk even. Kon het niet laten.

Nog een theoretische exercitie dan. Wat is de limiet voor een RX Vega om nog steeds 100 fps te halen?
Uitgaande van 1.500.000 draw calls per seconde kom je dan op maximaal 15.000 draw calls per frame uit. Maar wat als je nu 20.000 calls per frame hebt? Blijven er maximaal 75 frames over per seconde. Een GTX1080 zou op theoretische basis hier alsnog 120 frames moeten kunnen halen voordat deze aan een limiet zit, want 2.400.000 draw calls. Dat gebeurd niet omdat de RX Vega puur op hardware een stuk sneller is. Een GTX1080Ti daarentegen...

Het verschil is 45 frames op 120, dus 37,5%. Hoeveel sneller is een GTX1080Ti ongeveer? 30% toch of iets meer? Ah, nu word het dus opeens zeer interesant.

---

Tot zover dan DX11. DX12 en Vulkan is draw calls for days. Theoretische limieten van meer dan duizend frames, vrij irrelevante piek prestaties dus, tenzij je echt bizar complexe primitives wil gaan uitrekenen.

Hoewel, voor AMD is het wel interesant. Een RX480 staat bekend toch een aardige sprong in prestaties met zich mee te brengen bij DX12, in titels met een DX11 en DX12 implementatie. Ook staan AMD kaarten allang bekend hun prestaties beter vast te houden bij hogere resoluties. Dat duidt op een specifieke bottleneck bij lagere resoluties. Een bottleneck op het maximaal aantal te produceren frames, die alleen optreed bij DX11 titels, niet DX12 of Vulkan. Een draw calls bottleneck is dan een behoorlijk sterke kandidaat als het probleem.

RX Vega zit er gelukkig iets luxer in de draw calls bij dan Polaris, wat de DX11 prestaties ten goede komt. Een "super polaris" was dan waarschijnlijk ook een mislukking geweest omdat deze ook tegen een limiet was aangelopen. In de meeste titels zitten beide RX Vega's zo rond de GTX1080 qua prestaties. Bij 1080P, met de bijbehorende hogere framerates is de GTX1080 nog wel eens wat sneller, bij 1440P normaliseert het zich meestal, of komt de RX Vega al nipt voor, en bij 4K wint Vega meestal. Dat patroon is vrij herkenbaar en bekend. Draw calls zou het best wel eens kunnen verklaren waarom dit gebeurd.

Bij DX12/Vulkan is er ook een merkbaar verschil op te merken tussen de RX Vega 56 en 64, wat bij DX11 vaak maar minimaal is. Dat geeft verdere steun aan mijn theorie dat het probleem de draw calls zijn. Een RX Vega 64 laat systematisch zien in staat te zijn meer primitives te berekenen, en dus meer frames te produceren, als draw calls geen limitering vormen. Dat viel ook al op bij Fiji, en nu wederom.

---

Dan Forza 7. RX Vega is daar gewoon helemaal los en lijkt vrij optimaal te presteren met dank aan DX12 die geen draw call limitering meer oplegt aan RX Vega. Ook gaat de RX Vega 64 een stuk sneller dan de RX Vega 56. Waarom de rollen worden omgedraaid bij hogere resoluties met de GTX1080Ti snap ik alleen (nog) niet. Dat doet alleen geen afbreuk aan mijn theorievorming, die gebaseerd is op rationeel denkwerk, en in de regel correspondeert met de realiteit. Hebben we ook voldaan aan het basisprincipe van moderne wetenschap.

[Verwijderd]

Foritain schreef op woensdag 4 oktober 2017 @ 16:06:
[...]


Ieder zn ding, maar voor mijzelf telt maar één ding: het gemak. Als ze nu gewoon benches inbouwen in hun games (of reviewers laten weten dat dat het geval is), dan pakken reviewers het vanzelf op. Zeker met zo veel directe concurrenten is het maken van opnames 1) minder eerlijk 2) meer moeite.

Voor mij telt maar 1 ding: representativiteit. Laat die ingebouwde benchmarks nu vaak niet representatief zijn aangezien er gigantische verschillen zijn tussen daadwerkelijke gameplay waarbij de CPU flink wordt belast, er input van de speler is, NPC's hierop 'reageren' en er mogelijk ook nog eens veel andere spelers zijn en een benchmark waarbij alles al vast ligt. In theorie kan je die benchmarks veel representatiever maken maar zo ver zijn de developers blijkbaar nog niet, in het algemeen.
Het beste zou zijn als ze geen benchmarks inbouwen, dan hoeven 'reviewers' niet de verleiding te weerstaan om die te misbruiken. NIets persoonlijk, het is lazy reviewing om enkel ingebouwde benchmarks te gebruiken. Als je ze daarnaast wil gebruiken, prima, maar niet alleen die ingebouwde benchmarks. Kom dan maar een paar weken later met je review. Een grondige review bestaat uit alle volgende componenten:
- een groot aantal spellen en eventueel andere toepassingen die niet geoptimaliseerd zijn voor een merk (zoals Gimpworks) met alle populaire API's vertegenwoordigd
- 1% FPS, gemiddelde FPS, standaarddeviatie...bij gameplay waarbij je steeds zoveel mogelijk dezelfde gameplay hebt. Dat is veel accurater dan dat jij voorstelt aangezien het een statistische wet is dat je bij voldoende samples regressie naar het midden krijgt als de omstandigheden voldoende gelijk zijn. Dat komt dus weer op hetzelfde punt neer: niet lui reviewen. Niet 1 sample nemen maar een stuk of 5 samples nemen met ongeveer een kwartier aan gameplay.
- framerendertijd van de traagst gerenderde frames geven en het aantal vermelden. Bijvoorbeeld voor GTA5 vermelden dat je bij de 7700k 3 frames hebt die meer dan 0,1 seconde nodig hadden om gerenderd te worden en 1 bij de 1700.
- de inputlag meten

Doe dat alles en je hebt een goede review. Het is slappe hap om slechts gemakszuchtig even een ingebouwde benchmark te draaien en Fraps of Rivatuner of zo te gebruiken en dan de 1% eruit te halen en dit enkel bij DX11. Voor het laatste verwijs ik naar een video van AdoredTV van ongeveer 1 jaar geleden waarin hij uitlegde hoe je voor DX12 de 1% kon achterhalen toen nog niemand het deed. Kwestie van een tool van Intel-medewerker te gebruiken die dit in zijn vrije tijd programmeerde en zelf nog wat simpele code te schrijven om de data te verwerken (of moeilijk doen met Excel/Calc, ieder zijn keuze). Van mij hoeft niemand al die moeite te stoppen in een review maar ik ben wel van mening dat je het net zo goed niet kan doen als je het niet goed doet. Met de 99%/1% is het iets verbeterd en krijgen we een iets minder onnauwkeurig beeld maar we zijn er nog lang niet. Het is nog amateurhour en dat heeft niet enkel te maken met het gebrek aan tijd of moeite wat reviewers willen doen, het heeft ook te maken met een gebrek aan algemeen wetenschappelijk handelen, het is bijvoorbeeld kinderspel om de standaarddeviatie etc. te geven, wat goede plaatjes met statistische data te maken etc. en een deel van de reviewers zou ook moeten weten hoe je dat doet, een deel natuurlijk niet (Paul, Kyle, Linus...).

[ Voor 6% gewijzigd door Verwijderd op 04-10-2017 23:07 ]

[Foritain]

Je mist het punt al bij je eerste zin. Het gaat vaak (bijv in mijn geval) niet om de representieve game ervaring, daarvoor kan je een specifieke game review checken met x GPU's om te leren welke het beste is voor dat doeleinde. Het gaat bij de hardware vergelijking primair en secundair om de verschillen tussen bijvoorbeeld twee grafische kaarten in beeld te brengen, tot zover die al relevant zijn tegenwoordig. Ik ben het 100% met je eens dat wat jij wilt in theorie belangrijk is, maar zo kan ik nog 100 dingen bedenken die ik belangrijk vind. Ik vind Eve-online vet, jij vind Hello Kitty online vet, ik wil renderen en vieze films kijken en etc tegelijk, etc etc, jij wilt hem wellicht in een omgeving van 50 graden kunnen draaien, of -50. Het is dan nooit compleet genoeg.

Gemak vertalen naar lui is ook een redelijke cheap shot in dat opzicht. Ik mag hopen dat geen enkele reviewer dingen gaat doen tegen heug en meug. Dat gezegd hebbende, dat maakt de kritiek en evt wensen zoals bijv frametimes en nog wat stappen verder niet minder relevant of correct, daar niet van, maar om dan meteen over te gaan om te stellen dat je het dan maar beter niet kan doen is ook totale onzin. Een review moet iets proberen toe te voegen, zij het beeldmateriaal, testmateriaal, of (hopelijk) relevant inzicht, (hopelijk) wat vermakelijkheid, of soms gewoon aandacht voor iets wat mensen nog niet kennen. Maar "mijn manier is de enige manier" opmerkingen als feit uitdrukken ga ik niet in mee. Ik zie liever dat mensen weten op welk vlak ze dingen beter los kunnen laten / over kunnen laten aan de persoonlijkheden die daar wel helemaal leip van worden, dan dat ze dat 'ook' maar moeten gaan doen; dan hebben we allemaal wat te kiezen.

Daarbij, ik denk eerder dat er veel meer mensen zitten te wachten op een 250 woord samenvatting dan een echte test bij welke standaard dan ook, maar ieder zn ding enzo he

En ja, dat wij een andere kijk hebben op zaken was ons beide wel bekend volgens mij. Ik kan nog wat kolen op het vuur gooien door te zeggen dat het eigenlijk geen flikker uitmaakt of je een GTX 1060 of een RX 580 koopt op basis van gewoon een paar weken leven en gamen met beide kaarten. Niet onderbouwd (nou ja..), maar m.i. een realistischer beeld van de werkelijkheid en een mogelijk belangrijkere wetenschap voor de consument dan 2 weken lang scheelstaren naar tig fragmenten maal zoveel in GTA V.

[ Voor 5% gewijzigd door Foritain op 04-10-2017 23:24 ]

[Verwijderd]

Over het verschil tussen de 1060 en de 580 kunnen we kort zijn: FreeSync vs. G-Sync en DX12 vs. DX11. Of dat het uitmaakt welke van de twee je neemt hangt af van welke spellen je graag speelt, wat voor monitor je hebt en wanneer je denkt je monitor weer eens te vervangen.
Ja, ik zie graag dat de reviews meer gericht zijn op de nerds dan op de doorsnee consument aangezien ik denk dat daar meer informatie uit te halen valt. Hoe hinderlijk je het vindt om in 2 minuten tijd 3 keer microstutter te hebben (we mogen het toch wel microstutter noemen als je 0,1 second wacht op de volgende frame, ook al is het er maar 1) hangt van de persoon af, het is meer relevant dat je hier mogelijk informatie uit kan halen. Nu zegt die microstutter bij het ene spel geen fuck (de engine zelf die verre van perfect is?) maar als je voor veel spellen een dergelijk onderzoek doet dan krijg je veel meer interessante data. De volgende stap is dan dat je onderzoekt of dat de microstutter in de hand wordt werkt door de hogere FPS (dat lijkt bij Intel in ieder geval zo te zijn voor GTA5) of dat het met de architectuur te maken heeft. Er is veel informatie op te diepen door wel naar die 'pietluttigheden' te kijken, het ene antwoord leidt tot de volgende vraag...

Ja, het is prima dat verschillende mensen een verschillende manier van werken hebben maar het probleem bij die GPU-reviews is dat de ene manier zeer sterk oververtegenwoordigd is en de andere manier een stiefkindje is.

sdk1985 schreef op woensdag 4 oktober 2017 @ 16:39:
[...]

Wellicht iets te voorbarig. Met een luchtkoeler is het gehaald: sdk1985 in "Intel Nieuwsdiscussietopic"

Maar goed 4.5 Ghz op alle cores is wat dat betreft ook voldoende om het nadeel van de lagere standaard clocks te compenseren. Gezien de 5.1 Ghz bestaat er bij mij geen twijfel dat dit makkelijk haalbaar is.

Eerst maar even afwachten wat de refresh van Ryzen gaat doen. Met zo'n 10% verbetering is het in theorie mogelijk dat je rond de 4,4 GHz komt waarmee het verschil klein is. Als je het prijsverschil tussen de 8600k en de 1700 of 1600X in goede RAM stopt (zeer lage latencie en hoge klokfrequentie) dan heb je een hele fraaie combinatie. Natuurlijk, als je de 8600k delidt en er een goede koeler op zet dan wint die het bij veel spellen ruimschoots qua gemiddelde en maximale FPS maar dan praten we alweer over een heel andere situaite, je moet wel eerst die CPU delidden, niet voor de faint of heart zoals ze dat in het Engels zeggen en het geeft weer extra kosten.

[ Voor 39% gewijzigd door Verwijderd op 04-10-2017 23:35 ]

[sdk1985]

Verwijderd schreef op woensdag 4 oktober 2017 @ 23:24:
[...]

Eerst maar even afwachten wat de refresh van Ryzen gaat doen. Met zo'n 10% verbetering is het in theorie mogelijk dat je rond de 4,4 GHz komt waarmee het verschil klein is. Als je het prijsverschil tussen de 8600k en de 1700 of 1600X in goede RAM stopt (zeer lage latencie en hoge klokfrequentie) dan heb je een hele fraaie combinatie. Natuurlijk, als je de 8600k delidt en er een goede koeler op zet dan wint die het bij veel spellen ruimschoots qua gemiddelde en maximale FPS maar dan praten we alweer over een heel andere situaite, je moet wel eerst die CPU delidden, niet voor de faint of heart zoals ze dat in het Engels zeggen en het geeft weer extra kosten.

Ik zou er niet op rekenen. Een 1800X doet nu stock 3.6 met XFR boost naar 4.1 en max OC 4.2. Mijn inschatting voor de refresh: 100-200 Mhz base clock erbij en wie weet 100 Mhz bij de XFR.

De 8600K op 5.1 Ghz was overigens niet gedelid (maar wel 94 graden). Is verder ook helemaal niet zo gek, een 7600K doet ook 4.9 Ghz- 5.0 Ghz. Dus dan zou de gain 100 Mhz zijn.

[Verwijderd]

94 graden, hoe lang houdt die die 5,1 GHz vast?
Puur pragmatisch gezien zijn zowel de 8600k als de Ryzen CPU's een uitstekende keuze, het is een gok wat beter uitpakt op de lange termijn. Dat heeft met het verschil in aantal kernen of prijs (1700/1600 vs. 8600k) en met het upgradepad te maken, je weet dat een Ryzen 2 op hetzelfde moederbord kan draaien en dat Ryzen 3 waarschijnlijk ook daarop zal werken. Bij Intel heb je tegen die tijd alweer een nieuw moederbord nodig. Anderzijds moeten we afwachten hoelang het duurt voordat PCIe 3.0 x16 bottleneckt, momenteel bottleneckt PCIe 3.0 x8 zeer lichtjes de 1080, dat geeft enige indicatie. Het is redelijk gemakkelijk te voorspellen hoe snel de GPU verbetert maar de throughput voorspellen lijkt mij lastiger. Zoals ik eerder aangaf is Intel weer een realistische optie geworden naar mijn mening terwijl dat niet het geval was bij Kaby Lake vs. Ryzen. Daar ben ik blij mee - ondanks dat ik Intel haad omwille van de misdrijven, corruptie en fraude die het pleegde - aangezien dit AMD dwingt om ook weer een schepje erbovenop te doen, concurrentie is goed voor ons, de klanten.

[ Voor 19% gewijzigd door Verwijderd op 04-10-2017 23:46 ]

[Sp3ci3s8472]

sdk1985 schreef op woensdag 4 oktober 2017 @ 23:33:
[...]

Ik zou er niet op rekenen. Een 1800X doet nu stock 3.6 met XFR boost naar 4.1 en max OC 4.2. Mijn inschatting voor de refresh: 100-200 Mhz base clock erbij en wie weet 100 Mhz bij de XFR.

De 8600K op 5.1 Ghz was overigens niet gedelid (maar wel 94 graden). Is verder ook helemaal niet zo gek, een 7600K doet ook 4.9 Ghz- 5.0 Ghz. Dus dan zou de gain 100 Mhz zijn.

Volgens mij laatst Threadripper 1900x op 4.3 gezien, dacht lucht. Natuurlijk is dat waarschijnlijk wel een beter gebinde chip weer.

Intel zal wellicht een voordeel houden in DX11, maar in DX12 zal het voordeel wegvallen.

Het probleem met reviews is dat de levels die getest worden niet representatief zijn, een heel goed voorbeeld is Tombraider. Intel wint het in een aantal levels, AMD weer in een aantal andere levels. Als een review alleen level x laat zien dan kan het in het voordeel zijn voor Intel of AMD.

Het punt is dat levels de cpu op andere manieren belasten.

Dacht dat met de laatste patches AMD het over het algemeen beter doet in dat spel.

[Verwijderd]

Nog een probleempje met reviews: het blindstaren op benchmarks die belachelijk kort duren. De CPU haalt X MHz. Proficiat, maar je hebt er geen zak aan als die dat niet vasthoudt bij een langdurige load. Nu ja, je hebt er iets aan maar niet heel erg veel. Het bekende probleem van de MacBook Pro die goede quadcore CPU's gebruikt die belachelijke overkill zijn omdat de koeling zo slecht is.
Daar ergerde ik me aan bij de SkylakeX-reviews. Draai eens een uur lang zo'n test en zie hoe het dan presteert. Voor multithreadwerk met 10-18 kernen is het vermogen minstens zo belangrijk als de maximale klokfrequentie en als die hitte snel oploopt dan zal de CPU niet die hoge klokfrequentie vasthouden. Het is gek dat ze daar niet naar kijken want voor grafische kaarten doen ze dat wel (concreet, wat de boost wordt na verloop van tijd). Zo'n Cinebench R15 zegt bijvoorbeeld erg weinig als je 16 kernen gebruikt, daarvoor is de benchmark gewoon te kort. We hebben zwaardere benchmarks nodig voor zulke CPU's en het liefst ook benchmarks die minstens een half uur duren want typisch duurt zo'n CPU-load ook zo lang of langer als je die CPU voor het zwaardere werk gebruikt en het jet iets interesseert hoe hoog de performance is. Immers, als je je browser gebruikt, een video afspeelt of LibreOffice gebruikt dan zal het de meeste mensen worst wezen of dat de CPU 10% sneller of trager is, je zal het verschil niet (andere bottleneck: datatransfer tussen RAM/SSD en de CPU) of nauwelijks merken.

==================================================================================
AdoredTV over Forza en Coffee Lake. In een notendop, hij constateert dat Nvidia-kaarten een CPU-bottleneck hebben aangezien de schaling tussen de diverse Nvidia-kaarten niet normaal verloopt en hij constateert dat Intel Kaby Lake 'vermoordt' met de paper launch van Coffee Lake om mindshare te pakken (enthusiasts die op fora aangeven hoe geweldig Coffee Lake is ondanks dat niemand het kan kopen) en om AMD een hak te zetten (mensen die geen Ryzen kopen en wachten totdat Coffee Lake verkrijgbaar is), dit ten koste van de moederbordfabrikanten die een hoop Z270-moederborden niet meer verkocht krijgen maar dat hebben ze ook aan zichzelf te wijten (traag begonnen met Ryzen en overproductie voor Intel in die tijd).

Sp3ci3s8472 schreef op donderdag 5 oktober 2017 @ 01:06:
[...]


Volgens mij laatst Threadripper 1900x op 4.3 gezien, dacht lucht. Natuurlijk is dat waarschijnlijk wel een beter gebinde chip weer.

Op lucht inderdaad. Dat is niets nieuws, in de Cinebench-records zag je vanaf het begin 4,2 en 4,3 GHz. Inderdaad, Voor TR hebben ze de 5% best presterende samples van Ryzen gebruikt. Wat dat betreft is het voor ons gewone klanten wellicht een beetje spijtig dat TR op de markt is gekomen aangezien we zonder TR ook Ryzen-CPU's zouden zien die iets beter presteren.
Maar goed, het gaat over kleine verschillen. Met >=10% performance-verbetering wat AMD verwacht voor de GF '12 nm' FinFET node kan je in theorie ongeveer 400 MHz. hoger uitkomen. Aangezien Ryzen typisch 4,0-4,2 GHz. haalt voor de best presterende kern, zou je dan op 4,4-4,6 GHz uit kunnen komen. Of dat dat ook het geval gaat zijn daar doe ik geen voorspelling over maar dat is de bovengrens. Wat er niet aan klokfrequentie bij komt win je aan vermogen maar ik denk dat de meeste van ons liever hebben dat die maximale klokfrequentie zoveel mogelijk omhoog gaat.

Een interessante discussie - die hier nog niet is gevoerd terwijl het nogal voor de hand ligt - is hoe in het algemeen nodeverkleining uitpakt voor exact dezelfde architectuur. De beste indicator is om te kijken naar hoe in het verleden CPU's en GPU's die exact hetzelfde waren maar een kleinere node kregen presteerden t.o.v. de voorganger. Als iemand hier goede voorbeelden kent van nodeverkleining met exact dezelfde architectuur, noem ze even en we kunnen de twee stukken hardware met elkaar vergelijken en enig idee krijgen over de performanceverbetering.
Daarnaast ben ik benieuwd of dat AMD niet een paar kleine tweaks gaat toepassen die gemakkelijk zijn uit te voeren. Nogmaals, de 8600k en de 8700k zullen het qua single core performance winnen als je optimaliseert maar niemand hoeft daarvan wakker te liggen als PR bijvoorbeeld 4,4 GHz zou halen, laat Intel dan maar 4,6-5,1 GHz halen afhankelijk van of dat de gebruiker de CPU heeft gedelid.

[ Voor 34% gewijzigd door Verwijderd op 05-10-2017 18:16 ]

[Help!!!!]

^
Uhh, sommigen in dit topic lijken een roeping als volume schrijver gemist te hebben. Wat wel helpt om het ook gelezen te krijgen is om iets meer alinea's en witregels toe te passen. NOFI

[sdk1985]

Verwijderd schreef op woensdag 4 oktober 2017 @ 23:24:


[...]

Eerst maar even afwachten wat de refresh van Ryzen gaat doen. Met zo'n 10% verbetering is het in theorie mogelijk dat je rond de 4,4 GHz komt waarmee het verschil klein is. Als je het prijsverschil tussen de 8600k en de 1700 of 1600X in goede RAM stopt (zeer lage latencie en hoge klokfrequentie) dan heb je een hele fraaie combinatie. Natuurlijk, als je de 8600k delidt en er een goede koeler op zet dan wint die het bij veel spellen ruimschoots qua gemiddelde en maximale FPS maar dan praten we alweer over een heel andere situaite, je moet wel eerst die CPU delidden, niet voor de faint of heart zoals ze dat in het Engels zeggen en het geeft weer extra kosten.

Update: Ook Tweakers trekt hem boven de 5 Ghz, zelfs naar x53. Dus die delid vereiste is gelukkig niet aan de orde.

Zoals voorspeld is dit de nieuwe sandy bridge. Snel instappen dus dan zit je weer 5 jaar goed .

[Zeara]

sdk1985 schreef op donderdag 5 oktober 2017 @ 18:35:
[...]

Update: Ook Tweakers trekt hem boven de 5 Ghz, zelfs naar x53. Dus die delid vereiste is gelukkig niet aan de orde.

Zoals voorspeld is dit de nieuwe sandy bridge. Snel instappen dus dan zit je weer 5 jaar goed .

Totaal off topic natuurlijk, maar toch... TPU komt niet verder dan 4.8 Ghz op de i5

https://www.techpowerup.c...tel/Core_i5_8600K/17.html

[foppe-jan]

"zoals voorspeld"? Door wie dan?

Daarnaast is een render van 20s (en 1.4V core) nou niet echt relevant voor de vraag wat voor snelheden een CPU sustained trekt, en wat gezond is voor je CPU.

[sdk1985]

foppe-jan schreef op donderdag 5 oktober 2017 @ 18:45:
"zoals voorspeld"? Door wie dan?

Daarnaast is een render van 20s (en 1.4V core) nou niet echt relevant voor de vraag wat voor snelheden een CPU sustained trekt, en wat gezond is voor je CPU.

Zoals ook al gezegd is het op dit moment niet zo relevant of je nu 24/7 5.1 Ghz of 4.5 Ghz gaat draaien, zo lang je maar boven de clocks van de 7600K uit komt zit je goed. Het nadeel van de extra cores qua lagere clock is daarmee verdwenen. Maar denk dat dit meer iets is voor het Intel topic ipv het radeon topic.

[ Voor 35% gewijzigd door sdk1985 op 05-10-2017 18:49 ]

[Lord_Dain]

sdk1985 schreef op donderdag 5 oktober 2017 @ 18:46:
[...]



Zoals ook al gezegd is het op dit moment niet zo relevant of je nu 24/7 5.1 Ghz of 4.5 Ghz gaat draaien, zo lang je maar boven de clocks van de 7600K uit komt zit je goed. Het nadeel van de extra cores qua lagere clock is daarmee verdwenen. Maar denk dat dit meer iets is voor het Intel topic ipv het radeon topic.

Ik zit met mijn 6700K op 4,4Ghz ook goed, voorlopig geen enkele reden/game om te upgraden. Maare, dacht dat ik hier in het AMD Radeon topic zat... [edit: zie nu de edit pas ]

[Toettoetdaan]

Is dit een HBM2 APU 3Dmark entry: https://i.imgur.com/rmSNLlZ.jpg
(Ik kan de originele bron niet vinden, maar die 256MB varianten zijn gewoon DDR4, maar 4096MB lijkt onlogisch om van systeem RAM te komen. Het kan natuurlijk wel.)

[Verwijderd]

sdk1985 schreef op donderdag 5 oktober 2017 @ 18:35:
[...]

Update: Ook Tweakers trekt hem boven de 5 Ghz, zelfs naar x53. Dus die delid vereiste is gelukkig niet aan de orde.

Nogmaals, een paar seconden bij een benchmarkje op 5,1 GHz zegt geen fuck, het gaat erom of dat die dat ook een half uur lang volhoudt. Gezien de temperatuur van >90 graden Celsius wil ik eerst een testresultaat zien voordat ik geloof dat die dat volhoudt zonder het te delidden.
Instappen bij Intel doe ik sowieso niet zolang AMD een goed alternatief aanbiedt, daarvoor heeft het bedrijf teveel fraude en criminaliteit gepleegd, dat honoreer ik niet met een aankoopt. Als Intel zich normaal had gedragen dan zouden zowel Intel als AMD nu betere CPU's verkopen voor hetzelfde bedrag.
Zes jaar is erg optimistisch voor een hexacore, ik verwacht dat je tegen die tijd een octacore nodig hebt voor PC-gaming.

foppe-jan schreef op donderdag 5 oktober 2017 @ 18:45:
"zoals voorspeld"? Door wie dan?

Daarnaast is een render van 20s (en 1.4V core) nou niet echt relevant voor de vraag wat voor snelheden een CPU sustained trekt, en wat gezond is voor je CPU.

En dat inderdaad, als de CPU het al trekt dan is het de vraag hoe lang die CPU het uithoudt met continue temperaturen van >>90 graden Celsius, als dat na 20 seconden als >90 graden is dan zie ik het na een paar minuten boven de 100 zijn.
Eerst testen zien, dan pas conclusies trekken.

[ Voor 37% gewijzigd door Verwijderd op 05-10-2017 21:17 ]

[DaniëlWW2]

Toettoetdaan schreef op donderdag 5 oktober 2017 @ 20:19:
Is dit een HBM2 APU 3Dmark entry: https://i.imgur.com/rmSNLlZ.jpg
(Ik kan de originele bron niet vinden, maar die 256MB varianten zijn gewoon DDR4, maar 4096MB lijkt onlogisch om van systeem RAM te komen. Het kan natuurlijk wel.)

Ik zie AMD geen HBM2 gebruiken voor een APU. Kennelijk was de nieuwe memory controller van Vega in staat om ook GDDR geheugen te gebruiken, uiteraard met wat aanpassingen, en dat lijkt me heel wat logischer. GDDR6 voor Vega 11 sluit ik eigenlijk ook niet uit, of zelfs GDDR5, maar dat zien we wel. HBM2 zie ik niet gebeuren omdat zelfs een 4GB HBM2 stack al snel net zoveel kunnen kosten als het stukje silicon van de APU zelf. Kennelijk zijn de twee 4GB stacks van RX Vega iets van $150, en een Zen die was dacht ik geschat op minder dan $100. Zit je al snel op een flinke meerprijs. Totaal onbetaalbaar dus om HBM2 te gebruiken bij APU's.

Ook niet logisch omdat je juist met die nieuwe controller, RAM direct aan kan spreken buiten de CPU om. Dat scheelt latency, en maakt het een vrij praktische oplossing voor redelijk low end grafische chips. GDDR5 of GDDR6 kan in principe wel, maar ik denk toch gewoon RAM. Zeker voor laptops zou ik gewoon RAM denken. Je gaat anders wel erg veel hitte producerende onderdelen op een plek concentreren als je binnen de interposer ook plaats moet maken voor GDDR chips. Lijkt me minder dan optimaal.

Maar Raven Ridge zit er dus wel eindelijk aan te komen. Beter laat dan nooit, hoewel het 2017 feestseizoen waarschijnlijk vergeten zal moeten worden. Ik vermoed eigenlijk dat dit bewust is. Eerst mainstream, high end en professionele Zen voor de per unit marges, en daarna de APU's. Dit lijkt allemaal het eerste CPU team te zijn van AMD, en wat imput van de RTG voor de GPU kant. AMD CPU team twee komt ondertussen dan met de volgende Zen iteratie in begin 2018.

[Verwijderd]

Het lijkt me inderdaad weinig realistisch, voor de komende tijd, om HBM op de APU's te stoppen. Over een paar jaar misschien.

Help!!!! schreef op donderdag 5 oktober 2017 @ 18:26:
^
Uhh, sommigen in dit topic lijken een roeping als volume schrijver gemist te hebben. Wat wel helpt om het ook gelezen te krijgen is om iets meer alinea's en witregels toe te passen. NOFI

Ik ben niet degene die ervoor kiest om 3 reacties in 1 reactie te stoppen omdat de moderators hier allergisch zijn voor meer reacties onder elkaar.

[ Voor 12% gewijzigd door Verwijderd op 05-10-2017 23:22 ]

[Verwijderd]

DaniëlWW2 schreef op donderdag 5 oktober 2017 @ 21:56:
[...]


Ik zie AMD geen HBM2 gebruiken voor een APU. Kennelijk was de nieuwe memory controller van Vega in staat om ook GDDR geheugen te gebruiken, uiteraard met wat aanpassingen, en dat lijkt me heel wat logischer. GDDR6 voor Vega 11 sluit ik eigenlijk ook niet uit, of zelfs GDDR5, maar dat zien we wel. HBM2 zie ik niet gebeuren omdat zelfs een 4GB HBM2 stack al snel net zoveel kunnen kosten als het stukje silicon van de APU zelf. Kennelijk zijn de twee 4GB stacks van RX Vega iets van $150, en een Zen die was dacht ik geschat op minder dan $100. Zit je al snel op een flinke meerprijs. Totaal onbetaalbaar dus om HBM2 te gebruiken bij APU's.
...

Ik zal het heel erg jammer vinden als AMD mensen met een hoger budget zoals ik links laten liggen. Dan moet ik helaas noodgedwongen weer voor Intel + Nvidia quadro gaan, als ik een high end laptop wil.

Hier kun je Intel's adviesprijzen zien.
https://www.intc.com/inve...u-price-list/default.aspx

De duurste Mobile van Intel is o.a.: i7-6970HQ met een prijs van $623

Voordeel van HBM2 is dat er geen noodzaak meer is om een dedicated mobile videokaart te nemen. Bij de Iris Pro van Intel is dat mid end en dat wordt vaak gecombineerd met een AMD Polaris zoals in de MacBook Pro 2016. Dan kom je uit op een prijs van richting de $800.

Ik zie geen reden om geen HBM2 geheugen te kiezen. Ik zal het eerder een gemiste kans vinden, want je jaagt high end zakelijke users weg. En dat is juist de doelgroep die meer te besteden hebben.

[DaniëlWW2]

Verwijderd schreef op donderdag 5 oktober 2017 @ 23:40:
[...]

Ik zal het heel erg jammer vinden als AMD mensen met een hoger budget zoals ik links laten liggen. Dan moet ik helaas noodgedwongen weer voor Intel + Nvidia quadro gaan, als ik een high end laptop wil.

Hier kun je Intel's adviesprijzen zien.
https://www.intc.com/inve...u-price-list/default.aspx

De duurste Mobile van Intel is o.a.: i7-6970HQ met een prijs van $623

Voordeel van HBM2 is dat er geen noodzaak meer is om een dedicated mobile videokaart te nemen. Bij de Iris Pro van Intel is dat mid end en dat wordt vaak gecombineerd met een AMD Polaris zoals in de MacBook Pro 2016. Dan kom je uit op een prijs van richting de $800.

Ik zie geen reden om geen HBM2 geheugen te kiezen. Ik zal het eerder een gemiste kans vinden, want je jaagt high end zakelijke users weg. En dat is juist de doelgroep die meer te besteden hebben.

Maar als jij high end wil gaan met een laptop, dan zal je toch tegen limitaties van een APU aan gaan lopen ben ik bang. AMD gaat voor een chip, een platform strategie voor desktop, en de mobiele chips gaan gewoon lagere voltag, en lager geclockte modellen worden. De APU gaat maximaal een quadcore en een redelijke grafische chip zijn. Hoe sterk die chip precies is weet die geen NDA heeft getekend. Een chip vergelijkbaar met Polaris 10/20 zou ik niet verwachten. Dat is veel te groot voor een APU.

Nee, als je een flinke GPU wil, dan ben je afhankelijk van een losse chip, naast de CPU. Dat zal de mobiele versie worden van Vega 11. Dat lijken Vega 32 en Vega 28 te worden, dus de helft van Vega 10 qua hardware. Dan waarschijnlijk GDDR5 omdat HBM2 duur is, lastig te produceren etc. Met GDDR5 geheugen lopend op 2000MHz, en een vrij typische 256bit bus heb je al net zoveel bandbreedte als een GTX1070. Dat is het probleem niet. HBM2 is natuurlijk beter, als AMD het kan betalen, omdat HBM2 extreem efficiënt is. Er zijn alleen tekorten aan die chips, en ze worden ook opgekocht door Nvidia, Google en Intel. Dat is het probleem, ze zijn geweldig voor deep learning platformen. Die 8GB stacks voor Vega 10 gebruiken maar 15W, terwijl een *GB GDDR5 setup zo tegen de 50W aan zou zitten.

Overigens zou AMD ooit met een mobiele Vega 10 kunnen komen, als ze leren wat undervolting is. Je kan een Vega chip met gemak onder de 150W krijgen, en waarschijnlijk nog veel lager dan dit, als je de clocks maar laat zakken. Onder de 200W en redelijk vergelijkbaar met een GTX1080 kan ook gewoon. Dat heb ik met mijn RX Vega 56 gedaan.

[Dennism]

foppe-jan schreef op donderdag 5 oktober 2017 @ 18:45:
"zoals voorspeld"? Door wie dan?

Daarnaast is een render van 20s (en 1.4V core) nou niet echt relevant voor de vraag wat voor snelheden een CPU sustained trekt, en wat gezond is voor je CPU.

Relevant niet direct voor 24/7 OC's, maar het zegt wel wat. 5.2 booten op Kaby Lake was in de regel al een no go (zelfs met Delid), laat staan een render draaien.

Dat deze cpu's booten op 5.2 / 5.3 in reviews zonder delids en een cinebench kunnen draaien is eigenlijk al best heel wat. Je ziet ook dat redelijk wat reviewers aangeven dat OC's van 5.0 zonder delid met een deftige koeler mogelijk wel eens de standaard kunnen gaan worden zolang je niet heel de dag Prime95 met AVX gaat draaien.

Voor de beste OC's zal een delid zeker nodig blijven zijn, maar als je zonder al te veel moeite een 24/7 5.0 Ghz all core OC kan draaien zonder delid die bij normale workloads (gaming / productivity) een redelijke temperatuur heeft is dat toch een vrij grote winst voor de reguliere gebruiker t.o.v. Kaby Lake waar je (golden samples daargelaten) veel meer moeite moest doen voor een 5Ghz OC.

[foppe-jan]

offtopic:
https://etherscan.io/chart/hashrate

en toen steeg de hashrate weer.

[Verwijderd]

DaniëlWW2 schreef op vrijdag 6 oktober 2017 @ 08:58:
[...]


Maar als jij high end wil gaan met een laptop, dan zal je toch tegen limitaties van een APU aan gaan lopen ben ik bang. AMD gaat voor een chip, een platform strategie voor desktop, en de mobiele chips gaan gewoon lagere voltag, en lager geclockte modellen worden. De APU gaat maximaal een quadcore en een redelijke grafische chip zijn. Hoe sterk die chip precies is weet die geen NDA heeft getekend. Een chip vergelijkbaar met Polaris 10/20 zou ik niet verwachten. Dat is veel te groot voor een APU.

Nee, als je een flinke GPU wil, dan ben je afhankelijk van een losse chip, naast de CPU. Dat zal de mobiele versie worden van Vega 11. Dat lijken Vega 32 en Vega 28 te worden, dus de helft van Vega 10 qua hardware. Dan waarschijnlijk GDDR5 omdat HBM2 duur is, lastig te produceren etc. Met GDDR5 geheugen lopend op 2000MHz, en een vrij typische 256bit bus heb je al net zoveel bandbreedte als een GTX1070. Dat is het probleem niet. HBM2 is natuurlijk beter, als AMD het kan betalen, omdat HBM2 extreem efficiënt is. Er zijn alleen tekorten aan die chips, en ze worden ook opgekocht door Nvidia, Google en Intel. Dat is het probleem, ze zijn geweldig voor deep learning platformen. Die 8GB stacks voor Vega 10 gebruiken maar 15W, terwijl een *GB GDDR5 setup zo tegen de 50W aan zou zitten.

...

Waar ik nu een probleem mee heb is dat het huidige aanbod van APU/iGPU waarvan ik de grafische kracht veel te zwak vind. Als je er toch "weinig" aan hebt, laat het dan gewoon weg.
Als een APU zonder eigen geheugen te zwak is en een losse GPU veel te duur dan is het toch logisch om met een aanbod te komen dat er tussen zit. En daarnaast een combo van HBM2 APU + Polaris in Crossfire zie ik ook wel zitten.

Ik weet niet of de schaarste van HBM2 ook geldt voor lager geklokte versies. Stel dat er HBM2 wordt gebruikt, dan gaat AMD echt geen 945Mhz of 800Mhz varianten gebruiken. Ik denk eerder 600Mhz en dan is de prijs ook minder dan de $150.

[DaniëlWW2]

Verwijderd schreef op vrijdag 6 oktober 2017 @ 17:14:
[...]


Waar ik nu een probleem mee heb is dat het huidige aanbod van APU/iGPU waarvan ik de grafische kracht veel te zwak vind. Als je er toch "weinig" aan hebt, laat het dan gewoon weg.

De meeste GPU's zijn dan ook bedoeld voor 1080P video, en echt zeer lichte games. Dat Intel het een IGP (Intel Graphics Processor) noemt kan me niks schelen, het is een GPU, en samen met een CPU is het een APU. Wil je meer, dan ontkom je niet aan een aparte GPU chip. Een beetje GPU chip is ook een stuk groter dan een APU chip, dus CPU en GPU samen.

Een aparte losse lijn zonder de GPU is niet rendabel, dus bestaat ook niet. Het heeft ook zo zijn voordelen om een APU te verkopen. OEM's willen deze functionaliteit, en optioneel er zelf een extra GPU bij kunnen plaatsen. Omdat er ook geen GPU chips meer bestaan die op een moederbord zijn gesoldeerd, hebben OEM's geen andere keuze dan een APU.

Als een APU zonder eigen geheugen te zwak is en een losse GPU veel te duur dan is het toch logisch om met een aanbod te komen dat er tussen zit. En daarnaast een combo van HBM2 APU + Polaris in Crossfire zie ik ook wel zitten.

Ik weet niet of de schaarste van HBM2 ook geldt voor lager geklokte versies. Stel dat er HBM2 wordt gebruikt, dan gaat AMD echt geen 945Mhz of 800Mhz varianten gebruiken. Ik denk eerder 600Mhz en dan is de prijs ook minder dan de $150.

Polaris gaat nooit HBM2 krijgen. Dat vraagt om een serieus herontwerp van de chip, en het is oude technologie. Vega 11 kan, maar acht ik dus niet erg waarschijnlijk. Verder snap ik niet dat je je nu dood staart op HBM2. Het zijn de chips zelfs die hartstikke duur zijn, omdat er enorme schaarste is, en omdat het nieuwe, en betere technologie is. Verder zouden HMB2 chips die op 600MHz lopen, dit doen met lagere voltages. Je hebt 1,2v nodig voor 800MHz, 1,35v voor 945MHz. 600MHz zal gewoon met lagere voltages dan 1,2v werken, dus waarom die dure chips niet verkopen in een hogere segmentatie? AMD koopt gewoon HBM2 chips van de twee produceren, Samsung en SK Hynix, en stelt de voltages zelf af, afhankelijk of het een RX Vega 56 of 64 is.

Er is niks mis met GDDR5 voor een minder high end chip.

[Verwijderd]

@DaniëlWW2
Met HBM2 APU + Polaris bedoel ik dat alleen de APU HBM2 krijgt en NIET dat Polaris OOK HBM2 krijgt.

Hier heb je een laptop waarbij de CPU geen APU is.
https://www.asus.com/Laptops/ROG-Strix-GL702ZC/

en hier Xeon laptop, inmiddels EOL, omdat Intel deze processoren niet meer levert.
https://www.titancomputer...e-Workstation-p/x95mw.htm

En ik snap niet waarom $150 peperduur duur is. Als een IT'er per dag 15 minuten langer moet wachten en dat maal 200 werkdagen in 1 jaar. Dan stelt die $150 echt geen zak voor.

...waarom die dure chips niet verkopen in een hogere segmentatie?...

Dat probeer ik de hele tijd duidelijk te maken ik heb een groot budget voor een dure laptop.

Het valt me op dat veel IT'ers met een Macbook Pro rondlopen. Als prijs een issue is dan hadden ze allang voor een Windows laptop gekozen met een Linux distro.

[Sp3ci3s8472]

Verwijderd schreef op vrijdag 6 oktober 2017 @ 21:33:
@DaniëlWW2
Met HBM2 APU + Polaris bedoel ik dat alleen de APU HBM2 krijgt en NIET dat Polaris OOK HBM2 krijgt.

Hier heb je een laptop waarbij de CPU geen APU is.
https://www.asus.com/Laptops/ROG-Strix-GL702ZC/

en hier Xeon laptop, inmiddels EOL, omdat Intel deze processoren niet meer levert.
https://www.titancomputer...e-Workstation-p/x95mw.htm

En ik snap niet waarom $150 peperduur duur is. Als een IT'er per dag 15 minuten langer moet wachten en dat maal 200 werkdagen in 1 jaar. Dan stelt die $150 echt geen zak voor.


[...]

Dat probeer ik de hele tijd duidelijk te maken ik heb een groot budget voor een dure laptop.

Het valt me op dat veel IT'ers met een Macbook Pro rondlopen. Als prijs een issue is dan hadden ze allang voor een Windows laptop gekozen met een Linux distro.

Raven Ridge krijgt Vega, het lijkt mij in dat geval dan ook dat die chip meer kans heeft op HBM2. Zou ideaal zijn voor een snelle HTPC waarop te gamen valt.

[Verwijderd]

@Sp3ci3s8472
Daarnaast, die $150 gaat om 8GB HBM2. Als Raven Ridge HBM2 krijgt, dan zal het om max. 4GB zijn (8GB zal leuker zijn). De prijs van DDR4 en GDDR5 kost ook geld. Uiteindelijk is de kostprijs iets van $50 of minder, extra per 4GB.

[NitroX infinity]

4GiB HBM2? Ik denk eerder dat er hooguit maar 1GiB in komt als cache. Dat zal meer dan genoeg zijn voor een APU.

[foppe-jan]

New beta 19 is online:

http://www.guru3d.com/fil...burner-beta-download.html

Changes list includes:

· Added low-level AMD Vega 10 graphics processors family support. This means that now MSI AB can access this GPU directly without AMD ADL API, so more powerful voltage control (no longer limited by AMD ADL API) and extended and more efficient low-level hardware monitoring are available for Vega now
· Core voltage control for reference design AMD Vega series cards is now performed via low-level access to on-die SMC microcontroller. Voltage is adjusted in offset form now, applied to all P-states (just like it was on Fiji/Polaris) and full -100..+100 range is available
· Added GPU power draw graph to hardware monitoring module for AMD Vega series graphics cards
· Added HBM memory temperature graph to hardware monitoring module for AMD Vega series graphics cards
· Improved voltage offset calculation accuracy for AMD Fiji, Ellesmere and Baffin GPU families
· Improved voltage offset programming reliability on AMD Ellesmere and Baffin GPU families
· Fixed stuck GPU usage and memory controller usage monitoring on AMD Radeon RX 500 series under 17.6.1 and newer drivers
- Fixed issue with opening wrong graph properties under certain conditions when right clicking a graph in hardware monitoring window and selecting “Properties” command from the context menu
- Fixed issue with wrong alarm threshold visualization on the graph label in OSD for monochrome OSD layouts
- Improved plugins:
+ Data sources exported by plugins no longer share the same MONITORING_SOURCE_ID_UNKNOWN data source identifier, which means that now you can define independent custom formatting (e.g. group colors) for plugin specific data sources in OSD layout editor
+ PerfCounter plugin has been improved to handle corrupted registry performance counters list on some systems and to be able to access at least the part of performance counters available on the system in such case
- I've temporarily signed both installer and application executable with my own signature.

[Astennu]

foppe-jan schreef op maandag 9 oktober 2017 @ 18:32:
New beta 19 is online:

http://www.guru3d.com/fil...burner-beta-download.html

Changes list includes:

· Added low-level AMD Vega 10 graphics processors family support. This means that now MSI AB can access this GPU directly without AMD ADL API, so more powerful voltage control (no longer limited by AMD ADL API) and extended and more efficient low-level hardware monitoring are available for Vega now
· Core voltage control for reference design AMD Vega series cards is now performed via low-level access to on-die SMC microcontroller. Voltage is adjusted in offset form now, applied to all P-states (just like it was on Fiji/Polaris) and full -100..+100 range is available
· Added GPU power draw graph to hardware monitoring module for AMD Vega series graphics cards
· Added HBM memory temperature graph to hardware monitoring module for AMD Vega series graphics cards
· Improved voltage offset calculation accuracy for AMD Fiji, Ellesmere and Baffin GPU families
· Improved voltage offset programming reliability on AMD Ellesmere and Baffin GPU families
· Fixed stuck GPU usage and memory controller usage monitoring on AMD Radeon RX 500 series under 17.6.1 and newer drivers
- Fixed issue with opening wrong graph properties under certain conditions when right clicking a graph in hardware monitoring window and selecting “Properties” command from the context menu
- Fixed issue with wrong alarm threshold visualization on the graph label in OSD for monochrome OSD layouts
- Improved plugins:
+ Data sources exported by plugins no longer share the same MONITORING_SOURCE_ID_UNKNOWN data source identifier, which means that now you can define independent custom formatting (e.g. group colors) for plugin specific data sources in OSD layout editor
+ PerfCounter plugin has been improved to handle corrupted registry performance counters list on some systems and to be able to access at least the part of performance counters available on the system in such case
- I've temporarily signed both installer and application executable with my own signature.

Ik ben zelf geen fan van Voltage offset. Voor overclocking geen issue maar voor underclocken is het een ramp. Je 2e voltage gaat dan snel te laag en dan crashed hij zonder load. Met de 290X kon ik maar -37mv geven maar met een custom bios of wattman kon ik makkelijk lager eerder in de richting van -130mv.

[The Source]

Ik denk dat we dit jaar weinig custom VEGA meer gaan zien. AMD heeft geen update of GPUs beschikbaar. Als ze vandaag aangeven dat ze ze hebben dan kunnen wij die 2 weken later in productie hebben en een maand later liggen ze in de winkel. Dus voor december hoef je weinig VEGA te verwachten. Verder hoor ik ook dat veel merken hun orders voor de VEGA koelers bij thermal OEMs gecancelled hebben, dus mocht er GPU supply komen dan kan dit ook nog wel eens vertragend werken.

[Apoca]

Radeon Software Crimson ReLive Edition 17.10.1 BETA

Support For

• Evil Within 2
• Radeon Chill profile added
• Middle Earth: Shadow of War
• Radeon Chill profile added

Fixed Issues

• Bezel compensation in mixed mode Eyefinity cannot be applied.
• DiRT 4 may experience flickering tire graphics during gameplay or under certain terrain conditions when using Multi GPU enabled system configurations.

http://support.amd.com/en-us/download

[ Voor 3% gewijzigd door Apoca op 10-10-2017 21:04 ]

[Astennu]

The Source schreef op dinsdag 10 oktober 2017 @ 20:29:
Ik denk dat we dit jaar weinig custom VEGA meer gaan zien. AMD heeft geen update of GPUs beschikbaar. Als ze vandaag aangeven dat ze ze hebben dan kunnen wij die 2 weken later in productie hebben en een maand later liggen ze in de winkel. Dus voor december hoef je weinig VEGA te verwachten. Verder hoor ik ook dat veel merken hun orders voor de VEGA koelers bij thermal OEMs gecancelled hebben, dus mocht er GPU supply komen dan kan dit ook nog wel eens vertragend werken.

Lijkt er op dat AMD de chips vooral in de Instinct lijn levert?

Mogelijk komt er begin volgend jaar een Vega uit op het 12nm process. Echter zit nVidia ook niet stil.

Aan de andere kant als AMD goede midrange/high end kaarten heeft is het ook goed.
Dat je niet in de snelste classe mee kan doen is jammer en voor je marketing niet zo voordelig maar de meeste kaarten worden in de veel lagere prijs segmenten verkocht. Polaris deed het voor de mining hype als game kaart goed ondanks dat AMD geen high end kaart had die het van nVidia kon winnen.

[Sp3ci3s8472]

Astennu schreef op dinsdag 10 oktober 2017 @ 18:14:
[...]


Ik ben zelf geen fan van Voltage offset. Voor overclocking geen issue maar voor underclocken is het een ramp. Je 2e voltage gaat dan snel te laag en dan crashed hij zonder load. Met de 290X kon ik maar -37mv geven maar met een custom bios of wattman kon ik makkelijk lager eerder in de richting van -130mv.

Mee eens, voltage offset klinkt leuk. Dit had ik eerder voor mijn Ryzen systeem, helaas was dit niet goed stabiel te krijgen. Het zelf invullen is stabieler.

[Astennu]

Sp3ci3s8472 schreef op woensdag 11 oktober 2017 @ 12:39:
[...]


Mee eens, voltage offset klinkt leuk. Dit had ik eerder voor mijn Ryzen systeem, helaas was dit niet goed stabiel te krijgen. Het zelf invullen is stabieler.

Yep.
Bij CPU's heb je helaas geen controle over de verschillende Pstates en Turbo states. Eigenlijk zou je ook de 1-2 core turbo los willen kunnen aanpassen enz.

Offset voor OC kan er wel voor zorgen dat je Idle voltage niet de hele tijd 1.35v is maar wel wat kan zakken. Maar het is idd lastiger stabiel te krijgen. Goede balans zoeken tussen offset + Load line calibration.

[Dennism]

Astennu schreef op woensdag 11 oktober 2017 @ 09:05:
[...]


Lijkt er op dat AMD de chips vooral in de Instinct lijn levert?

Ben dan wel benieuwd wat de yields c.q. productie capaciteit is. Ik kan me toch lastig voorstellen dat de vraag vanuit de datacenter / HPC / Server en de lagere segmenten in de zakelijke markt e.d. zo groot is dat bij goede yields en een normale productie capaciteit alles daar heen gaat. Normaal zijn toch segmenten met relatief gezien lagere vraag maar hoge marges. Ik krijg dan toch het gevoel dat de yields of de productie capaciteit ook "te" laag is.

Zeker gezien de Instinct Mi25 / Radeon Pro / SSG ook allemaal nog een "Notify Me" knop hebben op hun respectievelijke websites zodat je bericht kan krijgen wanneer ze beschikbaar worden.

[ Voor 12% gewijzigd door Dennism op 11-10-2017 16:29 ]

[DaniëlWW2]

Dennism schreef op woensdag 11 oktober 2017 @ 16:22:
[...]


Ben dan wel benieuwd wat de yields c.q. productie capaciteit is. Ik kan me toch lastig voorstellen dat de vraag vanuit de datacenter / HPC / Server en de lagere segmenten in de zakelijke markt e.d. zo groot is dat bij goede yields en een normale productie capaciteit alles daar heen gaat. Normaal zijn toch segmenten met relatief gezien lagere vraag maar hoge marges. Ik krijg dan toch het gevoel dat de yields of de productie capaciteit ook "te" laag is.

Zeker gezien de Instinct Mi25 / Radeon Pro / SSG ook allemaal nog een "Notify Me" knop hebben op hun respectievelijke websites zodat je bericht kan krijgen wanneer ze beschikbaar worden.

Aan de andere kant neemt de vraag naar dergelijke hardware wel snel toe. Vega 10 is ook echt een uitstekende chip voor juist dit soort taken, en ook nog eens voor een goede prijs in dit segment. Ik speculeer/verwachtte eigenlijk al maanden dat veel chips hier naartoe zouden gaan, en ik lijk redelijk gelijk te krijgen. Zeker voor de volle Vega 10 chip heeft AMD botweg geen enkel financieel belang om de voorkeur te geven aan de RX lijn. Dat moet toch duidelijk zijn geweest toen de MI25 in juni al beschikbaar werd gemaakt, FE in juli, terwijl RX er pas in augustus/september was.

[Dennism]

DaniëlWW2 schreef op woensdag 11 oktober 2017 @ 17:18:
[...]


Aan de andere kant neemt de vraag naar dergelijke hardware wel snel toe. Vega 10 is ook echt een uitstekende chip voor juist dit soort taken, en ook nog eens voor een goede prijs in dit segment. Ik speculeer/verwachtte eigenlijk al maanden dat veel chips hier naartoe zouden gaan, en ik lijk redelijk gelijk te krijgen. Zeker voor de volle Vega 10 chip heeft AMD botweg geen enkel financieel belang om de voorkeur te geven aan de RX lijn. Dat moet toch duidelijk zijn geweest toen de MI25 in juni al beschikbaar werd gemaakt, FE in juli, terwijl RX er pas in augustus/september was.

Dat er procentueel gezien veel chips die kant op gaan lijkt me eigenlijk ook wel vrij zeker, en het is ook nog eens zeer logisch. Waarom een chip verkopen voor een paar honderd dollar wanneer je deze ook kan verkopen voor duizenden dollars.

Neemt niet weg dat ik nog steeds mijn vragen stel bij de yields / productie capaitecit als deze beide op niveau zijn zou je al wel meer beschikbaarheid verwachten ook van o.a. de Radeon Pro en SSG kaarten in de OEM workstations bijvoorbeeld.

[FortyOne]

Er gaan natuurlijk ook best wat Vega's richting Apple, die zullen wel een goede deal hebben bedongen. Geen idee hoeveel iMac Pro's er normaal gesproken in een kwartaal verkocht worden, maar als de productie van Vega nog niet zo vlot gaat zal het zeker een dingetje zijn.

Ik betwijfel sterk dat er veel Instinct producten verkocht worden, op dat vlak lopen ze nog erg achter op nVidia. Met de Radeon Pro's zijn ze wel aardig competitief, geloof ik.

[Help!!!!]

HardOCP: AMD vs. Intel HEDT Platform Showdown Editorial

[Dennism]

FortyOne schreef op woensdag 11 oktober 2017 @ 17:49:
Er gaan natuurlijk ook best wat Vega's richting Apple, die zullen wel een goede deal hebben bedongen. Geen idee hoeveel iMac Pro's er normaal gesproken in een kwartaal verkocht worden, maar als de productie van Vega nog niet zo vlot gaat zal het zeker een dingetje zijn.

Zeer weinig gok ik, aangezien het een nieuw product is en deze pas vanaf december verkrijgbaar zal zijn. Neemt natuurlijk niet wel dat ze voor die tijd zullen produceren en dus GPU's nodig zullen hebben, maar ook deze machine met zijn $4999 instap prijskaartje zou in de regel niet zo populair mogen zijn dat je bij hoge yields en een gezonde productie capaciteit tegen lever problemen aanloopt.

[DaniëlWW2]

Dennism schreef op woensdag 11 oktober 2017 @ 17:29:
[...]


Dat er procentueel gezien veel chips die kant op gaan lijkt me eigenlijk ook wel vrij zeker, en het is ook nog eens zeer logisch. Waarom een chip verkopen voor een paar honderd dollar wanneer je deze ook kan verkopen voor duizenden dollars.

Neemt niet weg dat ik nog steeds mijn vragen stel bij de yields / productie capaitecit als deze beide op niveau zijn zou je al wel meer beschikbaarheid verwachten ook van o.a. de Radeon Pro en SSG kaarten in de OEM workstations bijvoorbeeld.

Ik vermoed eigenlijk dat Vega 10 bij Samsung word geproduceerd, en niet bij GF, in niet al te grote kwantiteit, en daar zijn wat redenen voor te geven.

Ten eerste natuurlijk HBM2 tekorten waardoor er een limiet is aan hoeveel Vega 10 chips je kan maken voordat het zinloze overproductie is. Ten tweede is een high end GPU geen enorm volumeproduct zoals een x86 CPU. Ten derde wat er nu allemaal gebeurd bij GF fab 8 in Saratoga County, New York.

Fab 8 is de plek waar GF haar 14nm LPP FinFet wafers produceert. Daar komen alle Zen chips vandaan, en waarschijnlijk ook alle Polaris chips. FinFet is hardstikke duur, en zal niet worden gebruikt door kleine spelers. Die zijn afhankelijk van bestaande 28nm nodes, grotere nodes, of FD-SOI. HP zit bij Fab 10, voormalig IBM Building 323 waar ze hun eigen chips laten produceren op 14nm HP. Blijft AMD als enige afnemer van Fab 8 over. De gehele capaciteit zal dan ook voor AMD zijn. Dat zijn 60.000, 300mm wafers per maand.

Als ik echt super quick en dirty dan ga rekenen met een wafertool:
http://www.silicon-edge.c...p/resources/die-per-wafer

192mm2 die size voor Zen, dus 14mm die width ingevuld want 14x14=196. Kom je op 422 per wafer. Ga je uit van 80% yield, dan heb je er per maand dus 80x422:100 = 337,6 x 60.000 = 20.256.000 functionele chips per maand. Niet slecht.

edit: Nee stupid, het zijn 297 chips per wafer, 80% hiervan is 237,6x60.000=14.256.000. Leer kijken.

Natuurlijk zal niet alles Zen zijn, een deel al Polaris zijn, en Vega zou zelfs ook nog kunnen.

Het probleem is alleen niet huidige capaciteit, maar dat het een fab is dat alles produceert voor AMD. Begin volgend jaar krijgen we 12nm voor Ryzen 2, en waarschijnlijk ook voor Vega 11. Dit kan wederom alleen geproduceerd worden in Fab 8. Samsung gaat naar een eigen 11nm node, dus dat is ook geen optie, terwijl GF en Samsung nu de 14nm LPP node delen.

Nu lijkt me het ietwat problematisch om een clean room om te schakelen voor een nieuwe node, en tegelijkertijd ook chips te produceren. Allemaal eens, oke gaan we verder want er zijn meer problemen.

Fab 8 gaat binnenkort ook nog eens omgebouwd worden naar 7nm. Deze node zou vanaf H2/2018 beschikbaar zijn voor productie. Dat staat allang in de planning, en die houden ze nog steeds aan. Nu is 12nm een aangepaste 14nm LPP, en dat zal met aangepaste, huidige machines gaan neem ik aan. 7nm is echt ombouwen. Hoe wil je dit nu gaan doen?

---

Ik vermoed eigenlijk dat Polaris al uit productie is, bij GF, en Zen binnenkort zal volgen. Ik gok zo dat AMD een enorm volume heeft geproduceerd voor beide chips, en toen over is geschakeld op 12nm voor Ryzen 2 en Vega 11. Van die chips worden nu functionele producten gemaakt, en dat was het dan. GF moet dan wederom enorm volume's gaan produceren want de boel moet weer stilgelegd worden voor overschakeling naar 7nm, voor de 2019 lijn van Zen 2 en Navi.

Hoe wil je hier nu Vega 10 produceren, een chip die ook nog tot dik in 2018 verkocht zal moeten worden? Ik zie het dus niet gebeuren bij GF, maar bij Samsung. Ik zou ook niet verbaast zijn als Raven Ridge ook bij Samsung gemaakt zal worden op 14nm LPP. Dat is ook eerste generatie Zen, een op 14nm LPP gebakken CCX unit, en een Vega GPU. Ik zie dat echt niet meer bij GF geproduceerd worden, maar bij Samsung.

[Dennism]

DaniëlWW2 schreef op woensdag 11 oktober 2017 @ 21:07:

Als ik echt super quick en dirty dan ga rekenen met een wafertool:
http://www.silicon-edge.c...p/resources/die-per-wafer

192mm2 die size voor Zen, dus 14mm die width ingevuld want 14x14=196. Kom je op 422 per wafer. Ga je uit van 80% yield, dan heb je er per maand dus 80x422:100 = 337,6 x 60.000 = 20.256.000 functionele chips per maand. Niet slecht.

Ik zal wel iets verkeerd doen, want ik kom op 303 voor 10x19.2 en 297 voor 14x14 bij een 300mm wafer in die calculator

Quote verder wat ingekort en dat zou inderdaad allemaal kunnen wat je schetst, het zou natuurlijk ook zo maar niet zo kunnen zijn

Verder natuurlijk gelijk dat een high end GPU normaliter geen volume product is, maar als je van het zakelijke top segment tot het consumenten hogere midden segment effectief wil bedienen met 1 chip zou dit eigenlijk wel een volume product moeten zijn als je al je klanten tevreden wil houden.

[DaniëlWW2]

Dennism schreef op donderdag 12 oktober 2017 @ 08:59:
[...]


Ik zal wel iets verkeerd doen, want ik kom op 303 voor 10x19.2 en 297 voor 14x14 bij een 300mm wafer in die calculator

Ik heb alleen de eerste waarde aangepast naar 14mm, en wafer naar 300mm.

Quote verder wat ingekort en dat zou inderdaad allemaal kunnen wat je schetst, het zou natuurlijk ook zo maar niet zo kunnen zijn

Verder natuurlijk gelijk dat een high end GPU normaliter geen volume product is, maar als je van het zakelijke top segment tot het consumenten hogere midden segment effectief wil bedienen met 1 chip zou dit eigenlijk wel een volume product moeten zijn als je al je klanten tevreden wil houden.

En daarom denk ik dus dat het Samsung productie is. Die chips moeten ergens gemaakt worden. Verder zal AMD inzetten op marktpenetratie, maar ook niet durven gokken dat ze een gigantische stapel chips laten bakken, die niet verkopen, en ze deze dan moeten dumpen voor verlies. Het zal denk ik een geleidelijk proces zijn, waar ze maar zoveel wafers per maand afwerken voor Vega 10. Voldoende om alle HBM2 chips die ze kunnen krijgen, ook kunnen verkopen, maar niet meer. Blijkt er nu opeens dat Vega 10 naar 12nm gaat, dan ligt het heel anders.

Uiteindelijk denk ik ook dat Vega 10 niet de top prioriteit is voor AMD. Het is een gigantisch per unit margeproduct voor de MI25 en Radeon Pro, gedeeltelijk mislukte chips kunnen worden afgezet als RX Vega 56, en Apple levert wat extra volumeverkopen op. Het blijft alleen een 484mm2 chip, die AMD waarschijnlijk voor een zeer krappe marge verkoopt aan Apple of een AIB, als deze niet geschikt is voor een HPC kaart. Dat staat in schril contrast met Zen chips waar ze zo marges kunnen pakken die meermaals de productiekosten van de chip waren. Dan hebben ze ook nog eens bijna eindeloze binning en schaling bij Zen, of kunnen ze de beste chips nog eens voor extra marge verkopen als Threadripper/Epyc. Onder die omstandigheden, en met de problematiek dat AMD effectief maar een fab heeft, zie ik Vega 10 het ondergeschoven kindje worden.

[Dennism]

DaniëlWW2 schreef op donderdag 12 oktober 2017 @ 13:11:
[...]

Ik heb alleen de eerste waarde aangepast naar 14mm, en wafer naar 300mm.

Dan reken je toch met 140mm2 dies of ben ik nu even volledig blond?

Dat laatste wel met je eens trouwens dat Vega momenteel het onderschoven kindje lijkt te zijn.

[DaniëlWW2]

Dennism schreef op donderdag 12 oktober 2017 @ 13:19:
[...]


Dan reken je toch met 140mm2 dies of ben ik nu even volledig blond?

Nee, ik zat niet op te letten. Stupid height.

Dat laatste wel met je eens trouwens dat Vega momenteel het onderschoven kindje lijkt te zijn.

Zijn we het daar over eens.

[Verwijderd]

DaniëlWW2 schreef op donderdag 12 oktober 2017 @ 13:11:
[...]

Ik heb alleen de eerste waarde aangepast naar 14mm, en wafer naar 300mm.

[...]


En daarom denk ik dus dat het Samsung productie is. Die chips moeten ergens gemaakt worden. Verder zal AMD inzetten op marktpenetratie, maar ook niet durven gokken dat ze een gigantische stapel chips laten bakken, die niet verkopen, en ze deze dan moeten dumpen voor verlies. Het zal denk ik een geleidelijk proces zijn, waar ze maar zoveel wafers per maand afwerken voor Vega 10. Voldoende om alle HBM2 chips die ze kunnen krijgen, ook kunnen verkopen, maar niet meer. Blijkt er nu opeens dat Vega 10 naar 12nm gaat, dan ligt het heel anders.

Uiteindelijk denk ik ook dat Vega 10 niet de top prioriteit is voor AMD. Het is een gigantisch per unit margeproduct voor de MI25 en Radeon Pro, gedeeltelijk mislukte chips kunnen worden afgezet als RX Vega 56, en Apple levert wat extra volumeverkopen op. Het blijft alleen een 484mm2 chip, die AMD waarschijnlijk voor een zeer krappe marge verkoopt aan Apple of een AIB, als deze niet geschikt is voor een HPC kaart. Dat staat in schril contrast met Zen chips waar ze zo marges kunnen pakken die meermaals de productiekosten van de chip waren. Dan hebben ze ook nog eens bijna eindeloze binning en schaling bij Zen, of kunnen ze de beste chips nog eens voor extra marge verkopen als Threadripper/Epyc. Onder die omstandigheden, en met de problematiek dat AMD effectief maar een fab heeft, zie ik Vega 10 het ondergeschoven kindje worden.

Nu maar hopen dat de refresh van Vega in februari of maart wat beter gaat, en dat de 'mining'bubble dan is geknapt. Het is dat Nvidia nog steeds weigert om FreeSync te ondersteunen, anders zou ik warempel een Nvidia-kaart overwegen.

[ Voor 4% gewijzigd door Verwijderd op 12-10-2017 22:51 ]

[Olaf van der Spek]

Doet Intel eigenlijk al FreeSync?
Als Intel het ondersteunt en monitoren het standaard gaan ondersteunen..

[ Voor 52% gewijzigd door Olaf van der Spek op 13-10-2017 09:43 ]

[haarbal]

Olaf van der Spek schreef op vrijdag 13 oktober 2017 @ 09:40:
Doet Intel eigenlijk al FreeSync?
Als Intel het ondersteunt en monitoren het standaard gaan ondersteunen..

nee, ze hebben meer dan een jaar geleden gezegd het te gaan ondersteunen maar hebben dat nog niet gedaan.

Ik vrees dat we op de nieuwe hdmi standaard moeten wachten waar een free/g sync achtige refresh in zit.

[DaniëlWW2]

Ik was eens aan het kijken voor wat nieuwe dingen over hardware in het algemeen. Via via kwam ik weer eens bij het meestal goed geïnformeerde digitimes terecht. Kennelijk worden er toch redelijk wat Vega chips klaargemaakt voor Apple, maar dat was niet het opvallende. Nee, dat was dit.

AMD's Vega series GPUs are fabricated by GlobalFoundries on 14nm process, but Taiwan Semiconductor Manufacturing Company (TSMC) has won the order from AMD to fabricate its NAVI GPUs using 7nm process technology. As TSMC is also keen on making deployments in advanced packaging technologies, it will continue to maintain coopetition relationships with local OSATs.

http://www.digitimes.com/news/a20171023PD201.html

Wut? Navi gaat geen GF meer zijn, maar terug naar TSMC?

Het kan nog ook voor H2/2018. TSMC zou al bezig moeten zijn met risico productie, en volle productie zou in H2/2018 moeten draaien.
https://www.anandtech.com...-nm-8-nm-and-6-nm-added/2

Ik denk toch dat de RTG tegen problemen aanliep bij GF. 14nm GF is en blijft een low power node. Dat die behoorlijk goed werkte voor Zen, betekent niet dat het goed werkt voor Vega. Ondertussen is GF wel bezig met een 7nm proces, en twee iteraties hierop, die puur voor AMD bedoeld lijken. Klopt dit dus, dan is Navi er echt al H2/2018, met TSMC haar high performance node, en gaat GF alleen maar Zen doen op een dedicated node.

[Verwijderd]

Het is toch ook mogelijk dat TSMC iets voorloopt op GF en dat AMD alvast TSMC wat laat produceren en later (ook?) GF opdrachten geeft voor Vega op een kleinere node en voor Navi? Misschien eerst enkel high end omdat de capaciteit nog kleiner is en het nog wat duurder is en later een paar segmenten eronder ook? Er was eerder (1-2 maanden geleden) al een gerucht (behandeld door RedGamingTech) dat Navi al uit zou komen in 2018. Het zou me niet verbazen, als het productieproces er klaar voor is. AMD kan het goed gebruiken, de laatste midendkaarten dateren van mei 2016, voor Vega was er geen topsegment, enkel de twee segmenten eronder (1070/1080) en die refresh rond maart is een leuk zoethoudertje maar heel erg veel zoden zet het niet aan de dijk, het gat met de 1080 ti blijft erg groot (15-20?), en dan nog maar zien of dat er dan wel AIC-kaarten komen.

[ Voor 12% gewijzigd door Verwijderd op 23-10-2017 22:41 ]

[DaniëlWW2]

Als Navi een schaalbare architectuur is, dan gaan ze waarschijnlijk werken met een die, met een of twee Graphics Pipelines erop. Vervolgens nog een aantal losse dies, vergelijkbaar met Intel hun EMIB. Anders kan je botweg geen schaalbare GPU maken. Een GPU is veel complexer, en veel gevoeliger voor latency. Het kan niet door meerdere, volledige GPU's op een interposer te plakken zoals met Threadripper of Epyc.

Verder is er een reden dat er altijd een jaar zit tussen "tape-out", het moment dat de chip uitontwikkeld is, en de launch. Dat jaar is nodig om het ontwerp van de chip om te zetten naar de specifieke node, eindeloze te bugtesten of het wel werkt, clocks finetunen en dan productie beginnen en een launch voorraad opbouwen. Je kan absoluut niet even van TSMC naar GF gaan. Dat zou een uiterst langdurig en kostbaar geintje zijn. Absoluut no way dat ze kunnen wisselen tussen twee verschillende fabrikanten, met elk hun eigen node...

[foppe-jan]

http://support.amd.com/en...7.10.2-Release-Notes.aspx

Radeon Software Crimson ReLive Edition 17.10.2 Highlights

Support For

Windows®10 Fall Creators Update
This release provides initial support for the Windows®10 Fall Creators Update. For more information please visit here.
Wolfenstein™ II: The New Colossus
Up to 8% faster performance on Radeon™ RX Vega56 (8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440. (RS-188)
Up to 4% faster performance on Radeon RX 580 (8GB) graphics card than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440. (RS-189)
Destiny 2™
Up to 43% faster performance on Radeon™ RX Vega56 (8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440.(RS-184)
Up to 50% faster performance on Radeon RX 580 (8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440.(RS-185)
Assassin's Creed™: Origins
Up to 16% faster performance on Radeon™ RX Vega56 (8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440.(RS-186)
Up to 13% faster performance on Radeon RX 580(8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 1920x1080. (RS-187)
GPU Workload
A new toggle in Radeon Settings that can be found under the "Gaming", "Global Settings" options. This toggle will allow you to switch optimization between graphics or compute workloads on select Radeon RX 500, Radeon RX 400, Radeon R9 390, Radeon R9 380, Radeon R9 290 and Radeon R9 285 series graphics products.
Compute Support
Radeon Software now supports compute workloads for up to 12 installed Radeon RX 400, Radeon RX 500 or Radeon RX Vega series graphics products on Windows®10 system configurations.

Fixed Issues

Radeon Software may not appear in the uninstall options under "Apps and Features" on Windows® operating systems after a Radeon Software upgrade.
Minor corruption may appear in PLAYERUNKNOWN'S BATTLEGROUNDS™ in some game locations when using Ultra graphics settings in game.
Radeon Wattman may fail to apply user adjusted voltage values on certain configurations.
AMD XConnect™ Technology enabled system configurations may not be detected when plugged in or connected to a system after being previously unplugged during system sleep or hibernation.
Hearts of Iron™ IV may experience a crash or system hang during some scenario gameplay.
Radeon Settings gaming tab may not automatically populate games detected on the users system.

[Reksho]

foppe-jan schreef op dinsdag 24 oktober 2017 @ 10:28:
Destiny 2™
Up to 43% faster performance on Radeon™ RX Vega56 (8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440.(RS-184)
Up to 50% faster performance on Radeon RX 580 (8GB) graphics than with Radeon Software Crimson ReLive Edition 17.10.1 at 2560x1440.(RS-185)

Dat zijn wel hele flinke cijfers zeg. Ik zal het eens zien vanavond

[ Voor 5% gewijzigd door Reksho op 24-10-2017 12:04 ]

[Lord_Dain]

Zo dat is veelbelovend..we gaan het meemaken!!!

[edit]


THAT SHIT IS REAL!!!!!!!!! WTF!
Met de volgende instellingen op een Vega 56:
P6: 1602Mhz/1000mv
P7: 1667Mhz/1025mv
Mem: 950Mhz, 900mv
Energielimiet + 50%

Ter vergelijking, de MSI 1080ti Gaming X doet out of the box 5800.

[ Voor 94% gewijzigd door Lord_Dain op 24-10-2017 21:13 ]