Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Core » Software » nVidia gaat multithreaded drivers schrijven

nVidia gaat multithreaded drivers schrijven

Door Wouter Tinus, maandag 20 juni 2005 21:31
Bron: The Tech Report, views: 22.917

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.

nVidia Forceware 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.

Volgende 21:56 ECT Mach2 GT phase change-koeler getest
Vorige 21:00 Nieuwe codenamen voor Intels 45nm-chips opgedoken
Advertentie

Categorieën

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 82 reacties zichtbaar820 Off-topic / Irrelevant: 81 reacties zichtbaar81+1 On-topic: 58 reacties zichtbaar58+2 Informatief: 9 reacties zichtbaar9+3 Spotlight: 0 reacties zichtbaar0
«  1  2  »

Door Wim Leers, maandag 20 juni 2005 21:37

Score: 0
Wat heeft die 256MB er mee te maken??? :? |:(

Door sneakers, maandag 20 juni 2005 21:41

Score: 0
Een videokaart met 256 mb zal een grotere vooruitgang hebben dan een videokaart met 64 mb lijkt me...

Door hoeretoeter, maandag 20 juni 2005 21:45

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

Door immad, maandag 20 juni 2005 21:45

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

Door Pietervs, dinsdag 21 juni 2005 09:49

Score: 0
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??? |:(

Door Anthonie Smit, dinsdag 21 juni 2005 15:26

Score: 1
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.

Door Jan Groothuijse, maandag 20 juni 2005 22:58

Score: 0
Niets, drivers komen namelijk in het systeem geheugen te staan en niet in het video geheugen, wat er dus wel voor zorgt dat op dual opterons de drivers niet alleen 2 maal zoveel rekenkracht maar ook 2 maal zoveel geheugenbandbreette krijgt, mits NUMA.

Door jb044, dinsdag 21 juni 2005 04:11

Score: 0
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? :+

Door Jan Groothuijse, dinsdag 21 juni 2005 19:28

Score: 0
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.

Door jb044, woensdag 22 juni 2005 18:19

Score: 1
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 B-)

Door ToFast, maandag 20 juni 2005 21:46

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

Door Jan Groothuijse, maandag 20 juni 2005 22:56

Score: 1
Ho eens, het gaat gewoon om de driver, meer niet, zelfs niet de API (die toch ook vrij belangrijk is bij het 3d renderen :D) 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.

Door Keeper of the Keys, maandag 20 juni 2005 21:51

Score: 0
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]

Door twabi2, maandag 20 juni 2005 21:54

Score: 2
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?

Door mike_mike, maandag 20 juni 2005 22:12

Score: 2
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...

Door To_Tall, dinsdag 21 juni 2005 09:32

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

Door GORby, dinsdag 21 juni 2005 10:56

Score: 2
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.

Door trogdor, dinsdag 21 juni 2005 14:02

Score: 2
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.

Door Wouter Tinus, maandag 20 juni 2005 21:54

Score: 1
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.

Door Fairy, maandag 20 juni 2005 21:57

Score: 2
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 :)

Door Deadsy, maandag 20 juni 2005 22:01

Score: 2
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

Door Luuk1983, dinsdag 21 juni 2005 08:36

Score: 1
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.

Door Rune, dinsdag 21 juni 2005 09:33

Score: 2
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-

Door mjtdevries, dinsdag 21 juni 2005 09:54

Score: 1
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.

Door Rune, dinsdag 21 juni 2005 10:29

Score: 1
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-

Door mjtdevries, dinsdag 21 juni 2005 11:53

Score: 1
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?

Door Pietje Puk, dinsdag 21 juni 2005 11:54

Score: 1
@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".

Door Rune, dinsdag 21 juni 2005 14:36

Score: 1
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

Door mjtdevries, dinsdag 21 juni 2005 15:51

Score: 1
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)

Door Gogar, maandag 20 juni 2005 21:57

Score: 1
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 :)

Door n-i-x, maandag 20 juni 2005 22:16

Score: 1
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.

Door henk_DE_man, maandag 20 juni 2005 23:21

Score: 1
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.

Door Dark_man, maandag 20 juni 2005 23:22

Score: 1
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.

Door mjtdevries, dinsdag 21 juni 2005 09:08

Score: 1
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)

Door Pietje Puk, dinsdag 21 juni 2005 11:59

Score: 0
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.

Door mjtdevries, dinsdag 21 juni 2005 13:04

Score: 1
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.

Door fidelio675, dinsdag 21 juni 2005 12:28

Score: 1
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.

Door DJKroon, maandag 20 juni 2005 22:10

Score: 1
Multi-tread? :9
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 :z

Door Jan Groothuijse, dinsdag 21 juni 2005 00:55

Score: 0
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.

Door Derice, maandag 20 juni 2005 22:19

Score: 0
Gaan ze dan ook HT voor CPU's ondersteunen?
Lijkt me nou eens een goeie vooruitgang.

Door mjtdevries, dinsdag 21 juni 2005 09:10

Score: 1
Zodra je meerdere threads hebt, heb je automatisch ondersteuning voor HT.

HT is immers niet anders dan meerdere threads op 1 cpu verwerken.

Door Parabellum, maandag 20 juni 2005 22:37

Score: 1
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.

Door Skinkie, maandag 20 juni 2005 22:58

Score: 1
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.

Door Willson, maandag 20 juni 2005 23:16

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

Uiteraard is service nooit slecht

Door c0d1f1ed, dinsdag 21 juni 2005 00:15

Score: 1
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.

Door ChangeLife4Ever, maandag 20 juni 2005 23:49

Score: 0
Mooi initiatief van nVidia! Zeker nu we steeds meer multicore processoren krijgen, lijkt het me eigenlijk niet meer dan logisch, c.q. vereist dat de videokaart-leveranciers met hun drivers up to date blijven.

Ben benieuwd of Ati dit ook gaat doen. 'k Ben namelijk de trotse bezitter van een Ati 9700PRO in een SMP systeem en een nVidia 6600GT in een Celeron D systeem. 'k Had dus liever gehad dat Ati dit deed ;). Hopelijk komt dat nog, maar ik heb er nog niets van gehoord, c.q. gelezen ;(

'k Ben eigenlijk wel benieuwd wat dit oplevert. Als de drivers multi theaded zijn, maar de game niet, is de winst dan ook tussen de 5 en 30% :?

Door Chris Leicher, dinsdag 21 juni 2005 00:11

Score: 0
Interesante ontwikkeling alleen ben ik benieuwt naar de overhead die nodig is om de code geschikt te maken voor dual(dit kan nog al wat extra code overhead apleveren omdat alles moet worden getimed tussen de cores) en hoe deze code op een singel processor kan worden geminimaliseerd.

Afwachten dus.

Door c0d1f1ed, dinsdag 21 juni 2005 00:26

Score: 1
Overhead is minimaal. Immers zit je met een tweede core die niks liever wil dan data verwerken. Een gehele 'tweede processor' beschikbaar voor vertex-processing heeft heel wat rekenkracht (tot vier floating-point getallen per clock). Eens de core klaar is worden de resultaten naar de grafische kaart gestuurd. Die loopt meestal een paar frames achter dus er is een marge vooraleer de data echt nodig is.

Voor single-core processors zet je die vertex-processing gewoon uit.

Door Munters, dinsdag 21 juni 2005 13:05

Score: 0
Daar heb je nu juist geen multithreaded videodrivers voor nodig!
De applicatie (game) draait op proc 1, en de videodriver op proc 2.
Bij multithreaded drivers ga je de drivercode over meer dan 1 logische proc uitsmeren.

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.
Op het moment dat je beeld 1 ziet, leest de applicatie de huidige/nieuwe waardes van de userinput en de AI en begint met die uitgangspunten een nieuw beeld te berekenen. Dat ijlt echt niet na.

Door c0d1f1ed, dinsdag 21 juni 2005 16:58

Score: 0
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.

Door Munters, woensdag 22 juni 2005 11:13

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

Door mjtdevries, dinsdag 21 juni 2005 09:47

Score: 0
Het fijne van multithreaded code is dat het zowel voor multiprocessor als voor single processor gunstig is. Je gebruikt dus exact dezelfde code in beide situaties.

Je bereikt namelijk dat je cpu efficienter wordt gebruikt en dat is ook voor een single processor gunstig.

Als je spel zowiezo al continue 100% processor gebruikt merk je er uiteraard niet veel van, maar de overhead van multithreading is ook uitermate klein, dus je hebt er geen hinder van.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 21:56 ECT Mach2 GT phase change-koeler getest
Vorige 21:00 Nieuwe codenamen voor Intels 45nm-chips opgedoken
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011