News Kooperation mit MediaTek: Nvidias teures G-Sync-Modul wird überflüssig

Sternengucker80 schrieb:
Es war trotzdem einfach nur Standard im NB Bereich.
Dort hat es aber nur funktioniert, weil bei Notebooks keine Scaler eingesetzt werden und keine Signalübertragung per HDMI / DP notwendig ist. Das Display ist quasi direkt am VRAM der GPU angeschlossen. Deswegen kann die GPU das auch direkt kontrollieren. Außerdem wurde das auch nur genutzt zum Strom sparen, aber nicht für variable Frameraten beim Spielen.


Das besondere an der GSync war, das über die normale HDMI/DP Strecke zu ermöglichen. Und das war eben nicht so einfach.

Man muss eben neben dem Protokoll auch die Monitor, bzw. Scalerhersteller ins Boot bekommen - oder den Scaler selbst machen.


Mal ne Challenge an Euch.

Nehmen wir an, AMD hatte die Idee wirklich zuerst, oder sie wäre so offensichtlich gewesen, wie ihr es hinstellt, und der Standard stand schon in den Startlöchern.

Dann müsste man ja annehmen, dass bei NVidia ein paar Leute saßen und sich folgenden Gedanken hingegeben haben:

"Hey, wir wissen, dass es jetzt einen VRR Standard geben wird, der auf allen Monitoren läuft. Aber wir werden das nicht unterstützen, statt dessen stecken wir mal einfach viel Geld in eine eigene Lösung, für die die Anwender eigene Monitore kaufen müssen und die nur mit unseren GPUs läuft. Damit machen wir sicher viel viel Geld!"


Oder ist es eventuell wahrscheinlicher, dass es eher so gelaufen sein könnte, dass NVidia zu einem Zeitpunkt, als Freesync / AdaptiveSync am Desktop PC noch nicht mal als Idee existierte, folgendes dachte:

"Cool, VRR am PC, das gibt's noch nicht! Aber ei, wie kriegen wir das auf die Straße? Ein offener Standard ist doof, dann haben wir selbst ja nix davon außer Arbeit. Warum dann den Aufwand? Aber wenn wir uns die Monitore selbst bauen (oder deren Scaler) - damit würde das nur mit unseren eigenen GPUs funktionieren, wir etablieren einen eigenen, proprietären Standard und die Leute haben noch mehr Gründe unsere GPUs zu kaufen...! Und das Geld für die Entwicklung ist schnell wieder drin mit Zinsen und Zinseszinsen!"

und AMD das rechtzeitig spitz kriegt und dann sagt:

"Hm, das geht ja mal gar nicht, die arbeiten an noch einem Feature, das wir nicht haben! Aber so einen Chip zu entwickeln um mitzuhalten ist uns einfach zu teuer. Lass uns doch besser die Monitor-Hersteller und VESA überzeugen, dass sie das in einen Standard aufnehmen. Das kostet uns gar nix und NVidia können sich ihr teures Produkt in den Arsch stecken und die Investition abschreiben!".


Ganz ehrlich. Welche Variante ist wahrscheinlicher?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: autopilot
Du unterstellst hier Sachen, für die du keine beweise hast.
Ein Standard dauert halt bis der definiert ist. Da sind viele dran beteiligt. Und nicht nur amd. Das vesa Konsortium beinhaltet auch Nvidia.
Und Nvidia hat auch den neuen (suboptimalen) Steckerstandard mit dem Konsortium zusammen erarbeitet. Das dauert einfach seine Zeit.
Zu unterstellen, dass das aus Niedertracht gemacht wird ist an den Haaren herbeigezogen.
Denn in beiden Fällen sind genug andere Parteien beteiligt, die kein Interesse daran haben sich für sowas einspannen zu lassen.

Das ist absurd. Und in keinster Weise kannst du dafür Argumente, Quellen, Indizien geschweige den Beweise liefern. Du behauptest das einfach mal.

So ein Kindergarten Niveau haben weder Nvidia, AMD oder Intel nötig.
Und die haben es au chi erst Recht nicht nötig, dass Leute für sie sowas erzählen.
 
  • Gefällt mir
Reaktionen: ShiftC, jo0, Dai6oro und 5 andere
Ich bin mal gespannt, wie Mediathek und NVIDIA die Sache implementieren, welche Vorteile es gegenüber den heutigen Lösungen bringt und ob es Einschränkungen gibt für Menschen ohne NVIDIA Grafikkarte.
Bis mehr Informationen da sind, halte ich mich mit Vermutungen zurück - besonders mit Anschuldigungen auf Basis der heutigen GSync Lösungen.


@Grestorn

Ich verstehe deine Argumente immer noch nicht. Die Tatsache, dass NVIDIA seine Lösung auf den Markt gebracht hat und diese verkauft hat, zeigt doch, dass niemand etwas torpediert hat. Es gab einfach mit FreeSync und Q-Sync (Qualcomm) und MotionPro (Apple) und VRR (HDMI) und AdabtiveSync (DisplayPort) weitere Lösungen am Markt.
Wenn du Dinge behauptest, dann liefere doch bitte mal ein paar Nachweise.

Grestorn schrieb:
Ganz ehrlich. Welche Variante ist wahrscheinlicher?
Wahrscheinlicher auf Basis von was. Von Fakten? Oder von deiner "Meinung"?
Ich kann dir jetzt genauso zwei Geschichte erzählen mit wilden Anschuldigungen und dann am Ende fragen: Entscheide dich zwischen meinen beiden Geschichten - welche ist wahrscheinlicher?

Und dann stellst du einfach ein paar Annahmen auf, verpackt diese in schöne Geschichten ohne Nachweise, die die eigene Meinung unterstützen und schaut, "was man wahrscheinlicher findet". Deine anekdotische "Wahrheit" ist ja noch nicht mal eine Meinung, da sie nicht auf Fakten beruht. Ansonsten beleg doch erstmal, dass AMD die Idee "geklaut" hat und NVIDIA "torpediert hat", wie du es behauptet hast.

Und ich finde es echt schade, dass du dich auf der vorherigen Seite selbst als Opfer darstellst so à la "man darf seine Meinung nicht sagen" und "andere Meinungen sind hier nicht gerne gesehen". (Dein Beitrag davor).
Darfst du doch. Hast du auch. Wurde nicht gelöscht oder verschoben. Und andere diskutieren mit dir und haben eine andere Meinung. Ist eigentlich ein ziemlich cooles Konzept, wenn man es einmal verstanden hat.
 
  • Gefällt mir
Reaktionen: CadillacFan77, jo0, edenjung und 3 andere
Was genau ist der Unterschied zwischen dem extra Modul und der compatible Variante?

Hab einen älteren Monitor mit extra Modul: G-Sync flickert (also unbenutzbar). Der neue Monitor hingehen ist nur "compatible" aber funktioniert viel besser, ohne flicker und andere Probleme?
 
@aLanaMiau
Bei VRR gab es bei den ersten Monitoren noch diverse Probleme. Überwiegend bei den FreeSync Modellen, weil es keinen Zwang zur Einhaltung der Vorgaben gab und so haben viele Monitorhersteller Bugs und Unsinn implementiert. Dass das auch mal bei einem GSync Monitor passiert, ist also möglich.
Mein Stand ist, dass das heute kein so großes Problem mehr ist. Es gibt mittlerweile genug Erfahrungen mit der Technik und die Monitorhersteller von "Gaming-Monitoren" nehmen das Thema mittlerweile ernst - wird ja auch getestet von Influencern & co.
 
Grestorn schrieb:
Dort hat es aber nur funktioniert, weil bei Notebooks keine Scaler eingesetzt werden und keine Signalübertragung per HDMI / DP notwendig ist. Das Display ist quasi direkt am VRAM der GPU angeschlossen. Deswegen kann die GPU das auch direkt kontrollieren. Außerdem wurde das auch nur genutzt zum Strom sparen, aber nicht für variable Frameraten beim Spielen.
Im VRAM landen keine fertig berechneten Bilder. Das ist der Framebuffer und auch der könnte nicht direkt auf ein Display ausgeben. Im Notebook geht es in der Regel vom Framebuffer zu einem eDP Controller und dann bei eDP Verbindung zum Scaler des Displays (macht die ganze Ansteuerung).

eDP konnte sowas deutlich früher, genau aus den Energiespargründen. Einen scaler gibt es allerdings nach wie vor. Hier hat NVIDIA auch von Anfang an G-Sync ähnlich wie bei Fernsehern als Software für Marktübliche Scaler angeboten und nicht ihren eigenen Scaler (G-Sync Modul) verbaut.
 
  • Gefällt mir
Reaktionen: edenjung
Das kann man hier einfach aufgeben🤷🏻. AMD, hat es früher einfach anderst rum gemacht. Soweit ich weiß, war Intel zuerst mit SpeedStep im Notebook. ( Stromsparen) War glaub ich beim P3, für's Notebook. AMD, hat das ganze auf den Desktop ausgeweitet mit dem Athlon 64?. Oder war das schon früher? Einer hat eine Idee, einer erweitert das, wer hat hat dadurch Vorteile? Yes, genau wir Ideoten, die den Mist kaufen😜🤣😋. Ich weiß echt nicht, wie man sich beschweren kann, etwas kostenlos dazu zu bekommen, eventuell etwas schlächter, aber kostenlos! Ist ja das gleiche Drama, wie mit DSSL/ FSR und wie der ganze Mist heißt. Ja, es ist nicht ganz so gut, aber dafür läuft es mit Uralt Hardware und dann auch noch Hersteller unabhängig 😜. Ja, das ist ja wirklich eine Strafe😂😂😂😂 Wie kann man nur🤔
 
Vieles von denen wurde und wird überflüssig. Die ganze Firma ist auch überflüssig haha
 
Es wird einfach viel zu viel durcheinander geworfen. Inklusive dem Artikel der G-Sync und FreeSync als "Technik" darstellt.

In Wahrheit ist das aber eine ganze Kette an Features. Wir brauchen Software-Support um das ganze mit dem Spiel/OS/Programm zu organisieren. Wir brauchen Treiber Support evtl. mit Heuristiken um zu entscheiden wie man etwas am besten mit dem Bildschirm darstellt. Man braucht ein Protokoll um das ganze zum Monitor zu kommunizieren und wie der Monitor überhaupt sagt was er kann. Es braucht Hardware und Software im Monitor um das ganze korrekt umzusetzen.

FreeSync und G-Sync sind VOR ALLEM Marketingbegriffe für die gesamte Kette wie ein Hersteller das geplant hat und evtl. zertifiziert.

Was für die Kompatibilität erstmal wichtig ist ist nur das Protokoll. Wenn GPU und Monitor eine Überlappung in unterstützten Protokollen haben, dann geht VRR. Und VRR ist erstmal nur das Prinzip einer Variablen Refresh Rate.

An Protokollen gibt es:
  • G-Sync Proprietär. Ausgestorben. Aktuelle G-Sync Module können das noch. Aber nur für Kompatibilität mit Maxwell (900) oder älteren Nvidia GPUs die noch kein Adaptive Sync konnten
  • FreeSync über HDMI. Proprietär. Von AMD ausgedacht, nicht öffentlich. Am aussterben, weil es parallel zu HDMI VRR ist, was erst wesentlich später kam.
  • Vesa Adaptive Sync. Das Protokoll VRR über DP zu machen.
    • Offen, für jedes Vesa Mitglied erhältlich.
    • Kann NVidia seit 1000er / Pascal.
    • Kann Intel seit 11th gen / Xe.
    • Kann AMD seit Anfang von FreeSync.
  • HDMI VRR. Das ganze vom HDMI Konsortium. Auch für HDMI Lizenznehmer nutzbar. Eingeführt mit HDMI 2.1.
    • Kann NVidia seit 3000er / Ampere. Seit sie "HDMI 2.1" Ports haben.
    • Kann AMD seit RX6000. Seit sie "HDMI 2.1" Ports haben. Allerdings zu beginn noch eingeschränkt. So dass die GPU Softwareseitig nur FreeSync HDMI mit Monitoren machen wollte.

G-Sync Module haben schon vor langer Zeit (mein AW3821DW konnte das schon. Alles was neuer ist sollte das mindestens auch können) Adaptive Sync und HDMI VRR. Trotz der limitierten HDMI Datenrate geht HDMI VRR mit G-Sync Modulen. Und weil die Adaptive Sync sprechen kann man alle Vorteile des G-Sync Moduls (Flicker und artefaktfreies VRR von 1-max HZ) nutzen mit jeder GPU die Adaptive Sync kann.

Nvidia bundelt seit Anfang an weitere Features mit in den Marketingbegriff. Meistens sind diese Features ganz klar im Monitor (wie variables Overdrive, HDR Farbkalibrierung) oder auf der GPU Seite wie GPU-seitiges Frame-doubling. Und die meisten Features sind nicht irgendwie eingesperrt. Variables Overdrive macht der Monitor einfach. Er muss nur über ein Protokoll das er versteht überhaupt VRR bekommen.

Seit der 1000er Reihe können Nvidia GPUs Adaptive Sync und seit 3000er auch HDMI VRR. Das einzige was die nicht können ist FreeSync HDMI.
AMD kann alles außer das alte G-Sync, das man überhaupt nicht mehr braucht.

In beiden Fällen wird von Reviewern das Protokoll oft nicht klar vom Marketing getrennt und es ist schwer zu sagen, ob ein "G-Sync" beworbener Monitor jetzt neu genug für HDMI VRR und Adaptive Sync ist oder ob ein "FreeSync" Monitor noch den alten FreeSync HDMI Mist nutzt.

Und dann gibt es auch ab und an wieder neue Features obendrauf wie die End-To-End Latenzmessung von Nvidia die eigentlich technisch mit VRR rein gar nichts zu tun hat und halt den Nvidia Treiber als Software und die passenden Gegenstücke im Monitor braucht (USB Snooping, Bild-Änderungen messen).

engineer123 schrieb:
Ist es jetzt immer noch proprietär?
Kann es immer noch nur von NV Grakas genutzt werden?
Seit Jahren können G-Sync Module im Monitor auch alles was offen ist.

JMP $FCE2 schrieb:
Der Grafikkartentreiber nutzt dann <48 fps Frame Doubling, was das G-Sync-Modul im Prinzip auch macht.
Das weiß man nicht exakt. Der Vorteil es im Monitor zu machen ist, der Monitor kann das selbst entscheiden und weiß am besten was als Flackern sichtbar wäre. Da kommen viele Probleme mit billo VRR Displays her. Das klassische VRR Flicker wenn die Refreshrate stark schwankt.
Auf der anderen Seite weiß die GPU eher ob das nächste Frame rechtzeitig fertig wird und kann damit evtl. einen Ticken schlauer reagieren. AMD hat mit der Variante angefangen, weil dann konnte man das meiste im Treiber machen. Und jetzt klappt es immer nur zusammen mit einem guten Monitor. Wie Nvidia angefangen hat wissen wir nicht exakt, weil wir beim proprietären G-Sync nicht wissen was auf der GPU gemacht wurde und was im Modul. Alle halbwegs modernen Module machen aber alles im Modul, weshalb sie genauso problemfrei auf Intel und AMD GPUs gehen.

blackiwid schrieb:
Ich soll also von nem Monitorhersteller nen Monitor kaufen wo Hardware die darin ist mich am hindern dieser Hardware nutzt wenn ich mich für ne AMD Grafikkarte entscheiden habe...
Schnittstellen sind das wichtige. Und die Kritik ist viel zu abgehangen, weil beide Hersteller auf offene Protokolle übergegangen sind und alles was neu kommt mit VRR hat keinen Grund etwas eigenes zu machen. Die ganzen Probleme kommen nicht vom Protokoll sondern von wie der Monitor gebaut ist und die GPU entscheidet. Was man kritisieren sollte, ist das beide Hersteller an ihren Zertifikaten festhalten und nicht sinnvoll dokumentieren, was die Protokolle sind die sie können. Die können die Zertifikate gerne haben. Hat ja auch einen Mehrwehrt. Aber das sollte obendrauf kommen auf "kann Standard XYZ".

Hier profitieren vermutlich beide Hersteller davon. Weil sie für die Zertifikate Geld bekommen können und die Kunden besser gebunden bleiben, weil sie glauben proprietäre Hardware zu haben. Und man lügt ja nicht, wenn man das nur nicht klarstellt und möglichst viele Features bündelt ohne aufzuschlüsseln welche davon "proietär" sind und welche nicht.

edenjung schrieb:
Hmm nutzt Nvidia nicht bei ihren Laptops VRR? Vermarktet das aber als g-sync?
VRR ist nur die Kategorie, das Prinzip. Keine Technik und kein Protokoll. Das Protokoll war hier von Anfang an Adaptive Sync. Ohne Scaler hat die GPU hier schon länger direkte und mehr Kontrolle weshalb man keinen Scaler gebraucht hat, der das auch passend umsetzt.

Wechhe schrieb:
AMD hingegen hat es so implementiert, dass es über den offen verfügbaren HDMI/DisplayPort Standard klappt, der allen zur Verfügung steht.
Wie oben erwähnt, nur Teilweise. FreeSync HDMI wird dabei gerne unterschlagen und ist nicht weniger proprietär als das alte G-Sync. Und scheint den Problemberichten mit so manchen TVs als HDMI 2.1 neu war durchaus noch mehr Relevanz zu haben. Auch weil AMD eine Generation länger gebraucht hatte um HDMI VRR zu können. Und hat noch länger an ihrem propriäterem Protokoll festgehalten.

Und dann noch der HDR Kram dazu. Ich habe noch nicht klar herausgefunden wie sinnvoll das war (also ob klarer Vorteil für das Ergebnis oder nur Hack um es für sich einfacher zu machen). So oder so stirbt es aus, HDMI VRR macht das ganz normal mit sauberer Trennung.

blackiwid schrieb:
Wenn Gsync und Freesync zu absolut identischen Ergebnissen führt wozu ist es dann drin?
Beides sind nur Zertifikate die dir Mindestgarantien geben wenn du die gesamte Kette zertifiziert hast. Es gibt unterschiedliche Niveaus.

Und weiterhin, die Features aus den Zertifikaten die ausschließlich im Monitor sind (die meisten was die Ausgabe angeht), gehen auch mit allen anderen GPUs genauso. Da Nvidia mit ihren Modulen 95% im Monitor gemacht haben, eben auch entsprechend problemfrei.

Während der klassische nicht-Nvidia Weg eine Kombination erfordert. Der Monitor kann nur bis zu zB 48Hz runter und der GPU Treiber muss Frames verdoppeln um das einzuhalten. Und der GPU Treiber muss raten, ob diese 48Hz eine Grenze sind, bei der der Monitor kein Flackern hat oder schon deutlich sichtbar ist und die GPU eigentlich schon bei 70Hz anfangen sollte zu verdoppeln.

Die verschiedenen Hersteller haben unterschiedliche Policies wann sie verdoppeln. So kommt es dann das ein Monitorhersteller den Monitor nur mit einer GPU testet die Frames immer nach einem gewissen Schema verdoppelt. Und die andere GPU verhält sich anders und der Hersteller hat nicht getestet, dass der Monitor dann spinnt und flackert zB.

Bei Intel zB kann man auswählen, ob die Frames verdoppelt werden sollen, wann auch immer es geht oder nur wenn es notwendig ist. Hat beides vor und Nachteile und manche Monitore können das eine, manche das andere besser (G-Sync Modulen ist es egal).
Und gerade mit den Zertifikatsprogrammen ist es auch gut möglich, dass die GPU Treiber intern Profile haben, wie sie mit bestimmten zertifizierten Monitoren umgehen für das beste Ergebnis. Die offiziellen Daten die ein Monitor hergibt sind jedenfalls in Adaptive Sync und HDMI VRR sehr spärlich. Die untere Refreshrate Grenze ist dort eine harte Grenze. Und alles bis dahin hat einwandfrei zu gehen, sonst lügt der Monitor.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Gnarfoz, Hoebelix, ShiftC und 7 andere
Ray519 schrieb:
Der Monitor kann nur bis zu zB 48Hz runter und der GPU Treiber muss Frames verdoppeln um das einzuhalten. Und der GPU Treiber muss raten, ob diese 48Hz eine Grenze sind, bei der der Monitor kein Flackern hat oder schon deutlich sichtbar ist und die GPU eigentlich schon bei 70Hz anfangen sollte zu verdoppeln.

Ich habe jetzt den zweiten G-Sync-kompatiblen Monitor, einmal inoffiziell und einmal offiziell. Bei beiden hat der NV-Treiber unterschiedliche Umschaltpunkte gewählt, und beide waren nicht identisch mit der unteren Bereichsgrenze.

Das spricht stark dafür, dass der Treiber den Wert entweder separat vom Monitor geliefert bekommt, oder eine interne Liste mit Monitormodellen und passenden Umschaltpunkten verwendet.
 
Ray519 schrieb:
Beides sind nur Zertifikate die dir Mindestgarantien geben wenn du die gesamte Kette zertifiziert hast. Es gibt unterschiedliche Niveaus.
Wenn das stimmen würde, was dann auch Nvidia Schuld hat, da sie das proprietäre GSync mit dem gleichen Namen vermarkten wie das "offene"... wie soll man das unterschieden.

Stellt sich die Frage wozu es eine Kooperation braucht, hat Mediathek dann mit Intel und AMD auch eine Kooperation von der hier nicht berichtet wird, oder behandelt Mediathek diese ohne Kooperation gleich wie Nvidia? Dann stellt sich die Frage wozu die Kooperation?

Der Artikel suggeriert auch sogar in der Überschrift das diese Kooperation bzw der Chip von Mediathek "das teure Gsync Modul" überflüssig macht. In der Hinsicht das man das Modul nimmer braucht ist es doch auch heute schon überflüssig, es ist aber nicht überflüssig um das alte proprietäre GSync zu implementieren.

Wenn das stimmen sollte ist der ganze Artikel Clickbait, aber es stellt sich immer noch die Frage wozu die ne Kooperation brauchen wenn Intel und AMD (nehm ich mal an) keine solche Kooperationen haben?

Btw stimmt auch deine Auflistung nicht, du sprichst von Freesync HDMI aber was ist mit normalem Freesync wieso listest du das nicht auf, da das HDMI Konsortium AMD verboten hat unter Linux VRR mit HDMI zu supporten, wird man für Gaming Zwecke zumindest wenn man VRR will eh zwingend auf Displayport setzen müssen.
 
blackiwid schrieb:
Wenn das stimmen würde, was dann auch Nvidia Schuld hat, da sie das proprietäre GSync mit dem gleichen Namen vermarkten wie das "offene"... wie soll man das unterschieden.
Ja haben sie. Habe ich ja versucht zu beschreiben.

blackiwid schrieb:
Stellt sich die Frage wozu es eine Kooperation braucht,
Mein Vermutung: evtl Algorithmen zB für das variable Overdrive, andere IP für die Implementierung wie die G-Sync Module es bisher mit FPGAs gemacht haben. Und die noch proprietären Teile wie zB die Latenzmessung.

Und dann überwacht, so dass Nvidia sagen kann, jeder der den Chip verwendet, ist quasi 90% für G-Sync Ultimate zertifiziert, wie es bisher mit dem Modul auch war. (Edit: aber halt mit modernerem, energieeffizienterem Chip).
blackiwid schrieb:
Modul nimmer braucht ist es doch auch heute schon überflüssig,
Jedes Feature dass das kann (bezüglich VRR, ich glaube die integrierte Latenzmessung zB mit Nvidia, kann man nicht ohne Nvidia Hardware haben). Aber die Features die es hat implementiert es zuverlässig und zur Perfektion. Aber wenn die durchschnittliche Qualität von nicht zertifiziertem Kram steigt gibt es weniger Wille für ein teures Zertifikat zu bezahlen. Erst recht wenn es nur sehr wenige, limitierende Hardwarekonfigs gibt (Eingänge, DSC, HDMI FRL).
blackiwid schrieb:
es ist aber nicht überflüssig um das alte proprietäre GSync zu implementieren.
Ja. Aber wie viele Leute haben noch eine 900er Karte und wollen einen High-End VRR Monitor mit HDR etc. Die 900er Karten konnten noch kein richtiges HDR über DP.

Aber klar, hier wäre ein Vorteil für Nvidia Kunden. Wie bei Apple. Das was Inhouse mit Inhouse Marken beworben wird bleibt rückwärtskompatibel und "funktioniert" für den Nutzer gleich, auch wenn sich die Hardware und Technik untendrunter wesentlich ändert.

blackiwid schrieb:
wenn Intel und AMD (nehm ich mal an) keine solche Kooperationen haben?
Die eine Hälfte habe ich schon oben beantwortet. Die andere ist, dass AMD bisher nichts so vergleichbar konkretes im Monitor hatte. AMD hat ja auf GPU-seitiges Framereplizieren gesetzt. Gibt also keinen Bedarf das einem Monitor zu geben. Weil die Logik die AMD vorsieht ist in ihrer GPU und Treibern. Hauptsächlich Nvidia stellt Hardware für Monitore her die bis 1Hz runter geht, ohne das die GPU involviert sein muss (wie weit man runter gehen sollte kann man auch debattieren. Mein Intel iGPU will zB nicht unter 20Hz. Aber 35Hz kann schon tauglich sein je nach Situation. Und es geht mit G-Sync Modul halt unabhängig von der GPU).

blackiwid schrieb:
du sprichst von Freesync HDMI aber was ist mit normalem Freesync wieso listest du das nicht auf,
Was? Ich habe doch gesagt "FreeSync" ist genauso zu 99% ein Zertifikat wie modernes "G-Sync". Das Protokoll hinter "FreeSync" ist Adaptive Sync über DP und entweder FreeSync HDMI oder HDMI VRR über HDMI Kabel. Und der proprietäre Teil ist legacy und ist am und muss aussterben. Genauso wie proprietäres G-Sync was weniger eine Rolle spielt, weil soweit ich weiß alle HDR-fähigen G-Sync Module schon die offenen Standards können.
blackiwid schrieb:
da das HDMI Konsortium AMD verboten hat unter Linux VRR mit HDMI zu supporten,
Nein. Meinem Verständnis nach hat AMD keine Erlaubnis erhalten Teile vom HDMI 2.1 Standard von ihrer Implementierung öffentlich zu machen. Das behinhaltet unter anderem HDMI VRR, aber auch FRL.
Wobei wir keine genauen Details wissen was das Problem war. Ob der Quellcode zu nahe an den HDMI Specs war, so dass das HDMI Forum das als veröffentlichung des Standards werten würde oder andere extrem bürokratischen Hürden hat.
Ergänzung ()

JMP $FCE2 schrieb:
Das spricht stark dafür, dass der Treiber den Wert entweder separat vom Monitor geliefert bekommt, oder eine interne Liste mit Monitormodellen und passenden Umschaltpunkten verwendet.
Sehr spannend. Danke dafür. Du könntest die EDID Infos ansehen. Denn dort sollte drin stehen was der Monitor angibt. So war es für HDMI VRR, originales G-Sync und FreeSync HDMI. Ich habe gute Erfahrungen mit dem Linux Tool "edid-decode" gemacht. Das zeigt alles außer den Inhalt der alten G-Sync Extension schön an (das scheint aber auch mehr ein Marker zu sein. Gab ja auch nicht viel Auswahl)
Dumpen kann man zB mit CRU (Export als .bin Datei), aber es zeigt längst nicht alle Eigenschaften (insbesondere Adaptive Sync nicht) an und erst recht nicht gut lesbar.

allgemein HDMI 2.x Dinge, auch FRL & DSC
Code:
 Vendor-Specific Data Block (HDMI Forum), OUI C4-5D-D8:
    Version: 1
    Maximum TMDS Character Rate: 600 MHz
    SCDC Present
    VRRmin: 2 Hz
    VRRmax: 120 Hz

Nur auf DP Eingängen. Und sowohl bei AW3418 (altes Modul, kein Adaptive Sync) und AW3821 (Ultimate Modul, HDMI VRR & Adaptive Sync) gleicher Inhalt.
Code:
 Vendor-Specific Data Block (NVIDIA), OUI 00-04-4B:
    01 01

Code:
Display is continuous frequency
[....]
 Display Range Limits:
      Monitor ranges (Bare Limits): 1-144 Hz V, 246-246 kHz H, max dotclock 990 MHz

Code:
 Vendor-Specific Data Block (AMD), OUI 00-00-1A:
    Version: 2.1
    Minimum Refresh Rate: 40 Hz
    Maximum Refresh Rate: 120 Hz
    Flags 1.x: 0x00
    Flags 2.x: 0x00
    Maximum luminance: 0 (50.000 cd/m^2)
    Minimum luminance: 0 (0.000 cd/m^2)
    Unknown: 0x00 0x00

Von verschiedenen gemischten Monitoren. FreeSync HDMI habe ich zB nicht sondern hier über das Forum erhalten.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Grestorn
Korrekt, das ist auch der Grund warum am Monitor/TV Freesync (wenn einzelnen aktivierbar) mit HDMI 2.0 Quellen an, mit HDMI 2.1 aber aus geschaltet sein muss. Ein "Fehler" denn ich schon öfter bei verschiedenen TVs bzw. deren User gesehen habe.
Sternengucker80 schrieb:
Apple, hat auch nie was erfunden! Si
Auf wessen Basis hat Apple denn den M1 "geklaut"? Du bist da einem riesen Skandal auf der Spur :freak: .
 
Ray519 schrieb:
Nein. Meinem Verständnis nach hat AMD keine Erlaubnis erhalten Teile vom HDMI 2.1 Standard öffentlich zu machen. Das behinhaltet unter anderem HDMI VRR, aber auch FRL.
Wobei wir keine genauen Details wissen was das Problem war. Ob der Quellcode zu nahe an den HDMI Specs war, so dass das HDMI Forum das als veröffentlichung des Standards werten würde oder andere extrem bürokratischen Hürden hat.
Ich weiß nicht entweder bist du kein Entwickler oder dein Glaube oder irgendwas informiert deine Fähigkeit etwas zu interpretieren aber das ist ein extremer Reach mindestens.

Wenn eine Spezifikation raus gegeben wird, wird entweder gar kein Coder oder nur Pseudocode raus gegeben also nichts was man direkt kopieren könnte und kompilieren.

Und es gibt auch nicht viele Variationen, wenn der Monitor C erwartet muss man A B C machen um dann Ergebnis D zu bekommen. Das was du implizierst wäre das sie irgend ein Beispielcode gegeben hätten und AMD die selben Variablennamen oder so was verwendet hätte, nicht das das irgendwie wichtig wäre aber das könnte und hätte AMD ganz sicher geändert.

Nein was mir praktisch 100% sicher aber wenn ich mich auf deine wilde Spekulation einlasse 1000x wahrscheinlicher halte ist das jede Implementation des Standards als Opensource für sie fälschlicherweise das "veröffentlichen des Standards" wäre. Es gibt auch keinerlei Hinweise oder irgendwas das dies nicht der Fall ist und AMD nur irgendwie bisschen was ändern müsste und es dann ginge, dann hätte AMD das längst getan.

Das einzige was du argumentieren könntest ist das wenn sie quasi alles irgendwie in der Firmware machen und dann 1% als Software so ne art "hardware-start-vrr()" aufruft und die dann alles macht, das diese Seite dieser Wrapper dann Opensource sein könnte aber das wäre dann immer noch faktisch 100% proprietär und so ne Firmware selbst wenn man wollte was niemand wollen kann bei AMD ein zu bauen geht nicht von heute auf morgen und schon gar nicht rückwirkend.

Du klingst hier so bisschen wie nen Anwalt fürs Consortium, wie könnte man das was gesagt würde so interpretieren das sie unschuldig sind... nicht was ist plausibel.
 
blackiwid schrieb:
Wenn eine Spezifikation raus gegeben wird, wird entweder gar kein Coder oder nur Pseudocode raus gegeben also nichts was man direkt kopieren könnte und kompilieren.
Klar. Habe ich auch nicht gemeint.

Aber wenn die Spezifikation ein großes Flowchart hat oder ein Algorithmus und du das ziemlich direkt in C-Code übersetzt, könnte ich mir vorstellen das manch übereifriger Anwalt auf den Gedanken kommen könnte und sagt: das ist so nah am Inhalt der Spec dran, dass wir das als Veröffentlichung sehen, wofür keine Lizenz existiert.

Und ich schreibe ja, wir wissen es nicht genau. Wir wissen AMD Entwicklern war klar, dass da irgendwo Probleme auftreten könnten. Und sie haben einen nicht-öffentlichen Entwurf gemacht einer Implementierung. Sind damit zum HDMI Forum gegangen im Sinne von "hey, das ist was wir euch versucht haben zu erklären. So würde das aussehen. Geht das jetzt klar?" Und die Antwort war "nein". Und sie akzeptieren dass erstmal. Also irgendeine rechtliche Handhabe muss da existieren.


Und abgesehen davon habe ich Dinge am Rand deiner Ausssage kritisiert. Wie zB, dass das doch kein Verbot sein wird. Sondern eher dass es außerhalb von dem ist, was normal erlaubt ist. Und deshalb brauchen die Entwickler eine explizite Erlaubnis. Und da fällt mir nur ein, dass es um das veröffentlichen von irgendwelchen Dingen geht.
Weil was sonst gehört dem HDMI Forum für das sie Erlaubnis erteilen können.

Und dass es nicht nur VRR war, sondern der gesamte HDMI 2.1 Standard.

Und ich finde so Zitate vom AMD Entwickler wie
We have the basic functionality up and running, now we have to go through each of the features with legal and determine if/how we can expose them while still meeting our obligations.
Just to set expectations, as I stated earlier, what we can ultimately expose is dependent on legal review.
The HDMI Forum has rejected our proposal unfortunately. At this time an open source HDMI 2.1 implementation is not possible without running afoul of the HDMI Forum requirements.
passen zu meiner Interpretation. Das es irgendwie um die Veröffentlichung von Details die am Standard hängen ging. Auch wenn wir nicht wissen wie oder was genau.

Edit: Noch besser. Besagter Entwickler verweist als Erklärung auf folgenden Phoronix Artikel der so ziemlich zu meiner initialen Beschreibung passt.
 
Ray519 schrieb:
Aber wenn die Spezifikation ein großes Flowchart hat oder ein Algorithmus und du das ziemlich direkt in C-Code übersetzt, könnte ich mir vorstellen...
Aber ich sehe kein Weg das zu umgehen wenn man sich nicht an das Flowchart hält wird der Treiber schlicht nicht funktionieren.

Es ist einfach so das wenn man es quelloffen implementiert ist für jeden Ersichtlich wie es funktioniert. das kannst du so oder so schreiben statt If irgendwo eine when abfrage benutzen oder was auch immer... es bleibt ersichtlich wie es funzt.

Auch denk ich nicht das die Idee ist das "man es nach programmieren" kann oder irgendwas sondern das man den Code oder irgendwas nutzen kann um damit Flime zu kopieren, was offensichtlich wenn du auf irgend ne Torrent Webseite gehst auch ohne das geht.

Es ging dann vielleicht 1% einfacher für den Schnösel daheim... darum geht. Es geht nicht darum das das Konsortium Spielern es schwerer machen will zu spielen es geht halt um Hollywood das derer scheiß nicht kopiert wird... (was er wie gesagt eh wird, aber halt vielleicht noch ein bisschen einfacher).

Ansonsten gäb es auch keinerlei Gründe das Geheim zu halten.
 
Wechhe schrieb:
NVIDIA ist auch nicht auf die Idee gekommen. Wie du selbst sagst - VRR gab es schon vorher.

Doch, Nvidia ist auf die Idee gekommen, denn bis dahin nicht in Desktop Monitoren genutzten Standard VRR mit einem eigenen Scaler in den Monitore zu bringen.

AMD hatte bis dahin keinerlei solche Ansätze und hat dann nur schnell reagiert und konnte dank VRR auch etwas bringen.

Ohne Nvidias Umsetzung gebe es in Desktop Monitoren kein AdaptivSync.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: autopilot und Grestorn
Ich kann aus eigener Erfahrung sagen das G-Sync im gegensatz zu Free-Sync viel weniger Bildflackern hat während Ladebildschirmen und auch während der Nutzung von HDR. Ich habe beispielsweise bei Elden Ring den AW3423DW (G-Sync) mit dem AW3423DWF (Free-Sync) verglichen. Sofort fiel mir bei HDR auf das der DWF deutlich erkennbar am flackern war (war mit Free-Sync aus nicht der Fall), vor allem bei dunklen Szenen wohingegen der DW ein perfekt ruhiges Bild hatte. Auch hat sich der DWF nicht so flüssig angefühlt wie die G-Sync Variante.

Ich würde daher NVIDIA Nutzern immer zu G-Sync raten. Das ist in meinen Augen Free-Sync deutlich überlegen.
 
  • Gefällt mir
Reaktionen: autopilot
Shinigami1 schrieb:
Ich habe beispielsweise bei Elden Ring den AW3423DW (G-Sync) mit dem AW3423DWF (Free-Sync) verglichen
Mit welchen GPUs? Wenn du nur eine Nvidia GPU hast, dann ist für FreeSync halt „First Generation Freesync“ zum Einsatz gekommen und nicht das vom Monitor unterstützte Premium Pro.
 
Zuletzt bearbeitet:
Zurück
Oben