AMD brengt bètadriver uit met optimalisaties voor Project Cars en The Witcher 3

AMD heeft met enige vertraging Catalyst 15.5 bèta uitgebracht, een vernieuwde driver voor AMD-videokaarten. De driver moet afrekenen met de slechte grafische prestaties van AMD-hardware in de games The Witcher 3: Wild Hunt en Project Cars.

De nieuwe Catalyst-driver biedt met name updates aan voor de displaydriver en het Catalyst Control Center, zo meldt AMD. De driver moet volgens de fabrikant aanmerkelijk betere grafische prestaties leveren in The Witcher 3 en Project Cars. Bij The Witcher 3 zouden de prestaties met circa 10 procent stijgen als er een videokaart uit de R9- of R7-serie met één gpu wordt gebruikt. Bij Project Cars zouden de framerates met circa 17 procent toenemen.

AMD heeft ook een optimalisatie-handleiding voor The Witcher 3 uitgebracht. Ook is er een nieuw Crossfire-profiel voor The Witcher 3. Daarnaast adviseert AMD om gamers die Project Cars in een Crossfire-setup willen spelen om anti-aliasing uit te zetten om zo grafische fouten te voorkomen.

Reacties (173)

AA uitzetten onder crossfire? Dat is wel zeer jammer, want de aliasing in pCARS is echt verschrikkelijk afleidend(in de pre-release tenminste) Hopen dat ze dit snel repareren.

@DerwinAero:
Volgens AMD is het als volgt:
[419945] Project CARS: Corruption may be observed if Anti-Aliasing is set to DS2M when run in Crossfire mode. As a workaround we suggest using a different Anti-Aliasing method.

@Seth_Chaos:
Werkt DSR bij jou? Ik krijg zwarte balken langs de rand van mijn scherm..

Ah, dat is toch wel jammer dan, aangezien ik DS2M/DS4M de enige settings vond die echt goed de jaggies weghaalden.

Je kan AA wel aanzetten via CCC (toch??)

AMD doelt erop dat AA in pCARS enorm ten koste van de performance gaat(veel meer dan andere games blijkbaar i.v.m. graphische fouten), dus dit zal ook gelden als je het via de ccc aanzet.

[Reactie gewijzigd door DerwinAero op 29 mei 2015 11:16]

Dan kun je toch die super resolution optie gebruiken waarbij het gerenderd wordt op een veel hogere resolutie en daarna gedownscaled wordt. Ik zie dan geen kartelranden meer.

Beetje lastig als je al op 1440p speelt
Wordt dan wel een beetje erg zwaar.

Een of andere simpele postprocessing aa eroverheen dan, fxaa ofzo?

Volgens AMD's website gaat het om flickering, niet performance.

Juist, maar dan zul je dus alsnog AA uit moeten zetten, en heb je nogsteeds kartelranden.

Tja, dat krijg je als 2 concurrenten eigen 'tools' gaan bedenken voor betere performance, zowel pCars als W3 gebruiken afaik physx, iets wat AMD niet heeft en dus stukje performance gaat kosten. Nvidia heeft op zijn beurt DRS (DSR?), nu pcars bij voorbaat al een 'nvidia project vanaf start is', kunnen ze daar natuurlijk veel meer gebruik van maken.

Mogelijk dat de HDR series van AMD stuk beter zijn, blijf je nog steeds al die extra tooltjes en gimmicks houden waar developers dus op kunnen optimaliseren, betekend automatisch dat de concurrent dus een nadeel heeft. Consoles zie je dit nu ook met de GDDR5/3 en dat extra stukje geheugen op de XBO, ze moeten ergens keuzes maken en dat zal voor 1 van 2 slechter uitpakken.

Tja, dat krijg je als 2 concurrenten eigen 'tools' gaan bedenken voor betere performance

eigenlijk is het maar 1 van de 2. AMD maakt wel tools (tressFX bijvoorbeeld) maar maakt daar dan een open standaard van zodat nvdia er ook gebruik van kan maken en voor kan optimalizeren.

van de andere kant gebeurt dat nooit (en dat is niet overdreven) nvidia geeft NIKS vrij. een mooi voorbeeld is hairworks. precies het zelfde als TressFX, maar dan uitgebracht een jaar nadat tressFX was opengesteld, het doet niks beter als TressFX en voegt daarom dus helemaal niks toe, maar nVidia will het omdat AMD niet kan optimaliseren voor hairworks.

[Reactie gewijzigd door Countess op 29 mei 2015 14:57]

ben 2 jaar geleden na jaren met AMD gespeeld te hebben overgestapt op Nvidia en ben echt tevreden.
lijkt toch allemaal net ff lekkerder te draaien zonder eerst te moeten tweaken

In het geval van Witcher 3 is de waarheid toch iets anders en smeriger dan dat. AMD claimt dat Nvidia expres heeft gezorgd dat Witcher 3 beter presteert op Nvidia-architectuur door bij de ontwikkeling van die game daarop aan te sturen.

http://za.ign.com/the-wit...ely-sabotaged-the-witcher

Of dit precies de volledige waarheid is is een tweede (statement komt van AMD) maar hoe dan ook lijkt het erop dat AMD pas in een zeer laat stadium inzicht heeft gekregen onder de motorkap en daarom qua optimalisatie achterloopt. Het is niet onvoorstelbaar dat Nvidia proactief bezig is geweest om tijdens ontwikkeling van spellen te zorgen dat de game engine goed presteert op hun architectuur.

Nah, De recente Nvidia kaarten presteren een stuk beter dan AMD met Teselation en Physx effecten en laat daar de Witcher 3 hevig gebruik van maken.

Daarnaast zijn er ook gewoon games die geoptimaliseerd zijn voor AMD waarbij ze ook proactief bezig zijn geweest om tijdens ontwikkeling van spellen te zorgen dat de game engine goed presteert op hun architectuur.

De pot verwijt de ketel enzo.

[Reactie gewijzigd door Deem op 29 mei 2015 11:52]

met Teselation en Physx effecten en laat daar de Witcher 3 hevig gebruik van maken.

behalve dat nvidia met name tesselation gebruikt om AMD dwars te zitten en niet om de het visueel mooier te maken.

ze passen bijvoorbeeld 64x tesselation toe op een platte betonnen muur (of een oceaan die niemand ziet, of honden haar, of zoals bij the witcher, op haar). voegt NIKS toe, en kost prestaties op nVidia kaarten, maar dat nemen ze voor lief omdat het AMD meer verlies op levert.

als je in catalyst control center de game limiteert op 8x tesselation is het er visueel niks op achteruit gegaan maar zijn de prestaties wel weer op normaal niveau.

Zie deze vergelijking:

• 8x tesselation
• 16x tesselation
• 64x tesselation

Bron. En dan mag je je eigen conclusies trekken over de motivatie om het standaard op 64 te zetten .

Kan je me zeggen waar het verschil zit ? Ik kan dat namelijk niet meteen zien...

In de haren je ziet het vooral tussen 8x en 16x waar bij 8x je de buigingen van het haar in hoekjes gaan en 16 een stuk smoother.
64 is nog ietsjes maar dat verschil is moeilijker te zien.

De reden waarom AMD de limiet graag op 8-16x legt is omdat hun tessellation pipeline niet schaalt, en bij 10-11x al compleet inzakt qua performance.
Anders hadden ze 32x misschien ook wel als optie genoemd.

Maar bij AMD is er met 32x tov 64x weinig te winnen.
Daarentegen is er bij nVidia weinig te verliezen of je nu 16x, 32x of 64x gebruikt als bovengrens.

Alles staat of valt bij hoe goed je tessellation pipeline schaalt.
Het is net als met AF... Vroeger had je bruteforce-oplossingen die niet schaalden, dus je kon hooguit een waarde van 2x-4x gebruiken zonder al te veel performance-verlies.
Later kwamen er adaptive algoritmen die bepaalden hoeveel AF er nodig was, op basis van de hoeken waaronder de texture op het polygon gemapt werd.
Sindsdien kon je AF eigenlijk altijd wel op de max-waarde van 16x zetten, omdat de hardware er efficient mee omging, en zelden daadwerkelijk tot 16x AF ging. Die paar keer dat dat gebeurde in een frame, was verwaarloosbaar, dus een performanceverschil was er nauwelijks meer met 4x of 8x.

Er is wel een verschil. AMD maakt het Nvidia niet onmogelijk te optimaliseren, hun software is open source, dus Nvidia kan gewoon kijken wat er voor code gebruikt is.
Andersom echter niet, omdat Nvidia hun software gesloten houd.

Nvidia heeft vervolgens een techniek ontwikkeld waardoor ze beter, met minder rekenkracht "haar" effecten kunnen weergeven. Dit is heel mooi, echter gebruiken ze het nu meer om amd lastig te vallen, dan dat ze het gebruiken om zelf winst uit te halen ( ze maken de effecten liever zwaarder, waardoor dit extra negative impact heeft op AMD en maar matige impact heeft op hun eigen kaarten. )

Andersom echter niet, omdat Nvidia hun software gesloten houd.

Erm, hallo... dat doen we niet aan de hand van source code hoor.
Wat men doet is een speciale profiling-laag in de driver gebruiken. Die registreert alle calls met alle parameters, en deze kun je later terugspelen en analyseren.
Bij de DirectX SDK zit al zo'n tooltje, en nVidia en Intel leveren zelf ook eigen varianten ervan:
https://developer.nvidia....ght-visual-studio-edition
https://software.intel.com/en-us/gpa

AMD weet dus *precies* wat de games doen, zonder dat ze daar een letter sourcecode bij nodig hebben.
Sterker nog, alleen de game zelf kan je vertellen wat er *precies* gebeurt. Sourcecode vertelt je niet wat voor geometrie er gebruikt wordt, wat voor textures, hoe vaak per frame, met welke parameters etc. Vrij nutteloos dus.

[Reactie gewijzigd door Scalibq op 29 mei 2015 14:11]

Waarom je gedonwmod word begrijp ik niet, want je hebt zeker een goed punt.

Maar op die manier kun je alle code aflezen die op dat moment word uitgevoerd, echter is dit natuurlijk wel veel omslachtiger, dan dat je gewoon een scherm op en hebt staan met statische code ipv bewegende

Als je gewoon weet welke code gebruikt is, dus open source of niet, kun je daar je drivers voor schrijven.
Het is leuk dat je kan meten wat er gebeurt met bepaalde tools en het zo in kaart brengen ( wat AMD ook zeker zal doen) maar het is nog lang niet zo prettig als gewoon de broncode.

Maar op die manier kun je alle code aflezen die op dat moment word uitgevoerd, echter is dit natuurlijk wel veel omslachtiger, dan dat je gewoon een scherm op en hebt staan met statische code ipv bewegende

Zoals ik zeg, je kunt de command-stream van een game opnemen en afspelen.
In feite zie je dan gewoon de game-code: je ziet welke API-calls er wanneer gebruikt worden, en met welke parameters.
Ook alle shaders etc kun je gewoon zien, en dumps van verschillende framebuffers, meshes etc tijdens het renderen.

Echt, die source code, daar heb je weinig aan bij het analyseren van performance.
Trust me, ik doe dit al jaren.

Oke, ik wil je best geloven, aangezien je er verstand van lijkt te hebben.

Alsnog veranderd dat niet heel erg veel, je kunt dan bijv. zien dat er een bepaalde berekening word uitgevoerd bijv een hoge tesslation op een bepaalde object. Maar als Nvidia efficiënter is met deze berekening dan AMD, kunnen ze alsnog hiermee amd dwarsbomen door dit extra in game's te gooien, en AMD kan dit niet aanpassen lijkt me, omdat het niet opensource is ?

Maar als Nvidia efficiënter is met deze berekening dan AMD, kunnen ze alsnog hiermee amd dwarsbomen door dit extra in game's te gooien, en AMD kan dit niet aanpassen lijkt me, omdat het niet opensource is ?

En wat is het probleem precies?
De ontwikkelaar kan ervoor kiezen om meerdere detailniveaus van een bepaalde feature te hebben, of niet.
In dit geval is het blijkbaar alleen Hairworks aan of uit, niet low/medium/high of iets.
Een GPU-fabrikant zou niets met dergelijke zaken te maken moeten (willen) hebben.

Het zou best kunnen dat men besloten heeft dat het met Hairworks niet interessant was om meerdere detailniveaus te hebben... Misschien omdat er te weinig performancewinst was en/of te veel renderbugs bij minder detail. Dan maar aan/uit.

Helaas is het probleem dat Nvidia invloed gehad heeft in het ontwikkeling proces van de Witcher 3. En een ENORME hoeveelheid tesslation op het haar toegepast schijnt te hebben. Nvidia GPU's kunnen hier efficenter mee omspringen dus hebben zij niet veel last van deze tesselation ( het geeft hun een % fps vermindering) echter dit zijn ze bereid op te offeren omdat ze op deze manier een veel groter FPS verlies bij AMD weten te berijken. Dit trucje is vaker toe gepast en Nvidia lijkt er voorlopig nog niet mee te stoppen.

En daarom is het zo vervelend dat ze alles closed source houden, en dat game ontwikkelaars via "gameworks" technieken integreren in game's zonder dat ze weten wat voor gevolgen dit voor specifieke hw zal hebben.

Nvidia GPU's kunnen hier efficenter mee omspringen dus hebben zij niet veel last van deze tesselation ( het geeft hun een % fps vermindering) echter dit zijn ze bereid op te offeren omdat ze op deze manier een veel groter FPS verlies bij AMD weten te berijken. Dit trucje is vaker toe gepast en Nvidia lijkt er voorlopig nog niet mee te stoppen.

En wat is het probleem?
Dit heet concurrentie. Het juiste antwoord van AMD is komen met een GPU die beter is in tessellation dan nVidia. Daar wachten we nu al 5 jaar op. Zo niet, jammer dan. Ik lig er ook niet wakker van dat nieuwe games niet meer op m'n 3dfx Voodoo draaien. Ofwel je gaat mee in de race, ofwel je wordt achtergelaten. De rest wacht niet op je.
Anders kunnen we ook wel gaan klagen dat de meeste games niet goed op Intel GPUs draaien. En dat het detail van die games maar omlaag geschroefd moet worden.
Zo werkt het niet.

En daarom is het zo vervelend dat ze alles closed source houden, en dat game ontwikkelaars via "gameworks" technieken integreren in game's zonder dat ze weten wat voor gevolgen dit voor specifieke hw zal hebben.

Dat heeft niks met closed/open source te maken.
Het gaat hier puur om een paar parameters ergens in een functiecall. Het is ook puur de keuze van de ontwikkelaar hoe ze deze technologie inzetten.
En reken maar dat die ontwikkelar precies wist wat voor gevolgen dit had voor specifieke hardware. Je dacht toch niet dat ze in een vacuum opereren, en de code nooit op een AMD-GPU hebben getest?

[Reactie gewijzigd door Scalibq op 29 mei 2015 16:37]

Dus jij zou het niet erg vinden als AMD game ontwikkelaars zou puchen visuele effecten te gebruiken die erg leunen op Double precision of parallel computing ? Want dat kan Nvidia weer niet zo goed.

En het zou dus helemaal niet vervelden zijn als AMD het zo zou gebruiken dat zowel de prestatie van AMD zelf als die van Nvidia er onder lijden, enkel om te zorgen dat Nvidia veel slechter zou presteren in die game's ?

lijkt me dat we dan in een situatie komen die alleen maar de game's zelf raakt , die bepaalde game's enkel met merk X kunnen spelen en niet merk Y .

Hoe je het ook went of keert , als alle geruchten kloppen is dit gewoon verkeerd ! Maar goed dat is mijn mening.

Edit: typo

[Reactie gewijzigd door holhuizen op 29 mei 2015 17:18]

Dus jij zou het niet erg vinden als AMD game ontwikkelaars zou puchen visuele effecten te gebruiken die erg leunen op Double precision of parallel computing ? Want dat kan Nvidia weer niet zo goed.

Als het ook daadwerkelijk wat toevoegt aan de game, dan zeker.
En dat kun je hier niet ontkennen... The Witcher 3 ziet er met Hairworks aan toch wel degelijk wat realistischer uit.

Maar met double precision zou ik nou niet direct iets nuttigs kunnen verzinnen.
Mocht dat ooit veranderen, dan zeker, moeten games daar gebruik van maken, en moet nVidia gewoon zorgen dat hun GPUs daar goed in zijn.

Hoe je het ook went of keert , als alle geruchten kloppen is dit gewoon verkeerd ! Maar goed dat is mijn mening.

De geruchten kloppen dan ook niet.
Ten eerste gaat tessellation in Hairworks *tot* 64x, als in: het is een bovengrens, en geen hardcoded minimum zoals men het graag wil brengen.
Ten tweede is er duidelijk verschil te zien als je de tessellation kunstmatig beperkt tot een factor 8x of 16x. Het haar wordt dan blokkerig en de animatie van het haar is ook minder soepel. Dus er is echt wel een reden dat de ontwikkelaars de tessellation niet zo ver hebben afgeknepen als AMD het graag zou zien.

Bij de optie hair ingame staat toch duidelijk Nvidia vermeld? Nvidia heeft speciaal geïnvesteerd in deze techniek PhysX genaamd die oorspronkelijk door NovodeX ontwikkeld is, doorverkocht aan Ageia die met een losse insteekkaart is gekomen die commercieel geflopt is. Waarna Nvidia de boel overkocht en de techniek geïmplementeerd heeft in hun GPU zodat je geen aparte kaart nodig had.

PhysX heeft altijd de optie gehad om ook CPU only te gaan maar met gigantische performance kost tot gevolg.

Akkoord, het zou beter zijn dat er een standaard is voor PhysX maar die is er niet. Beter nog, AMD heeft er geen alternatief voor.

Heb je geen losse PhysX kaart/ Nvidia GPU => performance hit als je dit wil gebruiken, is al sinds 2008 zo. Waarom is dat nu zo een probleem?

En AMD doet gezellig mee met Mantle, BF4, Plants vs Zombies Modern Warfare, Dragon Age: Inquisition, etc
Geen AMD? pech gehad. In dat opzicht nog slechter omdat als je geen AMD hebt, heb je er helemaal niets aan. PhysX kan je wel gebruiken op AMD maar ja, dan kost het je bergen performance.

Als ik het zo lees zou men beter de PhysX permanent uitschakelen als er geen native hardware support is.

Alle fabrikanten hebben altijd al hun eigen standaard willen pushen, dat is de reden dat we vandaag met schijfjes opgescheept zitten (zip drive was een veel beter alternatief maar geen standaard), 60 in 1 lezers om alle memory formaten te ondersteunen om nog maar te zwijgen van al die mini usb waar je het verschil nauwelijks ziet maar toch net niet past.

AMD gebruiker hier overigens waar het als een zonnetje draait zolang ik maar van die hair optie afblijf.

[Reactie gewijzigd door sprankel op 29 mei 2015 21:26]

Akkoord, het zou beter zijn dat er een standaard is voor PhysX maar die is er niet. Beter nog, AMD heeft er geen alternatief voor.

AMD heeft er wel degelijk een alternatief voor, Bullet, wat Open Source is en gebruikt word in bv GTA
Intel heeft hier ook een goed alternatief(beter dan bullet en physx, imho), genaamd Havok, wat in bv Valve's Source Engine gebruikt word, en wel zeer goed draait op CPU

Heb je geen losse PhysX kaart/ Nvidia GPU => performance hit als je dit wil gebruiken, is al sinds 2008 zo. Waarom is dat nu zo een probleem?

Als ik het zo lees zou men beter de PhysX permanent uitschakelen als er geen native hardware support is.

het word nu pas een probleem, omdat je het nu niet meer kan uitschakelen in Project Cars, aangezien de game er voledig rond gebouwd is, en k hoor klachten van mensen met overclockte i5's die geen 30fps kunnen halen met CPU physx

AMD heeft er wel degelijk een alternatief voor, Bullet

Ten eerste is dat niet van AMD. Het is open source, en opgezet door een ontwikkelaar van Sony.
Ten tweede is Bullet geen alternatief. Het is 'een physics library', en het heeft 'wat GPGPU routines', maar het kan zich qua functionaliteit echt niet meten met Havok en PhysX.

Intel heeft hier ook een goed alternatief(beter dan bullet en physx, imho), genaamd Havok, wat in bv Valve's Source Engine gebruikt word, en wel zeer goed draait op CPU

Havok heeft geen GPGPU-acceleratie, en is dus niet geheel vergelijkbaar met PhysX.
Hierdoor wordt Havok ook anders toegepast in games. In PhysX games heb je nog wel eens extra detaillevels die alleen voor GPU geschikt zijn. Je kunt ze in theorie wel op de CPU draaien, maar daar heb je de processing power niet voor, dus levert dat onspeelbare framerates op.
Bij Havok heb je die optie niet, dus zal ieder detaillevel altijd ontwikkeld zijn met de CPU als target.

Ten eerste is dat niet van AMD. Het is open source, en opgezet door een ontwikkelaar van Sony.

hier heb je idd gelijk in, de main developper werkte eerst bij sony, daarna bij amd, maar volgens wikipedia werkt hij nu bij google, dus bullet is idd niet van AMD, mijn excuses hiervoor

Havok heeft geen GPGPU-acceleratie, en is dus niet geheel vergelijkbaar met PhysX.

havok heeft ondertussen wel al een tijdje openCL accelleration voor bepaalde delen, al is het idd niet zo uitgebreid als bij nvidia's physx

Hierdoor wordt Havok ook anders toegepast in games. In PhysX games heb je nog wel eens extra detaillevels die alleen voor GPU geschikt zijn. Je kunt ze in theorie wel op de CPU draaien, maar daar heb je de processing power niet voor, dus levert dat onspeelbare framerates op.

echter heeft havok ook dingen die physx niet heeft; zie http://www.havok.com/products/
persoonlijk vind ik dat je een compromis moet maken tussen speelbaarheid en physics, en dat vind ik dat havok veel beter doet dan physx, die wel meer geavanceerde physx heeft, maar in realiteit merk je er weinig van terug in games, behalve de enorme hit op je CPU als je geen nvidia draait, en als je kijkt naar hoe hard de physics systemen ooit falen in physx games, zoals watch-dogs en assassin's creed unity, vind ik (persoonlijk) havok een veel betere keuze, en denk ik dat nvidia misschien meer moet focussen op physx effecten die goed geimplementeerd zijn, ipv meer effecten die maar half tegoei werken, Havok mag technisch gezien simpeler zijn dan physx, maar wel stabieler, en maakt veel minder flaters in de physics dan physx (judging from modern games released with them)
daarbuiten, draait physx in project cars zowizo niet op de GPU(volgens de developpers), wat dus gans het voordeel van physx(in dit voorbeeld) eruit haalt, aangezien nu iedereen het op de CPU moet draaien, ook eigenaars van nvidia kaarten

[Reactie gewijzigd door jeroen7s op 1 juni 2015 15:05]

hier heb je idd gelijk in, de main developper werkte eerst bij sony, daarna bij amd, maar volgens wikipedia werkt hij nu bij google, dus bullet is idd niet van AMD, mijn excuses hiervoor

Voor zover ik weet, heeft hij nooit voor AMD gewerkt.
Hij heeft overigens ook steun van nVidia gehad in de vorm van videokaarten en vroege toegang tot OpenCL/Cuda drivers/tools.

havok heeft ondertussen wel al een tijdje openCL accelleration voor bepaalde delen, al is het idd niet zo uitgebreid als bij nvidia's physx

Heb je daar een bron voor? Ik weet alleen dat er ooit een vage OpenCL-demo geweest is op AMD-hardware (code nooit gereleased), maar na de overname door Intel is daar nooit wat mee gedaan.

echter heeft havok ook dingen die physx niet heeft; zie http://www.havok.com/products/

Kun je iets specifieker zijn?

en dat vind ik dat havok veel beter doet dan physx

Maar die keuze is niet aan Havok danwel PhysX, maar aan de mensen die de levels ontwerpen, en bepalen hoeveel objecten er onderhevig zijn aan physics, en in hoeveel detail etc er gesimuleerd wordt.

Wat doncuomo onder mij ook al schrijft: AMD's software is open source en dat van Nvidia niet, lastig om zo te kunnen optimaliseren...

Ik kan me overigens niet herinneren dat er vroeger (een paar videokaartgeneraties eerder) bij elke nieuwe game elke kaartfabrikant nieuwe drivers moest gaan uitgeven, vreemd hè? Je zou denken dat coders rekening houden met de hardware middels instellingen, maar onlangs schreef een coder mij dat ik maar een Nvidia moest kopen om software optimaal te kunnen gebruiken...

De grootste reden dat er specifieke drivers zijn is dat de GPU fabrikanten weten dat hun prestaties worden gemeten met de performance van AAA-titels. Dus plaatsen ze specifieke optimalisaties in hun drivers voor iedere AAA-titel.

Alle NVIDIA onderdelen zijn gewoon optioneel, ja het klopt dat AMD wat makkelijker is in het delen van hun code dan NVIDIA, maar uiteindelijk kan de code van AMD en NVIDIA prima naast elkaar draaien, danwel automatisch de juiste libraries gekozen worden aan de hand van je hardware.

En je hebt een goed punt trouwens, vroeger had je bijna nooit een nieuwe driver nodig, vandaag de dag is er voor 70% van de console ports weer een driver update nodig om de boel een beetje te laten draaien.

Het probleem is gewoon dat game developers zo veel luier zijn geworden, games worden gemaakt voor consoles (die 1-5 configuraties hebben en dan houd het wel weer op) en vervolgens even snel gepoort voor PC (die miljoenen configuraties hebben) en vervolgens mag de driver de problemen oplossen, [sarcasm] want aan de developers ligt het natuurlijk niet.. [/sarcasm]

Valt in de praktijk wel mee, ik meen zelfs dat TW3 op AMD beter draait dan op Nvidia. TW3 is gewoon ontwikkeld voor consoles (AMD GPU) en daarna geport naar de PC. Niet zo vreemd dat het (ondanks smerige truukjes van Nvidia - hairworks bijvoorbeeld) toch beter loopt op AMD GPU's.

Onjuist, Het ontwikkelplatform voor de Witcher 3 was de pc.
Dat blijkt uit de E3 beelden waarbij grafisch nog een stap verder ging dan de uiteindelijke game en uit de verklaring van de ontwikkelaar zelf.

Mensen is dit verschil in E3 beelden en release ingame beelden gaan opvallen. De ontwikkelaar heeft hierop gereageerd door te stellen dat in de ontwikkelfase onbekend was wat de specs zijn van de nieuwe consoles. Toen uiteindelijk bekend werd dat de consoles minder krachtig waren als verwacht hebben ze de boel gedownscaled.

Wat ik wel wil toevoegen is dat het inmiddels met deze patch wel klopt dat het spel gewoon degelijk draait op AMD-kaarten. Ik heb zelf een 7970, en na patch en hun suggesties (fullscreen, anti-aliasing uit) kan deze kaart 1080p@High aan. Wat me niet tegenviel van mijn beestje..

Wat ik me van het downscale-debat ook herinner is dat de programmers benadrukten dat het bij de E3-versie ging om een zeer klein terrein waarop gerenderd werd. In een grote wereld was dit sowieso volgens hen al niet haalbaar, consoles of niet. Of dat de E3-tentoonstelling misleidend maakte is aan ieders persoonlijk inzicht om te bepalen..

het feit dat je bijvoorbeeld bij the witcher de game met catalyst control center kan limiteren op 8x tesselation en dat er dan visueel NIKS veranderd maar de prestaties gewoon weer in lijn zijn met wat je zou verwachten maakt gewoon meteen duidelijk dat wat je beweert niet kopt en dat AMD gewoon gelijk heeft.

nvidia forceert 64x tesslation op dingen waar dat TOTAAL niet voor nodig is, en helemaal niks toe voegt, wat ze zelf ook prestaties kost, maar als het AMD maar meer kost nemen ze dat voor lief.

Of het ligt gewoon aan de AMD drivers. Het blijft een zwak punt bij ATI.

stel, beide campen hebben 2 even goede driver team van de zelfe grote.

drivers zouden daarom ongeveer gelijk van kwalitied moeten zijn.

nu begint een camp continue barricades op te werken voor het andere team met als enige doel de performance verlagen of artifects te creeren bij het andere team.

de drivers van dat team LIJKEN nu beter. en het andere team is nu ook nog eens veel onnodige tijd kwijt aan het proberen te omzeilen van die barricades

en dan zijn mensen zo dom om dat team de hemel in de prijzen omdat ze betere drivers zouden hebben.

jouw manier van denken beloond nvidia voor hun verwerpelijke gedrag dat zelfs hun eigen klanten schaad.

overigens de tesselation performance heeft NIKS met drivers te maken, enkel met een andere aanpak in de hardware. tot 8x tesselation is AMD meer als 50% sneller als nvidia, en pas bij 11x is het overslag punt.

de keuze van nvidia om op veel objecten 64x tesselation toe forceren is enkel en alleen om deze reden, en heeft opnieuw NIKS met AMD's drivers te maken.

[Reactie gewijzigd door Countess op 30 mei 2015 11:24]

Behalve dat amd driver team lang niet zo groot is als nvidia. NVIDIA is veel groter als dat.

dat maakt het alleen maar nog erger.

overigens de tesselation performance heeft NIKS met drivers te maken, enkel met een andere aanpak in de hardware. tot 8x tesselation is AMD meer als 50% sneller als nvidia, en pas bij 11x is het overslag punt.

Dat is dus het probleem van AMD: de D3D/OGL specs definieren tessellation factors tussen 1x en 64x.
Als je dan hardware ontwerpt die bij 11x al geen goede performance meer kan leveren (dat 'omslagpunt' is dus een exponentiele dip), dan doe je simpelweg iets fout.

Ach jee de drivers krijgen we die 10 jaar oude mythe weer.

Neuh, Het ligt aan het NVIDIA games support programma waarbij express dingen onnodig geforceerd worden die zelfs ten koste gaan vd 6xx series van Nvidia. Als je 680 even goed presteert als een 760 dan weet je dat er dingen gewoon niet kloppen......

Game Dev's krijgen een sloot met geld ( tot ca 5miljoen$ ) als hun games zo'n beetje vendor locked worden ( op Nvida 7xx kaarten ), AMD krijgt zelfs geen toegang krijgen tot de game devs volgens de contracten. AMD kan dus voor de release niets doen........

Slechte ontwikkeling voor de PC Gaming scene.

x8 zie je wel hoor.

bij 8x zie je het verschil idd nog wel, echter bij 16x moet je echt al moeilijk gaan doen om het verschil met 64x te zien
bron vergelijking:
http://wccftech.com/amd-a...tessellation-performance/

dus iemand die geld krijgt van nvidia (zie sponsoring overal in het spel) zegt dat wat amd zegt niet klopt ?


mmmm andere bronnen ?

Er zijn al jaren games met een NVIDIA (of net zo goed een AMD) introtje en logotjes her en der, maar ik heb (tot nu toe dan) nog nooit meegemaakt dat degene die niet genoemd word publiekelijk begint te huilen dat ze tegengewerkt worden, wat natuurlijk gewoon onzin is, bij Project Cars en Witcher 3 hebben ze gewoon gekozen om NVIDIA functionaliteit te gebruiken, die misschien niet werkt als je AMD hardware hebt, oke, jammer, maar dat is wat anders dan dat ze AMD tegenwerken, dat is gewoon aanstellerij.

ken je het hairworks systeem van amd: tressFX hair 3.0
dit werkt zowel beter op amd en nvidea kaarten maar nvidea heeft project red gepushed toch nvidea hairworks te gebruiken, een systeem waarop nvidea 5% slechter werkt maar amd 15%. hiermee hebben ze dus 10% winst in fps tenopzichten van de conncurent maar uiteindelijk komt het niemand van de consumenten tengoeden.

amd is nog naar project red gegaan om te vragen om toch nog hair fx te implementeren maar volgens hun was het daar al telaat voor. (zou me niks verbazen als ze een contract hadden met nvidea waarin stond dat dit niet mocht)

eff een link erbij voor de graph : http://wccftech.com/cd-pr...ed-amd-tressfx-witcher-3/
Edit: eff de naam verbetered van amd haar ding

[Reactie gewijzigd door Eternal Sidus op 29 mei 2015 14:53]

die procenten zijn tenopzichten van TressFX hair 3.0 dat hetzelfde of beter eruit ziet. kijk naar tombraider reboot bijvoorbeeld.

dus je hebt hetzelfde of minder mooi en slechteren prestaties

TressFX en Hairworks doen zeker niet hetzelfde, en zien er zeker ook niet hetzelfde uit.

[Reactie gewijzigd door Scalibq op 29 mei 2015 14:58]

ze doen toch zeker wel hetzelfde en ze zien er inderdaad niet hetzelfde uit. ze doen allebei zorgen dat elke of bijna elke haar apart wordt gerenderd en word beinvloed door physics ze hebben allebei een anderen techniek en het is tot de consument welke je het mooiste vind. ikzelf vind niet zo verschil ertussen zitten ze zijn anders maar allebei mooi. maar aangezien hairworks op allebei de merken slechter werkt kies ik dan toch TressFX hair als ik developer zou zijn.

Ik heb er nog niet teveel op ingelezen, maar zoals ik het zag was het ongeveer zo:

AMD geeft voor hun software de code vrij zodat NVIDIA hun dingen daarop kunnen aanpassen.

NVIDIA geeft hun code niet vrij en daarom lopen AMD kaarten zo brak op sommige spellen.

Ik was een beetje op reddit aan het rondneuzen en kwam tot die conclusie. Als iemand het beter weet of hier op weet aan te vullen hoor ik het graag!

Ben er niet zeker van of open proprietary vs opensource het probleem is. Het probleem is eerder de beperkte tijd die AMD schijnbaar heeft gekregen om met optimale drivers te komen.
Voor AA, dat bij AMD een probleem is, heeft CD Projekt RED een eigen ontwikkelde post-process anti-aliasing oplossing gebruikt. Dat staat dus los van closed code optimalisaties van GPU fabrikanten.

To tackle jagged edges, CD Projekt RED has developed their own post-process anti-aliasing solution, as hardware anti-aliasing techniques such as MSAA and TXAA are incompatible with REDengine 3's renderer. This unnamed post-processing technique operates with a level of fidelity similar to FXAA, but with an added temporal anti-aliasing component to reduce the crawling and shimmering of anti-aliased edges when the camera or player's viewpoint is in motion.

Dat bijvoorbeeld HairWorks zoveel Tesselation gebruikt speelt ook mee. Het is uiteidelijk een technologie voor Nvidia kaarten, veel van die kaarten doen ook beter tessalation dan de GCN architectuur van AMD.

Ja, en AMD heeft geen idee wat er nu weer verwacht wordt van hun kaarten, en kan dus achter NVidia aanhollen, wachtend op wat ze nu weer voor konijn produceren uit de hoed. Ze weten pas dat er iets is als het spel uit is, dus da's niet helemaal fair, gezien alles gereviewed wordt als het fris uitgebracht is, met hardware en drivers die dan bekend zijn... aka een achterstand voor de rooien.

Ja, en AMD heeft geen idee wat er nu weer verwacht wordt van hun kaarten

Alles wat je redelijkerwijs kunt verwachten volgens de OGL/DX-standaarden.

Nope, want iets als Crysis 2 met z'n onzichtbare tesselation-zee onder elke map staat niet in de standaarden, is niet praktisch, en dient totaal geen nut behalve het leven zuur maken voor AMD-kaarten omdat AMD deze ronde minder inzet op tessel. Als een spelmaker opeens overal double precision-rekenwerk op GPUs ging doen ging NVidia gruwelijk hard onderuit. Doen we ook niet, hoewel het wel mag en kan.

Ja ok, maar zo zijn er weer andere zaken aan te wijzen waar AMD gpu's al langere tijd rondjes rennen om de nVidia kaarten...
Zoals gezegd blijft het een keuze van AMD/nVidia waar ze het meest op in zettten.
Dat gezegd hebbende is nVidia er niet vies van al dan niet softwarematig features te beperken of door middel van vendor lock-in hun eigen kaarten het best uit de verf te laten komen, ondaks dat dit voor de eindgebruiker nagenoeg geen visueel verschil opleverd.
De gruchten gaan dan ook vaak dat nVidia niet schroomt hier extra voor te betalen... Dat klinkt mij dan ook meer als oneerlijke concurentie en niet meer zozeer als gezonde concurentie...

Zoals gezegd blijft het een keuze van AMD/nVidia waar ze het meest op in zettten.

En AMD heeft dus een slechte keuze gemaakt, en wordt daar nu op afgerekend.
Tijd om de keuze om te gooien en met een goede architectuur te komen.

Dat gezegd hebbende is nVidia er niet vies van al dan niet softwarematig features te beperken of door middel van vendor lock-in hun eigen kaarten het best uit de verf te laten komen, ondaks dat dit voor de eindgebruiker nagenoeg geen visueel verschil opleverd.

Ten eerste zijn een hoop van die claims direct afkomstig van de FUD-campagne van AMD's Richard Huddy, en gewoon pertinent onwaar.
Ten tweede, AMD is er ook niet bepaald vies van... Die betalen ontwikkelaars om de AMD-only Mantle API te gebruiken om hun eigen kaarten en CPUs beter uit de verf te laten komen.
Ze laten zelfs speciaal benchmarks ontwikkelen als StarSwarm, met de meest gruwelijk slechte DX11-code ooit, om mensen te misleiden dat Mantle zo geweldig is.
Vind je dat gezond?

Ondanks of die claims gegrond zijn of niet maakt mijn persoonlijke ervaring met nVidia ze voor mij wel geloofwaardiger...

Een aantal voorbeelden van mijn persoonlijke ervaringen:

- Virtual machines: De drivers van nVidia checken actief of er bepaalde virtuale extenties gebruikt worden (o.a. hyperV en KVM) en weigert in dat geval geforce kaarten te starten. Als je deze extensien uitzet of hide, of je de geforce kaart kan laten herkennen als quadro werkt het allemaal perfect. En ondanks dat nVidia bij hoog en bij laag beweerd dat ze het niet actief weren, komen er bij iedere driver update meer muren die dit verder in proberen te perken...

- PhysX: Hybrid PhysX werkt ook perfect als de drivers dit niet actief zouden weren... Persoonlijk zou ik nooit een main nVidia kaart kopen alleen omwille van PhysX, echter ben ik zeker wel bereid een lower end nVidia kaart aan te schaffen voor dedicated PhysX. Door dit actief te weren loopt nVidia in mijn geval alleen maar geld mis.
Daarnaast is er nog het grote verschil tussen PhysX SDK 2 en SDK 3. Speerpunt van de PhysX SDK 3 die al in 2011! is gelanceerd: multithreading support voor cpu's.
Metro 2033 redux was de eerste commerciële titel die gebruik maakte van PhysX SDK 3 voor zover ik weet. En gezien de korte tijd tussen metro 2033 last light en redux kan je mij niet vertellen dat de adaptatie van PhysX SDK 3 bijna 4 jaar heeft moeten duren... Als je het verschil in performance bekijkt met advanced PhysX tussen beide games, zal je zien dat in metro redux er nagenoeg geen performance hit meer is bij PhysX op de cpu, zelfs op mijn FX8350. Terwijl als je ditzelfde probeert op welke cpu dan ook met de PhysX SDK 2 hou je geen framerate meer over. Punt blijft dat het voor nVidia totaal geen commercieel belang heeft om de SDK 3 eerder te pushen, aangezien het alleen grote verschillen oplevert bij gebruik van PhysX op de cpu, waardoor de reden om een nVidia kaart aan te schaffen voor PhysX alleen maar afneemt. Dit terwijl PhysX in de afgelopen jaren nog steeds niet echt van de grond is gekomen.

- Als laatste probeerde ik laatst de "Endless city" demo te draaien, om te kijken hoe dat zou draaien op mijn AMD gpu. Wat bleek? De software weigert te starten als je geen nVidia main gpu in gebruik hebt... Voor een tesselation showcase vind ik dat toch vreemd... Wat heeft nVidia er voor belang bij die showcase te blokkeren voor andere kaarten?

Nogmaals voor alle bovenstaande voorbeelden geldt dat het nVidia's goed recht is om dit te blokkeren, alleen pretenderen ze in veel gevallen het niet actief te blokkeren terwijl alles er op wijst dat ze dit wel degelijk doen. Ook heeft het alleen maar nadelige gevolgen voor de consument zonder dat het veel oplevert voor nVidia.

Bovenstaande persoonlijke ervaringen en uitlatingen als deze zetten mij toch wel aan het denken...

Vendor A is also jokingly known as the "Graphics Mafia".

Wat gezien de rest van de context in de blog het meest overeen komt met nVidia.

Daarnaast heeft AMD altijd aangegeven dat het iedere producent vrij staat de Mantle api te implementeren. En wat je nu ook ziet gebeuren aangezien er een hoop dingen vanuit Mantle zijn opgegaan in de nieuwe OpenGL versie "Vulkan".

Als het inderdaad waar blijkt te zijn dat AMD expres brakke DX11 code heeft laten schrijven om Mantle te promoten keur ik dat ook zeker niet goed. Echter gaat het dan nog steeds over een benchmark. Bij Battlefield 4 hebben we zelf kunnen concluderen hoe effectief Mantle was in real life.

[Reactie gewijzigd door Spekkie88 op 1 juni 2015 10:34]

Een aantal voorbeelden van mijn persoonlijke ervaringen:

Die 'ervaringen' zijn wel voorbeelden van nVidia die z'n *eigen* software/hardware beperkt. Terwijl de discussie hier ging over het weren van AMD-hardware in games waar nVidia aan heeft meegewerkt.

Daarnaast is er nog het grote verschil tussen PhysX SDK 2 en SDK 3. Speerpunt van de PhysX SDK 3 die al in 2011! is gelanceerd: multithreading support voor cpu's.
Metro 2033 redux was de eerste commerciële titel die gebruik maakte van PhysX SDK 3 voor zover ik weet. En gezien de korte tijd tussen metro 2033 last light en redux kan je mij niet vertellen dat de adaptatie van PhysX SDK 3 bijna 4 jaar heeft moeten duren...

Er is nogal een verschil tussen het herschrijven/uitbreiden van een library/SDK en het gebruik ervan.
Vergelijk het met een nieuwe versie van Windows. Microsoft werkt daar een paar jaar aan, maar vrijwel alle applicaties draaien er direct op, omdat de API zelf niet of nauwelijks is veranderd.

- Als laatste probeerde ik laatst de "Endless city" demo te draaien, om te kijken hoe dat zou draaien op mijn AMD gpu. Wat bleek? De software weigert te starten als je geen nVidia main gpu in gebruik hebt... Voor een tesselation showcase vind ik dat toch vreemd... Wat heeft nVidia er voor belang bij die showcase te blokkeren voor andere kaarten?

Weinig, maar ze hebben er ook geen belang bij om support te gaan leveren op die benchmark voor andere hardware.
Maar ik was het met je eens, dus heb ik een patch ontwikkeld om de benchmark op alle DX11-hardware te draaien: https://scalibq.wordpress...ellation-demo-on-radeons/

Daarnaast heeft AMD altijd aangegeven dat het iedere producent vrij staat de Mantle api te implementeren. En wat je nu ook ziet gebeuren aangezien er een hoop dingen vanuit Mantle zijn opgegaan in de nieuwe OpenGL versie "Vulkan".

Tsja, nVidia heeft ook altijd gezegd dat ze ervoor open staan dat andere fabrikanten PhysX gaan implementeren. Ik vind het nogal nietszeggend.
Het verschil is natuurlijk dat PhysX nog waarde heeft, en Mantle niet.
Zodra PhysX net zo irrelevant wordt als Mantle, zal nVidia het waarschijnlijk ook wel 'doneren' aan Khronos als open standaard.

Als het inderdaad waar blijkt te zijn dat AMD expres brakke DX11 code heeft laten schrijven om Mantle te promoten keur ik dat ook zeker niet goed.

Dat staat inderdaad vast. Zoals ik elders al zei, er zijn genoeg tools om API calls te analyseren. Als je StarSwarm draait, zie je dat ze ENORM lange command queues opbouwen, waar je drivers gegarandeerd van over de zeik gaan (vooral die van AMD). Zonder enige aanwijsbare reden... Ze maken gewoon een worst-case voor DX11: heel veel calls die zo weinig mogelijk renderen, en dat dan ook nog eens met deferred contexts, zodat de drivers het intern moeten gaan bufferen.

nVidia heeft een aantal patches aan hun drivers gedaan, speciaal voor StarSwarm, en dat maakt een gigantisch verschil.

Bij Battlefield 4 hebben we zelf kunnen concluderen hoe effectief Mantle was in real life.

Yup, een HEEL stuk minder dan in StarSwarm, omdat BF4 *wel* normale DX11-code gebruikt.

Waar het mij meer om gaat is de mentaliteit van nVidia als bedrijf. Ondanks dat ik me

Er is nogal een verschil tussen het herschrijven/uitbreiden van een library/SDK en het gebruik ervan.
Vergelijk het met een nieuwe versie van Windows. Microsoft werkt daar een paar jaar aan, maar vrijwel alle applicaties draaien er direct op, omdat de API zelf niet of nauwelijks is veranderd.

En dat is dus juist mijn hele punt, de PhysX 3 SDK is al in 2011 geleased door nVidia als zijnde klaar en bruikbaar.
En nog heeft het bijna 4 jaar geduurd voor de eerste games uitkwamen die daadwerkelijk gebruik maakte van deze SDK...

Het verschil is natuurlijk dat PhysX nog waarde heeft, en Mantle niet.
Zodra PhysX net zo irrelevant wordt als Mantle, zal nVidia het waarschijnlijk ook wel 'doneren' aan Khronos als open standaard.

Zo irrelevant is Mantle nou ook weer niet. Mantle is ontwikkeld om overhead te reduceren net als bij DX12 de insteek is.
Zo zie je bijvoorbeeld dat er veer meel draw calls verwerkt kunnen worden onder DX12. Of dit direct nuttig is voor de FPS blijft afwachten, maar beide API's proberen de huidige "knelpunten" te adresseren, zodat deze niet voor problemen zorgen in de toekomst.

Weinig, maar ze hebben er ook geen belang bij om support te gaan leveren op die benchmark voor andere hardware.

Ik ben het ook zeker eens dat het voor nVida geen meerwaarde heeft om support te leveren op iets anders dan hun eigen hardware. Maar er is een wezenlijk verschil tussen geen support leveren en actief weren.
En mijn persoonlijke ervaring bij nVidia is dus dat er actief geweerd wordt.

Waar het mij meer om gaat is de mentaliteit van nVidia als bedrijf.

Een bedrijf is een bedrijf. Ze werken allemaal hetzelfde.

En dat is dus juist mijn hele punt, de PhysX 3 SDK is al in 2011 geleased door nVidia als zijnde klaar en bruikbaar.
En nog heeft het bijna 4 jaar geduurd voor de eerste games uitkwamen die daadwerkelijk gebruik maakte van deze SDK...

Ik snap je punt niet? Dat ligt toch niet aan nVidia? Zij maken die SDK beschikbaar. Wie die SDK wel of niet gebruikt, daar heeft nVidia geen controle over.
Ik bedoelde dat je gewoon de PhysX runtime kunt updaten naar de nieuwere versies met SSE2-optimalisaties en dergelijke, en dan maken games er gebruik van.

Zo irrelevant is Mantle nou ook weer niet.

Het werkt op een handjevol GPUs in een handjevol games, waar het niet spectaculair veel toevoegt qua performance, en in sommige gevallen zelfs trager is dan DX11.

Zo zie je bijvoorbeeld dat er veer meel draw calls verwerkt kunnen worden onder DX12. Of dit direct nuttig is voor de FPS blijft afwachten, maar beide API's proberen de huidige "knelpunten" te adresseren, zodat deze niet voor problemen zorgen in de toekomst.

Wat dus weinig met Mantle te maken heeft, behalve als je het marketingverhaal van AMD slikt dat er geen DX12 op komst was, en dat Microsoft zich 'ineens' bedacht heeft toen AMD met Mantle kwam.
Ik zit zelf in het DX12 early access programma, en werk dus zelf mee aan de ontwikkeling van DX12. Ik weet wel wat er wel en niet waar is van het verhaal van AMD.

Ik ben het ook zeker eens dat het voor nVida geen meerwaarde heeft om support te leveren op iets anders dan hun eigen hardware. Maar er is een wezenlijk verschil tussen geen support leveren en actief weren.

Het 'actief weren' is waarschijnlijk standaard policy bij nVidia demos.
Het enige doel is om te laten zien wat nVidia-hardware kan.
Ook AMD heeft vaak genoeg demos gereleased die niet werken op andere hardware, soms ook met actieve vendor-checks.

Dus ja, laat je niet teveel meeslepen in het Calimero-verhaal dat AMD predikt. AMD is geen haar beter dan nVidia. nVidia heeft alleen veel meer macht dan AMD. Op momenten dat AMD/ATi meer macht had (zoals het Radeon 9x00/GeForce FX-tijdperk), deden ze ook allerlei dingen waar ze nu nVidia van beschuldigen.

[Reactie gewijzigd door Scalibq op 1 juni 2015 11:49]

Maar het actief weren gaat dus veel verder dan alleen bij demo's.
En mocht dat in loop van de tijd weer omslaan zal ik net zo hard weer naar de kant van nVidia lopen. Echter is het op dit moment voor mij een reden om bij nVidia uit de buurt te blijven.
Desondanks kan ik me zeer zeker verwonderen over hardware die ze leveren.

En ondanks dat PhysX wellicht meerwaarde bied, wordt het nagenoeg nog steeds niet gebruikt omdat het niet cross platform is. En juist daarom snap ik de keuze van nVidia niet om geen hybrid PhysX toe te staan...

Maar het actief weren gaat dus veel verder dan alleen bij demo's.

Heb je daar een (recent) voorbeeld van dan?

Echter is het op dit moment voor mij een reden om bij nVidia uit de buurt te blijven.

Ik zou eerder bij AMD uit de buurt blijven. Dat moddergooien naar Intel en nVidia, terwijl ze zelf gewoon inferieure hardware leveren, begint zeer vermoeiend te worden.
En dan nog eens die Mantle-campagne eroverheen, met smerige trucs als StarSwarm...
Laat ze eerst maar eens met goede hardware komen.

En ondanks dat PhysX wellicht meerwaarde bied, wordt het nagenoeg nog steeds niet gebruikt omdat het niet cross platform is. En juist daarom snap ik de keuze van nVidia niet om geen hybrid PhysX toe te staan...

Wat bedoel je met 'cross-platform'? Want PhysX is wel degelijk cross-platform, het draait ook op consoles, linux, OS X, iOS en Android.
De meerwaarde zit hem er juist in dat je alleen op nVidia GPUs acceleratie hebt. Dat wil nVidia niet veranderen natuurlijk.

Ja, ok het is theoretisch cross platform, maar pas sinds de SDK 3 ook daadwerkelijk bruikbaar zonder hardware acceleratie vanuit nVidia. En dan zie je ook ineens dat het voordeel van die hardware acceleratie grotendeels teniet wordt gedaan, mits je een stevige cpu hebt.

De recente voorbeelden heb ik hierboven ook al gegeven.
Het niet toestaan van hybrid PhysX en het checken op hyperV en KVM extensies.
Allen onder het mom dat het zogenaamd ten goede zou komen aan de gebruikers ervaring van de consument.
Als je echter een geforce kaart zodaning mod dat deze wordt herkend als een gelijkwaardige quadro (je veranderd alleen de naam, verder niets) blijkt dat geforce kaarten perfect werken binnen VM's. Of als je de hyperV extensies uitschakelt (ten koste van performance) en KVM hide werken de kaarten ook ineens prima.
En ondanks dat nVidia vermeld dat het gaat om een "bug" die ze niet van plan zijn te fixen (koop dan maar een quadro) waar ik het prima mee eens ben, blijkt dat er bij recentere updates van de drivers alleen maar meer herkend en geblokkeerd wordt op deze manier. Zo was het namelijk eerst alleen KVM en nu ook ineens HyperV... Ik persoonlijk noem dat actief weren en niet bijdragen aan de "beste ervaring" voor de consument.

Bij AMD het moddergooien ben ik het ook niet mee eens, maar daar kan ik als consument voor kiezen het te negeren. Het doet namelijk niets af aan mijn gebruikers ervaring als consument.
Tot nu toe is nVidia voor mij als consument zijnde zich in bochten aan het wringen mij als consument te beperken in wat ik wel en niet mag met hardware ondanks dat die er perfect toe in staat is.
Dat ze zeggen het niet te ondersteunen en als je wel ondersteuning wil je maar een quadro moet kopen, prima.
Maar wat ze nu doen is beweren dat ze het niet ondersteunen, maar daarnaast ook nog actief ondermijnen. Waardoor ik als consument er hinder van ondervind.
Nogmaals dat is inderdaad het goed recht van nVidia, maar ik ben het daar niet mee eens.

Ja, ok het is theoretisch cross platform, maar pas sinds de SDK 3 ook daadwerkelijk bruikbaar zonder hardware acceleratie vanuit nVidia.

Helemaal niet.
Sterker nog, het is ooit als CPU-only library begonnen (NovodeX), en physics-acceleratie is pas toegevoegd toen Ageia de library overname en aanpaste aan hun PPU-hardware.

En dan zie je ook ineens dat het voordeel van die hardware acceleratie grotendeels teniet wordt gedaan, mits je een stevige cpu hebt.

Helemaal niet.
De snelste GPUs kunnen nog absoluut niet in de buurt komen van wat een high-end GPU aan physics-workload kan verwerken.

De recente voorbeelden heb ik hierboven ook al gegeven.
Het niet toestaan van hybrid PhysX en het checken op hyperV en KVM extensies.

Nee, dat had ik al gezegd, daarmee weren ze *hun eigen* producten. Je had het net over het weren van producten van *concurrenten*:

Maar het actief weren gaat dus veel verder dan alleen bij demo's.

In demo's worden concurrenten geweerd. Jij zegt dat het 'veel verder gaat', dus vraag ik voorbeelden van waar nVidia hun concurrenten weert in andere software dan demo's?

Tot nu toe is nVidia voor mij als consument zijnde zich in bochten aan het wringen mij als consument te beperken in wat ik wel en niet mag met hardware ondanks dat die er perfect toe in staat is.

Dat is een onzin-argument. Er is nu eenmaal 'harvested' hardware, en ook AMD en Intel doen daar net zo hard aan mee.
Je kunt geen features gebruiken waar je niet voor *betaald* hebt. Omdat ze deze features in het desbetreffende product niet hebben kunnen valideren (want dat kost extra tijd en dus geld).
Wil je een gevalideerd product, dan moet je die kopen, dan heb je er ook recht op.
Zo simpel ligt het.

Waardoor ik als consument er hinder van ondervind.

Jij als consument moet gewoon een Quadro kopen, als je features wil gebruiken die nVidia alleen bij de Quadro aanprijst.
Dat de GeForce kaarten 'toevallig' op dezelfde GPUs gebouwd zijn, geeft je nog geen recht op alle features. nVidia heeft immers die features nooit genoemd bij de GeForce, en dus heb je er ook geen recht op.
Zo werkt de markt nu eenmaal, en zoals ik zeg, Intel, AMD en anderen doen exact hetzelfde.

nVidia's statement zelf is dat het bij de geForce kaarten binnen een virtuele omgeving gaat om een bug en dat ze niet van plan zijn dit op korte termijn te fixen, if ever (ten tijde van KVM). Prima, kan ik mee leven want dat kost ze inderdaad geld en resources waar ik ze niet kan verwachten dat te fixen.
Echter blijkt dat ze wel geld en tijd stoppen in het verder beperken van de features en dus de "bug" alleen maar verder uitbreiden, want heel toevallig op de momenten dat er een workarround wordt gevonden kun je er donder op zeggen dat die in de volgende driver release niet meer werkt...

Nogmaals over de PhysX, kijk maar de verschillen in performance hit in metro 2033 en 2033 redux. Redux is een remake van 2033 met als voornaamste verschil de gebruikte PhysX sdk en dus de beste vergelijking tussen PhysX 2 en PhysX 3. Waar het bij metro 2033 (en overigens alle PhysX 2 based games als borderlands e.d.) totaal onspeelbaar wordt als je advanced PhysX aanzet op de cpu blijkt het in metro 2033 redux verbluffend goed te werken zelfs op mijn FX8350 met een minimale performance hit. Er is zelfs een voorbeeld (hoewel niet erg representatief) waarbij 3x GTX480 SLECHTER presteert in metro 2033 redux met physX op gpu dan op de cpu...

En op welke plekken doet AMD vergelijkbare dingen dan? Ze geven inderdaad aan dat "your milage may vary" bij het gebruik van non firepro kaarten in VM's en dat doet het ook zeker. Maar nergens blijkt dat dit ook actief geweerd wordt. Hetzelfde zie je terug in het feit dat sommige kaarten te unlocken zijn naar hun grote broer door middel van een bios flash.

Waar het mij om gaat is dat nVidia relatief veel moeite steekt in het beperken van een zeer kleine groep gebruikers.
Degene die daadwerkelijk in een productieomgeving gpu's in een VM willen gebruiken zullen hoe dan ook wel de Quadro's gebruiken. Het is echter wel prettig als voor een testlab niet gelijk de hoofdprijs hoeft te betalen voor een feature waarvan je nog niet zeker bent dat deze nuttig in gebruik zal zijn.

Hetzelfde voor hybrid physX. Hoeveel mensen zijn er daadwerkelijk die het gebruiken? En hoeveel moeite steekt nVidia er in deze mensen dwars te zitten?
Nogmaals er is een groot verschil in iets niet ondersteunen en moedwillig beperken.

En waarom zou ik bij het kopen van een nVidia kaart geen gebruik mogen maken van hardware PhysX? Daar heb ik toch ook gewoon voor betaald? Alleen als ik dan niet ook een kaart van nVidia gebruik voor rendering mag het ineens niet meer...
Terwijl dit in het begin wel gewoon heeft gewerkt en ook met de nodige hacks nog steeds uitzonderlijk goed werkt voor PhysX 2.
Dus dat nVidia deze beperking oplegt omwille van user experience is gewoon BS. Want het enige "probleem" bij hybrid PhysX zijn de drivers van nVidia die het moedwillig tegenhouden, als je door die bariere heen bent blijkt keer op keer dat het gewoon prima werkt.

En mijn gevoel zegt dan, als nVidia al zoveel moeite steekt in het beperken van een zo kleine groep gebruikers, hoe ver gaan ze dan wel niet bij NVTWIMTBP games...

Uitspraken als

Vendor A is also jokingly known as the "Graphics Mafia".

helpen daar in mijn ogen dan ook absoluut niet bij...

Nogmaals over de PhysX, kijk maar de verschillen in performance hit in metro 2033 en 2033 redux. Redux is een remake van 2033 met als voornaamste verschil de gebruikte PhysX sdk en dus de beste vergelijking tussen PhysX 2 en PhysX 3. Waar het bij metro 2033 (en overigens alle PhysX 2 based games als borderlands e.d.) totaal onspeelbaar wordt als je advanced PhysX aanzet op de cpu blijkt het in metro 2033 redux verbluffend goed te werken zelfs op mijn FX8350 met een minimale performance hit.

En dus? Ik ken die games niet, laat staan dat ik iets weet over hoe ze PhysX gebruiken. Ik kan hier dus totaal geen conclusies aan verbinden.

Er is zelfs een voorbeeld (hoewel niet erg representatief) waarbij 3x GTX480 SLECHTER presteert in metro 2033 redux met physX op gpu dan op de cpu...

Ja, daar noem je ook iets op... drievoudige SLI is sowieso een enorme can of worms. Beetje simpel om daar alles maar op PhysX te gooien. Het zal een combinatie van factoren zijn waarom dat niet werkt.
Er zijn vaak genoeg problemen met performance in SLI/CrossFire -configuraties, zeker met meer dan 2 GPUs, ook in applicaties die helemaal geen PhysX gebruiken.

Hetzelfde zie je terug in het feit dat sommige kaarten te unlocken zijn naar hun grote broer door middel van een bios flash.

Het feit dat ze gelocked zijn is toch een teken dat AMD actief het gebruik van die functies weert?
Je geeft dus zelf al het antwoord: AMD doet precies hetzelfde.

Het is echter wel prettig als voor een testlab niet gelijk de hoofdprijs hoeft te betalen voor een feature waarvan je nog niet zeker bent dat deze nuttig in gebruik zal zijn.

Sorry hoor, maar in een testlab moet je JUIST de goede hardware en software gebruiken. Anders is je test niet representatief.
Wat als je tijdens je test een GeForce gebruikt, en het werkt niet goed? Dan concludeer je dus dat de feature niet nuttig in gebruik is.
Terwijl diezelfde feature op een misschien Quadro wel goed had gewerkt, en wel nuttig had geweest.

moedwillig beperken.

Zoals dingen locken in het bios van een videokaart, bedoel je?

En waarom zou ik bij het kopen van een nVidia kaart geen gebruik mogen maken van hardware PhysX? Daar heb ik toch ook gewoon voor betaald? Alleen als ik dan niet ook een kaart van nVidia gebruik voor rendering mag het ineens niet meer...

Dat heeft nVidia ergens in de productomschrijving opgenomen. Je weet dat dus al voordat je die kaart koopt.

Terwijl dit in het begin wel gewoon heeft gewerkt en ook met de nodige hacks nog steeds uitzonderlijk goed werkt voor PhysX 2.
Dus dat nVidia deze beperking oplegt omwille van user experience is gewoon BS. Want het enige "probleem" bij hybrid PhysX zijn de drivers van nVidia die het moedwillig tegenhouden, als je door die bariere heen bent blijkt keer op keer dat het gewoon prima werkt.

Maar dat is geen garantie natuurlijk.
nVidia wil het gewoon niet ondersteunen, dat is hun keuze, en hun goed recht.
Het probleem is vooral dat als nVidia het WEL probeert te ondersteunen, dat ze dan AMD uitnodigen om rare fratsen in hun drivers te gaan uithalen zodat het alsnog niet goed werkt. Want AMD wil HELEMAAL niet dat men nVidia-kaarten gaat kopen voor PhysX.
nVidia heeft dus eigenlijk niet zo veel keus.

En mijn gevoel zegt dan

Ja, laten we alles op 'gevoel' doen... Waarom zouden we moeilijk doen en daadwerkelijk de code onderzoeken om een definitief antwoord te krijgen over hoe het wel of niet zit?

Vendor A is also jokingly known as the "Graphics Mafia"

Ja, want alles dat je op het internet leest is waar?

Ja, want alles dat je op het internet leest is waar?

Uiteraard zijn niet alle uitspraken op internet waar, maar ik mag toch hopen dat als je kijkt bij wie die uitspraak vandaan komt toch redelijk geloofwaardig mag zijn? En hetzelfde geldt voor jouw eigen reacties

De reden waarom ik juist metro 2033 (LL) aanhaal is omdat het dezelfde engine gebruikt als redux, met als speerpunt het gebruik van PhysX 3 ipv PhysX 2. Het is ook de enige game die zowel is uitgekomen met PhysX 2 als PhysX 3. Als je ook kijkt naar de effecten in game zijn die nagenoeg gelijk of zelfs beter.
Feit blijft dat GEEN ENKELE game die gebruik maakt van PhysX 2 fatsoenlijk te gebruiken is met cpu PhysX terwijl dit met PhysX 3 ineens wel mogelijk blijkt.
En dus heeft nVidia er wel degelijk baat bij om de adaptatie van PhysX 3 zo min mogelijk te stimuleren of zelfs onaantrekkelijk te maken. Immers wordt bij PhysX 3 de NOODZAAK voor een main nVidia gpu omwille van physX kleiner.

En nogmaals er is een wezenlijk verschil tussen iets niet ondersteunen en actief weren. Ik vraag ook helemaal niet van nVidia om hybrid physX te ondersteunen. Mij zal je dan ook niet horen klagen tegen nVidia als ze het toestaan vanuit de drivers, maar het toch incompatibel blijkt met een bepaalde game.
Daarnaast heeft het altijd gewerkt en heb ik hybrid physX meermaals aan de praat gekregen, waar het ENIGE probleem was de blokkades van nVidia te omzeilen.
Of AMD bij het vrijgeven van hybrid physX roet in het eten zal gaan gooien is net zo goed pure speculatie en mochten ze dat gaan doen zal ik ze dat ook zeer kwalijk nemen.

En waarom zou AMD HELEMAAL niet willen dat hybrid PhysX werkt? Hybrid PhysX is juist dat je een non nVidia gpu gebruikt voor renderen en enkel een nVidia gpu gebruikt voor de PhysX... AMD heeft dus alleen maar BAAT bij hybrid PhysX aangezien dat betekend dat gebruikers niet gebonden zijn aan nVidia main gpu's voor gebruik van PhysX... Het is niet zo dat ineens PhysX op een AMD gpu gedaan wordt...

Zoals dingen locken in het bios van een videokaart, bedoel je?

Daar gaat het om delen van de gpu uitschakelen die niet door de quality control zijn gekomen en daarom zijn uitgeschakeld, of omwille van productie tekorten/overschotten. Niet over features die softwarematig beperkt worden.
Maar ook hierbij zal je mij niet horen klagen tegen AMD als ik dan toevallig een kaart tref die niet te unlocken valt...

En nogmaals het is nVidia's goed recht om dit te doen, maar de manier waarop en waarom ze dit doen staat mij gewoon tegen. Net zo goed dat het moddergooien van AMD jou tegenstaat.

Als laatste:
Uiteraard heeft AMD ook genoeg uitgevreten en hebben ze ook niet altijd alles op orde. Maar als ik dan moet kiezen tussen 2 "kwaden" gaat op dit moment mijn voorkeur uit naar AMD vanwege het meer open karakter (en dan heb ik het niet over PR geneuzel, want dat is bij ieder commercieel bedrijf pure prut.)

[Reactie gewijzigd door Spekkie88 op 1 juni 2015 16:12]

Uiteraard zijn niet alle uitspraken op internet waar, maar ik mag toch hopen dat als je kijkt bij wie die uitspraak vandaan komt toch redelijk geloofwaardig mag zijn?

Weet ik niet? Bij wie komt het vandaan dan?
En lees je niet te makkelijk over het woordje 'jokingly' heen?

De reden waarom ik juist metro 2033 (LL) aanhaal is omdat het dezelfde engine gebruikt als redux, met als speerpunt het gebruik van PhysX 3 ipv PhysX 2. Het is ook de enige game die zowel is uitgekomen met PhysX 2 als PhysX 3. Als je ook kijkt naar de effecten in game zijn die nagenoeg gelijk of zelfs beter.

Crysis Warhead draaide ook beter dan de originele Crysis. Had vooral te maken met wat finetuning in de engine, en vooral ook in de content.
Nogmaals, zonder exact te weten wat ze precies gedaan hebben, kun je hier geen conclusies aan verbinden.

Feit blijft dat GEEN ENKELE game die gebruik maakt van PhysX 2 fatsoenlijk te gebruiken is met cpu PhysX terwijl dit met PhysX 3 ineens wel mogelijk blijkt.

Dat lijkt me zeker geen feit. Er zijn genoeg games met PhysX 2 die prima te spelen zijn op de CPU.

En dus heeft nVidia er wel degelijk baat bij om de adaptatie van PhysX 3 zo min mogelijk te stimuleren of zelfs onaantrekkelijk te maken. Immers wordt bij PhysX 3 de NOODZAAK voor een main nVidia gpu omwille van physX kleiner.

Dit is echt onzin. Waarom zou nVidia PhysX 3 uberhaupt uitbrengen, als ze liever hebben dat niemand het gebruikt?
Ik denk ook dat het helemaal niets te maken heeft met jouw hersenspinsels, maar puur met het feit dat men steeds meer ervaring opdoet in het toepassen van PhysX in games.

En waarom zou AMD HELEMAAL niet willen dat hybrid PhysX werkt?

Omdat AMD niet wil meehelpen aan het succes van nVidia.
Hoe minder winst nVidia maakt, hoe beter.

Hybrid PhysX is juist dat je een non nVidia gpu gebruikt voor renderen en enkel een nVidia gpu gebruikt voor de PhysX... AMD heeft dus alleen maar BAAT bij hybrid PhysX aangezien dat betekend dat gebruikers niet gebonden zijn aan nVidia main gpu's voor gebruik van PhysX... Het is niet zo dat ineens PhysX op een AMD gpu gedaan wordt...

De stap naar een main GPU van nVidia is wel een stuk kleiner als je toch al een nVidia GPU voor PhysX gebruikt.
Ook wordt het dan voor game developers steeds interessanter om PhysX te gaan ondersteunen.
AMD heeft er op geen enkele manier baat bij. Ze verdienen er niets aan, en het versterkt alleen de positie van hun concurrent op de markt.

Niet over features die softwarematig beperkt worden.

Jawel dus. Die twee gaan vaak samen, omdat bepaalde features via BIOS/drivers gelocked/unlocked kunnen worden. En dat is dus software.
Zelfs bij hardwarematig uitschakelen dmv laseren oid zie ik eigenlijk geen verschil qua concept. Je kunt het dan niet zelf meer activeren, maar het is wel een feature die gewoon in de hardware zit, terwijl jij er toch geen gebruik van mag maken. En in veel gevallen werken die features gewoon, vanwege bv productietekort/overschot.

Weet ik niet? Bij wie komt het vandaan dan?
En lees je niet te makkelijk over het woordje 'jokingly' heen?

De referentie staat 3 posts terug, en als je het geheel leest zit er wel degelijk een kern van waarheid in ondanks dat er "jockingly" staat.

Noem eens games die gebruik maken van PhysX 2, waarbij het INSCHAKELEN van physX NIET voor een verschrikkelijke performance drop zorgt...

Bij metro 2033 heb ik ook steeds alleen over het performance verschil tussen het wel en niet inschakelen van "advanced PhyX"
Waarbij dit bij redux een zeer geringe performance impact heeft als de cpu de PhysX moet afhandelen... Enige verschil? Het gebruik van PhysX sdk 3 i.p.v. sdk 2.

Hetzelfde geldt voor andere physX 2 games als mirrorsedge, borderlands (2 en The pre sequel), Batman, Maffia 2 en ga zo maar door. Stuk voor stuk games waarbij het inschakelen van de physX zorgt voor onspeelbare game als die verwerkt moet worden door de cpu. Zelf ben ik dan ook tot op heden geen PhysX 2 enabled game tegen gekomen waarbij het inschakelen van de physX niet zorgde voor een onspeelbare game als deze wordt afgehandeld door de cpu.

De reden waarom wel overstag moet na verloop van tijd is dat anders PhysX een stille dood zal sterven. Je ziet tot op heden dat de lijst van games die PhysX ondersteunen kort is... Het zal dan ook niets meer dan een commerciële afweging zijn om de PhysX 3 meer of minder te gaan promoten. Als physX alleen lekker draait om nVidia gpu's zal het nooit breed worden ingezet door studio's want dan schiet je gelijk de helft van je potentiële klanten af... Of het wordt alleen gebruikt voor leuke extra's zodat het niet teveel gemist wordt door non nVidia gamers.

En daarnaast wat heeft een studio er voor baat bij de SDK 3 NIET te gebruiken? Zoals je zelf al aangeeft bij het voorbeeld over windows, blijven de api calls nagenoeg gelijk waardoor het voor een developer JUIST aantrekkelijk zou moeten zijn om over te stappen, zeker omdat je op die manier een breder publiek kan laten genieten van al het werk wat je in je PhysX game hebt gestopt. Als je dit vervolgens legt naast de ontwikkeltijd van metro LL naar redux en de prijsstelling die ze voor de redux games hanteren, kan je mij niet wijsmaken dat het omzetten van PhysX 2 naar PhysX 3 zo machtig veel moeite heeft gekost dat adaptatie van SDK 3 4 jaar heeft moeten duren...
Dit terwijl nVidia er ALLE belang bij heeft, commercieel gezien, om dit zo lang mogelijk uit te stellen. Want dat is makkelijke PR: "kijk eens hoe goed PhysX werkt icm met onze gpu's en wat voor fancy features je anders misloopt!!!"

De stap naar een main GPU van nVidia is wel een stuk kleiner als je toch al een nVidia GPU voor PhysX gebruikt.
Ook wordt het dan voor game developers steeds interessanter om PhysX te gaan ondersteunen.

Door hybrid physX toe te staan zou het gebruik voor PhysX voor game devs ook een stuk interessanter maken inderdaad. Tot op heden is het maar een handjevol (recente) games die gebruik maken van PhysX en blijft de reden om te kiezen voor een nVidia main gpu erg klein. Dus degene die nu een main AMD gpu kopen zouden dat bij het toestaan van hybrid physX ook nog steeds doen... Voor nVidia trek je echter de mensen over de streep (zoals ik) om een EXTRA gpu te kopen (welliswaar geen high end kaart) uit het kamp van nVidia voor dedicated physX.
En dan is het waarmaken van de belofte het niet actief te weren door de drivers voor mij genoeg. Ik zal dan ook niet gaan lopen zeuren over support, want wil je 100% zeker zijn dat het werkt moet je maar een nVidia only setup kiezen.
Op die manier verliest AMD er nauwelijks mee want de mensen die nu ook al een AMD kaart kopen zullen dat blijven doen. Ik zie dan ook eerder dat bij het toestaan van hybrid physX er juist meer AMD gpu's verkocht zouden worden, want als je dan toch net die ene game tegenkomt die gebruik maakt van physX kan je er altijd nog voor kiezen een extra nVidia kaart bij te proppen voor dedicated physX.

De referentie staat 3 posts terug, en als je het geheel leest zit er wel degelijk een kern van waarheid in ondanks dat er "jockingly" staat.

In bijna iedere grap zit wel een kern van waarheid...
En nee, het zegt me niets. Ik weet niet wie dat is.

Noem eens games die gebruik maken van PhysX 2, waarbij het INSCHAKELEN van physX NIET voor een verschrikkelijke performance drop zorgt...

Okee, ik snap je probleem. Je begrijpt niet dat je PhysX niet kunt inschakelen of uitschakelen.
Games hebben *sowieso* physics.
Waar je het over hebt is idd dingen als 'advanced PhysX'... en die zijn speciaal ontworpen voor GPU-acceleratie.
Nogal logisch dat dat meestal niet goed draait op een CPU, daar is de workload niet voor ontworpen, daarvoor heb je de 'standaard' physics workload.
Havok-games hebben nooit zo'n 'advanced' stand, omdat er geen GPU-acceleratie is.

Enige verschil? Het gebruik van PhysX sdk 3 i.p.v. sdk 2.

Nogmaals, dat zal echt niet het enige verschil zijn, want het verschil in performance tussen versie 2.x en 3.x was vaak ergens tussen de 10 a 20% bij dezelfde code.

Hetzelfde geldt voor andere physX 2 games als mirrorsedge, borderlands (2 en The pre sequel), Batman, Maffia 2 en ga zo maar door. Stuk voor stuk games waarbij het inschakelen van de physX zorgt voor onspeelbare game als die verwerkt moet worden door de cpu.

Het inschakelen van de *advanced* PhysX bedoel je.
Allemaal games die er bekend om staan dat ze speciaal voor de GPU ontwikkeld zijn.
Ja, nogal logisch. Zoals ik al zo vaak gezegd heb, een GPU is vele malen sneller dan een CPU met physics.

Maargoed, je moet jezelf echt eens beter informeren... Je zit post na post te maken, die achteraf gewoon compleet nutteloos is, omdat je jezelf baseert op verkeerde aannamen, omdat je eigenlijk niet weet waat je het over hebt.

Er zijn inderdaad dingen van de PhysX sdk die niet hardware accelerated kunnen worden, maar het lijkt me dan ook niet meer dan logies dat je daar niet speciaal een nVidia GPU voor nodig hebt om het beter te laten werken... Ik heb het ook altijd alleen gehad over de advanced PhysX die daadwerkelijk hardware accelerated kunnen worden door de gpu, Anders heeft de hele discussie om voor een nVidia main gpu te gaan sowieso geen enkel nut.
Over physics heb ik het zelfs helemaal nooit gehad... (ondanks dat PhysX een physics engine is heb ik het altijd specifiek over PhysX gehad en niet over physics in het algemeen)

Mijn punt bij advanced PhysX blijft dat het verschil tussen PhysX 2 en PhysX afgehandeld door de cpu aanzienlijk verschild. Met als referentiepunt de verschillen tussen Metro 2033 en redux die ik hier op mijn eigen pc heb draaien. (Ik ben daar nog steeds van plan een uitgebreidere blogpost over te schrijven al is dat er door persoonlijke omstandigheden nog steeds niet van gekomen.)

Nogmaals, dat zal echt niet het enige verschil zijn, want het verschil in performance tussen versie 2.x en 3.x was vaak ergens tussen de 10 a 20% bij dezelfde code.

so you say...
Net als dat je zelf ook zegt dat je niet alles moet geloven wat je op internet leest...

Begrijp me niet verkeerd, ik wil je best geloven, alleen krijg ik van jou over het algemeen ook niet meer dan je woord...

Maargoed ondertussen zijn we hier aardig offtopic bezig en zal dit mijn laatste inbreng zijn hier.

Voel je vrij om hier nog een laatste woord te plaatsen of de discussie eventueel elders voort te zetten

[Reactie gewijzigd door Spekkie88 op 1 juni 2015 22:50]

Over physics heb ik het zelfs helemaal nooit gehad... (ondanks dat PhysX een physics engine is heb ik het altijd specifiek over PhysX gehad en niet over physics in het algemeen)

Dan begrijp je het dus nog steeds niet.
*Alle* physics in een game gaan met PhysX, wanneer die game PhysX gebruikt.
Bij de advanced PhysX-setting krijg je alleen veel gedetaiieerdere physics-effecten. Deze effecten zijn speciaal gemaakt voor mensen die een GPU hebben om die effecten te accelereren.
Die effecten zijn simpelweg te zwaar om te draaien op iets anders dan een GPU. Dat is het hele punt van die advanced setting.

Dat je dan klaagt dat het niet goed draait op een CPU geeft aan hoe weinig je begrijpt.

Physics is ook een onderdeel van de game-wereld. De ontwerpers van de levels/characters bepalen OOK wat voor physics-effecten er gebruikt worden in zo'n level.
Bij bv Mirror's Edge heb je dus twee versies van ieder level: de 'gewone', met simpele glas-effecten, ragdolls en verder niet zo heel veel.
En dan heb je de 'GPU-accelerated' versie van een level, met extra water-effecten, meer rook, glas etc, en ook allerlei toevoegingen als cloth etc.
Die versie van het level is natuurlijk veel zwaarder, omdat er veel meer physics in zit.
Zoveel physics kom je in games met Havok simpelweg niet tegen.
Ja, Havok *kan* wel cloth etc... Maar als je je hele level vol gaat gangen met vlaggen etc, die ook nog eens kunnen scheuren als je erop schiet etc, dan trekt je CPU dat net zo min als met PhysX zonder GPU. Dat is gewoon te zwaar voor eeen CPU.

Mijn punt bij advanced PhysX blijft dat het verschil tussen PhysX 2 en PhysX afgehandeld door de cpu aanzienlijk verschild. Met als referentiepunt de verschillen tussen Metro 2033 en redux die ik hier op mijn eigen pc heb draaien. (Ik ben daar nog steeds van plan een uitgebreidere blogpost over te schrijven al is dat er door persoonlijke omstandigheden nog steeds niet van gekomen.)

Tsja, ik kan daar niets over zeggen. Ik ken die games niet, en weet niet in hoeverre de implementatie verschilt.
Wat ik wel weet is dat PhysX 3 echt geen wonderen verricht tov PhysX 2 op de CPU.
Dus er blijven 2 mogelijkheden over:
1) In redux hebben ze de PhysX-implementatie een stuk efficienter gemaakt.
2) In redux hebben ze de PhysX workload omlaag geschroefd door de physics-effecten minder gedetailleerd te maken (wat niet per se inhoudt dat je ook verschil ziet).
In beide gevallen had PhysX 2 ook een stuk sneller geworden.

Dus je moet gewoon even snappen dat je bij physics ook gewoon verschillende 'resoluties' en detailniveaus etc kunt hebben, net als bij het grafische gedeelte.
Je gaat toch ook niet zeggen dat DX11 niet goed in elkaar zit omdat je videokaart met alle detail voluit op 4k een game niet op een speelbare framerate kan draaien?
Dat ligt dan niet aan DX11, maar aan het feit dat je die API gebruikt om een te zware workload naar je GPU te sturen.
Heb je een GPU die wel snel genoeg is, dan heb je geen probleem.

Op dit moment bestaan er geen CPUs die snel genoeg zijn voor de GPU-PhysX workload in games als Mirror's Edge.
Als je even zou googlen op hoeveel GFLOPS een high-end Intel Core i7 scoort (ergens tussen de 100 en 200 GFLOPS), en dat vergelijkt met een simpele GPU, zeg een 760 ofzo (over de 2 TFLOPS), dan zou je al je conclusies moeten kunnen trekken. De pure rekenkracht van een GPU ligt in een totale andere orde van grootte dan die van een CPU.

[Reactie gewijzigd door Scalibq op 1 juni 2015 23:24]

Bij Gameworks en Hairworks is dat niet het geval, zover ik weet. Daarnaast is AMD de enige partij die vergaande optimalisaties kan implementeren, omdat programmeurs tegen OpenGL / DirectX aanschrijven en (praktisch!) geen toegang hebben tot lagen daaronder.

Bij Gameworks en Hairworks is dat niet het geval, zover ik weet.

Juist wel dus. nVidia heeft dat een tijdje geleden letterlijk gezegd: https://youtu.be/aG2kIUerD4c
Edit, hier nog een keer: http://www.extremetech.co...o-the-witcher-3-wild-hunt

GameWorks source code is provided to developers that request it under license, but they can’t redistribute our source code to anyone who does not have a license. Most of the time we optimize games based on binary builds, not source code…

Daarnaast is AMD de enige partij die vergaande optimalisaties kan implementeren, omdat programmeurs tegen OpenGL / DirectX aanschrijven en (praktisch!) geen toegang hebben tot lagen daaronder.

Dat heeft er weinig mee te maken. Gameworks/Hairworks zijn 'normale' middleware-oplossingen, die bovenop OGL/D3D draaien.
AMD moet dus gewoon zorgen dat ze die APIs efficient implementeren.
Dat zie je ook met The Witcher 3: er is eigenlijk geen probleem. Zet tessellation laag met de driver-hack, en het presteert prima op AMD-kaarten. Ze zijn alleen niet goed in tessellation, en dat is een tekortkoming van de verouderde architectuur van AMD's GPUs.

Leuk dat mensen denken dat alle problemen met software zijn te verklaren/op te lossen, maar zo werkt het niet.

En verder, leuk dat AMD zo veel FUD heeft verspreid dat men inderdaad begint te geloven dat performance-problemen altijd in middleware opgelost moeten worden, en dat 'hacks/cheats' tegenwoordig als 'optimalisaties' worden benoemd.
Natuurlijk is dat onzin. Het probleem zit meestal in de driver of in de hardware zelf. Zoals je zelf zegt, programmeurs praten alleen tegen een OGL/DX-laag aan, en wat die laag moet doen, is gewoon strak gespecificeerd. Het is vervolgens aan de driver en de hardware om die specificatie efficient en robuust te implementeren.
Software moet ervanuit kunnen gaan dat alles werkt volgens de spec, zonder zich specifiek druk te hoeven maken over de exacte hardware. Dat is het hele uitgangspunt van hardware-abstractielagen, en dus ook van OGL/DX.

[Reactie gewijzigd door Scalibq op 29 mei 2015 15:32]

Maar het gaat niet om de API's die efficient geimplementeerd moeten worden; je kunt er donder op zeggen dat het standaardpad allang kapot geoptimaliseerd is. Wat drivers doen is kijken naar welke executable draait, en dan on-the-fly besluiten andere code uit te voeren dan het programma doorgeeft. Dit kan doordat een game feature X van api call Y niet zal gebruiken (wat tegelijkertijd enorm lastig is om statisch vast te stellen), maar toch call Y moet gebruiken omdat het functionaliteit Z bevat. Het is niet voor niets dat indie-developers soms aangeraden wordt hun executable anders te noemen zodat het gedrag van de API dan anders (sneller!) wordt.

AMD heeft inderdaad toegang gehad tot de executable van de games maar ZONDER hairworks; dat is er in de laatste maand ingedrukt.

Ze zijn alleen niet goed in tessellation, en dat is een tekortkoming van de verouderde architectuur van AMD's GPUs.

Dat is allemaal goed en wel, maar de tesselation instelling staat standaard op 64X. Er is geen zichtbaar verschil tussen 64X en 8X, waardoor het wel degelijk lijkt op sabotage. Je hebt immers hardware die relatief goed om kan gaan met 64X (nieuwere generatie nvidia) en kaarten die er slecht mee omgaan (AMD, oudere generatie nvidia). Een normale developer had zijn instelling dan op 8X gezet, maar Witcher zet het op 64X. Het is toch niet zo lastig om te zien waarom dat gebeurt als het spel begint met 'nvidia, the way it's meant to be played'?

Juist wel dus. nVidia heeft dat een tijdje geleden letterlijk gezegd: https://youtu.be/aG2kIUerD4c

Oke, maar dan heeft AMD alsnog de broncode niet, dus degene die moeten optimaliseren hebben er niets aan .

Maar het gaat niet om de API's die efficient geimplementeerd moeten worden;

Jawel, het pijnpunt zit hem in de hardware van AMD, niet de software.
De OGL/DX specs geven duidelijk aan dat tessellation factors tot 64x lopen.
Het ontwerp van AMD kan hier niet goed mee omgaan, en de concurrentie wel.

Er is geen zichtbaar verschil tussen 64X en 8X

Oh, zeker wel. Zelfs bij 16x zie je nog wel verschil (maar screenshots geven dat niet zo goed weer... Het is dynamisch, dus je moet het in beweging zien).

(nieuwere generatie nvidia)

Alle nVidia kaarten zijn goed schaalbaar met tessellation.
Als je op Kepler doelt, met oudere drivers draait de game sneller dan met de nieuwste drivers. nVidia is dit aan het onderzoeken, en zal met een driver-fix komen.
Het probleem is niet specifiek tessellation, de hele game draait trager op Kepler met de nieuwe driver.

Een normale developer had zijn instelling dan op 8X gezet, maar Witcher zet het op 64X.

Waarom heb ik het gevoel dat mensen praten alsof deze instellingen hard zijn?
Het is net als AF: dat kan maximaal op 16x. Alle moderne games zetten het ook standaard op 16x. In de praktijk heb je zoveel meestal niet nodig. De algoritmen zijn namelijk adaptief, en bepalen dynamisch hoeveel er nodig is, 16x is slechts de bovengrens, en wordt zelden gebruikt. Het verschil met 8x is vaak al nauwelijks te zien.

Zo ook met tessellation. Waarom zou je de max niet op 64x zetten, als je er zelden of nooit komt, en het dus geen probleem is voor performance?
Behalve bij AMD, waar de architectuur dusdanig slecht in elkaar zit, dat je dan nog maar een kwart van je GPU kunt gebruiken. Dus die paar keer dat je toevallig even uitschiet naar hogere tessellation factoren (AMD gaat bij alles boven de 10 al zweten), hakken er gigantisch in bij AMD. Jammer maar helaas.
AMD moet dat probleem in de hardware oplossen. Ik als developer zou *juist* ervoor kiezen om die 64x aan te houden.
AMD heeft dit probleem al 5 jaar, en dit is blijkbaar de enige manier om ze te dwingen om dat probleem aan te pakken.

Vergelijk het met de tijd van de GeForce FX: nVidia bakte niks van PS2.0. Moesten developers dan maar geen PS2.0 gebruiken? Nee, die gebruikten het volop, en dwongen nVidia zo om met een goede GPU-architectuur voor PS2.0 te komen.

Oke, maar dan heeft AMD alsnog de broncode niet, dus degene die moeten optimaliseren hebben er niets aan .

Zie mijn post elders. Je snapt niet hoe (driver) development werkt, en welke tools er gebruikt worden.
Dat geleuter met dat open source ook, ik word er moe van.
Alsof niemand meer iets kan zonder sourcecode tegenwoordig.

[Reactie gewijzigd door Scalibq op 29 mei 2015 16:27]

Heeft de developer van Witcher 3 niet op reddit laten weten dat AMD nergens aan mee wilde werken? Hij had geloof ik zelfs een screenshot geplaatst van de laatst uitgewisselde e-mails, terwijl Nvidia 'actief' bezig was met het proces en the witcher 3. Ik probeer de post nog te vinden en mocht die informatie kloppen....dan kunnen ze moeilijk nu gaan klagen.

Mijn ervaring is juist 180 graden de andere kant op. Ik heb veel betere ervaringen met AMD. Niet iedereens ervaring is hetzelfde. Ik mis bij Nvidia mijn passieve 3D en Super resolution en baremetal drivers.

AMD is gestopt met hun baremetal driver gezien DX12 hetzelfde zal gaan bieden. Nvidia heeft DRS technologie vergelijkbaar met wat jij Super Resolution noemt.

Nvidia heeft al "super resolution" sinds de 8000 of gtx260 oid.

De enige reden dat amd het ingebouwd heeft is omdat nvidia het bij de 970 en 980 plotseling als een feature ging marketen.

moet je verschl tussen windows/linux maar eens bekijken bij nvidia/amd, dat gat is groooooot

//edit;
nvidia is easy peasy, en werkt gewoon goed. amd/ati is heel vaak gepaard met problemen (uitgegaan van de closed-source drivers)

zal ongetwijfeld nu reactie komen van iemand die dit ontkracht. Maar met 250+ Linux games en stapel gpu's te hebben getest is dat onze conclusie.

opensource; dan is amd/ati stuk verder op linux dan nvidia
closed-source; loopt nvidia hard uit (soms loopt linux driver voor op die van windows)

[Reactie gewijzigd door himlims_ op 29 mei 2015 11:25]

Nou heb ik al jaren geen problemen meer met AMD-drivers, maar ik hoor nog wel iedereen roepen. Is het zo moeilijk om een shell-script uit te voeren, of hebben mensen absurde installaties? Of... is het gewoon een gerucht dat al jaren rondgaat, en nooit getest is?

Heck, voor iets als Ubuntu kun je gewoon externe drivers aanzetten, en de rest regelt zichzelf. Waarom moeilijk doen als het makkelijk kan?

zal ongetwijfeld nu reactie komen van iemand die dit ontkracht. Maar met 250+ Linux games en stapel gpu's te hebben getest is dat onze conclusie.

Heb je ook een mooi testverslag daarvan? As for verschil tussen Windows en Linux: tja, als spellen maar voor 1 platform uitgebracht worden is er uiteraard verschil. Verschil tussen NVidia en AMD is niet rampzalig, zie Phoronix bijvoorbeeld. Het hangt alleen af van de optimalisaties, iets als Bioshock is NVidia-optimized, en dat zie je.

hoe bedoel je? is AMD op linux een betere keus dan Nvidia?

Nee, andersom. Tot je de opensource drivers wil gebruiken, nouveau is ronduit slecht. Opensource drivers voor AMD zijn veel beter dan voor nVidia.

Dat was ooit zo. In 2D iig (met de binary/officiële driver!) blaast AMD compleet voorbij nVidia
http://www.phoronix.com/s...item=30way_linux_2d&num=1

En wie koopt ooit z'n videokaart voor 2d performance het is 3d performance waar het verschil tussen amd en nvidia in voordeel van nvidia is.

Ik game op Windows niet op Linux. Voor mij is onder Linux 2D dus veel belangrijker dan 3D.

Nee, andersom. Tot je de opensource drivers wil gebruiken, nouveau is ronduit slecht. Opensource drivers voor AMD zijn veel beter dan voor nVidia.

Dat komt omdat AMD (een beetje) meewerkt aan de open source drivers, waar nVidia zich er totaal niet mee bemoeit.
Nouveau is dus een onafhankelijk project zonder steun/documentatie van nVidia, die veelal via reverse engineering moet achterhalen hoe nVidia's GPUs werken.

De gamestudio's zijn gewoon te lui en laten de optimalisaties door AMD en Nvidia doen (die er anders op afgerekend worden door hun klanten).

Bij The Witcher is er besloten geweest om gebruik te maken van een toolset van nVidia om bepaalde effecten in beeld te brengen (zoals het haar). Hoewel deze instellingen zeer diepgaand zijn aan te passen en grotendeels zijn uit te schakelen benadeeld dit natuurlijk wel de AMD gebruiker.

Project CARS is dan weer een zeer goed spel vanwege de aandacht die is besteed aan de handelbaarheid van de wagens. Dit word bekomen door gebruik te maken van Physx, de physics engine die reeds enkele jaren eigendom is van nVidia en enkel hardwarematig versneld kan worden met behulp van een nVidia kaart (en het is niet langer mogelijk om een nV kaart te gebruiken voor de physics en een AMD kaart voor de graphics).

De studios hebben er dus voor gekozen om gamers een zo goed mogeljke ervaring te bieden die spijtig genoeg gebasseerd is op technologie van nVidia waar AMD kaarten het moeilijk mee hebben. Moet men dan een compromis sluiten en slechtere games maken?

Studios houden zich uiteindelijk gewoon aan standaarden en laten vooraf weten aan de gamer wat voor systeem ze gaan nodig hebben om het spel goed te kunnen spelen.

benadeeld dit natuurlijk wel de AMD gebruiker.

Zo 'natuurlijk' is dat niet hoor.
Het komt best wel eens voor dat een game met nVidia-code toch beter loopt op AMD-hardware of omgekeerd.
Verder is het een momentopname. Een volgende generatie hardware kan alles weer op z'n kop gooien, omdat de dingetjes waar nVidia eerst beter in was, nu beter gaan bij AMD-hardware, of omgekeerd.
Een mooi voorbeeld daarvan is Crysis 2. AMD-hardware deed het daarin minder goed met tessellation aan.
Na de introductie van de Radeon 7970 was AMD ineens de snellere in Crysis 2.
Ondanks dat AMD's tessellation hardware nog steeds problemen had bij hoge tessellation factors (en heeft, zie Witcher 3).
Het bewijst dus in feite dat nVidia niet zo heel extreem veel tessellation gebruikte in Crysls 2 (wat ook al duidelijk werd toen AMD met de driver-optie kwam om tessellation te beperken: je zag vooral op muren al vrij gauw hele lelijke aliasing, omdat de extra tessellation gewoon nodig was), en zo oneerlijk was het allemaal niet. Ze legden vooral een zwak punt in de AMD-architectuur bloot.

Witcher 3 zal wel eens hetzelfde verhaal kunnen gaan worden... Misschien dat een volgende architectuur van AMD de tessellation naar hetzelfde niveau tilt, of hoger, dan wat nVidia nu heeft, en dan zou AMD best wel eens de snellere GPU in Witcher 3 kunnen hebben.

Sommige verhalen zijn nog vreemder. Zo is Half-Life 2 ooit begonnen in samenwerking met ATi. In eerste instantie liep het ook voor geen meter op de GeForce FX. Toen de GeForce 6-serie kwam, was dat opgelost... En een aantal jaren geleden is Valve juist gaan samenwerken met nVidia, mede voor de OpenGL-ports en SteamOS. Terwijl het in feite nog steeds die Source-engine is die ooit samen met ATi is ontwikkeld voor DX9.

Je zou kunnen zeggen dat het eigenlijk wel goed is dat fabrikanten dergelijke optimalisaties doen. Zo houden ze elkaar scherp: je moet de DirectX/OpenGL standaard over de hele breedte goed ondersteunen, zodat je concurrent je niet kan pakken op je zwakke punten (zoals bv compute of tessellation).

[Reactie gewijzigd door Scalibq op 29 mei 2015 12:06]

Voor tessalation is het meer een afweging...
Voor zover ik heb begrepen maakt AMD deels gebruik van een hardware tesselator en nVidia niet...

Beide implementaties hebben voor en nadelen.
AMD is (veel?) sneller bij lagere ressalation, maar is slecht schaalbaar en gaat dus finaal onderuit bij hoge tessalation. AMD kiest er dan ook voor de hardware tessalator te optimaliseren voor het tessalation level wat voornamelijk gebruikt zal worden in games.
Bij TW3 wordt er echter gebruik gemaakt van extreem(?) veel tessalation, waardoor de hardware tessalator van de AMD kaarten en niet meer aankan.

nVidia heeft een andere insteek. Door geen hardware tessalator te gebruiken is nVidia relatief traag bij lagere tessalation, maar heeft ook een lagere performance hit bij hogere tessalation.

Zie hier een voorbeeld in tessalation performance tussen de HD7970 en de GTX580. Vanaf 11x tessalation is het omslagpunt.

Het is dan ook goed mogelijk dat de tessalator in de AMD 300 serie een upgrade krijgt waardoor ook TW3 inees veel beter zal draaien. Ondanks dat, is er vanuit AMD CCC altijd een profiel aan te maken voor een bepaalde game om de tessalation aan banden te leggen voor dat spel. (En wat AMD dus ook aangeeft in deze post).

Naarmate (verwacht wordt dat) meer games hogere tessalation gebruiken, zal je zien dat AMD de tessalation performance op zal schroeven in de nieuwere generatie kaarten. Het blijft echter zo dat dit nooit opgelost zal kunnen worden voor de oudere generatie aangezien het een hardware afweging is. En de enige mogelijkheid zal dus zijn om de tessalation vanuit de drivers te beperken.

Dit is dan ook de reden dat AMD een optie heeft in de drivers voor "AMD optimized tessalation" wat, als ik et goed begrijp, automtisch de optimale tessalation kiest voor jouw kaart.

TL;DR
lagere tessalation = win voor AMD
hoge tessalation = win voor nVidia
Het is dan ook zeer afhankelijk van de game in hoeverre de hogere tessalation uberhaubt visual improvement biedt.

Voor zover ik heb begrepen maakt AMD deels gebruik van een hardware tesselator en nVidia niet...

Dan heb je het niet goed begrepen.
nVidia heeft een schaalbare tessellation-pipeline gebouwd. Ze noemen deze architectuur PolyMorph: http://www.nvidia.com/object/IO_89569.html

GF100’s entire graphics pipeline is designed to deliver high performance in tessellation and geometry throughput. GF100 replaces the traditional geometry processing architecture at the front end of the graphics pipeline with an entirely new distributed geometry processing architecture that is implemented using multiple “PolyMorph Engines” . Each PolyMorph Engine includes a tessellation unit, an attribute setup unit, and other geometry processing units. Each SM has its own dedicated PolyMorph Engine (we provide more details on the Polymorph Engine in the GF100 architecture sections below). Newly generated primitives are converted to pixels by four Raster Engines that operate in parallel (compared to a single Raster Engine in prior generation GPUs). On-chip L1 and L2 caches enable high bandwidth transfer of primitive attributes between the SM and the tessellation unit as well as between different SMs.
Tessellation and all its supporting stages are performed in parallel on GF100, enabling breathtaking geometry throughput

Intel heeft overigens een vergelijkbare architectuur.

En *dat* is de reden dat nVidia wel goed is in tessellation en AMD niet.
Let vooral op dat de geometry engines ook triangles van de ene SM naar de andere SM kunnen doorsturen. Dit kan AMD niet. Daarom loop je in het ergste geval dus alle triangles op maar 1 SM te draaien, en draai je maar op een kwart of zelfs minder van je totale GPU.

AMD kiest er dan ook voor de hardware tessalator te optimaliseren voor het tessalation level wat voornamelijk gebruikt zal worden in games.

Dat is gewoon onzin.
Games kunnen iedere tessellation factor gebruiken die binnen de D3D/OpenGL specs vallen.
AMD heeft ook niets 'geoptimaliseerd'... ze liggen gewoon ver achter ten opzichte van nVidia/Intel.
Een dergelijke parallele geometrie-engine is gewoon een stuk ingewikkelder om te ontwerpen, en daarom schuift AMD dat al 5 jaar voor zich uit.
Het is vergelijkbaar met in-order execution CPUs en out-of-order execution CPUs.

Het is dan ook goed mogelijk dat de tessalator in de AMD 300 serie een upgrade krijgt waardoor ook TW3 inees veel beter zal draaien.

Vroeg of laat zal AMD eraan moeten geloven, en moet die tessellator parallel/schaalbaar gaan worden.

Naarmate (verwacht wordt dat) meer games hogere tessalation gebruiken, zal je zien dat AMD de tessalation performance op zal schroeven in de nieuwere generatie kaarten.

Het is geen kwestie van 'opschroeven'. Het is een kwestie van de totale GPU-architectuur omgooien en opnieuw beginnen. Zodra ze dit goed implementeren heb je ook *boem* ineens die volle schaalbaarheid.

TL;DR: AMD kan er gewoon niets van. Ze liggen zo'n 5 jaar achter op het gebied van GPU-architectuur.

edit:

Zie hier een voorbeeld in tessalation performance tussen de HD7970 en de GTX580. Vanaf 11x tessalation is het omslagpunt.

Je weet wel dat je daar naar mijn eigen blog linkt he?

[Reactie gewijzigd door Scalibq op 29 mei 2015 17:13]

Je verhaal verklaart inderdaad een hoop.
Maar toch verklaart het niet waarom AMD de vloer aanveegt met nVidia bij lagere tessalation.

[...]


Dat is gewoon onzin.
Games kunnen iedere tessellation factor gebruiken die binnen de D3D/OpenGL specs vallen.

Ja daar heb je gelijk in, maar wat ik daarmee bedoelde is dat er een bepaalde sweetspot zit in mate van tessalation. Je kan als developer uiteraard zoveel tessalation toepassen als je wil, maar als je dan van te voren al weet dat geen enkele gpu dit fatsoenlijk kan verwerken en de visual improvement verwaarloosbaar is, is het natuurlijk niet slim om het te doen.

AMD heeft ook niets 'geoptimaliseerd'... ze liggen gewoon ver achter ten opzichte van nVidia/Intel.
Een dergelijke parallele geometrie-engine is gewoon een stuk ingewikkelder om te ontwerpen, en daarom schuift AMD dat al 5 jaar voor zich uit.
Het is vergelijkbaar met in-order execution CPUs en out-of-order execution CPUs.


[...]


Vroeg of laat zal AMD eraan moeten geloven, en moet die tessellator parallel/schaalbaar gaan worden.


[...]


Het is geen kwestie van 'opschroeven'. Het is een kwestie van de totale GPU-architectuur omgooien en opnieuw beginnen. Zodra ze dit goed implementeren heb je ook *boem* ineens die volle schaalbaarheid.

TL;DR: AMD kan er gewoon niets van. Ze liggen zo'n 5 jaar achter op het gebied van GPU-architectuur.

Dat klopt dus ook niet. De aanpak van AMD is wel degelijk schaalbaar.
AMD maakt alleen gebruik van losse geometry engines ipv geintegreerd in de SM.
quote van anandtech.

Moving on, there are a number of back end and front end changes AMD has made to improve rendering performance, and the increased number of geometry processors is at the forefront of this. With Hawaii AMD has doubled the number of geometry engines from 2 to 4, and more closely coupling those with the existing 4 rasterizer setup they inherit. The increase in geometry processors comes at an appropriate time for the company as the last time the number of geometry processors was increased was with the 6900 series in 2010, when the company moved to 2 such processors. One of the side effects of the new consoles coming out this year is that cross-platform games will be able to use a much larger number of primitives than before – especially with the uniform addition of D3D11-style tessellation – so there’s a clear need to ramp up geometry performance to keep up with where games are expected to go.

En in principe kan AMD er dus voor kiezen nog meer geometry engines in de gpu's te plaatsen. AMD maakt alleen de afweging WAT REEËL is voor gebruik in games.
Naarmate de gpu's krachtiger worden en het dus voor ontwikkelaars interessanter wordt meer tessalation toe te passen, zal AMD zijn gpu's aanpassen.

Maar om nu te zeggen dat AMD 5 jaar achterloopt vind ik erg overdreven.
Het is een design keuze. Net zoals het een design keuze is geweest van nVidia om de FP64 CUDA cores te schrappen uit Maxwell en daardoor de titan X in DP slechter presteerd dan een GTX580...

Dus om dan maar weer even in je eigen termen te praten:
Die Titan X loopt 5 jaar achter op DP!!!! En is daarom compleet ruk!

Je verhaal verklaart inderdaad een hoop.
Maar toch verklaart het niet waarom AMD de vloer aanveegt met nVidia bij lagere tessalation.

Indirect wel: nVidia's aanpak is een vrij complex systeem, en je hebt dus wat meer overhead.
AMD's systeem is rechttoe-rechtaan... En bij weinig of geen tessellation is dat inderdaad sneller... Maar wat heb je eraan?
Dat is een puur theoretisch voordeel. In de praktijk ontlopen de GPUs elkaar ook in games zonder tessellation niet veel, omdat je eerder tegen andere bottlenecks aanloopt dan dat de overhead van de geometry pipeline een rol gaat spelen.

Ja daar heb je gelijk in, maar wat ik daarmee bedoelde is dat er een bepaalde sweetspot zit in mate van tessalation.

Nee, en dat probeer ik al 5 jaar uit te leggen. Blijkbaar is het gat tussen developers en 'tweakers' te groot om dat uit te kunnen leggen.
Tessellation is puur een vorm van 'geometry-compression'. Je kunt meshes met hoge dichtheid efficient opslaan met een low-res control mesh en bv een displacement map.
Hoe meer 'compressie' je toepast (control mesh zo laag mogelijke res, tessellation factors groter), hoe efficienter het wordt.
Je kunt meshes van vele miljoenen polygons realtime renderen, wat zonder tessellation compleet ondenkbaar is.

Het probleem is vooral dat veel games niet voor tessellation ontworpen zijn, en dus niet die low-res control meshes hebben. In plaats daarvan gebruiken ze de gewone meshes, en dan tessellation daarbovenop. Dat is dus niet echt de bedoeling.

nVidia's demo Endless City was een goed voorbeeld van hoe tessellation gebruikt zou moeten worden. Als je tessellation uitzet, zijn de gebouwen extreem low-poly en nauwelijks nog herkenbaar, omdat vrijwel al het detail uit tessellation volgt.

Dat klopt dus ook niet. De aanpak van AMD is wel degelijk schaalbaar.

Nee. AMD heeft gewoon de GPU in 4 stukken gedeeld, en ieder stuk heeft een geometry engine hardwired.
Die 4 stukken kunnen onderling niet met elkaar communiceren (zoals ik dus al zei), en daarom schaalt het dus niet.
In eerste instantie hadden ze maar 1 geometry engine, toen 2, en nu dus 4.
Vandaar dus dat ik zei dat je nu worst case maar een kwart van je GPU kunt gebruiken bij tessellation. Nogal logisch dat het dan niet schaalt, vind je niet?

En in principe kan AMD er dus voor kiezen nog meer geometry engines in de gpu's te plaatsen.

Als ze dit trucje nog een keer herhalen, heb je dus 8 stukken, en render je worst case op 1/8e van de GPU.
Deze aanpak deugt gewoon niet.
De geometry engines moeten op een flexibelere manier met de rest van de pipeline integreren.

Maar om nu te zeggen dat AMD 5 jaar achterloopt vind ik erg overdreven.

Dat is de waarheid: nVidia's PolyMorph werd al in de GTX480 geintroduceerd, die is in april 2010 geintroduceerd. 5 jaar oud dus.

Dus om dan maar weer even in je eigen termen te praten:
Die Titan X loopt 5 jaar achter op DP!!!! En is daarom compleet ruk!

Behalve dan dat dit een kunstmatige beperking is. nVidia heeft andere GPUs waarbij DP wel volledig ingeschakeld is, en loopt dus niet achter. AMD heeft geen schaalbaar alternatief voor tessellation, en dat is ook een stukje lastiger te doen dan DP wel of niet.

[...]


Indirect wel: nVidia's aanpak is een vrij complex systeem, en je hebt dus wat meer overhead.
AMD's systeem is rechttoe-rechtaan... En bij weinig of geen tessellation is dat inderdaad sneller... Maar wat heb je eraan?
Dat is een puur theoretisch voordeel. In de praktijk ontlopen de GPUs elkaar ook in games zonder tessellation niet veel, omdat je eerder tegen andere bottlenecks aanloopt dan dat de overhead van de geometry pipeline een rol gaat spelen.

Als ik me goed heb ingelezen komt dat voordeel bij nVidia door de implementatie van de "warp", correct?
Als dat het geval is heeft AMD namelijk iets soorgelijks genaamd de "wavefront" sinds de introductie van de GCN architectuur in 2011. Verder kan ik nergens terugvinden dat de verschillende onderdelen van de GPU niet met elkaar kunnen communiceren... Juist uit het hele verhaal over de L2 cahce van de GCN icm de "wavefront" doet mij het tegenovergestelde vermoeden:
Wederom een quote van anadtech:

Starting with memory and cache, GCN will once more pair its L2 cache with its memory controllers. The architecture supports 64KB or 128KB of L2 cache per memory controller, and given that AMD's memory controllers are typically 64bits each, this means a Cayman-like design would likely have 512KB of L2 cache. The L2 cache is write-back, and will be fully coherent so that all CUs will see the same data, saving expensive trips to VRAM for synchronization.

[...]


Nee, en dat probeer ik al 5 jaar uit te leggen. Blijkbaar is het gat tussen developers en 'tweakers' te groot om dat uit te kunnen leggen.
Tessellation is puur een vorm van 'geometry-compression'. Je kunt meshes met hoge dichtheid efficient opslaan met een low-res control mesh en bv een displacement map.
Hoe meer 'compressie' je toepast (control mesh zo laag mogelijke res, tessellation factors groter), hoe efficienter het wordt.
Je kunt meshes van vele miljoenen polygons realtime renderen, wat zonder tessellation compleet ondenkbaar is.

Het probleem is vooral dat veel games niet voor tessellation ontworpen zijn, en dus niet die low-res control meshes hebben. In plaats daarvan gebruiken ze de gewone meshes, en dan tessellation daarbovenop. Dat is dus niet echt de bedoeling.

nVidia's demo Endless City was een goed voorbeeld van hoe tessellation gebruikt zou moeten worden. Als je tessellation uitzet, zijn de gebouwen extreem low-poly en nauwelijks nog herkenbaar, omdat vrijwel al het detail uit tessellation volgt.

Dit ziet er inderdaad heel cool uit en zoals je zegt is dat de manier waarop tessalation gebruikt ZOU MOETEN WORDEN. Je geeft echter zelf al aan dat dit tot op heden nog steeds niet het geval is.

[...]


Nee. AMD heeft gewoon de GPU in 4 stukken gedeeld, en ieder stuk heeft een geometry engine hardwired.
Die 4 stukken kunnen onderling niet met elkaar communiceren (zoals ik dus al zei), en daarom schaalt het dus niet.
In eerste instantie hadden ze maar 1 geometry engine, toen 2, en nu dus 4.
Vandaar dus dat ik zei dat je nu worst case maar een kwart van je GPU kunt gebruiken bij tessellation. Nogal logisch dat het dan niet schaalt, vind je niet?

Ondanks dat er in de meeste reviews waarbij tessalation voorbij komt alleen wordt gekeken naar extremen (zoals 64x tesselation) kan je hier zien wat de verdubbeling in geometry units voor effect heeft tussen de HD7970 en de R9 290X (spoiler: nagenoeg een verdubbeling in performance.) Dus ondanks je claims dat het bij AMD voor geen meter schaalt, zie ik toch hele andere resultaten...

[...]


Als ze dit trucje nog een keer herhalen, heb je dus 8 stukken, en render je worst case op 1/8e van de GPU.
Deze aanpak deugt gewoon niet.
De geometry engines moeten op een flexibelere manier met de rest van de pipeline integreren.

Dit blijf je inderdaad aanhalen, maar na mij ingelezen te hebben in de GCN architectuur en dit te hebben vergeleken met de FERMI architectuur zie ik nog maar weinig verschillen...
Ik ben echter geen kenner op dit gebied, maar ik zou toch graag ergens iets meer ondebouwing zien van je claim dat AMD geen data uit kan wisselen tussen de verschillende delen en nVidia wel, aangezien de bevenstaande artikelen mij zeer sterk anders doen vermoeden.

[...]


Dat is de waarheid: nVidia's PolyMorph werd al in de GTX480 geintroduceerd, die is in april 2010 geintroduceerd. 5 jaar oud dus.

GCN is al uit 2011 en loopt AMD dus maar een jaar achter.

[...]


Behalve dan dat dit een kunstmatige beperking is. nVidia heeft andere GPUs waarbij DP wel volledig ingeschakeld is, en loopt dus niet achter. AMD heeft geen schaalbaar alternatief voor tessellation, en dat is ook een stukje lastiger te doen dan DP wel of niet.

Dit laatste klopt echt niet... Er zijn namelijk GEEN Maxwell gpu's die DP wel hebben... De enige quadro die tot nu toe is aangekondigt is de M6000 die dezelfde waardeloze DP performance heeft als de Titan X (het is namelijk exact dezelfde GPU).
nVidia heeft BEWUST de keuze gemaakt de FP64 cuda cores in Maxwell achterwege te laten en het is dus ook niet mogelijk deze weer "even in te voegen", tenzij je daar weer ruimte voor andere delen inleverd of de die nog groter maakt.
Waar het in het verleden dus inderdaad een kunstmatige beperking was omdat de FP64 Cuda cores waren uitgeschakeld, is dat sinds Maxwell niet meer het geval omdat ze fysiek niet meer aanwezig zijn.

[Reactie gewijzigd door Spekkie88 op 29 mei 2015 17:30]

Als ik me goed heb ingelezen komt dat voordeel bij nVidia door de implementatie van de "warp", correct?

Ik weet niet wat je gelezen hebt, maar 'warps' hebben te maken met hoe threads draaien op de compute units.
Dat heeft niet direct iets met tessellation te maken.

Verder kan ik nergens terugvinden dat de verschillende onderdelen van de GPU niet met elkaar kunnen communiceren...

Dat staat anders letterlijk zo getekend in het diagrammetje van het artikel waar je naar linkt.
Ze hebben maar 4 rasterizer units, en iedere geometry unit is hardwired aan een rasterizer unit en backend.
Dit is de 'oude' manier waarop GPUs ontwikkeld worden: zo kun je dezelfde blokken logica meerdere keren naast elkaar te copy-pasten, om zo low/mid/high-end varianten van een architectuur te bouwen.

Dit ziet er inderdaad heel cool uit en zoals je zegt is dat de manier waarop tessalation gebruikt ZOU MOETEN WORDEN. Je geeft echter zelf al aan dat dit tot op heden nog steeds niet het geval is.

Dat komt omdat AMD een blok aan het been is van game-designers.

Dus ondanks je claims dat het bij AMD voor geen meter schaalt, zie ik toch hele andere resultaten...

Nee, jij snapt niet wat er met 'schalen' bedoeld wordt.
Je vergelijkt verschillende architecturen. Schalen bedoelt dat de performance goed blijft naarmate de tessellation en dus polycount toeneemt, en dat is bij AMD duidelijk niet het geval. Boven een tessellation-factor van ongeveer 10-11 zakt de performance als een baksteen in elkaar, terwijl die bij nVidia en Intel wel overeind blijft.

Ik ben echter geen kenner op dit gebied

Dat blijkt, want je kijkt naar dingen die gaan over compute, en dat heeft niets met tessellation te maken.

GCN is al uit 2011 en loopt AMD dus maar een jaar achter.

Zo werkt het niet he?
nVidia heeft in 2010 met Fermi de state-of-the-art qua tessellation neergelegd. AMD heeft in 2015 nog steeds niets dat daarbij in de buurt komt. Dus lopen ze 5 jaar achter.

Dit laatste klopt echt niet... Er zijn namelijk GEEN Maxwell gpu's die DP wel hebben... De enige quadro die tot nu toe is aangekondigt is de M6000 die dezelfde waardeloze DP performance heeft als de Titan X (het is namelijk exact dezelfde GPU).

Er zijn wel andere GPUs. nVidia heeft die technologie gewoon op de plank, en kan deze op ieder gewild moment in een GPU inbouwen. Er zijn geen GPUs van AMD die efficiente tessellation hebben. Dat is het verschil.

Iets minder denigrerend mag ook
Ik probeer het te begrijpen en mijn gedachtegang te onderbouwen met de dingen die ik lees. Het enige wat ik van jou te horen krijg zijn claims, zonder onderbouwing...

Daarnaast zeg je eerst dit:

Vergelijk het met de tijd van de GeForce FX: nVidia bakte niks van PS2.0. Moesten developers dan maar geen PS2.0 gebruiken? Nee, die gebruikten het volop, en dwongen nVidia zo om met een goede GPU-architectuur voor PS2.0 te komen.

En vervolgens pretendeer je het volgende:

Dat komt omdat AMD een blok aan het been is van game-designers.

Daarnaast hebben we denk ik een verschillende interpretatie van schalen...
Jij zegt:

Nee, jij snapt niet wat er met 'schalen' bedoeld wordt.
Je vergelijkt verschillende architecturen. Schalen bedoelt dat de performance goed blijft naarmate de tessellation en dus polycount toeneemt, en dat is bij AMD duidelijk niet het geval. Boven een tessellation-factor van ongeveer 10-11 zakt de performance als een baksteen in elkaar, terwijl die bij nVidia en Intel wel overeind blijft.

Wat ik bedoel is dus dat dit een DESIGN KEUZE is van AMD. Zoals de grafiek die ik hierboven aanhaalde al laat zien is dat de geometry engins van AMD ook prima kunnen schalen, aangezien 2x meer engines resulteerd in 2x de performance (r9 290x vs HD 7970, beide GCN). Mijn punt is dan ook dat AMD wel degelijk betere tessalation performance "op de plank heeft liggen" mochten ze dat willen. Dit kost alleen die space en zal de die groter moeten of zal het te koste gaan van andere delen van de gpu.

Dat staat anders letterlijk zo getekend in het diagrammetje van het artikel waar je naar linkt.
Ze hebben maar 4 rasterizer units, en iedere geometry unit is hardwired aan een rasterizer unit en backend.
Dit is de 'oude' manier waarop GPUs ontwikkeld worden: zo kun je dezelfde blokken logica meerdere keren naast elkaar te copy-pasten, om zo low/mid/high-end varianten van een architectuur te bouwen.

En hoe is dat anders dan de diagrammen van nVidia?
Wat ik daar zie zijn ook alleen maar losse "modules" die met elkaar kunnen communiceren via de L2 cache (zoals ook in je eigen quote staat...)
Als je de moeite had genomen mijn gelinkte artikel over de GCN architectuur had gelezen, staat daar in AMD precies hetzelfde doet...
Mocht dit niet zo zijn of dat ik het totaal begrijp, ook prima, maar kom dan zelf ook eens met wat meer onderbouwing...

Zo werkt het niet he?
nVidia heeft in 2010 met Fermi de state-of-the-art qua tessellation neergelegd. AMD heeft in 2015 nog steeds niets dat daarbij in de buurt komt. Dus lopen ze 5 jaar achter.

AMD laat al jaren zien dat ze qua computing rondjes lopen om nVidia... is nVidia nu ook ruk en loopt het gigantisch achter?

Nogmaals mijn punt: Ja, huidige AMD gpu's blinken niet uit in tesselation en wellicht is hun implementatie niet ideaal. Daarentegen laat het verschil tussen de HD7970 en de R9 290X (puur tessalation) al zien dat er wel degelijk meer performance uit de GCN te halen valt. Alleen was dat tot op heden nog niet noodzakelijk (op TW3 na).
Het is maar net waar een bedrijf zijn prioriteiten heeft...

Er zijn wel andere GPUs. nVidia heeft die technologie gewoon op de plank, en kan deze op ieder gewild moment in een GPU inbouwen. Er zijn geen GPUs van AMD die efficiente tessellation hebben. Dat is het verschil.

Zo kan je alles goed praten natuurlijk...
Al die GPU's zullen of gebaseerd zijn op Kepler en dus niet beter presteren dan de Titan Z, of er zullen 32FP cuda cores vervangen moeten worden door FP64 cores waardoor de single precision niet zal kunnen tippen aan de Titan X, Of ze moeten de die NOG groter maken dan dat de GM200 al is, wat al de grootste ooit is...

Feit blijft dat mits nVidia ergens concessies doet er niet "even" wat DP performance tegenaan gegooid kan worden.

Als laatste krijg ik de indruk dat je nogal anti AMD bent, wat je goed recht is. Maar daardoor ook nogal wat roept. Je zegt er zelf veel verstand van te hebben en dat wil ik best geloven, al zou ik dan graag meer onderbouwing zien.

Daarnaast zijn er genoeg voorbeelden te noemen waarbij nVidia nogal "achterbaks" te werk gaat.
Voorbeelden zijn bijvoorbeeld het verschil tussen PhysX 2 en PhysX 3. Je kan claimen wat je wil maar PhysX 2 is (om welke reden dan ook) niet vooruit te branden op een cpu, terwijl PhysX 3 dit ineens wel allemaal prima kan. Zie het verschil in performance tussen metro 2033 (physX 2) en metro 2033 redux (PhysX 3).
Tevens heeft nVidia er ook een handje van features software matig te blokkeren. Ook dit is hun goed recht, maar laat bij mij wel een nare smaak achter... Bijvoorbeeld het blokkeren van GPU PhysX als er een andere primary GPU wordt ontdekt door de drivers. Een ander voorbeeld is het gebruik van gforce kaarten in een virtuele omgeving... Het officiële statement van nVidia is dat ze het "niet actief blokkeren", maar het ook niet ondersteunen... Feit is alleen wel dat bij iedere driver update steeds weer de nieuwe ontdekkingen om het aan toch aan de praat te krijgen de kop in worden gedrukt... Toeval? Dat geloof ik ondertussen niet meer.
Ook het feit dat ze weigeren ook maar enige ondersteuning te bieden aan OSS drivers stat mij persoonlijk tegen. Ondanks dat ook dit weer hun goed recht is laat het mij maar weer eens zien dat nVidia er alles aan zal doen om de concurrentie zo veel mogelijk dwars te zitten, al moeten ze over lijken... En uit eindelijk alleen gaan voor eigen gewin en daarbij totaal niet kijken naar de consument.

Het enige wat ik van jou te horen krijg zijn claims, zonder onderbouwing...

Ik onderbouw alles, maarja, als jij al het verschil niet begrijpt tussen een tessellator pipeline en een compute-architectuur, dan zul je vast ook mijn onderbouwing niet oppikken.

Daarnaast zeg je eerst dit:

[...]

En vervolgens pretendeer je het volgende:

Ja, ik ben dus consequent. Ik vind niet dat games features maar niet moeten gebruiken omdat maar 1 van de 2 fabrikanten er goede ondersteuning voor heeft.
Die andere fabrikant trekt vanzelf wel bij, of gaat failliet. Hoe dan ook, het probleem lost zich vanzelf op dan.

Daarnaast hebben we denk ik een verschillende interpretatie van schalen...

Ik heb geen 'interpretatie', ik gebruik de term gewoon zoals gebruikelijk in de wereld van software engineering.

Wat ik bedoel is dus dat dit een DESIGN KEUZE is van AMD.

Een keuze impliceert dat je twee of meer alternatieven had. AMD heeft geen alternatieven. Ze hebben gewoon nog niet zo'n architectuur ontwikkeld.
Je kunt dan net zo goed beweren dat het een 'keuze' is van AMD om geen snelle CPUs te bouwen.
Dat is geen keuze, want ze hebben die mogelijkheid gewoon niet.

Zoals de grafiek die ik hierboven aanhaalde al laat zien is dat de geometry engins van AMD ook prima kunnen schalen, aangezien 2x meer engines resulteerd in 2x de performance (r9 290x vs HD 7970, beide GCN).

Zoals ik al zei, dat is niet de juiste vergelijking. Waar je naar zou MOETEN kijken, is hoe de performance schaalt op dezelfde hardware van lage tessellation factors naar hoge tessellation factors, zie het SubD11 grafiekje. En daar zie je eigenlijk dat AMD's hardware alleen nog maar harder inzakt met meer engines (je ziet dat de rode lijn soms zelfs onder de blauwe valt). Het schaalt dus *minder* goed dan de oude aanpak.

Mijn punt is dan ook dat AMD wel degelijk betere tessalation performance "op de plank heeft liggen" mochten ze dat willen.

Omdat je nog steeds niet snapt wat schalen is.
Zoals je ziet, boven een tessellation factor van zo'n 14, is de R290X gewoon dezelfde snelheid als een 7970, terwijl de R290X een veel krachtiger GPU zou moeten zijn, en ook dus twee keer zo veel tessellation units heeft.
Zie je het probleem dan gewoon niet?
Snap je niet waar je nu naar zit te kijken bij die grafiek?

Dit kost alleen die space en zal de die groter moeten of zal het te koste gaan van andere delen van de gpu.

Het lukt nVidia anders al 5 jaar om een efficiente tessellator in competitieve GPUs te bouwen.
Zelfs Intel lukt het in hun superkleine, zuinige iGPUs. Dat is dus geen argument.
Sterker nog, zoals je in die eerdere grafiek kon zien, gaat deze bottleneck juist ten koste van de performance van andere delen van de GPU. Een R290X kan niet eens sneller zijn dan een 7970 als de tessellation factor boven de 14 komt.

Mocht dit niet zo zijn of dat ik het totaal begrijp, ook prima, maar kom dan zelf ook eens met wat meer onderbouwing...

Ik heb het al onderbouwd, ik heb de whitepaper van nVidia al gelinkt, en het relevante stuk over PolyMorph gequote.
Jij begrijpt het niet, en je WIL het niet begrijpen. Cognitieve dissonantie heet dat.
Ik heb niets meer toe te voegen aan die uitleg. Ga die whitepaper eerst maar eens goed lezen, en als je dan *gerichte* vragen stelt over dingen die je niet begrijpt, dan kan ik die toelichten. Maar hier kan ik niks mee.

AMD laat al jaren zien dat ze qua computing rondjes lopen om nVidia... is nVidia nu ook ruk en loopt het gigantisch achter?

Iets meer nuance mag ook wel. Ja, bitcoin is een leuke case voor AMD-hardware. Er zijn ook computing-taken waar nVidia beter scoort. Maar inderdaad, nVidia mag nog wel wat dingetjes aanpassen zodat ze ook beter zijn in bitcoin-achtige workloads. Daar laten ze zeker het een en ander liggen qua performance.

Daarentegen laat het verschil tussen de HD7970 en de R9 290X (puur tessalation) al zien dat er wel degelijk meer performance uit de GCN te halen valt. Alleen was dat tot op heden nog niet noodzakelijk (op TW3 na).

Nee, het laat dus juist zien dat deze aanpak NOOIT goed gaat schalen tot aan 64x. Bij 10x worden ze al ingehaald door nVidia.
Je ziet dat nVidia bijna lineair doorschaalt, waar AMD duidelijk een exponentiele dropoff heeft.

Als laatste krijg ik de indruk dat je nogal anti AMD bent

Ik ben vooral anti AMD-fanboys, die al 5 jaar lopen te huilen dat tessellation gebruiken in games niet eerlijk is. Zonder dat ze ook maar enig idee hebben waar ze over praten.

Je zegt er zelf veel verstand van te hebben en dat wil ik best geloven, al zou ik dan graag meer onderbouwing zien.

Ik weet niet of je het doorhad, maar 1 van je links was naar m'n eigen blog. Lees daar nog maar wat meer artikels, ik heb jaren geleden al genoeg over tessellation geschreven. Helaas is er nog steeds niets veranderd bij AMD.

Ik ben me vandaag pas daadwerkelijk grondig in proberen te lezen over tesselation en de verschillende implementaties tussen nVidia en AMD, jammer genoeg kan ik op het door jouw gelinkte whitepaper van nVidia bar weinig vinden over de kant van AMD, behalve jouw claim dat er bij AMD geen communicatie tussen de verschillende modules plaats kan vinden.
Wat ik uit het relevante gequote stuk van nVidia kon opmaken is dat de reden dat Polymorph werkt grotendeels komt door de gedeelde L2 cahce. Dat is dan ook de voornaamste reden dat ik uit ben gaan zoeken hoe de verschillende architecturen van nVidia en AMD in elkaar steken. Mijn bevindingen daaruit zijn (na 1 dag lezen) dat er op implementatie details geen wezenlijke verschillen zitten tussen de mogelijkheden in de verschillende architecturen.
Blijkbaar zoek ik dan in de verkeerde hoek, maar ik zou dan ook graag van jou wat concreter leesvoer over beide kanten ontvangen. (Dus ook wat meer info over de kant van AMD en inderdaad over (tesselator) pipelines in het algemeen)

Waar ik het echter niet mee eens ben is jouw mening over design keuze. Ik zie design keuze dan ook meer als een kruising van een weg. Je hebt een keuze een bepaalde weg in te slaan, maar als je die eenmaal hebt gekozen is het niet makkelijk je keuze te herzien.
Vergelijk het met de netborst P4's van intel. Ook dat noem ik een design keuze en ook daar had intel niet iets anders op de plank liggen... Intel heeft namelijk destijds het hele idee losgelaten en zijn weer verder gegaan op de P3 architectuur... Hetzelfde geld voor de AMD cpu's, dit is ook een voorbeeld waar een fabrikant een verkeerde keuze heeft gemaakt... Want ondanks dat de integer prestaties van de FX processoren echt wel een goede match waren voor de intels, bleek het gebrek aan FP prestaties een te groot gemis. Maar ook hier geld dat je niet even iets nieuws klaar hebt liggen en ook hier zie je dat men terug komt op een besluit aangezien de XEN architectuur weer meer overeenkomt met de Thubans...

Ondanks dat je mij nooit zal horen roepen dat het niet eerlijk is tesselation te gebruiken, vind ik het niet eerlijk AMD daar volledig op af te rekenen... In de PRAKTIJK is het namelijk nog steeds niet echt een issue geweest. Ook in TW3 is het meer een storm in een glas water, want 90% van de consumenten ziet niet eens het verschil tussen 64x en 16x tesselation...
In dat opzicht zou je ook kunnen stellen dat nVidia al 5 jaar lang voor niets geld en tijd heeft gestoken in een elegante oplossing.

Dus stellen dat AMD al 5 jaar achterloopt vind ik dan ook overdreven. Commercieel gezien is er voor AMD in die 5 jaar nog geen noodzaak geweest om iets te doen aan die tesselation prestaties.
Dat is ook eigenlijk wat ik bedoelde met "optimaliseren". Zowel AMD als nVidia passen hun architectuur aan, naar wat er in de praktijk het meeste voorkomt. Dit is dan ook de reden geweest voor nVidia om in Maxwell de design keuze te maken de "overtollige" FP64 cores te schrappen en die ruimte op te vullen met FP32 cores om zo de prestaties in de praktijk een boost te geven...
Als nu ineens iedereen besluit massaal gebruik te maken van DP (ook gewoon onderdeel van DX en Ogl) heeft nVidia een probleem, maar hetzelfde geld voor AMD als iedereen massaal gebruik gaat makken van hoge tesselation.

Intel is in deze helemaal een geval apart, want ondanks dat ze dan wellicht een goed uitgedachte tesselation implementatie hebben weten te fabriceren zijn ze nog steeds niet in staat een gpu te maken die er daadwerkelijk nuttig gebruik van kan maken.
Aan de andere kant speelt voor intel geld een kleinere rol dan voor nVidia en AMD, waardoor die het ook kan permitteren geld te stoppen in een nuttige feature voor de toekomst.

Ik ben me vandaag pas daadwerkelijk grondig in proberen te lezen over tesselation en de verschillende implementaties tussen nVidia en AMD, jammer genoeg kan ik op het door jouw gelinkte whitepaper van nVidia bar weinig vinden over de kant van AMD, behalve jouw claim dat er bij AMD geen communicatie tussen de verschillende modules plaats kan vinden.

Hoezo 'claim'?
Het is heel simpel: AMD implementeert tessellation op de naieve manier. Daarom is er geen mooi verhaal zoals bij nVidia's PolyMorph, want er valt niet veel over te vertellen.
AMD gaat natuurlijk niet letterlijk roepen van: "Wij kunnen niet communiceren tussen verschillende SMs", want dat klinkt niet bepaald positief. Dus een dergelijk 'bewijs' ga je inderdaad niet vinden. Maar je vindt ook nergens een aanwijzing dat het WEL kan.

Wat AMD doet, stamt nog uit de tijd van de eerste geometry shaders (een technologie die ook niet van de grond kwam vanwege bottlenecks in de pipeline). Het feit dat hun oplossing totaal niet schaalt in de praktijk is al genoeg bewijs dat hun implementatie niet schaalt.
De reden is dus dat ze niet kunnen communiceren, en dat blijkt als je hun architectuur goed bestudeert.
Of de resultaten van de benchmarks natuurlijk...
Zo zie je dus dat hun GPUs met 4 geometry engines bij lage tessellation factors sneller zijn dan die met 2 geometry engines.
Maar de performance zakt ook 2 keer zo hard in (ondanks dat de architectuur nieuwer is, en de geometry engines zelf dus ook sneller dan de oudere met 2 engines).
Dat is dus gebrek aan communicatie:
Je hebt 4 geometry engines, dus je hebt 4 pipelines waar je je polygon patches naartoe kunt sturen ipv 2.
Dus bij weinig of geen tessellation gaat dat sneller.
Maar op het moment dat iedere pipeline honderden triangles per patch moet gaan genereren zie je het probleem: Je hebt je GPU in 4 stukken verdeeld ipv 2, en die honderden triangles moeten nu door een kleiner deel van de GPU verwerkt worden, dus langzamer.
Als er communicatie was, zou je dit probleem niet zien: je verdeelt je triangles gewoon altijd evenredig over de hele GPU, ipv dat ze 'opgesloten' blijven binnen 1 van de 4 pipelines waarin ze begonnen zijn.

Wat ik uit het relevante gequote stuk van nVidia kon opmaken is dat de reden dat Polymorph werkt grotendeels komt door de gedeelde L2 cahce.

Dan snap je nog steeds totaal niet wat PolyMorph is.
PolyMorph is dus een cluster van 16 geometry engines. Dat zijn er dus sowieso al 4 keer zo veel als wat AMD heeft.
Maar de echte 'magie' zit hem erin hoe nVidia zoveel geometry engines aanstuurt: ze kunnen dus compleet parallel werken, over de HELE GPU. Patches kunnen overal vandaan komen, door ieder van deze 16 geometry engines verwerkt worden, en er zijn dan ook 4 rasterizers waar de output triangles naartoe kunnen, die de triangles door iedere SM in de GPU kunnen laten rasterizen.

Snap je uberhaupt wat er gebeurt in een tessellator eigenlijk?
In het niet-tessellation-geval heb je gewoon een lijst triangles, en die kunnen evenredig verdeeld worden over alle geometry engines in een GPU. Vanaf daar is alles 1-op-1, dus alles kan simpel gepipelined worden. 1 triangle in is 1 triangle uit. Vrij simpel. Gooi het door een rasterizer, en stuur je pixel pipelines aan.

Maar bij tessellation gebeurt er dus dit:
Je stopt er 1 polygon patch in, en de tessellator deelt dit dan op in meerdere triangles. Als je dus een hoge tessellation factor gebruikt, kan een enkele patch wel honderden of duizenden triangles voortbrengen.
Het probleem is: waar moet je heen met die triangles? Bij AMD is het antwoord: alleen naar de hardwired geometry setup/rasterizer van dat deel van de GPU. Daar zit de bottleneck. Een geometry setup/rasterizer die normaal gesproken maar 1 triangle had hoeven verwerken per keer, krijgt er nu ineens duizenden te verwerken. Dat terwijl de andere geometry setup/rasterizers op dat moment misschien idle zijn.

Bij nVidia heb je dus sowieso al meer geometry setup units, en je kunt de triangles ook nog eens naar ieder van die units forwarden. Dus zelfs bij een enorme 'explosie' van polygons kun je nog steeds efficient parallel blijven renderen.
Dat is het fundamentele verschil, en de reden waarom nVidia's aanpak wel schaalt, en die van AMD niet.

Bij nVidia is het niet een hardwired pipeline, maar een dynamisch blok dat de workloads verdeelt over de hele GPU, op basis van welke resources er idle zijn.
Zoals ik al zei, zie het als het verschil tussen in-order en out-of-order execution bij CPUs. Het idee is vrijwel hetzelfde.

Ook dat noem ik een design keuze en ook daar had intel niet iets anders op de plank liggen...

Oh jawel. Intel had ook nog de Itanium en de Pentium M/Core.
Pentum 4 was wel een foute keuze, en Intel heeft er vooral ook veel te lang over gedaan om de Pentium M/Core-tak weer als mainstream CPU-lijn te gaan gebruiken. Maar ze hadden die technologie wel degelijk in huis.

Ondanks dat je mij nooit zal horen roepen dat het niet eerlijk is tesselation te gebruiken, vind ik het niet eerlijk AMD daar volledig op af te rekenen...

Waarom niet? AMD heeft nota bene zelf altijd over tessellation geroepen. Al sinds de Radeon 8500 was men bezig met tessellation.
En nu is het eindelijk gestandaardiseerd in DX11, en nu verzaakt AMD al 5 jaar om een deugdelijke implementatie af te leveren.
Hun implementatie is typisch een geval van een checkbox-feature.
Ja, technisch gezien zit het erop, maar de implementatie is dusdanig slecht dat je er in de praktijk niets mee kunt.
Dat verhaal hadden we ook al met de geometry shader in DX10. Daar kon je in de praktijk ook niets mee, vanwege dezelfde bottleneck.

In dat opzicht zou je ook kunnen stellen dat nVidia al 5 jaar lang voor niets geld en tijd heeft gestoken in een elegante oplossing.

Nee, want nVidia heeft dat gewoon 5 jaar geleden in 1 keer goed gedaan. Sindsdien hebben ze PolyMorph vrijwel onveranderd in hun nieuwe ontwerpen toegepast. Dat heeft ze dus weinig extra tijd en geld gekost.
AMD moet die stap ooit nog gaan maken, en die gaat pijn doen.

Dat is ook eigenlijk wat ik bedoelde met "optimaliseren". Zowel AMD als nVidia passen hun architectuur aan, naar wat er in de praktijk het meeste voorkomt.

Dat is onzin, tessellation was er al veel eerder dan dat er games waren die het gebruikten.
Zelfs nu nog zijn de games met tessellation op 1 hand te tellen.
Het aantal games dat tessellation gebruikt zoals het bedoeld is, is 0.
Dat komt mede door de consoles. Pas sinds de Xbox One/PS4 hebben die ook een DX11-compatible tessellator aan boord... Maar helaas, ook die is van AMD, dus ook die schaalt niet.

Dit is dan ook de reden geweest voor nVidia om in Maxwell de design keuze te maken de "overtollige" FP64 cores te schrappen en die ruimte op te vullen met FP32 cores om zo de prestaties in de praktijk een boost te geven...

Niet helemaal vergelijkbaar.
FP64 is typisch een feature voor niet-grafische toepassingen. Voor graphics heb je genoeg aan FP32. Misschien dat nVidia uit de Tesla-hoek signalen kreeg dat FP64 niet belangrijk genoeg is (ook daar kunnen ze vast de meeste berekeningen wel met FP32 af, en alleen FP64 gebruiken in uitzonderlijke gevallen).
Sowieso moeten we het nog zien, want GM200 is nog niet officieel geintroduceerd.

Maar tessellation is een techniek die nog niet echt van de grond gekomen is, en het is overduidelijk dat schaalbaarheid de sleutel is.
Heb je wel eens gehoord van Pixar? En van RenderMan? Moet je eens wat over lezen. Zij gebruiken een REYES-renderer.
In feite komt het er op neer dat ze alles modelleren met bezier-patches, die via tessellation worden onderverdeeld tot 'micropolygons': polygons kleiner dan 1 pixel. Deze worden dan 'gesplat' in een soort supersampling-buffer, en dan wordt er anti-aliasing toegepast.

De reden hiervoor is dat ze op enorm hoge resoluties renderen, en tessellation is de enige manier om efficient tot het 'ideaal' van micropolygons te komen. Als je iedere polygon apart in je mesh wil opnemen en renderen, dan lopen de memory requirements compleet uit de hand. En ook de processing is dan niet meer te doen. Tessellation is namelijk niet alleen 'geometry compression', maar het maakt bepaalde zaken ook nog eens efficienter.
Zo doe je animatie op je low-res control mesh, en daarna doe je pas tessellation. Daardoor hoef je dus veel minder polygons te animeren.

Willen we dus 'Pixar-kwaliteit' graphics in games, dan moeten we dat via tessellation doen. En hoe beter de hardware kan schalen naar hoge mate van subdivision, hoe efficienter alles wordt.

Er is dus een heel duidelijk aanwijsbare reden waarom je goede tessellation in graphics hardware wil.
In tegenstelling tot DP64.

Intel is in deze helemaal een geval apart, want ondanks dat ze dan wellicht een goed uitgedachte tesselation implementatie hebben weten te fabriceren zijn ze nog steeds niet in staat een gpu te maken die er daadwerkelijk nuttig gebruik van kan maken.

Onderschat Intel niet. Hun GPUs zitten behoorlijk goed in elkaar. Ze richten zich dan wel alleen op low-end, maar daarin zijn ze wel goed. Hun GPUs zijn erg efficient als je ziet met hoe weinig transitors Intel eigenlijk werkt. Want dat is voor Intel het meest interessant: GPUs die zo goedkoop mogelijk te produceren zijn, en zo min mogelijk stroom verbruiken.
Als Intel hun huidige architectuur zou opschalen naar het formaat van een high-end AMD/nVidia GPU, dan zou je nog wel eens raar kunnen staan kijken van hoe goed dat eigenlijk wel is.

Ik heb zelf een Bay Trail laptop met Intel GPU die maar 2 EUs heeft... Twee! Dat is eigenlijk niks! En toch kun je daar lichte games op spelen (Half-Life2 of Portal is geen probleem). Stel je voor als je er iets van 1024 van had, en dan ook nog eens wat hoger geklokt dan in een SoC van 4-6W.

[Reactie gewijzigd door Scalibq op 31 mei 2015 12:24]

Dan snap je nog steeds totaal niet wat PolyMorph is.
PolyMorph is dus een cluster van 16 geometry engines. Dat zijn er dus sowieso al 4 keer zo veel als wat AMD heeft.
Maar de echte 'magie' zit hem erin hoe nVidia zoveel geometry engines aanstuurt: ze kunnen dus compleet parallel werken, over de HELE GPU. Patches kunnen overal vandaan komen, door ieder van deze 16 geometry engines verwerkt worden, en er zijn dan ook 4 rasterizers waar de output triangles naartoe kunnen, die de triangles door iedere SM in de GPU kunnen laten rasterizen.

Duidelijk verhaal dankje.

Snap je uberhaupt wat er gebeurt in een tessellator eigenlijk?

ja ik snap het principe van tesselation, maar inderdaad niet hoe dat precies verwerkt wordt door de verschillende onderdelen van een GPU.

Dat is onzin, tessellation was er al veel eerder dan dat er games waren die het gebruikten.
Zelfs nu nog zijn de games met tessellation op 1 hand te tellen.
Het aantal games dat tessellation gebruikt zoals het bedoeld is, is 0.
Dat komt mede door de consoles. Pas sinds de Xbox One/PS4 hebben die ook een DX11-compatible tessellator aan boord... Maar helaas, ook die is van AMD, dus ook die schaalt niet.

En dat is de schuld van AMD? Er gaan ook zat geruchten rond dat nVidia na hun ervaringen met de vorige generatie consoles er zelf niet op in is gegaan... Als ze AMD echt een hak hadden willen zetten op dat gebied had nVidia er JUIST op in moeten gaan.

Niet helemaal vergelijkbaar.
FP64 is typisch een feature voor niet-grafische toepassingen. Voor graphics heb je genoeg aan FP32. Misschien dat nVidia uit de Tesla-hoek signalen kreeg dat FP64 niet belangrijk genoeg is (ook daar kunnen ze vast de meeste berekeningen wel met FP32 af, en alleen FP64 gebruiken in uitzonderlijke gevallen).

Want CAD is geen grafische toepassing?

Sowieso moeten we het nog zien, want GM200 is nog niet officieel geintroduceerd.

Sterker nog de GM200 is zelfs al te koop in de vorm van de Titan X...

Onderschat Intel niet. Hun GPUs zitten behoorlijk goed in elkaar. Ze richten zich dan wel alleen op low-end, maar daarin zijn ze wel goed. Hun GPUs zijn erg efficient als je ziet met hoe weinig transitors Intel eigenlijk werkt. Want dat is voor Intel het meest interessant: GPUs die zo goedkoop mogelijk te produceren zijn, en zo min mogelijk stroom verbruiken.
Als Intel hun huidige architectuur zou opschalen naar het formaat van een high-end AMD/nVidia GPU, dan zou je nog wel eens raar kunnen staan kijken van hoe goed dat eigenlijk wel is.

Als je de gpu's gaat vergelijken tussen intel en de AMD apu's zal je zien dat de performance per watt redelijk gelijk ligt. Daarnaast zie je ook dat er bij de AMD apu's nog erg veel te winnen is als je die koppelt aan snel geheugen.

En opschalen is juist vaak waar de problemen ontstaan...

Ik heb zelf een Bay Trail laptop met Intel GPU die maar 2 EUs heeft... Twee! Dat is eigenlijk niks! En toch kun je daar lichte games op spelen (Half-Life2 of Portal is geen probleem). Stel je voor als je er iets van 1024 van had, en dan ook nog eens wat hoger geklokt dan in een SoC van 4-6W.

Dat is maar net wat voor naampje je beestje geeft...
De nieuwe APU's van AMD hebben zelfs maar 8 grafische "cores" en die rennen rondjes om de 48! EU's van intel...

Ook het AMD AM1 platform heeft vergelijkbare prestaties tegen een vergelijkbaar verbruik als de intel bay trails...

En dat is de schuld van AMD?

Het is de schuld van AMD dat er geen goede tessellator in de XB1/PS4 zit.

Want CAD is geen grafische toepassing?

Voor CAD heb je geen double-precision nodig.
Voor CAM/CAE misschien wel, in beperkte mate, maar dat is geen grafische toepassing.
Dus ja, sorry, maar ik krijg de indruk dat je maar wat roept.

Sterker nog de GM200 is zelfs al te koop in de vorm van de Titan X...

Klopt ja, ik zat te denken aan Tesla-varianten.
Maar het schijnt dat nVidia daar niet de GM200 voor gaat gebruiken, maar een andere chip.
We gaan het zien.
Op de Quadro gebruiken ze iig wel de GM200, die dezelfde FP64-performance heeft als de Titan... en dat is geen belemmering voor CAD-software, zoals je kunt zien: http://www.tomsitpro.com/...quadro-m6000,2-898-2.html

En opschalen is juist vaak waar de problemen ontstaan...

Bij GPUs juist niet, want die zijn embarassingly parallel (met uitzondering van tessellation dus, maar dat heeft Intel al aardig onder de knie).

Dat is maar net wat voor naampje je beestje geeft...
De nieuwe APU's van AMD hebben zelfs maar 8 grafische "cores" en die rennen rondjes om de 48! EU's van intel...

Wel apples-to-apples vergelijken, dit tabelletje geeft een aardige indruk: http://www.anandtech.com/...ew-core-i74950hq-tested/2

Ook het AMD AM1 platform heeft vergelijkbare prestaties tegen een vergelijkbaar verbruik als de intel bay trails...

Wat dus alleen maar mijn stelling onderstreept: Intel kan prima meekomen met een 'specialist' op het gebied van GPUs.

[Reactie gewijzigd door Scalibq op 1 juni 2015 13:02]

Klopt ja, ik zat te denken aan Tesla-varianten.
Maar het schijnt dat nVidia daar niet de GM200 voor gaat gebruiken, maar een andere chip.
We gaan het zien.
Op de Quadro gebruiken ze iig wel de GM200, die dezelfde FP64-performance heeft als de Titan... en dat is geen belemmering voor CAD-software, zoals je kunt zien: http://www.tomsitpro.com/...quadro-m6000,2-898-2.html

Ik weet niet hoor maar ik zie in die review dat de M6000 (top of the line Maxwell) daar vaker wordt afgetroefd door de vorige generatie Kepler chips dan andersom...

Wat dus alleen maar mijn stelling onderstreept: Intel kan prima meekomen met een 'specialist' op het gebied van GPUs.

Low end wel. High end wordt het ineens anders. Hoe sterker de grafische chips, hoe groter de verschillen worden ten gunste van de AMD apu's... Het blijft uit eindelijk koffiedik kijken en moeilijk te vergelijken aangezien er in beide gevallen ook nog rekening gehouden moet worden met het cpu gedeelte. Dus 1 op 1 vergelijken van de gpu's blijft lastig.
Wel zie je dat er bij AMD apu's nog genoeg te winnen valt qua performance naarmate de geheugensnelheid toeneemt.

Hoe dan ook hoop ik ook dat AMD tesselation spoedig goed onder controle krijgt, op welke manier dan ook.

Ik weet niet hoor maar ik zie in die review dat de M6000 (top of the line Maxwell) daar vaker wordt afgetroefd door de vorige generatie Kepler chips dan andersom...

Wel even de CAD-benchmarks eruit pikken natuurlijk, daar hadden we het namelijk over.
Hij verliest vooral in 2d workloads, wat niet zo vreemd is, want dat is niet performance-kritisch, en de meeste GPUs worden gethrottled in 2d-modus. De ene GPU is wat zuiniger ingesteld dan de andere.

Wel zie je dat er bij AMD apu's nog genoeg te winnen valt qua performance naarmate de geheugensnelheid toeneemt.

Bij Intel ook, vandaar dat ze met die CrystalWell-chip hebben geexperimenteerd om de bandbreedte-problemen van een iGPU te omzeilen.
Zou ook geen verrassing moeten zijn... bandbreedte is voor een GPU veel belangrijker dan voor een CPU, en het gat tussen dedicated VRAM en shared mem is enorm groot.

Maar ook daar zie je ineens een significante verhoging in die size en transistor count (nog afgezien van het on die eDRAM). En ondanks dat de performance hard omhoog gaat ten opzichte van de HD4600, kan de iris pro op dat moment eindelijk meekomen met de apu's van AMD qua gpu. Al gaat daar dan weer het kostenplaatje meespelen...

En uiteraard is het verschil enorm tussen dedicated RAM voor de gpu en het gebruik van "het normale" RAM. Maar wat ik bedoelde is dat je bij AMD al wezenlijke verschillen zag tussen DDR3 1333 en 2133 waarbij de GPU van intel daar nauwelijks gebruik van kon maken. Met de overstap naar DDR4 zal dat gat dan ook alleen maar groter worden, tenzij Intel crystalWell gemeengoed gaat maken in zijn nieuwe cpu's.

En uiteraard is het verschil enorm tussen dedicated RAM voor de gpu en het gebruik van "het normale" RAM. Maar wat ik bedoelde is dat je bij AMD al wezenlijke verschillen zag tussen DDR3 1333 en 2133 waarbij de GPU van intel daar nauwelijks gebruik van kon maken.

Intel gebruikt ook een andere rendertechniek ('zone rendering'), die meer verwant is aan de tile-based deferred rendering van PowerVR. Deze heeft minder bandbreedte nodig: https://software.intel.co...th-intel-extreme-graphics
Een zeer interressante technologie, waar ik sinds de begindagen van de PowerVR-serie al groot fan van ben.

[Reactie gewijzigd door Scalibq op 1 juni 2015 13:53]

Interessante techniek.
Zoals ik al zei ik ben opzich bekend met termen als tesselation en de theorie er achter en ben zeer nieuwsgierig over hoe zich dat vertaald naar de verschillende onderdelen van een GPU, al heb ik daar nog weinig kaas van gegeten.
Dus als je nog meer van dit soort artikelen hebt en meer artikelen die meer ingaan op de verschillende functies van GPU's in het algemeen, zou ik die graag lezen

Zoals ik al zei ik ben opzich bekend met termen als tesselation en de theorie er achter en ben zeer nieuwsgierig over hoe zich dat vertaald naar de verschillende onderdelen van een GPU, al heb ik daar nog weinig kaas van gegeten.

Dat is dus het punt... Er zijn meer wegen die naar Rome leiden.
Zoals je ziet... jij 'denkt' weinig schaling te zien bij Intel GPUs met sneller geheugen... Maar als je weet dat de GPU juist ontworpen is met een techniek die bandbreedte bespaart, zet dat alles ineens in een heel ander licht.

Intel, nVidia en AMD doen een hoop dingen allemaal net even anders. Sowieso kan dat per generatie verschillen. Vooral de pre-DX10 GPUs werken compleet anders dan wat we vandaag hebben.

Met software-renderers heb je een vergelijkbare situatie... Er zijn verschillende algoritmen met verschillende performance-karakteristieken en mogelijkheden.
Ik heb zelf een tijdje terug een software renderer ontwikkeld voor de originele IBM 5150 PC uit 1981, met CGA.
Deze heeft enorm weinig bandbreedte, dus moest ik een renderer ontwikkelen die enigszins vergelijkbaar is met een TBDR, om de bandbreedte te minimaliseren: https://scalibq.wordpress...23/8088-mph-the-polygons/
Ook qua berekeningen was dat vrij interessant, want je hebt alleen maar 16-bit integer registers, geen FPU.

Ik heb ook wat gespeeld met een PowerVR PCX2, de tweede generatie TBDR uit 1997: https://scalibq.wordpress...t-keeping-it-real-part-6/
Vooral hun Infinite Planes-techniek is vrij bizar.

Er is zoveel te vinden over graphics... zo veel technieken ontwikkeld door de jaren... daar kun je nog heel lang op studeren

Je zou kunnen zeggen dat het eigenlijk wel goed is dat fabrikanten dergelijke optimalisaties doen.

Zolang deze effecten in games ook maar uit te zetten zijn voor bezitters van het "verkeerde" merk hoeft het niet te bijten. Jammer blijft het natuurlijk wel (om dat woord maar weer eens te gebruiken).

De fabrikanten verliezen echter kostbare energie als ieder een eigen oplossing voor bijvoorbeeld physics en haar gaat ontwikkelen. Een model waarbij fabrikanten samenwerken aan oplossingen die voor de architecturen van de verschillende fabrikanten kunnen worden geïmplementeerd zou vriendelijker zijn voor de game industrie en haar klanten. Een verdeling van onderzoeksgebieden is ook af te spreken. De ene fabrikant stort zich op physics, de andere op de simulatie van haar of van bijvoorbeeld water. De resultaten van het onderzoek komt alle fabrikanten ten goede. Implementatie en vertaling naar hardware is dan nog altijd fabrikant specifiek. Voordeel kan wel zijn dat de functionaliteit aan de softwarekant op een universele manier kan worden gebruikt.

Fabrikanten moeten dan weer terug naar de concurrentie op hoe de technieken in hardware zijn geïmplementeerd, zonder dat ze game industrie en haar kanten frustreert met het kunnen spelen van slechts een gedeelte van de games op volledige functionaliteit. Wat hierboven is geschetst kan echt wel, maar de fabrikanten moeten willen. Met de huidige fabrikant specifieke functie ondergraven ze naar mijn idee de PC markt, en daarmee verlenen ze zichzelf geen dienst.

[Reactie gewijzigd door teacup op 29 mei 2015 12:36]

Een verdeling van onderzoeksgebieden is ook af te spreken. De ene fabrikant stort zich op physics, de andere op de simulatie van haar of van bijvoorbeeld water.

Dit staat haaks op het idee van concurrentie.
Het werkt alleen als onafhankelijke partijen dit doen, zoals bv OpenGL of DX.
Helaas hebben nVidia en Intel de twee grootste onafhankelijke physics-spelers opgekocht, en is de drempel te hoog voor een nieuwe speler om in de markt te stappen.

Fabrikanten moeten dan weer terug naar de concurrentie op hoe de technieken in hardware zijn geïmplementeerd

Zo werkt het nu al. De 'optimalisaties' in games zijn slechts een verlengstuk van de GPU-architectuur. Stap 1 is en blijft om een goede GPU-architectuur te doen, die ofwel kunstjes beter kan dan de concurrent, ofwel kunstjes die de concurrent nog helemaal niet kan.
Stap 2 is om die kunstjes in een game te benutten.

De studios hebben er dus voor gekozen om gamers een zo goed mogeljke ervaring te bieden die spijtig genoeg gebasseerd is op technologie van nVidia waar AMD kaarten het moeilijk mee hebben. Moet men dan een compromis sluiten en slechtere games maken?

het is nu niet alsof er geen goede alternatieven zijn voor physx
zoals bijvoorbeeld havok van intel, word door een groot aantal games gebruikt, alleen het zord niet zo fel gepromoot/geadverteert als de oplossing van nvidia
dit is een zeer goede physics engine, gebruikt door bijvoorbeeld Valve
http://physxinfo.com/articles/?page_id=154
hier kan je een mooie piechart vinden van de gemiddelde metacritic-rating van games die physx gebruiken en games die Havok gebruiken(natuurlijk niet voledig representatief, maar wel vreemd om te zien dat 40% van games met physx een metascore onder de 50 heeft, terwijl dit bij games met Havok slechts 15% is)

[Reactie gewijzigd door jeroen7s op 29 mei 2015 14:34]

havok van intel

Ja, AMD heeft de keus: willen ze op physics-gebied verliezen van hun grootste GPU-concurrent, of van hun grootste CPU-concurrent?

hier kan je een mooie piechart vinden van de gemiddelde metacritic-rating van games die physx gebruiken en games die Havok gebruiken(natuurlijk niet voledig representatief, maar wel vreemd om te zien dat 40% van games met physx een metascore onder de 50 heeft, terwijl dit bij games met Havok slechts 15% is)

Een beetje historische context is misschien ook wel fijn:
1) Havok was de eerste 'grote' physics library.
2) Half-Life 2 van Valve was een van de eerste games die physics op grote schaal toepaste voor de gameplay (samen met Max Payne 2).
3) De Half-Life 2 engine Source is 1 van de populairste engines voor games, dus Havok lift ook mee op dat succes. Veel games die Source gebruiken, gebruiken automatisch ook Havok.
4) PhysX (voorheen NovodeX) is altijd gratis te gebruiken geweest voor kleinere/onafhankelijke game-studios. Daardoor was dit een logische keuze ipv het toen dure Havok, en kom je PhysX dus ook veel tegen in mindere titels, waar Havok vooral voor de AAA-developers was.

dat havok van intel is maakt in de praktijk eigenlijk weinig uit, havok draait zeer goed op zowel de CPU van intel als van AMD, als je dat vergelijkt met Physx, is het een groot verschil in performance (physx draait op CPU zwaar ruk, zie http://techreport.com/new...ed-on-the-cpu-by-x87-code)

het gebruik van physx in indie-titles, verklaart voor een deel het grote aantal slecht gerate games, maar als je goed op de site had gekeken, zie je dat ook het totaal aantal(niet percentage) goede en excelente (70+ en 85+) games op Havok veel hoger ligt

dat de source engine Havok gebruikt maakt eigenlijk weinig uit, in vergelijking met Unreal Engine(wat physx gebruikt) word de Source Engine zeer weinig gebruikt, zeker bij AAA developpers,
Source engine word voornamelijk gebruik in mods / door indie developpers, Titanfall is de enige recente uitzondering die door een 'echte' AAA studio gemaakt is buiten valve

(physx draait op CPU zwaar ruk, zie http://techreport.com/new...ed-on-the-cpu-by-x87-code)

Sorry hoor, wordt die onzin nu nog steeds verspreid?
David Kanter is een idioot die belachelijke claims maakte, die al lang weerlegd zijn (het verschil in Bullet tussen x87 en SSE2 bleek in de praktijk rond de 8% te liggen, en dat is puur physics-code. Op een complete game scheelt het dus nog minder qua FPS). Daarnaast speelt het verhaal al jaren niet meer, omdat nVidia inmiddels SSE standaard ingeschakeld heeft.

Daarnaaast, als je een goede vergelijking wil, moet je dezelfde physics-omgeving in zowel Havok als PhysX vergelijken. Je zult zien dat PhysX op de CPU echt niet zo rot is als AMD beweert.

[Reactie gewijzigd door Scalibq op 29 mei 2015 16:59]

het artikel is mss wel outdated, mijn comment klopt nog steeds, daarbuiten moet je ook expliciet het gebruik van SSE uitzetten bij het compilen om X87 code te gebruiken, dus nvidia wist goed genoeg dat ze een trager pad namen, zelfs 5 jaar nadat het gebruik van x87 deprecated was, daarbuiten is de vergelijking met bullet een beetje scheef, in dat voorbeeld werd scalar SSE gebruikt, terwijl met vector SSE in practijk 4 32bit-instructies in 1 cpu-clock verwerkt kunnen worden, waardoor de performance verbetering veel hoger ligt dan 8%
bij physx 3.x is het idd zwaar verbeterd (en gebruiken ze dacht ik geen x87 meer) het feit blijft dat ik veel vaker bij physx based games klachten hoor over performance drops bij physics heavy scenes, terwijl ik zelden tot nooit heb horen klagen over performance drops bij Havok games

het artikel is mss wel outdated, mijn comment klopt nog steeds

Het artikel heeft nooit geklopt, en jouw comment dus ook niet.

daarbuiten moet je ook expliciet het gebruik van SSE uitzetten bij het compilen om X87 code te gebruiken

Waar heb jij het nou weer over?

dus nvidia wist goed genoeg dat ze een trager pad namen, zelfs 5 jaar nadat het gebruik van x87 deprecated was

En dus?
Ooit gehoord van legacy? nVidia heeft deze code ook maar over overgenomen van Ageia, en die weer van NovodeX.
De code is ooit, lang geleden, ontworpen voor x87, toen SSE2 nog geen optie was.
nVidia heeft niet 'bewust' de code trager gemaakt met x87. Zij, en hun voorgangers, waren gewoon erg traag met de adoptie van SSE2. Dat is natuurlijk niet zo mooi, maar omdat we het maar hebben over zo'n 8% verschil in performance, slaat het verhaal van Kanter en alle reacties daarop ook weer totaal de plank mis.

daarbuiten is de vergelijking met bullet een beetje scheef, in dat voorbeeld werd scalar SSE gebruikt, terwijl met vector SSE in practijk 4 32bit-instructies in 1 cpu-clock verwerkt kunnen worden, waardoor de performance verbetering veel hoger ligt dan 8%

Nee, dat is nou juist het probleem. Kanter, jij, en alle andere figuren die nog nooit een assembler van dichtbij gezien hebben, denken dat SSE2 iets magisch is (want dat vertelt Intel jullie altijd, en alles wat Intel zegt is waar, toch? Alles wat AMD zegt is ook altijd waar, heb ik hier op tweakers.net geleerd).
Ja, in theorie kun je in sommige ideale geisoleerde cases best leuke micro-optimalisaties doen met SSE2.
Maar we hadden het hier over een physics-library, en daar is de performance helemaal niet zo direct afhankelijk van de ruwe processing power.
De vergelijking was dus met Bullet, die geoptimaliseerd *en* gevectoriseerd is voor SSE2, en dat uitschakelen en alles x87-only maken, scheelde dus maar 8%.
Assembly-programmeurs kijken daar niet van op, want die weten dat SSE2 in de praktijk meestal niet zo spectaculair veel oplevert. In real-world scenarios heb je altijd nog van die problemen dat je branches hebt, cache-misses, problemen met data packen/unpacken, conversies tussen float/int en noem maar op.

het feit blijft dat ik veel vaker bij physx based games klachten hoor over performance drops bij physics heavy scenes, terwijl ik zelden tot nooit heb horen klagen over performance drops bij Havok games

Maar je begrijpt zelf ook wel dat je geen apples-to-apples vergelijkingen doet, dus dat je totaal geen conclusies kunt trekken uit zo'n vergelijking. Daarvoor moet je veel meer dingen weten... zoals hoeveel objecten er gesimuleerd worden, hoeveel iteraties per simulatie-stap, wat voor soort objecten (solidbody, softbody, ragdoll, fluid/smoke, noem maar op), hoe gedetailleerd deze objecten zijn gemodelleerd, etc.

oh en tuurlijk, physx draait totaal niet ruk op CPU, project cars:
http://steamcommunity.com...ions/0/613957600537550716
4e comment:
Nividia Panel -> PhysX - > CPU = 25fps 40% GPU
Nividia Panel -> PhysX - > Default = 60fps 100% GPU
op een i5 overclockt tot 4.8GHz

Dat zegt dus niks. We hebben totaal geen informatie over wat er berekend wordt, laat staan dat we het kunnen vergelijken met een andere API onder dezelfde workload.

De enige conclusies die je kunt trekken is: GPUs zijn sneller dan CPUs in physics.
Of misschien: Als je te zware physics load op CPU doet, zakt je framerate in.
Beiden open deuren, toch?

[Reactie gewijzigd door Scalibq op 29 mei 2015 19:59]

Dat zegt dus niks. We hebben totaal geen informatie over wat er berekend wordt, laat staan dat we het kunnen vergelijken met een andere API onder dezelfde workload.

De enige conclusies die je kunt trekken is: GPUs zijn sneller dan CPUs in physics.
Of misschien: Als je te zware physics load op CPU doet, zakt je framerate in.
Beiden open deuren, toch?

dus zijn er 2 opties
1) de developper heeft veel te zware physics in zijn game zitten, aangezien een moderne CPU die ook nog eens overclockt is het niet kan draaien
2) physx draait zwaar ruk op CPU, want het is bijlange na niet de enige game die klachten heeft in verband met physx

2) physx draait zwaar ruk op CPU, want het is bijlange na niet de enige game die klachten heeft in verband met physx

Dat kun je niet concluderen zonder een directe vergelijking.
Sowieso impliceert dat nog steeds optie 1, want ongeacht hoe snel of langzaam een physics library draait, het is niet de bedoeling dat een game niet soepel kan draaien.
Maar meestal hebben games meerdere detail-settings daarvoor.

[Reactie gewijzigd door Scalibq op 30 mei 2015 10:36]

Zover ik weet is dat Physx verhaal ondertussen achterhaald en draait het in veel instanties gewoon op de CPU (developers kunnen hiervoor kiezen), zoals volgens mij bij Project Cars ook het geval is.

De zogenaamde physics zijn ook helemaal niet zo zwaar in dit spel als men je wilt doen geloven (in ieder geval niet noemenswaardig zwaarder dan in Forza/GT/rfactor etc etc), voornamelijk omdat het ook op consoles moet draaien.

De zogenaamde physics zijn ook helemaal niet zo zwaar in dit spel als men je wilt doen geloven (in ieder geval niet noemenswaardig zwaarder dan in Forza/GT/rfactor etc etc), voornamelijk omdat het ook op consoles moet draaien.

physics niet zo zwaar
http://steamcommunity.com...ons/0/613957600537550716/
Nividia Panel -> PhysX - > CPU = 25fps 40% GPU
Nividia Panel -> PhysX - > Defult = 60fps 100% GPU
op een overclockte i5 op 4.8 GHz
en zo zijn er meerdere posts op steam
en het ergste van al is dan dat de developper 'Leviathan' claimt dat physx altijd op de CPU draait niet op de GPU

De gamestudio's programmeren op abstractielagen die anders geimplementeerd worden door AMD / nVidia. Vaak zie je ook dat games (en vooral engines) in samenwerking met een van die partijen ontwikkeld worden - voor die partij draaien ze dan goed, de andere minder. Zoals ook hier.

Waarschijnlijk zijn het best smerige praktijken onderwater.

Ik betwijfel of de game studios er veel aan kunnen doen. In tegenstelling tot OpenGL kunnen Nvidia en AMD niet zelf functies toevoegen aan Direct3D die dan alleen op hun kaarten werken.

Het enige wat ze misschien kunnen doen is meten welke functionaliteit erg traag is op AMD/Nvidia hardware en kijken of er een alternatieve functie is die betere performance levert. Maar gezien gpu fabrikanten geen funcies mogen toevoegen aan Direct3D is zal er wss niet een functie zijn die 100% hetzelfde doet en veel sneller is.

Bron:
http://en.m.wikipedia.org...on_of_OpenGL_and_Direct3D (Onder het kopje extensions)

[Reactie gewijzigd door mathijs727 op 29 mei 2015 11:34]

Ik draai deze game vanaf het begin met mijn r9 290 zonder problemen, geen vastlopers helemaal niets. Is er iemand die kan bevestigen dat deze beta versie goed is en dus daadwerkelijk voor verbetering zorgt?

Ik draai deze game vanaf het begin met mijn r9 290 zonder problemen, geen vastlopers helemaal niets. Is er iemand die kan bevestigen dat deze beta versie goed is en dus daadwerkelijk voor verbetering zorgt?

Hij draait nu nog veel beter dan eerst project cars met de nieuwe beta driver! voor wicher 3 hoef je het niet te doen! ik merk er weinig tot niks van! ook een r290x in the pocket!

Hey,

Bedankt voor je reactie, ik heb hem van het weekend geïnstalleerd inderdaad. Merk er weinig van, maar hij loopt nog wel stabiel. Dat vind ik het belangrijkste.

ja ik heb zelfs reshade+sweet fx er naast draaien zonder crashes! win 8.1 64 BIT.
Ik merk met project cars verschil in FPS! bij witcher helaas niet maar die ging al goed.
Grrr * Oh shit ik hoor een Necker attack! ik moet weg ciao!

Bij The Witcher 3 zouden de prestaties met circa 10 procent stijgen als er een videokaart uit de R9- of R7-serie met één gpu wordt gebruikt.

Betekent dit dat ik buiten de boot val met een AMD 7950? Is in principe nagenoeg gelijk aan een R9 280. Lijkt me een rare kunstmatige beperking mocht dit het geval zijn.

Nee hoor, doodleuk je tesselation lager zetten, en wat andere bijna onzichtbare trucs toepassen. Draait het goed genoeg. Alleen je hebt minder pats-powerr want je settings zijn niet maximaal. Don't worry, just play.

Ik kan het tot mijn verbazing al bijzonder goed spelen als ik hairworks uitzet op 2560x1440 (medium met een flink aantal settings handmatig op high gezet). In dit artikel wordt echter aangegeven dat de boost die deze driver versie geeft enkel een prestatie geeft op de R7/R9 kaarten.
De R9 280 is zower ik weet een rebranded 7950 (en de 280x een 7970).

Waren er problemen dan ?
Ik heb beide games (Pcars al sinds early alpha) en heb met beide totaal geen problemen gehad hoor lopen prima.

Heb een Sapphire R9 290 Tri-x en FX-8350 cpu

Er zijn tal van problemen op games die door Nvidia Gameworks worden geoptimaliseerd.

Zelf mensen met een Keplar gpu van 1 generatie terug van Nividia liept niet goed en Nvidia is bezig drivers te maken om ook voor deze gpu's de game beter te laten lopen.

We praten hier over gpu's die vorig jaar gewoon in de 700 euro price range zaten....

Neem een kijkje op de Nvidia offical forums en je ziet tall van problemen met keplar gpu's.

Ach het advies is daar ook simpel: upgraden naar een nieuwe kaart, of spel niet meer spelen. Eigenlijk heel simpel, optimaliseren doe je voor iets dat je verkoopt, niet voor oud spul, of de concurrent. Als je toevallig je eigen 'fans' die al een jaar (!) niks meer kopen in de voet schiet, so be it. Misschien halen ze dan wel een 970, of als ze die bus wantrouwen wel een 980. Overstappen naar het andere kamp doen ze toch niet, want daar is de performance in $(spel) ook niet beter... zo lang je de developers maar betaalt. Daarnaast zijn potentiele overstappers af te schrikken met horrorverhalen over drivers, een beetje pushen van je reviewers, en outright bullshit verkopen op fora.
Eigenlijk had deze post 100% cynisch moeten zijn... maar hij is helaas waar

Al die verhalen over gemene politieke spelletjes zijn wat mij betreft broodje aap verhalen, als AMD de grootste zou zijn zouden zij de boosdoener zijn.

sorry maar dat is gewoon niet waar. Als AMD iets nieuws bedenkt maken ze er een open standaard van,. AMD investeerd dus wel degelijk, en investeert ipv alleen in hun eigen, in de gehele PC markt.

nvidia is alleen geïnteresseerd in hun eigen hagje, en is bereid om de prestaties op hun eigen kaarten te verlagen zolang er maar meer word ingeboet op de AMD kaarten.

Ten tweede lees je al zeker een jaar of 15 dit soort berichten dat AMD drivers achter de feiten aanlopen...

omdat nvidia al 15 jaar grote zakken geld aan bied aan de niet technische mensen bij game developers om nvidia-only technologie te gebruiken, inclusief een clausule die zegt dat er geen broncode van de game naar AMD mag.

[Reactie gewijzigd door Countess op 29 mei 2015 14:57]

gemene politieke spelletjes, zal wel meevallen, maar ja ...
In het bedrijfsleven bestaat dat dus echt wel. Zeker als je een grote speler bent.

Goed nieuws, beter laat dan nooit. Wel opmerkelijk dat het best lang heeft geduurd voordat cfx werd ondersteund voor één van de grootste releases van het jaar (TW3). AMD zal het wel druk hebben om de 3xx serie uit te brengen...

Die optimalisatie-handleiding kan ik geen optimalisaties noemen omdat ze het uiteindelijke resultaat verslechteren. Bij de Witcher moet bijvoorbeeld AA uit. Dit zijn nog steeds work-around's en geen optimalisaties.