Gewinne durch FP16 und INT8 Format in Spielen?

[Godmode]

Da die Pascal Generation ja diese beiden Formate mit höherer Geschwindigkeit berechnen können wird, habe ich mich gefragt, ob und wieviel uns das für 3D bringen wird?

1.) Gibt es viele Berechnungen in aktuellen 3D-Engines, wo zB. ein half Float statt einem normalen 32 Bit Float ausreicht, bzw. sogar ein 8-Bit Integer?

2.) Muss das wieder vom Entwickler gemacht werden, oder könnte dass der Treiber automatisieren?

3.) Was wird das ganze bringen, oder ist das hauptsächlich für HPC Anwendungen interessant?

[Complicated]

Anand hat das kurz beleuchtet als Tonga FP16 in GCN in Hardware wieder eingeführt hat. Im Prinzip profitieren nur die Low-Power Chips davon und ganz besonders SoCs. Im Tonga Launch Artikel ist er darauf eingegangen:
http://www.anandtech.com/show/8460/amd-radeon-r9-285-review/2
Meanwhile GCN 1.2’s other instruction set improvements are quite interesting. The description of 16-bit FP and Integer operations is actually very descriptive, and includes a very important keyword: low power. Briefly, PC GPUs have been centered around 32-bit mathematical operations for some number of years now since desktop technology and transistor density eliminated the need for 16-bit/24-bit partial precision operations. All things considered, 32-bit operations are preferred from a quality standpoint as they are accurate enough for many compute tasks and virtually all graphics tasks, which is why PC GPUs were limited to (or at least optimized for) partial precision operations for only a relatively short period of time.

However 16-bit operations are still alive and well on the SoC (mobile) side. SoC GPUs are in many ways a 5-10 year old echo of PC GPUs in features and performance, while in other ways they’re outright unique. In the case of SoC GPUs there are extreme sensitivities to power consumption in a way that PCs have never been so sensitive, so while SoC GPUs can use 32-bit operations, they will in some circumstances favor 16-bit operations for power efficiency purposes. Despite the accuracy limitations of a lower precision, if a developer knows they don’t need the greater accuracy then falling back to 16-bit means saving power and depending on the architecture also improving performance if multiple 16-bit operations can be scheduled alongside each other.

Räumt aber noch andere Verwendungszwecke ein die ihm noch nicht klar sind:
Finally, data parallel instructions are the feature we have the least knowledge about. SIMDs can already be described as data parallel – it’s 1 instruction operating on multiple data elements in parallel – but obviously AMD intends to go past that. Our best guess would be that AMD has a manner and need to have 2 SIMD lanes operate on the same piece of data. Though why they would want to do this and what the benefits may be are not clear at this time.

[AnarchX]

In 3D nutzbar wird das ganze wohl sein, fragt sich wie viel Rechenlast man da umleiten kann, ohne das die Bildqualität sinkt:
http://blog.imgtec.com/powervr/powervr-gt7900-redefining-performance-efficiency
https://de45xmedrsdbp.cloudfront.net/Resources/files/GDC2014_Next_Generation_Mobile_Rendering-2033767592.pdf

[fondness]

Aktuell kann nur GCN1.2 FP16/INT16.

[Tesseract]

ich kann mir nicht vorstellen, dass FP16 abseits vom mobilen markt besonders relevant sein wird, dafür ist das format einfach zu schmal. kleine int-formate haben da wohl sogar noch bessere chancen da diese nicht "ungenauer" werden sondern nur der wertebereich kleiner wird.

[Godmode]

Danke für die Links. Wahrscheinlich wird NV einige Sachen aus Gameworks für FP16/INT8 optimieren, wo es halt möglich ist.

[iuno]

Ja, das ergibt sogar Sinn. Waere zumindest eine gute Moeglichkeit, aeltere HW (sowohl eigene als auch konkurrierende) obsolet zu machen und Verkauf anzukurbeln *scnr* Ich meine natuerlich, mehr Leistung rauszuholen :ulol: Aber mal im Ernst, das ist schon gut moeglich, trotzdem bleibt natuerlich die Frage, an welcher Stelle man in der Hinsicht 'sparen' kann.

[Ailuros]

ich kann mir nicht vorstellen, dass FP16 abseits vom mobilen markt besonders relevant sein wird, dafür ist das format einfach zu schmal. kleine int-formate haben da wohl sogar noch bessere chancen da diese nicht "ungenauer" werden sondern nur der wertebereich kleiner wird.

https://forum.beyond3d.com/posts/1805823/

You have got it backwards. It is not a case of FP32 catching up to FP16, it is FP16 capabilities being enhanced. It is happening in PC graphics as well, witness AMDs Tonga and where Intel is going since Gen8.

The reasons have been given before. All else being equal, FP16 operations take less power, requires less internal (and external) bandwidth, the hardware takes much less die area which for a given level of performance which lowers cost and improves yield which lowers cost again. Alternatively, for a given budget of die space and power draw, FP16 yields much better performance. Routinely using a compact numerical representation and only using larger formats when actually needed simply makes sense. Why waste limited resources?

I would contend, and recent developments in PC graphics space agrees, that rather than mobile graphics slavishly following in the footsteps of designs targeting high-end desktop PC/HPC, PC graphics will actually be more influenced by mobile solutions. Personal computing is moving to higher pixel densities (making small errors perceptually irrelevant) and laptops are moving towards lighter designs with longer battery lives, increasing demands on power efficiency. So rather than mobile loosing their constraints and being more enthusiast desktop like (SLI! Crossfire! 1200W PSUs!) which is a ridiculous notion, what is actually happening is that the bulk of personal computing is moving towards mobile constraints.
(Indeed, many who aren't emotionally rooted in PC space would contend that mobile is where the bulk of personal computing takes place these days. Windows PCs have become a (large) computing niche.)

If we project forward, these trends don't seem likely to turn around. New silicon tech is unlikely to make compromises unnecessary, rather the lithographic challenges going forward are increasing. If you want development to move forward, regardless of whether you are a tech hungry consumer, or a manufacturer who needs new stuff to sell, being ever more intelligent about how you use available resources seems like a very good idea.

https://forum.beyond3d.com/posts/1805847/

Sometimes it requires more work to get lower precision calculations to work (with zero image quality degradation), but so far I haven't encountered big problems in fitting my pixel shader code to FP16 (including lighting code). Console developers have a lot of FP16 pixel shader experience because of PS3. Basically all PS3 pixel shader code was running on FP16.

It is still is very important to pack the data in memory as tightly as possible as there is never enough bandwidth to lose. For example 16 bit (model space) vertex coordinates are still commonly used, the material textures are still dxt compressed (barely 8 bit quality) and the new HDR texture formats (BC6H) commonly used in cube maps have significantly less precision than a 16 bit float. All of these can be processed by 16 bit ALUs in pixel shader with no major issues. The end result will still be eventually stored to 8 bit per channel back buffer and displayed.

Could you give us some examples of operations done in pixel shaders that require higher than 16 bit float processing?

EDIT:
One example where 16 bit float processing is not enough: Exponential variance shadow mapping (EVSM) needs both 32 bit storage (32 bit float textures + 32 bit float filtering) and 32 bit float ALU processing.

However EVSM is not yet universally possible on mobile platforms right now, as there's no standard support for 32 bit float filtering in mobile devices (OpenGL ES 3.0 just recently added support for 16 bit float filtering, 32 bit float filtering is not yet present). Obviously GPU manufacturers can have OpenGL ES extensions to add FP32 filtering support if their GPU supports it (as most GPUs should as this has been a required feature in DirectX since 10.0).

Es gibt einiges mehr im spezifischen thread und es wurde sehr schnell ruhig in diesem als die zusaetzlichen FP16 Faehigkeiten in der Tegra X1 GPU angekuendingt wurden...(warum wohl? :confused: )

[deekey777]

Goldene Schaufel an mich bitte.

Polaris beherrscht nativ INT16/FP16, http://images.anandtech.com/doci/10446/P3.png?_ga=1.18704828.484432542.1449038245

Nach dieser Folie beherrschen nur die APUs nativ INT16/FP16 mit dritter GCN-Generation (welche sind das überhaupt), jetzt auch die Desktop-GPUs. Im B3D-Forum gibt auch eine Diskussion dazu:
https://forum.beyond3d.com/threads/amd-speculation-rumors-and-discussion.56719/page-181#post-1927331



: Register pressure is another bottleneck of GCN architecture. It's been discussed in many presentation since the current console gen launch. Fp16/int16 are great ways to reduce this bottleneck. GCN3 already introduced fp16/int16, but only for APUs. AMD marking slides state that GCN4 adds fp16/int16 for discrete GPUs (http://images.anandtech.com/doci/10446/P3.png?_ga=1.18704828.484432542.1449038245). This means that fp16/int16 is now a main feature on all GCN products. Nvidia is only offering fp16 on mobile and professional products. Gaming cards (GTX1070/1080) don't support it.

For what it's worth, when Tonga was released I was explicitly told that it supported FP16. So if that's not the case, that's a change in what AMD is saying.

+ https://forum.beyond3d.com/threads/amd-speculation-rumors-and-discussion.56719/page-182#post-1927339

Nvidia hatte mit der Geforce FX also Recht. X-D

[y33H@]

AMD sagte, dass man FP16 u.a. für TressFX nutze(n werde).

[aths]

ich kann mir nicht vorstellen, dass FP16 abseits vom mobilen markt besonders relevant sein wird, dafür ist das format einfach zu schmal. kleine int-formate haben da wohl sogar noch bessere chancen da diese nicht "ungenauer" werden sondern nur der wertebereich kleiner wird.
Bezieht man Genauigkeit auf die relative Abweichung, sind FP-Formate vorzuziehen. Bei großen Werten gröbere Abstände zu haben, ist oft nicht so schlimm, da der relative Genauigkeitsverlust recht klein ist.

[Foobar2001]

ich kann mir nicht vorstellen, dass FP16 abseits vom mobilen markt besonders relevant sein wird, dafür ist das format einfach zu schmal. kleine int-formate haben da wohl sogar noch bessere chancen da diese nicht "ungenauer" werden sondern nur der wertebereich kleiner wird.
Reicht voellig fuer gaengige Lichtberechnungen. Die Vorteile sind riesig, fast doppelter Durchsatz und weniger Registerdruck. Wer das nicht verwendet waere bloed.

[Kartenlehrling]

Hat "ATI Catalyst A.I" nicht schon FP16 genutzt, es wurde nur als FP32 abgespeichert weil es effizenter war.

[Foobar2001]

Das war fuer die Rendertargets, andere Baustelle

[robbitop]

Reicht voellig fuer gaengige Lichtberechnungen. Die Vorteile sind riesig, fast doppelter Durchsatz und weniger Registerdruck. Wer das nicht verwendet waere bloed.
Den doppelten Durchsatz sieht man doch aber nur bei GP100, IMGs letzte mobile GPUs und Tegra, oder?

[Foobar2001]

Ich weiss, dass AMD und NVIDIA beide planen doppelten Durchsatz zu haben. Was heute verfuegbar ist, ist unklar.

GP104 hat wohl gar keine Unterstuetzung. GCN 1.2+ sollte, aber ich weiss nicht welcher Durchsatz.

[Gipsel]

GP104 hat wohl gar keine Unterstuetzung. GCN 1.2+ sollte, aber ich weiss nicht welcher Durchsatz.GP104 hat schon Support. Allerdings kann GP104 die Vektorvarianten der fp16 Befehle (also z.B. für half2, nur mit denen gibt es ja bei GP100 den doppelten Durchsatz) nur mit 1/64 Rate ausführen :freak:. Damit wird es dann im Vergleich recht enttäuschend bzw. müssen dann die Skalarvarianten zum Einsatz kommen, die wohl 1:1 mit FP32 laufen.
Die neuen GCN Iterationen machen es afaik immer 1:1 zu fp32. Man hat also nur den Vorteil des gesparten Registerplatzes und Stromes (wodurch die GPU eventuell minimal höher boosten kann, wenn das genutzt wird). Aber wohl besser als gar nichts.

[Foobar2001]

GP104 hat schon Support. Allerdings kann GP104 die Vektorvarianten der fp16 Befehle (also z.B. für half2, nur mit denen gibt es ja bei GP100 den doppelten Durchsatz) nur mit 1/64 Rate ausführen :freak:.
Hae? ;D :freak:

Wie haben sie das denn geschafft?

[AnarchX]

Wahrscheinlich wird das auch nur auf den dedizierten FP64-ALUs mit ausgeführt.

Aber GP104 beherrscht Operationen, wo mit 4-facher Rate (~36 TOPS) INT8 verarbeitet werden kann, was wohl die Deep Learning OPs sind:
https://devtalk.nvidia.com/default/topic/934562/cuda-programming-and-performance/nvidia-pascal-geforce-gtx-1080-amp-gtx-1070/post/4889704/#4889704

Insgesamt Schade, dass weder GP10x noch Polaris FP16 mit 2x Rate ausführen können/dürfen.

[Nakai]

Ich implementiere derzeit spaßeshalber ein FPGA-Design (Xilinx Zynq7xxx) für einen neuronalen Coprozessor mit verteilten Ausführungsblöcken. Ziel: CNNs auf dem Ding ausführen und als AXI4-IP konfigurierbar machen. Derzeit habe ich die Ausführungseinheiten grob implementiert. Ich verwende ein Fixpoint/INT-Datenformat mit konfigurierbarer Bitbreite (Generic).

Wenn man die Numerik berücksichtigen will, zieht das schon einen Ratenschwanz an Änderungen mit sich, wie Rundung, Saturierung, etc. Will man das noch gut pipelinen, will man einiges Sachen auch noch anders konzipieren. Kurz, jede Pipelinestage ähnlich komplex, um im Design eine durchgängige gute Taktbarkeit zu erreichen, ebenso muss man sich überlegen, wie der Interconnect aussieht. Eine komplexe Ausführungsstruktur will man eigentlich eher nicht haben.

Wie gesagt, der Einbau von solcher Funktionalität kann die hohe Taktbarkeit und den Energieverbrauch schon etwas schmälern, vor allem, wenn man eine bestimmte Anzahl an Stages beibehalten muss. Eine SP von Paxwell ist 6 Stages lang. Das DARF man nicht ändern. Ergo wird die Funktionalität irgendwie auf die Stages "gemappt", wodurch die Taktbarkeit definitiv geschmälert wird.

€: Höhere INT8-Rate sollte tatsächlich relativ unproblematisch sein, als höhere FP16 Rate. Die ALUs gibt es bereits und ein FP32-Exponent ist bereits 8Bit breit und die Mantisse mit Vorzeichen eben 24Bit. Das sind ja nichts weiter als INT-ALUs welche eben MUL, ADD und Shift können müssen. Und INT-ALUs kann man einfach auftrennen, wenn Overflow/Underflow/Carry-Sachen nicht berücksichtigt werden müssen. Und soweit ich weiß, wird das alles in 32Bit Registern akkumuliert.

[Foobar2001]

Wahrscheinlich wird das auch nur auf den dedizierten FP64-ALUs mit ausgeführt.

Aber GP104 beherrscht Operationen, wo mit 4-facher Rate (~36 TOPS) INT8 verarbeitet werden kann, was wohl die Deep Learning OPs sind:
https://devtalk.nvidia.com/default/topic/934562/cuda-programming-and-performance/nvidia-pascal-geforce-gtx-1080-amp-gtx-1070/post/4889704/#4889704

Insgesamt Schade, dass weder GP10x noch Polaris FP16 mit 2x Rate ausführen können/dürfen.
Btw. man munkelt, dass Polaris GCN 1.2 ist wie Fury und R9 380. GCN 1.3 kommt erst mit Vega.

[seba86]

Verstehe ich richtig, dass FP16 & INT8 auch mvon der Farbtiefe abhängt?

Bei z.B. 16bit statt 32bit Farbtiefe hätte man doch doppelte Power hinsichtlich der äh... Texel-Leistung?

Bei einigen alten Games ist der Unterschied zwischen 16 und 32bit vernachlässigbar, wenn das also massiv Power einsparen würde, wäre eine Wiedereinführung schon geil..

[Foobar2001]

Das hat nichts mit der Farbtiefe zu tun. Die Rechenleistung wird potentiell hoeher sein.

[seba86]

Danke für die Erklärung...

[Ravenhearth]

Btw. man munkelt, dass Polaris GCN 1.2 ist wie Fury und R9 380. GCN 1.3 kommt erst mit Vega.

Polaris ist genauso wenig GCN 1.2 wie Tonga und Fiji, die richtige Bezeichnung für Polaris ist GCNv4. Selbst wenn man die anandtech-Nummering heranzieht, wäre es wohl eher GCN 1.3 oder 2.0, denn laut AMD ist Polaris die bisher größte Überarbeitung der Architektur, hinzu kommt 14nm. Wie kommt man überhaupt drauf, dass es die gleiche Architektur ist?

[Locuza]

Etwas konkreter geht es um die ISA oder eig. viel weitreichender die GFX-IP, wo der Linux-Treiber die Version 8 zurückgibt (Die gleiche wie GCN Gen 3).
Das scheint AMD auch mündlich Ryan Smith von Anandtech bestätigt zu haben:
And just to add to that, AMD told me that the ISA for Polaris "did not change" from GCN 3, so it should be identical.
https://forum.beyond3d.com/threads/direct3d-feature-levels-discussion.56575/page-36#post-1927971

Vega soll bekanntlich die GFX IP v9 beinhalten, was immerhin gewisse Änderungen nach sich ziehen würde.

[Ravenhearth]

Das muss aber nicht bedeuten, dass es keine Unterschiede in der Implementierung gibt. Aus dem anandtech-Rview:

At its heart, Polaris is based on AMD’s 4th generation Graphics Core Next architecture (GCN 4). GCN 4 is not significantly different than GCN 1.2 (Tonga/Fiji), and in fact GCN 4’s ISA is identical to that of GCN 1.2’s. So everything we see here today comes not from broad, architectural changes, but from low-level microarchitectural changes that improve how instructions execute under the hood.

Keine Ahnung warum sie beide Zählweisen parallel benutzen.

[Der HeinZ]

Mal als Leie doof gefragt: Kann man FP32 und FP16 oder gar int8 gleichzeitig nutzen?
Es hat doch nur etwas mit der präzision zu tun, oder ist der Grafikchip auf ein Format gleichzeitig beschränkt? In Kombination macht soetwas meiner Meiner Meinung nach mehr sinn, da man die Formate dann danutzen kann, wo man die entsprechenden Präzisionen benötigen würde und Resourcen einspart.
Kenn mich mit dem Thema leider garnicht aus.
Gruss Matthias

[Tesseract]

kommt drauf an was du mit "gleichzeitig" meinst. auf low-level-ebene kann eine 32-bit-multiplikation z.B. so aussehen:
"lade 32bit von adresse A, 32bit von adresse B, multipliziere sie und schreib es in adresse C"
wenn die 32bit-FPU zusätzlich zu 32bit-mul auch 2x16bit-mul kann gibt es dann z.B. zusätzlich die operation:
"lade 32bit von adresse A, 32bit von adresse B, multipliziere sie als 2x16 und schreib es in adresse C".
wenn in A und B jeweils 2 16bit floats hintereinander gespeichert sind hat man so 2 operationen gleichzeitig ausgeführt - das ist grob das konzept dahinter. natürlich kann auf FP16 auch FP32 oder int8 folgen. der hardware ist vollkommen egal was in den speicherbereichen drin steht, die macht einfach stur die angegebene operation auf die angegeben speicherbereiche. wenn du integer als floats zusammenrechnest kommt halt blödsinn raus.

[Der HeinZ]

kommt drauf an was du mit "gleichzeitig" meinst. auf low-level-ebene kann eine 32-bit-multiplikation z.B. so aussehen:
"lade 32bit von adresse A, 32bit von adresse B, multipliziere sie und schreib es in adresse C"
wenn die 32bit-FPU zusätzlich zu 32bit-mul auch 2x16bit-mul kann gibt es dann z.B. zusätzlich die operation:
"lade 32bit von adresse A, 32bit von adresse B, multipliziere sie als 2x16 und schreib es in adresse C".
wenn in A und B jeweils 2 16bit floats hintereinander gespeichert sind hat man so 2 operationen gleichzeitig ausgeführt - das ist grob das konzept dahinter. natürlich kann auf FP16 auch FP32 oder int8 folgen. der hardware ist vollkommen egal was in den speicherbereichen drin steht, die macht einfach stur die angegebene operation auf die angegeben speicherbereiche. wenn du integer als floats zusammenrechnest kommt halt blödsinn raus.
Vielen Dank für die Erklärung! Für mich immernoch schwer nachvollziehbar.

Wenn ich jetzt dein Beispiel nehme:
"lade 32bit von adresse A, 32bit von adresse B, multipliziere sie als 2x16 und schreib es in adresse C"

bedeutet dies dass er aus den zwei 32 Bit Werten zwei 16 Bit Werte macht (rundet) und diesen dann als 2x16 berechnet?
Außer dass er mit kleineren Zahlen rechnet und so Speicher/Bandbreite spart, ergibt sich durch die geringere Präzision ein Geschwindigkeitsvorteil, der heutzutage ins Gewicht fällt, also erheblich ist? Oder hängt das vom Chip ab und dessen Funktionsset?
oder
bin jetzt auf dem totalen Holzweg und habe es noch nicht verstanden?
Wie gesagt ich habe keine Ahnung :)
Vielleicht sollte ich mich erstmal mit Programmierung auseinandersetzen.
Gruss Matthias

[Tesseract]

bedeutet dies dass er aus den zwei 32 Bit Werten zwei 16 Bit Werte macht (rundet) und diesen dann als 2x16 berechnet?

es gibt in dem fall keine "32bit-werte". in den 32bit steht in den ersten 16bit die erste zahl und in den zweiten 16bit die zweite zahl.
zur veranschaulichung ein beispiel mit uint8 und uint4:
uint8-addition:
A: 0100 0001 + B: 0100 1010 = C: 1000 1011
2xuint4-addition:
A1: 0100 + B1: 0100 = C1: 1000
A2: 0001 + B2: 1010 = C2: 1011

die erste rechnung ist in dezimal interpretiert 65+74=139, die zweiten sind 4+4+8 und 1+10=11. in beiden fällen wurden 2x8bit gelesen, 1x8bit geschrieben und ein mal die ALU verwendet, die "arbeit" für die hardware war also die gleiche.

[AnarchX]

FP16@SM60 (GP100): http://pc.watch.impress.co.jp/img/pcw/docs/1023/668/html/10.jpg.html
INT8@SM61 (GP10x): http://pc.watch.impress.co.jp/img/pcw/docs/1023/668/html/9.jpg.html

[Screemer]

Was ist eigentlich an der Theorie dran dass nvidias shadercompiler beim ersten run den code untersucht und wo es sinnvoll ist die Genauigkeit auf fp16 reduziert und NV gpus deshalb mehr aus ihrer geringeren rohleistung holen können? Zumindest seit Fermi sind NV gpus ja bei fp16 doppelt so schnell wie bei fp32, wenn ich mich richtig erinnere.

[Hübie]

Im besten Fall hast du 1:1 von FP32->FP16, abgesehen von der Ausnahme im GP100 ;)

[Screemer]

Im besten Fall hast du 1:1 von FP32->FP16, abgesehen von der Ausnahme im GP100 ;)

Das betrifft aber nur compute und nicht das filtering oder verstehe ich folgenden Artikel falsch?

http://www.anandtech.com/show/4008/nvidias-geforce-gtx-580/2

[Foobar2001]

Filtering ist eine komplett andere Baustelle.

Was ist eigentlich an der Theorie dran dass nvidias shadercompiler beim ersten run den code untersucht und wo es sinnvoll ist die Genauigkeit auf fp16 reduziert und NV gpus deshalb mehr aus ihrer geringeren rohleistung holen können? Zumindest seit Fermi sind NV gpus ja bei fp16 doppelt so schnell wie bei fp32, wenn ich mich richtig erinnere.
Nichts. Das ist unmoeglich und es gibt ueberhaupt keine FP16-Cores/ALUs/Shader in Fermi.

Nur Pascal GP100 hat im Moment schnelles FP16, das wird sich mit der naechsten Generation sicher aendern und bei AMD wohl mit Vega.

[Complicated]

AMDs Tonga hat ebenfalls schon FP16 Beschleunigung. Es ist Teil des GCN3 Instructionsets:
http://www.anandtech.com/show/9390/the-amd-radeon-r9-fury-x-review/2
Auch Fiji kann 16-bit ebenso wie Carrizo.

[Hübie]

Die können alle keine zwei FP16 Operanden auf jeweils eine ALU mappen...

[Troyan]

Nur Pascal GP100 hat im Moment schnelles FP16, das wird sich mit der naechsten Generation sicher aendern und bei AMD wohl mit Vega.

Tegra X1 und Parker können es ebenfalls.

[Mancko]

Bringt vermutlich Nintendo für die Switch was oder?

[mr coffee]

Auf jeden Fall kommt es mit der PS4 Pro.

Aus http://www.gamesindustry.biz/articles/2016-10-21-sony-we-still-believe-in-console-generations

Interestingly, when looking at the architectural improvements that PS4 Pro offers, Cerny pointed out that the way the system handles computing enables it to provide more than the base 4.2 teraflops that have been advertised. "It's possible to perform two 16-bit operations at the same time, instead of one 32-bit operation. In other words, with full floats, PS4 Pro has 4.2 teraflops of computational power. With half floats, it now has double that -- which is to say, 8.4 teraflops of computational power. As I'm sure you understand, this has the potential to radically increase the performance of games," he commented.

[-/\-CruNcher-/\-]

Bringt vermutlich Nintendo für die Switch was oder?

Es bringt schon lange der Shield etwas also kannst du davon ausgehen das es Nintendo das gleiche bringt ;)

[Finch]

Jetzt mal für uns/mich Laie(n).

Wenn so ein Tegra X2 bei FP32 0.75 Tflops hat und in der Lage ist pro FP32 operation 2x16FP durchzuführen, verdoppelt sich die Leistung? (Siehe PS4Pro Link von Mr. Coffee)

Bzw. Wie viel lässt sich in Spielen mit FP16 berechnen?

wäre es also möglich, dass die Switch mit dem X2 mit Hilfe von FP16 der XB1 nahe kommen könnte?

[Hübie]

Ich klau mal Gipsel seinen Beitrag:

Außer dem von AnarchX bereits genannten, kommen viele Berechnungen der Beleuchtung, Oberflächennormalen und der letztendlichen Pixelfarbe mit FP16 aus. Dies ist aber auch immer von den genau benutzten Algorithmen abhängig, also nicht völlig zu verallgemeinern. Man kann in einem Shader ja alle Datentypen mischen, wie es einem beliebt. Man berechnet bestimmte Operationen mit FP16 (oder auch INT16) wenn es reicht (worüber sich der Programmierer klar werden muß), sonst eben FP32/INT24/INT32.

[Finch]

Danke, diesen Auszug muss ich überlesen haben. Wie kommt es, dass erst jetzt auf diese Schiene aufgesprungen wird?

[Kartenlehrling]

Vor 7 Jahren hat ja ATI einen Vorversion versucht, da hat aber Nvidia von Betrug und nicht 100% Qualität geschrieben, schon damal könnte ATI zwischen 0-15% Leistungs Gewinn erzielen.

[Finch]

bis zu 15% sind schon ordentlich. Dann dürfte das ganze ja nun langsam an Fahrt aufnehmen, wenn nun NV und AMD damit arbeiten wollen.

[deekey777]

Vor 7 Jahren hat ja ATI einen Vorversion versucht, da hat aber Nvidia von Betrug und nicht 100% Qualität geschrieben, schon damal könnte ATI zwischen 0-15% Leistungs Gewinn erzielen.
Was?

[Nakai]

http://www.geeks3d.com/20100916/fp16-demotion-a-trick-used-by-ati-to-boost-benchmark-score-says-nvidia/

[Nakai]

http://www.geeks3d.com/20100916/fp16-demotion-a-trick-used-by-ati-to-boost-benchmark-score-says-nvidia/

€: Da hatte AMD noch kein FP32-FP16-Verhältnis von 1:2. ;)

Der Vorteil kommt schon alleine davon, dass die Speichersubsysteme weniger stark belastet werden. Mit doppelter Rate und Optimierungen kann man nochmal von einem Sprung ausgehen. ;)

[Gipsel]

http://www.geeks3d.com/20100916/fp16-demotion-a-trick-used-by-ati-to-boost-benchmark-score-says-nvidia/Da hat man Rendertargets von 4xFP16 auf R11G11B10 (oder auch R10G10B10A2) gesetzt (und damit die Hälfte der Bandbreite gespart). Das war traditionell der Schalter "Surface Optimizations" im Treiber, keine Ahnung, ob es den noch gibt. Das hat eigentlich erstmal nicht so viel mit der Genauigkeit der eigentlichen Berechnungen im Shader zu tun (außer der Vermutung, daß wenn 10 Bit pro Komponente im Rendertarget als Ergebnis reichen, man vermutlich oft mit FP16 bei den Rechnungen auskommen dürfte [stimmt aber nicht immer]). Daß das bei nV nicht so viel brachte, liegt einfach an deren im Vergleich zu AMD traditionell schlechteren Performance der ROPs mit diesen Formaten (nur halfrate Blending, gewinnen dort also gegenüber FP16 nichts), während bei AMD das auch mit Blending Fullspeed geht (FP16 zwar auch, hängt dann bloß extrem an der Bandbreite). Bei den TMUs schwächelt dagegen AMD bei FP16 etwas (häufig wird ein Rendertarget ja auch wieder darüber eingelesen). Kurz, bei nV geht die benötigte Bandbreite runter, aber ebenso der ROP-Durchsatz bei Einsatz von Blending. Bei AMD benötigt man nur die halbe Bandbreite hält den ROP-Durchsatz aber oben (der nutzbare vergrößert sich) und verdoppelt den TMU-Durchsatz mit dem Format. Also vollkommen klar, daß AMD das mehr gebracht hat.

[deekey777]

http://www.geeks3d.com/20100916/fp16-demotion-a-trick-used-by-ati-to-boost-benchmark-score-says-nvidia/
Nope, da vor sechs Jahren.

Wurde aber auch offiziell benutzt und zwar in Resident Evil 5. Und natürlich auf der Xbox360, https://www.beyond3d.com/content/articles/4/4

The ROP's can handle several different formats, including a special FP10 mode. FP10 is a floating point precision mode in the format of 10-10-10-2 (bits for Red, Green, Blue, Alpha). The 10 bit colour storage has a 3 bit exponent and 7 bit mantissa, with an available range of -32.0 to 32.0. Whilst this mode does have some limitations it can offer HDR effects but at the same cost in performance and size as standard 32-bit (8-8-8-8) integer formats which will probably result in this format being used quite frequently on XBOX 360 titles. Other formats such as INT16 and FP16 are also available, but they obviously have space implications. Like the resolution of the MSAA samples, there is a conversion step to change the front buffer format to a displayable 8-8-8-8 format when moving the completed frame buffer portion from the eDRAM memory out to system RAM.

Leider konnte das die R520er Generation nicht (nur INT10), sondern FP10 kam später in die PC-Welt (weil DX10-Bestandteil).

[-/\-CruNcher-/\-]

Nicht zu vergessen der Bezug zu Cheating ist heute ein ganz anderer was damals Cheating wird heute mehr als jemals zuvor aus HVS sicht betrachtet ;)

[Foobar2001]

Da hat man Rendertargets von 4xFP16 auf R11G11B10 (oder auch R10G10B10A2) gesetzt (und damit die Hälfte der Bandbreite gespart). Das war traditionell der Schalter "Surface Optimizations" im Treiber, keine Ahnung, ob es den noch gibt. Das hat eigentlich erstmal nicht so viel mit der Genauigkeit der eigentlichen Berechnungen im Shader zu tun (außer der Vermutung, daß wenn 10 Bit pro Komponente im Rendertarget als Ergebnis reichen, man vermutlich oft mit FP16 bei den Rechnungen auskommen dürfte [stimmt aber nicht immer]). Daß das bei nV nicht so viel brachte, liegt einfach an deren im Vergleich zu AMD traditionell schlechteren Performance der ROPs mit diesen Formaten (nur halfrate Blending, gewinnen dort also gegenüber FP16 nichts), während bei AMD das auch mit Blending Fullspeed geht (FP16 zwar auch, hängt dann bloß extrem an der Bandbreite). Bei den TMUs schwächelt dagegen AMD bei FP16 etwas (häufig wird ein Rendertarget ja auch wieder darüber eingelesen). Kurz, bei nV geht die benötigte Bandbreite runter, aber ebenso der ROP-Durchsatz bei Einsatz von Blending. Bei AMD benötigt man nur die halbe Bandbreite hält den ROP-Durchsatz aber oben (der nutzbare vergrößert sich) und verdoppelt den TMU-Durchsatz mit dem Format. Also vollkommen klar, daß AMD das mehr gebracht hat.
1. R11G11B10 ist auch heute noch sehr verbreitet in Verwendung. Alle neuen GPUs unterstuetzen es als Target-Format. Fuer den HDR-Buffer vor dem Tonemapping ist die Praezission ausreichend.
2. Alles was bei AMD auf FP16 expandiert wird in den TMUs ist half rate, also sehr wahrscheinlich auch R11G11B10.
3. Hier wird alles bunt durcheinander geschmissen. Was haben Rendertarget-Formate mit der ALU-Praezission zu tun?

[deekey777]

1. R11G11B10 ist auch heute noch sehr verbreitet in Verwendung. Alle neuen GPUs unterstuetzen es als Target-Format. Fuer den HDR-Buffer vor dem Tonemapping ist die Praezission ausreichend.
2. Alles was bei AMD auf FP16 expandiert wird in den TMUs ist half rate, also sehr wahrscheinlich auch R11G11B10.
3. Hier wird alles bunt durcheinander geschmissen. Was haben Rendertarget-Formate mit der ALU-Praezission zu tun?
Zu 3.:

Vor 7 Jahren hat ja ATI einen Vorversion versucht, da hat aber Nvidia von Betrug und nicht 100% Qualität geschrieben, schon damal könnte ATI zwischen 0-15% Leistungs Gewinn erzielen.

Das ist der richtige Ansprechpartner.

Und ja nicht vergessen:
In Q3A hat ATi damals auch gecheatet.

[Nakai]

FP16@SM60 (GP100): http://pc.watch.impress.co.jp/img/pcw/docs/1023/668/html/10.jpg.html
INT8@SM61 (GP10x): http://pc.watch.impress.co.jp/img/pcw/docs/1023/668/html/9.jpg.html

Das INT8-Zeug ist für DL sehr interessant. Ich hab da vor einiger Zeit ja eine Post verfasst, wie NV seine DL-TOPs schön rechnet. Deckt sich ziemlich genau mit dem.

[deekey777]

Wir haben anscheinend einen FP16-Hype. Einige fühlen sich in ihrer Ehre verletzt, weil die Scorpio aktuell keinen doppelten FP16-Durchsatz bzw. kein 2:1-Verhältnis beherrscht. Ihr wisst schon, was ich meine.

Reicht voellig fuer gaengige Lichtberechnungen. Die Vorteile sind riesig, fast doppelter Durchsatz und weniger Registerdruck. Wer das nicht verwendet, waere bloed.

Es gab vor zig Jahren eine Studie, wonach Wissenschaftler für ihre Simulationen durchgehend doppelte Genauighkeit nutzten, obwohl sie duch mixed precision bessere Leistung erhalten würden. Der Grund war einfach: Sie wollten keine Mehrarbeit. Für Konsolen wird man diese Mehrarbeit eher leisten, aber für den PC eher nicht. (Ich weiß, dass das zitierte Posting älter ist.)

Ist eigentlich treiberseitiges Shaderreplacement (noch) möglich, mit dem FP32-Shader durch FP16-Shader ersetzt werden?

[iuno]

Für Konsolen wird man diese Mehrarbeit eher leisten, aber für den PC eher nicht.

Ist eigentlich treiberseitiges Shaderreplacement (noch) möglich, mit dem FP32-Shader durch FP16-Shader ersetzt werden?
Die Mehrarbeit ist herauszufinden, wo fp16 reicht. Wenn das gemacht ist, gibt es doch keinen Grund das auf dem PC zu verwehren.
Und da alle Shader nach wie vor durch den Treiber muessen kann man auch von dort aus reinpfuschen.

[Nakai]

Ist eigentlich treiberseitiges Shaderreplacement (noch) möglich, mit dem FP32-Shader durch FP16-Shader ersetzt werden?

Aus meiner Sicht eher nicht, da man, um den doppelten Durchsatz zu erreichen, auf Vec2 FP16 Datentypen und zugehörige OPs zurückgreifen muss. Diesbezüglich müsste man große Teile des Shadercodes umschreiben. So einfach geht das nicht, aber für spezielle Shader sollte es tatsächlich wenig problematisch sein.

Ahja, nur weil AMD davon spricht nun doppelten FP16-Durchsatz zu erreichen. Man muss auch einen Haufen an zusätzlichen Instruktionen mitliefern.
NV hat für 4xINT8-Support auch Reduktions-Instruktionen mitgeliefert, welche zwei 4xINT8-Blöcke auf einen Wert aufaddieren.

[][immy]

Was ich aktuell nicht so ganz verstehe, macht das wirklich einen großen Unterschied aus?
Das mit dem doppelten Durchsatz am ende kann ich nicht so richtig glauben. Immerhin muss man sich dann auch ein paar Zusätzliche Dinge merken damit man am ende auch weiß ob es jetzt ein 16-bit oder 32-bit Ergebnis ist bzw. ob die werte das zuvor waren. Ich kann man gut vorstellen das dabei auch einiges an overhead produziert wird den man bei einer durchgehenden 32-bit Nutzung nicht hatte. Macht es am ende wirklich so viel aus das es sich lohnt?

[deekey777]

Doppelter Durchsatz entsteht, weil die PS4Pro (und Vega&GP100 und die ULP-GPUs) in einem Wisch 2 fp16-Intruktionen ausführen kann, dadurch entsteht die theoretisch doppelte Leistung der PS4Pro-GPU im Vergleich zu fp32. Ob man diesen theoretischen Wert erreichen kann, ist natürlich eine andere Frage.

So, wie ich es verstehe, geht es vielen eher um die Ersparnisse und freiwerdende Resourcen.

[gravitationsfeld]

Aus meiner Sicht eher nicht, da man, um den doppelten Durchsatz zu erreichen, auf Vec2 FP16 Datentypen und zugehörige OPs zurückgreifen muss. Diesbezüglich müsste man große Teile des Shadercodes umschreiben. So einfach geht das nicht, aber für spezielle Shader sollte es tatsächlich wenig problematisch sein.
Muss man nicht. Es reicht "half" statt "float" als Datentyp zu verwenden, den Rest erledigt der Compiler.

[danarcho]

Muss man nicht. Es reicht "half" statt "float" als Datentyp zu verwenden, den Rest erledigt der Compiler.
Das hat auch einen einfachen Grund (Ich bleib mal bei GCN):
Eine CU hat 64 "Shader-Einheiten", nur dass dieser Begriff wenig aussagt. Eigentlich besitzt eine CU 4 SIMD16-ALUs.
Jede dieser SIMD16-ALUs kann unabhängig Instruktionen ausführen. Die Instruktionen betreffen aber immer 64 Daten (eine Wavefront), egal ob Float, Double oder Half. Normale Float instructions werden entsprechend in 4 Takten ausgeführt (4 mal 16), danach die nächste Instruktion usw. Double instructions werden bei 1:2 in 8 Takten ausgeführt, ansonsten noch langsamer. Und jetzt ratet mal, wo der Trick liegt bei Float16.
Bei GCN3/4 werden Float16 Instruktionen auch nur in 4 Takten ausgeführt und eben das soll auf 2 Takte (2 mal 32) beschleunigt werden. An der Programmierung ändert sich vom Modell nichts (weiter SPMD) und so gesehen sind das auch keine packed instructions, die man irgendwo benutzen könnte.
Vektor-Datentypen bringen auch keinerlei Vorteile, da der Compiler nicht in der Lage ist, diese horizontal auf die SIMD-Einheiten zu bringen. Sprich: Vektoren werden sequentiell bearbeitet.

[gravitationsfeld]

Das ist nicht richtig. Double rate FP16 ist im Prinzip SIMT64 mit SIMD2 FP16-Instructions. Es sind 64 pairs in einer Wavefront. Die pair instructions muessen immer die gleiche Op fuer beide Haelften ausfuehren.

Die Latenz bleibt bei 4 Takten. Das geht auch nicht anders wegen Abhaenigkeiten mit der Skalar-Einheit und anderen Scheduling-Eigenheiten von GCN.

[danarcho]

Ach krass, danke!
Hast du eine Quelle, wo ich das mal nachlesen könnte?
Theoretisch bräuchte es dann aber schon wenigstens einen SLP pass im Compiler, um jeweils 2 gleiche Instruktionen zu finden. Und ganz kapier ich auch nicht, was für instructions da rauskommen sollen. Wenn die 64 Float16-pairs umsetzen, sind es ja doch packed instructions :confused:
Naja, ich warte mal auf die ISA docu.

[edit]
Vermutlich meinst du das hier: http://www.anandtech.com/show/11002/the-amd-vega-gpu-architecture-teaser/2
Aber so ganz eindeutig finde ich das noch nicht. Zumal der Text auch sagt, eine CU könnte jetzt schon 128 FP Ops ausführen... Da sind noch einige Fragen offen, aber das gehört eher in den Vega-Thread.
Wahrscheinlich wird einfach die Workgroup-Size erhöht um genügend gleiche Instructions zu finden oder AMD bringt FP16 intrinsics oder beides, who knows.
[\edit]

[deekey777]

Nächste id Tech setzt massiv auf FP16-Berechnungen (https://www.golem.de/news/id-software-naechste-id-tech-setzt-massiv-auf-fp16-berechnungen-1704-127494.html)

Die nächste Iteration der id-Tech-Engine soll mehr CPU-Kerne und erneut das Vulkan-API nutzen. Auch von FP16 möchte id Software Gebrauch machen, noch ist die Hardware-Unterstützung aber abseits von Sony Playstation 4 Pro gering.

[Hübie]

Die Begründung klingt für mich etwas hanebüchen:
Die Shader-Einheiten werden besser ausgelastet, da weniger Register-Speicher notwendig ist.

Der Registerspace ist eigentlich weniger das Problem, sondern, dass man zwei Ops auf eine FP32 ALU mappen kann. Man korrigiere mich wenn ich mich irre. ;)

[Locuza]

Register-Pressure scheint durchaus häufiger einen Flaschenhals unter GCN darzustellen.
https://image.slidesharecdn.com/gs-4106mah-finalfullversion-140131075645-phpapp01/95/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-32-638.jpg?cb=1391155201

Wie gewöhnlich bei "neuen" Entwicklungen muss man auf konkrete Zahlen warten, wie viel Performancezuwachs man von FP32 auf Single-Rate FP16 gewinnt und dann noch einmal von Double-Rate FP16.

[Simon]

Die Begründung klingt für mich etwas hanebüchen:


Der Registerspace ist eigentlich weniger das Problem, sondern, dass man zwei Ops auf eine FP32 ALU mappen kann. Man korrigiere mich wenn ich mich irre. ;)
Du bist korrigiert.
Paar Links:
https://www.microway.com/hpc-tech-tips/avoiding-gpu-memory-performance-bottlenecks/
http://docs.nvidia.com/cuda/maxwell-tuning-guide/ - Kapitel 1.4.2

Register allocation is one of the most critical parts of an optimizing com-
piler. Although a great effort has been put into researching how to allocate
registers, not much of it has been focused on vector registers. This report
seeks to find out what fundamentally new problems arise when allocating vec-
tor registers rather than scalar registers, how the previously known problems
change in vector registers and what methods can be used to tackle these issues.
http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8884733&fileOId=8884748


Das ist selbst auf CPUs ein Problem:
https://software.intel.com/en-us/articles/dont-spill-that-register-ensuring-optimal-performance-from-intrinsics

[gravitationsfeld]

Die Begründung klingt für mich etwas hanebüchen:


Der Registerspace ist eigentlich weniger das Problem, sondern, dass man zwei Ops auf eine FP32 ALU mappen kann. Man korrigiere mich wenn ich mich irre. ;)
Du irrst dich. Occupancy ist oft ein Problem.

Register-Pressure scheint durchaus häufiger einen Flaschenhals unter GCN darzustellen.
Bei jeder GPU.

[Hübie]

Danke euch für die Erklärungen und links. :up: Hab es versäumt das Abonnement zu aktualisieren, daher die späte Rückmeldung. Kam jetzt nur durch Vega auf die Idee hier zu gucken.
Gibt es denn verwertbare Zahlen zu normal und mixed mode in Spiele-Engines?

[HOT]

https://www.golem.de/news/id-software-naechste-id-tech-setzt-massiv-auf-fp16-berechnungen-1704-127494.html

schon älter, aber spannend.

[Hübie]

Siehe Post #66 ;D

[Entropy]

Register allocation is one of the most critical parts of an optimizing com-
piler. Although a great effort has been put into researching how to allocate
registers, not much of it has been focused on vector registers. This report
seeks to find out what fundamentally new problems arise when allocating vec-
tor registers rather than scalar registers, how the previously known problems
change in vector registers and what methods can be used to tackle these issues.
http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8884733&fileOId=8884748
Genau das verursacht mit FP16 Probleme für Compiler, Registerallokation muss paarweise passieren. (Jemand hier aus dem Forum wunderte sich weshalb Ich das nicht einfach dem Compiler überlasse.)
Für die beste Leistung ist die Organisation der Daten extrem wichtig. Der Schritt von NVidia und AMD von Vektoreinheiten hin zu skalaren ist zum Teil dem komplizierten Compilerbau geschuldet.

[gravitationsfeld]

FP16 ist da sogar gewissermassen schlimmer als die alten AMD-VLIW-Chips, weil es die gleiche Operation sein muss fuer beide Werte.

[deekey777]

Wolfenstein 2 und Doom mit FP16 (https://www.computerbase.de/2017-07/radeon-rx-vega-vorgestellt/3/)

AMD hat angekündigt, dass Wolfenstein 2: The New Colossus von id Software (erscheint im Oktober) das erste Spiel sein wird, das Rapid Packed Math und damit die FP16-Berechnungen von Vega 10 unterstützen wird. ...
Einen Ausblick, was FP16 in Spielen bringen kann, hat AMD anhand eines noch nicht veröffentlichen Serra genannten Tests vom 3DMark gezeigt, der eben auf FP16-Berechnungen setzt. Je nach Effect können durch Rapid Packed Math in dem Tests 20 bis 25 Prozent mehr Performance herausgeholt werden. Es gab auch ein Video von dem Test zu sehen, das die FPS-Steigerung bestätigt. Unter anderem sollen diverse Post-Processing-Effekte wie Bloom und die Beleuchtung durch FP16 profitieren können.


RPM ist aber nicht Vega exklusiv, oder?

[tEd]

Wolfenstein 2 und Doom mit FP16 (https://www.computerbase.de/2017-07/radeon-rx-vega-vorgestellt/3/)



RPM ist aber nicht Vega exklusiv, oder?

Ist nicht exklusiv.

[deekey777]

Ich klaue mal:

https://www.techpowerup.com/reviews/AMD/Vega_Microarchitecture_Technical_Overview/3.html

AMD has added supported for 8-bit operations back with NGCU, has retained the 16-bit floating point operations from Polaris and continued to maintain FP32 and FP64 operation support as well. One new feature here is Rapid Packed Math wherein multiple 16-bit operations can be handled simultaneously between 32-bit operations. If a task has some complex 32-bit operations where precision is key, nothing changes. However, if your application is not demanding on precision- for example, if it is a lighting effect or change from one to another- then you can use Rapid Packed Math to perform said operation as a 16-bit one thus taking up less resources and increasing performance throughput. AMD estimates a Vega NGCU to be able to handle 4-5x the number of operations per clock cycle relative to the previous CUs in Polaris. They demonstrate a use case of Rapid Packed Math using 3DMark Serra- possibly a yet unannounced Futuremark benchmark- wherein 16-bit integer and floating point operations result in as much as 25% benefit in operation count.

[tEd]

Ich klaue mal:

https://www.techpowerup.com/reviews/AMD/Vega_Microarchitecture_Technical_Overview/3.html

Mit nicht exklusiv meine ich das 2xfp16 Code auch in Zukunft so von anderen Grafikchips genutzt werden kann ohne das man diesen anpassen müsste ausser es werden Shader Intrinsics genutzt.

Im Moment unterstützen die Nvidia Consumer Karten 2xfp16 nicht. Volta Consumer Karten dann vielleicht aber schon.

[deekey777]

RPM auch für Far Cry 5: https://www.youtube.com/watch?v=LvRdKkc4bfk&feature=youtu.be

[Locuza]

[...]
RPM ist aber nicht Vega exklusiv, oder?
Gute Frage, Intel unterstützt Double-Rate FP16 seit Broadwell.

Wäre ugly wenn das dann so läuft wie bei Nvidia, wo Conservative Rasterization über exklusive APIs gelöst wurde, anstatt den DX11.3/12 Standard zu verwenden, teilweise verständlich um Windows 7/DX11 Vanilla Support zu gewährleisten, aber dafür ist andere Hardware auf ewig ausgeschlossen.

[Entropy]

Gute Frage, Intel unterstützt Double-Rate FP16 seit Broadwell.Echt? Wie kann man das ansprechen?

RPM ist aber nicht Vega exklusiv, oder?PowerVR und NVidia X1 haben RPM schon seit ein paar Jahren.

[Locuza]

Echt? Wie kann man das ansprechen?
[...]
Seite 8:
In each EU, the primary computation units are a pair of SIMD floating-point-units (FPUs).
Although called FPUs, they support both floating-pointand integer computation.
These units can SIMD execute up to four 32-bit floating-point(or integer) operations, or SIMD execute up to eight 16-bit integer or 16-bit floating-point operations.
The 16-bit float (half-float) support is new for gen8 compute architecture.

https://software.intel.com/sites/default/files/Compute%20Architecture%20of%20Intel%20Processor%20Graphics%20Gen8.pdf

Andrew Lauritzen der damals bei Intel noch gearbeitet hat (Jetzt bei EA bei der SEED-Gruppe) hat folgenden Kommentar noch genannt:
Yes, it's 2x FP16 rate with no limitations that I know of in terms of getting full FP16 MAD throughput. Unlike Imagination however you do need instructions to convert FP32<->FP16 (I think Maxwell does as well?) so you will lose some efficiency on mixed precision math.
https://forum.beyond3d.com/posts/1818215/

Und Gen 9 hat den FP16 Support etwas erweitert:
16-bit floating point capability is improved with native support for denormals and gradual underflow.
https://software.intel.com/sites/default/files/managed/c5/9a/The-Compute-Architecture-of-Intel-Processor-Graphics-Gen9-v1d0.pdf

Über gängige APIs wie DX und OpenCL kann man FP16 verwenden.
Bei Skylake (Gen 9) und vermutlich Broadwell (Gen 8) wurde FP16 allerdings nicht unter DX12 unterstützt, bei DX11.X meldete der Treiber brav Support, vielleicht unterstützen neuere Treiber jetzt auch unter DX12 FP16, wobei ich das nicht verfolgt habe.


Bezüglich Gen 9 gibt es einen Artikel mit Performance-Werten für Bildbearbeitungsalgos:
http://www.sisoftware.eu/2017/04/14/fp16-gpgpu-image-processing-performance-quality/


Allgemein sind die Intel iGPUs extrem spannend vom Featureset.
Kohärent eingebunden im Ring mit einem gemeinsamen Last-Level-Cache.
Die Architektur kann unterschiedliche SIMD-Breiten verwalten, ab Gen 9 explodiert das Teil förmlich von den möglichen Funktionen, wie double-rate FP16, ein viertel FP64-Rate , voller DX12 Support, welcher erst jetzt bei AMD mit Vega erscheint und vermutlich bei Nvidia mit Volta.
Darüber hinaus wird sogar noch nativ MSAA x16 unterstützt.
Das AF ist auch seit Ivy-Bridge Referenz.
Die Tessellation-Performance war zu Fermi oder Kepler Zeiten als ich Ergebnisse dafür gesucht habe, sogar gleich wenn nicht besser, als bei Nvidia.

Man kann sich ehrlich fragen, was Intel mit dem ganzen Zeug bei iGPUs will. :freak:
So extrem overengineered für die Anwendungszwecke, kein Wunder das die perf/mm² so schlecht ausfällt.

[aufkrawall]

Das AF ist auch seit Ivy-Bridge Referenz.

Ist schlechter als NV HQ und außerdem brutal teuer.
Zudem bringt es Intel fertig, dass die Serious-Engine mit Vulkan noch langsamer läuft als mit dem ohnehin schon extrem lahmen OGL-Pfad. Auch alle anderen Spiele laufen mit LL-API langsamer. Grafikfehler kommen dann noch dazu.
Auf dem Papier hauen einen die Features um, in der Praxis sind es aber lahme Krüppel. Was da in den Release Notes für die Treiber immer an Grafikfehlern für alle möglichen Titel aufgeführt wird, spricht auch Bände.

[gravitationsfeld]

Das ist aber definitiv der Treiber. ANV auf Linux hat diese Probleme ja anscheinend nicht?

[x-force]

Man kann sich ehrlich fragen, was Intel mit dem ganzen Zeug bei iGPUs will. :freak:
So extrem overengineered für die Anwendungszwecke, kein Wunder das die perf/mm² so schlecht ausfällt.

wahrscheinlich ist das treiber team nicht annähernd so fähig wie das team, das den igp entworfen hat.

ich denke mit den treibern schießt sich intel auch nur selbst ins bein.
bei der igp liegt noch einiges an potential brach. liest sich wirklich toll, aber leider bis auf quicksync und desktop für fast nicht zu gebrauchen.

[aufkrawall]

Bei deinem vkquake waren mir unter Linux gleich drei Fehler sofort aufgefallen.
Obs den Fehler mit Fusion nur unter Windows gab, weiß ich nicht mehr. Unter Windows lief aber nicht mal der DX11-Pfad mit Skylake fehlerfrei.
Und bei CS:GO kostete AF mehr als höchste vs. niedrigste Shaderdetails.

[Locuza]

Ist schlechter als NV HQ und außerdem brutal teuer.
Zudem bringt es Intel fertig, dass die Serious-Engine mit Vulkan noch langsamer läuft als mit dem ohnehin schon extrem lahmen OGL-Pfad. Auch alle anderen Spiele laufen mit LL-API langsamer. Grafikfehler kommen dann noch dazu.
Auf dem Papier hauen einen die Features um, in der Praxis sind es aber lahme Krüppel. Was da in den Release Notes für die Treiber immer an Grafikfehlern für alle möglichen Titel aufgeführt wird, spricht auch Bände.
Ich habe am Rande mitbekommen, dass unter DX9 es sichtlich mehr geflimmert hat, als unter DX10+ Spielen und das man das AF auf Balanced stellen sollte, da es scheinbar sonst zu aggressiv wirkt.

Keine Ahnung wie intensiv du dich mit den Einstellungen beschäftigt hast, im Internet finde ich nicht viel und ich selber habe keine Intel iGPU.

Leider hat sich intern bei Intel scheinbar etwas stärker verändert, Interessen und Personal sind nicht mehr die gleichen.
Nach Broadwell gab es nur noch eine BGA SKU mit der GT4e Lösung bei Skylake mit dem Skull Canyon Nuc und Kaby-Lake war ein simpler Refresh und Coffee-Lake stellt auch nur einen Refresh dar, wobei natürlich 2 CPU-Kerne mehr deutlich sinnvoller sind.

Intel hatte noch Kooperationen mit Spieleentwicklern bezüglich Just Cause 3 (DX11.3) und F1 2015 mit Conservative Rasterization und ROVs, aber das ist intern nicht über Tests hinausgegangen und Intel scheint die Bemühungen beendet zu haben.

Schade, dass hatte Potential und gerade die neuen Rendering-Features haben mir gefallen.

[deekey777]

Gute Frage, Intel unterstützt Double-Rate FP16 seit Broadwell.


Echt? Wie kann man das ansprechen?

PowerVR und NVidia X1 haben RPM schon seit ein paar Jahren.
Ich meinte das anders. Ich dachte, RPM sei ein Sammelbegriff für die (native) Nutzung von FP16 und AMD diese Tools/Bibliothek/wasauchimmer nur für Vega bietet, da AMD FP16-Fähigkeiten nur auf Vega demonstriert.

[Entropy]

...
Man kann sich ehrlich fragen, was Intel mit dem ganzen Zeug bei iGPUs will.
Danke, für den ausgiebigen Post!
ich würde annehmen, da die iGPU auch auf Cherry Trail verwendet wird, das es hauptsächlich auf Mobile abzielt, da es dort gängig ist einfach den ganzen Shader in half zu bauen. Die Entscheidung dafür ist bestimmt vor mehr als 5 Jahren gefallen, als es für Intel noch relevant war.



Und bei CS:GO kostete AF mehr als höchste vs. niedrigste Shaderdetails.Für AF brauchst du nunmal größere Mipstufen der Texturen. Bei bis AF4 hast du 4 mal den Bandbreitenverbrauch, bis AF16 hast du 16 mal.

Da iGPUs auf dem Hauptspeicher arbeiten, hast du bestenfalls ~20 GB/s zur verfügung, deswegen sind die Chancen sehr hoch, dass du einfach Bandbreitenlimitiert bist.
EDRAM sollte auch nicht viel bringen bei AF, weil die Textureinheiten vermutlich schon auf den Hauptspeicher ausgelegt sind.

[Locuza]

Ich meinte das anders. Ich dachte, RPM sei ein Sammelbegriff für die (native) Nutzung von FP16 und AMD diese Tools/Bibliothek/wasauchimmer nur für Vega bietet, da AMD FP16-Fähigkeiten nur auf Vega demonstriert.
Ich denke man kann RPM = Rapid Packed Math nur als double-rate FP16 verstehen, wo zwei FP16 Operationen in einem Schwung ausgeführt werden und in ein Register gespeichert.
So etwas beherrscht nur AMDs GCN Gen 5 (Vega) und Intels Gen 8 (Broadwell).

[aufkrawall]

Ich habe am Rande mitbekommen, dass unter DX9 es sichtlich mehr geflimmert hat, als unter DX10+ Spielen und das man das AF auf Balanced stellen sollte, da es scheinbar sonst zu aggressiv wirkt.

Keine Ahnung wie intensiv du dich mit den Einstellungen beschäftigt hast, im Internet finde ich nicht viel und ich selber habe keine Intel iGPU.

Ich hatte mir für die Beurteilung nur den Filtertester angeschaut, wo die mitgelieferte ground2-Textur meist schnell aufschlussreich ist. afair ließ sich im Treiber die Filterung nicht verbessern.


Für AF brauchst du nunmal größere Mipstufen der Texturen. Bei bis AF4 hast du 4 mal den Bandbreitenverbrauch, bis AF16 hast du 16 mal.

Da iGPUs auf dem Hauptspeicher arbeiten, hast du bestenfalls ~20 GB/s zur verfügung, deswegen sind die Chancen sehr hoch, dass du einfach Bandbreitenlimitiert bist.
EDRAM sollte auch nicht viel bringen bei AF, weil die Textureinheiten vermutlich schon auf den Hauptspeicher ausgelegt sind.
Gibts für die IGP gegenüber der CPU noch eine Einschränkung bez. der Bandbreite? Die CPU nimmt der GPU im krassen GPU-Limit ja zumindest durch die niedrige Auslastung nicht noch zusätzlich nennenswert etwas weg.
Der 6700k hat hier eine Bandbreite von ~55GB/s zur Verfügung.

Die IGP hatte ich btw. bei 1280x1024 betrieben. Hitman mit niedrigsten Details: DX11: ~17fps; DX12: 15fps. :freak:

[gravitationsfeld]

Niedrige Aufloesung aendert daran nichts nennenswertes am ALU-zu-Mem-Verhaeltnis. Alle IGPs sind massiv Speicherbandbreiten-Limitiert.

Die CPU-Requests blocken die IGP-Transfers zusaetzlich durchaus, weil Speichercontroller in Bursts arbeiten muessen. Selbst auf den Konsolen ist das ein Problem.

[Locuza]

Intel hat das schöne Design, dass die CPU und GPU gemeinsam einen Last-Level-Cache als Back-Up besitzen, bevor Anfragen zum Speicher wandern.
Bei den AMD Konsolen gibt es keinen gemeinsamen Cache und somit eine Cache-Stufe weniger, entsprechend wird auch der Memory-Controller häufiger bedient.

----

Und ein wenig offtopic, *hust*, FP16. :redface:
In den Fußnoten gibt AMD ja an, wie viel FPS bei Serra von Futuremark erreicht werden, einmal mit FP16 und einmal mit FP32:
FP32: 44 FPS
FP16: 50 FPS (+ 13,6%)
https://i.imgur.com/wmKVMV3.jpg

[dargo]

Guter Fund.

Das bitte dann aber nicht vergessen. :wink:

Results may very upon release of final produkt and final drivers.


Edit:
Da fällt mir gerade ein der eine AMD Typ sprach ja schon im Video, dass im neuen 3DMark RPM 15% mehr Leistung bringt. Diese Werte von AMD sind sicherlich aufgerundet. Für 15% reicht nämlich schon das --> 50,3 vs. 43,7. :wink:

[deekey777]

Dieser Folienausschnitt findet sich auch im Vega-Thread. Vielleicht steht aber dieser User bei dir auf der Ignore. :ulol:

[Entropy]

Gibts für die IGP gegenüber der CPU noch eine Einschränkung bez. der Bandbreite? Die CPU nimmt der GPU im krassen GPU-Limit ja zumindest durch die niedrige Auslastung nicht noch zusätzlich nennenswert etwas weg.
Die Priorität ist
1. Video Controller (also was mal D/A Wandler war). Das ist immerhin 0,5 GB/s bei 1080p und 2 GB/s bei 4k, 10% der Bandbreite.
2. CPU Instruction-Fetch
3. CPU Data-Fetch
4. GPU Fetches
Das ist schlicht nach Sensibilität sortiert.

Der 6700k hat hier eine Bandbreite von ~55GB/s zur Verfügung.Laut Intel (https://ark.intel.com/products/88195/Intel-Core-i7-6700K-Processor-8M-Cache-up-to-4_20-GHz) sind es 34GB/s.
Ich denke, in den meisten Fällen wo iGPUs benutzt wird, steckt auch kein Hochleistungsram drinnen.

Entwickler optimieren auch nicht auf iGPUs, oder in den seltensten Fällen. Dass Intel FP16 nun doch offen anbietet wuste ich nichtmal, und ich war einer der ersten der damit rumspielen durfte. Auf Konsolen war es gängig die Daten möglichst klein zu halten, viele Spiele wurden mit FP16 oder sogar 8 Bit Vertexdaten (z.B. für Position) entwickelt.

Vielleicht wird FP16 wieder wichtiger, falls AMD leistungsfähige APUs liefert. 2TFlop/s bzw 4 in Halfs würde viele Konsolenports Spielbar machen, wenn die Bandbreite stimmt.