nVidia gaat multithreaded drivers schrijven

nVidia gaat zijn ForceWare-drivers ombouwen om gebruik te maken van meerdere threads. Dit heeft Ben de Waal van nVidia verklaard tegenover de Tech Report. Vanaf versie 80.00 zou de universele driver voor GeForce-videokaarten aan multithreading moeten gaan doen. Op de vraag waarom hier niet veel eerder aan gedacht is komt het antwoord dat de programmeurs eigenlijk al lange tijd met het idee aan het spelen zijn, maar dat met name Windows het erg moeilijk maakt voor een driver om (nuttig) gebruik te maken van meerdere threads.

Er zou nu echter een oplossing gevonden zijn, waardoor een extra core in de toekomst onder andere ingezet zou kunnen worden om vertices te verwerken. Normaal is dit een taak voor de GPU, maar als deze het te druk heeft laat de driver de CPU bijspringen. In de toekomst zouden hiervoor dus meerdere cores in plaats van slechts één ingezet worden. Verwacht wordt dat de prestaties door dit soort trucs 5 tot 30 procent omhoog kunnen gaan. De Waal is overigens sceptisch over het nut van multithreaded drivers op de langere termijn. Zodra de spellen zelf al meerdere cores gaan benutten zou het effect ervan namelijk flink kunnen afnemen.

Reacties (82)

[Keeper of the Keys]

Zulke 'trucjes' betekenen wel dat je meteen de performance van de videokaart zelf niet meer eerlijk kunt vergelijken tenzij de andere fabrikanten ook uitwerken hoe ze dit moeten doen.
(of als je het op de een of andere manier uit kunt zetten)

Dan wordt het een vergelijking wie of dat het beste implementeert.

Ander probleem zou kunnen zijn dat als programma's en spellen ook gaan inspringen op de mogelijkheden van meer threads dat met elkaar gaat botsen en het juist performance kan gaan kosten...

edit:

@twabi2:
Als je een paar videokaarten benchmarkt in een systeem dan is de hoeveelheid RAM van het systeem als het goed is altijd hetzelfde...
En als je de hoeveelheid geheugen op de kaart bedoeld, dat vind ik uiteraard geen trukje, dat wordt gewoon vermeld en je kunt het vergelijken met de scores van een andere videokaart.
@ algemeen:
Ik geloof dat ik niet goed wordt begrepen, ik ben niet tegen optimalisaties - zolang die eerlijk zijn en dus geen vertekend beeld geven - , en in testsystemen waar alles behalve de videokaart constant gelijk blijft kun je eerlijk zien wat er gebeurt.
Alleen kun je nu minder (goed) zien in hoeverre er werk zal wordt gedaan door de CPU (dat hiervoor door de GPU werd gedaan).

[edit2]
waarom overbodig?
[/edit]

[twabi2]

Doet het er toe of iemand "truks" gebruikt of niet, als je maar meer resultaat haalt!
Het is dankzij optimalisaties zoals deze dat we steeds sneller gaan. Of wou je vb meer ram ook al een trukje noemen?

[Verwijderd]

Doet het er toe of iemand "truks" gebruikt of niet, als je maar meer resultaat haalt!
Het is dankzij optimalisaties zoals deze dat we steeds sneller gaan. Of wou je vb meer ram ook al een trukje noemen?

Sommige truuks (zeker uit het verleden) geven een vertekend beeld. De benchmarks behoren hardware te testen niet software. Anders kan de zelfde "truuk" uitvoeren bij een andere kaart later opeens aanteonen dat de achterliggende hardware veel krachtiger is, wil je toch graag weten van te voren als je hem koopt. De drivers kun je gratis opdaten, de hardware niet...

[To_Tall]

je vergeet dat er software nodig is om hardware te testen... en de software uiteindelijk bepaalt hoe efectief je hardware word gebruikt.

[GORby]

De benchmarks behoren hardware te testen niet software

Niet helemaal mee eens.

Die benchmarks moeten testen hoe de gebruiker het produkt ervaart. Als de gebruiker het produkt ervaart als zijnde zeer snel met goede beeldkwaliteit, dan maakt het niet uit of het aan de hardware of aan de software ligt.

Een extreem snelle kaart zou volgens jou dus een hoge score moeten krijgen, ook al is ie niet vooruit te branden door de slechte drivers?

Neen, wat mij interesseert is de prestaties en de beeldkwaliteit in games & techdemos.

[trogdor]

imho hoort, afhankelijk van de test, ofwel een los component getest te worden, ofwel een heel systeem.
En in het geval van het hele systeem hoort daar natuurlijk ook de software/drivers bij.

[Verwijderd]

Ik vindt multithreading geen trucje.
Het is stom dat ze dat nog niet eerder hebben gedaan. Zijn ati's drivers niet al multithreaded?

Is dit trouwens threading op de GPU of op de CPU?
Als het op CPU is hadden ze op deze manier al een tijd gebruik kunnen maken van HT.

multithreading is een techniek die bij intensieve processen die niet multiproces draaien, gewoon gebruikt moet worden.

Verwacht echter niet dat je spelletje nu opeens een berg fps erbij heeft, er wordt niets sneller, alleen efficienter.

-R-

[mjtdevries]

De reden dat ze het niet al gebruikten is dat het geen snelheidswinst oplevert, terwijl de drivers wel flink herschreven moeten worden, wat dus geld kost en nieuwe bugs introduceert.

Maar multithreading wordt nu een buzzword met al dat gedoe over multicore cpu's.
Je hebt zelfs kans dat de drivers al multithreaded waren, maar dat het nooit verteld is omdat het niet interessant is. Maar nu kan de PR afdeling het goed gebruiken.

Overigens spreek je jezelf flink tegen.

Het doel van multithreading is juist dat de boel wel sneller werkt. Je cpu wordt efficienter gebruikt en dus is de code sneller uitgevoerd.

De reden dat het hier niets helpt is dat het uitvoeren van de drivercode maar zo ontzettend weinig cpu gebruikt bij een spel.

Verder ben ik het met je eens dat multithreading geen trucje is.

Bij trucjes denk ik aan zaken die alleen in benchmarks gebruikt kunnen worden, of waarbij beeldkwaliteit wordt aangetast of zo iets dergelijks.
Multithreading kan universeel worden toegepast en tast geen beeldkwaliteit aan. Het is dus geen trucje.

[Verwijderd]

Efficientere code is niet per definitie snellere code.
Er wordt efficienter met de resources van de PC omgegaan (dus niet de GPU).
Er is dus nagenoeg geen snelheidswinst. Alleen de drivercode wordt wat efficienter uitgevoerd, maar de GPU code blijft gewoon dezelfde snelheid. (En dan begin ik niet eens over synchronisatie mechanismes, waarbij er altijd een op de ander moet wachten).

-R-

[mjtdevries]

Leg dan eens uit wat jouw definitie van efficienter is?

Bv wat efficienter met de cpu resources omgegaan. Wat betekent dat dan?

Ik kan daarbij maar 1 ding bedenken en dat is dat de cpu minder staat te wachten....
En als ie minder staat te wachten is je code dus eerder uitgevoerd. en dat betekent dat het sneller is.

Maar daar ben je het dus niet mee eens, dus kun jij duidelijk uitleggen wat jij bedoeld met efficienter met de cpu resources omgaan?

[Verwijderd]

@Rune
In dit geval wordt de code van de driver geoptimaliseerd zodat de resources van de PC effectiever benut kunnen worden. De GPU (hardware) wordt daar niet sneller van maar er worden bijvoorbeeld wel meer vertices per seconde berekend. De gevraagde operatie (het weergeven van het scherm) kan dus op dezelfde hardware sneller worden uitgevoerd.

Tuurlijk kan een ontwikkelaar er ook voor kiezen om de beeldkwaliteit te laten toenemen zonder dat de snelheid afneemt maar uiteindelijk zorgt de driver optimalisatie er,hopelijk, voor dat de ontwikkelaar meer performance uit dezelfde hardware kan halen. De hardware wordt dan ook in de beleving van de gebruiker wel degelijk "sneller".

[Verwijderd]

Ok.. stel het multiproces spul als volgt voor:
stel je hebt 4 kassa's bij een supermarkt. (4 threads)
je hebt als je geluk hebt 2 kassieres (2 cpu's of 1 dual core of zelfs 1 HT (windows snapt het verschil niet tussen HT en SMP)).
En je hebt een kassa systeem waar maar 1 kassa tegelijk gebruikt kan worden voor 1 klant (synch IO, windows is niet zo goed in async IO)
Gezien het feit dat parallelisme altijd serialiseerbaar moet zijn, moet er gebruik gemaakt worden van een synchronisatie mechanisme. Bv een bedrijfsleider die bepaalt welke kassiere waar gaat zitten en aan de ene kassiere doorgeeft dat de andere klaar is met de kassa.

Zijn de klanten nu sneller geholpen dan dat ze zouden zijn als ze in een rij zouden staan?
Nee. Het kassa systeem is hier het traagste systeem. Zowel in 1 lange rij als in 4 korte rijen wacht je op het kassa systeem. Het voordeel is wel dat de andere kassiere alvast voorbereidingen kan treffen voor als het kassasysteem weer vrij is. (efficienter gebruik resources, variabelen kunnen gevuld worden, gegevens kunnen klaargezet worden, geheugen kan gealloceerd worden.).

Maar nu. Zelfs al zou je het kassasysteem opvoeren zodat de kassieres er tegelijkertijd gebruik van kunnen maken (async IO in het geval van nvidia, dan kom je weer een ander probleem tegen. Op een gegeven moment zijn de klanten in de rij op. Want we hebben twee kassieres die de rijen afhandelen, maar er is maar een persoon die klanten de winkel binnenlaat (directx (is niet multithreaded, en niet multiprocess)) dus dan wacht je weer op die persoon.

Moraal van dit verhaal: wacht tot de drivers uit zijn, installeer het op een machine met 4 xeons en kijk hoeveel sneller je spelletje loopt (er vanuit gaande dat het spel ook multithreaded is, want anders is dat weer een vertragende factor (al loop je dan nog steeds tegen je ST directX aan). (nouja... niet echt een moraal)

-R-

edit: typos

[mjtdevries]

Ok. Dus je geeft aan dat als er van die 4 kassa's steeds maar 1 tegelijkertijd gebruikt kan worden dan kan de tweede kassiere toch al wel voorbereidingen treffen voor als het kassasysteem weer vrij is.

Maar die voorbereidingen geven je wat snelheids winst want je hoeft ze niet meer te doen op het moment dat het kassasysteem vrij is. Toch?
En dan betekent dat toch dat de klanten uiteindelijk wel sneller geholpen zijn...?


Het andere geval waarbij je aangeeft dat op een gegeven moment de klanten in de rij op zijn is weer iets heel anders.
Je drivercode is dan wel degelijk sneller geworden, maar het blijkt vervolgens dat dat de bottleneck niet was.

En daar geef ik je helemaal gelijk in.
(heb dat ook al in andere reacties betoogt)

[Fairy]

Dus stel ik maak een supergeweldige allersnelse videokaart maar ik geeft de meest brakke trage ongeoptimaliseerde drivers mee, dan vind jij dat deze kaart wint?

Nee ook optimalisaties spelen een rol, het balletje ligt nu dus ook weer bij ATI

[Deadsy]

idd
een GPu maker heeft volledige service te leveren
niet alleen GPUs maar ook drivers.

drivers horen er gewoon bij.

als ze de kaarten van ATi en Nvidia met elkaar gaan vergelijken instaleren ze toch ook de drivers.
mocht Nvidia een extra feature hebben of mocht ATI een extra feature hebben waardoor andere delen van de PC beter hun werk (of uberhaubt iets) kunnen doen dan hoort dat erbij.

1 voorbeeld is er al
Nvidia kaarten krijgen op Nforce 4 een kleine speedboost.

en zodat games en drivers niet met elkaar botsen mag geen probleem zijn.
want de driver feature die nvidia will gaan maken zal ook uitgeschakeld kunnen worden door de game mocht deze dit zelf geimplimenteerd hebben.
iets wat vast en zeker door gamedevelopers overlegd zal worden met Nvidia en consorten.

edit: tikfouten

[Wouter Tinus]

Zulke 'trucjes' betekenen wel dat je meteen de performance van de videokaart zelf niet meer eerlijk kunt vergelijken tenzij de andere fabrikanten ook uitwerken hoe ze dit moeten doen.
(of als je het op de een of andere manier uit kunt zetten)

Alsof de drivers nu nog geen extreem belangrijke rol spelen? De laatste tijd zie je misschien geen dramatische verschillen, maar dat is wel het resultaat van vele jaren lang optimaliseren. Nieuwe spelers (bijv. XGI) gaan iedere keer keihard op hun plaat als het op drivers aankomt, ook al zijn hun chips in principe niet eens zo slecht.

[Luuk1983]

Het is nu ook al het geval. Wie het beste driver implementeerd heeft de snelste kaart. NVIDIA heeft bijvoorbeeld betere OpenGL drivers waardoor Doom3 een stuk sneller is dan op een ATI kaart, terwijl ATI kaarten bijna alles in Direct3D winnen.

[mjtdevries]

Hoera we hebben weer het nieuwste buzzword: Multithreading!

Dit is pure PR bullshit.

Begrijp me niet verkeerd. Ik ben een groot voorvechter van multithreaded software, maar dit verhaal is echt onzin.

Als je een diepgaande technische uitleg wilt hebben verwijs ik naar de comments op techreport. makfu heeft het daar al perfect verwoord: http://techreport.com/ja.zz?comments=8459

Maar ik zal in een kort een aantal dingen aanstippen.
Ten eerste is het verhaal dat het OS de zaak moeilijk maakt dus onzin. (zie de link hierboven)

Ten tweede is die 5 tot 30% zeer misleidend. Ja het uitvoeren van de drivercode zal wellicht 5 tot 30% sneller gaan. Maar het spel zal dan 0.005 tot 0.030% sneller gaan!
De reden hiervoor is dat een spel maar een heeeeeele korte tijd bezig is met het uitvoeren van drivercode. De rest zit in uitvoeren van DX9 code en spelcode.

Ten derde is het dus onzin dat multithreaded games de impact van deze drivers kunnen verminderen. Zoals ik hierboven aangaf wordt er maar een heeeeeel weinig cpu tijd aan die driver code besteed.
Verder zullen er voorlopig geen multithreaded games zijn die beide cpu's continu 100% bezig kunnen houden. Er blijven dus genoeg cpu cycles over om dat hele kleine beetje driver code uit te voeren.

Conclusie: leuk dat Nvidia multithreaded drivers wil maken, maar als consument hebben we daar helemaal NIETS aan.

Waarbij heeft het dan wel zin?
Simpel: bij die zaken die veel cpu tijd vragen in een spel. Dus de code van het spel zelf, en de DX9 code.

DX9 is nu nog singlethreaded en heeft de nodige beperkingen die veel tijd kosten. De grootste bottlenecks daarin worden in de volgende DX versie gefixed.

[Verwijderd]

Dit is pure PR bullshit.

5-30% is PR bullshit? Sorry maar als je zo'n beloftes maakt is het geen PR. Als je niet aan de verwachting voldoet is het zelfs anti-reclame. En Ben de Waal staat aan het hoofd van het driver-team. Hij houdt zich bezig met de technische kant van de zaak, niet de PR, en zal dus een goed beeld hebben op de werkelijke mogelijkheden.

Ten tweede is die 5 tot 30% zeer misleidend. Ja het uitvoeren van de drivercode zal wellicht 5 tot 30% sneller gaan. Maar het spel zal dan 0.005 tot 0.030% sneller gaan!

Je vergeet compleet dat die code in parallel draait, op een multi-GHz core die niks anders te doen heeft. Dus de gebruikelijke drivercode draait op één core, terwijl de andere core -volledig- gebruikt kan worden voor extra vertex-processing. Da's ettelijke miljarden floating-point berekeningen extra.

De reden hiervoor is dat een spel maar een heeeeeele korte tijd bezig is met het uitvoeren van drivercode. De rest zit in uitvoeren van DX9 code en spelcode.

Drivercode neemt een aanzienlijke hap uit de beschikbare rekentijd. De reden hiervoor is dat zowat alle optimalizaties in de driver gebeuren. De GPU is 'domme rekenkracht' en het is aan de driver om er enkel dingen naar toe te sturen die uiteindelijk op het scherm verschijnen.

En wat is volgens jou 'DX9 code'? Dát is pas code die heel weinig tijd inneemt. De DirectX runtime is enkel een interface tussen de applicatie en de driver (i.e. de brug tussen user mode en kernel mode). Die doet echt niks rekenintensief. Als een DirectX functie lang duurt is het omdat de onderliggende driver er zo lang over doet.

Ten derde is het dus onzin dat multithreaded games de impact van deze drivers kunnen verminderen.

Ik hoop dat je vanaf hier nu zelf je fouten uit kunt halen...

Tip: Geen kritiek geven, en vooral geen negatieve, over iets waar je noppes van kent.

[mjtdevries]

5-30% is PR bullshit? Sorry maar als je zo'n beloftes maakt is het geen PR. Als je niet aan de verwachting voldoet is het zelfs anti-reclame. En Ben de Waal staat aan het hoofd van het driver-team. Hij houdt zich bezig met de technische kant van de zaak, niet de PR, en zal dus een goed beeld hebben op de werkelijke mogelijkheden.

De antwoorden op je vragen staan al in mijn orginele bericht. Maar aangezien je die blijkbaar niet hebt begrepen zal ik hier nogmaals uitleggen.
5-30% is PR bullshit omdat het spel NIET 5-30% sneller gaat. Maar ondertussen denkt iedereen hier dat wel en denk dat Nvidia weer wat geweldigs heeft gedaan.
Een pluim voor de PR afdeling van Nvidia, die hiermee geweldig werk heeft geleverd.
Wanneer straks blijkt dat die 5-30% helemaal niet gehaald word is dit al weer lang vergeten en is er dus geen anti-reclame. Ondertussen is de verbetering van het imago blijvend.
Wat betreft de technische kant. Dat gaat veel te diep voor de discussie hier. Zoals ik al zei staat dat al door ettelijke mensen prima verwoord in de discussie bij techreport. En dan door mensen die daadwerkelijk drivers schrijven, ipv een manager die wel aan het hoofd staat, maar niet (meer) op dat diepgaande nivo er mee bezig is.

Je vergeet compleet dat die code in parallel draait, op een multi-GHz core die niks anders te doen heeft. Dus de gebruikelijke drivercode draait op één core, terwijl de andere core -volledig- gebruikt kan worden voor extra vertex-processing. Da's ettelijke miljarden floating-point berekeningen extra.

Je vergeet dat de driver maar een heel simpel dingetje is. Een simpele vertaling van de DX api's naar de gpu hardware. Dat vergt maar heel weinig cpu cycles.
En als een vertaling maar 0.1% van de cpu usage van een spel in beslag neemt, dan heeft een 30% sneller vertaling dus maar heel weinig effect op de uiteindelijke snelheid van een spel.
En dan maakt het geen zier uit hoe snel die andere core is want de hoogste snelheidswinst die je zelfs in theorie. (met een 5THz cpu) kunt bereiken is immers maar 0.1%.

Drivercode neemt een aanzienlijke hap uit de beschikbare rekentijd. De reden hiervoor is dat zowat alle optimalizaties in de driver gebeuren. De GPU is 'domme rekenkracht' en het is aan de driver om er enkel dingen naar toe te sturen die uiteindelijk op het scherm verschijnen.

De GPU is tegenwoordig geen domme rekenkracht meer. Denk maar aan de shaders die tegenwoordig de beperkende factor zijn in spellen. Daar heeft een driver helemaal niets mee te maken.
Maar zelfs al zouden al die optimalisaties in de driver zitten. (wat voor het grootste gedeelte niet waar is) dan nog is dat 5-30% cijfer misleidend. Optimalisaties geven je eens een keer 5 - 10% winst. Nu gaat die 5-10% winst dus 5-30% sneller. De uiteindelijk snelheidswinst van multithreading komt dan uit op 0,0025% - 3%.
Zou er iemand hier enthousiast worden wanneer in het artikel stond dat multithreading in de driver je spel in gunstige situaties wel 3% sneller zou kunnen maken?

En wat is volgens jou 'DX9 code'? Dát is pas code die heel weinig tijd inneemt. De DirectX runtime is enkel een interface tussen de applicatie en de driver (i.e. de brug tussen user mode en kernel mode). Die doet echt niks rekenintensief. Als een DirectX functie lang duurt is het omdat de onderliggende driver er zo lang over doet.

Tim Sweeney is het niet met je eens. DX zit niet efficient in elkaar. Daardoor krijg je een gigantisch overhead op Direct3D calls. Dat is zelfs zo erg dat het 50% van de cpu tijd in beslag neemt!!
(Niet rekenintensief zei je toch? )
Het grote voordeel van multicore cpu's is dat je die overhead kunt 'verbergen'.
Die overhead is er trouwens ook de oorzaak van dat je in spellen met multithreading het renderen niet kunt versnellen. Wel kun je AI, physics etc goed multithreaden.
Je kunt dit nalezen in de volgende thread op beyond3D:
http://www.beyond3d.com/forum/viewtopic.php?t=21194&highlight=

En daarmee is de conclusie over die tip van je dan ook duidelijk: De pot verwijt de ketel dat ie zwart ziet!

[Verwijderd]

De antwoorden op je vragen staan al in mijn orginele bericht. Maar aangezien je die blijkbaar niet hebt begrepen zal ik hier nogmaals uitleggen.

In jouw eerste bericht staan blinde aannames.

5-30% is PR bullshit omdat het spel NIET 5-30% sneller gaat.

Ja? Bewijzen daarvoor of nog blinde aanames?

Wat betreft de technische kant. Dat gaat veel te diep voor de discussie hier.

Je wil het niet of je kan het niet? Hint: Ik schrijf drivers, en heb ook al drivers voor grafische kaarten geschreven.

Zoals ik al zei staat dat al door ettelijke mensen prima verwoord in de discussie bij techreport.

Ja? Haal er dan eens het deel uit dat bewijst dat 5-30% snelheidswinst onmogelijk is.

Je vergeet dat de driver maar een heel simpel dingetje is. Een simpele vertaling van de DX api's naar de gpu hardware. Dat vergt maar heel weinig cpu cycles.

De laatste code van een grafische driver die ik gezien heb was dan toch wat meer dan een 'simpel dingetje'. Hint: Op NVIDIA werken -teams- aan de drivers, geen één persoon.

De GPU is tegenwoordig geen domme rekenkracht meer. Denk maar aan de shaders die tegenwoordig de beperkende factor zijn in spellen. Daar heeft een driver helemaal niets mee te maken.

Echt? Het is al enkele keren gebeurd dat een nieuwe driver 20% of meer performantiewinst oplevert. Magie? Of zit er misschien toch meer in die drivers dan je dacht...

Tim Sweeney is het niet met je eens. DX zit niet efficient in elkaar. Daardoor krijg je een gigantisch overhead op Direct3D calls. Dat is zelfs zo erg dat het 50% van de cpu tijd in beslag neemt!!
(Niet rekenintensief zei je toch? )

Ik herhaal: "Als een DirectX functie lang duurt is het omdat de onderliggende driver er zo lang over doet." Noem maar eens een lang durende taak van de DirectX runtime op die niet op de GPU uitgevoerd wordt.

En daarmee is de conclusie over die tip van je dan ook duidelijk: De pot verwijt de ketel dat ie zwart ziet!

Sorry maar ik heb wel degelijk uitgebreide ervaring. Jij hebt hier nog niks van je beweringen bewezen (en dat zal ook niet lukken).

Als je een deftige profiling tool zoals VTune hebt kan je zelf nagaan hoeveel tijd er in de DirectX runtime gespendeerd word en hoeveel in de driver.

[mjtdevries]

De blinde aannames komen allemaal van jouw kant.

De drivercode kan nooit het spel 5-30% sneller maken omdat die code maar een fractie van de cpu tijd van een spel in beslag neemt.

Dat is geen blinde aanname, dat is gewoon gezond verstand gebruiken!!

Als je dat niet kan inzien dan is de hele rest van de discussie al zinloos.

Inderdaad is het al enkele keren gebeurd dat een driver 20% prestatiewinst gaf. En in AL die gevallen is keihard bewezen dat één van de volgende zaken het geval was:
- een ernstige bug was gefixed
- er was een cheat gebruikt
- de beeldkwaliteit werd omlaag gehaald

Helaas heeft het vaak erg lang geduurd voor de waarheid over die gevallen naar boven kwam. (Tijdens het 3DMark schandaal is er flink wat naar boven gekomen)
(overigens geldt dat voor prestaties winst bij drivers van alle merken. Dus zowel ATI, Nvidia, XGI, S3 en ga zo maar duur)

Tim Sweeney is het niet met je eens. DX zit niet efficient in elkaar. Daardoor krijg je een gigantisch overhead op Direct3D calls. Dat is zelfs zo erg dat het 50% van de cpu tijd in beslag neemt!!
(Niet rekenintensief zei je toch? )

Ik herhaal: "Als een DirectX functie lang duurt is het omdat de onderliggende driver er zo lang over doet." Noem maar eens een lang durende taak van de DirectX runtime op die niet op de GPU uitgevoerd wordt.

Je kan iets wel herhalen, maar dat maakt het nog niet waar.

Als je nou even de moeite zou hebben genomen de link die ik vermeld heb te bekijken, dan had je al gelezen waardoor die vertraging komt en dan had je dus ook al gelezen dat het niet door de driver komt!!
De driver moet wachten op DirectX en die bottleneck word in de volgende DirectX versie verwijderd.

Het staat er zwart op wit, exact uitgelegd waar de bottleneck zit, door verscheidene bekende programmeurs. Hoeveel meer bewijs moet ik in godsnaam leveren voor jij het geloofd?

Op deze manier is elke discussie dus compleet zinloos.

We spreken elkaar wel weer als deze drivers publiek worden en de praktijk ook bewijst dat je ongelijk hebt.

[Verwijderd]

De drivercode kan nooit het spel 5-30% sneller maken omdat die code maar een fractie van de cpu tijd van een spel in beslag neemt.

Je hebt een tweede CPU-core, die anders NIKS staat te doen. Stel je een applicatie voor die vertex-processing gelimiteerd is. Zo zijn er genoeg, het hoeft niet eens constant zo te zijn. Dan kan die tweede CPU-core volledig gebruikt worden voor vertex-processing. Da's geen fractie van de tijd, maar 100% van de tijd van die tweede CPU-core.

De vorige drivers spendeerden liever zo weinig mogelijk tijd. Maar wat je niet lijkt te snappen is dat met multi-core er een tweede core bijhangt die anders niks te doen heeft. Dan gebruik je die toch liever voor iets nuttigs?! Als die de bottleneck van de vertex-processing kan wegnemen kan je spel gerust 5-30% sneller.

Dat is geen blinde aanname, dat is gewoon gezond verstand gebruiken!!

't Is ook perfect gezond verstand dat je alle verwerkingseenheden/cores aan het werk zet. Als je twee metsers betaalt om je huis te bouwen ga je de tweede toch niet laten luieren omdat de eerste zijn mortel nog niet droog is? Zet die aan de andere kant van het huis. Gezond verstand.

Je kan iets wel herhalen, maar dat maakt het nog niet waar.

Al een VTune sessie gedraaid? Nee, want anders waren je ogen wel opengegaan. Jij bent hier degene die "iets herhaald" zonder verdere argumenten.

Maar het gaat niet eens om de huidige tijd dat de driver in de CPU spendeert. Het gaat erom dat je 200% processorkracht hebt en maar 100% gebruikt.

Het staat er zwart op wit, exact uitgelegd waar de bottleneck zit, door verscheidene bekende programmeurs. Hoeveel meer bewijs moet ik in godsnaam leveren voor jij het geloofd?

Wat bewijs? Ze hebben het over hoe die 100% verdeeld is. En dat het "bekende programmeurs" zijn daar heb ik niks aan. Zij werken in de applicatielaag, ik werk eronder in de driverlaag. Als zij zien dat een DirectX functie lang duurt, dan zien zij niet dat dit driverfuncties aanroept die lang duren.

En om de Beyond3D thread te quoten:

All the drivers, graphics card hardware and CPU instruction sets added together make the API and HAL functions of D3D take a long, long time (comparitively).

De driver moet wachten op DirectX en die bottleneck word in de volgende DirectX versie verwijderd.

Is het ooit in je opgekomen dat de traagheid van DirectX functies de som is van de tijd in de runtime en van de driver? Ja, er is overhead in de runtime die er beter niet is, maar da's nie de bulk. Bewijs? Kijk naar OpenGL; die heeft zulke overhead niet, en draait die 50% sneller? Dacht het niet, met moeite een procent... Wat we kunnen verwachten van de nieuwe runtime is misschien 1% snelheidswinst. Da's welkom, want het was verspilde tijd, maar niks revolutionairs.

We spreken elkaar wel weer als deze drivers publiek worden en de praktijk ook bewijst dat je ongelijk hebt.

Veel succes maar ik heb het bewijs van jouw ongelijk al naast me liggen. Tip: VTune is gratis voor 30 dagen evaluatie. Maar 't is nog veel eenvoudiger om te realizeren dat er nog een tweede CPU-core volledig vrij is om te assisteren met vertex-processing indien nodig.

[mjtdevries]

Grappig dat je uit die beyond3D thread quote terwijl die hele thread je ongelijk aangeeft.
Sterker nog, de persoon die jij quote is geeft zelf juist ook aan dat DX zo'n grote overhead heeft. Precies dus het tegengestelde van wat jij beweert.

En dat wil jij dan als bewijs voor jouw stelling gebruiken??

Dit wordt echt te belachelijk. Ik ga hier geen woord meer aan vuil maken.

[Verwijderd]

Grappig dat je uit die beyond3D thread quote terwijl die hele thread je ongelijk aangeeft.

Al wat daar staat is dat DirectX functies lang duren. Ik heb al genoeg herhaald dat dit vooral door de onderliggende drivers komt. Verder heeft men het niet over de mogelijkheid om op een tweede CPU of core aan vertex-processing te doen. Dus die thread bewijst totaal niet dat 5-30% performantiewinst voor multi-threaded drivers onmogelijk is.

En kijk even naar dit, zopas gepost op Beyond3D: http://pc.watch.impress.co.jp/docs/2005/0622/graph1.files/PCwatch_GF78 00GTX_19419_image001.gif Die nieuwe kaart is totaal vertex-processing gelimiteerd. Laat daar je tweede CPU-core assisteren en je kan absoluut hogere performantie halen. 3D Mark 2005 is niet DirectX gelimiteerd, makkelijk bewezen met VTune.

Dit wordt echt te belachelijk. Ik ga hier geen woord meer aan vuil maken.

Best ja, want je beschuldigt NVIDIA van PR leugens zonder iets bewezen te hebben. 't Is niet voor niks dat je gemodereerd bent. En als je nog altijd twijfelt aan mijn inzicht: http://sw-shader.sourceforge.net/faq.html#About Me

Kijk ik wil hier niks persoonlijks van maken maar je kan het best eens even opnieuw overdenken. Start vanuit de veronderstelling dat 5-30% wel mogelijk is en zoek sluitende bewijzen dat het niet mogelijk zou zijn. Als je ze vindt mag je me ze altijd laten weten, maar anders zou het fatsoenlijk staan dat je toegeeft dat je misschien fout was...

[aval0ne]

Wedden dat ATI binnenkort ook met multithreaded drivers komt? Zoals zo vaak is het eerst nvidia die met de innovatie komt en ATi die zal volgen.

[mjtdevries]

Uiteraard komt ATI binnenkort hier ook mee. Hun PR afdeling zal heus niet alleen Nvidia met dit buzzword laten spelen.

[Verwijderd]

Het probleem is wel dat er ook nog een moeilijke technische kant aan zit. Het is bijlange niet enkel PR. En NVIDIA gaat dit soort informatie niet vrijgeven voordat ze niet al 90% klaar zijn (anders is het te lang wachten voor het publiek, en kan ATI ze nog inhalen ook).

Wat uiteraard niet uitsluit dat ATI er ook al aan bezig was...

Maar het juiste moment kiezen voor zo'n aankondigingen is van cruciaal belang. Als ATI nu multi-threaded drivers aankondigt is dat veel minder geloofwaardig.

[mjtdevries]

Het probleem is dat er al via die moeilijke technische kant bewezen is dat dit geen 30% winst op gaat leveren, maar dat fanboys de links waar dat piekfijn in uitgelegd word gewoon negeren!

Je helpt wel 100% gelijk dat de andere partij met zulke PR stunts het nakijken heeft, omdat het niet geloofd wordt als je het ook meteen claimed.

ATI zal dus even moeten wachten voor ze dit ook aankondigen, zodat het geloofwaardiger klinkt. Eén of twee maand is daarvoor waarschijnlijk voldoende. Een aparte aankondiging kort voor de launch van de R520 zou ook een goed moment zijn. En dan kunnen ze de eerste versie van de driver bij de launch publiek maken.

[Gogar]

haha straks gaat alles multi-threaded worden en zit je met een spel aan de 20 threads ofzo. Dan gaan ze elkaar juist weer in de weg zitten en andere overhead. En zo komt er vevolgens weer een enorme vraag naar quad core en gaat de multicore race van start

[mjtdevries]

Threads in een spel gaan elkaar niet zo snel in de weg zitten. Het is namelijk helemaal niet zo makkelijk om threads te maken die volledig onafhankelijk van elkaar uitgevoerd kunnen worden.
Van die 20 threads zitten er waarschijnlijk 18 te wachten op een andere thread.

Uiteindelijk is multithreading zeer voordelig. Het is de beste methode om je CPU zo optimaal mogelijk te gebruiken. (Zelfs op een enkele cpu is het daarom al voordelig)

[Verwijderd]

Van die 20 threads zitten er waarschijnlijk 18 te wachten op een andere thread.

Dat is nou precies wat ik in de weg zitten zou willen noemen......

Trouwens op een single core systeem is het meest effectieve nog steeds om een single threaded programma complete controle over de CPU te geven. Geen enkele vorm van synchronisatie, time slices opgeven enz enz. Gewoon puur je programma laten rekenen. Probleem is dan wel dat je programma de CPU continu zwaar moet belasten maar de performance die je misschien, zou kunnen winnen door gebruik te maken van Hyperthreading ben je al snel kwijt aan synchronisatie.

[mjtdevries]

Ik heb me wellicht ongelukkig uitgedrukt.
Die 18 threads zitten gewoon te wachten op het resultaat ergens van. Dat kan een andere thread zijn die op de CPU draait, maar het kan ook I/O zijn, die dus niet de cpu bezet houdt.

Maar die wachtende threads zitten die 2 threads die wel draaien totaal niet in de weg. Dus het is niet zo dat die 2 threads nu langzamer worden uitgevoerd of zo.

Dat is trouwens ook de reden waarom een multithreaded programma ook op een singlecore systeem winst op kan leveren.
als je bij een singlethreaded programma met I/O bezig bent, dan staat je cpu idle terwijl je wacht tot die I/O klaar is. Bij een multithreaded programma kun je terwijl de eerste thread wacht op het voltooien van de I/O, ondertussen een tweede thread laten draaien.

Heb je een situatie waarbij je geen langzame dingen doet zoals I/O en je cpu al continu op 100% draait, dan helpt multithreading je inderdaad niet op de boel sneller te krijgen.
Multithreading helpt je vooral op je cpu op 100% te houden in situaties waarbij ie anders op bv 50% zou staan.

[n-i-x]

En wat is daar mis mee?
Ik vind het eigenlijk vrij goed dat men begint om meerdere cores te gebruiken, want anders dan zouden we nu ongeveer blijven steken wat snelheid betreft.

[Verwijderd]

haha straks gaat alles multi-threaded worden en zit je met een spel aan de 20 threads ofzo. Dan gaan ze elkaar juist weer in de weg zitten en andere overhead. En zo komt er vevolgens weer een enorme vraag naar quad core en gaat de multicore race van start

Toch is dit inderdaad wel de richting die men plant om op te gaan. Als je de lange termijn plannen lees van de grootste cpu designers, dan is multi-core de toekomst. Met multi-core wordt dan gedoeld op uiteindelijk een aantal cores dat in de orde van groote van enige 10-tallen zit.

[Dark_man]

Dat is toch juist mooi?

Je ziet toch nu al dan dat er in de toekomst vraag zal zijn naar meer cores.

Net als toen MMX uitkwam er later de behoefte ontstond naar nog meer en betere extra instructiesets.

Dus het zou niet eens zo gek zijn als ze bij 45nm CPU's al bij de 16 Cores zitten.

Waarom? Omdat het nodig is.

[Verwijderd]

Ik ben niet zo blij met dit nieuws. Zo blijft de mythe dat games niet multithreaded zijn in stand.
Games gebruiken allang meer threads. Anders zouden games continu stilvallen als een netwerk pakketje niet verstuurd kan worden, of als er een nieuwe connectie binnen komt.
Start maar eens een game, ctrl-alt-del of alt-tab eruit en bekijk in de process manager hoeveel threads hij gebruikt.
Veel mensen zijn niet in staat om te onderscheiden dat het alleen over de driver laag gaat, niet om directx zelf of om de games.
Voor een driver voegt het weinig toe, in de directx laag wordt een hoop berekend, en dat moet naar de kaart gestuurd worden. De driver doet voornamelijk aan data versturen en wachten of er een status bit omvalt zodat hij weet dat de operatie klaar is. Wat eerder genoemd wordt, meer vertices berekenen, dat gebeurt toch allemaal op de kaart zelf sinds T&L.

[Skinkie]

Goh... waarom doen ze dit nu juist als de oude kaarten niet meer worden ondersteund. Misschien hadden de oude kaarten hier juist wel baat bij.

[Willson]

Omdat de nieuwe kaarten verkocht moeten worden, de oude zijn dat al...

Uiteraard is service nooit slecht

[Verwijderd]

Je gaat toch geen Geforce FX in een modern dual-core systeem steken? Trouwens, er is zowiezo een voordeel bij dual-core systemen omdat de driver en het spel elk op een core kunnen draaien. Van zodra de spellen meer gebruik maken van multi-threading zal die efficiëntie nog verbeteren. De driver kan gerust single-theaded blijven, 't is niet dat die een hele core voor zich opeist, laat staan meer.

De Waal's oplossing is enkel nuttig gedurende de overgangsperiode dat spellen nog geen gebruik maken van de tweede core.

[Verwijderd]

met name Windows het erg moeilijk maakt voor een driver om (nuttig) gebruik te maken van meerdere threads

Zouden de Linux gebruikers dan eerder van nog snellere graphics kunnen genieten dan Windows gebruikers?

[Verwijderd]

Dat kon sowieso al (met de goede drivers).
Q3 draaide bij mij onder linux (2.6 pre-emptive) altijd sneller dan onder windows. En dit staat los van de graphics, maar de rest van het spel was sneller. Input handling ed. (dit had volgens mij alleen te maken met het feit dat de 2.6 kernel een pre-emptive kernel is en dat system calls interrupted konden worden waardoor Q3 minder hinder ondervond van het OS).

-R-

[Verwijderd]

Goh, zeven jaar geleden had mijn 3DLabs Oxygen VX1 ook al multithreaded drivers... naja, goed dat Nvidia nu ook het licht ziet.

[aval0ne]

7 jaren geleden waren er geen multi core cpu's dus daar hadden we niks aan. Het is pas nu dat het interessant is.

[codeneos]

Het is niet alleen voor dual core cpu's maar ook voor `gewone` SMP systemen. En bij mijn weten waren die er al wel 7 jaar geleden!

[zeikstraal]

Dual bordjes waren er toen ook al....

[Verwijderd]

Toen ik nog op school zat heb ik ook vaak multithreaded spul moeten maken. Er bestonden toen ook al geen multicore systemen.

Maar inderdaad SMP kan hier gebruik van maken, HT kan hier gebruik van maken, maar zelfs op een single CPU machine kan je hier nog bepaalde programmeerproblemen mee de wereld uit werken. Je kan aan threads verschillende programmeertaken toekennen en deze via een synchronisatie mechanisme (bv. semaforen) deze taken uit laten voeren. (dit kan zowel multithreaded als multi process).

Maar iig. is multithreading al zo oud als het (echt) multitasken.

-R-

[DJKroon]

Multi-tread?
Eerste wat bij me opkwam was een dual-core GPU en dan met 2 op een printplaatje zou fantastisch zijn

@ Keepers of the Keys
Naja, trukjes, beter goed gejat dan slecht bedacht

[Verwijderd]

In GPU's zijn duizende pixels tegelijker aan het bewerkt worden, is er onderscheid gemaat tussen de geometry berekeningen gedeelte en het pixel berekene gedeelte, naar gerefereerd als Vertex pipeline Pixel Rendering pipeline.

In de tijd van Voodoo bedachten ze deze structuur, de raster engine chip maakte het raster en de pixel engine chip plakte de texture erop. Later werd het 1 chip, kwamen er 2 texture units per pipeline (waar ze patent op hadden) nog later kwamen er meer pixel pipelines. En toen kwam nvidia met hwTnL, en kreeg geometry berekeningen een basisplaats op de GPU. Toen heeft nVidia nog eenmaal een kaart gemaakt met ongeveer gelijke features, enkel had deze 2 texture units per pipeline (net als de voodoo's) en kreeg deze een flinke geheugen bus (ipv's GeForce 1's miezerige 64bit) inclusief de met GeForce DDR geintroduceerde DDR en nVidia noemde dat ding de GeForce 2 GTS.

De GeForce 3 had alweer shaders............

Maargoed, dual core, dat is op GPU's simpelweg niet van toepassing.

[Verwijderd]

Als je het mij vraagt dan dan werken de cpu en gpu fabrikanten niet echt lekker meer met elkaar en wisselen steeds minder info over elkaars produkten uit. Mogelijk om dat het belang steeds groter word op nieuwe ontwikkelingen en hun core business steeds meer onzchtbaarder word vanwege de nieuwe produkten waarmee ze komen.

Een ongewenste ontwikkeling op de lange termijn lijkt mij, aangezien het nu al allemaal erg onduidelijk is naar de consument toe, laat staan als we straks 2 jaar verder zijn. Ontwikkeling is goed, maar zoals het in real life ook eraan toe gaat op het moment, zodra men niet meer met elkaar samenwerkt gaat het allemaal meer spaak lopen en vertragen. Het vergelijk wat me boven komt is de samenwerking van centrale en lokale overheid, ook dat is al een soepzooitje.

[0siris]

Klinkt goed, maar wie weet gaat nVidia alleen de drivers opnieuw compileren en klaar.....

[ToFast]

Het geheugen heeft er niets mee te maken. Het gaat hier om de instructiesets van de cpu cq gpu.

[Verwijderd]

Ho eens, het gaat gewoon om de driver, meer niet, zelfs niet de API (die toch ook vrij belangrijk is bij het 3d renderen ) De instructie sets hebben er weinig mee te maken, dat is een heel andere laag, de drivers sturen wel instructies naar de GPU maar die hebben niets van doen met de instructieset van de CPU.