PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Verhältnis Interne/"Externe" Präzision bei GPUs?

thop
2004-03-09, 16:20:27
Also so wie ich das ja verstehe rechnen heutige GPUs intern ja alle mit 32bit oder mehr, hauptsächlich damit sich Rundungsfehler nicht addieren. Soweit so gut.

Was ich dann aber immer noch nicht so Recht verstehe ist warum dann Spiele bei 16bit schneller sind obwohl eigentlich doch alles schon vorberechnet ist und die Reduktion von 32bit->16bit doch eigentlich sogar noch extra Zeit kosten müsste. Liegt es ausschließlich an den 16bit Texturen bzw. der geringeren Datenmenge die dann insgesamt zu schaufeln ist?

Zusatzfrage: Sind die externen 32bit eigentlich echte 32bit oder bloss die üblichen 24bit RGB + 8bit Alpha Kanal? Wie sieht das intern aus? Fragen über Fragen.
ShadowXX
2004-03-09, 16:31:36
Original geschrieben von thop
Also so wie ich das ja verstehe rechnen heutige GPUs intern ja alle mit 32bit oder mehr, hauptsächlich damit sich Rundungsfehler nicht addieren. Soweit so gut.

Was ich dann aber immer noch nicht so Recht verstehe ist warum dann Spiele bei 16bit schneller sind obwohl eigentlich doch alles schon vorberechnet ist und die Reduktion von 32bit->16bit doch eigentlich sogar noch extra Zeit kosten müsste. Liegt es ausschließlich an den 16bit Texturen bzw. der geringeren Datenmenge die dann insgesamt zu schaufeln ist?

Zusatzfrage: Sind die externen 32bit eigentlich echte 32bit oder bloss die üblichen 24bit RGB + 8bit Alpha Kanal? Wie sieht das intern aus? Fragen über Fragen.

IMHO brauchen die 16Bit Bildschirmausgaben einfach weniger Fuellrate...

Zur Zusatzfrage: 24+8
R300
2004-03-09, 18:12:56
Naja neuere Grakas wie meine Radeon 9700Pro sind mit 16Bit langsamer als mit 32Bit.
Ich habs mit 3DMark01 getestet, kann mich aber nicht mehr erinnern, wie groß der Unterschied war.
ram
2004-03-09, 21:15:49
Original geschrieben von thop
Was ich dann aber immer noch nicht so Recht verstehe ist warum dann Spiele bei 16bit schneller sind obwohl eigentlich doch alles schon vorberechnet ist und die Reduktion von 32bit->16bit doch eigentlich sogar noch extra Zeit kosten müsste. Liegt es ausschließlich an den 16bit Texturen bzw. der geringeren Datenmenge die dann insgesamt zu schaufeln ist?

Ja. Lese- + Schreibzugriffe auf den Farb- und Tiefenspeicher benötigen bei 16bit in der Regel nur die Hälfte der Kapazität, die bei einem 32bit Framebuffer benötigt würde. Bei 16bit-Texturen statt 32bit-Texturen reduziert sich auch die Übertragungskapazität bei Zugriffen auf den Texturspeicher.

Ausnahmen können z.B. daher kommen, das Kompressionsalgorithmen o.ä. nur für 32bit ausgelegt sind und bei 16bit-Rendering einfach deaktiviert oder weniger effektiv sind.

Zusatzfrage: Sind die externen 32bit eigentlich echte 32bit oder bloss die üblichen 24bit RGB + 8bit Alpha Kanal? Wie sieht das intern aus? Fragen über Fragen.

32bit ist bei den Farbwerten 24bit RGB + 8 bit Alpha. Bei den Tiefenwerten kanns 24bit Z + 8 bit Stencil oder 32bit Z sein.
Chief o Hara
2004-03-10, 00:05:34
Original geschrieben von ShadowXX
IMHO brauchen die 16Bit Bildschirmausgaben einfach weniger Fuellrate...

Zur Zusatzfrage: 24+8

Nee in Sachen Füllrate gibt es keinen Unterschied zwischen 16 und 32bit Fabrtiefe. Warum auch, es werden ja schließlich nicht plötzlich mehr oder weniger Pixel verarbeitet.
Mehr Farbtiefe benötigt schlichtweg Bandbreite.
Ne 9800SE dürfte von 16bit Farbtiefe keinen großen Leistungsschub bekommen während eine GF2 gleich doppelt so schnell wäre.

edit: ram von 3dconcept?
MadManniMan
2004-03-10, 02:03:33
Hm, ich denke gerade darüber nach, ob der Schritt zu einer höheren externen Farbtiefe irgend Sinn machte... Bähnding seh ich irgendwie in letzter Zeit verdammt oft.

BTW @ram: endlich kennt man mal dein Konterfei =)
marco42
2004-03-10, 09:29:19
Original geschrieben von MadManniMan
Hm, ich denke gerade darüber nach, ob der Schritt zu einer höheren externen Farbtiefe irgend Sinn machte... Bähnding seh ich irgendwie in letzter Zeit verdammt oft.

BTW @ram: endlich kennt man mal dein Konterfei =)

Das kannst du sehen. Auf unseren SGIs hat du bei manchen nicht texturierten Modellen den Unterschied zwischen 8bit und 12bit pro channel klar gesehen. Macht aber daher wohl eher Sinn bei Visualisierungen und weniger bei Spielen.
Gast
2004-03-10, 11:45:49
Original geschrieben von MadManniMan
BTW @ram: endlich kennt man mal dein Konterfei =)

Wo?
aths
2004-03-10, 12:32:33
Original geschrieben von MadManniMan
Hm, ich denke gerade darüber nach, ob der Schritt zu einer höheren externen Farbtiefe irgend Sinn machte... Ja, natürlich.

Der nächste Schritt wäre, den 32-Bit-Framebuffer in 10:10:10:2 aufzuteilen, und weiterhin Alphablending und FSAA zu unterstützen. Teil 3 des FP-Artikels kommt Ende dieser oder Anfang nächster Woche :)
MadManniMan
2004-03-10, 14:17:07
Original geschrieben von Gast
Wo?

PCGH, aktuelle Ausgabe letzte Seite =)

aths,
ich verstehe den Sinn von nur 2bit Alpha nich. Bissel wenig, oder?
aths
2004-03-10, 14:56:45
Original geschrieben von MadManniMan
PCGH, aktuelle Ausgabe letzte Seite =)

aths,
ich verstehe den Sinn von nur 2bit Alpha nich. Bissel wenig, oder? Destination Alpha wird fast nie gebraucht.
R300
2004-03-10, 15:36:56
Original geschrieben von aths
Ja, natürlich.

Der nächste Schritt wäre, den 32-Bit-Framebuffer in 10:10:10:2 aufzuteilen, und weiterhin Alphablending und FSAA zu unterstützen. Teil 3 des FP-Artikels kommt Ende dieser oder Anfang nächster Woche :)

Der R3x0 hat doch schon ein 10:10:10:2 Framebuffer.
aths
2004-03-10, 16:56:10
Original geschrieben von R300
Der R3x0 hat doch schon ein 10:10:10:2 Framebuffer. Dann funzt MSAA nicht mehr, afaik.
Xmas
2004-03-11, 13:14:28
Original geschrieben von R300
Der R3x0 hat doch schon ein 10:10:10:2 Framebuffer.
AFAIK kann er dies als Textur/Rendertarget-Format, aber nicht auf den Bildschirm ausgeben. Parhelia kann es aber sicher.