News Grafik-Patente: Intel und AMD angeblich in Lizenzgesprächen

Prokiller schrieb:
AMD und Intel?

hmmmm... hoffen wir mal das beste ..hoffe es wird keine negativen Auswirkungen für Intel haben

Du scheinst wohl noch zu klein zu sein.. AMD und Intel sind in einer Symbiose ;) Diverse Patentabkommen, AMD war mal Lizenzfertiger für Intel und meistens Wechseln auch nur die Ingenieure von Intel zu AMD oder andersrum
Achja Intel braucht AMD, damit die Kartellbehörden ruhe geben. Deswegen war damals nach dem Skandal sogar die Option dass Intel nur noch Architekturen fertigen darf und eine Ausgegliederte Foundry diese herstellen sollte. Selbst wenn AMD also Intel 3-5% Marktanteil abknabbern sollte, selbst bei 20%, kann es Intel immer noch recht Herzlichst egal sein.
Intel könnte AMD aus der Portokasse kaufen und Nvidia den Krieg erklären.. Aber warum sollte man? Ogliopole sind für beide Hersteller sinnig, und Intel verschenkt ja schon die CPUs um gegen ARM anzukommen..
Nach all den CPU Lizenzen (AMD64 zb.) wäre es ein logischer Schritt. Und man könnte AMD indirekt Geld zuschieben, damit AMD nicht in die Brüche geht. Etwas anderes macht Apple derzeit nicht anders.

@Kisser:
Hat doch Intel mit Larrabee, und ist damit ordentlich aufs Maul gefallen.. Aber klar, Intel entwickelt mal eben ohne Knowhow eine Massenmarkttaugliche GPU :D Der Witz ist gut. Achja Die APUs von Intel sähen auch als Aus, wenn AMD HBM oder eDRAM auf dem Package hätte.. Leider ist AMD ein Konzern, der sich so grade über Wasser hält, aber kannst ja mal bei Intel fragen, ob die noch GPU Ingenieure wie dich suchen :D
 
Zuletzt bearbeitet:
AMD-Mafiosi
Wobei man sagen muss Kaveri gab es als 3 Modul Ansatz mit 512 Shader und der Speichercontroller unterstützt GDDR5 (ist auch ein QuadChannel vorhanden).
Scheinbar hatten aber zu wenige OEMs Interesse, aber ein ITX Board mit Sockel und 8 GB verlöteten GDDR5 wäre mit Kaveri 3 Moduler möglich gewesen. Wäre für Steam-Konsolen oder sonstige Leute die sich ein HTPC bauen interessant gewesen. Nur bringt dir das nichts, wenn die OEM so ein Teil nicht in Fertig Rechner ect verbauen. Somit ist nur ein Kaveri mit 2 Cores und 2 aktiven Speicher Channel auf den Markt gekommen.
Carrizo wurde dann das ganze quasi gestrichen und man arbeitet wohl Richtung HBM. Da können die OEMs dann nicht mehr viel "falsch" mit der Speicherbestückung machen ^^

Intel wird ihre GPU sicher auch ausbauen und früher oder später den eDRAM durch HMC austauschen. Vllt ist es mit Cannonlake dann schon so weit ? Würde zu 2017 Zen HBM APU zeitlich passen.
 
@ pipip
Die SIMD-Breite hat primär etwas mit der Datenparallelität zu tun. Sie teilt sich auf in die "logische" SIMD-Breite (aka warp-size oder wavefront-size) und die "physikalische" SIMD-Breite. Die logisch SIMD-Breite beschreibt auf wieviele Datenelemente sich eine SIMD-Instruktion bezieht. Sie beträgt bei AMD 64, bei NVIDIA 32 und bei Intel ist sie variabel zwischen 8, 16 und 32. GPUs mit höheren logischen SIMD-Breiten benötigen weniger Kontroll-Logik, weshalb sie in der Regel eine höhere Rohleistung haben. Im Auslgeich dafür veschwenden sie aber mehr Rechenleistungen wenn die Kernels nicht perfekt datenparallel sind. Deshalb sind solche GPUs auch stärker auf Optimierungen bzw. auf Algorithmen angewiesen, welche die Datenparallelität erhöhen. Asynchronous-Compute hat jedoch nichts mit Datenparallelität sondern eher mit Taskparallelität zu tun, weshalb die SIMD-Breite dafür weitestgehend irrelevant ist.

Neben der logischen SIMD-Breite gibt es noch die physikalische SIMD-Breite, welche beschreibt wie Breit die Recheneinheiten einer SIMD-Einheit ausgelegt sind. Ist die physikalische SIMD-Breite kleiner als die logische SIMD-Breite so benötigt eine SIMD-Einheit für eine Instruktion mehrere Takte um sie abzuarbeiten. Zum Beispiel: Maxwell hat eine logische SIMD-Breite von 32. Die SIMD-Einheiten aus CUDA-Cores haben in Maxwell ebenfalls eine physikalische Breite von 32. Ergo benötigen eine solche SIMD-Einheit für jede Instruktion einen Takt. Eine SIMD-Einheit aus Special-Function-Units hat in Maxwell eine Breite von 8. Ergo benötigt sie für jede Instruktion 4 Takte. Die physikalische SIMD-Breite in GCN ist 16 und die logische SIMD-Breite 64, weshalb eine SIMD-Einheit für eine Instruktion 4 Takte benötigt. Abgesehen davon, dass die physikalische SIMD-Breite den Instruktionsdurchsatz und die Latenzen beeinflusst hat sie keine mir bekannten Auswirkungen beim Programmieren bzw. Optimieren.
 
Zuletzt bearbeitet:
kisser schrieb:
Wenn die Architektur nicht schnell wäre, dann würde auch der eSRAM nichts helfen! Intels GPU-Architektur ist sehr leistungsfähig und sowohl AMD als auch Nvidia können froh sein, dass Intel kein Interesse daran hat, dedizierte GPUs zu entwickeln.

:lol: achso ja, dann haben sie ja Glück gehabt. Klar, Intel wäre absolut konkurrenzfähig, ist aber zu faul in dieses Geschäft einzusteigen...
Wir wissen ja alle, was für Unmengen an $ Intel im Tablet/Smartphone Markt verschwendet hat, nur um irgendwie Marktanteile zu gewinnen. Es ist ja wohl selbstverständlich, dass die Marktanalysten bei Intel liebend gern dGPUs herstellen ließen, wenn es sich lohnen würde.
 
zeedy schrieb:
:lol: achso ja, dann haben sie ja Glück gehabt. Klar, Intel wäre absolut konkurrenzfähig, ist aber zu faul in dieses Geschäft einzusteigen...

Das sie es können zeigt der HPC Markt mit der Phi und jetzt im besonderen der KNL. Große Marktanteile, in wenigen Jahren. Davon träumt AMD und sind in diesem Bereich schon länger im Geschäft. Die Performance ist da, man müsste nur ordentliches Potenzial in die Software stecken, denn die ist für Grafik aktuell kaum geeignet. Aber warum so dumm sein statt 5000€ nur 500€ für eine GPU/Beschleuniger zu verlangen. Die KNL ist auf Grund der Fertigung und dem Bedarf restlos weg, wir müssen Monate warten für größere Mengen.

Aber was will man von dir erwarten..
 
Nai
GPUs mit höheren logischen SIMD-Breiten benötigen weniger Kontroll-Logik, weshalb sie in der Regel eine höhere Rohleistung haben.
Aber das war auch der Grund, wieso ich meinte, dass eine fiktive GPU der Mittelklasse oder Performance Klasse von Intel vermutlich auch größer wäre, weil eben das "Front End" größer wäre.

Eventuell hat sie bei der Software keine Auswirkung, aber ich denk da stark an die Fertigung. Shader kann man einfach besser nebeneinander packen, sprich haben eine höhere Packdichte als die ganzen Logi-Einheiten. Deshalb könnte es gut sein, dass bei einer ZEN APU mit gleich vielen ALUs, die GPU kleiner ausfällt, als es bei Intel der Fall ist. Jetzt kommt es eben zu den Optimierungen, welche wie erwähnt durch DX12 optimaler abläuft, als es eventuell mit DX11 noch der Fall ist. (wenn man sich jetzt mal nur auf Windows bezieht)
Async Compute habe ich deshalb erwähnt, weil kommende Game mehr und mehr auf Physikbasierende Shader/Engine aufbauen werden, somit mehr Shader benötigt werden wird, die auch die Physik oder sogar KI berechnen. Mit den ACE-Unit könnte man ja direkt einigen CUs, welche vllt nicht so sehr mit Grafik-Aufgaben gefüttert werden können direkt mit Physik-Aufgaben füttert. Der Clou dahinter wäre ja, dass man dann wie bisher zu einer gewissen oberen Schranke/Grenze, shader optimal mit Grafikaufgaben füttert und den Rest Physik Aufgaben. Ich bin sehr optimistisch, dass man das zu mindestens bei Konsolen Games so machen wird. Deshalb kann für eine GPU mit vielen Shader, Async Compute sehr wertvoll sein. Oder sehe ich das zu simpel ?

Sprich, der Chip hat im optimalsten Fall bei gleicher Fläche zu anderen Lösung mit mehr Logik, mehr Shader und somit mehr Rohpower, die sie aber nützten können, indem man ihnen auch noch andere Aufgaben zuspielt. Im Endeffekt könnte man von "Rekombination" sprechen.

Was die Intel GPU angeht, ich frage mich ja bis heute, ob die EUs nicht genauso wie der CPU Part gleich gestappelt/geordnet ect wird (gleiche Biblotheken für die Transistoren). Sprich, Intel gar nicht vorhatte, die Packdichte derart zu erhöhen, deshalb macht deren Umsetzung für ihre GPU auch so am meisten Sinn für ihre Fertigung. Auch vermute ich, dass Intel anfangs sowieso eher nur den unteren Bereich, speziell mobile SoCs anvisiert hatte und jetzt ihre Architektur nach oben fit macht. Dafür könnte es im Bereich HSA wiederum sehr interessant werden. Speziell da es ja Aufgaben gibt, wo eine 16 bit Operation völlig ausreichend ist. NV macht das ja mit dem X1 Tegra bereits. Das werden wir auch bei Pascal sehen, aber das weißt du mit Sicherheit ^^

strex
Gab es die Phi nicht teilweise quasi geschenkt ? Ich erinnere mich an Preise von 100-200 Dollar.
 
Jopp, die alten aus Restbestände und Leasing-Rückläufer. Wer deckt sich schon mit alte ein. Di KNL gibt es aktuell nur mit Warteliste..
 
pipip schrieb:
Der i5 5775c hat 48 EUs. Ein Sub-Slice mit 80 Alus soll 10 EUs sein. Somit sind das auch ca 386 ALUs(Shaders) und der Takt geht bis 1.15 GHz.
Im Vergleich der A10 7850k hat einen Takt von 720MHz. Das sind ca 37% weniger Takt, dafür hat der A10 512 Shader.
Somit ein AMD GPU mit 386 Shader und auch 1Ghz+ wäre vermutlich gleich schnell.

Die reine Rechenleistung in TFlops ist ja eine errechnete Größe. Da sind alle Hersteller gleich schnell, denn jeder "Shader" kann pro Takt eine MADD (multiply-add) Operation ausführen, also 2 Rechenoperationen.
Macht bei Nvidias 3072 Shader etwa 6,2 TFlops, bei AMD mit 4096 shader etwa 8,2 TFlops und bei Intel mit 384 Shadern eben 768GFlops (jeweils bei 1GHz Takt).

pipip schrieb:
Denke nicht, dass das so einfach ist, wie du dir das vorstellst. Die Shader sollten ja auch gut ausgelastet werden und gut skalieren. Sieht man ja bei AMD ab Fijii und teils bei Hawaii sehr gut, dass unter DX12 mit Async Compute einige Shader erst ordentlich ausgelastet werden können. Bei kleineren GPUs, tritt der Effekt nicht so stark oder gar nicht auf.

Ich sehe nicht, warum gerade Intel Probleme haben sollte, statt der 384 Shader im i5 5775 (bzw. der 512 Shader in der Iris Pro 580) eine GPU mit zB. 4096 Shadern entsprechend auszulasten.
Ergänzung ()

Dai6oro schrieb:
Wohl doch nicht so einfach ...

Aus der gleichen Quelle:
Erst auf dem Intel Developer Forum im April 2007 verkündete der damalige Senior Vice President und General Manager von Intel, Patrick Gelsinger, dass es sich beim Larrabee um High-End-Grafikkarten auf Basis von „IA++“-Kernen handelt. Als Einsatzbereich gab Gelsinger wissenschaftliches Rechnen, Visualisierungen oder andere Anwendungen im Bereich Gesundheit und Analyse an.

Man war da wohl zu optimistisch, alle Einsatzbereiche (inklusive 3D-Gaming) mit einer Hardware abdecken zu können.

Ich sehe aber nicht, was Larrabee als Many-Core x86 Design mit Intels gegenwärtiger GPU-Architektur zu tun hat.
Ergänzung ()

strex schrieb:
Die andere Seite der Medaille ist natürlich die Treiberunterstützung. Im Bereich Spiele muss man da schon einiges an Arbeit reinstecken und laufend Anpassung durchführen. Das sieht man ja schon bei dem massiven Aufwand was NV betreiben hat, um DX11 zu beschleunigen.

Mit DX12 wird sich das aber zum Teil ändern, weil hier ein größerer Teil dieser Arbeit auf die Entwickler "ausgelagert" wurde.
Ergänzung ()

zeedy schrieb:
:lol: achso ja, dann haben sie ja Glück gehabt. Klar, Intel wäre absolut konkurrenzfähig, ist aber zu faul in dieses Geschäft einzusteigen...

Es lohnt sich finanziell schlichtweg nicht, weil damit kaum Geld zu verdienen ist. Deshalb steigt da Intel nicht ein. AMD verdient so gut wie nichts mit den GPUs und bei Nvidia stammt auch der größte Teil des Gewinns aus dem HPC-Bereich.

Für die paar Milliönchen, die mit diskreten GPUs zu verdienen sind, rührt Intel keinen Finger.
Im HPC-Business sind sie mit ihren Knights Corner/Landing Chips aber stark im Kommen und dort wird RICHTIG Geld verdient.
 
Zuletzt bearbeitet:
CCIBS schrieb:
Intel hat in den letzten Jahres was iGPU betrifft riesen Fortschritte gemacht und zu behaupten sie seien schlechter als die der Konkurrenz ist in der Zwischenzeit nicht mehr durch die Bank richtig.

Besonders was Energiesparr CPU betrift sind sie sehr stark.

Wo Intel wohl noch immer hinterher hinkt sind wohl die Treiber. Die sind zwar auch viel besser geworden, aber noch nicht auf dem Level der anderen beiden.

Einer der wenigen intelligenten Beiträge in diesem Thread :daumen:

Mickey Cohen schrieb:
eigenartig, dass amd das nie gemacht hat. jede firma in dieser branche lizenziert gewisse technologien.

Das wundert mich auch. Wahrscheinlich sitzen zu viele Dogmatiker in den Reihen von AMD. Ich bin mir sicher das die Probleme von AMD größtenteils hausgemacht sind. Das Intel fragwürdige Vertriebsmethoden anwendet steht allerdings außer Frage.

Siemens-Nixdorf schrieb:
Warum, die APUs sind doch Gurken. Die schnellsten Intel Iris Graphics schlagen jeden A10 mit Abstand.

Ja das mag im Moment so sein. allerdings kostet eine intel CPU mit Iris Pro Grafik auch wesentlich mehr als eine AMD APU.

So viel mehr das es sinnvoller ist eine dedizierte Grafikkarte mit ein AMD APU zu kombinieren. So bekommt man für das gleiche Geld bessere Spieleleistung und vor allem wesentlich bessere Treiber die regelmäßig gepflegt werden.

Ich rede hier aus leidlicher Erfahrung weil ziemlich viele Spiele auf meinem Notebook mit intel Grafik rumgezickt haben. Viele Spiele starten gar nicht oder haben in den Releasenotes dicke Hinweise stehen das intel nicht unterstützt wird. Von hässlichen Grafikfehlern und Abstürzen mal abgesehen...
 
psYcho-edgE schrieb:
Spiele damit auch, auf ner mobilen Intel GMA HD (i5 460M). Is auch nicht langsamer als die dedizierte NV 420M und für LoL auf 50fps in Mittel reicht es. :p

Deswegen muss ich15 Minuten im Ladebildschirm warten :p :D
 
jbauer schrieb:
Natürlich sind sie an AMD vorbei gezogen, dass wird auch von keinem hier bestritten. Jedoch wird von einigen behauptet, dass die Technik hinter der iGPU von Intel "überlegen" ist und daher die genannten Prozessoren schneller sind.

Gleich mehr:

Siemens-Nixdorf schrieb:
Warum, die APUs sind doch Gurken. Die schnellsten Intel Iris Graphics schlagen jeden A10 mit Abstand.
Intel Iris Pro Graphics schlägt den A10 jedoch nur auf Grund des eDRAM mit Abstand. Der eDRAM beschleunigt sogar den CPU-Teil bei Intel in bestimmten Szenarien gegenüber den CPUs ohne eDRAM, da er als L4-Cache agiert und sofern die Daten hinein passen.

Hier sind sogar sehr viele entsprechende Tests - sogar von Computerbase - verlinkt worden, hier ein weiterer: http://www.golem.de/news/core-i7-57...nd-edram-ueberraschend-flott-1506-114512.html. Man muss die Balken und Informationen nur mal etwas genauer betrachten und etwas besser seine Schlüsse ziehen.

So kann auch den Iris Pro CPUs der eDRAM zum Beispiel auch nur bis zu einem gewissen Punkt als Puffer agieren. Iris Pro verfügt über 48EUs bei 1150MHz, die anderen beiden um 20EUs bei 1250MHz. Die iGPU sollte also alleine technisch gut 100% schneller sein, was sie jedoch nicht immer ist. Also wird auch bei Intel die iGPU ausgebremst und kann seine theoretische Leistung nicht gänzlich umsetzten.

Gleich mehr:

CCIBS schrieb:
Hier mal in Erinnerung gerufen, der damalige Test von CB über die 5775c iGPU

https://www.computerbase.de/2015-06/intel-core-i7-5775c-test/2/
Andere Spiele, die bei entsprechenden Details nun gut über 100% zulegen gegenüber der schwächeren Grafik im Haswell, was wohl dafür spricht, dass der eDRAM gut als Puffer agieren kann. Sieht man sich die Speichertests an, mekt man aber auch, dass Intel bei den größeren iGPU durchaus von schnellerem Speicher profitiert. Genauso zeigt sich aber auch, dass die APU von AMD sogar die Leistung der Iris Pro erreicht, sofern das Speicherinterface nicht limitiert.

Da Intel wohl nun auch die höheren Ausbaustufen ohne eDRAM anbietet, müsste man dort nach sehen wie sich die Ausbaustufen mit den selben EU-Zahlen mit und eben ohne den eDRAM verhalten.

strex schrieb:
Das leidige Problem mit den Treibern und wohl auch ein Grund warum AMD Mantle initiiert haben. Wer die ersten Interviews und Berichte genau gelesen hat, stellt schnell fest: AMD geht es auch darum Verantwortung wieder zurück auf die Entwickler zugeben. In früheren DX Versionen liegt viel Verantwortung bei den GPU-Herstellern und dass diese API-Aufrufe für ihre Architektur zurecht biegen oder Murkscode von Entwicklern ihren GPUs schmackhaft machen.

DX12 und Vulkan zwingt Entwickler wieder dazu, ihren eigenen Code zu optimieren und sauber zu implementieren, statt einfach "schmutzig" ihre Aufrufe abzusetzten in DX und dann zu hoffen, dass die GPU-Hersteller das in ihren Treibern zurecht biegen.

@Kisser ...
Irgendwie kann man deine Beiträge echt nicht ernst nehmen. Du schreibst einen Bullshit zusammen, der geht auf keine Kuhhaut mehr. nVidia macht den meisten Gewinn mit dem HPC-Bereich? Öhm ... Rechenzentren (HPC-Bereich) machen gerade mal schlappe 82 000 000$ aus in deren Umsatz. ... Knapp über 750 000 000 werden durch den Bereich Gaming ausgemacht ... Der Gewinn liegt bei ca. 250 000 000 ... Die Margen im HPC-Bereich mögen höher sein, der Markt ist sicher jedoch nicht der Hauptgeldgeber für nVidia ...

Nun ja, wenn du schon dir bei solchen Sachen deine Argumente zurecht lügen musst, kann man deine Beiträge getrost ignorieren und nicht ernstnehmen. Entschuldige diese klare Aussage ...
 
Ich habe zum eigentlichen Thema nichts zu sagen, ausser: Wer nicht in den entsprechenden Abteilungen arbeitet, kann nichts genaueres Wissen. Es sei denn, es hat schon jemand von dort was ausgeplaudert... Alles andere ist wieder Spekulatius, mal mehr oder weniger schmackhaft.

OT zur iGPU
Denkt hier auch nur einer mal daran, daß AMD die schlechtere Effizienz hat, daß CPU und GPU Teil nicht zeitgleich mit voller Leistung laufen können. Das war mir mit meiner ersten AMD APU schon klar, seit dem THG Test des A10-7890K ist auch geklärt warum genau das so ist. Nennt sich Power Control.
Sobald man die GPU des A10 fordert, wird die CPU in der Leistungsaufnahme begrenzt. Leider gibt es (noch) keinen BIOS Hack der Power Control deaktiviert oder wenigstens anpassbar macht.
Würde man diese Bremse entfernen, sähe der Broadwell im Spieletest ganz schön alt aus.


edit: Ich lehne mich auch mal aus dem Fenster. Wenn man die BIOS Limits entfernt, die APU köpft und für gute Kühlung sorgt, hat man ein Spiel-System das sich vor einer Kombi aus entsprechenden Komponenten nicht verstecken muss,
 
Zuletzt bearbeitet:
Locuza schrieb:
Aus Hardwaresicht ist Intel schon seit Broadwell eleganter unterwegs, als AMD.
Shared Virtual Memory, Cache-Kohärenz usw. ist alles drin.
Zusätzlich genießt man bei Intel einen schönen LLC für CPU und GPU, aber das ist schon seit Sandy-Bridge, wenn auch damals noch primitiver, vorhanden.

Wo genau ist die Intel-Lösung eleganter?
Ergänzung ()

Bzgl. Grafik-Cache auf den Intels:

Ich denke es ist gut für AMD das AMD seinen Stiefel durchzieht, anstatt sich zu verzetteln. AMD hat dafür keine Ressourcen.
Welchen wirtschaftlichen haben den die Dinger mit eigenen Grafik-Cache für Intel gebracht?

Schaut man auf die Konsolen scheint Sony ohne speziellen Grafik-Cache im Moment den besseren Deal gemacht zu haben. Ob MS mit seinem Konvergenz über verschiedene Plattformen Gefängniscomputer Konzept dagegen anstinken kann wird die Zukunft zeigen. Jedenfalls bietet AMD/Khronos der Entertainment-Industrie mit Vulkan eine Alternative ohne Ihre Gewinne bei MS versteuern zu müssen, wenn sich die Entertainment-Industrie den einigen kann.

Ob das alles für AMD aufgeht wird sich zeigen, sich zu verzetteln wäre niemals aufgegangen. Ich bin jedenfalls vorsichtig optimistisch das das für AMD aufgeht.
 
Ich denke mal das Intel seinen Konkurrenten ein bisschen unterstützen wird damit dieser dem Markt erhalten bleibt.
 
zeedy schrieb:
Oh ein Fakt ja... Nein ich glaube nicht ;) Aber dein Gequatsche wenns um AMD geht, kennt man ja schon..

Mäßige mal deinen Ton, wenn du nicht sachlich diskutieren kannst, dann lass es doch einfach ganz.

Nur um ein paar echte Fakten zu erwähnen: 28nm vs 14nm; edRAM vs DDR3.

14nm und eDram, alles Dinge, die Intel hat und AMD nicht. Was kann AMD gleich noch mal besser?

Nächstes Jahr kommen Zen APUs mit Polaris iGPU, mal sehen was Intel dann zu bieten hat. Wenn AMD auch noch HBM auf dem Die direkt neben dem Kern verbaut, dann sieht Intel kein Land, das ist schon mal sicher.
Jo, und genau der gleiche Spruch kommt dann nächstes Jahr, nur mit Zen II, Vega und HBM2 statt Zen, Polaris und HBM.
Der Satz ist irgendwie beinahe eine allgemeingültige Konstante: "Nächstes Jahr wird AMD besser sein!"
 
jbauer schrieb:
Jo, und genau der gleiche Spruch kommt dann nächstes Jahr, nur mit Zen II, Vega und HBM2 statt Zen, Polaris und HBM.
Der Satz ist irgendwie beinahe eine allgemeingültige Konstante: "Nächstes Jahr wird AMD besser sein!"

Dann ist also die Entwicklung der letzten Jahre spurlos an Dir vorübergegangen?
Getreu nach dem Motto, AMD war immer scheisse und es wird so bleiben?
Igendwie beinahe eine allgemeingültige Konstante: "Nächstes Jahr wird AMD genauso beschissen sein!"
10041565.jpg
 
Zuletzt bearbeitet:
@ Teralios

Ich rede vom Gewinn und nicht vom Umsatz! Mach dir mal den Unterschied klar. ERST denken, DANN schreiben!
Vorerst: Teralios -> ignore-list
Wer jedes Mindestmaß an Benehmen vermissen lässt braucht mit mir nicht zu diskutieren!
Ergänzung ()

EchoeZ schrieb:
Sobald man die GPU des A10 fordert, wird die CPU in der Leistungsaufnahme begrenzt. Leider gibt es (noch) keinen BIOS Hack der Power Control deaktiviert oder wenigstens anpassbar macht.
Würde man diese Bremse entfernen, sähe der Broadwell im Spieletest ganz schön alt aus.

Dass AMDs GPU-Architektur kein Kostverächter ist, ist ja nicht neues. Die GPU kann alleine schon die TDP des Chips nahezu ausreizen, eine Umgehung der Powercontrol würde höchstens vielfach zu Schäden an den Boards führen, weil die Leistungsaufnahme um einiges nach oben klettern würde. Oder aber man müsste die Boards von vornherein auf höhere Leistungsaufnahme auslegen, was sie wiederum teurer machen würde.
 
Also wenn ich ein fertiges K_Modell eines beliebigen Herstellers nehme, und die CPU/APU übertakte, daß sie -ich meiss' einfach mal - 50W mehr Leistungsaufnahme hat, dann geht das Board kaputt?

Wenn ich so die Leistungsaufnahme sehe, die ein auf 5GHz übertakteter i7 benötigt, besteht die Gefahr das Board zu schädigen?


edit: Ich ging ja hier von der, erstmal, theoretischen Möglichkeit aus, mit geköpfter APU und evtl Wakü, dann Powercontrol wech, bzw Limits Stück für Stück ausdehnen.
Ich denke das die Funktion in erster Linie den DIE schützen soll.
Man müsste natürlich für einen praktischen Test ein Board wählen, das eine hohe Leistungsaufnahme am Sockel auch verträgt. Da stimme ich Dir zu, ein Standard FM2+ Board würde warscheinlich wegbrezeln.
 
Zuletzt bearbeitet:
Die Gefahr von Schäden besteht immer, wenn ein System außerhalb der dafür vorgesehenen Grenzen betrieben wird.
Wenn ein Board beispielsweise nur CPUs bis max. 95W TDP unterstützt, dann KANN es funktionieren, auch CPUs mit 125W TDP darauf laufen zu lassen. Allerdings ist die Spannungsversorgung der CPU dann überlastet und das KANN auf Dauer zu Schäden führen.
 
Zurück
Oben