nVidia gaat multithreaded drivers schrijven

ga je dat ook nog onderbouwen of laat je het hierbij? want ik begrijp het ook niet.

Ach, mijn verouderde radeon 9700 128 mb is toch wel sneller dan jouw geforce fx 5200 256 mb x)

Een videokaart met 256 mb zal een grotere vooruitgang hebben dan een videokaart met 64 mb lijkt me...
Je hebt 100 euro en krijgt er 5% bij. Of je hebt 1000 euro en krijgt er 5% bij.
Hoeveel % meer ga je in het tweede geval er op vooruit ten opzichte van het 1e geval???

Je hebt het helemaal fout.
Hët gaat om de drivers, niet om grafische objecten.
Drivers worden berekend door de processor en in het systeemgeheugen geplaatst, niet in het geheugen van je grafische kaart.
De grafische kaart word zelfs niet sneller aangestuurd, je processor houd wel rekenkracht over voor andere dingen zoals de game.

Ben ff te lui om het uit te googlen maar eh is in dat geval PCI-E niet de bottleneck: Mem - CPU - HTT - NB - PCI-X - GPU?

Of heb ik het nou verkeerd begrepen wat het Opteron / AMD64 platform betreft?

Nou nog afwachten hoe het gaat werken voor de Intels met HT, waar de 2e logische core ook performance verlies kan veroorzaken. De rauwe performance versus latency discussie lijkt me in het geval van games iig nogal kansloos.

edit[totaal offtopic]:

Neeeeeee, u ook al tweakers.net!! met de stormvloed aan MS onzin banners kan ik leven maar erotisch getinte banners na 12en, what's next party poker?

Neen, voor drivers die op de processor draaien en systeem geheugen gebruiken zal niet snel de PCIe (dus g*dv*rd*mm* niet PCI-X) lin de bottleneck zijn........

Ik geloof dat je niet helemaal begrijpt wat drivers precies doen.

Eh ja sorrie voor de X, was laat

Dus voor een GPU driver gaat het alleen om de CPU en het systeem geheugen ... en dan heb ik het niet helemaal begrepen, jaja

Snap je wel en het zal in de praktijk wel meevallen, maar als de driver er werkelijk in slaagt om de systeem geheugen bandbreedte x 2 uit te putten, blijf ik me afvragen of je al die data nog wel richting GPU krijgt.

Maar we zullen zien, he mischien krijg je straks wel 4way MB's met plek voor 2 of 4 GPU's voor een ronduit misselijk makende gaming performance

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

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.

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.

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-

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?

@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".

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

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)

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.

Enne, de kaart loopt echt geen "paar frames achter" hoor. Zou niet best zijn, want het beeld wordt over het algemeen opgebouwd vanuit of met de huidige plek van de speler. Je ziet precies 1 beeld terug.

Fout. Je ziet het beeld van een paar frames geleden. Bij een framerate van 100 FPS kan dat gerust drie of meer frames zijn. Dat staat gelijk met 0,03 seconden, wat veel sneller is dan je reactievermogen en de speler is dan slechts heel weinig van positie veranderd.

edit:bericht verwijderd. bij nader inzien beschreef ik hetzelfde als c0d1fled hierboven.