Playstation 4 Pro: Bietet Features der neuen AMD-Vega-GPUs

Auf das fett markierte kann man getrost verzichten, immer. Ich weiß nicht wie sich color correction auswirkt, denke aber dürfte ebenfalls überflüssig sein.
Das kann natürlich deine subjektive Einschätzung sein, Spiele implementieren die Effekte letztendlich unterschiedlich, einige dezent und wirkungsvoll, andere schlicht übertrieben und es hängt natürlich auch von der technischen Umsetzung ab.
Color correction und tone mapping sind aber integrierte Abschnitte für das fertige Bild, wo es keine "off" Einstellungen gibt.
Sebastian hat sich in dem Bezug auch nur um die Nachbearbeitungen konzentriert, ich wollte einen Beitrag finden, wo immerhin Anwendungsfälle genannt werden.

Ein allgemeiner Beitrag von ihm neulich:
Games will be using mixed FP16 + FP32 as soon as we get consoles that support FP16. When developers get their shader code bases optimized for FP16 (and INT16), there will be a clear advantage in games for GPUs that support FP16/INT16 (double rate math + half register storage). AMD's entire desktop lineup already supports FP16/INT16 (Tonga, Fiji, Polaris10/11). I am sure Nvidia follows the suit when there are real performance gains to be seen in most of the games.

Personally I don't see much use for INT8 math in games. HDR output demands at least 10 bits per channel and FP processing suits HDR pipelines better than integer. INT16 is useful for many compute tasks (2d pixel coordinate math, etc). INT16 can replace INT32 in most cases (for zero loss of quality).

Similarly I don't see need for FP64 in games anytime soon. 3xINT32 position data is sufficent to model the whole earth in millimeter precision. FP32 is enough for view space (and/or camera centered) math.
Nvidia Pascal Announcement | Page 95 | Beyond3D Forum
 
Was rechnet eine GPU denn aus? Richtig: Welche Färbung das Pixel bekommt.

Für die meisten Pixel ist eine Vielzahl an Faktoren zu berechnen, um die finale Farbe zu bestimmen. Während es sicherlich sichtbare Folgen hätte, die Farbinformationen aus einer Fototextur mit zu geringer Präzision zu verrechnen, sieht das bei mehreren darüber gelegten Schatten oder bei Transparenzen schon anders aus. Wenn der Effekt keinen Verlauf kennt, kann auch bei geringer Präzision kein Banding auftreten und kleine absolute Fehler sind nicht nur schwer zu sehen – ohne Referenzobjekt weiß der Spieler nicht einmal, dass die Scheibe vor ihm 70,2 statt 70,3 Prozent Transparenz aufweisen sollte. Auch für viele Compute-Berechnungen könnte ich mir eine reduzierte Präzision gut vorstellen. Kleine Fehler gehen zum Beispiel in einem Partikeleffekt mit hunderten Vertices einfach unter.
 
Für die meisten Pixel ist eine Vielzahl an Faktoren zu berechnen, um die finale Farbe zu bestimmen. Während es sicherlich sichtbare Folgen hätte, die Farbinformationen aus einer Fototextur mit zu geringer Präzision zu verrechnen, sieht das bei mehreren darüber gelegten Schatten oder bei Transparenzen schon anders aus. Wenn der Effekt keinen Verlauf kennt, kann auch bei geringer Präzision kein Banding auftreten und kleine absolute Fehler sind nicht nur schwer zu sehen – ohne Referenzobjekt weiß der Spieler nicht einmal, dass die Scheibe vor ihm 70,2 statt 70,3 Prozent Transparenz aufweisen sollte. Auch für viele Compute-Berechnungen könnte ich mir eine reduzierte Präzision gut vorstellen. Kleine Fehler gehen zum Beispiel in einem Partikeleffekt mit hunderten Vertices einfach unter.

Nur wenn ich einen 32Bit Wert filtern will hilft es mir nichts dass der Transparenzfaktor in 8Bit darstellbar wäre. Promotion macht daraus wieder eine 32x32 Rechnung (was genau das ist was heute passiert, die Effektinputs selbst liegen in geringerer Auflösung vor aber das Ergebnis muss halt oft doch in "voller" Auflösung vorliegen).
Wenn der Faktor selbst aber natürlich noch von x Werten abhängt könnte man diesen in der Tat in geringerer Auflösung berechnen.
 
Zuletzt bearbeitet:
Warum überrascht es mich nicht, dass sich hier wieder die Entwickler-Experten mit einem Link melden um das zu wiederlegen was Sony und AMD für nützlich halten... Konsolen scheinen hier noch immer auf großes Interesse zu treffen und jeder meint schlauer als der Andere zu sein, wenn es um technische Fragen geht :D

Mal so nebenbei, eine 500€ GPU zu besitzen macht einen noch lange nicht zu einem Experten.
 
Zuletzt bearbeitet:
Eigentlich steckt noch viel mehr dahinter:
blue nugroho auf Twitter: "everyone talk FP16
a microcode thing, it is mandatory for SM 6.0
and X1 also support it FL12_1+
as X1 is 12_x (not just 12_1) it is beyond https://t.co/Udly3UVArl"


"everyone talk FP16
a microcode thing, it is mandatory for SM 6.0
and X1 also support it FL12_1+
as X1 is 12_x (not just 12_1) it is beyond"
Das ist mitunter der größte Rotzaccount und Nutzer den es auf Twitter gibt.
Jegliche Aussage von ihm ignorieren und maximal die Bilder und Verlinkungen anschauen.
Die X1 unterstützt nicht das FL12.1 wie unter DX12 für den PC definiert.
FP16 ist auch nicht Pflicht für SM 6.0.
 
Das ist mitunter der größte Rotzaccount und Nutzer den es auf Twitter gibt.
Jegliche Aussage von ihm ignorieren und maximal die Bilder und Verlinkungen anschauen.
Die X1 unterstützt nicht das FL12.1 wie unter DX12 für den PC definiert.
FP16 ist auch nicht Pflicht für SM 6.0.

Ich hatte es nur verlinkt, da Dresdenboy darauf reagiert hat, welcher ja sehr verlässlich ist.
 
Ich bin auch ursprünglich auf den schrecklichen Müll durch Dresdenboy gekommen.
Ich weiß nicht wie viel er davon selber ernst nimmt.
 
FP ist umso genauer, je näher der Wert an Null liegt. Nachdem sich der Spieler (bzw. die Kamera) aber nie von der Stelle bewegt, sondern immer an der Position 0/0/0 steht und stattdessen die Spielwelt ihre Position ändert, kann ich mir das Feature schon als sehr nützlich vorstellen.
 
Nur wenn ich einen 32Bit Wert filtern will hilft es mir nichts dass der Transparenzfaktor in 8Bit darstellbar wäre. Promotion macht daraus wieder eine 32x32 Rechnung (was genau das ist was heute passiert, die Effektinputs selbst liegen in geringerer Auflösung vor aber das Ergebnis muss halt oft doch in "voller" Auflösung vorliegen).
Wenn der Faktor selbst aber natürlich noch von x Werten abhängt könnte man diesen in der Tat in geringerer Auflösung berechnen.

Es geht aber doch nur mit welcher Ganuigkeit ich rechne. Farben haben aktuell bei 32Bit Farbtiefe gar keine 32Bit Genauigkeit sondern nur eine 8Bit Genauigkeit pro Kanal. Bei Geometrieberechnungen ist eine hohe Genauigkeit sehr wichtig, da mit unterschiedlich großen Polygonflächen hantiert wird und es sonst Probleme gibt. Bei vielen Effekten wird eine hohe Genauigkeit aber nicht gebraucht. Bei den Schatten sind es z.B. nur 8Bit pro Kanal. Daraus eine 32Bit Zahl zu machen ist kein Problem, da nur Nullen ergänzt werden und es macht auch keinen Unterschied ob man es vorher mit einer höheren Genauigkeit berechnet hat, weil am Ende der Definitionsbereich kleiner ist und die vielen Nachkommastellen ignoriert werden.
 
Zurück