[Algemeen] NVIDIA Nieuwsdiscussie Topic - Deel 56

[oeLangOetan]

Verwijderd schreef op dinsdag 01 september 2015 @ 14:52:
Schijnt dat Nvidia ook Asynchronous kan gebruiken als ik dit lees?
https://www.reddit.com/r/...s_it_true_nvidia_cant_do/

Ze kunnen async compute als je enkel compute taken uitvoert. Dit is een functie die in CUDA vaak gebruikt wordt & veel winst oplevert. Het probleem is echter dat ze geen 'grafische' taken en 'compute' taken tegelijk kunnen plannen (wat je doet in een game). Hierdoor kan de async compute functionaliteit in games niet gebruikt worden.

Ik vindt het trouwens iets te ver gaan als met zegt dat nvidia async compute in dx12 niet ondersteunt. Ze ondersteunen het wel, maar het levert geen prestatie winst op. Er is niets mis met het synchroon uitvoeren van asynchrone taken.

[Phuncz]

oeLangOetan schreef op dinsdag 01 september 2015 @ 16:57:
Er is niets mis met het synchroon uitvoeren van asynchrone taken.

Natuurlijk niet, maar dan moet er ook niet de schuld gelegd worden bij "bugs" als de prestaties tegenvallen.

[oeLangOetan]

Phuncz schreef op dinsdag 01 september 2015 @ 17:02:
[...]

Natuurlijk niet, maar dan moet er ook niet de schuld gelegd worden bij "bugs" als de prestaties tegenvallen.

Tjah, das de nvidia marketing machine en die is al meer 10 jaar zo bezig. Het werkt in ieder geval, keer op keer vallen veel reviewers, ontwikkelaars & klanten voor de leugens (of het geld) van nvidia.

[Verwijderd]

Ja dat is wel jammer want zit nu met een gtx 980 ti en had hoop voor dx12 voor nieuwe effecten en niet zo zeer voor performance al is dat natuurlijk ook mooi meegenomen. Ik wil verder ook alle effecten kunnen gebruiken zonder al te veel performance hits zoals soms het geval is met gameworks effecten en hoopte dat dx 12 daar ook wat verandering in brengt.

Ik heb nu ook die nieuwe physx flex gezien in Killing floor 2 en dat koste ook veel te veel extra performance net als bij normale physx over de gpu. Beetje jammer dat dit soort mooie effecten te zwaar zijn voor mid end gpu's

[V3g3ta]

Ik heb vandaag juist een 980 Ti ontvangen en hoopte dat hij zeker zo'n 3 jaar meekan.. Hoe zit het nu met dit gedoe? Storm in een glas water?

[-The_Mask-]

Kan nog steeds gewoon 3 jaar mee, alleen zal de performance hit in sommige DX12 games groter zijn dan een nu ongeveer gelijk presterende Fury X videokaart van AMD.

[Phuncz]

Ik zou er inderdaad niet vanuit gaan dat je kaart morgen, volgende maand of zelfs volgend jaar ondermaats presteert. Het ligt er ook aan wat je verwacht en hoe de markt zich evolueert. Maar ik zou niet meteen het schip verlaten hoor

[spNk]

Verwijderd schreef op dinsdag 01 september 2015 @ 19:30:
Ja dat is wel jammer want zit nu met een gtx 980 ti en had hoop voor dx12 voor nieuwe effecten en niet zo zeer voor performance al is dat natuurlijk ook mooi meegenomen. Ik wil verder ook alle effecten kunnen gebruiken zonder al te veel performance hits zoals soms het geval is met gameworks effecten en hoopte dat dx 12 daar ook wat verandering in brengt.

Ik heb nu ook die nieuwe physx flex gezien in Killing floor 2 en dat koste ook veel te veel extra performance net als bij normale physx over de gpu. Beetje jammer dat dit soort mooie effecten te zwaar zijn voor mid end gpu's

Wat voor "effecten" had je op gehoopt dan? Ik heb eigenlijk het idee dat er weinig effecten meer bij hoeven te komen (wil je het realistisch houden), sowieso hoeft dat niet perse via DX natuurlijk.

[Verwijderd]

spNk schreef op woensdag 02 september 2015 @ 10:01:
[...]

Wat voor "effecten" had je op gehoopt dan? Ik heb eigenlijk het idee dat er weinig effecten meer bij hoeven te komen (wil je het realistisch houden), sowieso hoeft dat niet perse via DX natuurlijk.

Effecten is wat verkeerd verwoord. Ik bedoel meer foto realistische games.

[-The_Mask-]

Dat moet wel kunnen met de huidige technieken, alleen is je PC daar veel te traag voor. Dus voordat we dat gaan zien zijn we heel wat jaar en hardware verder.

[spNk]

Maar word het wel daadwerkelijk mooier zodra het foto realitisch word? Momenteel worden kleuren vaak overdreven om iets er mooier uit te laten zien.

[Verwijderd]

spNk schreef op woensdag 02 september 2015 @ 11:39:
Maar word het wel daadwerkelijk mooier zodra het foto realitisch word? Momenteel worden kleuren vaak overdreven om iets er mooier uit te laten zien.

Ja heel veel mooier dan die cartoon stijl in sniper elite. Maar het moet ook bij de game passen dus cartoon stijl hoort bij sommige games zoals borderlands

[Phuncz]

Meer performance => betere graphics => meer realistische games mogelijk.

Developers vroegen niet zo hard om DX12 (zoals het nu is) voor de grap, maar omdat ze meer kunnen doen met close-to-metal APIs. DX12 is juist om die controle die over de jaren heen verloren is gegaan terug te geven aan de developers. Je zou dus heel erg enthousiast moeten zijn voor DX12 want in tegenstelling tot een nieuwe GPU kopen biedt dat meer performance bij ondersteunde kaarten voor de gratis update naar Windows 10.

En als Windows 10 je niets zegt is er nog altijd Vulkan die er waarschijnlijk voor OS X en Linux komt.

[Verwijderd]

-The_Mask- schreef op dinsdag 01 september 2015 @ 23:23:
Kan nog steeds gewoon 3 jaar mee, alleen zal de performance hit in sommige DX12 games groter zijn dan een nu ongeveer gelijk presterende Fury X videokaart van AMD.

Dit, de performance hit zal wat groter zijn. En aangezien de 980ti nog steeds de vloer aanveegt met de FuryX in dx11 en veel harder overclocked zou ik mij geen zorgen maken.

[Verwijderd]

Phuncz schreef op woensdag 02 september 2015 @ 17:25:
Meer performance => betere graphics => meer realistische games mogelijk.

Developers vroegen niet zo hard om DX12 (zoals het nu is) voor de grap, maar omdat ze meer kunnen doen met close-to-metal APIs. DX12 is juist om die controle die over de jaren heen verloren is gegaan terug te geven aan de developers. Je zou dus heel erg enthousiast moeten zijn voor DX12 want in tegenstelling tot een nieuwe GPU kopen biedt dat meer performance bij ondersteunde kaarten voor de gratis update naar Windows 10.

En als Windows 10 je niets zegt is er nog altijd Vulkan die er waarschijnlijk voor OS X en Linux komt.

Over Vulkan gesproken komt het ook voor windows?

http://www.phoronix.com/s...NVIDIA-Vulkan-Drv-Details

Dit jaar wil Nvidia nog met Vulkan drivers komen maar dat is alleen voor Linux ?

[-The_Mask-]

Verwijderd schreef op woensdag 02 september 2015 @ 18:53:
[...]

Dit, de performance hit zal wat groter zijn. En aangezien de 980ti nog steeds de vloer aanveegt met de FuryX in dx11

Echt een groot verschil idd.

en veel harder overclocked zou ik mij geen zorgen maken.

Ik heb eigenlijk nog weinig serieuze reviews gezien waar overklokken is meegenomen. De software was bij de launch nog niet gereed, maar is dat nu wel. Er leek nogal eens een geheugenbandbreedte te kort te zijn en een 100% overklok op HBM heb ik al gezien, dus ik denk dat je een beetje te voorbarig bent.

Vergeet ook niet dat de boost klok bij nVidia toch al vaak vrij hoog is, zodat er procentueel minder ruimte is voor overklokken.


Zie hier het verschil in performance met het geheugen van 500MHz naar 560MHz.

Zelf met deze bescheiden verhoging in kloksnelheid was de winst in performance al beter dan met een nVidia GeForce GTX 980 Ti was gehaald door TechPowerUp. Dus ik zou eerst wat meer resultaten afwachten voordat je je conclusie trekt.

[sjekneck]

-The_Mask- schreef op woensdag 02 september 2015 @ 20:18:
[...]

[afbeelding]
Echt een groot verschil idd.

[...]

Ik heb eigenlijk nog weinig serieuze reviews gezien waar overklokken is meegenomen. De software was bij de launch nog niet gereed, maar is dat nu wel. Er leek nogal eens een geheugenbandbreedte te kort te zijn en een 100% overklok op HBM heb ik al gezien, dus ik denk dat je een beetje te voorbarig bent.

Vergeet ook niet dat de boost klok bij nVidia toch al vaak vrij hoog is, zodat er procentueel minder ruimte is voor overklokken.

[afbeelding]
Zie hier het verschil in performance met het geheugen van 500MHz naar 560MHz.

Zelf met deze bescheiden verhoging in kloksnelheid was de winst in performance al beter dan met een nVidia GeForce GTX 980 Ti was gehaald door TechPowerUp. Dus ik zou eerst wat meer resultaten afwachten voordat je je conclusie trekt.

Vergeet je dan ook niet om even de keerzijde van de overclock te tonen


En de conclusie van het verhaal in dat zelfde verhaal
In this graph, I'm showing full-system power draw during testing. This test has clock speeds fixed at 1100 MHz for better comparison. As you can see, power ramps up very quickly, much faster than maximum clock or performance. From stock to +144 mV, power draw increases by 27%, while overclocking potential only went up by 5% and real-life performance increases by only 3%.

En dan eronder ook nog
Looking at the numbers, I'm not sure if a 150W power draw increase for a mere 3 FPS increase is worth it for most gamers. Smaller voltage bumps to get a specific clock frequency 100% stable are alright, though.

Niet heel gunstig volgens mij De chip kan harder draaien, maar gaat sneller meer verbuiken en opwarmen dan deze sneller werkt. De fury x is duidelijk geen chip om all out te gaan. Daarom is er maar 1 versie van en mogen fabrikanten niet knoeien met de kaart.

[-The_Mask-]

sjekneck schreef op woensdag 02 september 2015 @ 23:04:

Vergeet je dan ook niet om even de keerzijde van de overclock te tonen
[afbeelding]

En de conclusie van het verhaal in dat zelfde verhaal
In this graph, I'm showing full-system power draw during testing. This test has clock speeds fixed at 1100 MHz for better comparison. As you can see, power ramps up very quickly, much faster than maximum clock or performance. From stock to +144 mV, power draw increases by 27%, while overclocking potential only went up by 5% and real-life performance increases by only 3%.

En dan eronder ook nog
Looking at the numbers, I'm not sure if a 150W power draw increase for a mere 3 FPS increase is worth it for most gamers. Smaller voltage bumps to get a specific clock frequency 100% stable are alright, though.

Niet heel gunstig volgens mij De chip kan harder draaien, maar gaat sneller meer verbuiken en opwarmen dan deze sneller werkt. De fury x is duidelijk geen chip om all out te gaan.

Verbruiksverhoging is ongeveer 125W, AC verbruiksverhoging is namelijk minder dan 150W wat dus neerkomt op ongeveer 125W DC. En dat is eigenlijk precies de verwachte verhoging.

Op 1215MHz wordt namelijk gebruik gemaakt van +0,144V dat is een spanningsverhoging van 12%.
De frequentie is bijna 16% omhoog gegaan. Hierdoor zou je dus een verbruiksverhoging verwachten van 40%. Verbruik schaalt linear met de frequentie en exponentieel met de spanning. Verbruik is echter ongeveer 50% gestegen, komt omdat er nog een constante in de berekening zit en de pomp en fan ook meer gaan verbruiken. Al met al is het toch vrij normaal. Sowieso moet je om een goede vergelijking te doen ook hetzelfde met een GTX 980 Ti doen en dat is niet gedaan.

Daarnaast zei ik al dat het geheugenbandbreedte wat aan de krappe kant was, een kleine overklok hierop gaf al duidelijke performancewinst. Als je dat niet meeneemt dan gaat de performance idd niet zoveel omhoog, dat is bij elke videokaart hetzelfde.

Daarom is er maar 1 versie van is en fabrikanten niet mogen knoeien met de kaart.

Fury X, Fury en Fury Nano. Van Fury X mogen fabrikanten hun eigen PCB en koeler maken. En van de Nano is de verplichting dat die klein blijft en een TDP van 175W blijft houden, PCB en koeler mag aangepast worden. En in de herfst komt dan nog Fury X2.

[Verwijderd]

Enige wat ik zie is performance op een resolutie waarvoor je eigenlijk 2 kaarten nodig hebt. En dat is sowieso geen feest, of je nu voor rood of groen kiest.

De vrm temps van de FuryX zijn trouwens ook bizar hoog zodra je meer voltage gaat pakken.

[ Voor 22% gewijzigd door Verwijderd op 03-09-2015 09:11 ]

[sjekneck]

-The_Mask- schreef op woensdag 02 september 2015 @ 23:27:
[...]

Verbruiksverhoging is ongeveer 125W, AC verbruiksverhoging is namelijk minder dan 150W wat dus neerkomt op ongeveer 125W DC. En dat is eigenlijk precies de verwachte verhoging.

Op 1215MHz wordt namelijk gebruik gemaakt van +0,144V dat is een spanningsverhoging van 12%.
De frequentie is bijna 16% omhoog gegaan. Hierdoor zou je dus een verbruiksverhoging verwachten van 40%. Verbruik schaalt linear met de frequentie en exponentieel met de spanning. Verbruik is echter ongeveer 50% gestegen, komt omdat er nog een constante in de berekening zit en de pomp en fan ook meer gaan verbruiken. Al met al is het toch vrij normaal. Sowieso moet je om een goede vergelijking te doen ook hetzelfde met een GTX 980 Ti doen en dat is niet gedaan.

Daarnaast zei ik al dat het geheugenbandbreedte wat aan de krappe kant was, een kleine overklok hierop gaf al duidelijke performancewinst. Als je dat niet meeneemt dan gaat de performance idd niet zoveel omhoog, dat is bij elke videokaart hetzelfde.

Voor een paar luttele fps dus, ik mis nog steeds feiten die je verhaal verhelderen. De bron waar je zelf mee komt maakt zelf duidelijk dat de winst minimaal is en het verbruik enorm toeneemt. 125W zoals je het zelf noemt voor een minimale winst is gewoon niet goed. Die chip zuipt al genoeg stroom op standaard clocks. Even 400W bij een overclock voor enkel de videokaart is gekkenwerk.

Fury X, Fury en Fury Nano. Van Fury X mogen fabrikanten hun eigen PCB en koeler maken. En van de Nano is de verplichting dat die klein blijft en een TDP van 175W blijft houden, PCB en koeler mag aangepast worden. En in de herfst komt dan nog Fury X2.

ik doelde op de Fury X. Zover ik op internet lees is er echt geen Fury X met een andere koeler of ontwerp dan de oem koeler van AMD. Ik komt ook geen aftermarket versies tegen door te zoeken ernaar.

[Blaat]

-The_Mask- schreef op woensdag 02 september 2015 @ 20:18:
[...]

[afbeelding]
Echt een groot verschil idd.

[...]

Ik heb eigenlijk nog weinig serieuze reviews gezien waar overklokken is meegenomen. De software was bij de launch nog niet gereed, maar is dat nu wel. Er leek nogal eens een geheugenbandbreedte te kort te zijn en een 100% overklok op HBM heb ik al gezien, dus ik denk dat je een beetje te voorbarig bent.

Vergeet ook niet dat de boost klok bij nVidia toch al vaak vrij hoog is, zodat er procentueel minder ruimte is voor overklokken.

[afbeelding]
Zie hier het verschil in performance met het geheugen van 500MHz naar 560MHz.

Zelf met deze bescheiden verhoging in kloksnelheid was de winst in performance al beter dan met een nVidia GeForce GTX 980 Ti was gehaald door TechPowerUp. Dus ik zou eerst wat meer resultaten afwachten voordat je je conclusie trekt.

Mooi grafiekje, maar hoeveel mensen draaien er in de praktijk 4k?

Het is algemeen bekend dat de voorsprong groter wordt naarmate de resolutie omlaag gaat. Vziw hebben de meeste pc's nog steeds 1080p of 1440p schermen en daarin is de 980ti wel een stukje sneller.

[Xtr3me4me]

Ik hou het mooi bij me GTX980Ti en er komt een 2e eraan voor sli mode. Dat van DX12, tja wacht gewoon lekker af. Maak me niet druk om 1 benchmark die gemaakt is door een amateur programmeurtje zoals meerdere al gezegd hebben.

Zodra de echte games met DX12 naar voren komt, zullen we het gauw genoeg weten en daarbij zijn deze kaarten de eerst komende 3 jaar wel meer dan genoeg

[Verwijderd]

Benchmark is toch ook wat pro AMD vermoed ik want de makers van de (Benchmark)game hebben ook aan Mantle gewerkt en dan krijg ik wel argwaan zoals velen ook hebben vanwege gameworks.

[Zeara]

Volgens mij heeft een medewerker in een van die blogs gemeldt dat zowel AMD als Nvidia even vaak langs zijn geweest op kantoor, maar dat Nvidia zelfs nauwer email contact heeft gehad over alles.

Ik heb zelf meer argwaan naar Nvidia, dat ze specifiek hebben gevraagd om bepaalde features uit de benchmark te halen. Maar goed, we moeten gewoon afwachten tot de eerste games daadwerkelijk uit zijn. Zoals de DX12 patch voor ARK en Deus Ex als voorbeelden.

[dahakon]

Xtr3me4me schreef op donderdag 03 september 2015 @ 09:58:
Ik hou het mooi bij me GTX980Ti en er komt een 2e eraan voor sli mode. Dat van DX12, tja wacht gewoon lekker af. Maak me niet druk om 1 benchmark die gemaakt is door een amateur programmeurtje zoals meerdere al gezegd hebben.

Zodra de echte games met DX12 naar voren komt, zullen we het gauw genoeg weten en daarbij zijn deze kaarten de eerst komende 3 jaar wel meer dan genoeg

Altijd goed om blij te zijn met je hardware, maar het is wel erg gemakkelijk om deze man van Oxide, samen met zijn collegae, weg te zetten als een stelletje amateurs, alleen omdat nVidia minder goed voor de dag komt dan AMD in de eerste DX12 Benchmark (die overigens onderdeel is van een echt DX12 spel).

Verwijderd schreef op donderdag 03 september 2015 @ 10:20:
Benchmark is toch ook wat pro AMD vermoed ik want de makers van de (Benchmark)game hebben ook aan Mantle gewerkt en dan krijg ik wel argwaan zoals velen ook hebben vanwege gameworks.

Een Mantle-benchmark maken is niet hetzelfde als aan Mantle werken. Mantle is een kindje van AMD in samenwerking met de makers van Frostbite.

[ Voor 47% gewijzigd door dahakon op 03-09-2015 12:32 ]

[Zeara]

dahakon schreef op donderdag 03 september 2015 @ 12:29:
[...]


Altijd goed om blij te zijn met je hardware, maar het is wel erg gemakkelijk om deze man van Oxide, samen met zijn collegae, weg te zetten als een stelletje amateurs, alleen omdat nVidia minder goed voor de dag komt dan AMD in de eerste DX12 Benchmark (die overigens onderdeel is van een echt DX12 spel).

Ik denk dat ie dat simpele benchmarkje bedoeld of je kunt zien of je GPU Async ondersteund of niet. En dus niet de AoS benchmark.

[Verwijderd]

dahakon schreef op donderdag 03 september 2015 @ 12:29:
[...]


[...]


samenwerking met de makers van Frostbite.

En Oxide

Edit.

Er is blijkbaar ook winst te behalen voor Nvidia, waar waarom wel met de gtx 770 en niet met de titan x?
http://wccftech.com/nvidi...ist-features-explained/4/

[ Voor 33% gewijzigd door Verwijderd op 03-09-2015 13:30 ]

[Indy91]

Oxide?

Volgens mij is Mantle toch ontwikkeld door:

Mantle was originally developed by AMD in cooperation with DICE starting in 2013.

[Xtr3me4me]

dahakon schreef op donderdag 03 september 2015 @ 12:29:
[...]


Altijd goed om blij te zijn met je hardware, maar het is wel erg gemakkelijk om deze man van Oxide, samen met zijn collegae, weg te zetten als een stelletje amateurs, alleen omdat nVidia minder goed voor de dag komt dan AMD in de eerste DX12 Benchmark (die overigens onderdeel is van een echt DX12 spel).

Een echt DX12 game in Alpha. Tevens is het gebasseerd op basis hoe de code geschreven is in het spel, dat houd niet gelijk in dat we nu deze 1-malige test gebasseerd op een pre-alpha gecodeerde game de Nvidia af te schrijven.

Ik denk zelf dat we Nvidia niet moeten onderschatten wat er gaat gebeuren als de daadwerkelijke DX12 games uit zullen rollen. Het kan men nog eens vies tegen vallen (Daar bedoel ik dus de AMD fan-boys mee)

Wat ik gewoon meer wil zeggen is dat er nu te haastige conclusies worden getrokken op basis van 1 spel. En zoals we al weten, zijn games altijd of Nvidia favo of AMD favo.

Kan zo maar zijn dat in de volgende DX12 game, dat Nvidia, AMD achter zich laat in benchmarks en krijg je daar weer veel blaat over.

[ Voor 14% gewijzigd door Xtr3me4me op 03-09-2015 13:44 ]

[Verwijderd]

Indy91 schreef op donderdag 03 september 2015 @ 13:34:
Oxide?

Volgens mij is Mantle toch ontwikkeld door:
[...]

Dan Baker of een andere medewerker van Oxide ook. Las het laatst nog ergens.

[Sp3ci3s8472]

Verwijderd schreef op donderdag 03 september 2015 @ 13:20:
[...]


En Oxide

Edit.

Er is blijkbaar ook winst te behalen voor Nvidia, waar waarom wel met de gtx 770 en niet met de titan x?
http://wccftech.com/nvidi...ist-features-explained/4/

Nvidia Test 1: Core i7 5960X + Geforce GTX Titan X

• DX11: 45.7 fps
• DX12: 42.7 fps

Nvidia Test 2: Core i5 3570K + Geforce GTX 770

• DX11: 19.7 fps
• DX12: 55.3 fps

http://wccftech.com/nvidi...ist-features-explained/4/
Omdat dit een tikfout is. Geloof je het zelf dat een GTX770 sneller is als een Titan X op dezelfde settings?
Denk dat elk gezond denkent mens ziet dat die waarde niet klopt.

Verwijderd schreef op donderdag 03 september 2015 @ 13:39:
[...]

Dan Baker of een andere medewerker van Oxide ook. Las het laatst nog ergens.

Nee, Frostbite en AMD, andere hebben alleen ondersteuning aangebracht in hun engines. Tenzij je een bron hebt die anders zegt.

Het gerucht gaat dat Dan Baker de posts op OC.net heeft gemaakt. Dat heeft niks te maken met of hij wel of niet aan Mantle heeft gewerkt.
Oxide heeft zich dus moeten verdedigen tegen Nvidia die hun incompetent noemt omdat er zogenaamd een MSAA bug in het spel zat. De meeste grote techsites trekken die opmerking van Nvidia in twijfel.

Verder is Oxide erg open over wat ze doen met hun spel, is de source code van hun engine al 1 jaar beschikbaar bij Intel, AMD en Nvidia. Hebben ze nauw samengwerkt met Nvidia, Nvidia heeft zowaar een shader aangeboden omdat deze sneller is op hun kaarten. Deze is door Oxide ingbouwd.

Daarnaast begint Nvidia met pushen naar Oxide om bepaalde code uit hun spel te halen. Hebben techsites zowaar een reviewguide van Nvidia gekregen om het spel te testen .
Blijkbaar neemt Nvidia die toch maar een "slechte alpha benchmark" erg serieus.

Maar natuurlijk is dit allemaal niet waar omdat Oxide niet te vertrouwen is en Nvidia nooit wat fout doet .

Voor de geinteresseerden een lijstje met spellen die allemaal Async Compute implementeren:
http://www.overclock.net/...hmarks/1800#post_24371229

Dit is natuurlijk ook een onbelangrijke DX12 feature die geen developer wil gebruiken...
Totdat Nvidia het zelf in Pascal heeft, dan wordt natuurlijk gedaan alsof ze zelf de heilige graal hebben ontdekt zoals ze hebben gedaan met tesselation .

@Spliffire hieronder
Een bak koffie mag ook helpen . Ik heb het blog wat betreft Mantle en DX12 van Oxide doorgelezen, ze geven hieraan dat ze hebben gewerkt aan het implementeren van Mantle in hun game, maar niet dat ze direct aan Mantle hebben gewerkt.

[ Voor 4% gewijzigd door Sp3ci3s8472 op 03-09-2015 14:38 ]

[Verwijderd]

Nee ook Oxide maar kan de bron niet vinden. Ik zal wel niet gezond zijn dan
http://www.techpowerup.co...e-amd-summit-2013.194485/

Nvidia doet altijd alles fout dat ontken ik niet

-Physx GPU altijd brak en niet open geldt ook voor Flex voorlopig
-Code voor gameworks alleen maar aan de gameontwikkelaar geven ipv aan iedereen zoals AMD en Intel
-Dx10.1 uit games laten zoals misschien ook hier het geval is met Acs straks.

[ Voor 87% gewijzigd door Verwijderd op 03-09-2015 14:54 ]

[Phuncz]

Verwijderd schreef op donderdag 03 september 2015 @ 10:20:
Benchmark is toch ook wat pro AMD vermoed ik want de makers van de (Benchmark)game hebben ook aan Mantle gewerkt en dan krijg ik wel argwaan zoals velen ook hebben vanwege gameworks.

Is het niet al bewezen en algemeen geweten dat GameWorks AMD én oudere Nvidia kaarten crippled, terwijl AMD Mantle een extra API is die niets aan de DX11 of DX12 API doet ? Jawel.

[Werelds]

Waarom zijn er zovelen die hier ineens proberen te beweren dat AMD hier achter zou zitten, of dat Oxide speciaal voor AMD hardware heeft geprogrammeerd? Hebben jullie niet gelezen ofzo?

- Oxide heeft een marketing deal met AMD; AMD legt daarbij verder geen beperkingen op aan Oxide m.b.t. wat ze doen met hun game
- AMD, Intel, Nvidia zijn allemaal bij Oxide over de vloer geweest. AMD en Nvidia beide 3 keer om .
- Nvidia een stuk actiever per email
- Nvidia een stuk actiever met code checkins

Quote van Oxide:

Since we've started, I think we've had about 3 site visits from NVidia, 3 from AMD, and 2 from Intel ( and 0 from Microsoft, but they never come visit anyone ). Nvidia was actually a far more active collaborator over the summer then AMD was, If you judged from email traffic and code-checkins, you'd draw the conclusion we were working closer with Nvidia rather than AMD

En voordat er weer een grapjas antwoord met "Ja maar dat komt van Oxide HUEHUEHUE" - ze kunnen zulke dingen niet zeggen als het niet waar is, want dan krijgen ze een rechtszaak van jewelste aan hun broek van Nvidia. Het is ook Nvidia die valse claims de wereld in stuurde, waarschijnlijk dachten ze dat Oxide het lef niet zou hebben zich op deze manier te verdedigen.

Feit is gewoon dat Nvidia's scheduler duidelijk niet geschikt is. Punt. Zie ook de thread op Overclockers; de scheduler is vanaf Kepler een stuk simpeler (en dus minder flexibel) die gewoon niet zo effectief is als die van AMD. Nvidia heeft toegang tot de broncode, heeft er ook aan gewerkt dus als hier iets "anti-Nvidia" in zou zitten zouden ze daar al lang melding van gemaakt hebben. Als er een betere manier was voor hun hardware hadden ze die ook al lang ingebakken.

Dit in tegenstelling tot TWIMTBP (sorry, "Gameworks").

Edit: en Oxide "amateurtjes" noemen

[ Voor 5% gewijzigd door Werelds op 03-09-2015 19:30 ]

[SAiN ONeZ]

Ik kan me nog de softwarematige dx9 implementatie op de gf5 series herinneren, daarvoor de free (hardwarematige) upgrade van 8.1 naar dx9 op de 9700pro, het uitblijven van Nvidia's dx10 drivers ttv Vista. Dx11 ging wat soepeler maar volgens mij hebben ze daar gemeend de inhaalslag weer te hebben gemaakt, gezien de huidige dx12 ontwikkelingen.

Je zou zeggen dat ze er van geleerd zouden moeten hebben..

[Sp3ci3s8472]

Mooi filmpje wat in jip en janneke taal uitlegt waarom DX12 en Async Compute leuk zijn. Het is in feite een soort van hyperthreading voor de GPU, dingen die eerder idle waren worden nu wel gebruikt.

offtopic:
Kijken op eigen risico, wordt gepresenteerd door een AMD dev

[ Voor 18% gewijzigd door Sp3ci3s8472 op 04-09-2015 00:53 ]

[Yamotek]

Eigenlijk komt het erop neer dat nvidia gewoon hogere marges qua prijs en beter geoptimaliseerde Dx11 drivers/kaarten leverden dan dat AMD dat heeft gedaan.

Dat het mooi is voor AMD dat ze over een jaar een stuk beter presterende oude kaarten hebben is leuk, maar dat betekent dat ze al die jaren al potentie hebben laten liggen... wat toch behoorlijk zonde is. Maar gezien de theoretische kracht van de kaarten is het ook niet zo vreemd dat Nvidia niet meer mee komt, AMD kaarten hebben wanneer alles maximaal benut wordt veel meer rekenkracht in huis dan de Nvidia kaarten.

Echter wordt dit met Dx11 niet gebruikt en dit is dan ook goed terug te zien in het verbruik van de kaarten. Al met al ontlopen de twee kaartfabrikanten elkaar dus niet en dat is alleen maar mooi, dan hoop ik dat ze nu weer vooral bezig gaan met nieuwe betere kaarten ontwerpen en niet elkaar tegenwerken met software'matige' features.

[Verwijderd]

SAiN ONeZ schreef op donderdag 03 september 2015 @ 20:05:
Ik kan me nog de softwarematige dx9 implementatie op de gf5 series herinneren, daarvoor de free (hardwarematige) upgrade van 8.1 naar dx9 op de 9700pro, het uitblijven van Nvidia's dx10 drivers ttv Vista. Dx11 ging wat soepeler maar volgens mij hebben ze daar gemeend de inhaalslag weer te hebben gemaakt, gezien de huidige dx12 ontwikkelingen.

Je zou zeggen dat ze er van geleerd zouden moeten hebben..

Hoe komt Nvidia aan deze techniek als AMD zijn kaarten daar voor maakt met in het achterhoofd voor Mantle amd zal dat zeker even aan nvidia vertellen? Net zoals dat Nvidia ook weer andere features heeft in dx12.

[SAiN ONeZ]

Just another API, en blijkbaar goed genoeg om door Microsoft over te nemen als de blueprint voor DX12, waar ze genoeg info over kunnen verkrijgen, het is meer een designflaw in hun hardware, terwijl ze het wel aan zagen komen, gezien de drukke mailconversaties met de betreffende benchmark makers nadat het bekend werd.

Het misbruiken van tessalation, wat ATi kaarten destijds al hadden, zij het ondermaats, is toch hetzelfde, daar hoor ik je niet over, maar dat zal wel "The way its meant to be played" zijn?

[Verwijderd]

Een blue print voor een architectuur die al gemaakt werd in 2013 terwijl toen geen dx 12 in de planning stond bij MS?

[SAiN ONeZ]

Dat komt vooral omdat MS nogal lui is, en dat inkoppertje wel gelegen kwam, zeker gezien de driveroverhead binnen DX11.

[Werelds]

Verwijderd schreef op vrijdag 04 september 2015 @ 11:16:
Een blue print voor een architectuur die al gemaakt werd in 2013 terwijl toen geen dx 12 in de planning stond bij MS?

Jij koppelt de architecturen te hard aan de software API's.

AMD heeft GCN niet ontworpen aan de hand van D3D11, D3D12, Mantle of de console API's. GCN is ontworpen om zo efficiënt mogelijk werk te kunnen verrichten. Het enige "software" gedeelte waar ze daarbij aan hebben gedacht is "hoe ziet dit er uit op een heel laag niveau?". De console API's zijn op die gedachten gebouwd; en Mantle vervolgens ook. Die laatste bestond nog niet toen GCN ontworpen werd, dat is juist een gevolg van GCN.

Nvidia aan de andere kant heeft juist wel vanuit een software perspectief gekeken. Hun architecturen zijn geschikt voor D3D11 workloads, omdat de hardware bepaalde dingen juist heel specifiek aan de software over laat. Een deel van de scheduler taken doet Nvidia gewoon in software. Ze hebben ook een vrij harde grens tussen graphics en GPGPU. Dat is technisch gezien een stap terug en is niets meer dan brute force, maar wel effectief in D3D11.

Ze waren gewoon niet voorbereid op Mantle en de gevolgen daar van. Ik denk ook niet dat AMD zo bijzonder veel kán fixen aan hun D3D11 drivers. Als je GCN en Fermi/Kepler/Maxwell vergelijkt valt toch wel op dat AMD's GPU is op gezet met de gedachte dat elke ALU in principe altijd voor elke taak inzetbaar moet zijn. De fixed function hardware (ROPs, TMUs etc) zullen altijd blijven omdat die altijd efficiënter zijn voor hun werk, maar de rest zit bij AMD vrij losjes in elkaar, vandaar ook de 8 ACEs.

[Verwijderd]

Komt er dus op neer dat Nvidia en Amd bijna de zelfde architecturen moeten hebben voor dx 12 en het nadeel nu is dat je nog meer zal zien dat de ene game beter werkt op Nvidia en de ander op AMD tot dan.

[spNk]

Nee dat hoeft helemaal niet. Er is nog altijd een driver die de vertaalslag doet naar de hardware, alleen kan er nu dus minder met software opgelost worden.

[SAiN ONeZ]

Verwijderd schreef op vrijdag 04 september 2015 @ 12:06:
Komt er dus op neer dat Nvidia en Amd bijna de zelfde architecturen moeten hebben voor dx 12 en het nadeel nu is dat je nog meer zal zien dat de ene game beter werkt op Nvidia en de ander op AMD tot dan.

Als het beter draait op Nvidia komt het door GW, draait het beter op AMD komt het ook door GW, maar dan omdat het niet geimplementeerd is


Microsofts DX12 slogan "It's Time it gets played the way it is meant to be played"

[ Voor 73% gewijzigd door SAiN ONeZ op 04-09-2015 13:08 ]

[Verwijderd]

Wat een onzin dat het gelijk door gameworks komt. Je hebt ook UR games zonder die shit en daarop zal Nvidia ook beter draaien. Het komt eerder door de game ontwikkelaar die slecht programmeert voor AMD want die heeft de course code van allles in gamework en die mag dat volledig aanpassen.

[ Voor 14% gewijzigd door Verwijderd op 04-09-2015 13:13 ]

[Sp3ci3s8472]

Verwijderd schreef op vrijdag 04 september 2015 @ 13:12:
Wat een onzin dat het gelijk door gameworks komt. Je hebt ook UR games zonder die shit en daarop zal Nvidia ook beter draaien. Het komt eerder door de game ontwikkelaar die slecht programmeert voor AMD want die heeft de course code van allles in gamework en die mag dat volledig aanpassen.

Niet alle ontwikkelaars krijgen die code. Zullen vast wel wat haken en ogen aanziten.
De meeste ontwikkelaars werken gewoon met een door Nvidia gecompilde dll. Zou me niks verbazen dat je extra moet bijbetalen als ontwikkelaar indien je de source code wilt krijgen.

[ Voor 0% gewijzigd door Sp3ci3s8472 op 04-09-2015 13:55 . Reden: soort van gratis dus ]

[Verwijderd]

Ontwikkelaars die GW gebruiken krijgen gratis de source code. Wat Nvida niet wil hebben is dat de Course code naar andere bedrijven gaat wat niets met het maken van games te maken heeft. Dat is alles wat tot nu toe bekend is over GW source code's

Many NVIDIA GameWorks components including tools, samples and binaries are freely available to all developers. For other binary or source code access please contact us at Game Works Licensing:

[ Voor 29% gewijzigd door Verwijderd op 04-09-2015 13:28 ]

[Jeroenneman]

SAiN ONeZ schreef op vrijdag 04 september 2015 @ 12:46:
[...]


Als het beter draait op Nvidia komt het door GW, draait het beter op AMD komt het ook door GW, maar dan omdat het niet geimplementeerd is


Microsofts DX12 slogan "It's Time it gets played the way it is meant to be played"

Ach, en als DX12 eenmaal echt op gang is gekomen, dan zijn zowel Nvidia als AMD weer aan de volgende generatie begonnen.

DX11 had ook echt een tijdje waarin wel games uitkwamen die het gebruiken maar dan echt minimaal (tesselation op dingen die je nauwelijks merkt, knopjes op een uniform die net iets ronder zijn, echt de minieme details). De enthousiastelingen die je nu het hardst hoort schreeuwen, staan toch ieder jaar opnieuw bij de winkel, en de mainstream klant zal het niet heel erg vinden om een beetje eye candy uit te zetten, als het verschil toch klein is.

[Sp3ci3s8472]

Jeroenneman schreef op vrijdag 04 september 2015 @ 13:27:
[...]
Ach, en als DX12 eenmaal echt op gang is gekomen, dan zijn zowel Nvidia als AMD weer aan de volgende generatie begonnen.

DX11 had ook echt een tijdje waarin wel games uitkwamen die het gebruiken maar dan echt minimaal (tesselation op dingen die je nauwelijks merkt, knopjes op een uniform die net iets ronder zijn, echt de minieme details). De enthousiastelingen die je nu het hardst hoort schreeuwen, staan toch ieder jaar opnieuw bij de winkel, en de mainstream klant zal het niet heel erg vinden om een beetje eye candy uit te zetten, als het verschil toch klein is.

DX11 heeft een andere insteek dan DX12. DX12 is vooral gericht op minder overhead.
Denk dat de adoptie van DX12 een heel stuk sneller zal zijn dan die van DX11, zie ook deze lijst.
Juist de de mainstream klanten zullen er met DX12 op vooruit gaan omdat ze meer eye candy aan kunnen zetten doordat DX12 gewoon meer performance geeft, met name als je eerder cpu limited was.

Met DX12 krijgen de huidige kaarten een langere levensduur (GCN met Async Compute en Maxwell 2.0 kaarten met andere features?). Ik ga in ieder geval het komende jaar geen nieuwe kaart kopen, ik wacht wel op de 2e generatie 14/16nm kaarten.

Edit:
Vind het opmerkelijk dat nu DX12 wordt gedownplayed. Toen Mantle uitkwam was het helemaal tof en zou dat de volgende grote stap in PC gaming worden.

[ Voor 5% gewijzigd door Sp3ci3s8472 op 04-09-2015 13:54 ]

[SAiN ONeZ]

Al in 2013 werd gewaarschuwd voor de vreemde praktijken die GW heten:

http://www.extremetech.co...opers-end-users-and-amd/2

"AMD is no longer in control of its own performance. While GameWorks doesn't technically lock vendors into Nvidia solutions, a developer that wanted to support both companies equally would have to work with AMD and Nvidia from the beginning of the development cycle to create a vendor-specific code path. It's impossible for AMD to provide a quick after-launch fix. This kind of maneuver ultimately hurts developers in the guise of helping them."

[Jeroenneman]

Sp3ci3s8472 schreef op vrijdag 04 september 2015 @ 13:52:
[...]


DX11 heeft een andere insteek dan DX12. DX12 is vooral gericht op minder overhead.
Denk dat de adoptie van DX12 een heel stuk sneller zal zijn dan die van DX11, zie ook deze lijst.
Juist de de mainstream klanten zullen er met DX12 op vooruit gaan omdat ze meer eye candy aan kunnen zetten doordat DX12 gewoon meer performance geeft, met name als je eerder cpu limited was.

Met DX12 krijgen de huidige kaarten een langere levensduur (GCN met Async Compute en Maxwell 2.0 kaarten met andere features?). Ik ga in ieder geval het komende jaar geen nieuwe kaart kopen, ik wacht wel op de 2e generatie 14/16nm kaarten.

DX12 is wel een stuk meer "werk" voor de bedrijven. DX blijft volgens Microsoft ook gewoon bestaan naast DX12. DX12 vereist dat je als dev meer aandacht besteedt aan dingen die eerst door de high level API werden geregeld. Een low-level API kan zo voordelen hebben, maar behalve flinke RTS games, zal het voordeel in de meeste games wel meevallen (net zoals Mantle in BF4).

[Verwijderd]

SAiN ONeZ schreef op vrijdag 04 september 2015 @ 13:52:
Al in 2013 werd gewaarschuwd voor de vreemde praktijken die GW heten:

http://www.extremetech.co...opers-end-users-and-amd/2

"AMD is no longer in control of its own performance. While GameWorks doesn't technically lock vendors into Nvidia solutions, a developer that wanted to support both companies equally would have to work with AMD and Nvidia from the beginning of the development cycle to create a vendor-specific code path. It's impossible for AMD to provide a quick after-launch fix. This kind of maneuver ultimately hurts developers in the guise of helping them."

Daarom hebben ze het ook open gegooid wat nog steeds word ontkent door pro AMD figuren.

[LongBowNL]

Verwijderd schreef op vrijdag 04 september 2015 @ 14:00:
[...]


Daarom hebben ze het ook open gegooid wat nog steeds word ontkent door pro AMD figuren.

Hoe bedoel je open gegooid? Open Source? Open voor developers? Open voor AMD/Intel etc.?

[-The_Mask-]

Jeroenneman schreef op vrijdag 04 september 2015 @ 13:27:
[...]


Ach, en als DX12 eenmaal echt op gang is gekomen, dan zijn zowel Nvidia als AMD weer aan de volgende generatie begonnen.

Dat wel, maar dat betekend niet dat je er nu geen rekening mee zou moeten houden. Of denk je dat iedereen jaarlijks een nieuwe videokaart koopt? Ik niet iig en volgens mij verreweg de meeste mensen niet. Het is dus wel degelijk iets om in overweging te nemen bij aankoop van een nieuwe videokaart.'

Verwijderd schreef op vrijdag 04 september 2015 @ 14:00:
[...]


Daarom hebben ze het ook open gegooid wat nog steeds word ontkent door pro AMD figuren.

Dat moet dan vandaag gebeurt zijn? Heb je een linkje naar de source code dan?...

[SAiN ONeZ]

Verwijderd schreef op vrijdag 04 september 2015 @ 14:00:
[...]


Daarom hebben ze het ook open gegooid wat nog steeds word ontkent door pro AMD figuren.

Je brandt MS/AMD af voor het hergebruiken van MANTLE voor DX12, wat er voor zorgt de GPU bakkers niet meer kunnen cheaten door software te gebruiken, terwijl Nvidia dit al jaren doet met GW/TWIMTBP en begin je te janken dat ze dit niet kunnen maken, beetje hypocriet toch?

[ Voor 28% gewijzigd door SAiN ONeZ op 04-09-2015 14:14 ]

[Verwijderd]

-The_Mask- schreef op vrijdag 04 september 2015 @ 14:11:
[...]

Dat wel, maar dat betekend niet dat je er nu geen rekening mee zou moeten houden. Of denk je dat iedereen jaarlijks een nieuwe videokaart koopt? Ik niet iig en volgens mij verreweg de meeste mensen niet. Het is dus wel degelijk iets om in overweging te nemen bij aankoop van een nieuwe videokaart.'


[...]
Dat moet dan vandaag gebeurt zijn? Heb je een linkje naar de source code dan?...

Die kun je aanvragen bij Nvidia als je een gameontwikkelaar bent staat regelrecht in rechten van gameworks.
Bron: Nvidia.com.

[SAiN ONeZ]

There's some history here, with Nvidia having a reputation for being more proprietary than AMD, which has always been seen as more of an open-source, open-dialogue, open-competition company. Indeed, Nvidia even has some history with trying to hide colluding with competitors behind trade secret law. But if it's allowed to simply lock up the open dialogue that everyone agrees makes for the best gaming ecosystem all around, the results could be quite poor for the PC gaming community as a whole. Particularly if upset AMD GPU owners who aren't aware of the background end up pointing the fingers at their co-victims of Nvidia rather than the villain itself.

bron:
https://www.techdirt.com/...w-development-tools.shtml

[Verwijderd]

Weet je wat het probleem is Als nvidia iets open gooit wil pro AMD er niets van weten omdat ze liever hebben dat Nvidia arrogant blijft en niets laat delen dus houden ze zich er stil over al is het al een dik jaar open

[-The_Mask-]

sjekneck schreef op donderdag 03 september 2015 @ 09:22:
[...]

Voor een paar luttele fps dus, ik mis nog steeds feiten die je verhaal verhelderen. De bron waar je zelf mee komt maakt zelf duidelijk dat de winst minimaal is en het verbruik enorm toeneemt.

Zoals ik al meermaals zei. De reviews zijn geschreven voordat de software voor het overklokken klaar was. Maar je kan duidelijk uit de review halen dat er een geheugenbandbreedte te kort is. Er zijn echter al overklokkers geweest nu die een 100% OC op het geheugen hebben gehaald, dan is je bottleneck natuurlijk gelijk weg.

Dus om een uitspraak te doen over de overklokbaarheid zou het nogmaals moeten worden getest, nu er wel goed werkende software voor is.

Ik komt ook geen aftermarket versies tegen door te zoeken ernaar.

Nee en ik ook niet van een Titan X. nVidia heeft bij die kaart besloten dat niet toe te laten en AMD bij de Fury X. Van mij mochten ze dat van beide wel toelaten, maar dat hebben ze dus niet gedaan en daar kun je vrij weinig aan veranderen.

[-The_Mask-]

Verwijderd schreef op vrijdag 04 september 2015 @ 14:18:
[...]


Die kun je aanvragen bij Nvidia als je een gameontwikkelaar bent staat regelrecht in rechten van gameworks.
Bron: Nvidia.com.

Ja dus nog steeds closed source.

Verwijderd schreef op vrijdag 04 september 2015 @ 14:23:
Weet je wat het probleem is Als nvidia iets open gooit wil pro AMD er niets van weten omdat ze liever hebben dat Nvidia arrogant blijft en niets laat delen dus houden ze zich er stil over al is het al een dik jaar open

Juist....

[Verwijderd]

-The_Mask- schreef op vrijdag 04 september 2015 @ 14:25:
[...]

Ja dus nog steeds closed source.

Niet voor de game ontwikkelaar die het kan aanpassen voor de gpu makers.

[haarbal]

Er is een hoop heisa over gameworks, maar tot nu toe zijn het extra effecten die gewoon uit kunnen. De rest van de code kan amd gewoon inzien, ik zie het probleem niet.

Die ashes benchmark is nu ook een hoop om te doen aangezien een 290x ongeveer hetzelfde bereikt als een 980Ti. Maar een fury X is ook niet veel sneller. Vrij complex stuk software denk, lastig om conclusies te trekken.

Momenteel zou ik neigen naar amd, maar ik wacht op de die shrink, de 670 moet het nog maar even volhouden, desnoods met graphics op xbox one niveau.

[SAiN ONeZ]

Alsof nvidia tools gaat aanreiken om de game op AMD beter te laten lopen, yeah right.

Lees vooral die laatste zin: This kind of maneuver ultimately hurts developers in the guise of helping them

[SAiN ONeZ]

haarbal schreef op vrijdag 04 september 2015 @ 14:36:
Er is een hoop heisa over gameworks, maar tot nu toe zijn het extra effecten die gewoon uit kunnen. De rest van de code kan amd gewoon inzien, ik zie het probleem niet.

Die ashes benchmark is nu ook een hoop om te doen aangezien een 290x ongeveer hetzelfde bereikt als een 980Ti. Maar een fury X is ook niet veel sneller. Vrij complex stuk software denk, lastig om conclusies te trekken.

Momenteel zou ik neigen naar amd, maar ik wacht op de die shrink, de 670 moet het nog maar even volhouden, desnoods met graphics op xbox one niveau.

Ik zou me toch flink beklopt voelen, als ik met zo een high end kaart door de maker zelf word gecrippled om de nieuwste telg beter uit de bus te laten komen, dan heb ik al met een AMD kaart, laat staan als ik er zelf een zou hebben.

[haarbal]

SAiN ONeZ schreef op vrijdag 04 september 2015 @ 14:45:
[...]
Ik zou me toch flink beklopt voelen, als ik met zo een high end kaart door de maker zelf word gecrippled om de nieuwste telg beter uit de bus te laten komen, dan heb ik al met een AMD kaart, laat staan als ik er zelf een zou hebben.

Er wordt niet gecrippled, nieuwe drivers zijn niet langzamer.

En hij was 110 inc. dus beschouw het ook niet als een high end kaart.

[Xtr3me4me]

SAiN ONeZ schreef op vrijdag 04 september 2015 @ 14:45:
[...]


Ik zou me toch flink beklopt voelen, als ik met zo een high end kaart door de maker zelf word gecrippled om de nieuwste telg beter uit de bus te laten komen, dan heb ik al met een AMD kaart, laat staan als ik er zelf een zou hebben.

Het is een benchmark op basis van eigenlijk nog niks. Alpha game en een benchmark gemaakt door een amateur.

Mensen reageren gelijk zo overhyped terwijl het net zoals altijd...een storm in een glas water is.
Nvidia heeft niet eens officieel gereageerd.

Ik heb een GTX980Ti en ik voel me niet beklopt. Want het zegt nog helemaal niks, de games zijn niet uit en het eerste spel zit zelfs nog in Alpha status. Daarnaast zijn er meerdere wegen naar rome en Nvidia zal wel met bepaalde methodes hun doen eruit halen wat eruit te halen valt.

Ik zou pas echt in de lach schieten als ze een oplossing vinden en opeens AMD weer terug in hun schaamhoek plaatsen, dan kan je me echt vegen. En dan opeens is iedereen stil

Speculeren en hier en daar wat kleine testjes zeggen niks en daarom en heel simpel gezegd, gewoon afwachten tot het moment daar is en dan pas conclusies trekken.
Van de hoogste toren schreeuwen heeft ook alleen nut als de concrete feiten daadwerkelijk op tafel liggen.

De eeuwige battle tussen nvidia en amd, telkens weer. En nvidia fan boys laten zich opfokken door amd fan boys en andersom.

Al met al, wacht ik lekker af tot de daadwerkelijke games uit zijn en de benchmarks "daarvan" naar voren komen van "meerdere" testers met "nieuwste drivers"

http://www.guru3d.com/new...ble-certain-settings.html

Quote uit de site zelf:


Conclusion / TL;DR

Maxwell is capable of Async compute (and Async Shaders), and is actually faster when it can stay within its work order limit (1+31 queues). Though, it evens out with GCN parts toward 96-128 simultaneous command lists (3-4 work order loads). Additionally, it exposes how differently Async Shaders can perform on either architecture due to how they're compiled.

These preliminary benchmarks are NOT the end-all-be-all of GPU performance in DX12, and are interesting data points in an emerging DX12 landscape.

Caveat: I'm a third party analyzing other third party's analysis. I could be completely wrong in my assessment of other's assessments
Edit - Some additional info

This program is created by an amateur developer (this is literally his first DX12 program) and there is not consensus in the thread. In fact, a post points out that due to the workload (1 large enqueue operation) the GCN benches are actually running "serial" too (which could explain the strange ~40-50ms overhead on GCN for pure compute). So who knows if v2 of this test is really a good async compute test?

What it does act as, though, is a fill rate test of multiple simultaneous kernels being processed by the graphics pipeline. And the 980 TI has double the effective fill rate with graphics+compute than the Fury X at 1-31 kernel operations..

[ Voor 40% gewijzigd door Xtr3me4me op 04-09-2015 15:11 ]

[Werelds]

spNk schreef op vrijdag 04 september 2015 @ 12:35:
Nee dat hoeft helemaal niet. Er is nog altijd een driver die de vertaalslag doet naar de hardware, alleen kan er nu dus minder met software opgelost worden.

Sterker nog, de hardware wordt belangrijker. Beter hardware ontwerp vertaalt zich veel directer naar betere performance

Jeroenneman schreef op vrijdag 04 september 2015 @ 13:57:
DX12 is wel een stuk meer "werk" voor de bedrijven. DX blijft volgens Microsoft ook gewoon bestaan naast DX12. DX12 vereist dat je als dev meer aandacht besteedt aan dingen die eerst door de high level API werden geregeld. Een low-level API kan zo voordelen hebben, maar behalve flinke RTS games, zal het voordeel in de meeste games wel meevallen (net zoals Mantle in BF4).

Nee hoor. Veel bedrijven hebben al een vertaal slag gemaakt naar de console API's of gebruiken een engine die dat heeft. In het laatste geval hoeft de developer dus niets te doen, in het eerste geval valt het werk relatief mee. En zoiets als de Copy functionaliteit in Async Compute vergt helemaal niet veel werk, terwijl het wel een easy win is. DX11 zal vast nog wel gebruikt worden voor kleine games, maar de grotere en meer ervaren studio's zullen echt wel gebruik maken van DX12.

Verwijderd schreef op vrijdag 04 september 2015 @ 13:26:
Ontwikkelaars die GW gebruiken krijgen gratis de source code. Wat Nvida niet wil hebben is dat de Course code naar andere bedrijven gaat wat niets met het maken van games te maken heeft. Dat is alles wat tot nu toe bekend is over GW source code's

Many NVIDIA GameWorks components including tools, samples and binaries are freely available to all developers. For other binary or source code access please contact us at Game Works Licensing:

Verwijderd schreef op vrijdag 04 september 2015 @ 14:00:
Daarom hebben ze het ook open gegooid wat nog steeds word ontkent door pro AMD figuren.

Verwijderd schreef op vrijdag 04 september 2015 @ 14:27:
Niet voor de game ontwikkelaar die het kan aanpassen voor de gpu makers.

Verder lezen dan je neus lang is.

- Er is niets "open gegooid", daar moet je voor betalen
- Die licentie voor de broncode is een stuk prijziger, veel developers nemen die niet
- Die broncode mag AMD echter niet inzien...dus dan moet een developer dat optimaliseren voor AMD hardware zonder de hulp van AMD?

Het is een beetje alsof ik jou turbo's voor auto motoren verkoop en tegen extra betaling krijg je ook nog de handleiding er bij. Maar je mag niet de fabrikanten van de motoren vragen hoe je die dingen het beste kunt monteren en afstellen. Dat werkt dus alleen als je al een expert bent op het gebied van die motoren.

Zie je nu in hoe scheef dit is?

[Verwijderd]

Edit
Sorry voor mijn slechte Engels .

[ Voor 106% gewijzigd door Verwijderd op 04-09-2015 15:25 ]

[Phuncz]

Wat een ongelofelijke butt-hurt in dit topic. DX12 is een feit en we moeten:
1. het nieuws, artikels en opmerkingen van developers en redacteurs negeren
2. wachten op Pascal en de eerste echte DX12 game (laat me raden, die met de UE4 engine ?)
3. blij zijn dat GameWorks zo'n meerwaarde is voor de gamers en gaming industrie

De eerste keer dat een nieuwe DX-versie effectief drastisch meer performance belooft, Nvidia scoort minder goed in de eerste tests, ze kunnen zich enkel verdedigen met verzonnen argumenten (MSAA bug), meerdere artikels hebben proefondervindelijk en theoretisch-ondersteunde gegevens waarom dit is en ineens gaat het over AMD ? Zoek het toch niet zelf, Nvidia geraakt hier heus uit en het heeft echt geen zin AMD erbij te betrekken. Het is niet omdat Nvidia nu een issue heeft die aangekaart moet (en zal) worden, dat AMD daar de oorzaak van is.

[sjekneck]

Phuncz schreef op vrijdag 04 september 2015 @ 17:17:
Wat een ongelofelijke butt-hurt in dit topic. DX12 is een feit en we moeten:
1. het nieuws, artikels en opmerkingen van developers en redacteurs negeren
2. wachten op Pascal en de eerste echte DX12 game (laat me raden, die met de UE4 engine ?)
3. blij zijn dat GameWorks zo'n meerwaarde is voor de gamers en gaming industrie

De eerste keer dat een nieuwe DX-versie effectief drastisch meer performance belooft, Nvidia scoort minder goed in de eerste tests, ze kunnen zich enkel verdedigen met verzonnen argumenten (MSAA bug), meerdere artikels hebben proefondervindelijk en theoretisch-ondersteunde gegevens waarom dit is en ineens gaat het over AMD ? Zoek het toch niet zelf, Nvidia geraakt hier heus uit en het heeft echt geen zin AMD erbij te betrekken. Het is niet omdat Nvidia nu een issue heeft die aangekaart moet (en zal) worden, dat AMD daar de oorzaak van is.

Op basis van de eerste test zijn er nu al een aantal mensen van beide kanten die met geleende info komen uitleggen hoe het wel of niet zit en ze weten het allemaal het beste. Opeens is asynchronous compute de heilige graal en de beste uitvinding sinds gesneden brood. Raar he dat mensen in een nvidia topic niet hetzelfde zeggen als in het amd topic .
Twee chipdesigns met sterke en zwakke punten. Beetje het teselation verhaal, maar dan asynchronous compute. Een beetje minder fel doordrammen zou sommige mensen sieren....

[Phuncz]

Async Compute is een op consoles reeds gebruikte technologie voor de optimale rendering performance van de engine.
Tesselation in Hairworks is een Nvidia-only technologie die gemakkelijk 30-60% performance scheelt voor bv. het wapperende haar van het hoofdpersonage.

De eerste kan een evolutie in performance teweeg brengen, de tweede kan de game onspeelbaar traag maken. Toch best een groot verschil.

[ Voor 16% gewijzigd door Phuncz op 05-09-2015 07:58 ]

[D33F]

Nieuwe statement van Oxide developer over D3D12 @ Beyond3D:

Wow, lots more posts here, there is just too many things to respond to so I'll try to answer what I can.

/inconvenient things I'm required to ask or they won't let me post anymore
Regarding screenshots and other info from our game, we appreciate your support but please refrain from disclosing these until after we hit early access. It won't be long now.
/end

Regarding batches, we use the term batches just because we are counting both draw calls and dispatch calls. Dispatch calls are compute shaders, draw calls are normal graphics shaders. Though sometimes everyone calls dispatchs draw calls, they are different so we thought we'd avoid the confusion by calling everything a draw call.

Regarding CPU load balancing on D3D12, that's entirely the applications responsibility. So if you see a case where it’s not load balancing, it’s probably the application not the driver/API. We’ve done some additional tunes to the engine even in the last month and can clearly see usage cases where we can load 8 cores at maybe 90-95% load. Getting to 90% on an 8 core machine makes us really happy. Keeping our application tuned to scale like this definitely on ongoing effort.

Additionally, hitches and stalls are largely the applications responsibility under D3D12. In D3D12, essentially everything that could cause a stall has been removed from the API. For example, the pipeline objects are designed such that the dreaded shader recompiles won’t ever have to happen. We also have precise control over how long a graphics command is queued up. This is pretty important for VR applications.

Also keep in mind that the memory model for D3d12 is completely different the D3D11, at an OS level. I’m not sure if you can honestly compare things like memory load against each other. In D3D12 we have more control over residency and we may, for example, intentionally keep something unused resident so that there is no chance of a micro-stutter if that resource is needed. There is no reliable way to do this in D3D11. Thus, comparing memory residency between the two APIS may not be meaningful, at least not until everyone's had a chance to really tune things for the new paradigm.

Regarding SLI and cross fire situations, yes support is coming. However, those options in the ini file probablly do not do what you think they do, just FYI. Some posters here have been remarkably perceptive on different multi-GPU modes that are coming, and let me just say that we are looking beyond just the standard Crossfire and SLI configurations of today. We think that Multi-GPU situations are an area where D3D12 will really shine. (once we get all the kinks ironed out, of course). I can't promise when this support will be unvieled, but we are commited to doing it right.

Regarding Async compute, a couple of points on this. FIrst, though we are the first D3D12 title, I wouldn't hold us up as the prime example of this feature. There are probably better demonstrations of it. This is a pretty complex topic and to fully understand it will require significant understanding of the particular GPU in question that only an IHV can provide. I certainly wouldn't hold Ashes up as the premier example of this feature.

We actually just chatted with Nvidia about Async Compute, indeed the driver hasn't fully implemented it yet, but it appeared like it was. We are working closely with them as they fully implement Async Compute. We'll keep everyone posted as we learn more.

Also, we are pleased that D3D12 support on Ashes should be functional on Intel hardware relatively soon, (actually, it's functional now it's just a matter of getting the right driver out to the public).

Thanks!

TL;DR

Het gaat vooral om dit stukje:

"We actually just chatted with Nvidia about Async Compute, indeed the driver hasn't fully implemented it yet, but it appeared like it was. We are working closely with them as they fully implement Async Compute. We'll keep everyone posted as we learn more."

[ Voor 3% gewijzigd door D33F op 05-09-2015 09:20 ]

[haarbal]

Sowieso zal er bij ashes nog een hoop te winnen zijn aan de nvidia kant, de dx11 versie is sneller.

[madmaxnl]

Ja voorheen was dat anders ook altijd. DX9 sneller dan DX10 etc. Meer details etc kost gewoon meer kracht en als je dan de features uit DX12 die je snelheidswinst opleveren niet, of niet goed, functioneren, tja...

[haarbal]

Maar hier is het eindresultaat identiek, als dx12 fundamenteel beter beweert te zijn moet de fps hoger zijn.

[Verwijderd]

Eerst een hoop gezeur maken die Oxide en AMD en nu in eens de boel terug draaien en zeggen dat Nvidia het wel heeft in plaats van niet. Proberen ze nu echt deze marketing toe te passen?

[The Fox NL]

Oxide en AMD hebben nooit beweerd dat Nvidia geen asynchrone shaders heeft. Oxide heeft het op raden van Nvidia uit gezet omdat het verschrikkelijk traag was. Er is wel kans dat Nvidia geen hardware schedulers heeft om het werk te verdelen en dat ze daarom de drivers moeten verbeteren omdat de huidige software implementatie van geen kanten werkt.

[Verwijderd]

Oxide: NV GPUs do not support DX12 Asynchronous Compute/Shaders. Hebben ze dus wel als feit neergezet alleen wat te snel beoordeeld en later terug gedraaid. Nvidia wou graag dat Asynchronous word uitgeschakeld maar dat is niet gebeurd.

[XanderDrake]

Wat? Wordt het nu weer in twijfel getrokken?? Grootste storm in een glas water die ik in tijden heb gezien... Man

[Sp3ci3s8472]

Verwijderd schreef op zaterdag 05 september 2015 @ 13:31:
Oxide: NV GPUs do not support DX12 Asynchronous Compute/Shaders. Hebben ze dus wel als feit neergezet alleen wat te snel beoordeeld en later terug gedraaid. Nvidia wou graag dat Asynchronous word uitgeschakeld maar dat is niet gebeurd.

Ik heb Oxide nergens die quote zien maken.
http://www.overclock.net/...hmarks/1200#post_24356995

Curiously, their driver reported this feature was functional but attempting to use it was an unmitigated disaster in terms of performance and conformance so we shut it down on their hardware. As far as I know, Maxwell doesn't really have Async Compute so I don't know why their driver was trying to expose that.

Dat tweakers het zo als feit op gooit heeft niks te maken met Oxide.

Je haalt een aantal dingen door elkaar. Ze hebben het wel uitgeschakelt maar dan alleen op Nvidia kaarten, waarom zouden ze een prima werkende feature uitschakelen alleen maar omdat het op Nvidia kaarten (nog) niet kan?

Verdraai nu steeds niet wat er wordt gezegt, lees je gewoon even goed in voor je iets post. Wat ook helpt is het "nieuws" zo dicht mogelijk bij de bron te lezen. Nieuwsites willen graag meer views krijgen door het met een spectaculaire titel/inhoud te brengen. Wat dus niet altijd correct is.

De rest van de posts die door Kollock zijn gemaakt, nergens beweert hij dat het nooit zou kunnen. Dat hebben andere mensen ervan gemaakt. Het is alleen erg dom van Nvidia dat ze de feature wel "exposen" via de driver terwijl hij nog geeneens (goed) werkt. Ben benieuwd of ze nu met een softwarematige oplossing komen of dat ze toch hardwarematige support hebben.
http://www.overclock.net/forums/posts/by_user/id/473364

[Help!!!!]

Sp3ci3s8472 schreef op zaterdag 05 september 2015 @ 18:47:
Het is alleen erg dom van Nvidia dat ze de feature wel "exposen" via de driver terwijl hij nog geeneens (goed) werkt.

Of ze dachten dat ze er mee weg konden komen, maar dat is evengoed vrij dom.

Ben benieuwd of ze nu met een softwarematige oplossing komen of dat ze toch hardwarematige support hebben.
http://www.overclock.net/forums/posts/by_user/id/473364

En dat is volgensmij de hele crux.

[Sp3ci3s8472]

Help!!!! schreef op zaterdag 05 september 2015 @ 21:54:
[...]

Of ze dachten dat ze er mee weg konden komen, maar dat is evengoed vrij dom.

[...]

En dat is volgensmij de hele crux.

Zelf denk ik na het lezen van een aantal posts op OC.net dat het een software oplossing is. Blijkbaar heeft Nvidia het gedeelte wat het normaal hardwarematig zou schedulen eruit gesloopt om daarmee stroom te besparen. Dit plus het eruitslopen van GPGPU compute dingen helpt ze om stroom te besparen.
Alleen lopen ze er nu tegen aan dat het wat pittiger wordt om het allemaal werkende te krijgen en de latency met VR laag te houden. Het is dus nog even afwachten hoe dat voor ze uitpakt.

Zie ook volgende filmpje (David Kanter blijkbaar na een Nvidia event):

[ Voor 4% gewijzigd door Sp3ci3s8472 op 06-09-2015 01:51 ]

[Nehabje]

Dit is zojuist op Overclock.net gepost: http://www.overclock.net/...wd-sourcing#post_24385652

Een heel goed topic. Is een goede samenvatting van wat er de laatste paar dagen is gebeurt, en hoe Nvidia er mee om gaat.

[XanderDrake]

Mijn take-away message is dit:

There is no underestimating nVIDIAs capacity to fix their driver. It will be fixed. As for the performance derived out of nVIDIAs HyperQ solution? Best to wait and see.

[Verwijderd]

Wat ik niet begrijp is dat Nvidia dat niet toe past of klaar heeft voor windows 10. Nvidia is altijd goed bezig met hun drivers en daar staan ze ook wel bekent om.

[Sorki]

Verwijderd schreef op maandag 07 september 2015 @ 13:31:
Wat ik niet begrijp is dat Nvidia dat niet toe past of klaar heeft voor windows 10. Nvidia is altijd goed bezig met hun drivers en daar staan ze ook wel bekent om.

AMD staat bekend om hun slechte drivers Nvidia om de goeie. Dat is zo'n beetje een mantra geworden.

Persoonlijk vind ik dat Nvidia de laatste tijd juist heel wat steken laat vallen en AMD het boeltje wat meer op orde heeft. Toegegeven, bij nvidia zit alles er veel gelikter uit

[Indy91]

Verwijderd schreef op maandag 07 september 2015 @ 13:31:
Wat ik niet begrijp is dat Nvidia dat niet toe past of klaar heeft voor windows 10. Nvidia is altijd goed bezig met hun drivers en daar staan ze ook wel bekent om.

Dan volg je het videokaarten nieuws niet zo heel lang, dunkt mij.

Volgens mij hebben in het verleden zowel nVidia als AMD wel eens de plank misgeslagen op drivergebied. Ik zal je geheugen eens wat opfrissen.
De nVidia missers:

• DX10 done wrong drivers, nVidia mistte ten tijde van de introductie van DX10 nogal wat functionaliteiten voor de oorspronkelijke DX10 API. De DX10 specificaties zijn toen naar beneden zijn bijgesteld om nVidia tevreden te stellen.
• Diverse (beta)driver releases die defecten konden veroorzaken bij een bepaalde serie nVidia kaarten.

De AMD missers:

• Zeer slechte drivers voor ATi Rage pro

Ik zou juist stellen dat nVidia NIET altijd goed bezig is met hun drivers.

[Sp3ci3s8472]

Indy91 schreef op maandag 07 september 2015 @ 15:59:
[...]

Dan volg je het videokaarten nieuws niet zo heel lang, dunkt mij.

Volgens mij hebben in het verleden zowel nVidia als AMD wel eens de plank misgeslagen op drivergebied. Ik zal je geheugen eens wat opfrissen.
De nVidia missers:

• DX10 done wrong drivers, nVidia mistte ten tijde van de introductie van DX10 nogal wat functionaliteiten voor de oorspronkelijke DX10 API. De DX10 specificaties zijn toen naar beneden zijn bijgesteld om nVidia tevreden te stellen.
• Diverse (beta)driver releases die defecten konden veroorzaken bij een bepaalde serie nVidia kaarten.

De AMD missers:

• Zeer slechte drivers voor ATi Rage pro

Ik zou juist stellen dat nVidia NIET altijd goed bezig is met hun drivers.

Je ziet op het forum dit jaar steeds vaker dat de WHQL drivers van Nvidia niet altijd lekker werken, vaak wordt dan simpelweg aangeraden om naar een oudere versie over te stappen. Natuurlijk leuk dat Nvidia vaker drivers uitbrengt maar als ze niet stabiel zijn dan heb je er weinig aan.

Je vergeet het Vista driver debakel .

http://arstechnica.com/ga...-of-buggy-nvidia-drivers/

Maar dit wordt altijd vergeten. AMD heeft zover ik weet hun drivers altijd goed op orde, het enige wat je ze kan aanmerken is dat ze bij GameWork/TWIMTBP titels wat meer werk nodig hebben (obviously) en daardoor de driver later uitbrengen.

Het verbaast mij eigenlijk altijd waarom AMD ervan wordt beschuldigt slechte drivers te hebben.

Om de zaak wat luchtiger te houden nog een filmpje betreft Async Compute .

[Phuncz]

Sorki schreef op maandag 07 september 2015 @ 14:00:
[...]


AMD staat bekend om hun slechte drivers Nvidia om de goeie. Dat is zo'n beetje een mantra geworden.

Persoonlijk vind ik dat Nvidia de laatste tijd juist heel wat steken laat vallen en AMD het boeltje wat meer op orde heeft. Toegegeven, bij nvidia zit alles er veel gelikter uit

Kom jij maar snel naar 2015, de situatie is allang niet meer zo slecht als jij ze schetst. Ik heb in twee jaren geen énkele driver-related BSOD meer gehad, zelfs niet met "beta" AMD drivers.
Edit: beter lezen, Phuncz !

[sdk1985]

Sp3ci3s8472 schreef op maandag 07 september 2015 @ 16:13:
[...]


Je ziet op het forum dit jaar steeds vaker dat de WHQL drivers van Nvidia niet altijd lekker werken, vaak wordt dan simpelweg aangeraden om naar een oudere versie over te stappen. Natuurlijk leuk dat Nvidia vaker drivers uitbrengt maar als ze niet stabiel zijn dan heb je er weinig aan.

Je vergeet het Vista driver debakel .
[afbeelding]
http://arstechnica.com/ga...-of-buggy-nvidia-drivers/

Maar dit wordt altijd vergeten. AMD heeft zover ik weet hun drivers altijd goed op orde, het enige wat je ze kan aanmerken is dat ze bij GameWork/TWIMTBP titels wat meer werk nodig hebben (obviously) en daardoor de driver later uitbrengen.

Het verbaast mij eigenlijk altijd waarom AMD ervan wordt beschuldigt slechte drivers te hebben.

Dat komt voort uit de users die nooit driver problemen hebben. De laatste keer dat ik een Nvidia driver probleem had stamt uit bij mij uit een oude hitman game (contracts, 2004?). Dat was alleen een game die ik 2 weken voor de release speelde. Tegen de tijd dat de game officieel uitkwam was het probleem (met de shadows) opgelost. De laatste keer dat ik met AMD driver problemen had was de launch van de e350 APU waarbij het ongeveer 11 maanden heeft geduurd voor het werkte zoals het hoorde.

AMD heeft de naam niet voor niets, er zijn gewoon veel voorbeelden te vinden van games waarbij de hotfix op zich liet wachten. Daarnaast hebben we het frametimes debacle gehad waarbij AMD heeft toegegeven de drivers gewoon nooit op consistentie te testen (terwijl Nvidia dit wel deed). Om van die naam af te komen (heb ik al vaker vemeld hier) zullen ze Nvidia niet moeten evenaren maar voorbij streven.

[ Voor 16% gewijzigd door sdk1985 op 07-09-2015 17:29 ]

[Sorki]

Phuncz schreef op maandag 07 september 2015 @ 17:19:
[...]

Kom jij maar snel naar 2015, de situatie is allang niet meer zo slecht als jij ze schetst. Ik heb in twee jaren geen énkele driver-related BSOD meer gehad, zelfs niet met "beta" AMD drivers.

Da's toch net wat ik zeg?

[Werelds]

Sp3ci3s8472 schreef op maandag 07 september 2015 @ 16:13:
Het verbaast mij eigenlijk altijd waarom AMD ervan wordt beschuldigt slechte drivers te hebben.

Dat heeft te maken met ATI/AMD's geschiedenis. Tussen R300 (9700/9800) en eind van R600/begin R700 ging het niet bepaald lekker met AMD. De chips waren matig en de drivers waren ronduit slecht. En laat dat nu net de periode zijn waarin velen met PC's begonnen, omdat het toen allemaal een beetje meer uit die "nerd" sfeer was geraakt dankzij e-sports. Vista is aan velen voorbij gegaan, dus dat debacle hebben ze geen last van gehad.

Dat is inderdaad al lang niet meer zo, ik heb met m'n 5870 en 6950 geen enkele keer een BSOD, driver reset of wat dan ook gehad (en dan was m'n 5870 ook een goed sample ook, 975 op de core zonder voltage verhoging - ding draait overigens nog steeds op die clocks ). Dat is met m'n G80/G92 daarvoor en m'n 460, 680, 770 en 970 wel anders. Wel is CCC gewoon een stuk stront

Er zijn wel dingen die bij Nvidia gewoon altijd slecht zijn in de drivers. Er zit te veel foute detectie in, waardoor interlaced modes voor geen meter werken. Dat was in 2005 zo en dat is nu nog steeds zo. Overscan/underscan gaat nog steeds faliekant fout en het heeft 2,5 jaar geduurd eer je dat eens bij kon stellen in de driver. Meerdere monitors is nog steeds een drama tenzij je ze in Surround gebruikt. En laten we het maar even niet over Nvidia + RGB hebben

Daarnaast is er ook een hoop onzin rondom AMD's "beta" drivers tegenover Nvidia's "WHQL" drivers. Dat WHQL label is waardeloos, het betekent alleen dat ze goed gekeurd zijn door MS. Ze zijn niet stabieler of wat dan ook. Maar ja, groen labeltje en geen waarschuwing, dus het moet wel beter zijn toch?

sdk1985 schreef op maandag 07 september 2015 @ 17:25:
AMD heeft de naam niet voor niets, er zijn gewoon veel voorbeelden te vinden van games waarbij de hotfix op zich liet wachten.

Moet je er ook wel bij vermelden dat het heel toevallig in veel van die gevallen om TWIMTBP titels gaat; of titels waar er duidelijk een relatie met Nvidia was, zoals RAGE

[ Voor 3% gewijzigd door Werelds op 07-09-2015 20:21 ]

[Phuncz]

Sorki schreef op maandag 07 september 2015 @ 20:12:
[...]
Da's toch net wat ik zeg?

Ah ja oops, heb blijkbaar me vergist met een andere reactie of een ander topic, my bad !

[dahakon]

sdk1985 schreef op maandag 07 september 2015 @ 17:25:
AMD heeft de naam niet voor niets, er zijn gewoon veel voorbeelden te vinden van games waarbij de hotfix op zich liet wachten. Daarnaast hebben we het frametimes debacle gehad waarbij AMD heeft toegegeven de drivers gewoon nooit op consistentie te testen (terwijl Nvidia dit wel deed).

Het gekke is dan toch dat mensen nVidia blijven verdedigen, zelfs nadat (zoals benoemd) de DX10 drivers lang ronduit slecht waren, de drivers hardware letterlijk de dood in joegen (Star Craft II menu bleef de kaart op volle toeren draaien) nu weer problemen met DX12/Win 10 drivers, terwijl nVidia claimt jarenlang met Microsoft te heben samengewerkt aan DX12 en dan is er nog het geval waar nVidia gebasseerde laptops in sommige gevallen te kampen hadden met schermen die spontaan stuk gingen bij de overgang naar Windows 10.

Een oprechte vraag. Als nVidia echt zo goed is met drivers, waarom heeft AMD dan (wederom) geen problemen met de overgang naar een nieuw OS met nieuwe DX versie, terwijl nVidia wederom tegen vreemde problemen aan hobbelt? Men verwacht dat nVidia wel snel eventjes een fix heeft, maar nVidia heeft al heel veel tijd gehad om dingen op orde te hebben, lijkt me zo. Sterker, men had het in zijn geheel niet over slecht werkende drivers, totdat Oxide naar buiten kwam met hun 'problemen'.

[Sp3ci3s8472]

sdk1985 schreef op maandag 07 september 2015 @ 17:25:
[...]

Dat komt voort uit de users die nooit driver problemen hebben. De laatste keer dat ik een Nvidia driver probleem had stamt uit bij mij uit een oude hitman game (contracts, 2004?). Dat was alleen een game die ik 2 weken voor de release speelde. Tegen de tijd dat de game officieel uitkwam was het probleem (met de shadows) opgelost. De laatste keer dat ik met AMD driver problemen had was de launch van de e350 APU waarbij het ongeveer 11 maanden heeft geduurd voor het werkte zoals het hoorde.

AMD heeft de naam niet voor niets, er zijn gewoon veel voorbeelden te vinden van games waarbij de hotfix op zich liet wachten. Daarnaast hebben we het frametimes debacle gehad waarbij AMD heeft toegegeven de drivers gewoon nooit op consistentie te testen (terwijl Nvidia dit wel deed). Om van die naam af te komen (heb ik al vaker vemeld hier) zullen ze Nvidia niet moeten evenaren maar voorbij streven.

Het is dus voor iedereen anders wat betreft drivers. De laatste keer dat ik problemen had met ATI drivers was met een 9600, C&C Generals gaf problemen. Logisch want ik had mijn drivers nog nooit geupdate.
Wat betreft Nvidia, met een 7800GS had ik met spellen die de HL2 engine gebruikten vaak het probleem dat ik ineens een vage roze overlay kreeg als ik daarna een film wilde kijken schijtiritant .
De E-350 die ik heb heeft altijd probleemloos gewerkt in mijn HTPC (OpenElec).

Denk dat het dus ook heel subjectief is.

dahakon schreef op maandag 07 september 2015 @ 21:17:
[...]


Het gekke is dan toch dat mensen nVidia blijven verdedigen, zelfs nadat (zoals benoemd) de DX10 drivers lang ronduit slecht waren, de drivers hardware letterlijk de dood in joegen (Star Craft II menu bleef de kaart op volle toeren draaien) nu weer problemen met DX12/Win 10 drivers, terwijl nVidia claimt jarenlang met Microsoft te heben samengewerkt aan DX12 en dan is er nog het geval waar nVidia gebasseerde laptops in sommige gevallen te kampen hadden met schermen die spontaan stuk gingen bij de overgang naar Windows 10.

Een oprechte vraag. Als nVidia echt zo goed is met drivers, waarom heeft AMD dan (wederom) geen problemen met de overgang naar een nieuw OS met nieuwe DX versie, terwijl nVidia wederom tegen vreemde problemen aan hobbelt? Men verwacht dat nVidia wel snel eventjes een fix heeft, maar nVidia heeft al heel veel tijd gehad om dingen op orde te hebben, lijkt me zo. Sterker, men had het in zijn geheel niet over slecht werkende drivers, totdat Oxide naar buiten kwam met hun 'problemen'.

Terrechte vraag, hoewel ik niet denk dat we daar een goed antwoord op zullen krijgen. Denk dat ze toch tegen meer problemen aanlopen dan ze aanvankelijk hadden gedacht wat betreft softwarematig scheduling, wat natuurlijk raar is aangezien ze al eeuwen aan DX12 werken als ik ze mag geloven. Stilletjes blijven helpt hun situatie niet echt, we krijgen nog steeds het nieuws via Oxide in plaats van Nvidia zelf.

[sdk1985]

dahakon schreef op maandag 07 september 2015 @ 21:17:
[...]


Het gekke is dan toch dat mensen nVidia blijven verdedigen, zelfs nadat (zoals benoemd) de DX10 drivers lang ronduit slecht waren, de drivers hardware letterlijk de dood in joegen (Star Craft II menu bleef de kaart op volle toeren draaien) nu weer problemen met DX12/Win 10 drivers, terwijl nVidia claimt jarenlang met Microsoft te heben samengewerkt aan DX12 en dan is er nog het geval waar nVidia gebasseerde laptops in sommige gevallen te kampen hadden met schermen die spontaan stuk gingen bij de overgang naar Windows 10.

Wacht even hoor... Dat Starcraft 2 in het hoofdmenu geen framerate limiter toepast is toch niet vendor specifiek? Dat is een fout van blizzard. Daar hoort je videokaart ook absoluut niet stuk van te gaan... Mocht dit wel zo zijn dan is dat triest (gevalletje garantie!) maar het staat volledig los van het driver verhaal. Als ik met mijn videokaart 8 uur Furmark ga draaien dan wordt hij ook warm en dan verwacht ik niet dat hij daar stuk van mag gaan. Daar is throttling voor uitgevonden... Het helpt ook als je videokaart niet één groot stofnest is (ook niet vendor specifiek).

@werelds
Ik doel eigenlijk meer op games uit de tijd voor gameworks etc. In die tijd was de kans wel heel erg groot dat het een game met Nvidia spam was. Die van AMD waren immers onderhand op één hand te tellen. Ik herinner me Dirt en Rollercoaster Tycoon 3 met reclame voor AMD. Natuurlijk speel ik niet alle games maar mijn installbase zit al jaren boven de 100 .

De E-350 die ik heb heeft altijd probleemloos gewerkt in mijn HTPC (OpenElec).

Ik draaide hem op Windows XP en 7. Was er verder positief over, zie de review productreview: Asus E35M1-M review door sdk1985 . Achteraf waren er op het XBMC forum meerdere gebruikers met freezes. In de final versie van 12.x verdwenen die problemen gelukkig spontaan.

[ Voor 14% gewijzigd door sdk1985 op 07-09-2015 22:34 ]

[haarbal]

Dat van starcraft II herinner ik me ook nog, veel kaarten begaven het. Mijn 8800gtx heeft het gewoon doorstaan, maar ik had hem ook een paar maanden daarvoor schoongemaakt, wat meer dan 10 graden scheelde.

Er was wel een nvidia driver die binnen een dag weer van de site gehaald werd omdat de fancontrol verneukt was, heeft wel wat kaarten het leven gekost, maar dat was niet tijdens de starcraft 2 tijd.

Ik denk dat de betere driver reputatie toch komt van de vele driverlaunches met nieuwe per game performance tweaks. En misschien doordat sli tot de 290x echt beter was dan crossfire.

[ Voor 5% gewijzigd door haarbal op 07-09-2015 23:10 ]

[Sp3ci3s8472]

sdk1985 schreef op maandag 07 september 2015 @ 22:24:
[...]

Wacht even hoor... Dat Starcraft 2 in het hoofdmenu geen framerate limiter toepast is toch niet vendor specifiek? Dat is een fout van blizzard. Daar hoort je videokaart ook absoluut niet stuk van te gaan... Mocht dit wel zo zijn dan is dat triest (gevalletje garantie!) maar het staat volledig los van het driver verhaal. Als ik met mijn videokaart 8 uur Furmark ga draaien dan wordt hij ook warm en dan verwacht ik niet dat hij daar stuk van mag gaan. Daar is throttling voor uitgevonden... Het helpt ook als je videokaart niet één groot stofnest is (ook niet vendor specifiek).

[...]

Ik draaide hem op Windows XP en 7. Was er verder positief over, zie de review productreview: Asus E35M1-M review door sdk1985 . Achteraf waren er op het XBMC forum meerdere gebruikers met freezes. In de final versie van 12.x verdwenen die problemen gelukkig spontaan.

Vooral oude engines cappen de framerate nooit, dit is eigenlijk ook niet aan de ontwikkelaar om dat te doen (maar dat is mijn mening). Als jij als gebruiker v-sync uitzet, dan vind ik het normaal dat de engine ernaar streeft om een zo'n hoog mogelijke framerate te halen. Ik weet nog dat ik in bijvoorbeeld Quake 3 of MOHAA de fps zo tweakte dat ik net wat hoger kon springen, dit was veel hoger dan 60fps.
Het is pas sinds enkele jaren dat spellen op 30fps of 60fps worden gecapped op de pc, wat echt niet van deze tijd is met al die 120hz/144hz monitoren . Dit zijn overigens vaak console ports.

Ik dacht dat Nvidia destijds (4xx en 5xx) het throttlen deed via software door naar de executable te kijken (GTX480 werd daar extreem gethrottled ). Het kan dus dat ze Starcraft II niet op het lijstje hadden staan.

[sdk1985]

Sp3ci3s8472 schreef op maandag 07 september 2015 @ 23:10:
[...]


Vooral oude engines cappen de framerate nooit, dit is eigenlijk ook niet aan de ontwikkelaar om dat te doen (maar dat is mijn mening). Als jij als gebruiker v-sync uitzet, dan vind ik het normaal dat de engine ernaar streeft om een zo'n hoog mogelijke framerate te halen. Ik weet nog dat ik in bijvoorbeeld Quake 3 of MOHAA de fps zo tweakte dat ik net wat hoger kon springen, dit was veel hoger dan 60fps.
Het is pas sinds enkele jaren dat spellen op 30fps of 60fps worden gecapped op de pc, wat echt niet van deze tijd is met al die 120hz/144hz monitoren . Dit zijn overigens vaak console ports.

Ik dacht dat Nvidia destijds (4xx en 5xx) het throttlen deed via software door naar de executable te kijken (GTX480 werd daar extreem gethrottled ). Het kan dus dat ze Starcraft II niet op het lijstje hadden staan.

Ik ben het met je eens dat het niet leuk is dat games op 30 of 60 fps worden gecapped.

Maar beide genoemde spellen zijn nu net games waarbij er wel een standaard framelimit is die moet aangepast worden in de .cfg bestanden (of via de console): seta com_maxfps "125") . Dat is eigenlijk al zo sinds er 3d shooters met multiplayer zijn. Het is daarnaast ook gewoon redelijk nutteloos om 300 fps in het hoofdmenu te halen.

Het fijnste blijven games als Endless Legends die gewoon de optie bieden om Vsync of een instelbare cap te gebruiken (van bijvoorbeeld 30,60 of 120 fps).

Mijn GTX 460 Hawk throttlede in ieder geval op basis van temperatuur. Aangezien je die flink kon overvolten was het niet zo moeilijk om daar in de zomer 90 graden mee te halen in Furmark.

Maar goed we hadden het o.a. over drivers en Starcraft 2. Ik zocht even naar de patch en kwam dit tegen: http://us.battle.net/sc2/en/forum/topic/375107634. Rara wat staat erbij

ATI has released updated drivers to enable Anti-Aliasing in Starcraft 2. Previously even forcing application to use AA would not work for Starcraft 2, but with the new driver, it can now be done. This may slow down your FPS considerably, so watch out.
It also improves performance in certain crossfire setups.
EDIT: that was version 10.7a, you should probably get a more recent version now (which may offer increased benefits). Visit amd/ATI's website to get the latest version.


nVidia cards could/can already force AA.

Ik denk dat we op basis hiervan Starcraft even kunnen afschrijven als voorbeeld van slecht werkende Nvidia drivers . (Overigens natuurlijk een redelijk triviaal probleem, zonder AA had ik SC2 ook wel kunnen spelen).

[ Voor 21% gewijzigd door sdk1985 op 07-09-2015 23:39 ]