[Sammelthread] Offizieller AMD [[ RX6700 // RX 6700XT // 6750XT // X6800 // 6800XT // 6900XT // 6950XT]] Overclocking und Modding Thread [[ Wakü - Lukü - LN2]]
- Ersteller xXx-Eagleone-xXx
- Erstellt am
@Holzmann: Entspann dich, hast ja recht. Wenn du ein Video machen willst, dann natürlich freiwillig. 
AMD kann nur künftige Treiber ändern, nicht existierende. Selbst wenn die's vermasselt haben, muss UL das Problem irgendwie lösen. Die können ja auch schlecht alle Treiber von z. B. 21.9.1 bis 21.11.1 vom Ranking ausschließen.
Bis dahin ist hier wohl Benchpause. Ich hab jedenfalls kein' Bock auf den Aufwand, wenn ein tolles nächstes Ergebnis nicht mehr beklatscht, sondern schief angesehen wird. 😕
AMD kann nur künftige Treiber ändern, nicht existierende. Selbst wenn die's vermasselt haben, muss UL das Problem irgendwie lösen. Die können ja auch schlecht alle Treiber von z. B. 21.9.1 bis 21.11.1 vom Ranking ausschließen.
Bis dahin ist hier wohl Benchpause. Ich hab jedenfalls kein' Bock auf den Aufwand, wenn ein tolles nächstes Ergebnis nicht mehr beklatscht, sondern schief angesehen wird. 😕
Zuletzt bearbeitet:
Sorry, i went too fast. This is the bit for the Overdrive Features on the first tab. It is a 32bit value, and the bits are shifted by the SMU_11_0_7_ODFEATURE_... values. The 1 is just notation, if you know the bit is shifted by n bits, you know where to write a 1 or a 0 to activate/deactivate the named feature. That is what the check buttons on tab 1 do.
..and again, too fast. The overdrive features are bytes, not bits. That would be the PPT features. But it is basically the same, the position where to write a 1 or 0.
Sorry, dass ich das jetzt nochmal hoch hole, war ne Runde spazieren: Ich kann natürlich nur für mich sprechen, aber für mich ist jeder Score legit, bevor jemand berechtigte(!) Zweifel anmeldet und das auch belegen kann. @snakeeyes hat sich selber bei UL gemeldet, wo ist also das Problem? Ganz im Gegenteil: Ich sehe das als sehr positiv.
Was weleh hingegen bei OCN schreibt: "Offenbar wurden auch bei weiteren Luxx Scores der Bug ausgenutzt" Achja? Bei welchen denn? Belege? Hinweise? --> Keine, also vermutlich doch nur ne leere Behauptung respektive Bullshit. Den Post hatte er auch geschrieben, bevor @Devcom seinen, später wieder gelöschten, Score hochgeladen hat.
Wir als Team-LUXX und in diesem Fall vor allem auch ihr als HOF-6900xt-Bencher sollten über so einem Blödsinn stehen. Darüber hinaus ist unsere Diskussion hier öffentlich für jeden einsehbar, jeder kann teilnehmen und der Großteil der Leute postet doch sogar seine kompletten Settings, wo manch anderer ein großes Geheimnis draus machen würde. Mehr Transparenz geht doch fast nicht.
So, fertig gemeckert.
Eigentlich sollte man das vergessen, außer du redest vom SOC 🤔
Es existieren +30 aktive sensoren, aufgeteilt in 4-5 stages des throttlings
Vermeer's core range geht über 1.55v durch FIT tolleriert und über 1.68v im OC_Mode (auch durch FIT, welcher sich nicht komplett deaktiviert) tolleriert
Der maximale wert liegt weitaus höher im confidential Berreich
FIT-PRE throttle voltage (meistens dual CCD units triggern das), liegt je nach sample zwischen 1.45 und 1.5v
FIT-VID Boost cap liegt allerdings bei 1.4v und tiefer
Jeder kern welcher über 1.4v VID requested innerhalb momentanen "zuu strikten" limits und "zuu strikten FIT Scalar" ~ wird hard-frequency throttled
Dies hängt zwar zusammen mit dem CAC-Sensor, welches eine direkte verbindung zum EDC hat, aber halt auch "nicht nur"
Zuu lange geschichte
Zuu falscher thread
Zuu wenig Zeit gerade. 2 Tage damit verbracht einen defekten 5900X wiederzubeleben. Geht morgen nach DE zurück zZZ
======================================
Letzteres gehe auch an diesem OCN dude. Keine Angenehme ehmalige erfahrung gemacht, aber ich hab echt gerade zu wenig Zeit um mit ihm zu streiten
Es ist traurig dass er den ganzen research ignoriert (oder einfach wirklich ingorant ist ~ heh) und nicht rauslesen kann wieso der Unterschied so hoch ist
Naja über den Tesselation bug kann keiner was - aber ehrlich gesagt sollte man anfragen was nun "korrekt" sei ~ da die neuen driver ebenfalls andere Tesselation werte haben als die Ehmaligen
Kann ja echt nicht sein dass 3D-Mark keine fixen settings enforced, wenn AMD ebenfalls bei der Surface Optimization "cheated" ~ aber dann mit sowas kommt
Mein Beileid an alle LUXX nutzer mit invalid scores
Zuletzt bearbeitet:
Ich meine den Wert, den man zB mit HWinfo ausliest.
Schreib doch auf englisch, wenn es dir leichter fällt.
Devcom hat gut' ne Stunde vor dem Post hochgeladen
Anhänge
Da du die Liste schlafen gelegt hast: Ja, hatte ich.
Der 21.11.1 hat auch den "Tesselation" bug ?
Ich mein wir können das direkt im driver.inf ändern, wenn 3D Mark irgendwelche speziellen anforderungen habe.
* die Paar werte welche ich damals gezeigt hatte, passen die signature & hash checks ~ brechen somit nicht WHQL und sind immer noch "signed" drivers
Nur ich kann nichts davon rauslesen
Wenn , dann ja ~ sollten sie alle scores mit den Treiben löschen. Gleiches Recht für alle
Kann ja nun echt keiner was davon dass 3D Mark's "legit" Ansichten nun komplett anders sind, als das was AMD mit den Treibern ausliefert
Ich mein wir können das direkt im driver.inf ändern, wenn 3D Mark irgendwelche speziellen anforderungen habe.
* die Paar werte welche ich damals gezeigt hatte, passen die signature & hash checks ~ brechen somit nicht WHQL und sind immer noch "signed" drivers
Nur ich kann nichts davon rauslesen
Wenn , dann ja ~ sollten sie alle scores mit den Treiben löschen. Gleiches Recht für alle
Kann ja nun echt keiner was davon dass 3D Mark's "legit" Ansichten nun komplett anders sind, als das was AMD mit den Treibern ausliefert
Result not found
www.3dmark.com
So jetzt ist nix verändert Tess, auf Anwendung Treiber 10.2 Windows 11
und auch gefilmt mit Wattman Einstellungen beim Start.
Hatte auch noch nie so einen Cpu score.
ILoveTattoo
Enthusiast
Was ich lustig finde. Ich wurde am 1.8 schon auf nen Discord angeschrieben, Bezüglich den Tess Bug . da wurde ich nur belächelt. Am 16 August habe ich UL mein Ergebniss mit 25.452 Overall gemeldet bezüglich meiner Vali des Laufes.
Der übrings immer noch keine Vali bekommen hat.
Und erst jetzt wo Snake sich dazu meldet , und das Public aus dem OCN Forum machen, soll gehandelt werden.
Der übrings immer noch keine Vali bekommen hat.
Und erst jetzt wo Snake sich dazu meldet , und das Public aus dem OCN Forum machen, soll gehandelt werden.
@Techlogi: Durch den großen Erfolg der Listenteilnehmer hier unterscheiden sich die besten Ränge zwischen 3DMark und unseren Listen kaum. Und nur weil [LUXX] drauf steht, muss nicht überall Ehrenhaftigkeit drin stecken. Es ist eine psychologische Tatsache, dass einfache Regelverstöße im gleichen Maß zunehmen wie das Risiko dabei ertappt zu werden abnimmt. Und das Ausnutzen des Tess Bugs ist nicht nachweisbar.
Bis jetzt waren wir (fast) alle im Glauben, dass sich durch Tess Off keine zusätzlichen Punkte erzielen lassen. Jetzt liegt der Preis aber auf dem Tisch und die Versuchung ist da. Selbst wenn jeder hier sich selbst für charakterfest genug hält, ihr zu widerstehen, kann er das von seinem Nächsten nur vermuten.
Die Ruhendstellung der Ranglisten soll uns schützen, und zwar vor gegenseitigen Verdächtigungen. Die müssen nicht mal laut ausgesprochen werden: Die Unsicherheit allein genügt schon, um Gedanken zu vergiften und aus Glückwünschen insgeheime Verwünschungen zu machen. Wer das für übertrieben hält, kennt die Menschen nicht, behaupte ich.
BTW: Was glaubst du, wieviele PNs heute im Lauf des Tages schon zum Thema hatten, ob der Score dieses oder jenes Dritten wohl legit sei? Hast du wirklich keine bekommen? Glückwunsch.
Ich höre gern deine und weitere Meinungen dazu.
Bis jetzt waren wir (fast) alle im Glauben, dass sich durch Tess Off keine zusätzlichen Punkte erzielen lassen. Jetzt liegt der Preis aber auf dem Tisch und die Versuchung ist da. Selbst wenn jeder hier sich selbst für charakterfest genug hält, ihr zu widerstehen, kann er das von seinem Nächsten nur vermuten.
Die Ruhendstellung der Ranglisten soll uns schützen, und zwar vor gegenseitigen Verdächtigungen. Die müssen nicht mal laut ausgesprochen werden: Die Unsicherheit allein genügt schon, um Gedanken zu vergiften und aus Glückwünschen insgeheime Verwünschungen zu machen. Wer das für übertrieben hält, kennt die Menschen nicht, behaupte ich.
BTW: Was glaubst du, wieviele PNs heute im Lauf des Tages schon zum Thema hatten, ob der Score dieses oder jenes Dritten wohl legit sei? Hast du wirklich keine bekommen? Glückwunsch.
Ich höre gern deine und weitere Meinungen dazu.
Zuletzt bearbeitet:
ILoveTattoo
Enthusiast
Mach mal folgendes, Lass den Treiber mal absichtlich abstürzen mit zu viel Takt . Dann Startest Du , und versuchst mit dem gleichen Takt einen Run( Wo Du sicher bist das er durch geht ). Ich könnte drauf schwören, das das Ergebniss schlechter aus schautResult not found
So jetzt ist nix verändert Tess, auf Anwendung Treiber 10.2 Windows 11
und auch gefilmt mit Wattman Einstellungen beim Start.
Hatte auch noch nie so einen Cpu score.
ILoveTattoo
Enthusiast
Es gibt einen Unterschied zwischen Bugrun oder nicht ,den man aber nur
1: mit dem EVC messen kann , oder mit einem externen Strommessgerät.
Sobald Tess on ist , steigt die Leistungsaufnahme gewaltig, grade in Verbindung mit einer Spannungserhöhung.
1: mit dem EVC messen kann , oder mit einem externen Strommessgerät.
Sobald Tess on ist , steigt die Leistungsaufnahme gewaltig, grade in Verbindung mit einer Spannungserhöhung.
Result not found
www.3dmark.com
so wie gewünscht
@ShirKhan Den Tess Bug gibt es ja nicht erst seit heute und ich denke, nur weil es nun ein Ergebnis in der HOF gab (welches vom User selbst erst an UL gemeldet und dann gelöscht wurde), müssen wir nicht in Panik verfallen. Stattdessen hier im Thread weiter research betreiben und das ganze (weiter) an UL und AMD melden.
Jetzt darf aber gerne auch nochmal jemand anders dazu was sagen.
Jetzt darf aber gerne auch nochmal jemand anders dazu was sagen.
ILoveTattoo
Enthusiast
Hattest Du ein kompletten Blackscreen ?Result not found
so wie gewünscht
Temperaturen und Spannungen gehen hand in hand
- Dauer des spikes, ob 10-20ms oder <1ms
- Die "höhe" des Amperage's im Zusammenhang mit der Spannung (viel spannung, wenig current = fein, fast egal auf welcher temp)
- Die Dichte der Node, nm-nodesize , somit die chance an Kettenreaktionen zwischen "Gates"
- Die Zeit welche es ab/in 65c, 90c, 105c verbringt ~ den wie AMD schon meinte, 105c Hotspot "sind fein" , zumindest in den öffentlich genannten und programmierten limits
Am Schluss kommt noch die Silicon Lottery ins spiel ob Leaky Silicon oder nicht (je nach Fab und color change benimmt es sich anders, liebt spannung/hasst spannung)
Also generell auch bei RAM , bedeuted Voltage garnichts - fast nichts
Arriving Amperage, ist das wichtige ~ so ebenso bei Zen.
Voltage heißt auch nicht gleich Hitze , aber high input current kann manchmal helfen ~ wie wir es hier wohl machen dank dem VMIN mode
Normalerweise haben alle Zen units (GPUs too) mindestens 2 Emergency sensoren ~ komplett getrennt von OverCurrent Sensing units
Selbst wenn du FIT verbuggst und die oben genannten (Vermeer kern) limits fährst ~ also wo FIT nicht mehr zurückthrottlen kann und das wirklich ankommt
(nicht nur visuel gesendet oder requested wurde)
Dann besteht immer noch die Möglichkeit dass sich das Gerät im fail safe mode schaltet, und bei 550mhz zb, sind auch 1.8v potentiell je nach dauer, und sehr niedrigem Amperage (last) wert ~ komplett harmlos
Mit sehr vielen * dazugeschrieben
Das selbe sollte bei der GPU sein
Ich denke, man kann sie spike technisch auf weitaus höherer Spannung rennen
Solange die Karte nicht hardwaremäßig modifiziert wird ~ werden "tödliche !" spikes zum Kern rechtzeitig aufgehalten
Im besten Falle zwar garnicht erst gesendet, aber wenn ~ dann sicherlich aufgehalten. *
* Damit will ich nicht garantieren dass die Leute nicht derren Karte killen können mit MPT,
Aber logisch und designmäßig betrachtet, hätte sogar das Bios nicht genug zugriff eine tödliche Spannung zu senden (bitte nicht übertreiben) **
** letztenendlich kommt es aber weiterhin drauf an "wie kalt war die karte, wie hoch war der Wiederstand und wie lange der spike anliegt (XOC wäre potentiel gefährlicher, da resistency fällt)
Degrading, ist ein "Zeit" Thema,
Es ist schwer etwas mit solch vielen Sensoren zu degraden. Besonders wenn es sich dann fast realtime mäßig anpasst und die spannungen selber niedriger stellt, bzw effective clock dropt
(aus XYZ "zu hohem" Grund)
Wirkliche "degradation" merkst du nur, wenn du die selben Ergebnisse im selben Raum, mit der selben Raumtemperatur, und potentiell der selben Jahreszeit (+1 Jahr) vergleichst.
Und selbst das garantiert dir nicht perfekte vergleiche, dass "degradation" daran schuld war und nicht einfach "external sources" wie zb anderers sauberer strom zu dieser Jahreszeit ~ deinen Boost verhindern.
Degradation ist ein langes langsames Thema, und wirklich rausfinden wirst du es nicht in der kurzen Zeit
Dafür kannst du alle variablen nicht issolieren welche gegen dich arbeiten und sich spannungs und frequenz technisch korrigieren
Zuletzt bearbeitet:
ILoveTattoo
Enthusiast
Fast der gleiche Takt , nur 21.7.2 Treiber
www.3dmark.com
ebenfalls gleicher Takt nur 21.10.2
www.3dmark.com
Bisher war der 21.7.2 der schnellste Treiber für Timespy.
Und bevor die Disku wieder aufkommt. Ich habe keinen als Cheater betitelt.
Selbst Rauf hat mit LN2 und einem 12900k@ Ln2 keinen so einen hohen GPU Score gehollt.
www.3dmark.com
Result not found
www.3dmark.com
ebenfalls gleicher Takt nur 21.10.2
Result not found
www.3dmark.com
Bisher war der 21.7.2 der schnellste Treiber für Timespy.
Und bevor die Disku wieder aufkommt. Ich habe keinen als Cheater betitelt.
Selbst Rauf hat mit LN2 und einem 12900k@ Ln2 keinen so einen hohen GPU Score gehollt.
I scored 26 191 in Time Spy
Intel Core i9-12900K Processor, AMD Radeon RX 6900 XT x 1, 32768 MB, 64-bit Windows 10}
www.3dmark.com
Zuletzt bearbeitet:
