App installieren
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
AMDs zukünftige APU/CPU-Strategie
- Ersteller BavarianRealist
- Erstellt am
Es muss garnichts geben, das war nur ein Beispiel von mir, wenn Jaguar HT & Dual Channel DDR3 hätte, dann warum nicht gleich auch ein MCM Package mit 2x Kabini DIEs bauen, das wäre vielleicht günstiger als Regor/Propus.Warum muss es unbedingt eine 8-Core-Version von Jaguar geben? Wie wäre es mit einer 6-Core-Variante und Dualchannel...als eigenes Derivat ähnlich dem Thuban? Acht Cores machen wären womöglich stark Bandbreiten-limitiert.
Übrigens, Jaguar Core = 3,1mm² @28nm & Bobcat = 4,9mm² @40nm
.
EDIT :
.
Der Speichercontroller wurde von 32 auf 40 Bit erweitert, wäre das Dual Channel würde sich das aufbohren eig. nicht lohnen.Und ich schreib einfach mal Dualchannel (aber wissen tu ich auch nix)
bbott
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 4.363
- Renomée
- 60
- Mein Laptop
- HP Compaq 8510p
- Prozessor
- AMD FX-8370
- Mainboard
- Asus M5A99X
- Kühlung
- Corsair H60
- Speicher
- 16GB DDR3-1866 Crucial
- Grafikprozessor
- Sapphire HD5770
- Display
- 4k 27" DELL
- SSD
- Samsung Evo 850
- HDD
- 2x Seagate 7200.12
- Optisches Laufwerk
- Pioneer, Plextor
- Soundkarte
- Creative X-Fi Xtreme Music
- Gehäuse
- Silverstone TJ-02S
- Netzteil
- Enermax 450W
- Betriebssystem
- Windows 7
Der Speichercontroller wurde von 32 auf 40 Bit erweitert, wäre das Dual Channel würde sich das aufbohren eig. nicht lohnen.
Wenn schon wurde der Adress-Raum von 32- auf 40-Bit erweitert, d. h. er kann mehr als 4BG ansprechen. Ein Speicher-Controller mit 40-Bit breiter Datenanbindung macht keinen Sinn.
Ja die Jaguar Kerne sollen nicht schlecht sein, 4 OoO Kerne mit 2MB L2, 128Bit FPU, alle SSE Befehle & AVX Instruction, +15% IPC & +10% Takt ist ein guter Fortschritt gegenüber Bobcat.
Abwarten wie groß die APU dann ausfallen wird, Bobcat ist in 40nm > 77mm² groß, Jaguar in 28nm sollte mit 4 Kerne nicht viel größer ausfallen.
Der einzige Nachteil ist Singlechannel DDR3 & kein FMA Support, sonst hätte man via HT & MCM 8 Kerne erwarten können, das wäre doch was eine APU mit 8 Kerne unter 200mm² bzw. 2x 80mm²
Bobcat- und Jaguar sind sehr gelungen, aber sie sind in ihren Funktionen auch bechränkt. Die Frage ist um wieviel die Diefläche diese Kerne ansteigen würden, wenn die Pilldriver Kerne auslaufen und er alle Einsatzgebiete abdecke müsste? Nicht das dieser Prozessor dann für sein Einsatzgebiet (Subnotebooks, Tabletts, Nettops, Netbooks) nicht mehr geeignet ist.
Wieso eigentlich eine APU mit 8 Kernen? Das versteh ich nicht, denn dort wo ein solcher Prozessor gut, ist auch der Bulldozer gut. Und die Softwarestruktur läuft doch auch nur langsam in diese Richtung. Über welchen Zeithorizont reden wir eigentlich?
Ist schwer, dieses Thema mit ein paar Worten zu erfassen. Die Thematik ist mir schon klar. Vielleicht hätte sich AMD ohne die Machenschaften von Intel auch gut im X86 Sektor behauptet.
Ist aber nicht. Jetzt geht es halt darum, die Zukunft zu gestalten.
Edit:
Ich meinte das es nicht am wollen gelegen hat oder das nichts in diesen Bereich getan wurde. Im Gegenteil zu den Athlon 64 Zeiten hat AMD verstärkt versucht ein Bein in die Tür der OEM, Serverhersteller und gr. Händler zu kommen. Das hat ja auch nur begrenzt funktioniert. Das ist nun Vergangenheit.
Ich sehe nicht umbedingt das AMD ein Hardware Problem hat. Selbst das Fazit bei CB zu Trinity und Vishera war recht positiv. Klar wäre jetzt ein günstigeres Design besser, nur ob nun AMD wesentlich besser da stehen würde (ich habe da meine Zweifel)? Ich hoffe mal das AMD durch die von dir aufgezählten neuen Geschäftsfelder zumindest mittel- bis langfristig besser da steht. Sondern das Drumherum passt nicht.
Dell scheint in Dtl. keine Rechner mehr mit AMD Prozessoren zu verkaufen. Zumindest auf ihrer HP oder bei Geizhals habe ich keine gefunden (Polen scheint für NB kauf ein lohnender Ort zu sein. Dort ist die Auswahl, auch bei den anderen Herstellern, wesentlich größer.) . Bei schlechten bis miesen Auswahl braucht man sich nicht zu wundern, dass auch die Verkäufe so sind (Falls jetzt jemand mit der fehlenden Nachfrage kommt. Darauf antworte ich nur: oft behaupet, nie bewiesen. Demnach müssten wir alle auch Glossy Displays wollen oder die massenhaften Probleme bei einer Hotline sind alle total neu)
Zuletzt bearbeitet:
amdfanuwe
Grand Admiral Special
- Mitglied seit
- 24.06.2010
- Beiträge
- 2.372
- Renomée
- 34
- Prozessor
- 4200+
- Mainboard
- M3A-H/HDMI
- Kühlung
- ein ziemlich dicker
- Speicher
- 2GB
- Grafikprozessor
- onboard
- Display
- Samsung 20"
- HDD
- WD 1,5TB
- Netzteil
- Extern 100W
- Betriebssystem
- XP, AndLinux
- Webbrowser
- Firefox
- Verschiedenes
- Kaum hörbar
Hier ein Inteview mit Dr Suresh Gopalakrishnan, server unit’s general manager and corporate VP
http://www.datacenterdynamics.com/focus/archive/2012/11/amd%E2%80%99s-server-business-what%E2%80%99s-next
http://www.datacenterdynamics.com/focus/archive/2012/11/amd%E2%80%99s-server-business-what%E2%80%99s-next
@fluant
Ich habe mich irgendwie falsch ausgedrückt: Intel hat OpenCL konsequent gemieden, bis man es nicht mehr konnte, weil es sich trotz(!) Intels konsequenter Nichtbeachtung inzwischen stark verbreitet hat und für parallele Programmierung eben zahlreiche Vorteile bietet. Jetzt muss man natürlich irgendwie auf die schon bestehende Situation am Markt reagieren.
Intel hat sein OpenCL SDK, welches in der ersten Version mehr schlecht als recht war, im Juli 2011 veröffentlicht (Die Spezifikation von OpenCL 1.0 stammt vom 18.November 2008 ). AMDs erste Implementierung war, soweit ich weiß, im Ati Stream SDK 2.0 im August 2009. In diesen zwei Jahren hat AMD im PC-Bereich (abgesehen von Apple) weitgehend alleine für OpenCL gekämpft, weil Nvidia sich stärker auf CUDA konzentriert hat.
Bis Juni 2012 war zudem AMDs OpenCL-CPU-Treiber auf Intel CPUs schneller als AMDs eigener Compiler, was angesichts von Intels allgemein bekanntem Compiler KnowHow ein desaströses Ergebnis ist. Das scheint man bei Intel nun endlich mit dem 2013er SDK hinter sich zu lassen (wohl nicht ganz zufällig zum Zeitpunkt der Markteinführung der XeonPhi).
Fakt bleibt aber: Es hätte mit OpenCL deutlich schneller gehen können, wenn Intel sich dem nicht so lange verweigert hätte. Intel macht die Dinge erst dann, wenn sie für sie selbst von Nutzen sind (was nachvollziehbar ist, schließlich sind die nicht die Wohlfahrt, sondern ein börsennotiertes Unternehmen), das führt aber dazu, dass AMD kaum Vorgaben machen kann, ohne sich daran kaputtzuarbeiten, wenn Intel nicht mitmacht. Gleichzeitig kann AMD seine Vorteile nicht ausspielen, weil Intel daran kein Interesse hat.
Es gibt eine Serie von Dingen, die AMD versucht hat zu etablieren und die letztlich an der Nichtunterstützung durch Intel gescheitert sind. (Dicke Ausnahme AMD64) Dagegen kann Intel Vorgaben ohne größere Schwierigkeiten am Markt durchdrücken, einfach durch die schiere Masse an Produkten, die damit auf den Markt kommen. (Dicke Ausnahme: IA64).
Das kostet halt ziemlich viel Energie und Geld bei AMD. Und das ist das Problem, wenn man einen riesigen Mitbewerber hat, der quasi alles blockieren kann, einfach indem er nicht mitzieht.
Und das trifft essentiell AMDs APU-Konzept. Man hatte einen handfesten Hardware-Vorteil, konnte ihn aber softwareseitig nicht nutzen, weil Intel erst mit einer OpenCL-Unterstützung in die Puschen kommt, wenn man den eigenen HW-Nachteil zumindest neutralisiert hat. Das macht Intel voraussichtlich mit Haswell (da AMD ja mit Kaveri offensichtlich noch länger braucht oder der gar nicht kommt oder wie auch immer).
Ich habe mich irgendwie falsch ausgedrückt: Intel hat OpenCL konsequent gemieden, bis man es nicht mehr konnte, weil es sich trotz(!) Intels konsequenter Nichtbeachtung inzwischen stark verbreitet hat und für parallele Programmierung eben zahlreiche Vorteile bietet. Jetzt muss man natürlich irgendwie auf die schon bestehende Situation am Markt reagieren.
Intel hat sein OpenCL SDK, welches in der ersten Version mehr schlecht als recht war, im Juli 2011 veröffentlicht (Die Spezifikation von OpenCL 1.0 stammt vom 18.November 2008 ). AMDs erste Implementierung war, soweit ich weiß, im Ati Stream SDK 2.0 im August 2009. In diesen zwei Jahren hat AMD im PC-Bereich (abgesehen von Apple) weitgehend alleine für OpenCL gekämpft, weil Nvidia sich stärker auf CUDA konzentriert hat.
Bis Juni 2012 war zudem AMDs OpenCL-CPU-Treiber auf Intel CPUs schneller als AMDs eigener Compiler, was angesichts von Intels allgemein bekanntem Compiler KnowHow ein desaströses Ergebnis ist. Das scheint man bei Intel nun endlich mit dem 2013er SDK hinter sich zu lassen (wohl nicht ganz zufällig zum Zeitpunkt der Markteinführung der XeonPhi).
Fakt bleibt aber: Es hätte mit OpenCL deutlich schneller gehen können, wenn Intel sich dem nicht so lange verweigert hätte. Intel macht die Dinge erst dann, wenn sie für sie selbst von Nutzen sind (was nachvollziehbar ist, schließlich sind die nicht die Wohlfahrt, sondern ein börsennotiertes Unternehmen), das führt aber dazu, dass AMD kaum Vorgaben machen kann, ohne sich daran kaputtzuarbeiten, wenn Intel nicht mitmacht. Gleichzeitig kann AMD seine Vorteile nicht ausspielen, weil Intel daran kein Interesse hat.
Es gibt eine Serie von Dingen, die AMD versucht hat zu etablieren und die letztlich an der Nichtunterstützung durch Intel gescheitert sind. (Dicke Ausnahme AMD64) Dagegen kann Intel Vorgaben ohne größere Schwierigkeiten am Markt durchdrücken, einfach durch die schiere Masse an Produkten, die damit auf den Markt kommen. (Dicke Ausnahme: IA64).
Das kostet halt ziemlich viel Energie und Geld bei AMD. Und das ist das Problem, wenn man einen riesigen Mitbewerber hat, der quasi alles blockieren kann, einfach indem er nicht mitzieht.
Und das trifft essentiell AMDs APU-Konzept. Man hatte einen handfesten Hardware-Vorteil, konnte ihn aber softwareseitig nicht nutzen, weil Intel erst mit einer OpenCL-Unterstützung in die Puschen kommt, wenn man den eigenen HW-Nachteil zumindest neutralisiert hat. Das macht Intel voraussichtlich mit Haswell (da AMD ja mit Kaveri offensichtlich noch länger braucht oder der gar nicht kommt oder wie auch immer).
Zuletzt bearbeitet:
Dresdenboy
Redaktion
☆☆☆☆☆☆
BTW aus den letzten Mercury-Zahlen ermittelt (von mir auf IH kopiert):
Nvidia: 11M units
AMD: 5.7M dGPUs + 7.8M iGPUs = 13.5M units
Nvidia: 11M units
AMD: 5.7M dGPUs + 7.8M iGPUs = 13.5M units
LoRDxRaVeN
Grand Admiral Special
- Mitglied seit
- 20.01.2009
- Beiträge
- 4.169
- Renomée
- 64
- Standort
- Oberösterreich - Studium in Wien
- Mein Laptop
- Lenovo Thinkpad Edge 11
- Prozessor
- Phenom II X4 955 C3
- Mainboard
- Gigabyte GA-MA790X-DS4
- Kühlung
- Xigmatek Thor's Hammer + Enermax Twister Lüfter
- Speicher
- 4 x 1GB DDR2-800 Samsung
- Grafikprozessor
- Sapphire HD4870 512MB mit Referenzkühler
- Display
- 22'' Samung SyncMaster 2233BW 1680x1050
- HDD
- Hitachi Deskstar 250GB, Western Digital Caviar Green EADS 1TB
- Optisches Laufwerk
- Plextor PX-130A, Plextor Px-716SA
- Soundkarte
- onboard
- Gehäuse
- Aspire
- Netzteil
- Enermax PRO82+ II 425W ATX 2.3
- Betriebssystem
- Windows 7 Professional Studentenversion
- Webbrowser
- Firefox siebenunddreißigsttausend
- Schau Dir das System auf sysprofile.de an
Puh, ich wusste nicht, dass AMD soviel weniger dGPUs absetzt, wie Nvidia. Erschreckend finde ich...
BavarianRealist
Grand Admiral Special
- Mitglied seit
- 06.02.2010
- Beiträge
- 3.358
- Renomée
- 80
Die Frage ist: woran liegt's? GCN braucht sich nicht zu verstecken.
Womöglich mag es Intel einfach nicht gern, wenn in Rechnern/Notebooks mit Intel-CPU eine AMD-Graka drin steckt...
Bis Juni 2012 war zudem AMDs OpenCL-CPU-Treiber auf Intel CPUs schneller als AMDs eigener Compiler, was angesichts von Intels allgemein bekanntem Compiler KnowHow ein desaströses Ergebnis ist. Das scheint man bei Intel nun endlich mit dem 2013er SDK hinter sich zu lassen (wohl nicht ganz zufällig zum Zeitpunkt der Markteinführung der XeonPhi).
Es wäre peinlich, wenn AMD trotz des Erfahrungsvorteils sich gleich vom ersten Intel SDK hätte übertrumpfen lassen müssen.
Fakt bleibt aber: Es hätte mit OpenCL deutlich schneller gehen können, wenn Intel sich dem nicht so lange verweigert hätte.
Hier erneut die Nachfrage, wo ist die Quelle für die Behauptung? AMD hat es doch nur wegen der GPUs gepusht. Natürlich pusht es derjenige, der davon im besonderen Maße profitieren kann. Und das ist bei AMD als Anbieter von schnellen GPUs der Fall. Oder meinst du mit den ollen GMA Krücken bis Clarkdale bzw. eigentlich SB hätte das einen besonderen Sinn gemacht? Abgesehen davon, dass die älteren iGPUs ohne frei programmierbaren EUs OpenCL inkompatibel sind. Oder möchtest du ernthaft kritisieren, dass Intel den CPU-OpenCL Support für Nehalem hätte bringen sollen? Als ob AMD sich so sehr mit OpenCL ins Zeug gelegt hätte, wenn sie nicht dafür gescheite GPUs besitzen würden. Das ganze APU Marketinggeschwafel war darauf ausgelegt. Intel ist ein Gründungsmitglied von OpenCL. Eine Verweigerung kannst du ohne sichere Beweisführung nicht in den Raum stellen. Du kannst höchstens fehlende dedizierte GPUs von Intel oder OpenCL fähige iGPUs kritisieren.
LinuS
Vice Admiral Special
Wenn das denn auch alles dGPUs bei nV sind. Wie sieht es denn z.B. mit Tegra bei nV aus? Sind die Verkaufszahlen davon in den Zahlen von Dresdenboy inbegriffen? Wenn ja, sieht die Sache doch gleich um einiges entspannter aus.LoRDxRaVeN schrieb:Puh, ich wusste nicht, dass AMD soviel weniger dGPUs absetzt, wie Nvidia. Erschreckend finde ich...
Dresdenboy
Redaktion
☆☆☆☆☆☆
Sorry, da fehlte in der Schnelle noch etwas Kontext Ich antwortete auf eine Diskussion wg. AMDs Anteil von 34% bei dGPUs in Notebooks.Wenn das denn auch alles dGPUs bei nV sind. Wie sieht es denn z.B. mit Tegra bei nV aus? Sind die Verkaufszahlen davon in den Zahlen von Dresdenboy inbegriffen? Wenn ja, sieht die Sache doch gleich um einiges entspannter aus.
Die restlichen Zahlen stehen hier:
http://investorvillage.com/mbthread.asp?mb=476&tid=12299056&showall=1
@fluant
Peinlich ist da gar nichts. Intel hat schließlich eine Menge KnowHow in dem bereich und hatte zwei Jahre Zeit einen entsprechenden Compiler und Treiber zu basteln.
Es ist ganz einfach so, dass Intel das Zeug nicht unterstützt hat. Aus fertig basta. Sie haben zwei Jahre länger gebraucht um einen entsprechenden Treiber zu veröffentlichen als AMD. Und anfangs war das auch nur ein CPU-Treiber (den hätte man tatsächlich auch schon für die Nehalems bringen können). Was haben die also zwei Jahre gemacht, wenn sie Gründungsmitglied sind? Sie haben sich zurückgelehnt und gedacht: Lass die mal machen.
Was muss ich da beweisen? Dass es mit OpenCL schneller gegangen wäre. Naja...das ist Spekulation, aber doch wohl eine nachvollziehbare. Oder warum sollte nun Intel jetzt plötzlich sonst auf die Idee kommen, dass OpenCL doch eine gute Lösung ist...?
Aber um meine Argumentation noch etwas auszuweiten, um was es mir geht:
OpenCL kann deutliche Vorteile bei parallelisierbaren Workloads bringen, da stimmst Du mir doch zu oder?
Und genau dafür hatte AMD eine Hardware- und Software-Lösung, nämlich die Möglichkeit via OpenCL CPU und GPU gemeinsam für Rechenaufgaben zu nutzen.
Doch um das zu etablieren braucht man Entwickler, die sich auf sowas einlassen.
Nun ist es im x86-Softwarebereich (und auch woanders) aber so: Die Programmierer schauen sich erstmal an, was der Markt unterstützt, bevor sie anfangen für exotische Nischen zu programmieren. (Kosten-/Nutzenrechnung).
Und wenn Intel etwas nicht unterstützt, dann ist AMD leider so eine exotische Nische.
Nun hat Intel zwei Jahre lang nicht mitgezogen, was OpenCL angeht. Keine Treiber (der CPU-Treiber von AMD hat ja netterweise auch mit Intel-CPUs funktioniert), keine Tools, kein gar nichts.
AMD stand alleine, hat die Entwickler beackert und teils finanziert, hat Tools entwickelt, hat die Werbetrommel gerührt. Intel hat in der Zeit was gemacht? Genau....gar nichts. Müssen sie auch nicht. Darum geht´s mir nicht. intel hat nicht unfair gespielt. Aber sie können Innovationen verhindern, einfach indem sie nicht mitziehen.
Und zu was führt das: AMD strampelt sich mit einer eigentlich super Möglichkeit tot. Viel Aufwand, wenig Nutzen. Und das liegt einzig und allein an der Marktverteilung im x86-Bereich. Und daher meinte ich wäre der x86-bereich für AMD eine Sackgasse und mit jedem Tag an dem man Marktanteile verliert, wird´s ein bisschen enger.
Peinlich ist da gar nichts. Intel hat schließlich eine Menge KnowHow in dem bereich und hatte zwei Jahre Zeit einen entsprechenden Compiler und Treiber zu basteln.
Es ist ganz einfach so, dass Intel das Zeug nicht unterstützt hat. Aus fertig basta. Sie haben zwei Jahre länger gebraucht um einen entsprechenden Treiber zu veröffentlichen als AMD. Und anfangs war das auch nur ein CPU-Treiber (den hätte man tatsächlich auch schon für die Nehalems bringen können). Was haben die also zwei Jahre gemacht, wenn sie Gründungsmitglied sind? Sie haben sich zurückgelehnt und gedacht: Lass die mal machen.
Was muss ich da beweisen? Dass es mit OpenCL schneller gegangen wäre. Naja...das ist Spekulation, aber doch wohl eine nachvollziehbare. Oder warum sollte nun Intel jetzt plötzlich sonst auf die Idee kommen, dass OpenCL doch eine gute Lösung ist...?
Aber um meine Argumentation noch etwas auszuweiten, um was es mir geht:
OpenCL kann deutliche Vorteile bei parallelisierbaren Workloads bringen, da stimmst Du mir doch zu oder?
Und genau dafür hatte AMD eine Hardware- und Software-Lösung, nämlich die Möglichkeit via OpenCL CPU und GPU gemeinsam für Rechenaufgaben zu nutzen.
Doch um das zu etablieren braucht man Entwickler, die sich auf sowas einlassen.
Nun ist es im x86-Softwarebereich (und auch woanders) aber so: Die Programmierer schauen sich erstmal an, was der Markt unterstützt, bevor sie anfangen für exotische Nischen zu programmieren. (Kosten-/Nutzenrechnung).
Und wenn Intel etwas nicht unterstützt, dann ist AMD leider so eine exotische Nische.
Nun hat Intel zwei Jahre lang nicht mitgezogen, was OpenCL angeht. Keine Treiber (der CPU-Treiber von AMD hat ja netterweise auch mit Intel-CPUs funktioniert), keine Tools, kein gar nichts.
AMD stand alleine, hat die Entwickler beackert und teils finanziert, hat Tools entwickelt, hat die Werbetrommel gerührt. Intel hat in der Zeit was gemacht? Genau....gar nichts. Müssen sie auch nicht. Darum geht´s mir nicht. intel hat nicht unfair gespielt. Aber sie können Innovationen verhindern, einfach indem sie nicht mitziehen.
Und zu was führt das: AMD strampelt sich mit einer eigentlich super Möglichkeit tot. Viel Aufwand, wenig Nutzen. Und das liegt einzig und allein an der Marktverteilung im x86-Bereich. Und daher meinte ich wäre der x86-bereich für AMD eine Sackgasse und mit jedem Tag an dem man Marktanteile verliert, wird´s ein bisschen enger.
Zuletzt bearbeitet:
LinuS
Vice Admiral Special
Besten Dank für die Quelle. Nun dann sind die Werte von nV in der Tat lediglich die dedizierten Karten im Notebookbereich. Dies hört sich dann in der Tat recht schlimm für AMD an. Nun kann man aber immernoch vorhalten, dass dies mit der nächsten Generation von Grafikeinheiten wieder genau umgekehrt aussehen kann. Gerade dort schwanken die "Baufirmen" doch heftig zwischen AMD und nV.Sorry, da fehlte in der Schnelle noch etwas Kontext Ich antwortete auf eine Diskussion wg. AMDs Anteil von 34% bei dGPUs in Notebooks.
Die restlichen Zahlen stehen hier:
http://investorvillage.com/mbthread.asp?mb=476&tid=12299056&showall=1
Mit Haswell & Ultrabook wird Nvidia wieder großen Boden verlieren, anders als Sandy/Ivy Bridge werden die Ultrabooks keine dedizierte Grafikkarten mehr brauchen, durch den Wachstum von Ultrabooks wird der Marktanteil von Nvidia Grafikchips dann Zeit für Zeit schrumpfen.
RICHTHOFEN
Admiral Special
- Mitglied seit
- 07.12.2001
- Beiträge
- 1.086
- Renomée
- 8
Mit Haswell & Ultrabook wird Nvidia wieder großen Boden verlieren, anders als Sandy/Ivy Bridge werden die Ultrabooks keine dedizierte Grafikkarten mehr brauchen, durch den Wachstum von Ultrabooks wird der Marktanteil von Nvidia Grafikchips dann Zeit für Zeit schrumpfen.
Die Argumentation ist doch sehr dünn. Wenn es danach geht bräuchte schon heute kaum mehr einer eine dedizidierte GPU. Verbaut wirds trotzdem. Verkauft sich halt besser. Den Abgesang auf dedizidierte GPUs höre ich nun schon seit Jahren und trotzdem macht Nvidia nach wie vor ausgezeichnete Umsätze damit. Der einzige die richtig Federn gelassen hat ist AMD. AMD GPU + Intel CPU ist anscheinend nicht sonderlich beliebt.
Zuletzt bearbeitet:
sompe
Grand Admiral Special
- Mitglied seit
- 09.02.2009
- Beiträge
- 14.493
- Renomée
- 2.030
- Mein Laptop
- Dell G5 15 SE 5505 Eclipse Black
- Prozessor
- AMD Ryzen 9 3950X
- Mainboard
- MSI MPG X570 GAMING PRO CARBON WIFI
- Kühlung
- Wasserkühlung
- Speicher
- 4x 16 GB G.Skill Trident Z RGB, DDR4-3200, CL14
- Grafikprozessor
- AMD Radeon RX 6900 XT
- Display
- 1x 32" LG 32UD89-W + 1x 24" Dell Ultrasharp 2405FPW
- SSD
- Samsung SSD 980 PRO 1TB, Crucial MX500 500GB, Intel 600p 512GB, Intel 600p 1TB
- HDD
- Western Digital WD Red 2 & 3TB
- Optisches Laufwerk
- LG GGC-H20L
- Soundkarte
- onboard
- Gehäuse
- Thermaltake Armor
- Netzteil
- be quiet! Dark Power Pro 11 1000W
- Betriebssystem
- Windows 10 Professional, Windows 7 Professional 64 Bit, Ubuntu 20.04 LTS
- Webbrowser
- Firefox
Ob er dann endlich der GPU des Llano/Trinity paroli bieten kann....?
Mal ganz ehrlich...die GPU des IB wurde zum Teil auch als Llano Killer gehandelt und was blieb davon übrig?
Wer mehr GPU Leistung will wird auch ein entsprechendes Modell kaufen wollen oder sollen diese gleich zu Apple gehen?
Mal ganz ehrlich...die GPU des IB wurde zum Teil auch als Llano Killer gehandelt und was blieb davon übrig?
Wer mehr GPU Leistung will wird auch ein entsprechendes Modell kaufen wollen oder sollen diese gleich zu Apple gehen?
boxleitnerb
Vice Admiral Special
- Mitglied seit
- 27.01.2008
- Beiträge
- 517
- Renomée
- 5
Die iGPU von Haswell "GT3" ist eine Verdopplung der "GT2 " GPU, was willste dann noch mit einer dezidierten GPU im Ultrabook Markt?
Sry für das offtopic.
An eine dedizierte GPU wird man trotzdem nicht (überall) rankommen. Und 2014 gibts dann wieder 70% mehr Leistung.
mariahellwig
Grand Admiral Special
Mit Haswell & Ultrabook wird Nvidia wieder großen Boden verlieren, anders als Sandy/Ivy Bridge werden die Ultrabooks keine dedizierte Grafikkarten mehr brauchen, durch den Wachstum von Ultrabooks wird der Marktanteil von Nvidia Grafikchips dann Zeit für Zeit schrumpfen.
Jau. Kommt hinzu das Intel mit Phi nVidias Premiumprodukte angräbt. Für nVidia wird es hart.
ONH
Grand Admiral Special
Wie hoch ist der apfel-Anteil?
Wird auch Weltweit 5% geschätzt. Somit wird wohl der Hauptteil vom Martanteilzuwachs durch Apple zustandekommen, und das der bei Notebook höher liegt wird wohl daran ligen das Apple in denn iMacs auch Notebook HW verwendet.
Bond.007
Admiral Special
- Mitglied seit
- 13.02.2003
- Beiträge
- 1.097
- Renomée
- 7
- Standort
- Berlin
- Mein Laptop
- Dell XPS M1330 mit Win7
- Prozessor
- Xeon E5-2696 v4 --> 22Cores!!
- Mainboard
- Asrock X99 WS
- Kühlung
- Corsair Hydro Series H110 mit 2x Noctua NF-A14 PWM
- Speicher
- 32GB Crucial DDR4-2133
- Grafikprozessor
- Palit GeForce GTX 1650 KalmX Passiv
- Display
- Eizo EV2455-BK
- SSD
- Samsung SSD 980 PRO 2TB; 2x Samsung 870 Evo 4TB
- Optisches Laufwerk
- 3x LG UHD BluRay
- Soundkarte
- OnBoardSound
- Gehäuse
- Lian Li PC-B25FB Blue Ring + 3x120er S2 Noiseblocker Multiframe Lüfter + beQuiet Dämmset
- Netzteil
- Sea Sonic Platinum Series Fanless 400W
- Betriebssystem
- Win 10 Pro
- Webbrowser
- Chrome
- Verschiedenes
- Idle: 55W und max: 195W, sehr sparsam und wahnsinnig schnell.
Jau. Kommt hinzu das Intel mit Phi nVidias Premiumprodukte angräbt. Für nVidia wird es hart.
Ist das ein nVidia-Untergangsprognose Thread oder ein Amd/Apu Zukunftsaussichten Thread?
FredD
Gesperrt
- Mitglied seit
- 25.01.2011
- Beiträge
- 2.472
- Renomée
- 43
Soweit auch meine (bisherige) Einschätzung. Ich bin der Sache mal auf den Grund gegangen.
http://images.apple.com/pr/pdf/q3fy12datasum.pdf
Unit Sales 2012 (Q2 + Q3)
2,2 Mio iMac
5,8 Mio MacBook Pro ("Mac Portable")
Wenn ich das richtig sehe, sind in jedem iMac und jedem MacBook eine Ivy Bridge CPU und eine Kepler GPU verbaut. Apple als Zünglein an der rot-grünen Waage ? - von wegen!
http://images.apple.com/pr/pdf/q3fy12datasum.pdf
Unit Sales 2012 (Q2 + Q3)
2,2 Mio iMac
5,8 Mio MacBook Pro ("Mac Portable")
Wenn ich das richtig sehe, sind in jedem iMac und jedem MacBook eine Ivy Bridge CPU und eine Kepler GPU verbaut. Apple als Zünglein an der rot-grünen Waage ? - von wegen!
Ähnliche Themen
- Antworten
- 0
- Aufrufe
- 470
- Antworten
- 2
- Aufrufe
- 1K
- Antworten
- 0
- Aufrufe
- 5K
- Antworten
- 0
- Aufrufe
- 917
- Antworten
- 0
- Aufrufe
- 657