PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : J.C kommentar zu nv30 vs r300 in doom3


tEd
2003-01-30, 04:48:59
http://www.shacknews.com/docs/press/012903_carmackplan.x

doom3 wird tatsächlich floating point shaders nutzen , das find ich toll. Ich häts ehrlich gesagt nicht gedacht.

Razor
2003-01-30, 06:47:45
Originally posted by tEd
http://www.shacknews.com/docs/press/012903_carmackplan.x

doom3 wird tatsächlich floating point shaders nutzen , das find ich toll. Ich häts ehrlich gesagt nicht gedacht.
Jo, hab' ich auch gerade gelesen...

R300-Unterstützung
- ARB (Basic)
- R200 (full featured, almost always single pass)
- ARB2 (floating point fragment shaders, minor quality improvements, always single pass)

NV30-Unterstützung
- ARB (Basic)
- NV10 (full featured, five rendering passes, no vertex programs)
- NV20 (full featured, two to three rendering passes)
- NV30 (full featured, always single pass)
- ARB2 (floating point fragment shaders, minor quality improvements, always single pass)

Zumindest gibt's einen R200-Path für ATI-Karten *eg*
(nicht ganz ernst gemeint ;-)

Bis denne

Razor

Salvee
2003-01-30, 06:52:58
THX tEd,

hier der Grafikchip-relevante Teil:


Jan 29, 2003
------------
NV30 vs R300, current developments, etc

At the moment, the NV30 is slightly faster on most scenes in Doom than the R300, but I can still find some scenes where the R300 pulls a little bit ahead.
The issue is complicated because of the different ways the cards can choose to run the game.

The R300 can run Doom in three different modes: ARB (minimum extensions, no specular highlights, no vertex programs),
R200 (full featured, almost always single pass interaction rendering), ARB2 (floating point fragment shaders, minor quality improvements, always single pass).

The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five rendering passes, no vertex programs), NV20 (full featured, two or three rendering passes),
NV30 ( full featured, single pass), and ARB2.

The R200 path has a slight speed advantage over the ARB2 path on the R300, but only by a small margin, so it defaults to using the ARB2 path for the quality improvements.
The NV30 runs the ARB2 path MUCH slower than the NV30 path. Half the speed at the moment.
This is unfortunate, because when you do an exact, apples-to-apples comparison using exactly the same API, the R300 looks twice as fast, but when you use the vendor-specific paths, the NV30 wins.

The reason for this is that ATI does everything at high precision all the time, while Nvidia internally supports three different precisions with different performances.
To make it even more complicated, the exact precision that ATI uses is in between the floating point precisions offered by Nvidia, so when Nvidia runs fragment programs, they are at a higher precision than ATI's, which is some ustification for the slower speed. Nvidia assures me that there is a lot of room for improving the fragment program performance with improved driver compiler technology.

The current NV30 cards do have some other disadvantages: They take up two slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually one to care about fan noise, but the NV30 does annoy me.

I am using an NV30 in my primary work system now, largely so I can test more of the rendering paths on one system, and because I feel Nvidia still has somewhat better driver quality (ATI continues to improve, though). For a typical consumer, I don't think the decision is at all clear cut at the moment. For developers doing forward looking work, there is a different tradeoff -- the NV30 runs fragment programs much slower, but it has a huge maximum instruction count. I have bumped into program limits on the R300 already.

As always, better cards are coming soon.

John Carmack


@ Razor
Der R300 braucht keinen eigenen Renderpfad, um gut zu performen *eg*
(nicht ganz ernstgemeint ;-)

Edit: Der Rest ist natürlich auch höchst lesenswert.

WeyounTM
2003-01-30, 07:20:49
IMHO nervt das ganze Gehype rund um Doom ein wenig. Man kauft sich doch bitte schön nicht eine Graka wegen einem Spiel. Und jetzt kommt mir nicht mit solchen Sprüchen wie: wennze in Doom gut performt, dann lüppt auch alles andere flott ;)

Aber wie gesagt: alles nur IMHO

Salvee
2003-01-30, 07:35:05
Es geht ja nicht um Doom, sondern darum, was John Carmack über die Chips zu berichten hat.
Der Typ hat schon mehr über 3D Grafik vergessen, als fast alle hier jemals wissen werden.
Er reizt die Karten jedesmal bis aufs letzte aus, findet Bugs und Fehler, und veröffentlicht diese auch, da er auf niemanden Rücksicht nehmen muss.
Mir fällt kein anderer Developer ein, welcher dermassen auf den Punkt kommt.

WeyounTM
2003-01-30, 07:42:03
Unter dem Aspekt sieht die Sache natürlich anders aus ;) ! Nach dem 1 Millionsten Doom3 /JC Thread wird man wohl etwas zu feinfühlig :D . Nichtsdestotrotz gibt es ja eine ganze Menge Zeitgenossen die so verfahren, wie ich es oben angedeutet habe ;) !

mirp
2003-01-30, 07:56:49
Es wird über Jahre etliche Spiele geben, die auf der Doom3-Engine basieren. Also geht es hier eher darum, wie bestimmte Grafikkarten mit dieser Engine zurechtkommen, als um das Spiel Doom3.

Natürlich sagt das nichts über andere Engines aus. ;-)

WeyounTM
2003-01-30, 08:05:01
Originally posted by mirp
Natürlich sagt das nichts über andere Engines aus. ;-)

Sag ich ja :)
Bei Morrowind haben mir die ganzen q3-Engine-Tests jedenfalls nicht wirklich weitergeholfen...

Aber vielleicht gibt es ja irgendwann auch mal ein Rollenspiel mit D3-Engine :stareup:

nggalai
2003-01-30, 08:54:06
Hi there,

die technische Diskussion zum .plan (i.e. hauptsächlich der zweite Teil des Textes) findet da statt:

http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=52123

Hier bitte nur "allgemeines" und Grafikkarten-spezifisches diskutieren. :)

z.B. das hier:

"The current NV30 cards do have some other disadvantages: They take up two slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually one to care about fan noise, but the NV30 does annoy me."

Wow. Wenn sogar Carmack sich über den Lärm beklagt, dann muss es echt mühsam sein. Wie schon im anderen Thread gefragt--hat wer bestätigte Informationen (i.e. nicht THG), dass der Föhn auf den Review-Karten nicht dem endgültigen Modell entspricht? Mal abgesehen von der Farbe?

ta,
-Sascha.rb

perforierer
2003-01-30, 09:32:28
Ich glaube da gibts noch keine bestätigte Info. Jedenfalls hab ich noch nix in der Richtung gelesen. Nach wie vor gilt, dass nVidia versprochen hat, die Karte würde nicht so laut sein in der fertigen Version. Andererseits ist ja schon der Idle-Modus derb laut.
Ich weiss auch nicht, inwieweit die Entscheidung nVidias, die Karten selbst fertigen zu lassen die Lüfterwahl der einzelnen"Hersteller" beeinflusst.

P.S.: Ich finde, die erste Hälfte des JC Comments sollte man hier kommentieren, weil es da ja auch um die Fähigkeiten des FX geht.

SamLombardo
2003-01-30, 10:41:14
Kann mir mal jemand erklären was es mit den floating point shaders auf sich hat? bzw was der Fakt dass D3 diese nutzen will nun eigentlich praktisch bedeutet?


Vielen Dank im Vorraus, Sam

Dr. Greenthumb
2003-01-30, 10:49:32
Originally posted by perforierer
Ich glaube da gibts noch keine bestätigte Info. Jedenfalls hab ich noch nix in der Richtung gelesen. Nach wie vor gilt, dass nVidia versprochen hat, die Karte würde nicht so laut sein in der fertigen Version. Andererseits ist ja schon der Idle-Modus derb laut.
Ich weiss auch nicht, inwieweit die Entscheidung nVidias, die Karten selbst fertigen zu lassen die Lüfterwahl der einzelnen"Hersteller" beeinflusst.

P.S.: Ich finde, die erste Hälfte des JC Comments sollte man hier kommentieren, weil es da ja auch um die Fähigkeiten des FX geht.

Zum Kühler: Thilo hat (wo weiss ich nicht mehr) gepostet das die Hersteller eigene Kühlerlösungen entwickeln die den Leadtek GF4ti Kühlern sehr ähnlich sehen, also Riesenkühlkörper mit 2 Lüftern der die Karte komplett umschliesst, aber noch ein wenig massiver ausfallen. Lauter als die jetzige Lösungen werden die bestimmt nicht.

Zu den Fähigkeiten: Die Karte hat sehr flexible Möglichkeiten, grade was die Shader angeht. Das John Carmack immmer noch der Oberguru ist, sieht man IMHO auch daran, das er sich (im Gegensatz zu fast allen Konkurrenten) für eine OpenGL Engine entschieden hat. Nur damit kann man, über eigene Renderpafade, die Möglichkeiten voll ausschöpfen. Das Spiel läuft im optimalen Fall immmer mit der besten BQ die die Karte darzustellen vermag.

Wenn D3 rauskommt, geht es also wieder los mit den Screenshots R300 vs nV30!!! Vorrauszitat ;D: "Im Tunnel sieht meine 9700 besser aus!!" oder "Die Lampe wirft am Eingang präzisere Schatten mit meiner FX!!"

Das wird (wieder) ein Spass *eg*

Demirug
2003-01-30, 10:57:14
Originally posted by SamLombardo
Kann mir mal jemand erklären was es mit den floating point shaders auf sich hat? bzw was der Fakt dass D3 diese nutzen will nun eigentlich praktisch bedeutet?


Vielen Dank im Vorraus, Sam

floating point shader erlauben eine höhere Genauigkeit beim berechnen der Pixelfarben. Dadurch werden zum einen Colorbanding effekte reduziert (bei floating point nur noch in ganz extremen fällen) zum anderen können Bumpmap und Reflextionseffekte ebenfalls genauer gerechnet werden.

Um es kurz zu machen: floating point shader erzeugen ein optisch besseres Ergebniss.

aths
2003-01-30, 11:16:48
Originally posted by SamLombardo
Kann mir mal jemand erklären was es mit den floating point shaders auf sich hat? bzw was der Fakt dass D3 diese nutzen will nun eigentlich praktisch bedeutet?

Vielen Dank im Vorraus, Sam Einerseits wird die Genauigkeit erhöht. Momentan wird vorwiegend mit 1+8 (Vorzeichen-Bit + "Nachkomma-Bits") = 9 Bit Integer pro Farbkanal gerechnet, (Radeon 8500 rechnet afaik mit mindestens 12 Bit Integer.)

Floating Point Formate für Grafikkarten gehen erst ab 16 Bit los, womit sich also feinere Abstufungen berechnen lassen. Der vielleicht noch wichtigerer "Trick" ist aber die Art der Speicherung. Mit Integer wird jede Grundfarbe gleichmäßig abgestuft, mit Floating Point werden schwache Intensitäten jedoch feiner quantisiert. Das wirkt sich positiv auf den Rundungsfehler bei Multiplikationen aus.

Bei Integer-Formaten ist der Rundungs-Fehler bei kleinen Werten relativ gesehen sehr groß, bei Floating-Point-Formaten wird der Fehler viel gleichmäßiger über alle Intensitäten verteilt.

Dank der Floating-Point-Darstellung ist also der Rundungsfehler unproblematischer, und dank der im gleichen Zuge erhöhten Bit-Zahl ist das Ergebnis ohnehin noch mal genauer.

Das hat eine Reihe angenehmer Eigenschaften. Bei Max Payne, aber auch Quake, besonders gut aber bei RtCW sieht man schon heute im 32-Bit-Modus "Color-Banding", also Farb-Abstufungen statt feinen Übergängen. Zwar reicht die 24-Bit-Farbe beim 32-Bit-Rendering eigentlich aus, um feinste Übergänge darzustellen, doch weil während der Berechnung zwischendurch gerundet wird, bekommt man gröbere Ergebnisse.

Außerdem muss man heute mit dem Integer-Format etwas tricksen, um Overbright Lighting zu realisieren. Von der 8 Bit Auflösung pro Farb-Kanal verbleiben dann effektiv z.B. nur noch 6. Beim Floating Point Format hat man von vornherein einen größeren Farbraum als von -1 ... +1, so dass Overbright Lighting ohne "Tricks" möglich ist.

Beim Bump Mapping muss man aktuell mit nur 8 Bit alle möglichen Winkel realisieren, was leider zu grob für wirklich feine Details ist. Hier bringen Floating-Point-Texturen genauere Bump Maps, was in Zukunft hoffentlich endlich mal zu "Detailed Bump Maps" führt, die sich sehen lassen können...

Unregistered
2003-01-30, 11:30:56
Originally posted by mirp
Es wird über Jahre etliche Spiele geben, die auf der Doom3-Engine basieren. Also geht es hier eher darum, wie bestimmte Grafikkarten mit dieser Engine zurechtkommen, als um das Spiel Doom3.

Natürlich sagt das nichts über andere Engines aus. ;-)
Welche Spiele basieren denn auf der Q2(!)-Engine? Wenn man die alle gerne spielt, dann fällt einem die Wahl der richtigen Graka vielleicht leichter. Die Folgespiele dieser Entwickler werden dann wahrscheinlich auf der Q3-Engine basieren.

Unregistered
2003-01-30, 11:42:12
Originally posted by Salvee
Es geht ja nicht um Doom, sondern darum, was John Carmack über die Chips zu berichten hat.
Der Typ hat schon mehr über 3D Grafik vergessen, als fast alle hier jemals wissen werden.
Er reizt die Karten jedesmal bis aufs letzte aus, findet Bugs und Fehler, und veröffentlicht diese auch, da er auf niemanden Rücksicht nehmen muss.
Mir fällt kein anderer Developer ein, welcher dermassen auf den Punkt kommt. das ist aber aus nem alten interview genau wie der grösste teil des oberen posts von dir

Radeonator
2003-01-30, 11:48:41
Auf jedenfall findet J.C. die NV30 auch zum :kotz: Laut

"The current NV30 cards do have some other disadvantages: They take up two
slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually
one to care about fan noise, but the NV30 does annoy me."

:rofl:

Er wird nicht der letzte sein, den das Teil derbst nerven wird...

Hauwech
2003-01-30, 12:13:38
Also noch einmal, NVidia laesst am Anfang erstmal Grakas produzieren damit die ganzen Firmen erst mal ueberhaupt genuegend haben. Danach koennen die machen was die wollen mit der Kuehlung solange sie die Spezifikationen von Nvidia einhalten. Von daher glaube ich ganz stark das JC sich ne neue holen wird (na gut, er selber wohl eher nicht, da werden sich die Grakahersteller die Klinke in die Hand druecken: Nimm meine! Nein! Meine ist viel leiser!! Quatsch!! bal abl abla ;)).
Eigentlich wirklich schade ist, dass er wahrscheinlich neben NVidia ist, (oder vielleicht DER einzige ;)) der den NV30 am besten kennt und auch ausnutzen wird. Info's von ihm was den Chip und dessen Aufbau/Faehigkeiten betrifft waeren wahrscheinlich Gold wert :)

Radeonator
2003-01-30, 12:47:19
Axo und welches Kühlsystem soll da deiner Meinung nach vewendet werden???

Der Chip wird AFAIK extrem Heis (selbst die Rückseite soll kochend Heiss werden) , also braucht man eine sehr gute Kühlung. Die einzige bessere Lösung wäre WAKÜ, der Preis würde dadurch aber bestimmt nicht niedriger...

Piffan
2003-01-30, 13:27:34
Wenn ich richtig verstanden habe, dann ist die Ati besser, wenn sich J.C an die "reine API" hält. Der NV braucht hingegen eine Extrawurst bzw. man muß nach dem NV- Treiber compilieren.....

Ungeachtet der Möglichkeiten in der fernen Zukunft, kurzfristig scheint mir, dass NV sich einen Vorteil dadurch zu verschaffen erhofft, dass man die Entwickler zu sich rüberzieht, damit diese mal wieder NV- like entwicklelt...

Habe ich das so in etwa richtig verstanden? Oder interpretiere ich mal wieder Böswilligkeit hinein? Da Prob ist, dass ich von API, Renderpfaden, 3d- Programmierung null Ahnung hab....

Wenn es aber im Tenor so ist, dann ist NV für mich erledigt....

Unregistered
2003-01-30, 13:50:28
Originally posted by Piffan
Wenn ich richtig verstanden habe, dann ist die Ati besser, wenn sich J.C an die "reine API" hält. Der NV braucht hingegen eine Extrawurst bzw. man muß nach dem NV- Treiber compilieren.....

Ungeachtet der Möglichkeiten in der fernen Zukunft, kurzfristig scheint mir, dass NV sich einen Vorteil dadurch zu verschaffen erhofft, dass man die Entwickler zu sich rüberzieht, damit diese mal wieder NV- like entwicklelt...

Habe ich das so in etwa richtig verstanden? Oder interpretiere ich mal wieder Böswilligkeit hinein? Da Prob ist, dass ich von API, Renderpfaden, 3d- Programmierung null Ahnung hab....

Wenn es aber im Tenor so ist, dann ist NV für mich erledigt....


Jo, es scheint so als wenn die höhere Genauigkeit von 128Bit selbst intern durch eine Halbierung der Leistung erkauft werden muß. So reichts unter normalen Umständen nur für 16Bit-FP, was für nVidia-gewöhnte aber trotzdem bei normalen Spielen der reinen Luxus seion sollte (hab mir gestern mal wieder schön das Colorbanding der GF3/4 in BF1942 angetan).

Bei Doom 3 scheints aber trotzdem einen sehbaren Unterschied zu machen, wahrscheinlich aufgrund der komplexen Berechnungen. Das sind halt so die Sachen, die nicht im nVidia-Launchpaper neben den "schöneren Pixeln" stehen.:D

Labberlippe
2003-01-30, 13:52:37
Originally posted by Piffan
Wenn ich richtig verstanden habe, dann ist die Ati besser, wenn sich J.C an die "reine API" hält. Der NV braucht hingegen eine Extrawurst bzw. man muß nach dem NV- Treiber compilieren.....

Ungeachtet der Möglichkeiten in der fernen Zukunft, kurzfristig scheint mir, dass NV sich einen Vorteil dadurch zu verschaffen erhofft, dass man die Entwickler zu sich rüberzieht, damit diese mal wieder NV- like entwicklelt...

Habe ich das so in etwa richtig verstanden? Oder interpretiere ich mal wieder Böswilligkeit hinein? Da Prob ist, dass ich von API, Renderpfaden, 3d- Programmierung null Ahnung hab....

Wenn es aber im Tenor so ist, dann ist NV für mich erledigt....

Ich bin eher der Meinung das der NV30 einiges am Kasten hat.
Dadurch ist es nicht so einfach dem einen "Standartpfad" zu geben.
Die Frage ist, wieviel wurde jetzt wirklich im Chip verändert.
Wenn nur minimale Änderungen sind, dann ist schon heavig.

Gruss Labberlippe

nggalai
2003-01-30, 13:53:02
Originally posted by Piffan
Wenn ich richtig verstanden habe, dann ist die Ati besser, wenn sich J.C an die "reine API" hält. Der NV braucht hingegen eine Extrawurst bzw. man muß nach dem NV- Treiber compilieren.....Jein. Im ARB2-Modus verwendet die NV30 das 32bitFP Format, die Radeon9700 24bitFP. Beim Herstellerspezifischen Pfad ist's noch unklar, ob da bei der NV30 16bitFP oder Integer verwendet wird.

i.e. ist nicht ganz ein Apfel-Apfel vergleich, obwohl derselbe Pfad verwendet wird.

ta,
-Sascha.rb

nggalai
2003-01-30, 13:54:13
Hi there,
Originally posted by Unregistered
Jo, es scheint so als wenn die höhere Genauigkeit von 128Bit selbst intern durch eine Halbierung der Leistung erkauft werden muß. So reichts unter normalen Umständen nur für 16Bit-FP, was für nVidia-gewöhnte aber trotzdem bei normalen Spielen der reinen Luxus seion sollte (hab mir gestern mal wieder schön das Colorbanding der GF3/4 in BF1942 angetan).

Bei Doom 3 scheints aber trotzdem einen sehbaren Unterschied zu machen, wahrscheinlich aufgrund der komplexen Berechnungen. Das sind halt so die Sachen, die nicht im nVidia-Launchpaper neben den "schöneren Pixeln" stehen.:D Naja--Offline-Renderer z.B. Renderman werden meist mit 16bit FP verwendet, i.e. DAS sollte für ein Spiel echt dicke reichen.

ta,
-Sascha.rb

Piffan
2003-01-30, 13:57:42
Originally posted by Piffan
Wenn ich richtig verstanden habe, dann ist die Ati besser, wenn sich J.C an die "reine API" hält. Der NV braucht hingegen eine Extrawurst bzw. man muß nach dem NV- Treiber compilieren.....

Ungeachtet der Möglichkeiten in der fernen Zukunft, kurzfristig scheint mir, dass NV sich einen Vorteil dadurch zu verschaffen erhofft, dass man die Entwickler zu sich rüberzieht, damit diese mal wieder NV- like entwicklelt...

Habe ich das so in etwa richtig verstanden? Oder interpretiere ich mal wieder Böswilligkeit hinein? Da Prob ist, dass ich von API, Renderpfaden, 3d- Programmierung null Ahnung hab....

Wenn es aber im Tenor so ist, dann ist NV für mich erledigt....

Um das noch mal genauer auszuführen: Hält sich JC strikt an die Api, dann ist die Radeon doppelt so fix bei ARB2. Um die NV schneller zu machen als die Radeon, muß er für die NV30 eine Extrawurst braten....

Für den BEncher oder Spieler heißt es dann: Wow, die NV ist schneller als die Ati... Ja, aber nur durch einen Zusatzaufwand, den die Entwickler bringen müssen...Falls der NV30 DER Hammer geworden wäre, dann wäre zu befürchten, dass die NV- Lastigkeit der Developper niemals nachlässt....

Jetzt wo aber die NV mehr oder weniger "durchschnittliche" Leistungen erbringt, ist die Gefahr einer starken Verbreitung in der Spielerschaft wohl eher gering.... also vielleicht doch keine Extrawurst für NV....

edit: Jau, habe das mit den 128bit eben auch gelesen. Wenn der Output durch die Extra- Wurst tatsächlich schöner wird, dann sähe es vielleicht anders aus.... Also würde man die bessere Bildqualität nur sehen, wenn man die volle Präzision auch ausnutzt. Aber muß da tatsächlich ein eigener Pfad geschrieben werden, kann der Treiber nicht als Wrapper fungieren.... Denn sonst werden doch wohl die wenigsten Spiele die NV30 voll unterstützen...

Hauwech
2003-01-30, 13:58:53
Originally posted by Radeonator
Axo und welches Kühlsystem soll da deiner Meinung nach vewendet werden???

Der Chip wird AFAIK extrem Heis (selbst die Rückseite soll kochend Heiss werden) , also braucht man eine sehr gute Kühlung. Die einzige bessere Lösung wäre WAKÜ, der Preis würde dadurch aber bestimmt nicht niedriger...

Hat doch Dr. Greenthumb schon gesagt und dem schliesse ich mich auch an.

Crushinator
2003-01-30, 13:59:35
Originally posted by Piffan Habe ich das so in etwa richtig verstanden? Oder interpretiere ich mal wieder Böswilligkeit hinein? Da Prob ist, dass ich von API, Renderpfaden, 3d- Programmierung null Ahnung hab.... Meine Meinung: Der Kommentar ist nach meinem Geschmack sehr objektiv und gibt die derzeitigen Fakten zum Thema R300 vs NV30 klasse wieder. Ich lese u.A. daß er das raffiniert findet, daß NV nicht überall mit voller Genauigkeit rechnet. (wenn's in dem Augenblick eh nicht gebraucht wird) und daß NV30 einen eigenen Renderpfad haben muß, um vernünftig schnell zu sein. Als Entwickler würde ich da genau so verfahren wie er, zumal die R300 schnell genug zu sein scheint.

Kurz gesagt: Er findet auch, daß es z.Z. eine mehr oder weniger Patt-Situation ist mit leichten Speed-Vorteilen für NV30, und Ich interpretiere da noch hinein, daß erst wenn JC irgendwann auch mal primär auf 'ner Radeon entwicklet, man auch den Praktikanten loben kann.;)

Labberlippe
2003-01-30, 14:01:25
Originally posted by Piffan


Um das noch mal genauer auszuführen: Hält sich JC strikt an die Api, dann ist die Radeon doppelt so fix bei ARB2. Um die NV schneller zu machen als die Radeon, muß er für die NV30 eine Extrawurst braten....

Für den BEncher oder Spieler heißt es dann: Wow, die NV ist schneller als die Ati... Ja, aber nur durch einen Zusatzaufwand, den die Entwickler bringen müssen...Falls der NV30 DER Hammer geworden wäre, dann wäre zu befürchten, dass die NV- Lastigkeit der Developper niemals nachlässt....

Jetzt wo aber die NV mehr oder weniger "durchschnittliche" Leistungen erbringt, ist die Gefahr einer starken Verbreitung in der Spielerschaft wohl eher gering.... also vielleicht doch keine Extrawurst für NV....

Hi

Also von dieser Seite aus wäre es natürlich keine gute Aktion.
Kurz wenn er einen Pfad nehmen muss, welche "schlechter" ist damit die NV30 Performt, dann ist das nicht gut.
Kurz es heist die Karte ist schnell, ein neuer Rekord. (Dafür die Qualität lausiger, aber das fällt ja dann keinen auf.)

Hmm mal gucken wie J.C das lösen wird.

Gruss Labberlippe

BlackBirdSR
2003-01-30, 14:06:16
sieht man den Unterschied 16FP 24FP?
hat ATi eigene Extensions zu OpenGL die Carmack benutzen könnte?

also was soll er groß einen eigenen R300 Pfad schreiben, obwohl sie bei ARB und R200 schon sehr schnell läuft?

Quasar
2003-01-30, 14:14:35
Originally posted by Labberlippe
(Dafür die Qualität lausiger, aber das fällt ja dann keinen auf.)

Das kannst du genausogut von 24 vs 32Bit FP behaupten.

Blöderweise scheint wirklich kein echter 1:1 Vergleich möglich zu sein. Ich denke, schon der Sprung auf 16Bit FP wird bei guter Ausnutzung der Möglichkeiten ein visueller Quantensprung sein, eine weitere Erhöhung auf 24Bit sieht man möglicherweise beim direkten Vergleich in einigen Situationen und den noch weiteren Sprung auf 32Bit FP kann man allerhöchstens für Offline-Rendering als Sinnvoll erachten, IMO.

Da werden sich wieder die Geister scheiden, wie vormals bei der SS vs. MS-Debatte und neuerlich bei der biAF vs. triAF bzw. dann der optimierten triAF vs. unoptimierten triAF Diskussion.

Demirug
2003-01-30, 14:19:26
Originally posted by Piffan
Wenn ich richtig verstanden habe, dann ist die Ati besser, wenn sich J.C an die "reine API" hält. Der NV braucht hingegen eine Extrawurst bzw. man muß nach dem NV- Treiber compilieren.....

Ungeachtet der Möglichkeiten in der fernen Zukunft, kurzfristig scheint mir, dass NV sich einen Vorteil dadurch zu verschaffen erhofft, dass man die Entwickler zu sich rüberzieht, damit diese mal wieder NV- like entwicklelt...

Habe ich das so in etwa richtig verstanden? Oder interpretiere ich mal wieder Böswilligkeit hinein? Da Prob ist, dass ich von API, Renderpfaden, 3d- Programmierung null Ahnung hab....

Wenn es aber im Tenor so ist, dann ist NV für mich erledigt....

Sowas wie eine "reine API" gibt es bei OpenGL sowieso nur im begrennztem Umfang. Jeder Hersteller darf eigene Extensions einbringen. Einigen sich mehrer Hersteller auf eine gemeinsame Extension wird diese dann oft zur ARB Extension. Sowohl NVIDIA wie auch ATI unterstützen besagte Extension für "Fragment Programme". Wenn nun JC damit die gleiche Extension wie ich meint wie ich handelt es sich dabei um die ATI Extension für Fragmentprogramme von der NVIDIA der Meinung war das sie das auch können und sie deshalb zur ARB Extension wurde. Da der NV30 Chip aber wesentlich mehr kann als diese Extension abdeckt hat NVIDIA noch eine zusätzliche eigene Extension entwickelt. Wenn ich JC nun richtig verstanden habe ist die ARB Extension zwar im Treiber enthalten aber laut NVIDIA noch nicht optimiert. Zum Beispiel wird immer mit den vollen FP32 gerechnet obwohl das gar nicht notwendig wäre.

Unregistered
2003-01-30, 14:22:55
das mit den bits ist doch keine neuigkeit! nvidia unterstützt 16 u 32 bit ati nur 24bit. ich sehe hier ganz klar den vorteil für nvidia: bei spielen 16bit ->höhere geschwindigkeit mit min. schlechterer qualität. 32bit -> ofline rendern: vorteil: höhere genauigkeit geschwindikeit schlechter, jedoch egal (da ofline).
ati ist irgendwo zwischen drinnen-> für offline rendern zu ungenau, für spiele zu langsam. (überspitzt dargestellt)

nggalai
2003-01-30, 14:28:04
Hi Piffan,
Originally posted by Piffan
Um das noch mal genauer auszuführen: Hält sich JC strikt an die Api, dann ist die Radeon doppelt so fix bei ARB2. Um die NV schneller zu machen als die Radeon, muß er für die NV30 eine Extrawurst braten....Nochmals: das stimmt so nicht, da sich bei ARB2 bei den beiden Grafikkarten die Rendergenauigkeit beträchtlich unterscheidet. Ob der Unterschied sichtbar ist sei mal dahingestellt (wie schon gesagt, die meisten Offline-Rendersachen werden mit fp16 gerendert), aber dass eine Karte mit fp32 langsamer als eine mit fp24 ist sollte eigentlich naheliegend sein. Wenn NV wie versprochen noch den ARB-Teil speed-optimiert, sollte das Verhältnis wie vorhergesehen sein. Momentan scheint fp24 bei der ATI in etwa geleichflott zu sein wie fp16 bei NV.

ta,
-Sascha.rb

Demirug
2003-01-30, 14:28:30
Originally posted by BlackBirdSR
sieht man den Unterschied 16FP 24FP?
hat ATi eigene Extensions zu OpenGL die Carmack benutzen könnte?

also was soll er groß einen eigenen R300 Pfad schreiben, obwohl sie bei ARB und R200 schon sehr schnell läuft?

Nach allem was ich weiss ist die ARB Extension identisch mit der Extension welche ATI für den R300 benutzten wollte. Deswegen kein eigener R300 Pfad.

Ob man nun die Unterschiede zwischen FP16, FP24 und FP32 sieht? Eher nicht. Das erste Problem ist das egal wie Intern gerechnet wird für den Framebuffer sowieso auf 8 bit per Color runterskaliert werden muss. Und das addieren der Lichtquellen läuft nur mit der Framebuffergenauigkeit ab.

Der zweite Punkt ist mal wieder das Gesetzt des geringer werdenden Ertrags.

IMO wird man daher einen unterschied höchstens auf Screenshots erkennen können in der Bewegung nicht.

Hauwech
2003-01-30, 14:33:12
Eine zentrale Aussage ist imho das man von der NV30 in Sachen Performance noch so einiges erwarten kann. Bedeutet viel Arbeit aber kann sich fuer Nvidia nur lohnen. Ehrlich gesagt glaube ich nicht das JC so eine Aussage machen wuerde wenn er auch nicht dran glaubt. Ich halte ihn fuer so gut das er merken wurde wenn Nvidia ihn mit solchen Versprechungen 'lot of room for improvement' nur verarscht.

BlackBirdSR
2003-01-30, 14:38:34
Originally posted by Demirug


Nach allem was ich weiss ist die ARB Extension identisch mit der Extension welche ATI für den R300 benutzten wollte. Deswegen kein eigener R300 Pfad.

Ob man nun die Unterschiede zwischen FP16, FP24 und FP32 sieht? Eher nicht. Das erste Problem ist das egal wie Intern gerechnet wird für den Framebuffer sowieso auf 8 bit per Color runterskaliert werden muss. Und das addieren der Lichtquellen läuft nur mit der Framebuffergenauigkeit ab.

Der zweite Punkt ist mal wieder das Gesetzt des geringer werdenden Ertrags.

IMO wird man daher einen unterschied höchstens auf Screenshots erkennen können in der Bewegung nicht.

danke, aber das waren eher rethorische fragen... um den vorigen Poster zum Nachdenken anzuregen,
also kein Bedürfnis zu antworten, aber trotzdem danke :)

zeckensack
2003-01-30, 15:01:13
Originally posted by Piffan
edit: Jau, habe das mit den 128bit eben auch gelesen. Wenn der Output durch die Extra- Wurst tatsächlich schöner wird, dann sähe es vielleicht anders aus.... Also würde man die bessere Bildqualität nur sehen, wenn man die volle Präzision auch ausnutzt. Aber muß da tatsächlich ein eigener Pfad geschrieben werden, kann der Treiber nicht als Wrapper fungieren.... Denn sonst werden doch wohl die wenigsten Spiele die NV30 voll unterstützen... Es ist anders rum: Die Extrawurst (=NV30-Pfad) arbeitet mit geringerer Präzision.

zeckensack
2003-01-30, 15:04:26
Originally posted by BlackBirdSR
sieht man den Unterschied 16FP 24FP?
hat ATi eigene Extensions zu OpenGL die Carmack benutzen könnte?

also was soll er groß einen eigenen R300 Pfad schreiben, obwohl sie bei ARB und R200 schon sehr schnell läuft? ATI hat auf ARB_fragment_program standardisiert. Eine spezifische Extension gibt's nur für den R200 (der ARB_fragment_program auch nicht unterstützen kann).

zeckensack
2003-01-30, 15:07:58
Originally posted by Unregistered
das mit den bits ist doch keine neuigkeit! nvidia unterstützt 16 u 32 bit ati nur 24bit. ich sehe hier ganz klar den vorteil für nvidia: bei spielen 16bit ->höhere geschwindigkeit mit min. schlechterer qualität. 32bit -> ofline rendern: vorteil: höhere genauigkeit geschwindikeit schlechter, jedoch egal (da ofline).
ati ist irgendwo zwischen drinnen-> für offline rendern zu ungenau, für spiele zu langsam. (überspitzt dargestellt) Unsinn. Jedenfalls auf der Basis der in diesem Thread vorhandenen Informationen ...

FP16 auf NV30 ist beim derzeitigen Stand eben nicht schneller als FP24 auf ATI. Die nehmen sich speed-mäßtig nichts.

Unregistered
2003-01-30, 15:09:12
Originally posted by zeckensack
Unsinn. Jedenfalls auf der Basis der in diesem Thread vorhandenen Informationen ...

FP16 auf NV30 ist beim derzeitigen Stand eben nicht schneller als FP24 auf ATI. Die nehmen sich speed-mäßtig nichts.

bis jetzt

SamLombardo
2003-01-30, 16:51:15
@Demirug und aths:
Danke für eure Antworten

mfG Sam

Piffan
2003-01-30, 17:31:40
Jetzt habe ich es vielleicht auch geschnallt. Also noch mal meine Dummy- Zusammenfassung: Der NV30 hat eine höhere Kapazität bei der Präzision, die kostet im direkten Vergleich mit der R300 unter ARB2 eine Menge Speed derzeit. Will man dies verhindern, dann muß man die speziellen, noch weiter gefassten Extensions von NV anwenden (Extrawurst). Oder falls man doch nur nach ARB2 arbeitet, dann muß NV sehen, diese Version auf Speed zu optimieren, also die hohe Präzision nur da zu nutzen, wo es Not tut bzw. sichtbare Vorteile schafft...

Ergo gäbe es zwei Wege: Der Treiber ist intelligenter als bisher oder man muß eben die Extrawurst braten...;)

Vielen Dank für die geduldigen Belehrungen, nun weiß ich, dass der OpenGL- Standard relativ offen ist und darum nicht so richtig mit D3D- zu vergleichen; es also gar nicht die "reine" API gibt....Scheint also mehr so ein "Genossenschaftlicher" Zusammenschluss zu sein....

HOT
2003-01-30, 17:43:16
Er schrieb jedenfalls, das der R300 bei einem "Apple to Apple" Vergleich mit ARB2 Extensions doppelt so schnell arbeitet wie der NV30. Der optimierte Modus ist eine Art Kompromisslösung, da hier nicht immer mit voller Präision gerendert wird. Der NV30 bricht erheblich ein, wenn die volle Präzision genutzt wird...

Salvee
2003-01-30, 17:44:08
Originally posted by Unregistered
das ist aber aus nem alten interview genau wie der grösste teil des oberen posts von dir

Wie meinen ?

VoodooJack
2003-01-30, 17:44:34
Ich möchte mich bei JC bedanken für diese Klarstellung. Jetzt weiß ich endlich, welchen Path ich wählen werde.

9700Pro bzw. 9900Pro -> ARB2-Path

Zum einen dürften durchgängig 24bit-FP Genauigkeit eine gute Bildqualität garantieren. Speedmäßig brauche ich mir auch keine Gedanken mehr zu machen. Die 9700Pro ist im ARB2-Path doppelt so schnell wie die GeforceFX. Und die ist immerhin das Maß aller Dinge.

Quasar
2003-01-30, 17:49:13
Eine seltsame Begründung für deine Schlussfolgerung, IMO.

Quasar
2003-01-30, 17:51:34
Originally posted by zeckensack
Unsinn. Jedenfalls auf der Basis der in diesem Thread vorhandenen Informationen ...

FP16 auf NV30 ist beim derzeitigen Stand eben nicht schneller als FP24 auf ATI. Die nehmen sich speed-mäßtig nichts.

??
Ich hab JC so verstanden, dass nV30 auf dem nV30-Pfad schneller ist, als R300 auf sowohl dem R200 als auch auf dem ARB2-Pfad. Wenn nV30 gleichzeitig langsamer als ATi auf dem ARB2-Pfad aufgrund der vollen 32Bit Präzision ist, müsste daraus doch folgen, dass es dem nV30 nur mit dem nV30-Pfad möglich ist, seine 16Bit-Option zu nutzen, die dann schneller als ATis ARB2-Option ist.

Wo liegt mein Denkfehler?

nggalai
2003-01-30, 17:57:34
Hi Quasar,
Originally posted by Quasar
Wo liegt mein Denkfehler? Der NV30-Pfad könnte auch Integer sein, und der ARB2-Pfad bei der GFFX wie von Humus vermutet mit fp16 laufen (lässt sich unter OpenGL offenbar äusserst einfach festsetzen, auch wenn fp32 bei der GFFX default wäre).

ta,
-Sascha.rb

Quasar
2003-01-30, 17:59:59
Thx Sascha,
edit: "könnte..."

Dann lass ich mich mal von der öffentlichen und legalen BETA überraschen. ;)

BlackBirdSR
2003-01-30, 18:00:16
Originally posted by nggalai
Hi Quasar,
Der NV30-Pfad könnte auch Integer sein, und der ARB2-Pfad bei der GFFX wie von Humus vermutet mit fp16 laufen (lässt sich unter OpenGL offenbar äusserst einfach festsetzen, auch wenn fp32 bei der GFFX default wäre).

ta,
-Sascha.rb

ist das nicht suboptimal dann?
allerdings macht es in dieser Weise etwas mehr Sinn wenn man 16FP oder 32FP im ARB2 Pfad einfach festlegen kann.
Wir werden sehen..

Demirug
2003-01-30, 18:06:27
Originally posted by Quasar


??
Ich hab JC so verstanden, dass nV30 auf dem nV30-Pfad schneller ist, als R300 auf sowohl dem R200 als auch auf dem ARB2-Pfad. Wenn nV30 gleichzeitig langsamer als ATi auf dem ARB2-Pfad aufgrund der vollen 32Bit Präzision ist, müsste daraus doch folgen, dass es dem nV30 nur mit dem nV30-Pfad möglich ist, seine 16Bit-Option zu nutzen, die dann schneller als ATis ARB2-Option ist.

Wo liegt mein Denkfehler?

Quasar, kein Denkfehler.

Die NV30 Extension erlaubt mixed Calculationen. Man kann FP16, FP32 und Integer innerhalb eines Shader beliebig mischen.

Die ARB Extension kennt einfach nur FP ohne die Angabe einer Genauigkeit. In den aktuellen Treibern hat NVIDIA diese Extension für FP32 ausgelegt. Nun gibt es bei dieser Extension aber noch die Möglichkeit den Treiber zu sagen ob man es schön oder schnell haben möchte. Diese Funktionen sind aber lediglich hinweisse und müssen deshalb auch nichts tun (bei ATI könnte sie ja auch nichts tun). NVIDIA hat also für diese Extension bisher scheinbar nur das nötigste programmiert und deshalb auch noch viel Luft nach oben.

zeckensack
2003-01-30, 18:06:40
Originally posted by Quasar


??
Ich hab JC so verstanden, dass nV30 auf dem nV30-Pfad schneller ist, als R300 auf sowohl dem R200 als auch auf dem ARB2-Pfad. Wenn nV30 gleichzeitig langsamer als ATi auf dem ARB2-Pfad aufgrund der vollen 32Bit Präzision ist, müsste daraus doch folgen, dass es dem nV30 nur mit dem nV30-Pfad möglich ist, seine 16Bit-Option zu nutzen, die dann schneller als ATis ARB2-Option ist.

Wo liegt mein Denkfehler? Kein Denkfehler ;)

Ich habe das was John schrieb nur etwas konservativer ausgelegt, nämlich so daß NV30 (auf'm NV30-Pfad) und R300 (auf R200- oder ARB2-Pfad) ungefähr gleich schnell sind.

At the moment, the NV30 is slightly faster on most scenes in Doom than the R300, but I can still find some scenes where the R300 pulls a little bit ahead.
Emphasis mine.

Demirug
2003-01-30, 18:30:50
Originally posted by nggalai
Hi Quasar,
Der NV30-Pfad könnte auch Integer sein, und der ARB2-Pfad bei der GFFX wie von Humus vermutet mit fp16 laufen (lässt sich unter OpenGL offenbar äusserst einfach festsetzen, auch wenn fp32 bei der GFFX default wäre).

ta,
-Sascha.rb

Ich weiss jetzt nicht wie Humus zu dieser Schlussfolgerung kommt (zu faul den Thread zu suchen) aber ich kann es nicht so ganz nachvollziehen. Um die Shader beim NV30 in einem Pass laufen zu lassen muss man auf die neue Extension für Fragmentprogramme zurückgreifen. Dort sind aber alle Register mindestens FP16. Man kann zwar für viele Berechnungen Int12 erzwingen aber dafür müssen jeweils die Eingangs und Ausgangswerte von FP auf Integer und zurück gewandelt werden. ob das nun schneller ist als direkt mit FB16 zu rechnen mag ich bezweifeln.

Zudem passt die Aussage das der ARB2 Pfad nur etwa halb so schnell wie der NV30 Pfad ist gut zu der Aussage das FP16 doppelt so schnell wie FP32 ist.

nggalai
2003-01-31, 08:40:15
HI Demiurg,

ich seh's gleich wie Du; hauptsächlich wenn man die Geschwindigkeitsunterschiede vergleicht ist's naheliegen, dass ARB2 mit fp32 und der NV30 Pfad mit fp16 läuft. Ich hab' das nur der Vollständigkeit halber erwähnt. ;)

Hier Humus's Posting auf B3D:From the GL_ARB_fragment_program spec:

quote

(22) Should we provide applications with a method to control the
level of precision used to carry out fragment program computations?

RESOLVED: Yes. The GL implementation ultimately has control over
the level of precision used for fragment program computations.
However, the "ARB_precision_hint_fastest" and
"ARB_precision_hint_nicest" program options allow applications to
guide the GL implementation in its precision selection. The
"fastest" option encourages the GL to minimize execution time,
with possibly reduced precision. The "nicest" option encourages
the GL to maximize precision, with possibly increased execution
time.

If the precision hint is not "fastest", GL implementations should
perform low-precision operations only if they could not
appreciably affect the final results of the program. Regardless
of the precision hint, GL implementations are discouraged from
reducing the precision of computations so aggressively that final
rendering results could be seriously compromised due to overflow
of intermediate values or insufficient number of mantissa bits.

Some implementations may provide only a single level of precision,
in which case these hints may have no effect. However, all
implementations will accept these options, even if they are
silently ignored.

More explicit control of precision, such as provided in "C" with
data types such as "short", "int", "float", "double", may also be
a desirable feature, but this level of detail is left to a
separate extension.

unquote

So the ARB path can hint which precision it want and I can almost garantuee that using ARB_precision_hint_fastest will use FP16 on the GFFX.i.e. Humus's Ansatz ist, dass es von Carmack ziemlich bescheuert wäre, beim ARB2-Pfad auf der NV30 fp32 zu verwenden, wenn's a) so lahm ist, b) wohl nicht viel besser als fp16 aussieht und c) sich einfach umstellen lässt.

ta,
-Sascha.rb

nggalai
2003-01-31, 08:45:10
Nachtrag:

ich denke, Humus hat da was überlesen, oder wollte gar kein Statement zum Thema abgeben (i.e. welches fp-Format verwendet der ARB2-Pfad auf NV30), sondern allgemeine Informationen. Weil, ich meine nur:

John Carmack thus speaketh
To make it even more complicated, the exact precision that ATI uses is in between the floating point precisions offered by Nvidia, so when Nvidia runs fragment programs, they are at a higher precision than ATI's, which is some justification for the slower speed.ATI verwendet fp24, i.e. "in between the floating point precision offered by Nvidia" (fp16 / fp32), und wenn Carmack dann sagt, dass die fragment shader auf der NV30 mit "higher precision" laufen, bleibt nur fp32 für den ARB2-Pfad auf der NV30.

ta,
-Sascha.rb

Demirug
2003-01-31, 08:49:29
Some implementations may provide only a single level of precision,
in which case these hints may have no effect. However, all
implementations will accept these options, even if they are
silently ignored.


Wenn ich JC richtig verstanden haben greift genau dieser Absatz. NVIDIA hat bisher nur reines fp32 implementiert.

nggalai
2003-01-31, 09:23:18
Originally posted by Demirug


Wenn ich JC richtig verstanden haben greift genau dieser Absatz. NVIDIA hat bisher nur reines fp32 implementiert. Ja, sehe ich auch so.

ich habe mir sagen lassen, dass ARB_precision_hint_fastest "global" funktioniere, und nicht getrennt z.B. pro Shader gesetzt werden kann. Vielleicht will JC unterschiedliche Genauigkeiten pro Szenario fahren können?

Hmm. Heisst das, dass der NV30-Pfad daher integer sein MUSS? ???

*kaffee-rauslass*

ta,
-Sascha.rb

tEd
2003-01-31, 10:18:45
Hmm. Heisst das, dass der NV30-Pfad daher integer sein MUSS? ???

*kaffee-rauslass*

ta,
-Sascha.rb [/SIZE]

das denke ich nicht. ich glaube es liegt einfach ander momentanen limitierten implementierung von der arb extension in den treibern.

ich denke das man sich zuerst auf die eigene extension konzetriert hat um da zuerst die ganze funktionalität bereit zustellen , so das die Cg Sachen auch funktionieren.

Demirug
2003-01-31, 10:39:09
Originally posted by nggalai
Ja, sehe ich auch so.

ich habe mir sagen lassen, dass ARB_precision_hint_fastest "global" funktioniere, und nicht getrennt z.B. pro Shader gesetzt werden kann. Vielleicht will JC unterschiedliche Genauigkeiten pro Szenario fahren können?

Hmm. Heisst das, dass der NV30-Pfad daher integer sein MUSS? ???

*kaffee-rauslass*

ta,
-Sascha.rb

Wenn ich die Spec richtig verstanden habe läst sich die Genauigkeit pro "Fragment Programm" vorgeben. Ein OpenGL Fragment Programm ist das gegenstück zu einem DX Pixelshader.

Wie schon weiter oben gesagt erfordert das 1 Pass für alles beim NV30 die benutzung von neuen Extension. Diese sind nun aber primär auf die benutzung von FP16 und FP32 ausgelegt. Eine Fixedpoint Genauigkeit kann zwar für bestimmte Berechnungen erzwungen werden aber die Register bleiben FP16 und FP32 deswegen sehe ich da im Moment auch nicht unbedingt eine Möglichkeit wie Fixedpoint schneller sein sollte.

Für die "alte" DX8 Funktionalität könnte man durchaus noch einen schnelleren Weg im Chip implementiert haben da es ja dort nicht so viele freiheiten gab aber bei den neuen Fragmentprogrammen wüsste ich jetzt spontan echt nicht wie das gehen sollte.

zeckensack
2003-01-31, 14:15:40
GL Hints sind normalerweise* global, ergo nicht an einzelne Shader/Texturen/sonstiges gebunden.

Es ist selbstverständlich legal, sie zwischendurch umzusetzen. Außerdem kann man sie mit anderen state changes (eben wieder shader, texturen, sonstiges) verkapseln, indem man display lists benutzt.

*ich habe die ARB_fp spec jetzt nicht durchgelesen und kann deswegen nicht 100%ig sagen, ob der ARB_fp_precision hint auch global ist. Schätzungsweise wird man hier aber keine Extrawurst gemacht haben, denn das würde Änderungen am Hint-System an sich nach sich ziehen.

Demirug
2003-01-31, 14:26:53
Originally posted by zeckensack
GL Hints sind normalerweise* global, ergo nicht an einzelne Shader/Texturen/sonstiges gebunden.

Es ist selbstverständlich legal, sie zwischendurch umzusetzen. Außerdem kann man sie mit anderen state changes (eben wieder shader, texturen, sonstiges) verkapseln, indem man display lists benutzt.

*ich habe die ARB_fp spec jetzt nicht durchgelesen und kann deswegen nicht 100%ig sagen, ob der ARB_fp_precision hint auch global ist. Schätzungsweise wird man hier aber keine Extrawurst gemacht haben, denn das würde Änderungen am Hint-System an sich nach sich ziehen.

In der Spec steht:

3.11.4.5.2 Precision Hint Options

Fragment program computations are carried out at an implementation-
dependent precision. However, some implementations may be able to
perform fragment program computations at more than one precision,
and may be able to trade off computation precision for performance.

If a fragment program specifies the "ARB_precision_hint_fastest"
program option, implementations should select precision to minimize
program execution time, with possibly reduced precision. If a
fragment program specifies the "ARB_precision_hint_nicest" program
option, implementations should maximize the precision, with possibly
increased execution time.

Only one precision control option may be specified by any given
fragment program. A fragment program that specifies both the
"ARB_precision_hint_fastest" and "ARB_precision_hint_nicest" program
options will fail to load.

Wie gesagt für mich liest sich das als ob man den Hint pro Fragment Programm ändern darf.

Unregistered
2003-02-01, 02:37:22
OpenGL is doch als "Statemachine" implementiert, sollte also IMHO keine Probleme bereiten nen glHint() Call abzusetzen, wenn man die Präzision ändern lassen möchte.
Blöde wird es nur, wenn er innerhalb eines Shaderprogrammes die Präzision wechseln will, das is' afaik net zulässig.

Unregistered
2003-02-01, 03:49:22
>>Blöde wird es nur, wenn er innerhalb
>>eines Shaderprogrammes die Präzision
>>wechseln will, das is' afaik net zulässig.

Bzw. nicht möglich und damit komplett abhängig von der OGL Implemenation.
Es steht in der Spezifikation drin, dass man es 'ner weiteren Extension überlassen wurde, 'C-like' (float, double, short, int) Datentypen zu definieren.

Unregistered
2003-02-01, 04:54:48
Ähm, nochmal 'ich', habe mir das mal durchgelesen und der 'precision hint' funktioniert gar nicht über glHint, sondern muss direkt zu Beginn des Shaders angegeben werden, als sogenannte Option.
Und Options sind, laut Grammatik, nur zu Beginn des Shaders erlaubt.

"!!ARBfp1.0
OPTION ARB_precision_hint_fastest;

#rest

END"

Bin mir aber net sicher, ob ARB_precision_hint_fastest komplett gross geschrieben werden muss.