Beperkingen huidige generatie GPU's

[Verwijderd]

Ik doe momenteel een onderzoek naar de beperkingen van de huidige generatie GPU's voor de consumentenmarkt.

Aangezien hier veel mensen zijn met een mening , dacht ik dat er vast wel enige reacties zouden komen.
Let wel, het gaat hier om GPU's voor de consumentenmarkt. Beperkingen op elk gebied.

[_Rayman_]

Een grote beperking is volgens mij de bandbreedte van het geheugen en het aantal bewerkingen per puls.
Een bijkomend probleem is het verbruik en de warmte ontwikkeling.

[ Voor 25% gewijzigd door _Rayman_ op 02-01-2003 11:13 ]

[Verwijderd]

Moet het beslist voor de GPU? Want het mem op de videokaarten is eigenlijk meer een beperking.

[Verwijderd]

LAten het we het uitbreiden tot de complete videokaart

[Verwijderd]

Ik denk persoonlijk dat de ultieme videokaart real-time rendering doet met als resultaat een beeld dat niet van het echt is te onderscheiden. Waar zitten dan de beperkingen? Niet alleen het geheugen

[_Rayman_]

Als je over beeld gaat praten, dan moet je ook de beeldschermen erbij betrekken.

[Verwijderd]

Ik ga niet over beeld praten

[EXX]

Dit begrijp ik niet helemaal; bedoel je zoiets als DirectX ondersteuning voor bepaalde versies die de ene kaart wel heeft en de andere niet?

bv. zoiets:

code:

GPU                     Transistor  Manufacturing   Core    
                          Count       Process       Clock   
ATI Radeon 7500 (64MB)    30M       0.18-micron     290MHz  
ATI Radeon 8500 (128MB)   60M       0.15-micron     275MHz  
ATI Radeon 8500 (64MB)    60M       0.15-micron     275MHz  
ATI Radeon 8500LE (128MB) 60M       0.15-micron     250MHz  
ATI Radeon DDR (64 MB)    30M       0.18-micron     183MHz  
Matrox Parhelia (128MB)   80M       0.15-micron     220MHz  
NVIDIA GF2 MX 200 (32MB)    -       0.18-micron     175MHz  
NVIDIA GF2 MX 400 (64MB)    -       0.18-micron     200MHz  
NVIDIA GF2 Pro (64MB)     25M       0.18-micron     200MHz  
NVIDIA GF2 Ultra (64MB)   25M       0.18-micron     250MHz  
NVIDIA GF3 (64MB)         57M       0.15-micron     200MHz  
NVIDIA GF3 Ti200 (64MB)   57M       0.15-micron     175MHz  
NVIDIA GF3 Ti500 (64MB)   57M       0.15-micron     240MHz  
NVIDIA GF4 MX440 (64MB)   -         0.15-micron     270MHz  
NVIDIA GF4 MX460 (64MB)   -         0.15-micron     300MHz  
NVIDIA GF4 Ti4200 (128MB) 63M       0.15-micron     250MHz  
NVIDIA GF4 Ti4200 (64MB)  63M       0.15-micron     250MHz  
NVIDIA GF4 Ti4400 (128MB) 63M       0.15-micron     275MHz  
NVIDIA GF4 Ti4600 (128MB) 63M       0.15-micron     300MHz  
ST Micro Kyro II (64MB)   15M       0.18-micron     175MHz  


GPU                        T&L Pixel Texture Units Memory  Memory  Memory          Memory 
                               Pipes    per Pipe    Size    Clock   Bus            Bandwidth
ATI Radeon 7500 (64MB)     DX7     2       3       64MB    230MHz  1x128-bit DDR   7.4GB/s
ATI Radeon 8500 (128MB)    DX8     4       2       128MB   275MHz  1x128-bit DDR   8.8GB/s
ATI Radeon 8500 (64MB)     DX8     4       2       64MB    275MHz  1x128-bit DDR   8.8GB/s
ATI Radeon 8500LE (128MB)  DX8     4       2       128MB   250MHz  1x128-bit DDR   8.0GB/s
ATI Radeon DDR (64 MB)     DX7     2       3       64MB    183MHz  1x128-bit DDR   5.9GB/s
Matrox Parhelia (128MB)    DX8     4       4       128MB   275MHz  1x256-bit DDR   17.6GB/s
NVIDIA GF2 MX 200 (32MB)   DX7     2       2       32MB    166MHz  1x64-bit SDR    1.3GB/s
NVIDIA GF2 MX 400 (64MB)   DX7     2       2       64MB    166MHz  1x128-bit SDR   2.7GB/s
NVIDIA GF2 Pro (64MB)      DX7     4       2       64MB    200MHz  1x128-bit DDR   6.4GB/s
NVIDIA GF2 Ultra (64MB)    DX7     4       2       64MB    230MHz  1x128-bit DDR   7.36GB/s
NVIDIA GF3 (64MB)          DX8     4       2       64MB    230MHz  4x32-bit DDR    7.36GB/s
NVIDIA GF3 Ti200 (64MB)    DX8     4       2       64MB    200MHz  4x32-bit DDR    6.4GB/s
NVIDIA GF3 Ti500 (64MB)    DX8     4       2       64MB    250MHz  4x32-bit DDR    8.0GB/s
NVIDIA GF4 MX440 (64MB)    DX7     2       2       64MB    200MHz  2x64-bit DDR    6.4GB/s
NVIDIA GF4 MX460 (64MB)    DX7     2       2       64MB    275MHz  2x64-bit DDR    8.8GB/s
NVIDIA GF4 Ti4200 (128MB)  DX8     4       2       128MB   222MHz  4x32-bit DDR    7.1GB/s
NVIDIA GF4 Ti4200 (64MB)   DX8     4       2       64MB    250MHz  4x32-bit DDR    8.0GB/s
NVIDIA GF4 Ti4400 (128MB)  DX8     4       2       128MB   275MHz  4x32-bit DDR    8.8GB/s
NVIDIA GF4 Ti4600 (128MB)  DX8     4       2       128MB   325MHz  4x32-bit DDR    10.4GB/s
ST Micro Kyro II (64MB)    N/A     2       1       64MB    175MHz  1x128-bit SDR   2.8GB/s

Oei, oei, dit vermeubelt de layout een beetje

edit:

Heb er maar even 2 tabelletjes van gemaakt

[ Voor 36% gewijzigd door EXX op 02-01-2003 11:24 ]

[Verwijderd]

Hmz.. misschien moet ik duidelijker zijn:

Wat zijn de harware- en softwarematige beperkingen van GPU's om tot een optimaal (zie post over realtime rendering) resultaat te komen?

BV: pipelines, cpu kracht, memory bandwidth etc etc, drivers (wat precies)

EXX: dat schema is wel handig. tnx

En dan zijn er nog de economische beperkingen zoals concurrentie

[ Voor 12% gewijzigd door Verwijderd op 02-01-2003 11:24 ]

[floduR]

Dat schema is wel interessant, zo zie dat die Matrox Parhelia erg veel bandbreedte heeft door een 256bit memory bus, maar dat dat geen garantie is voor een snelle processie

Ik mis de radeon 9xxx serie, daar ben ik dan wel benieuwd naar. In deze tabel zijn de geforces nog het snelst, en dat met een 4x32bit mem bus

[Wekkel]

floduR schreef op 02 januari 2003 @ 11:27:
Dat schema is wel interessant, zo zie dat die Matrox Parhelia erg veel bandbreedte heeft door een 256bit memory bus, maar dat dat geen garantie is voor een snelle processie

Ik mis de radeon 9xxx serie, daar ben ik dan wel benieuwd naar. In deze tabel zijn de geforces nog het snelst, en dat met een 4x32bit mem bus

Vergeet niet dat Matrox niets gedaan heeft met Z-compressie technieken, zodat die hoge bandbreedte in de praktijk veel minder waard zou kunnen blijken. Bovendien zijn theoretische waarden minder interessant dan de praktische uitkomsten.

Zie het laatste geintje van ATi over vermelding van theoretische bandbreedtes in persberichten (mooie sneer richting Nvidia ).

[Aetje]

Het probleem met de huidige GPUs is dat ze gewoon niet de rekenkracht hebben om realtime niet-van-echt te onderscheiden beelden te renderen... Deze zouden in een dusdanig hoge resolutie )en met een monitor die deze resolutie met deze refreshrate aankan) moeten worden gecreerd, dat onze ogen het onderscheid tussen de pixels niet meer kunnen maken.

Verder, zelfs al zou de rekenkracht in de GPU zitten, de computer kan simpelweg de data niet snel genoeg naar de GPU brengen. AGP 8x is hier weer een stapje verder in...

[floduR]

Als je kijkt naar 3dmark en dan 'nature' dat ziet er niet heel realistisch uit, maar wel beweegt bijna alles realistisch (maar nog lang niet alles beweegt, zoals in real-live). Zet je alles naar maximaal (1600x1200 AA4x alles 32bit enz) dan haalt ie op een ti4600 de 30fps nog niet.

Dus tegen de tijd dat we een real-life 3d hologram image kunnen renderen, zijn we 200 jaar verder denk ik

[Wekkel]

Ik denk dat er op het moment meer problemen zijn met een software achterstand dan met hardware achterstand. Volgens mij blijft dat voorlopig ook even de trend.

Als het tempo van videohardware zo doorgaat met elke 6 maanden een nieuw vlaggeschip, mogen fabrikanten zo ongeveer hun eigen games/patches gaan maken om nog een argument te hebben voor de koopbereidheid van dit soort kaarten.

Het is de uitdaging van het moment om software ontwikkelaars met lange productie termijnen (meestal meer dan een jaar) goede tools te geven als hardware fabrikant om het meeste uit niet ouder dan 6 maanden zijnde hardware te trekken op het moment van release van zo'n spel.

Zeker met nieuwe features ipv spierballengeweld, waar nu de balans meer komt te liggen, moet er een goed argument blijven om een verse videokaart te kopen als consument. Aan niet bruikbare features op het moment van koop heb je weinig, aan meer fps altijd.

[apa]

Het grootste probleem is de software lijkt me... Om een volledig realistisch beeld te krijgen (vergelijkbaar met bv. DVD kwaliteit die je afspeeld op je PC), zou je een engine moeten schrijven die volledig realistisch kan werken en dat lijkt me geweldig ingewikkeld omdat allemaal hardwarematig op te vangen. Natuurlijk kan een GPU al veel realisme in zich bakken, maar genoeg zal het nooit zijn.

Tegenwoordig kan je bepaalde aspecten van beelden programmeren, maar eigenlijk zou ieder partikel die op het beeld zichtbaar is (of beter: die een invloed kan hebben op het beeld) volledig in code beschreven moeten worden. Om bv. een zandvlakte te beschrijven wordt nu gebruik gemaakt van een beschrijving van de de vlakte zelf. Je kan er allerlei eigenschappen van aangeven, maar uiteindelijk blijft het een vlak. Om visueel realistisch te kunnen zijn zou je ieder korreltje zand moeten beschrijven. Je ziet in games bv. vaak overgangen van zand/aarde naar gras. Maar de korrels die aan de schoenen van je personnage plakken, die verschijnen meestal niet op het gras. En als dat al wel zo is, dan blijft het er niet op... Of beweegt het zand en het gras niet mee met de wind, ...

Volgens mij is het nog niet voor meteen dat we 100% realistische beelden krijgen. We komen er zeker wel, maar het kan nog jaren duren. Ik kan me bv. best inbeelden dat we ooit omgevingen zullen kunnen creëren door te definiëren dat de muren van een bepaald type baksteen zijn, dat de grond van zand is en dat het regenachtig is. Al deze elementen van de omgeving zouden dan met elkaar kunnen interageren, zonder dat de programmeur daar rekening mee moet houden. Daarvoor zou je bv. een soort standaard database van omgevings-elementen kunnen gebruiken waar de volledige beschrijving van ieder element, samen met zijn interactie met andere elementen gestockeerd wordt.

[Verwijderd]

Wekkel schreef op 02 January 2003 @ 11:46:
Ik denk dat er op het moment meer problemen zijn met een software achterstand dan met hardware achterstand. Volgens mij blijft dat voorlopig ook even de trend.

Als het tempo van videohardware zo doorgaat met elke 6 maanden een nieuw vlaggeschip, mogen fabrikanten zo ongeveer hun eigen games/patches gaan maken om nog een argument te hebben voor de koopbereidheid van dit soort kaarten.

De software achterstand hangt meer van de fabrikant. Nvidia optimaliseert hun drivers bijvoorbeeld veel beter dan Ati, al is Ati hier ook al meer mee bezig. Maar de drivers van videokaarten zijn wel redelijk goed, door betere drivers zal een kaart hoogstens 25% beter worden (vanaf eerste release tot de laatste beste driver voor die kaart). En die 25% is eigenlijk al te veel.

En dat de kaarten te snel zijn voor de games op dit moment ben ik het niet mee eens, ik denk het juist andersom, de games lopen misschien wel voor op de videokaarten. Neem bijvoorbeeld unreal tournament 2003. Als je alles op de maximale instellingen zet is het nauwelijks te spelen, dan heb ik het dus wel over AA en AF beide aan. En verder is het handig dat kaarten erg snel zijn ivm de toekomst, je kunt er dan lekker lang mee.

[Wekkel]

Verwijderd schreef op 02 January 2003 @ 12:03:
[...]


De software achterstand hangt meer van de fabrikant. Nvidia optimaliseert hun drivers bijvoorbeeld veel beter dan Ati, al is Ati hier ook al meer mee bezig. Maar de drivers van videokaarten zijn wel redelijk goed, door betere drivers zal een kaart hoogstens 25% beter worden (vanaf eerste release tot de laatste beste driver voor die kaart). En die 25% is eigenlijk al te veel.

En dat de kaarten te snel zijn voor de games op dit moment ben ik het niet mee eens, ik denk het juist andersom, de games lopen misschien wel voor op de videokaarten. Neem bijvoorbeeld unreal tournament 2003. Als je alles op de maximale instellingen zet is het nauwelijks te spelen, dan heb ik het dus wel over AA en AF beide aan. En verder is het handig dat kaarten erg snel zijn ivm de toekomst, je kunt er dan lekker lang mee.

Je hebt het nu over driveraanpassingen. Daar refereer ik niet aan met software. Driveraanpassingen zullen primair betrekking hebben op samenwerking met overige hardware en API's, zoals Directx en OpenGL. De laatste twee heb ik niet in gedachten met software. Ik denk aan de software zelf, die gebruik maakt van de API's. Als de software geen of onvoldoende gebruik weet te maken van API's, ben je nog weinig geholpen met een verse videokaart, anders dan meer brute kracht.

Brute kracht, je geeft 't zelf al aan. Dat is waar kaarten nog steeds op afgerekend worden. Engines gaan nog uit van brute rekenkracht en polygonen pompen, terwijl de hardware al een ander pad inslaat. Effecten, overnemen van taken ipv zoveel mogelijk polygonen er doorheen jassen. Een slimmere benadering van 3d dus. De software grijpt terug op het bekende pad: polygonen, hoe meer, hoe beter. Aan al die mooie extra features op je videokaart heb je niets als je software daar niets mee doet. UT2003 zal vast features van huidige kaarten aanspreken, maar sofware wordt IMHO nog steeds gepunt op brute rekenkracht, ipv een slimme benadering.

[TweakerNummer]

Als je echt niet van echt te onderscheiden scene's wilt creeeren heb je niet zoveel aan al die leuke trucks zoals pixel en vertex shaders, bump mapping, texture compression etc. deze zijn meer bedoeld om een zo mooi mogelijk beeld te creeeren omdat de huidige video kaarten in vergelijking met de werkelijkheid erg gelimiteerd zijn. Je kan zonder een pixel & vertex shader veel mooiere water effecten creeeren maar het kost wel veel meer rekenkracht en die rekenkracht is er niet (tenminste niet zonder dat het ten koste gaat van andere modellen in de omgeving).

[Verwijderd]

wat ik het jammere vindt is dat bijvoorbeeld toen dx8 geintroduceerd werd er lange tijd geen dx8 spellen zijn uitgebracht, het 1e spel wat zichtbaar gebruik maakt van de nieuwigheden van dx8 is morrowind. Dit spel kwam veel later uit dan dx8, ofwel, de extra features die de gf3 t.o.v van de gf2 had werden niet benut ( ik laat snelheid even achterwegen ).

[Scighera]

Inderdaad, de hardware is altijd één DX-versie verder ivm met de software.
Wat ik ook een minpunt vind tegenwoordig, dat 3D voor 2D gaat. In nieuwe drivers wordt altijd de 3D verbeterd terwijl aan de 2D weergaven nauwelijks iets wordt gedaan. De 6025xp van Ati was een vooruitgang op het gebied van 2D, de Drivers die daarna weer kwamen waren op 3D gebied sneller maar dit was ten koste gegaan van de 2D.

Edit:
Ik vergeet te zeggen dat de overzichtelijkheid van de markt van vidoekaarten nou ook niet bepaald vooruit gaat (kijk maar naar de 8500,9000,9100 of Ti4400, TI4800)

[ Voor 18% gewijzigd door Scighera op 02-01-2003 12:56 ]

[Verwijderd]

Iemand nog suggesties over de prijs/kwaliteit als beperking? Dit is uiteraard persoonlijk, maar er zullen ongetwijfeld veel mensen met dezelfde mening zijn en dat is een representatief beeld voor de tweakers-groep

[Verwijderd]

Wekkel schreef op 02 januari 2003 @ 12:13:
[...]


Je hebt het nu over driveraanpassingen. Daar refereer ik niet aan met software. Driveraanpassingen zullen primair betrekking hebben op samenwerking met overige hardware en API's, zoals Directx en OpenGL. De laatste twee heb ik niet in gedachten met software. Ik denk aan de software zelf, die gebruik maakt van de API's. Als de software geen of onvoldoende gebruik weet te maken van API's, ben je nog weinig geholpen met een verse videokaart, anders dan meer brute kracht.

Brute kracht, je geeft 't zelf al aan. Dat is waar kaarten nog steeds op afgerekend worden. Engines gaan nog uit van brute rekenkracht en polygonen pompen, terwijl de hardware al een ander pad inslaat. Effecten, overnemen van taken ipv zoveel mogelijk polygonen er doorheen jassen. Een slimmere benadering van 3d dus. De software grijpt terug op het bekende pad: polygonen, hoe meer, hoe beter. Aan al die mooie extra features op je videokaart heb je niets als je software daar niets mee doet. UT2003 zal vast features van huidige kaarten aanspreken, maar sofware wordt IMHO nog steeds gepunt op brute rekenkracht, ipv een slimme benadering.

Welke software heeft dan in jouw ogen een achterstand? Je zegt dat de software een probleem is en dan wil ik wel eens weten wat je nu precies een probleem vind.

En wat is er mis met brute kracht? Ik kijk ook het meest naar brute kracht van kaarten, en degene die daarin het best presteert schaf ik ook aan. Natuurlijk moeten die kaarten wel van goede kwaliteit zijn en een normale 2d hebben. Als je een kaart wil die wat minder vlot is maar wel zeer scherp en stabiel neem je gewoon een Matrox, als je veel gamed neem je een Geforce.

[The Dutch Dude]

Kort gezegd:
De grootste beperking NU is rekenkracht. Je kunt dat een beetje opvangen met truukjes, maar een tekort is een tekort.
De grootste beperking WORD de realisme dat de software kan maken. Tenzij er idd databases en grafische talen uitkomen die dat alles al doen voor programmeurs. Anders word de software veel te duur (eh! prijs/kwaliteit)

En prijs is altijd een beperking. Een videokaart word gemaakt met een bedrag in gedachten (high-end of low-end). Puur ontwikkelen om een zo lomp mogelijke kaart te maken, die niemand kan kopen, maar over 3 jaar met de nieuwste technieken dan voor een normale prijs te maken is, is er niet bij voor een fabrikant. Les 1 van economie: een bedrijf moet altijd winst maken.

[xos]

Wat ook een beperking is de rest van de hardware. Zoals in vele benchmarks naar voren komt van de huidige generatie videokaarten blijkt dat de cpu de bottleneck aak is. Tis misschien niet direct een beperking van die videokaart maar zeker wel iets waar rekening mee gehouden moet worden aangezien de videokaart zo niet maximaal kan werken.

[peke]

De grootste beperking is zoals eerder gezegd de software, de fabrikanten zouden beter iedere gpu van éénzelfde generatie een exact zelfde ontwerp geven en dan besparen op het geheugen icm een lagere clock, perfect voorbeeld daarvan zijn de verschillen tussen r9700pro/r9700/r9500pro tov de r9500/r9100/r9000pro/r9000, de laatste serie is de meest verkochtte en de spellen worden ook daarvoor ontwikkeld.

[TweakerNummer]

Het prijsverschil tussen de R9500 Pro en non-Pro is niet zoveel (mits men niet voor de overdreven dure Hercules 9500 Pro kiest) en de 9500 Pro is wel veel sneller. De Pro wordt niet zoveel verkocht i.v.m. leveringsproblemen (lees: de OEM's kopen alles op).

Als je buiten de video kaart gaat kijken stuit je op veel meer problemen dan alleen de CPU. Als je real-time wilt renderen dat niet van echt te onderscheiden is zal je ook oneindige grote textures moeten genereren (dit zal terugvallen op het systeem geheugen) en ook zeer complexe berekeningen moeten uitvoeren wat betreft grote van de bladeren, hoe regendruppels vallen, zwaarte-kracht berekeningen etc etc. Er valt dus nog heel wat te berekenen voor de CPU en die heeft daartoe de juiste hoeveelheid cache, toelevering van data (van de HD), busbreedte enz. voor nodig. Zo wordt het een beetje een verhaal over wat er allemaal mis is met de computer......