Carmack on NV30 vs/ R300 and DooM-III rendering (technische Diskussion)

[nggalai]

Hola,

Die allgemeine Diskussion zu diesem .plan findet da statt:
http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=52112

In diesem Thread soll's um die technischen Sachen gehen, besonders den 2. Teil des .plans.

Link: http://www.gamefinger.com/plan.asp?userid=johnc&id=16151

Text:

***

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 justification 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.

-------------

Doom has dropped support for vendor-specific vertex programs
(NV_vertex_program and EXT_vertex_shader), in favor of using
ARB_vertex_program for all rendering paths. This has been a pleasant thing to
do, and both ATI and Nvidia supported the move. The standardization process
for ARB_vertex_program was pretty drawn out and arduous, but in the end, it is
a just-plain-better API than either of the vendor specific ones that it
replaced. I fretted for a while over whether I should leave in support for
the older APIs for broader driver compatibility, but the final decision was
that we are going to require a modern driver for the game to run in the
advanced modes. Older drivers can still fall back to either the ARB or NV10
paths.

The newly-ratified ARB_vertex_buffer_object extension will probably let me do
the same thing for NV_vertex_array_range and ATI_vertex_array_object.

Reasonable arguments can be made for and against the OpenGL or Direct-X style
of API evolution. With vendor extensions, you get immediate access to new
functionality, but then there is often a period of squabbling about exact
feature support from different vendors before an industry standard settles
down. With central planning, you can have "phasing problems" between
hardware and software releases, and there is a real danger of bad decisions
hampering the entire industry, but enforced commonality does make life easier
for developers. Trying to keep boneheaded-ideas-that-will-haunt-us-for-years
out of Direct-X is the primary reason I have been attending the Windows
Graphics Summit for the past three years, even though I still code for OpenGL.

The most significant functionality in the new crop of cards is the truly
flexible fragment programming, as exposed with ARB_fragment_program. Moving
from the "switches and dials" style of discrete functional graphics
programming to generally flexible programming with indirection and high
precision is what is going to enable the next major step in graphics engines.

It is going to require fairly deep, non-backwards-compatible modifications to
an engine to take real advantage of the new features, but working with
ARB_fragment_program is really a lot of fun, so I have added a few little
tweaks to the current codebase on the ARB2 path:

High dynamic color ranges are supported internally, rather than with
post-blending. This gives a few more bits of color precision in the final
image, but it isn't something that you really notice.

Per-pixel environment mapping, rather than per-vertex. This fixes a pet-peeve
of mine, which is large panes of environment mapped glass that aren't
tessellated enough, giving that awful warping-around-the-triangulation effect
as you move past them.

Light and view vectors normalized with math, rather than a cube map. On
future hardware this will likely be a performance improvement due to the
decrease in bandwidth, but current hardware has the computation and bandwidth
balanced such that it is pretty much a wash. What it does (in conjunction
with floating point math) give you is a perfectly smooth specular highlight,
instead of the pixelish blob that we get on older generations of cards.

There are some more things I am playing around with, that will probably remain
in the engine as novelties, but not supported features:

Per-pixel reflection vector calculations for specular, instead of an
interpolated half-angle. The only remaining effect that has any visual
dependency on the underlying geometry is the shape of the specular highlight.
Ideally, you want the same final image for a surface regardless of if it is
two giant triangles, or a mesh of 1024 triangles. This will not be true if
any calculation done at a vertex involves anything other than linear math
operations. The specular half-angle calculation involves normalizations, so
the interpolation across triangles on a surface will be dependent on exactly
where the vertexes are located. The most visible end result of this is that
on large, flat, shiny surfaces where you expect a clean highlight circle
moving across it, you wind up with a highlight that distorts into an L shape
around the triangulation line.

The extra instructions to implement this did have a noticeable performance
hit, and I was a little surprised to see that the highlights not only
stabilized in shape, but also sharpened up quite a bit, changing the scene
more than I expected. This probably isn't a good tradeoff today for a gamer,
but it is nice for any kind of high-fidelity rendering.

Renormalization of surface normal map samples makes significant quality
improvements in magnified textures, turning tight, blurred corners into shiny,
smooth pockets, but it introduces a huge amount of aliasing on minimized
textures. Blending between the cases is possible with fragment programs, but
the performance overhead does start piling up, and it may require stashing
some information in the normal map alpha channel that varies with mip level.
Doing good filtering of a specularly lit normal map texture is a fairly
interesting problem, with lots of subtle issues.

Bump mapped ambient lighting will give much better looking outdoor and
well-lit scenes. This only became possible with dependent texture reads, and
it requires new designer and tool-chain support to implement well, so it isn't
easy to test globally with the current Doom datasets, but isolated demos are
promising.

The future is in floating point framebuffers. One of the most noticeable
thing this will get you without fundamental algorithm changes is the ability
to use a correct display gamma ramp without destroying the dark color
precision. Unfortunately, using a floating point framebuffer on the current
generation of cards is pretty difficult, because no blending operations are
supported, and the primary thing we need to do is add light contributions
together in the framebuffer. The workaround is to copy the part of the
framebuffer you are going to reference to a texture, and have your fragment
program explicitly add that texture, instead of having the separate blend unit
do it. This is intrusive enough that I probably won't hack up the current
codebase, instead playing around on a forked version.

Floating point framebuffers and complex fragment shaders will also allow much
better volumetric effects, like volumetric illumination of fogged areas with
shadows and additive/subtractive eddy currents.

John Carmack

***

ta,
-Sascha.rb

[BlackBirdSR]

bei ARB2 läuft die R300 fast doppelt so schnell,
d.h die GF FX auf FP32 und die R300 auf FP24.

heisst das auch dass die FX in ihren eigenen SPeedpath auf fp16 läuft, und die R300 weiterhin auf FP24?

[2B-Maverick]

also sehe ich richtig, das:
a) NV30 mit dem NV30 code-path (non-floating point) ein bissl schneller als R300 ist
b) NV30 mit dem floating-point code-path nur HALB so schnell wie der R300 ist?

hmmm... das würde zumindest mit den DX9 Shader Tests auf Beyond3D übereinstimmen.

Ach ja: nach obigen Aussagen sollte man ja tatsächlich Unterschiede sehen können zwischen R200/NV30 und dem ARB2 path, oder?

Da hat NV noch viiieeeellll Arbeit vor sich.

[tEd]

[SIZE=1]Originally posted by 2B-Maverick
also sehe ich richtig, das:
a) NV30 mit dem NV30 code-path (non-floating point) ein bissl schneller als R300 ist

ich glaub im nv30 codepath läuft er vorallem mit 16bit FP

b) NV30 mit dem floating-point code-path nur HALB so schnell wie der R300 ist?
so wie es aussieht läuft der nv30 momentan mit der arb extension nur mit 32bit FP , ich weiss nicht wie das da definiert ist , zeckensack sollte das wissen

[Demirug]

NV30 mit NV30 Codepfad (wahrscheinlich fp16) ist doppelt so schnell wie NV30 mit ARB2 (fp32). Das entspricht ja genau dem was NVIDIA gesagt.

R300 mit R200 Pfad ist etwas schneller als R300 mit ARB2 Pfad. In beiden Fällen fp24.

NV30 mit NV30 Pfad ist schneller als R300 mit ARB2 oder R200 Pfad
NV30 mit ARB2 Pfad ist langsamer (erscheint JC halb so schnell) als R300 mit ARB2 Pfad.

Also:

NV30 (ARB2) < R300 (ARB2) < R300 (R200) < NV30 (NV30)

Der visuelle Unterschied liegt nicht zwischen ARB2 und R200/NV30 sondern zwischen Integer und FP Pfaden. Also auf der einen Seite ARB2 und NV30 und auf der anderen R200.

Und ja NVIDIA weiss wohl das sie noch eine Menge arbeit haben sonst würden sie nicht unbedingt von "lot of room" sprechen.

Was ich auch noch interessant finde ist das bei den fp Pfaden das normalisieren der Vektoren nicht mehr über Cubemaps sondern über das Fragmentprogramm erledigt wird. Das entlasstet die Bandbreite kostet dafür aber Fillrate(Shaderops). Dem NV30 dürfte das besser schmeken als dem R300. Beide profitieren aber von der besseren Qualität welche diese Entscheidung nach sich zieht.

[Exxtreme]

Also die Aussage finde ich etwas komisch:

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

Also das, was ich bis jetzt von der Qualität der NV30-Treiber gesehen habe mit den ganzen Grafikfehlern etc... also das stimmt mich nachdenklich.

P.S: Klingt irgendwie nach "Schadensbegrenzung".

[x-dragon]

Originally posted by Exxtreme
Also die Aussage finde ich etwas komisch:

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

Also das, was ich bis jetzt von der Qualität der NV30-Treiber gesehen habe mit den ganzen Grafikfehlern etc... also das stimmt mich nachdenklich. Ist für die Karte denn unbedingt der aktuellste Treiber erforderlich? Vielleicht nutzt er ja einen anderen als den neuen Beta-Treiber. Wobei natürlich die Frage ist wie es leistungsmäßig mit anderen, also älteren Treibern aussieht. Zumindest aktuelle DirectX-Unterstützung wird ja nicht benötigt.

[Salvee]

Originally posted by Demirug
R300 mit R200 Pfad ist etwas schneller als R300 mit ARB2 Pfad. In beiden Fällen fp24.


Originally posted by Demirug
Der visuelle Unterschied liegt nicht zwischen ARB2 und R200/NV30 sondern zwischen Integer und FP Pfaden. Also auf der einen Seite ARB2 und NV30 und auf der anderen R200.



Irgendwie beissen sich die beiden Aussagen. R200 ist Integer und nicht FP24, oder ? Deswegen auch die geringere Qualität.

'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.'

Edit: Oder weil R300 intern immer mit 24Bit FP rechnet?

[Unregistered]

Originally posted by Exxtreme
Also die Aussage finde ich etwas komisch:

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

Also das, was ich bis jetzt von der Qualität der NV30-Treiber gesehen habe mit den ganzen Grafikfehlern etc... also das stimmt mich nachdenklich.

P.S: Klingt irgendwie nach "Schadensbegrenzung".


Wenn ich sehe, welche Grafikfehler ATi Karten produzieren, dann ist ganz klar, warum Entwickler NV-Hardware bevorzugen. btw. welche fehler unter OPENGL sollen die GFFX Treiber denn produzieren??

[Demirug]

Originally posted by Salvee




Irgendwie beissen sich die beiden Aussagen. R200 ist Integer und nicht FP24, oder ? Deswegen auch die geringere Qualität.

'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.'

Mit NV30/R200 meinte ich Renderpfade nicht die Chips und ja der R200 pfad ist ein Integer Pfad. Deswegen ist das mit dem "In beiden Fällen fp24." auch nicht richtig. Mein Fehler :bonk:. Intern rechnet der R300 eigentlich schon mit fp24 kann die höhrer Genauigkeit aber aufgrund der Verwendung eines R200 Shaders nicht nutzen.

[Demirug]

Originally posted by Exxtreme
Also die Aussage finde ich etwas komisch:

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

Also das, was ich bis jetzt von der Qualität der NV30-Treiber gesehen habe mit den ganzen Grafikfehlern etc... also das stimmt mich nachdenklich.

P.S: Klingt irgendwie nach "Schadensbegrenzung".

Ich vermute mal stark das die OpenGL Treiber für die NV30 Extensions schon funktionieren weil NVIDIA sich immer erst mal um diesen Teil der Treiber bei einem neuen Chip kümmert damit die Launch-Demos auch laufen.

[Exxtreme]

Originally posted by Unregistered
Wenn ich sehe, welche Grafikfehler ATi Karten produzieren, dann ist ganz klar, warum Entwickler NV-Hardware bevorzugen. btw. welche fehler unter OPENGL sollen die GFFX Treiber denn produzieren??
Wo produzieren ATi-GraKas Grafikfehler unter OpenGL? Und welche meinst du denn? Rage-Serie, R100, RV100, R200, RV250, R300??

[Unregistered]

Originally posted by Exxtreme

Wo produzieren ATi-GraKas Grafikfehler unter OpenGL? Und welche meinst du denn? Rage-Serie, R100, RV100, R200, RV250, R300??


Wo ist da die Antwort auf meine Frage??
Welche Fehler zeigen die GFFX Treiber unter OGL?

Und was soll dies:
"Also das, was ich bis jetzt von der Qualität der NV30-Treiber gesehen habe mit den ganzen Grafikfehlern etc... also das stimmt mich nachdenklich. "

[Exxtreme]

Originally posted by Unregistered



Wo ist da die Antwort auf meine Frage??
Welche Fehler zeigen die GFFX Treiber unter OGL?
Wo habe ich behauptet, daß die OpenGL-Treiber Grafikfehler produzieren?


Originally posted by Unregistered
Und was soll dies:
"Also das, was ich bis jetzt von der Qualität der NV30-Treiber gesehen habe mit den ganzen Grafikfehlern etc... also das stimmt mich nachdenklich. "
http://www.hardocp.com/image.html?image=MTA0MzYyMDg1OTVjVVNkMzFISXhfNF8yMl9sLmpwZw==
http://www.hardocp.com/image.html?image=MTA0MzYyMDg1OTVjVVNkMzFISXhfNF8yM19sLmpwZw==
http://www.hardocp.com/image.html?image=MTA0MzYyMDg1OTVjVVNkMzFISXhfNF8yNF9sLmpwZw==


Und das war auch keine Antwort auf meine Frage. :)

[Unregistered]

Hi

Hmm ok das mit den Pfade ist mir klar.

Eines frage ich mich aber.
Kann der Endkunde eigentlich die Settings selbst wählen. ???
Es hängt dann davon ab welcher Pfad zum Zug kommt.
Wie löst JC dieses.
Fragt er die div. Graka ab und bei Low Qualität wäre Pfad eins mit 16FP
High Quality mit Pfad 2 und 24FP oder 32FP. ???
(Grob gesagt jetzt.)

Gruss Labberlippe

[Demirug]

Originally posted by Unregistered
Hi

Hmm ok das mit den Pfade ist mir klar.

Eines frage ich mich aber.
Kann der Endkunde eigentlich die Settings selbst wählen. ???
Es hängt dann davon ab welcher Pfad zum Zug kommt.
Wie löst JC dieses.
Fragt er die div. Graka ab und bei Low Qualität wäre Pfad eins mit 16FP
High Quality mit Pfad 2 und 24FP oder 32FP. ???
(Grob gesagt jetzt.)

Gruss Labberlippe

Zuerst wird einmal ermittelt welche Pfade überhaupt lauffähig sein. Das geht recht einfach über das Abfragen der benötigten Extensions. Bleiben nun bei dieser Abfrage mehrer Möglichlichkeiten übrig muss die Engine eine davon auswählen. Scheinbar gibt es dort ein Prioritätssystem welches bestimmten Pfaden den Vorzug vor anderen gibt. In der A**** konnte man über die Config diese Entscheidung beeinflussen. Ob diese wahl jetzt aber noch irgendwie mit den Qualität settings verbunden ist/wird kann ich aber nicht sagen.

[Unregistered]

Originally posted by Demirug


Zuerst wird einmal ermittelt welche Pfade überhaupt lauffähig sein. Das geht recht einfach über das Abfragen der benötigten Extensions. Bleiben nun bei dieser Abfrage mehrer Möglichlichkeiten übrig muss die Engine eine davon auswählen. Scheinbar gibt es dort ein Prioritätssystem welches bestimmten Pfaden den Vorzug vor anderen gibt. In der A**** konnte man über die Config diese Entscheidung beeinflussen. Ob diese wahl jetzt aber noch irgendwie mit den Qualität settings verbunden ist/wird kann ich aber nicht sagen.

Hmmm
Kurz gesagt, wenn J.C mit der Performance nicht zufrieden ist, nimmt er einen anderen Pfad und die Sache hätte sich oder die Engine.
Allerdings kann dann gut möglich sein das dafür die BQ leicht "schlechter" ist.
Auf der anderen Seite ist das aber gar nichtmal so übel.
Wenn die Engine einen kurzen Check durchführt und merkt das die Performance nicht ausreicht, dann einfach umswitchen.
Wenn dann ein Nachfolger Chip die benötigt Performance hat, schaltet die Engine auf den besseren Pfad um. :D


Bin gespannt wie er das lösen will.

Gruss Labberlippe

[Labberlippe]

Originally posted by Unregistered


Hmmm
Kurz gesagt, wenn J.C mit der Performance nicht zufrieden ist, nimmt er einen anderen Pfad und die Sache hätte sich erledigt.
Allerdings kann dann gut möglich sein das dafür die BQ leicht "schlechter" ist.
Auf der anderen Seite ist das aber gar nichtmal so übel.
Wenn die Engine einen kurzen Check durchführt und merkt das die Performance nicht ausreicht, dann einfach umswitchen.
Wenn dann ein Nachfolger Chip die benötigt Performance hat, schaltet die Engine auf den besseren Pfade um. :D


Bin gespannt wie er das lösen will.

Gruss Labberlippe

Verdammt, ich muss mir merken das ich als Unreg nicht editieren kann.

Gruss Labberlippe

[BlackBirdSR]

hmm heisst das, die R300 kann zwar nur 24FP aber dafür mit voller geschw. während die FX zwar 32FP kann dafür aber hinter die R300 fällt und damit effektiv nur 16FP wirklich nutzen kann?

[2B-Maverick]

Frage an die champs:

Nutzt der default NV30 path denn nun floating point oder nur 12bit integers?
Dazu habe ich nirgendwo Infos gefunden.

[Demirug]

Originally posted by 2B-Maverick
Frage an die champs:

Nutzt der default NV30 path denn nun floating point oder nur 12bit integers?
Dazu habe ich nirgendwo Infos gefunden.

100% sicher sagen kann ich das auch nicht. Da es aber keinen Geschwidigkeitsunterschied zwischen Integer und fp16 geben soll und fp16 Vorteile hat würde ich mal davon ausgehen das fp16 benutzt wird.

[Unregistered]

Originally posted by Demirug


100% sicher sagen kann ich das auch nicht. Da es aber keinen Geschwidigkeitsunterschied zwischen Integer und fp16 geben soll und fp16 Vorteile hat würde ich mal davon ausgehen das fp16 benutzt wird.

ich dachte :

Fixel-Point > 16FP > 32FP

[2B-Maverick]

Originally posted by Unregistered


ich dachte :

Fixel-Point > 16FP > 32FP

das dachte / denke ich auch.
Wozu sonst sollte der NV30 drei verschieden Renderpfade in Hardware implementiert haben?

[Quasar]

Originally posted by Exxtreme

Wo produzieren ATi-GraKas Grafikfehler unter OpenGL? Und welche meinst du denn? Rage-Serie, R100, RV100, R200, RV250, R300??
Bei mir z.B. in QI-Tenebrae in der Entry-Hall und im ersten Level. Der Qualm vor dem "easy-skill" Raum und im ersten Raum des "richtigen" Levels sehen fies gerastert aus.

[Demirug]

Originally posted by 2B-Maverick


das dachte / denke ich auch.
Wozu sonst sollte der NV30 drei verschieden Renderpfade in Hardware implementiert haben?

Die Integergenauigkeit wird aus Gründen der Kompatibilität zu den alten Karten gebraucht. Ich kann die Aussage von einem NVIDIA Mitarbeiter das Integer nicht schneller als FP16 sei im Moment gerade nicht finden. Sobald sie mir wieder über den weg läuft poste ich das hier.

[2B-Maverick]

Originally posted by Demirug


Die Integergenauigkeit wird aus Gründen der Kompatibilität zu den alten Karten gebraucht. Ich kann die Aussage von einem NVIDIA Mitarbeiter das Integer nicht schneller als FP16 sei im Moment gerade nicht finden. Sobald sie mir wieder über den weg läuft poste ich das hier.

rgr.. warte gespannt... auch auf Benchmarks :)

[Demirug]

Ich habe die Information wiedergefunden. Das ganze war eine email und aufgrund des Datums ist die Aussage eher spekulativer Natur gewessen.

Die offizielle Information entspricht dem was 2B-Maverick und der Unreg gesagt haben.

fp16 doppelt so schnell wie fp32.

Spezial unterstützung für "älter" Apps mit Integer Shadern welche schneller als fp16 ist.

Es gibt allerdings keine Informationen darüber ob diese "Unterstützung" auch mit den neuen NV30 Extension benutzt werden kann oder lediglich für die <= NV25 Extension und DX 8 Shader zum Einsatz kommt.

[tb]

DX8 PS 1.0 - 1.4

ShaderMark v1.6a - DX8 1.0 - 1.4 Pixel Shader Benchmark - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768x32) (D24X8)
HAL (pure hw vp): NVIDIA GeForce FX 5800 Ultra

benchmark info
mip filter reflections: on


shaders:
PS 1.0 - Diffuse Bump Mapping
PS 1.0 - Diffuse Bump Mapping
82.38 fps

shaders:
PS 1.0 - Diffuse Bump Mapping
PS 1.4 - Bumped Diffuse Lighting with per pixel intensity falloff
54.57 fps


DX9 PS 1.0 - 1.4

ShaderMark v1.6a - DX9 1.1 - 1.4 Pixel Shader Benchmark - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): NVIDIA GeForce FX 5800 Ultra
benchmark info
mip filter reflections: DX9

shaders:

shaders:
PS 1.0 - Diffuse Bump Mapping
PS 1.0 - Diffuse Bump Mapping
219.40 fps

shaders:
PS 1.0 - Diffuse Bump Mapping
PS 1.4 - Bumped Diffuse Lighting with per pixel intensity falloff
91.64 fps


DX9 PS 2.0 Test

ShaderMark v1.6a - DX9 2.0 Pixel Shader Benchmark - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): NVIDIA GeForce FX 5800 Ultra
benchmark info
mip filter reflections: DX9

shaders:
shaders:
PS 2.0 - Diffuse Bump Mapping
PS 2.0 - Diffuse Bump Mapping
81.32 fps

shaders:
PS 2.0 - Diffuse Bump Mapping
PS 2.0 - Bumped Diffuse Lighting with per pixel intensity falloff
59.28 fps

------------------

ShaderMark v1.6 - DX9 2.0 Pixel Shader Benchmark - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 SERIES
benchmark info
DX9 mip filter reflections: on
mip filter reflections: on

shaders:

shaders:
PS 2.0 - Diffuse Bump Mapping
PS 2.0 - Diffuse Bump Mapping
207.10 fps

shaders:
PS 2.0 - Diffuse Bump Mapping
PS 2.0 - Bumped Diffuse Lighting with per pixel intensity falloff
193.67 fps



"...Spezial unterstützung für "älter" Apps mit Integer Shadern welche schneller als fp16 ist...."

Scheint irgendwie noch nicht in die Treiber gelangt zu sein.

Bisher sieht DX9 und 1.0'er Shader schon recht gut aus. DX8 PS 1.0-1.4 und DX9 PS 2.0 sind wohl noch recht unoptimiert. Hoffentlich bekommt NVIDIA den Einbruch bei den 1.4'er Shadern hin, die laufen ja mit höherer Genauigkeit als die 1.0'er und mit niedrigerer als die 2.0'er.

Thomas

[Demirug]

Originally posted by tb
"...Spezial unterstützung für "älter" Apps mit Integer Shadern welche schneller als fp16 ist...."

Scheint irgendwie noch nicht in die Treiber gelangt zu sein.

Bisher sieht DX9 und 1.0'er Shader schon recht gut aus. DX8 PS 1.0-1.4 und DX9 PS 2.0 sind wohl noch recht unoptimiert. Hoffentlich bekommt NVIDIA den Einbruch bei den 1.4'er Shadern hin, die laufen ja mit höherer Genauigkeit als die 1.0'er und mit niedrigerer als die 2.0'er.

Thomas

Also die aussage bezüglich der Speed kommen von Ballew: http://www.beyond3d.com/previews/nvidia/nv30launch/index.php?p=2

Nur um sicher zu gehen:

Das einzige was sich beim den Benchmark zwischen der DX8 und der DX9 Version ändert ist die DX-Runtime die 1.0 shader sind genau die gleichen?

Zu dem 1.4 Shadern:

AFAIK ist dort keine Genauigkeit vorgeschrieben. Ein Chip muss nur Durchgängig für alle 1.x Shader die er unterstützt die gleiche Genauigkeit haben und diese über dden Caps-Wert "PixelShader1xMaxValue" melden.

Das es dort noch probleme gibt erklärt auch das verhältnissmässig schlechte abschneiden beim Advanced Shader Test des 3dmarks.

[tb]

Originally posted by Demirug


Nur um sicher zu gehen:

Das einzige was sich beim den Benchmark zwischen der DX8 und der DX9 Version ändert ist die DX-Runtime die 1.0 shader sind genau die gleichen?


yeph.

[Gerhard]

Mir ist aufgefallen, JC spricht beim NV30 von 3 unterschiedlichen Genauigkeiten mit jeweils unterschiedlicher Geschwindigkeit.
Damit sagt er doch eigentlich auch indirekt das 16bit FP langsamer ist. (damit fügt sich dies auch bestens ins Bild ein)

[Unregistered]

FP32 ist ungenauer als FP16, so habe ich das aufgefasst. ?

Wenn das so ist, dann kann die FX nur punkent wenn der FP16 Pfad verwendet wird.
Also hätte hier die R300 die Nase vorn.

Gruss Labberlippe

[Demirug]

Originally posted by Unregistered
FP32 ist ungenauer als FP16, so habe ich das aufgefasst. ?

Wenn das so ist, dann kann die FX nur punkent wenn der FP16 Pfad verwendet wird.
Also hätte hier die R300 die Nase vorn.

Gruss Labberlippe

FP32 ist genauer als FP16 dafür aber auch nur halb so schnell. Da Pixar aber auch nur FP16 benutzt gehe ich mal davon aus das FP16 durchaus ausreicht.

[BlackBirdSR]

Originally posted by Demirug


FP32 ist genauer als FP16 dafür aber auch nur halb so schnell. Da Pixar aber auch nur FP16 benutzt gehe ich mal davon aus das FP16 durchaus ausreicht.

wie bekommt ATI die FP24 hin ohne allzuviel an Geschw. zu verlieren?

[Demirug]

Originally posted by BlackBirdSR


wie bekommt ATI die FP24 hin ohne allzuviel an Geschw. zu verlieren?

ATI hat ja nur FP24. So wie so nun im Moment aussieht hat der R300 die gleiche Anzahl von FP24 ALUs wie der NV30 FP16 ALUs (welche er aber nicht wirklich hat). Zudem glaube ich das diese FP24 ALUs auch für die "alten" PS 1.x zuständig sind. Aus diesem Grund kann der Unterschied zwischen Integer und FP dort auch nicht so dramatisch sein.

Die NVIDIA ALUs sind ja wie gesagt primär FP32 ALUs welche aber auch zwei FP16 Ops in der gleichen Zeit ausführen können. Das wurde ja mehr oder minder von JC bestätigt. Zudem gibt es scheinbar noch irgendeinen Trick um FixedPoint Operationen schneller laufen zu lassen. Ob das jetzt nur einen Treibersache ist und ob es nur mit bestimmten Pixelshader versionen läuft kann ich jetzt aber nicht sagen.

[Unregistered]

Originally posted by Demirug


FP32 ist genauer als FP16 dafür aber auch nur halb so schnell. Da Pixar aber auch nur FP16 benutzt gehe ich mal davon aus das FP16 durchaus ausreicht.

Eben.

@Leonidas
In Deiner News steht das der NV30 einen eigenen Pfad bekommt.
Allerdings sollte man darauf hinweisen das dieser nur mit FP16 (sowie es momentan aussieht) angesprochen wird.
Kurz der FX ist zwar schneller aber "ungenauer"

Gruss Labberlippe

[Unregistered]

Originally posted by Demirug


ATI hat ja nur FP24. So wie so nun im Moment aussieht hat der R300 die gleiche Anzahl von FP24 ALUs wie der NV30 FP16 ALUs (welche er aber nicht wirklich hat). Zudem glaube ich das diese FP24 ALUs auch für die "alten" PS 1.x zuständig sind. Aus diesem Grund kann der Unterschied zwischen Integer und FP dort auch nicht so dramatisch sein.

Die NVIDIA ALUs sind ja wie gesagt primär FP32 ALUs welche aber auch zwei FP16 Ops in der gleichen Zeit ausführen können. Das wurde ja mehr oder minder von JC bestätigt. Zudem gibt es scheinbar noch irgendeinen Trick um FixedPoint Operationen schneller laufen zu lassen. Ob das jetzt nur einen Treibersache ist und ob es nur mit bestimmten Pixelshader versionen läuft kann ich jetzt aber nicht sagen.

Bei ATi is 24FP anscheinend für alles zuständig ( FixedPoint + 16FP + 24FP ). Nvidia hätte bestimmt sehr viel Geld für das Design gezahlt, da sie dann den NV30 einfacher und effizienter designt hätten (nämlich ohne RegisterCombiners). Bei ATi zahlt es sich hier wahrscheinlich aus, das die die alte Cromatic-Crew, die vor 4-5 Jahren schon Multimediachips gebaut hat, aufgekauft haben.

Beim NV30 sind die alten RegisterCombiners für FixedPoint zuständig (deshalb ist der ShaderMark hier auch so schnell) und hier ist dann auch die GFFx immer etwas schneller als die R300(?). Deshalb denke ich, das der DIII-NV30-Pfad auch ein normaler Fixed-Point Pfad ist.

Die FP16 und FP32 laufen ja über die gleichen Shader, aber FP32 nur mit halber Geschwindigkeit. Wenn man sich die Shadermarks hier anschaut, dann sieht man IMHO das die GFFx um einiges langsamer ist, als die R300. Auch bei FP16 sollte die GFFx mit den jetzigen Treibern immer noch etwas langsamer sein, als die R300 und auch deshalb denke ich das der NV30-Pfad "nur" Fixed-Point ist

[[LOG]Skar]

wobei rein aus den aussagen von Carmack hätte ich so verstanden, dass der NV30
Pfad ein Mischmasch Pfad ist aus allem, ev nach außen Fixed Point und die
"internen" Shaderprogs mit Floating Point?

[Demirug]

ATI hat kein FP16. Dort gibt es nur FixedPoint und FP24.

Ob die RegisterCombiners wirklich noch verbaut sind ist ja nach wie vor nicht 100% sicher. Aber das müsste sich leicht testen lassen.

Laut den Aussagen von NVIDIA laufen alle FP Operationen über die gleiche Einheit ab.

Sollten aber nun die alten RegisterCombiners wirklich noch verbaut sein dann läuft der NV30 Pfad auf jeden Fall über die FP Einheiten weil es mit den RegisterCombiners gar nicht möglich ist eine DOOM III Lichtquellenpass mit nur einem Pass zu rendern.

Shadermark ist DX. DOOM III ist OpenGL. Deshalb kann man da nicht unbedingt direkte Schlussfolgerungen ziehen.

[Unregistered]

@demirug

Warum heisst das jetzt "FixedPoint". Klingt Integer zu gewöhnlich? Oder kommt das jetzt so von JC?

[Demirug]

Originally posted by Unregistered
@demirug

Warum heisst das jetzt "FixedPoint". Klingt Integer zu gewöhnlich? Oder kommt das jetzt so von JC?

Man kann auch Integer sagen. Das man jetzt FixedPoint benutzt kommt daher das es zum Beispiel bei den DX Shadern jetzt auch Integer Konstanten gibt. Zudem unterscheiden Shaderhochsprachen auch zwischen einem fixed und einem Integertyp. Im Endeffekt dient es nur zur bessere Unterscheidung.

[Unregistered]

Originally posted by Demirug
Sollten aber nun die alten RegisterCombiners wirklich noch verbaut sein dann läuft der NV30 Pfad auf jeden Fall über die FP Einheiten weil es mit den RegisterCombiners gar nicht möglich ist eine DOOM III Lichtquellenpass mit nur einem Pass zu rendern.


Thanks!

das erste Argument dafür, das der NV30-Pfad FP16 ist.

hätte ich aber auch schon früher merken können :


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.

[Unregistered]

Originally posted by Unregistered


Thanks!

das erste Argument dafür, das der NV30-Pfad FP16 ist.

hätte ich aber auch schon früher merken können :



Ich seh da aber keine schluessige Argumentation. Aber ausser JC wird uns das so schnell auch keiner sagen.

[Unregistered]

BTW, wen juckts? ATi rendert schon seit der Radeon1 mit einer höheren internen Praezision als Nvidia.

Jetzt ploetzlich wo auch nVidia das Augenmerk darauf richtet wird es interessant?!

[Quasar]

Nein.

[christoph]

also siehts doch im moment so aus als ob nv30 ca 50% absackt wenn mit floating point statt integer präzision gerendert wird. vieles deutet darauf hin das nv30 zwei seperate pipelines für fp bzw int verbaut hat während ati alles über die fp pipeline berechnet.

http://www.beyond3d.com/forum/viewtopic.php?t=4092&start=220

original posted von davebaumann

Its looking more and more likely that they have just wasted space on the inclusion of a specific int pipeline along the FP pipeline, whereas ATI just took the route of doing everything over the FP pipeline. I'd always doubted that Geoff Ballews responce to my question was actually saying what we thought it was, but its increasingly looking like it really is, and this seems to me to be incredibly wasteful. Someone in this thread (or another) praised ATI for doing everything over the FP pipeline and dumping the integer, but does this really merit praise? It just seems like plain old common sence to me, and nothing that hasn't been done before.

If its really the case that NV30 has two separate paths per pipeline then I'm starting to wonder about the rest of the NV3x chips as well.

[Ikon]

Originally posted by christoph
also siehts doch im moment so aus als ob nv30 ca 50% absackt wenn mit floating point statt integer präzision gerendert wird.

Nein, FP ist ja nicht gleich FP. FP32 gegenüber FP16 ist ca. 50% langsamer auf dem NV30, und FixedPoint ist offenbar (warum auch immer) nochmal geringfügig schneller als FP16.

[Salvee]

Originally posted by Unregistered


Ich seh da aber keine schluessige Argumentation. Aber ausser JC wird uns das so schnell auch keiner sagen.

Es geht darum, dass mit den alten Registercombiners kein Singlepass rendering möglich wäre. Also, da NV30 path singlepass ist, müssen entweder andere regcombiner als in gf4 vorhanden sein (irgendwie unwahrscheinlich), oder (eher wahrscheinlich) FP16 benutzt werden.
so hab ichs zumindest verstanden

[Razor]

Originally posted by Unregistered

@Leonidas
In Deiner News steht das der NV30 einen eigenen Pfad bekommt.
Allerdings sollte man darauf hinweisen das dieser nur mit FP16 (sowie es momentan aussieht) angesprochen wird.
Kurz der FX ist zwar schneller aber "ungenauer"

Gruss Labberlippe
Klasse LL,

kann es sein, dass Du da was falsch verstanden hast ?
Dann zeige mir doch bitte mal einen Unterschied von fp16 zu fp24 (oder fp32) !
Vor allem bitte in Games und am besten noch in Bewegung...
;D

Sorry, aber das finde ich einfach zu ulkig !
Wenn die R300 dadurch Leistung gewinnen würde, wenn sie auf fp16 herunter geschaltet wär, würde ATI das sofort machen. Ohne mit der Wimper zu zucken...

Allerdings hat ATI hier keine unterschiedlichen Pfade implementiert und kann nur fp24 (weil Mindestanforderung von DX9). Insofern würde es auf einer R300 einfach keinen Vorteil bringen...

Auf einem NV30 hingegen schon...
Und das Problem mit der default-seitigen fp32-Ausführung (sowohl DX9, als auch OGL2) wird nVidia sicherlich auch bald in den Griff bekommen. Vermutlich gibt's dann dafür eine (versteckte) Treiberoption, oder etwas ähnliches.

Bis denne

Razor

[aths]

Hm. ATI bietet eine Präzision zwischen 16 und 32 Bit, also 24 Bit, für 16-Bit-Geschwindigkeit. Gleiche Leistung, mehr Qualitätsreserve. Ist doch klasse, oder?

[Unregistered]

Originally posted by aths
Hm. ATI bietet eine Präzision zwischen 16 und 32 Bit, also 24 Bit, für 16-Bit-Geschwindigkeit. Gleiche Leistung, mehr Qualitätsreserve. Ist doch klasse, oder?

Razor hat da schon immer seine ganz eigene (leicht verklärte)Sichtweise.;D

[Pitchfork]

Btw. DirectX hat nie die Maximalgenauigkeit der Shader vorgeschrieben. Afaik ist es durchaus legal, auch alle PS1.0-1.4 Shader mit FP Genauigkeit zu rechnen. Was imho ATI auch macht. Die GFFX hat die alten Register Combiner mitgeschleppt und das erlaubt natürlich auch, die alten Shader mit der alten Präzision laufen zu lassen mit der gleichen Speed pro Takt wie GF4.

[Demirug]

Originally posted by Pitchfork
Btw. DirectX hat nie die Maximalgenauigkeit der Shader vorgeschrieben. Afaik ist es durchaus legal, auch alle PS1.0-1.4 Shader mit FP Genauigkeit zu rechnen. Was imho ATI auch macht. Die GFFX hat die alten Register Combiner mitgeschleppt und das erlaubt natürlich auch, die alten Shader mit der alten Präzision laufen zu lassen mit der gleichen Speed pro Takt wie GF4.

Ja die Maximalgenauigkeit ist der Hardware überlassen. Es gibt nur ein paar Forderungen:

Sie muss für alle 1.x Shader gleich sein.
Der grösstmögliche Wert muss über die Caps gemeldet werden.
Der in den Caps gemeldete Wert definiert die genauigkeit im positiven und negativen. Das heist: steht in den Caps 8 so liegt der zulässige Bereich von -8 bis +8. Bei der Ausgabe wird allerdings immer auf 0..1 begrennzt und dieser Wert auf die verfügbaren Bits im Framebuffer abgebildet.

[[LOG]Skar]

Kann man eigentlich mehrere Shaderprogramme pro Szene nutzen?
(Ohne Multi-Pass)
Und könnte man auf der GF FX größere Shader-Progs nutzen ohne, dass
sie langsamer wird?

Greetz

[Demirug]

Originally posted by [LOG]Skar
Kann man eigentlich mehrere Shaderprogramme pro Szene nutzen?
(Ohne Multi-Pass)

Ja, im Prinzip kann man so viele Shader benutzten wie man möchte. Wenn man den Shader aber zu oft wechselt ist das schlecht für die Performances.


Und könnte man auf der GF FX größere Shader-Progs nutzen ohne, dass
sie langsamer wird?

Greetz

Längere Shader sind zwangsläufig langsamer. Das gilt aber für alle Chips.

[Pitchfork]

Originally posted by Demirug


Ja die Maximalgenauigkeit ist der Hardware überlassen. Es gibt nur ein paar Forderungen:

Sie muss für alle 1.x Shader gleich sein.
Der grösstmögliche Wert muss über die Caps gemeldet werden.
Der in den Caps gemeldete Wert definiert die genauigkeit im positiven und negativen. Das heist: steht in den Caps 8 so liegt der zulässige Bereich von -8 bis +8. Bei der Ausgabe wird allerdings immer auf 0..1 begrennzt und dieser Wert auf die verfügbaren Bits im Framebuffer abgebildet.

Man muß zwischen dem Wertebereich und der Genauigkeit unterscheiden. In den Caps steht nur der Wertbereich, über die Genauigkeit steht nix. Und es würde mich auch wundern, wenn über die Genauigkeit nennenswerte Vorschriften gemacht werden (insbesondere ein Satz wie "muß für alle 1.x gleich sein" klingt seltsam).

Pitchfork

[Demirug]

Originally posted by Pitchfork


Man muß zwischen dem Wertebereich und der Genauigkeit unterscheiden. In den Caps steht nur der Wertbereich, über die Genauigkeit steht nix. Und es würde mich auch wundern, wenn über die Genauigkeit nennenswerte Vorschriften gemacht werden (insbesondere ein Satz wie "muß für alle 1.x gleich sein" klingt seltsam).

Pitchfork

Ja, natürlich nur als man das ganze definiert hat gab es ja nur Integerwerte. Deshalb ergab sich die Genauigkeit in gewisser Weisse ja aus dem Wertebereich. Und das es eben für alle Shader Versionen gleich sein muss (könnte auch nur ein soll gewesen sein) hängt damit zusammen das man die Shader ohne Probleme mischen kann.

[Pitchfork]

Aus dem Wertebereich muß sich die Genauigkeit nicht unbedingt ableiten, da ja nicht unbedingt die Genauigkeit bei 1/256 liegen muß. Im Gegenteil, die DX8 ATI Karten haben eine größere Genauigkeit als 1/256 im Gegensatz zur Geforce. Zusätzlich erlauben die ATI Karten den Wertebereich von -8 bis +8, während die Geforces nur von -1 bis +1 gehen.
Daß man Shader mischen kann, hat ja nix mit der Genauigkeit zu tun (ausser beim Z-Wert, und der wird immer gleich iteriert und nicht im Shader berechnet - bis auf Ausnahmen), sondern einfach damit, daß es nur eine Fragment Shading Unit im Chip gab, die von TSS über PS1.1-PS1.3 sowie PS1.4 alles berechnet hat. Und so macht es ja ATI immer noch, dh. sie werden die Genauigkeit der PS1.X Shader bestimmt nicht künstlich auf 11-14bit beschränkt haben, sondern die auch immer in FP24 berechnen. Nur NV hat drei verschiedene Genauigkeiten im Chip eingeführt - so denn die These stimmt, daß die alten Register Combiner tatsächlich in Hardware vorhanden sind und nicht auf die PS2.X Fragment Shader abgebildet werden....

Dürfte man leicht prüfen können: einfach nen schönen Specular Exponenten mit PS1.3 oder PS1.4 schreiben und auf verschiedener Hardware laufen lassen. Je nach Genauigkeit dürfte das Banding mehr oder weniger auffallen. Und wenn die GFFX genauso schöne Artefakte zeigt wie die GF4, so sieht man dann auch, ob die GFFX die alten Register Combiner noch hat.

[Demirug]

Ja du hast recht. Ich habe in dem Moment nicht daran gedacht das ATI ja nicht nur den Wertbereich erhöht hat.

Gleiche Genauigkeit bei allen Shadern macht durchaus Sinn. Aber nur in Multi-Pass Situationen wenn man nicht immer die gleichen Shaderversion für alle Passes benutzt. So etwas dürfte aber eher selten vorkommen.

ATI rechnet beim R300 auch bei den PS 1.x mit voller FP24 Genauigkeit. Als Range ist dort ein sehr grosser Wert angeben den man mit Integereinheiten nicht erreichen könnte. In diesem Zusammenhang wäre eine Liste mit den NV30 DX Caps mal Interesant. Aber die werden wir ja über kurz oder lang bekommen.

[Pitchfork]

Stimmt. Auf die Sache mit dem Range als Indikator für die Genauigkeit hätte ich auch kommen können.

[HOT]

Jedenfalls erklärt das die Architektur der Chips. Wenn der R300 Multipass macht BRAUCHT er das 256Bit Speicherinterface. Der NV30 BRÄUCHTE es nur bei FP32 ;)

[Demirug]

Originally posted by HOT
Jedenfalls erklärt das die Architektur der Chips. Wenn der R300 Multipass macht BRAUCHT er das 256Bit Speicherinterface. Der NV30 BRÄUCHTE es nur bei FP32 ;)

Ich kann dir bei deiner Überlegung nicht so ganz folgen. Die Interne Rechengenauigkeit hat doch nichts mit dem Speicherinterface zu tun.

Ob man die PS jetzt mit FP16 oder FP32 laufen lässt hat überhaupt keine Auswirkung auf die Bandbreite.

[HOT]

Das ist schon klar. Aber wenn eine Berechnung nicht in einem Pass erfolgt, dann geibts doch speicherugriffe oder?

[2B-Maverick]

tja.... wie ist das mit dem loop-back?
Braucht man da mehr Bandbreite? Oder nur mehr Takt-Zyklen?

[Demirug]

@Hot:
Ja beim Multipass braucht man auch Speicherbandbreite. Aber für DOOM III reichen die R300 Shadermöglichkeiten wohl aus. Wenn die Shader aber wirklich mal zu lang für den R300 werden hat der NV30 einen Vorteil.

@2B-Maverick:
Loop-Backs laufen vollkommen innerhalb das Chips ab (also keine Bandbreite). Deswegen hat man ja überhaupt erst mit dem Multitexturing in einem Pass angefangen. Ein weiterer Vorteil ist das man beim Loop-Back die Rechengenauigkeit der ALUs beibehalten kann und nicht auf die Genauigkeit des Framebuffers herunter gehen muss.

[christoph]

auf b3d sind neue infos aufgetaucht

http://www.beyond3d.com/forum/viewtopic.php?t=4190

The integer format from NV30 (called fx12) is a 12bit fixed point format
(sign + 1bit integer + 10bit fraction). This is an extended version of the legacy
mode supported by the register combiners (the register combiners used a 9bit S8 representation),
so I guess it will be used most of the time in current apps (fixed fragment pipeline,
register combiner mode/fragment combiner mode, and upto PS 1.3).

Only in 'modern' cases the floating point formats will be used: nvidia new OpenGL extensions,
PS 2.0, ARB_fragment_program.

I'm dubious on whether the fp16 is really x2 speed of the fp32, I think that the Doom3 NV30 codepath
uses this fx12 format, and the speed wins Carmack cites are not from using a fp16 vs. fp32. Methinks
that the fp16 format is there just for bandwidth saving purposes and to double the number of temporary registers.

For information on NV30 format & operation precision, see Section 3.11.4.1: Fragment Program Storage Precision and
Section 3.11.4.2: Fragment Program Operation Precision from NVIDIA OpenGL Extension Specification for CineFX

[Demirug]

Originally posted by christoph
auf b3d sind neue infos aufgetaucht

http://www.beyond3d.com/forum/viewtopic.php?t=4190



Die Überlegung bezüglich fp16 zu fp32 ist definitive falsch. Denn wie schon gesagt hat der Datentyp keinen Einfluss auf die benötigte Bandbreite. Und warum fp16 doppelt so schnell sein kann wie fp32 wurde ja schon mehrfach einleuchtend erklärt.

Um einen Singlepass Shader für DOOM III zu bauen wird zwangsläufig die NV30 Extension gebraucht. Dort gibt es besagten fx12 Datentyp aber eigentlich gar nicht. Es können lediglich einige Rechenoperationen mit fx12 Genauigkeit durchgeführt werden. Die Frage die allerdings nirgends benatwortet wird ist wie diese fx12 Berechnungen nun durchgeführt werden und wie schnell diese im verhältniss zu fp16 und fp32 in Context der NV30-Extension sind.

Irgendwie kommt man so nicht weiter ;)

[StefanV]

Hm, kanns sein, daß NV den 'Pfusch' mit 16bit FP und 32bit FP Formaten auch mit 16bit vs. 32bit Farbtiefe gemacht hat ??

[Demirug]

Originally posted by Stefan Payne
Hm, kanns sein, daß NV den 'Pfusch' mit 16bit FP und 32bit FP Formaten auch mit 16bit vs. 32bit Farbtiefe gemacht hat ??

Den Verdacht hatte ich auch schon Stefan. Wenn dann allerdings wohl nur bei den GF2 Chips. Bei der GF1 hätte das nicht wirklich sinn gemacht. Man müsste mal ein bischen mit Colorbanding rumspielen.

[tEd]

ein kleines interview zum plan file mit J.C hat beyond3d gemacht.

http://www.beyond3d.com/interviews/jcnv30r300/index.php?p=1

[Labberlippe]

Originally posted by Razor

Klasse LL,

kann es sein, dass Du da was falsch verstanden hast ?
Dann zeige mir doch bitte mal einen Unterschied von fp16 zu fp24 (oder fp32) !
Vor allem bitte in Games und am besten noch in Bewegung...
;D

Sorry, aber das finde ich einfach zu ulkig !
Wenn die R300 dadurch Leistung gewinnen würde, wenn sie auf fp16 herunter geschaltet wär, würde ATI das sofort machen. Ohne mit der Wimper zu zucken...

Allerdings hat ATI hier keine unterschiedlichen Pfade implementiert und kann nur fp24 (weil Mindestanforderung von DX9). Insofern würde es auf einer R300 einfach keinen Vorteil bringen...

Auf einem NV30 hingegen schon...
Und das Problem mit der default-seitigen fp32-Ausführung (sowohl DX9, als auch OGL2) wird nVidia sicherlich auch bald in den Griff bekommen. Vermutlich gibt's dann dafür eine (versteckte) Treiberoption, oder etwas ähnliches.

Bis denne

Razor

Dann zeige mir bitte in Games und bewegen ob man deutlich Unterschiede beim Tri-AF von ATi und nVIDIA sieht.
oder läufst Du immer mit schrägen Blick durch die Levels. :D

Merkste das Argument ist gleich und sinnlos.
Punkt ist das nVIDIA nur schneller mit FP16 ist und mit FP32 um die Hälfte langsamer als die ATi.
Dafür bietet die ATi nur 24 an.
ok das kann man lassen.
Aber wenn Du schon läster, dann frage ich Dich ob FP32 sinnvoll ist, wenn laut Dir der Unterschied zwischen FP16,24, und 32 eh nicht zum sehen in Bewegung per Games ist.

Immer wenden und drehen wie man es benötigt.

Gruss Labberlippe