AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?
- Ersteller UNRUHEHERD
- Erstellt am
Nun ja, Intel schaltet fehlerhafte Features nachträglich einfach mal ab. (TSX)
Atombossler
Admiral Special
Ich hab ja auch gar nicht behauptet, dass es bei Anderen nicht auch zu nennenswerten Bugs kommt.
Allein es ist recht selten, weniger Performancerelevant, bzw. es werden Konsequenzen gezogen (ok. bei nVidia weniger ... ).
Das vermisse ich irgendwie bei AMD.
Nach dem X-ten verbockten Release sollte man doch da mal was dran ändern, oder nicht?
Auch der Polaris Release war alles andere als gut.
Im Gedächtnis bleibt nur der Spec. Bruch ...
Erst die Radeon-Pro WX Serie macht jetzt eine doch recht gute Figur, damit hätten Sie im Desktop viel besser Punkten können.
Von dem viel beworbenen HEVC Hardware Encoding ist weit und breit nichts zu sehen ...
Wenn das mal kein Bumerang gibt.
Von wegen zugesicherte Leistungen und so ...
Allein es ist recht selten, weniger Performancerelevant, bzw. es werden Konsequenzen gezogen (ok. bei nVidia weniger ... ).
Das vermisse ich irgendwie bei AMD.
Nach dem X-ten verbockten Release sollte man doch da mal was dran ändern, oder nicht?
Auch der Polaris Release war alles andere als gut.
Im Gedächtnis bleibt nur der Spec. Bruch ...
Erst die Radeon-Pro WX Serie macht jetzt eine doch recht gute Figur, damit hätten Sie im Desktop viel besser Punkten können.
Von dem viel beworbenen HEVC Hardware Encoding ist weit und breit nichts zu sehen ...
Wenn das mal kein Bumerang gibt.
Von wegen zugesicherte Leistungen und so ...
Och büdde, ganz bestimmt nicht.
tomturbo
Technische Administration, Dinosaurier
Warum soll Polaris kein Hevc decodieren können?
Bei meinem HTPC mit 460er klappt es jedenfalls.
Bei meinem HTPC mit 460er klappt es jedenfalls.
Laut diesem Herrn hier mangelt es wohl eher an der Software:
https://www.reddit.com/r/Amd/comments/4yjaya/here_are_some_sample_hevc_encodes_using_polaris/
https://www.reddit.com/r/Amd/comments/4yjaya/here_are_some_sample_hevc_encodes_using_polaris/
tomturbo
Technische Administration, Dinosaurier
Huch, das hatte ich glatt überlesen.
Gut HW-Encoding hat mich aufgrund der miesen Quali eh nie interessiert.
Von daher war ich auf decoding, was ja auch erst seit kurzem ordentlich funktioniert, fokusiert.
Sorry
Atombossler
Admiral Special
Natürlich tut es das.
Polaris hat die Funktionalität durchaus.
Nur womit nutzen/ansteuern?
Das ist es doch genau.
Da muss sich AMD über Kritik nicht wundern.
Stefan Payne
Grand Admiral Special
Wait, what?!
Von wem?!
Der 'normale' User kauft doch eh Intel oder ihm wird zu Intel geraten, auch wenn totaler Unsinn...
Das wäre bitter, wenn es einen Fehler im Silizium gibt der mit Workaround zwar gefixt werden kann aber 30-40% Leistung kostet.
Alles andere lässt mich aber hoffen! Leistungstechnisch auf Augenhöhe mit Intel - gut Bandbreitenintensiv Tests noch nicht - was aber am Limit liegen dürfte...
Nur auch hier kommt der Preis von 300$ für den 8Kerner/16Threads.. Das wäre eine Bombe in meinen Augen... Damit würden sie devinitiv Marktanteile holen... Nur das Sie so ticken glaube ich nicht. Bzw. fürs Spitzenmodell das mit Haswell-E mithalten kann - wenn man dem Leak glauben mag - können Sie ruhig 600$ aufrufen und wären noch immer im Vergleich zu Intel sehr interessant...
Alles andere lässt mich aber hoffen! Leistungstechnisch auf Augenhöhe mit Intel - gut Bandbreitenintensiv Tests noch nicht - was aber am Limit liegen dürfte...
Nur auch hier kommt der Preis von 300$ für den 8Kerner/16Threads.. Das wäre eine Bombe in meinen Augen... Damit würden sie devinitiv Marktanteile holen... Nur das Sie so ticken glaube ich nicht. Bzw. fürs Spitzenmodell das mit Haswell-E mithalten kann - wenn man dem Leak glauben mag - können Sie ruhig 600$ aufrufen und wären noch immer im Vergleich zu Intel sehr interessant...
cyrusNGC_224
Grand Admiral Special
Ja, das sollten sie sein lassen. Dann lieber etwas länger warten (das zieht sich doch eh wieder) als so einen Quatsch releasen.
Ich denke mal, ZEN wird man erst Anfang des 2. Quartals richtig bekommen.
WindHund
Grand Admiral Special
Es wuerde mich eher wundern, wenn die Tradition nicht fortgesetzt wird!
Der Fix kann alles moegliche sein, ich vermute eher sie nutzen nur ein BIOS welches sehr klein ist vom Speicherplatz her.
Das waere dann mit einem UEFI weniger problematisch, nur braucht das UEFI den gesamten CPUID String und nicht nur ein Test Sample String.
Beim Naples will man scheinbar fehler an der SMT implementierung gefunden haben, womoeglich noch mit Intel Code und keinen eigenstaendigen von AMD.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Je nachdem wie lange das Problem bekannt ist kann die Entwicklung einer gefixten Revision bereits abgeschlossen sein und es womöglich auch schon gefixte Samples geben.
Solche oberflächlichen Einblicke mögen ja ganz nett sein aber geben keinen definitiven Stand zur Entwicklung an. Beispielsweise brauchs du zur Qualifizierung der Plattform wohl kaum einen Chip vom letzten Entwicklungsstand. Da dürfte auch ein frühes, lauffähiges Sample reichen das die Spezifikationen für die Plattform einhält.
Ich würde also nicht zu viel auf sowas geben sondern auf das fertige Produkt warten.
Solche oberflächlichen Einblicke mögen ja ganz nett sein aber geben keinen definitiven Stand zur Entwicklung an. Beispielsweise brauchs du zur Qualifizierung der Plattform wohl kaum einen Chip vom letzten Entwicklungsstand. Da dürfte auch ein frühes, lauffähiges Sample reichen das die Spezifikationen für die Plattform einhält.
Ich würde also nicht zu viel auf sowas geben sondern auf das fertige Produkt warten.
Ich sehe die situation ein wenig gelassener. Sollte es wirklich einen Bug geben bezüglich des HT, so kann amd es in der ersten Charge ja abschalten. Sie hätten dann gegenüber Intel immer noch den Vorteil von 8 echten Kernen gegenüber Intel mit 4 Physischen und weiteren 4 logischen kernen. Das silizium ist ja nicht übermäsig groß und ich würde da schon 350 EUR dafür zahlen wenn sie mit der Leistung gegenüber Intel auf Augenhöhen sind. Ich denke, da würden auch viele zugreifen und mit dem erwirtschafteten Geld, kann mann immer nochmal eine neue Rev. finanzieren welche dann mit mehr leistung und 8 Physischen + 8 Logischen als Upgrade teurer angeboten werden kann. Dann käme die absolute Sperspitze eben 2-3 Monate spähter.
LG
Dune
LG
Dune
WindHund
Grand Admiral Special
Das meinte ich auch, es sind Samples die halbgar sind, die dürfen Fehler haben.
Welche Plattform meinst du? Die AM4 oem Mainboards?
Der cpuid String ist nur wichtig für die richtige zuweisung des fix.
ohne verliert man Leistung.
Das war bewußt allgemein geschrieben weil es nichts spezielles für die AM4 Plattform ist sondern letztendlich auf jedes neue mainboard zutrifft.
Die Entwicklung der Mainboards läuft schließlich parallel ab und die dafür nötigen Spezifikationen sind auch entsprechend zeitig verfügbar udn an diese müssen sich letztendlich CPU und Mainboard halten.
Wenn man mal genauer darüber nachdenkt wäre es auch ziemlich unsinnig auf den fertig entwickelten und bereinigten Prozessor zu warten denn dann würde der erstmal ohne Mainboard da stehen. Wer kauf einen Prozessor ohne ein Mainboard zu bekommen in dem er ihn betreiben kann?
Dann lieber die erforderlichen Spezifikationen im Vorfeld festlegen und das Bugfixing parallel laufen lassen.
Der TLB Bug des ersten Phenoms war ja letztendlich auch nur so ein Debakel weil er bereits auf dem Markt war. Wäre er vorher aufgefallen dann hätte man den Prozessor wohl eher verschoben, gleich mit der bereinigten Version gestartet und der Endkunde hätte davon abgesehen vom späteren Release nichts mitbekommen.
Die Entwicklung der Mainboards läuft schließlich parallel ab und die dafür nötigen Spezifikationen sind auch entsprechend zeitig verfügbar udn an diese müssen sich letztendlich CPU und Mainboard halten.
Wenn man mal genauer darüber nachdenkt wäre es auch ziemlich unsinnig auf den fertig entwickelten und bereinigten Prozessor zu warten denn dann würde der erstmal ohne Mainboard da stehen. Wer kauf einen Prozessor ohne ein Mainboard zu bekommen in dem er ihn betreiben kann?
Dann lieber die erforderlichen Spezifikationen im Vorfeld festlegen und das Bugfixing parallel laufen lassen.
Der TLB Bug des ersten Phenoms war ja letztendlich auch nur so ein Debakel weil er bereits auf dem Markt war. Wäre er vorher aufgefallen dann hätte man den Prozessor wohl eher verschoben, gleich mit der bereinigten Version gestartet und der Endkunde hätte davon abgesehen vom späteren Release nichts mitbekommen.
Zuletzt bearbeitet:
Ein guter Punkt, meistens wurden die beiden Fälle hier einfach in einen Topf geworfen.
Mal abgesehen davon halte ich den damaligen Affentanz um den Bug für den Desktop Bereich ohnehin für überzogen denn ich hatte selbst einen davon, bewußt darauf geachtet das der Fix nicht aktiv wird und die Kiste lief dennoch anstandslos. Abstürze die in der Zeit auftraten waren eher auf Probleme mit der jeweiligen Software oder diverser Treiber zurück zu führen, traten auch bei andern Prozessoren auf und verschwanden mit den Software und Treiber Updates.
BoMbY
Grand Admiral Special
Nicht wirklich spannend auf den ersten Blick:
Dürfte eher für die Server-Zens mit mehreren Modulen interessant sein? Das heißt die Memory Controller pro Summit Ridge Modul mit ihren jeweils zwei Kanälen arbeiten prinzipiell erstmal vollkommen unabhängig voneinander?
Edit: Das könnte auch einige der Erkennungs- und Performanceprobleme erklären. Ich schätze das ist so in der Software bisher nicht wirklich vorgesehen, dass hier quasi bis zu vier getrennte CPUs auf einem Sockel sitzen. Im Prinzip muss das OS die bei Dual-Sockel Systemen nicht behandeln wie 2x32 sondern als 8x8, damit der Speicher optimal zugewiesen werden kann, und man sollte natürlich auf jeden Channel mind. ein Speichermodul haben.
Dürfte eher für die Server-Zens mit mehreren Modulen interessant sein? Das heißt die Memory Controller pro Summit Ridge Modul mit ihren jeweils zwei Kanälen arbeiten prinzipiell erstmal vollkommen unabhängig voneinander?
Edit: Das könnte auch einige der Erkennungs- und Performanceprobleme erklären. Ich schätze das ist so in der Software bisher nicht wirklich vorgesehen, dass hier quasi bis zu vier getrennte CPUs auf einem Sockel sitzen. Im Prinzip muss das OS die bei Dual-Sockel Systemen nicht behandeln wie 2x32 sondern als 8x8, damit der Speicher optimal zugewiesen werden kann, und man sollte natürlich auf jeden Channel mind. ein Speichermodul haben.
Zuletzt bearbeitet:
Wäre das dann nicht sowas wie der ganged / unganged Mode der beim Phenom eingeführt wurde?
Damit konnte man ja einstellen ob die 2 Speicherkanäle nur zusammen oder auch unabhängig von einander agieren können.
Bei einem Programm war es natürlich von Vorteil wenn die Kanäle gebündelt sind aber sobald Multithreading / -tasking ernsthaft ins Spiel kam war es günstiger wenn die Kerne gleichzeitig auf jeweils einen Kanal zugreifen können anstatt sich in der Warteschlange anstellen zu müssen.
Damit konnte man ja einstellen ob die 2 Speicherkanäle nur zusammen oder auch unabhängig von einander agieren können.
Bei einem Programm war es natürlich von Vorteil wenn die Kanäle gebündelt sind aber sobald Multithreading / -tasking ernsthaft ins Spiel kam war es günstiger wenn die Kerne gleichzeitig auf jeweils einen Kanal zugreifen können anstatt sich in der Warteschlange anstellen zu müssen.
Alles in allem klingt das Posting von dem angeblichen "insider" doch recht positiv. Dass Engineering-Samples noch Bugs haben ist ja nun mal nicht so eine furchtbar ungewöhnliche Neuigkeit. Genau deshalb ist das Ding noch nicht auf dem Markt sondern noch in der Evaluierung.
Warum ier schonwieder der TLB Bug beschworen wird (und kein Wort über den Fdiv-Bug der Pentiums aus dem Blauen Lager, der es auch in Release-Prozessoren geschafft hat) ist mir schleierhaft.
@Atombossler
du kloppst ganz schön große Worte für jemanden der noch keine eigene CPU vorweisen kann.
Hast du eigentlich schonmal, sagen wir, einen 16 Bit Addierer zusammengebaut? - z.b. Auf einem ButterBoard mit TTL-Bausteinen?
Oder wenigstens einen Treiber geschrieben für einen kleinen Controllerchip, man verlangt ja schon garnicht etwas von der Komplexität eines Polaris.
Was mich betrifft bin ich höchst gespannt auf Zen. Nicht übertrieben euphorisch, aber gespannt.
Dass hier schonwieder über ungelegtei Eier geunkt wird ist allerdings typisch. Ich wette wenn Zen bei seinem Release keine 2000% Vorsprung in der Schwan.... ähm, Balkenlänge im IchmachmirmalmeinenBenchamrkweilichSoCoolbin - Shootout vorweisen kann wird schonwieder der Untergang des Abendlandes heraufbeschworen
~Haswell-IPC wäre schonmal ein sehr deutlicher Schritt. - Und man wird da kaum ewig stehenbleiben, Zen+ ist ja auch schonwieder schemenhaft auf der Timeline erkennbar.
Vor allem interessant wie sie diesesmal die Cache-Pipeline hingekriegt haben, das Cachedesign mit dem merkwürdigen Write-Through L1 war ja auch eine der Achillesfersen des Bulldozer-Designs.
Vielleicht ist auch gerade dort der entsprechende Bug angesiedelt. - Also im Cache-Subsystem, dort kann man schnell mal 30 oder 40% Performance vernichten wenn z.b. die Prefetcher nicht sauber arbeiten und die CPU ständig auf ihre Daten warten muss. Das ist wie bei einem Uhrwerk, wenn ein Zahnrädchen an der falschen Stelle klemmt, bringt das die ganze Maschine aus dem Tritt.
Dennoch, solange keins von den Dingern im Regal liegt mit dem erwähnten Bug ist es absolut kein Grund hier rumzumaulen. Schließlich fragt auch bei den Intelschen Engineering-Samples keiner ob die Bugfrei sind (oder verlangt das) und käme schon garkeiner auf die Idee dass deswegen die Release-CPUs Schrott sein müssten.
Fragt mal einen KFZ-Ingineur wie viele Fehler ein Prototyp einer neuen Fahrzeugklasse oftmals hat, die erst bei den Tests auffallen - sonst bräuchte man die ja nicht machen.
Womöglich ist das sogar ein Bug der nur auf Muktisockel-Konfigurationen auftritt und den Desktop nichtmal tangieren würde (aber natürlich trotzdem gefixt werden muss) - Wir wissen es einfach nicht. Aber hauptsache den Lichtbringer an die Wand gekachelt...
Grüße,
Meiner Einer
Warum ier schonwieder der TLB Bug beschworen wird (und kein Wort über den Fdiv-Bug der Pentiums aus dem Blauen Lager, der es auch in Release-Prozessoren geschafft hat) ist mir schleierhaft.
@Atombossler
du kloppst ganz schön große Worte für jemanden der noch keine eigene CPU vorweisen kann.
Hast du eigentlich schonmal, sagen wir, einen 16 Bit Addierer zusammengebaut? - z.b. Auf einem ButterBoard mit TTL-Bausteinen?
Oder wenigstens einen Treiber geschrieben für einen kleinen Controllerchip, man verlangt ja schon garnicht etwas von der Komplexität eines Polaris.
Was mich betrifft bin ich höchst gespannt auf Zen. Nicht übertrieben euphorisch, aber gespannt.
Dass hier schonwieder über ungelegtei Eier geunkt wird ist allerdings typisch. Ich wette wenn Zen bei seinem Release keine 2000% Vorsprung in der Schwan.... ähm, Balkenlänge im IchmachmirmalmeinenBenchamrkweilichSoCoolbin - Shootout vorweisen kann wird schonwieder der Untergang des Abendlandes heraufbeschworen
~Haswell-IPC wäre schonmal ein sehr deutlicher Schritt. - Und man wird da kaum ewig stehenbleiben, Zen+ ist ja auch schonwieder schemenhaft auf der Timeline erkennbar.
Vor allem interessant wie sie diesesmal die Cache-Pipeline hingekriegt haben, das Cachedesign mit dem merkwürdigen Write-Through L1 war ja auch eine der Achillesfersen des Bulldozer-Designs.
Vielleicht ist auch gerade dort der entsprechende Bug angesiedelt. - Also im Cache-Subsystem, dort kann man schnell mal 30 oder 40% Performance vernichten wenn z.b. die Prefetcher nicht sauber arbeiten und die CPU ständig auf ihre Daten warten muss. Das ist wie bei einem Uhrwerk, wenn ein Zahnrädchen an der falschen Stelle klemmt, bringt das die ganze Maschine aus dem Tritt.
Dennoch, solange keins von den Dingern im Regal liegt mit dem erwähnten Bug ist es absolut kein Grund hier rumzumaulen. Schließlich fragt auch bei den Intelschen Engineering-Samples keiner ob die Bugfrei sind (oder verlangt das) und käme schon garkeiner auf die Idee dass deswegen die Release-CPUs Schrott sein müssten.
Fragt mal einen KFZ-Ingineur wie viele Fehler ein Prototyp einer neuen Fahrzeugklasse oftmals hat, die erst bei den Tests auffallen - sonst bräuchte man die ja nicht machen.
Womöglich ist das sogar ein Bug der nur auf Muktisockel-Konfigurationen auftritt und den Desktop nichtmal tangieren würde (aber natürlich trotzdem gefixt werden muss) - Wir wissen es einfach nicht. Aber hauptsache den Lichtbringer an die Wand gekachelt...
Grüße,
Meiner Einer
hm ich halte die avx Einheit meines 4790k auch für BUG behaftet, da sie die cpu ganz an ihre grenzen bringt, das dann mal 0,05volt drauf gehauen werden ist Thermal betrachtet in einigen Anwendungen sehr grenzwertig (Boinc Asteroid .... ). Und da redet auch keiner von Bug.
Interessant fand ich es schon was sie so gesehen/testet haben aber es heist immer noch warten.
Was mich ehr verwundert ist die intel Meldungen zu 2018 Cpus das gabs doch noch nie so weit vorher?
lg
Interessant fand ich es schon was sie so gesehen/testet haben aber es heist immer noch warten.
Was mich ehr verwundert ist die intel Meldungen zu 2018 Cpus das gabs doch noch nie so weit vorher?
lg
Der FDIV-Bug bei Intel wurde schon sehr negativ bewertet, damals.
Aber seitdem war es gefühlt "schon immer" so, dass auf AMD stärker draufgedroschen wurde. Das läuft ja schon jetzt wieder, indem schon vermeintliche bzw. "gefühlte" Fehler durchsickern, auch wenn die nie so beim Kunden ankommen werden...
Aus diesem Grund dürfen sie sich beim Zen-Launch IMHO *keine* Fehler leisten. Der Polaris-Launch war diesbezüglich kein Ruhmesblatt; AMD darf keine Angriffsfläche zeigen.
Umgedeutet könnte es ja auch sein, dass mit den CPUIDs und dem BIOS ja ggf. bei manchen "Plaudertaschen" das Testsystem seitens AMD gezielt gebremst werden sollte, damit die wahre Leistung überraschend ans Licht kommt. Ggf. gibt es mehrere Bremsfeatures und entsprechende "Leaks" könnte man je nach "geleaktem" Verhalten bei AMD nachvollziehen. Aber gut, das ist ja schon gegen Ockham's Razor.
Atombossler
Admiral Special
Es wuerde mich eher wundern, wenn die Tradition nicht fortgesetzt wird!
Der Fix kann alles moegliche sein, ich vermute eher sie nutzen nur ein BIOS welches sehr klein ist vom Speicherplatz her.
Das waere dann mit einem UEFI weniger problematisch, nur braucht das UEFI den gesamten CPUID String und nicht nur ein Test Sample String.
Beim Naples will man scheinbar fehler an der SMT implementierung gefunden haben, womoeglich noch mit Intel Code und keinen eigenstaendigen von AMD.
Na ja, genau das meinte ich ja aber. Das wird nicht reichen ...
Der Vishera ist da jetzt schon schneller im Single Core und beim Multi fehlt nicht viel und das sind 4M/8T.
40% + auf Excavator sollten anders aussehen Bug oder nicht.
--- Update ---
Alles in allem klingt das Posting von dem angeblichen "insider" doch recht positiv. Dass Engineering-Samples noch Bugs haben ist ja nun mal nicht so eine furchtbar ungewöhnliche Neuigkeit. Genau deshalb ist das Ding noch nicht auf dem Markt sondern noch in der Evaluierung.
Warum ier schonwieder der TLB Bug beschworen wird (und kein Wort über den Fdiv-Bug der Pentiums aus dem Blauen Lager, der es auch in Release-Prozessoren geschafft hat) ist mir schleierhaft.
@Atombossler
du kloppst ganz schön große Worte für jemanden der noch keine eigene CPU vorweisen kann.
Hast du eigentlich schonmal, sagen wir, einen 16 Bit Addierer zusammengebaut? - z.b. Auf einem ButterBoard mit TTL-Bausteinen?
Oder wenigstens einen Treiber geschrieben für einen kleinen Controllerchip, man verlangt ja schon garnicht etwas von der Komplexität eines Polaris.
Was mich betrifft bin ich höchst gespannt auf Zen. Nicht übertrieben euphorisch, aber gespannt.
Dass hier schonwieder über ungelegtei Eier geunkt wird ist allerdings typisch. Ich wette wenn Zen bei seinem Release keine 2000% Vorsprung in der Schwan.... ähm, Balkenlänge im IchmachmirmalmeinenBenchamrkweilichSoCoolbin - Shootout vorweisen kann wird schonwieder der Untergang des Abendlandes heraufbeschworen
~Haswell-IPC wäre schonmal ein sehr deutlicher Schritt. - Und man wird da kaum ewig stehenbleiben, Zen+ ist ja auch schonwieder schemenhaft auf der Timeline erkennbar.
Vor allem interessant wie sie diesesmal die Cache-Pipeline hingekriegt haben, das Cachedesign mit dem merkwürdigen Write-Through L1 war ja auch eine der Achillesfersen des Bulldozer-Designs.
Vielleicht ist auch gerade dort der entsprechende Bug angesiedelt. - Also im Cache-Subsystem, dort kann man schnell mal 30 oder 40% Performance vernichten wenn z.b. die Prefetcher nicht sauber arbeiten und die CPU ständig auf ihre Daten warten muss. Das ist wie bei einem Uhrwerk, wenn ein Zahnrädchen an der falschen Stelle klemmt, bringt das die ganze Maschine aus dem Tritt.
Dennoch, solange keins von den Dingern im Regal liegt mit dem erwähnten Bug ist es absolut kein Grund hier rumzumaulen. Schließlich fragt auch bei den Intelschen Engineering-Samples keiner ob die Bugfrei sind (oder verlangt das) und käme schon garkeiner auf die Idee dass deswegen die Release-CPUs Schrott sein müssten.
Fragt mal einen KFZ-Ingineur wie viele Fehler ein Prototyp einer neuen Fahrzeugklasse oftmals hat, die erst bei den Tests auffallen - sonst bräuchte man die ja nicht machen.
Womöglich ist das sogar ein Bug der nur auf Muktisockel-Konfigurationen auftritt und den Desktop nichtmal tangieren würde (aber natürlich trotzdem gefixt werden muss) - Wir wissen es einfach nicht. Aber hauptsache den Lichtbringer an die Wand gekachelt...
Grüße,
Meiner Einer
Mei, ungelegte Eier ...
... wir sind hier ja schliesslich im Speku Forum und was tut man da?
--- Update ---
So ist es, leider bekommen Sie's aber immer wieder hin irgend etwas zu versemmeln.
Dann lass es eben einen Monat länger dauern, Weihnachten ist doch dann eh schon vorbei, kommt doch nicht drauf an.
Das Teil muss einfach rundum gut werden, die ganzen Tester machen es noch schlecht genug.
Zuletzt bearbeitet:
Beim Naples will man scheinbar fehler an der SMT implementierung gefunden haben, womoeglich noch mit Intel Code und keinen eigenstaendigen von AMD.
Wenn "Intel-Code" nicht läuft ist es ein Bug.
