Archiv verlassen und diese Seite im Standarddesign anzeigen : load balancing ?
mapel110
2003-04-30, 05:06:25
inwiefern kann es das bei grafikkarten denn geben ?
kann man zum beispiel arbeit von der graka auf die cpu verlagern, wenn man feststellt, dass diese das schneller kann ?
Exxtreme
2003-04-30, 05:36:09
Originally posted by mapel110
inwiefern kann es das bei grafikkarten denn geben ?
kann man zum beispiel arbeit von der graka auf die cpu verlagern, wenn man feststellt, dass diese das schneller kann ?
AFAIK geht das. Der Savage2000 konnte das angeblich um die T&L-Engine zu entlasten.
zeckensack
2003-04-30, 05:44:04
Originally posted by Exxtreme
AFAIK geht das. Der Savage2000 konnte das angeblich um die T&L-Engine zu entlasten. Der war gut :lol:
:rofl:
*scnr*
Exxtreme
2003-04-30, 05:46:46
Originally posted by zeckensack
Der war gut :lol:
:rofl:
*scnr*
Deswegen schrieb ich auch 'angeblich'. ;)
mapel110
2003-04-30, 05:51:23
hatte der savage 2000 nicht eine verkrüppelte t&l einheit ?
StefanV
2003-04-30, 09:04:54
Originally posted by mapel110
hatte der savage 2000 nicht eine verkrüppelte t&l einheit ?
Deswegen die Smileys von Zecke :)
BTW: konnten das nicht auch Geforce2 und GF3 ??
Endorphine
2003-04-30, 10:59:43
AFAIK machen die ATI- und nVidia-Treiber das schon seit längerem bei allen Geometrieberechnungen. Für mich erklärt das auch die Tatsache, dass die CPU-Auslastung sofort immer bei 100 % ist, wenn nur mal eine Pyramide aus sechs Dreiecken beschleunigt gezeichnet und einfarbig texturiert wird.
Interessant wäre es doch sicher, das load balancing mal auszuschalten und die VS-Performance mal einigermassen losgelöst von der CPU messen zu können. Ginge das nicht mit ein paar Registryeinträgen (aths und Exxtreme könnten sicher Antwort geben :))? Ich könnte mir auch gut vorstellen, dass die T&L Einheit von GPUs bis GF2 bei heutigen CPUs >2 GHz eher bremst als beschleunigt.
Chris Lux
2003-04-30, 11:06:26
Originally posted by Endorphine
AFAIK machen die ATI- und nVidia-Treiber das schon seit längerem bei allen Geometrieberechnungen. Für mich erklärt das auch die Tatsache, dass die CPU-Auslastung sofort immer bei 100 % ist, wenn nur mal eine Pyramide aus sechs Dreiecken beschleunigt gezeichnet und einfarbig texturiert wird.
hehe, das liegt ehr daran, dass man diese pyramide in einer quasi endlos schleife immer wieder zeichnet und nicht wartet bis sich was am bild ändert ;)
zeckensack
2003-04-30, 11:24:17
Originally posted by Hans Ohlo
hehe, das liegt ehr daran, dass man diese pyramide in einer quasi endlos schleife immer wieder zeichnet und nicht wartet bis sich was am bild ändert ;) Jopp :)
Originally posted by Endorphine
AFAIK machen die ATI- und nVidia-Treiber das schon seit längerem bei allen Geometrieberechnungen.
AFAIK machen weder Ati noch NV sowas.
Deshalb ist die Geometrieleistung einer Radeon oder GF auf AMD k6-400 und XP1700 exakt identisch.
micki
2003-04-30, 12:51:20
die grakas von creativ labs VP760 oder so haben ein balancing in der graka. die ist programmierbar und deswegen kann man einstellen in welchem verhältniss die recheneinheiten was tun, also z.B. schwerpunkt auf transformation oder auf pixelshading legen.
dass die savage2000 sowas können soll, hab ich auch gelesen.
Mfg
micki
Endorphine
2003-04-30, 13:03:31
Originally posted by Hans Ohlo
hehe, das liegt ehr daran, dass man diese pyramide in einer quasi endlos schleife immer wieder zeichnet und nicht wartet bis sich was am bild ändert ;) Stimmt :sulkoff: ;) Daran hab ich vorhin nicht gedacht.
Warum ist das eigentlich so? Das ist doch irgendwo eine hirnrissige Verschwendung von CPU- und GPU-Leistung. Ich bleibe ja auch nicht nach dem einparken im Auto sitzen und fahre immer wieder in die Parklücke rein und raus, bis ich irgendwann mal wieder irgendwo hinfahren muss (oder der Sprit alle ist oder was weiss ich).
Endorphine
2003-04-30, 13:05:53
Originally posted by ow
AFAIK machen weder Ati noch NV sowas.
Deshalb ist die Geometrieleistung einer Radeon oder GF auf AMD k6-400 und XP1700 exakt identisch. Ich hatte mal vor längerer Zeit irgendwo was gelesen, dass zumindest der nVidia-Treiber zwecks optimaler Performance die Geometriearbeit zwischen GPU und CPU dynamisch aufteilt. Frag mich aber nicht wo und ob das ne zuverlässige Quelle war...
mapel110
2003-04-30, 13:36:16
Originally posted by Endorphine
Stimmt :sulkoff: ;) Daran hab ich vorhin nicht gedacht.
Warum ist das eigentlich so? Das ist doch irgendwo eine hirnrissige Verschwendung von CPU- und GPU-Leistung. Ich bleibe ja auch nicht nach dem einparken im Auto sitzen und fahre immer wieder in die Parklücke rein und raus, bis ich irgendwann mal wieder irgendwo hinfahren muss (oder der Sprit alle ist oder was weiss ich).
es gibt ja fps begrenzer oder v-sync ;)
Originally posted by Endorphine
Ich hatte mal vor längerer Zeit irgendwo was gelesen, dass zumindest der nVidia-Treiber zwecks optimaler Performance die Geometriearbeit zwischen GPU und CPU dynamisch aufteilt. Frag mich aber nicht wo und ob das ne zuverlässige Quelle war...
vielleicht ist in den NV-Quadro-Treibern sowas drin. (?)
Sinn macht es ja ohnehin nur bei der T&L Berechnung, bei der Pixel-Berechnung kann die CPU gar nicht mehr eingreifen.
3DLabs hat afaik T&L-load-balancing schon laenger implementiert.
zeckensack
2003-04-30, 13:55:42
Originally posted by micki
dass die savage2000 sowas können soll, hab ich auch gelesen.
Mfg
micki Das finde ich vor allem deswegen komisch, weil die T&L-Einheit des S2k erst mit dem Holzhammer gefixt werden mußte. Im 3DMark2000 kommt das Gerät dann noch auf ~2Mio Tris/s IIRC, was nun wirklich nicht bemerkenswert viel ist.
Das verdächtige an der Geschichte ist, daß diese Geometrieleistung konstant ist, egal wieviele HW-Lichter aktiv sind. Der S2k hat IMO ein Problem damit, wenn er weniger als 8 Lichter berechnen soll. Dadurch wird die T&L komplett kontraproduktiv, weil das L in T&L bekanntermaßen (oder vielleicht "leider"?) im Consumer-Bereich eher ein 'störender Nebeneffekt' war und ist.
Um jetzt den Bogen zu kriegen: jede CPU die es zur Lebzeit des S2k (neuwertig) zu kaufen gab, konnte die Transformation schneller erledigen. Load balancing macht da nun wirklich keinen Sinn, das einzige was man mit dieser T&L-Einheit in der Praxis anfangen konnte, war sie abzuschalten ;)
Originally posted by zeckensack
das einzige was man mit dieser T&L-Einheit in der Praxis anfangen konnte, war sie abzuschalten ;)
zumal eine aktive HWT&L unter OGL auch noch massiv Bildfehler verursacht hat, so gesehen zB. unter Q3 auf meiner (ex-deiner;)) S2k.
micki
2003-04-30, 16:02:54
2mio polys sind auch das, was man über den bus an eine graka schieben kann... jedenfalls hab ich ums brechen nicht geschaft mit opengl und den arrays mehr darstellen zu lassen (pro sek)
vielleicht hatten die t&l keine möglichkeit die buffer im vram zu halten und sie haben vertices immer durschieben müssen.
MfG
micki
Originally posted by micki
2mio polys sind auch das, was man über den bus an eine graka schieben kann...
MfG
micki
Noe, meine PCI Voodoo Banshee schafft schon 4Mio. tris/s in den 3DMarks 2000/2001.
micki
2003-04-30, 16:30:13
hmm... dann muss ich immer wat falsch gemacht haben ;)
MfG
micki
ps. wenn man mehrere passes mit der selben geometrie macht, kann man den buffer locken und mehrmals zeichnen, damit würde man dann mehr als 2mio bekommen...
Originally posted by micki
hmm... dann muss ich immer wat falsch gemacht haben ;)
MfG
micki
ps. wenn man mehrere passes mit der selben geometrie macht, kann man den buffer locken und mehrmals zeichnen, damit würde man dann mehr als 2mio bekommen...
Hab gerade mal den Polygon-Test des 3DM2001 in SW TL auf einer Radeon8500 gebencht:
1L: 4,1 Mio.
8L: 2,2 Mio.
/edit: 3DM2000, SW TL
1L: 4284k
4L: 3575k
8L: 2856k
mit P3 Optimierung (SSE)
1L: 6988k
4L: 6168k
8L: 5429k
Alles auf AMD XP1700, Win98, Cat3.2.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.