Alder Lake: Potenzielle Probleme mit DRM-Middleware
Intel hat in einem Entwickler-Leitfaden darauf hingewiesen, dass es potenzielle Probleme mit der neuen Hybrid-Architektur und DRM-Middleware geben kann.
Mit Alder Lake steht bei Intel ein größerer Umbau bei der Prozessor-Architektur an und das Unternehmen weist nun auf potenzielle Probleme mit DRM-Maßnahmen hin, die durch das heterogene Design verursacht werden können. Intel rät den Anbietern, die DRM-Software an die neue Architektur anzupassen. Ob es tatsächlich zu Problemen kommt, wird vom Einzelfall abhängen - Spieler sollten nicht überrascht sein, wenn ein Titel den Dienst auf der gerade neu erworbenen CPU verweigert.
Insbesondere bei DRM-Systemen, die komplex sind und sich tief ins System eingraben, könnte Ungemach drohen, da sie auf einem recht niedrigen Level agieren. Problematisch wird das Thema dann wohl bei Spielen, die keinen Software-Support mehr erhalten und die Anbieter das DRM weder patchen noch entfernen wollen oder können. Konkrete Beispiele gibt es derweil keine, Intel erwähnt aber namentlich Denuvo:
"Wenn Ihr bestehendes oder kommendes Spiel eine DRM-Middleware verwendet, sollten Sie den Middleware-Anbieter kontaktieren und sich vergewissern, dass er hybride Architekturen im Allgemeinen und die kommende Intel ADL-Plattform im Besonderen unterstützt. Aufgrund der Beschaffenheit moderner DRM-Algorithmen kann es sein, dass die Middleware CPU-Erkennung verwendet und sich der kommenden Hybrid-Plattformen bewusst sein sollte. Intel arbeitet mit führenden DRM-Anbietern wie Denuvo zusammen, um sicherzustellen, dass ihre Lösungen die neuen Plattformen unterstützen."
Für Spiele, deren Support noch läuft, oder Neuentwicklungen sollte die Umstellung kein großes Thema sein, da es ein Interesse gibt, dass die Software läuft. Bei kompetitiven Spielen muss man zudem ohnehin prüfen, ob andere Elemente wie Anti-Cheat-Systeme auch auf Alder Lake problemlos laufen. Interessanter wird es bei Titeln, mit denen bereits abgeschlossen wurde. Da werden sich Entwickler und Publisher fragen müssen, ob sich der Aufwand und die Kosten lohnen.
Quelle: Intel
Sorry, falsch ausgedrückt. Die "temporäre" Deaktivierung ist natürlich nicht das Problem, einzig die Notwendigkeit dieses jedes Mal im BIOS machen zu müssen wäre dies das "Armutszeugnis".
Ansonsten sind wir voll einer Meinung, Probleme können immer auftreten bei neuen Architekturen, wahrscheinlich hat man dies einfach ein wenig verdrängt, da von Intel in diesem Bereich doch recht wenig "neues" kam im letzten Jahrzehnt.
Denke, dass es ein bigLittle Problem sein wird.
Die Lösung der "temporären" Deaktivierung wäre aber schon irgendwie ein Armutszeugnis für Intel, hier sollte man dann doch bitte schnellstmöglich einen Softwareschalter einbauen.
Darüber hinaus, in den ISAs werden immer wieder Befehle auf deprecated gesetzt und verschwinden dann in späteren Versionen relativ unbemerkt aus dem Design. Auch bei den älteren Zen's gab es bspw. einige explizit für veraltet erklärte Befehle, die zu der Zeit aktuelle Software immer noch nutzte.
Einige Kopierschutz/DRM-Software kann sich hier bspw. durchaus bewusst auf exotische Befehle stützen, bspw. um zu vermeiden, dass sie virtualisiert oder emuliert wird, etc. Da lassen sich die jeweiligen Hersteller natürlicherweise nicht in die Karten schauen, denn ansonsten wüsste man auch direkt, wie man derartige SW aushebeln kann. Wird man abwarten müssen.
Größere Architekturwechsel bergen immer Risiken für die weiterverwendung alter Software ... wie gesagt, wenn aber die Hybrid Technology das "Problem" sein sollte, dürfte sich das leicht umgehen lassen. Warum diese das Problem sein könnte? Weil die ISA zwar weitestgehend angeglichen ist, es aber dennoch diffizile Unterschiede zwischen den Kernen gibt und es auf den E-Kernen (früher Atoms) einige wenige andere Befehle als auf den großen Kernen gibt und umgekehrt, was aber i. d. R. bestenfalls für Systemsoftware relevant ist. Man könnte jetzt weiter spekulieren und überlegen, dass wenn ein DRM-Thread bspw. zuerst auf einem Golden Cove läuft und dann auf einen Gracemont umgelegt wird (nachdem er seine ISA-Erkennung schon längst abgeschlossen hat), könnte er versuchen ein paar exotischere low-level Befehle anzusprechen, die plötzlich "verschwunden" sind und das würde natürlich zu Problemen führen.
Armutszeugnis seitens Intel, nö, warum sollte es? Das ist komplett neue Technologie. Wenn man erwarten würde, dass auch ein heutiger, moderner Mikroprozessor noch bis in kleinste Detail vollends abwärtkompatibel zu CPUs aus den 80ern wäre, wären wir nich beim heutigen Leistungsniveau angekommen und die Designs wären vermutlich noch deutlich fehleranfälliger. Ab einer gewissen Entwicklungsstufe gilt es alte Zöpfe abzuschneiden, sonst kommt man entwicklungstechnisch nicht merklich weiter bzw. bleibt deutlich hinter den Möglichkeiten zurück.
Und wie gesagt, sollte es mit dem temporären Deaktivieren der Gracemont-Kerne (muss man ja nicht, es wird gar auch Varianten ohne diese geben) tatsächlich getan sein, würde alte SW dennoch größtenteils besser auf den Golden Cove-Kernen laufen als jemals zuvor, weil das voraussichtlich die derzeit durchsatzstärkste Mirkoarchitektur ist und anscheinend noch gepaart mit dem derzeit höchsten Takt (bei den großen CPUs). Ob es wirklich "so einfach" ist, wird man natürlich noch abwarten müssen. Dass Intel hier vorwarnt ist nur sinnvoll und vermutlich auch rechtlich angeraten.
Ergänzend: Ob es vielleicht ein "Thread-Pinning-Tool" von Intel oder gar Microsoft geben wird bleibt abzuwarten. Ich hätte auch auf so etwas als Migrationsunterstützung hin vermutet, denn wie könnte man ansonsten am einfachsten bei alter SW allen Problemen aus dem Weg gehen, indem man einfach definiert, dass bspw. alle an der MeinSpiel.exe hängenden Prozesse und Threads grundsätzlich nur auf Golden Cove-Kernen zu platzieren sind. Ob eine derartiger Ansatz aber tatsächlich alle Probleme zu lösen vermag weiß ich nicht. Alle Eventualitäten inkludierend würde ich grundsätzlich auf ein "Nein" tippen, denn einige SW verwendet die ISA nicht unbedingt so wie vom CPU-Hersteller vorgesehen, sei es nur, weil man das letzte Quentchen Performance herausholen will oder aber man sich als Entwickler für besonders geistreich hält oder aber weil man bewusst sehr speziellen und HW-abhängigen Code schreiben will, sei es um die Lauffähigkeit einzuschränken oder bspw. ein Reverseengeneering zu erschweren oder was auch immer.
Verstehe deinen Ansatz dann leider nicht, mit deiner Sig rufst du doch zum Windows 11 Boykott auf und forderst dazu auf, bei Windows 10 zu bleiben!
Im Post selber schreibst du dann, wenn ich AL hab, dann auch Win11?
Irgendwie wittere ich da eine Doppelmoral
Für mich ist Fakt, dass ich Windows 11 getestet habe, als Ryzen Besitzer aber schnell zu Win10 zurückgekehrt bin und Win 11 immer mal wieder (auf zweiter Platte installiert) aktualisiere und schaue was so passiert. Für mich war aber in der Vergangenheit immer klar, dass ich mind. ein Jahr warte und dann erst umsteige, so auch bei Win 10 und Win 7. Unrecht hatte ich glaube ich selten mit dieser Vorgehensweise, meistens hat man in den ersten Monaten noch recht viele Probleme und daher glaube ich, dass AL vieleicht einfach noch zu früh kommt (zumindest wenn Win11 quasi vorausgesetzt wird)
Ich hab es darum geschrieben. Um die Aussage, das ich doch auch wechseln könnte, in dem ich eine manuelle Installation durchführe. Von vornherein klar abzusagen.
Wenn du hier ein Aufruf zum Boykott raus gelesen hast. Bitte ich um Nachsicht, da das nicht meine Intention gewesen war/ist.
p.s.
Ich hab meine Signatur geändert und hoffe das es jetzt auch für dich klarer zu verstehen ist.
p.p.s
Auch werde ich keine teure Hardware kaufen um Windows 11 nutzten zu können. Da meine PC noch reichlich Power hat.
Darüber hinaus besteht wohl anscheinend im BIOS die Möglichkeit die kleinen Kerne auch zu deaktivieren, d. h. will man alte SW nutzen und auf Nummer Sicher gehen, könnte man diesen Weg gehen und vermutlich auch problemlos mit einem 8+8er arbeiten, den man temporär teildeaktiviert und man würde immer noch von den deutlich performanteren P-Kernen profitieren. Bei bspw. alten Games wäre das vermutlich gar noch weniger ein Problem, denn die skalieren tendenziell noch weniger gut als moderne Titel mit den CPU-Kernen.
Denke, dass es ein bigLittle Problem sein wird.
Die Lösung der "temporären" Deaktivierung wäre aber schon irgendwie ein Armutszeugnis für Intel, hier sollte man dann doch bitte schnellstmöglich einen Softwareschalter einbauen.
Im Post selber schreibst du dann, wenn ich AL hab, dann auch Win11?
Irgendwie wittere ich da eine Doppelmoral
Für mich ist Fakt, dass ich Windows 11 getestet habe, als Ryzen Besitzer aber schnell zu Win10 zurückgekehrt bin und Win 11 immer mal wieder (auf zweiter Platte installiert) aktualisiere und schaue was so passiert. Für mich war aber in der Vergangenheit immer klar, dass ich mind. ein Jahr warte und dann erst umsteige, so auch bei Win 10 und Win 7. Unrecht hatte ich glaube ich selten mit dieser Vorgehensweise, meistens hat man in den ersten Monaten noch recht viele Probleme und daher glaube ich, dass AL vieleicht einfach noch zu früh kommt (zumindest wenn Win11 quasi vorausgesetzt wird)
Wäre interessant zu erfahren ob die 6x0 Konfig auch von den gleichen Problemen betroffen sein wird?
Darüber hinaus besteht wohl anscheinend im BIOS die Möglichkeit die kleinen Kerne auch zu deaktivieren, d. h. will man alte SW nutzen und auf Nummer Sicher gehen, könnte man diesen Weg gehen und vermutlich auch problemlos mit einem 8+8er arbeiten, den man temporär teildeaktiviert und man würde immer noch von den deutlich performanteren P-Kernen profitieren. Bei bspw. alten Games wäre das vermutlich gar noch weniger ein Problem, denn die skalieren tendenziell noch weniger gut als moderne Titel mit den CPU-Kernen.