Nvidia Titan X - LG 27GN950-B - 120Hz und 10Bit-Farbtiefe

Drewkev schrieb:
aber wo hast du diese Zahl her?
Der Rechner bietet hier leider nur die Anzeige für HDMI an und keine 120 Hz (weil damals offenbar noch nicht im VESA Standard). Entsprechend haben 2x60 Hz die gleiche Bandbreite wie 120.

1658748241272.png

https://www.extron.de/product/videotools.aspx

EDIT: Über den Basis Modus sind doch 120 Hz auswählbar. 120 Hz scheinen für CVT Reduced Blanking nicht spezifiziert zu sein.

1658748499243.png
 
Zuletzt bearbeitet:
Wenn Ihr Tipps für eine geeignete Graka habt, dann könnt Ihr es gerne mitteilen.
Zumindest denke ich, dass sie HDMI 2.1 oder 2.2 und DisplayPorts mit 1.4a unterstützen sollte.

Muss leider los.
Schaue später wieder rein. Danke.
 
cvzone schrieb:
Allerdings halten sich viele Karten oder Monitore technisch nicht 100% an irgendwelche Standards. Das führt ja immer wieder zu Verwirrung im Forum. "XY kann dies und jenes nicht, obwohl die Bandbreite laut Standard reichen sollte..."
Ich kann zwar nicht mit Sicherheit sagen, wie exakt die Hersteller die Spezifikationen implementieren, aber hier werden wieder die Video-Timings vergessen. Eine Auflösung hat keine Fixe Bandbreite. Es gibt Video-Timings die schaffen UHD@120 innerhalb der HBR3 Bandbreite und die meisten können es eben nicht. Dazu gibt es zu den Monitoren so schöne Tabellen mit "Horizontal Frequency" daraus kann man auf die Video Timings schließen und dann weiß man ob es passt oder nicht.

Ich kann zwar auch nicht ausschließen, dass ein GPU Treiber eine bestimmte Kombination absichtlich blockiert, aber bisher lag alles was ich in diesem Forum an Limits gelesen habe noch an Features oder der Bandbreite. Man muss nur präzise genug sein.
Drewkev schrieb:
32Gbps? Ich will deine Expertise keineswegs anzweifeln
Das ist mit Encoding Overhead drauf und deshalb irrelevant. Wenn man die 8b/10b Enkodierung abzieht landest du auch bei den bekannten ~25Gbit/s. Die sollte man auch verwenden, da es für Thunderbolt relevant ist. Und wesentlich sinnvoller, sont enthalten die angeblichen "Displaybandbreiten" noch Variablen, wie welche Generation von welchen Anschluss es betrifft. Das sollte man immer vorher rausrechnen...
Ergänzung ()

@cvzone Der hier bietet deutlich mehr:
https://tomverbeure.github.io/video_timings_calculator

Und im LTT Forum gibt es noch einen der einen weniger mit den verschiedenen Varianten vollspammt. Aber ich finde das gerade praktisch um aus der Horizonal-Freq. den Timing-Standard zu extrapolieren.
Ergänzung ()

1658749007422.png

Aus dem im LG Manual angegeben 3840x2160 bei 214.563kHz, bei 95Hz können wir schließen, dass der Monitor CVT-RB nutzt (zumindest in dieser Auflösung).
Und dann können wir ablesen, dass das zusammen mit 4:2:2 sogar noch locker mit HBR2 machbar ist. Mit RGB 8 Bit noch mit HBR3.
Für 120Hz hingegen (immer noch CVT-RB) sind wir bei 102% von HBR3 weshalb das nicht geht...
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: cvzone
Ray519 schrieb:
Das ist mit Encoding Overhead drauf und deshalb irrelevant4. wenn man die 8b/10b Enkodierung abzieht landest du auch bei den bekannten ~25Gbit/s.
Danke Dir.

Kannst du das kurz erläutern und warum wäre das irrelevant? Ich hatte mich immer über diese Abweichung gewundert und mich bisher nicht mit den Video Timings im Detail beschäftigt, auch wenn ich z.B. mit CRU soweit gut klar komme.
Ergänzung ()

Ray519 schrieb:
Mit RGB 8 Bit noch mit HBR3.
Würde in dem Falle aber bedeuten, die Titan X macht kein HBR3, sonst würde es ja möglich sein. Oder wie wäre das zu verstehen?
 
Klar. Wobei der 25 <-> 32 GBit/s Unterschied sogar gar nichts mit den Videotimings zu tun haben. Ich vereinfache mal ein wenig: :

32Gbit/s ist was physikalisch über das Kabel geht. Da 4 Adernpaare also 4x 8.10 Gbit/s. Oder anders jedes Adernpaar läuft auf ~8GHz (die digitalen Signale zumindest).
1658749180017.png


Wir wollen / müssen aber sicherstellen, dass die Leitung ein neutrales Potential hat (genau in der Mitte der Pegel). So dass man nur minimal Energie braucht um die gesamte Leitung unter den Schwellwert um "0" zu erkennen zu ziehen. Oder umgekehrt nur minimal Energie braucht um die Leitung über den Schwellwert für "1" anzuheben.

Wenn wir aber zufällig ein Signal hätten, dass 1s lange nur "1" enhält, dann wäre die Leitung nicht mehr im durschnitt "neutral". Um das sogenannte DC-Balancing zu erreichen gibt es jetzt verschiedene Encoding-Verfahren.

8b/10b ist sehr weit verbreitet aber auch schon gut alt. Für alle 8 Bit Nutzdaten werden damit 10 Bit physikalisch Übertragen. So braucht man nicht alle möglichen Kombinationen von 10 Bit, sondern nur solche, die nicht zu Einseitig nur 0en oder 1en Enthalten.
Man hat also so ziemlich auf jeder schnelleren Leitung immer einen Encoding-Verlust. Mit DP 2.0 wird dies zB auf von PCIe (ab irgendeiner Version, 2.0 oder 3.0) und Thunderbolt bekannte 128b/132b angehoben.

Damit wird zB nur noch 3% der Bandbreite an Encoding verloren anstatt den 20% von 8b/10b. HDMI 2.1 FRL nutzt aber ein anderes schlechteres Encoding...
 
  • Gefällt mir
Reaktionen: cvzone
Danke Dir. Meine Ausbildung zum IT Systemelektroniker ist 20 Jahre her und ich arbeite seit 18 Jahren in einem anderen Beruf, daher bin ich da etwas raus. Die Begründung verstehe ich. :)
 
Videotimings dagegen sind eigentlich in Pixeln angeben. Zum Monitor werden nicht nur die dargestellten Pixel übertragen, sondern auch "Blanks".
Historisch lässt sich das zB mit Röhrenmonitoren erklären. Der Elektronenstrahl scannt bei denen von Links Oben, Zeile für Zeile das Bild ab. Dabei benötigt der Strahl aber Zeit um vom rechten Ende des Monitors zurück zum Linken zu kommen (H-Blank). Und nochmal mehr Zeit um von Rechts Unten noch Links Oben zurück zu kommen (V-Blank).

Mit LCDs etc ist das aber physikalisch nicht mehr so begründet. Aber wir nutzen die Blank-Intervalle zB um Audiodaten oder HDR-Metadaten zu übertragen. Deshalb hat HDMI zB nach dem normalen CEA Standard deutlich längere Blanks. Aber es gibt eine Reihe Formate (CVT-Reduced Blanking, CVT-RB2) die extra Bandbreite sparen. Bei LCDs üblich ist mittlerweile CVT-RB, mit HDMI CEA für Standard-Auflösungen. Komplett Custom ist aber auch möglich.

Diese Blanks werden immer noch in Pixel gezählt, so dass man eine Pixel-Clock hat (typisch in MHz), eine Frequenz mit der Pixel übertragen werden.
Videotimings geben nun an, wie viele Pixel davon zu einem Frame gehören und zu einer Zeile. Und wo die sichtbaren Pixel in einer Zeile Anfangen (die Blanks verteilen sich auf vor und nach der Zeile).

Deshalb kann man mit der Zeilenfrequenz / HFreq, typisch in kHz meist rausfinden welcher Standard hintendran steckt.

Edit:
Ein Beispiel aus meinen EDID-Daten:
Code:
Detailed Timing Descriptors:
DTD 1:  3840x1600   59.993961 Hz  12:5     99.350 kHz    397.400000 MHz (880 mm x 367 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   48 Vpol N

Für die finale Bandbreite muss man alle Teile zusammenrechnen. Wobei sich auch mir nicht mehr erschließt, was die exakten Anforderungen an Sync (ein spezifischer Zeitpunkt in den Blanks) ergibt. Aber letztendlich erkennt der Monitor hier Flanken im Signal um die Pixel-Clock und Zeilenfrequenz aus dem Signal zu extrahieren. Zumindest bei HDMI werden nämlich den Displays die Auflösungen etc nicht angekündigt (zumindest nicht das ich wüsste), sondern die Quelle fängt einfach an Dinge zu senden. Und das Display muss aus den Frequenzen erkennen, was das jetzt für ein Format ist und wie das darzustellen ist.
Deshalb kann man vllt auch leicht an den Blanks drehen mit Tools wie CRU oder Custom Resolutions im Treiber und knappe Dinge immer noch hinbekommen. Aber irgendwann kommt der Monitor nicht mehr mit und dann bleibt es schwarz.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: cvzone
Ray519 schrieb:
Deshalb kann man vllt auch leicht an den Blanks drehen mit Tools wie CRU oder Custom Resolutions im Treiber und knappe Dinge immer noch hinbekommen.
Da hatte ich genau ein Problem. Mit 4K120 Hz gibt es ja mit AMD öfter das Problem mit hohem Idle Speichertakt, welches eine andere die Blanking Lines Einstellung im Rahmen positiv beeinflussen kann.

Beim LG C9 hat der TV dann einfach angefangen die Lines vom unteren Bildschirmrand einfach wieder oben darzustellen, wenn die BR zu hoch war...
 
Zuletzt bearbeitet:
Zum LG 27GN950-B habe ich nun im Benutzerhandbuch auf den letzten 2 Seiten die Werte gefunden.

Link zum Manual:
https://www.manualslib.de/manual/737479/Lg-Ultragear-27Gn950.html?page=31#manual

Auszug:
Auflösung - Horizontal Frequenz (kHz) - Vertikal Frequenz (Hz) - Polarität - Anmerkung
3840 x 2160 | 214,563 | 95 | +/- | DisplayPort 1.4 (DSC*) / DisplayPort 1.4
3840 x 2160 | 274,438 | 120 | +/- | DisplayPort 1.4
3840 x 2160 | 320 | 144 | +/- | DisplayPort 1.4 (DSC*)
3840 x 2160 | 355 | 160 | +/- | DisplayPort 1.4 (DSC*) ([Overclock] [Ein])
 
Die hatte ich auch schon in #23 zitiert. Deshalb komme ich zu dem Schluss das 95Hz 8Bit RGB bei dir noch gehen muss. Falls nicht hast du vermutlich an irgendeiner Stelle ein Limit auf HBR2 Geschwindigkeit (auch gerne DP 1.2 genannt) drin.
Aber 10 Bit geht entweder nur mit Chroma-Subsampling oder maximal bei 60Hz.
 
Unter der NVIDIA-Systemeinstellung steht bei Auswahl von 95 Hz "YCbCr422 und 8Bit" drin. RGB kann man nicht auswählen.
Wie gesagt, die Schriften an den Desktop-Symbolen sind dabei stark kantig und irgendwie nicht ganz rein weiß. Vielleicht gewöhnt man sich aber im Laufe der Zeit daran.

Im Menü des Monitors unter "Spiel Modus" kann man z.B. HDR Effekt oder sRGB einstellen. Zum normalen Arbeiten werde ich mir wohl ein Preset erstellen.
Bei 60 Hz sind die Schriften der Desktop-Symbole sauberer und rein weiß dargestellt.
 
James007 schrieb:
Wie gesagt, die Schriften an den Desktop-Symbolen sind dabei stark kantig und irgendwie nicht ganz rein weiß.
Das ist genau was Chroma Subsampling macht.
Und wie gesagt, dann limitiert dich noch irgendwas anderes auf HBR2 Geschwindigkeit mit diesem Monitor.

Weil 95 Hz + 8 Bit RGB ist nur 79% Auslastung des Anschlusses. Den einzigen Grund dir RGB nicht anzubieten sind eigentlich dass Kabel oder Monitor die Geschwindigkeit nicht schafft.
 
Zuletzt bearbeitet:
Das ist interessant.
"...Kabel oder Monitor die Geschwindigkeit nicht schafft."

Wie verstehe ich, dass der Monitor ggf. die Geschwindigkeit nicht schafft, welche von der Graka übertragen wird?

Kann mir eigentlich nicht vorstellen, dass das mitgelieferte DisplayPort-Kabel des Monitors dies nicht schafft. Dann würde es überhaupt nicht im Sinne des Monitor-Herstellers sein.
 
James007 schrieb:
Kann mir eigentlich nicht vorstellen, dass das mitgelieferte DisplayPort-Kabel des Monitors dies nicht schafft.
Sollte nicht der Fall sein. Und wie ich bereits erwähnt hatte, die Monitor-Einstellung dazu.
Ansonsten wäre es immer noch irgendwas merkwürdiges wie ein Bug. Wie gesagt ich bin mir aufgrund der Zahlen ziemlich sicher dass es gehen müsste. Die 95Hz alleine ist ja schon eine sehr ungewöhnliche Zahl. Die kommt garantiert daher dass damit irgendein Limit irgendeiner Art gerade so unterboten wird. Sonst wäre 100Hz viel typischer.
 
Ggf. mal die Einstellungen des Monitors im Onscreen Display durchschauen. Manchmal kann man die Version des Eingangs einstellen. Wenn man hier zw. DP 1.2 oder 1.4 wählen könnte, würde dies einiges erklären.
 
Im Monitor-Menü kann man unter "Allgemein" die DisplayPort-Version einstellen:
1.4 (DSC) | 1.4 | 1.2
(Steht aktuell auf 1.4)

Im User-Manual der "Nvidia GeForce GTX Titan X" steht folgendes:

- DisplayPort 1.2 Certified, DisplayPort 1.3/1.4 Ready: Drive the latest
DisplayPort panels with support for resolutions up to 4096x2160.

- HDMI3: Support for HDMI includes 4K resolution at 60 Hz, GPU-accelerated
Blu-ray 3D support, x.v.Color, HDMI Deep Color, and 7.1 digital surround
sound.
 
Sorry. Ich meinte, dass ich die Graka schon in meinem Computer vorhanden ist und den Monitor erworben habe.

Nun habe ich mich entschieden in den nächsten Tagen eine passende Graka für den Monitor zu bestellen. Diese wird DisplayPorts 1.4a und HDMI 2.1 Anschlüsse besitzen.
 
Nein, dass ist nicht der Plan.
Bin noch am recharchieren!
Wahrscheinlich eine 3080er. Aber welche, dass wird sich noch zeigen.
 
Zurück
Oben