PureBoard

Jap, damit ist der Zugriff auf den Grafikspeicher gemeint.
die Geforce 8600GT hat 128 Bit und eine 8800GT hat 256 Bit.
Eine Ati Radeon 2900XT hat 512 Bit. Wobei letztere eine doppelte Float-Präzision gegenüber den NV-Karten hat...
Ihr könnt schon Recht haben damit, dass intern mit mehr als 32 Bit gerechnet wird...

Warum sind es eigentlich 32Bit? Es reichen doch 24Bit (außer man hat noch zusätzlich nen Alphakanal).

dllfreak2001 hat geschrieben:Warum sind es eigentlich 32Bit? Es reichen doch 24Bit (außer man hat noch zusätzlich nen Alphakanal).

Es gab ja mal 24-Bit-Farbtiefen. Aber auf einer 32-Bit-CPU war es einfach
komfortabler mit 32-Bit-Werten zur rechnen. Dabei ging es weniger um den
Alphakanal als um die Geschwindigkeit.

Die Busbreite der nVidia und ich glaube auch der Ati Grafikkarten ist auch abhängig von der Speicherbestückung. Bei den Karten mit 128bit Busbreite ist in der Lowend version mit wenig Speicher oft nur 64bit genutzt, was afaik mit dem Platinenlayout zusammenhängt.

Um Nics kommentar besser zu verstehen solltest du dir ein bischen x86 Assembler antun. Mit einer 32Bit x86 CPU in eine 24bit Speicherzelle zu schreiben ist viel aufwändiger als in eine 32bit Speicherstelle. Wenn ich mich nicht täusche wären mindestens zwei Operationen nötig um das machen zu können statt einer. Da müsste man einer 16bit Wert kopieren und einen 8bit wert. Bin aber keine Assemblerexpertin, kann da auch falsch liegen

Seien wir uns erstmal einig, dass die oft benannte Speicherbandbreite aktueller Karten keine Aussage über die interne Verarbeitung von Farbwerten innerhalb einer GPU macht.

Die Speicherbausteine können parallel ausgelesen ausgelesen werden von daher kann man auch zwei 64-bit-Chips zusammenschalten um 128Bit Bandbreite zu nutzen (siehe auch Dualchannel).

Im 3D-Center-Forum bin ich auch noch nicht an eine sinnvolle Antwort gekommen.

Aber Geschwindigkeit ist das Stichwort: Wenn die erstmal alles in Floats umwandeln, denn im Grafikspeicher Floatfarben zu speichern ist doch Platz-Verschwendung. Andersrum würde sie nur beim Zugriff auf die Daten die Farben erstmal in Floats umwandeln und zurück (zB. um in den Cache zu schreiben) würden sie massig Performance verlieren.
Aber mal abwarten, vielleicht erwisch ich da einen der Spezialisten.


Edit: Ihr habt Recht, habe jetzt die Bestätigung. Die Farben werden in der GPU in Floats umgewandelt und auch als solche verarbeitet.

Ist ja auch logisch. Bei Floats kann es nicht zu einem Überlauf kommen. Es
kann höchstens passieren, dass der Wert "unendlich" wird. Und beim
Postprocessing wird erst alles, was größer als 1 ist auf genau 255 gesetzt.

Das mach ich auch in meiner Raytracing-Engine nicht anderst. Somit ist es
auch möglich bei berechneten viel zu hellen Bildern den Gammawert z.B. auf
0.1 zu setzen und trotzdem keine Farben zu verlieren.

Hab hier gerade noch einen Artikel gefunden, in dem Raytracing und Rasterisierung verglichen wird.
Bericht - Raytracing in Spielen 2.0

Außerdem habe ich heute morgen im Kiosk gesehen, dass in der PC Games
(oder so ähnlich) ein Artikel über Nvidia und seinem Konkurrenzprodukt
Raytracingkarte steht. Mehr hab ich aber auch nicht gelesen.

Ich bin auf jeden Fall mal gespannt, wie weit es dieses Jahr dann schon geht.

Bin auch schon gespannt, wie das funktionieren wird. Bzw. wan alles endlich mal richtig ins Rollen kommt nach dem Prinzip "Jetzt erhältlich!", aber da muss seine Software auch extra schreiben, oder irre ich mich? Ist ja noch eine weitere API neben DirectX und OpenGL.

Das soll OpenRT werden...

Wobei ich geb dem ganzen in naher Zukunft erstmal keine Chancen.

Intelligentes Antialiasing musst du auch noch reinpacken dafür muss man entweder noch nebenher die 3D-Daten parat halten oder man machts nicht intelligent und rendert ein Bild mit wesentlich höherer Auflösung und skaliert es dann auf die Desktopauflösung runter.
In beiden Fällen wird ein Haufen Leistung verbraten.

Wie siehts eigentlich mit Anisotropischen Filtern aus? Braucht man die für
Raytracing überhaupt?.

Kantendetektion hast du bei Raytracing automatisch und musst für's
Antialiasing nur noch diese neu berechnen, also nicht das ganze Bild hoch
skaliert berechnen. Mipmapping und Anisotropische Filter brauchst du gar
nicht, weil es dadurch nicht schneller wird und die Qualität beeinträchtigt
würde.

Die Leute vom OpenRT-Projekt verstehen ihr Handwerk haben sich schon
mit den "einfachen" Dingen auseinandergesetzt und natürlich hoch optimiert
entwickelt. Bin schon ein paar Mal bei denen gewesen und werde auch in die
Proseminare für Computergrafik gehen. Bin schon gespannt, was mich da
erwarten wird.

Nur komisch das alle ihre RT-engines ohne AA laufen.