NVIDIA entwickelt Project Denver: ARM Desktop CPU

[Coda]

Und bei wie vielen Programmen und Tools werden denn konsequent die Windows APIs benutzt? Das dürfte die deutliche Minderheit sein...
In einem Protected Mode OS können Programme nur die zur Verfügung gestellten APIs nutzen und sonst nichts.

Solange das OS komplett portiert wird - wovon ich ausgehe - ist es theoretisch wirklich nur eine Rekompilierung. Praktisch gibt's natürlich aber solche Probleme, dass 3rd party Libs nur für x86 zur Verfügung stehen oder Little vs. Big Endian.

Ist es denn wirklich realistisch mit sagen wir .NET eine performante 3D Engine zu entwickeln? Beim restlichen Code eines Spiels könnte ich mir .NET ja noch eher vorstellen - aber die Performance-kritischen Sachen?
Das ist heutzutage meiner Meinung nach kein Problem mehr. Die VMs haben in den letzten Jahren enorme Fortschritte gemacht. Und generell wird die Performance von .NET und Java maßlos unterschätzt. Vor allem ist das schöne, dass alle Programme mit einer besseren VM auf einmal schneller sind.

Da stehen nur die Konsolen mit ihren kleinen Hauptspeichern im Weg. Leider.

[iFanatiker]

Richtig, das ist auch schon egal. Denn trotz all der Pfennigfuchserei sieht man nämlich das ARM bereits jetzt in ähnlichen Größenordnungen performt wie die Intel CPUs. Beim Energieverbrauch liegen noch mehrere Größenordnungen dazwischen, aber bei der performance liegt man zwar wenn auch nicht auf Augenhöhe, so zumindest schonmal auf Schussweite. Und das jetzt schon, ohne A15 Eagle und ohne Desktopausrichtung.
So eine gute Ausgangsposition kann man von Via nicht behaupten, dabei bauen die schon seit jahzehnten Desktop CPUs.

Aehmmmm...ich sehe nur, daß ein Cortex A9 mit 2 GHz ungefähr die doppelte Leistung eines Atom N270 bringt und dies in einen Benchmark welcher fast zu 100 % mit der Anzahl der Cores skaliert (zwei gegen einen).

Vergleichen wir es also mit dem aktuellen N550 (der N270 wird IMHO nicht mal mehr von Intel verkauft)....wird in diesem Benchmark also ungefähr Gleichstand rauskommen und dabei ist ein Cortex A9 mit 2 GHz auf dem Markt IMHO noch gar nicht als fertiges Produkt vorhanden (nur als IP). Das höchste der Gefühle war zur Zeit in großen Massen erhältlich ist, ist der Tegra 2 mit 1 GHz.

Fazit:

Ein absoluter High-End Cortex A9 schlägt die absolute Einstiegs x86 CPU, welche sogar mit In-Order kommt und gar nicht mal die Taktvorteile auspielt (eigentlich könnte Intel eben den Atom noch höher prügeln wenn sie wollten), recht knapp bei der IPC in diesem Benchmark. Dazu ist es eben ein recht spezieller Benchmark.

Würde Intel wollen wäre wohl auch ein Z5xx Dual-Core mit unter 4 Watt kein Problem und dabei werden die Atoms eben immer noch in 45 nm gefertigt (gegenüber 40 nm für Cortex A9).

ich behaupte das gegenteil, welcher programmierer hat schon die zeit seine eigenen apis zu entwickeln?

Ja...alle "Programmierer" arbeiten alle im stillen dunklen Keller......NOT

Klener Exkurs in moderne Softwarentwicklung:

Wer garantiet, daß verwendete Midware z. B. keine "Optimierungen" enthält? Wir haben hier für unsere Windows Produkte Bibliotheken im Einsatz die vor 10 Jahren gekauft wurden und einfach laufen.....und die Herstelelr gibt es nicht mal mehr.

[Coda]

Wer garantiet, daß verwendete Midware z. B. keine "Optimierungen" enthält? Wir haben hier für unsere Windows Produkte Bibliotheken im Einsatz die vor 10 Jahren gekauft wurden und einfach laufen.....und die Herstelelr gibt es nicht mal mehr.
Das ist tatsächlich wohl das größte Problem.

Deshalb braucht man auch etwas wie Rosetta für alte x86 Applikationen. Die neueren können hoffentlich rekompiliert werden oder sind ohnehin schon .NET.

[Gipsel]

Schön dass du EEMBC mal gegooglet hast und weißt das es die nicht erst seit gestern gibt.Ähm, der Link auf deren Website war schon in der von mir verlinkten Aussage des Dhrystone-Authors von 1999, noch bevor Du mit den Werten angekommen bist. :rolleyes:
Dann informiere dich mal besser, es gibt diverse Gründe wieso coremark besser als drystone ist.Daß der Code etwas moderner als der Dhrystone-Kram ist, bleibt ja unbenommen. Trotzdem ist etwas, das vollkommen aus dem L1 läuft nicht wirklich realistisch, was EEMBC ja (wie von mir oben zitiert) ausdrücklich selber so sagt. Zumal alle Benchmarks auf die Bedürfnisse von embedded Systemen zugeschnitten wurden und nicht wirklich Wert auf die im Desktopsegment durchaus üblichen Sachen legen.
Denk mal drüber nach was man überhaupt für benches nehmen kann, wenn man die cpu-architektur, nicht den speicher, nicht den compiler, etc. testen will. da ist coremark schon ziemlich das einzige.Vielleicht denkst Du mal darüber nach, ob die Cache-Struktur, die Speicher-Interfaces und die ganze Systemarchitektur nicht auch irgendwie in der Praxis eine Rolle spielen. Daß die L/S-Einheiten einer modernen CPU so groß sind wie ein ganzer ARM-Core, hat z.B. nichts damit zu tun, daß x86 ineffizient wäre oder so. Da wird einfach mehr Aufwand getrieben. Und überlege mal, wie lange Intel bzw. AMD da schon dran rumbasteln und wieviel das wohl bringt.

Aber um Deiner Aufforderung nachzukommen und in Anbetracht der von nvidia vorgegebenen Ausrichtung auch auf Workstations und Server wäre ich für SpecInt und SpecFP. Dann haben wir nämlich mal einen Test der kompletten Architektur, der Compiler, der Caches, des Speicherinterfaces usw., also alles das, was CoreMark ausläßt. ;D
Ich kann mich nur wiederholen. Die Tatsache dass Coremark aus dem Cache läuft ist nur fair, denn ein 32bit LP-DDR Interface wollen wir nun wirklich nicht mit dem 192bit DDR3 Interface eines Bloomfields vergleichen. Auch was das cachesystem angeht hat der ARM wegen seiner ausrichtung auf LowPower eher Nachteile. Das wird sich als DesktopCPU jedenfalls ändern.Egal ob fair oder nicht, es ist einfach nicht realistisch für reale Anwendungen. Wenn die Performance eine Klippe runterfällt, sobald ein paar Speicherzugriffe stattfinden, dann ist das sehr wohl praxisrelevant. Und wenn ich das richtig sehe, gibt es den Cortex A9 mit bis zu 8 MB L2 (im Tegra2 ist 1 MB verbaut). Bis da erkennt man jetzt irgendwie nicht wirklich einen Nachteil. Und wie ich oben schon mal angedeutet habe, ist es nicht damit getan, mal so eben ein breiteres Speicherinterface dranzuklemmen (das liegt sowieso im Verantwortungsbereich des jeweiligen Nutzers, im Macro ist es nicht dabei, nur ein Interface mit mit 16 Bytes / 5 Takte Bandbreite zur Anbindung an die Außenwelt wird bereitgestellt). Das könnte so ein Cortex A9 wohl überhaupt nicht effizient nutzen. Da sind deutlich mehr Anpassungen nötig, die eben *nicht* unbedingt ganz einfach sind.
Ja das ist Wahnsinn! bei 2-3mm² pro core in 40nm vs 32nm beim Atom.Wie fondness schon sagte, gibt es momentan keine 32nm Atoms.

Ein Cortex A9 dual Core im taktoptimierten Design ohne L2 mißt laut ARM 6,7mm² in TSMCs 40G Prozeß. Zwei Bobcat-Kerne im gleichen Prozeß messen (auch ohne L2) etwa 9,2 mm². Der Bobcat hängt einen Atom (der bei Coremark taktbereinigt ~10% hinter einem Cortex A9-Kern liegt, ein wenig blöd wegen HT, aber das sind die von Dir ausgebuddelten Zahlen) ja doch zumeist ab (okay, HT hilft dem Atom oft schon, aber laß uns sagen, es liegt in etwa auf einem Level). Hast Du schon mal Fließkomma-Benchmarks vom ARM gesehen (spaßenshalber z.B. mal 'ne Matrixmultiplikation)? Also wenn das mit dem A9 nicht wesentlich schneller geworden ist (der A8 lag so etwa bei 1/4 der Leistung eines Atom, ohne Vektorerweiterung sogar noch mehr; edit: laut ARM ist die A9 FPU doppelt so schnell, man liegt also nur noch Faktor 2 hinter Atom), sieht es da ganz schnell ganz düster aus. Denke Dir noch ein paar Speicherzugriffe dazu und Du verstehst vielleicht, wie ich zu meiner Einschätzung der für ernsthafte Anwendungen zu geringen Performance komme.

Und bei der Stromverbrauchsangabe von 1,9W für den 2GHz CortexA9 DualCore sollte man auch im Hinterkopf behalten, daß das wohl die Angabe nur für die Kerne ist, also ohne L2, ohne Speicherinterface, ohne Grafik. Das alles ist in der Zacate-TDP natürlich schon mit drin. Allein vom Flächenvergleich (ein Bobcat-Kern nimmt nur ~6% der kompletten Die-Fläche ein), würde es mich schon etwas wundern, wenn ein Bobcat@1.6GHz wirklich mehr als 3 Watt verbraten sollte (AMD sagt nicht umsonst "sub 1 W capable", bei 1 GHz kann das schon bald hinkommen). Da liegen also mitnichten Größenordnungen beim Stromverbrauch dazwischen, ich würde ein Maximum von Faktor 3 tippen.

Achja, mal so nebenbei, die Coremark-Werte des A9, die Du oben zitiert hast, sind von einer FPGA-Simulation (lief mit 1.0 MHz) hochskaliert. Real gemessen sind die nämlich nicht. Das Ergebnis der FPGA-Simulation wurde genau 2 Tage vor dem Heise-Artikel, dem Du die Grafik entnommen hast, veröffentlicht ;)
Den Rückschluss auf die Anwendungen machst im moment alleine du.Hallo? Die schlußendliche Anwendungsperformance ist natürlich das Entscheidende und war auch gemeint, wenn hier im Thread von Performance gesprochen wurde! Du bist mit den eher theoretischen und nicht auf die Anwendungsperformance übertragbaren Benchmarks angekommen. Aber die theoretische (Int-)Peakperformance eines uralten PentiumPro war taktnormiert die gleiche wie die vom Core2 oder Phenom, der Bulldozer wird sogar eine niedrigere aufweisen. Ich denke trotzdem, daß BD in Anwendungen auch auf 200MHz runtergetaktet einen PentiumPro in so ziemlich allen relevanten Benchmarks um Längen schlagen würde.
[..]So eine gute Ausgangsposition kann man von Via nicht behaupten, dabei bauen die schon seit jahzehnten Desktop CPUs.Ja, die kamen auch aus dem Low-Performance/Low-Power (okay, schon mehr als die ARMs) Sektor. Haben dann jahrelang dran rumentwickelt, die Architektur aufgebohrt, Features dazugepackt (out of order, Spekulation, MultiCore, SIMD-Erweiterungen usw.). Schlußendlich stieg der Stromverbrauch deutlich an (die sind doch jetzt auch schon bei locker über 20W, oder?), die Performance-Relation zu High-End-CPUs ist aber im Prinzip immer noch mies. Die können vielleicht mit den Einstiegsmodellen der beiden größeren Anbieter mithalten. Also diese Entwicklung sollte (und wird es auch imo) nvidia dringend deutlich überbieten.

[Fattyman]

Hast Du schon mal Fließkomma-Benchmarks vom ARM gesehen (spaßenshalber z.B. mal 'ne Matrixmultiplikation)? Also wenn das mit dem A9 nicht wesentlich schneller geworden ist (der A8 lag so etwa bei 1/4 der Leistung eines Atom, ohne Vektorerweiterung sogar noch mehr; edit: laut ARM ist die A9 FPU doppelt so schnell, man liegt also nur noch Faktor 2 hinter Atom), sieht es da ganz schnell ganz düster aus.
Tja und da käme dann NVidias KnowHow aus der Grafikkartenschiene ins Spiel. Die sollten doch eine ziemlich performante FPU-Implementation einbringen bringen können.

[Gipsel]

Tja und da käme dann NVidias KnowHow aus der Grafikkartenschiene ins Spiel. Die sollten doch eine ziemlich performante FPU-Implementation einbringen bringen können.
Nur sehr bedingt.
GPU:
sehr kompakt aber hohe Latenz
(z.B. ATI: 8 Takte bei <1GHz; nvidia: ~20 Takte bei <2 GHz)
CPU:
ziemlich groß aber deutlich niedrigere Latenz
(3 bis 5 Takte bei >3 GHz)

Für normale Operationen wie Additionen/Multiplikationen das Ganze natürlich.

[Coda]

Wobei ein guter Engineer eigentlich beides bauen können sollte.

Von der Logik müsste man aber wohl völlig neu anfangen. Weniger Pipeline-Stufen und dafür breiter.

Mathematisch könnte ich mir aber schon vorstellen, dass einige Tricks bei beidem funktionieren.

[Gipsel]

Wobei ein guter Engineer eigentlich beides bauen können sollte.

Von der Logik müsste man aber wohl völlig neu anfangen. Weniger Pipeline-Stufen und dafür breiter.

Mathematisch könnte ich mir aber schon vorstellen, dass einige Tricks bei beidem funktionieren.
Na klar, Addierer (sind wirklich kein Problem) und Multiplier baut man ja auch nicht erst seit gestern, die Tricks beim Design sind natürlich bei den entsprechenden Engineers schon bekannt.
Allerdings wird sowas Kritisches in CPUs schon per Hand auf die Eigenschaften des jeweiligen Prozesses getrimmt. Das ist dann schon ein etwas anderes Geschäft. Und die Anforderungen an die Registerfiles bei CPU(-FPU)s sehen ebenfalls anders als bei GPUs aus (da haben Zugriffe auch eine recht hohe Latenz, das geht bei CPUs natürlich nicht).

Edit:
Ich muß wirklich mal an der Masse der Füllwörter in meinem Geschreibe arbeiten, so oft wie da "schon" drinsteht X-D

[hell_bird]

Nur sehr bedingt.
GPU:
sehr kompakt aber hohe Latenz
(z.B. ATI: 8 Takte bei <1GHz; nvidia: ~20 Takte bei <2 GHz)
CPU:
ziemlich groß aber deutlich niedrigere Latenz
(3 bis 5 Takte bei >3 GHz)

Für normale Operationen wie Additionen/Multiplikationen das Ganze natürlich.
bedeutet das, dass man in einer APU sogar soetwas wie SSE zusätzlich braucht, da über den "GPU-Teil" die Latenz zu groß wäre?


Allerdings wird sowas Kritisches in CPUs schon per Hand auf die Eigenschaften des jeweiligen Prozesses getrimmt. Das ist dann schon ein etwas anderes Geschäft. Und die Anforderungen an die Registerfiles bei CPU(-FPU)s sehen ebenfalls anders als bei GPUs aus (da haben Zugriffe auch eine recht hohe Latenz, das geht bei CPUs natürlich nicht).

man sollte nicht vergessen, dass nvidia sich nach Aussage vom Chef eine Menge Leute zusammengekauft hat, die schon eine Weile im CPU Geschäft sind

[Coda]

bedeutet das, dass man in einer APU sogar soetwas wie SSE zusätzlich braucht, da über den "GPU-Teil" die Latenz zu groß wäre?
Natürlich.

[Tesseract]

Und bei wie vielen Programmen und Tools werden denn konsequent die Windows APIs benutzt? Das dürfte die deutliche Minderheit sein...

es muss ja nicht unbedingt nur die windows API sein. im prinzip tut es jede lib, die es auf der plattform gibt. das trifft z.B. bei spielen auf die großen lizenzengines (z.B. unreal engine) sowieso zu, die einen nicht unerheblichen teil der spiele ausmachen und auf viele custom engines inzwischen ebenso weil man ja auch auf den konsolen mitspielen (pun intended) will.
auch viele größere softwaresuites sind inzwischen (oder eh schon länger) relativ plattformunabhängig, schon allein deswegen weil man die software für z.B. windows und mac anbietet.
und open source projekte sowieso.

betroffen sein wird hauptsächlich diverse (heft-cd-)crapware, für die es alternativen gibt und eine reihe (teilweise lange laufende) bussiness-software. das erste ist relativ egal weil es massig alternativen gibt und für das zweite könnte man eine art kompatiblity-layer einbauen. wäre wohl nicht der erste. :D

also so schwarz würde ich das nicht sehen. natürlich ist das nicht von einem tag auf den anderen getan, aber sooo unmöglich ist das dann auch wieder nicht.

[xxxgamerxxx]

es muss ja nicht unbedingt nur die windows API sein. im prinzip tut es jede lib, die es auf der plattform gibt. das trifft z.B. bei spielen auf die großen lizenzengines (z.B. unreal engine) sowieso zu, die einen nicht unerheblichen teil der spiele ausmachen und auf viele custom engines inzwischen ebenso weil man ja auch auf den konsolen mitspielen (pun intended) will.
auch viele größere softwaresuites sind inzwischen (oder eh schon länger) relativ plattformunabhängig, schon allein deswegen weil man die software für z.B. windows und mac anbietet.
und open source projekte sowieso.

betroffen sein wird hauptsächlich diverse (heft-cd-)crapware, für die es alternativen gibt und eine reihe (teilweise lange laufende) bussiness-software. das erste ist relativ egal weil es massig alternativen gibt und für das zweite könnte man eine art kompatiblity-layer einbauen. wäre wohl nicht der erste. :D

also so schwarz würde ich das nicht sehen. natürlich ist das nicht von einem tag auf den anderen getan, aber sooo unmöglich ist das dann auch wieder nicht.

Das ändert aber nichts daran, dass diese abstrakten Layer trotzdem die entsprechenden APIs der jeweiligen OSse verwenden. Je mehr dieser Layer dazwischen sind, desto mehr muss man natürlich hoffen, dass die Maintainer diese auch für die entsprechenden Plattformen anbieten.

[Tesseract]

Das ändert aber nichts daran, dass diese abstrakten Layer trotzdem die entsprechenden APIs der jeweiligen OSse verwenden. Je mehr dieser Layer dazwischen sind, desto mehr muss man natürlich hoffen, dass die Maintainer diese auch für die entsprechenden Plattformen anbieten.

ich hab nie was anderes behauptet. meine aussage war, dass selbst ein großer teil der non-OS-APIs kein problem machen sollte.

[davidzo]

betroffen sein wird hauptsächlich diverse (heft-cd-)crapware, für die es alternativen gibt und eine reihe (teilweise lange laufende) bussiness-software. das erste ist relativ egal weil es massig alternativen gibt und für das zweite könnte man eine art kompatiblity-layer einbauen. wäre wohl nicht der erste. :D


Ernstzunehmende Businessoftware läuft ab einer mittleren Unternehmensgröße sowieso Plattformunabhängig auf Terminalservern. Nur so kann man sicherstellen das alle dieselbe Version verwenden, die Software immer überall verfügbar ist und einwandfrei auf den jeweiligen Endgeräten jeder Abteilung funktioniert ohne dass die Wartungskosten explodieren.

Überhaupt, wenn der Clientmarkt in die OS-Verteilung miteingerechnet würde, dann wäre der Anteil Microsofts an Businessystemen wohl deutlich geringer als die bisher kolportierten 98%+, durch Mitbewerber wie Citrix, Wyse, Sun und FSC, die neben XP embedded auch allerlei andere Betriebssysteme verbauen.

Wieso viele kleinere Firmen immernoch Fat-Clients kaufen liegt meist nicht an den Anforderungen der Software, sondern eher an nach wie vor unzureichende IT-Planung und Beratung und ungenügend ausgebildetem konservativem IT-Personal.

Die Durchsetzung von Thinclients bei den größeren und langsam auch mittleren Firmen bedeutet aber für den Prozessormarkt eben auch ein nicht zu unterschätzendes Momentum weg von großen X86 Cores zu Energiesparenden Low Performance Prozessoren. Da bei Clients die X86 Kompatibilität gar keine Rolle spielt, weil darauf angewiesene Software dann auf einem fetten X86 Anwendungsserver läuft, sehe ich in diesem markt auch großes Potential für ARM. Und da reicht das aktuelle Portfolio schon größtenteils aus...

[Bucklew]

Das ist heutzutage meiner Meinung nach kein Problem mehr. Die VMs haben in den letzten Jahren enorme Fortschritte gemacht. Und generell wird die Performance von .NET und Java maßlos unterschätzt. Vor allem ist das schöne, dass alle Programme mit einer besseren VM auf einmal schneller sind.
Eine GUTE z.B. XP32-VM kann wohl eine deutlich bessere Kompatibilität für ältere Software bieten, als das aktuell in Win7 der Fall ist. Speziell wenn man Win7 x64 nutzt.

[Coda]

Zusammenhang?

[Bucklew]

Zusammenhang?
Das ein x86-System mit (aktuellem) Windows noch lange nicht jede x86-Software ausführt. Da könnte ein ARM-System mit einem guten Emulator durchaus Vorteile sogar gegen über dem x86-System haben, obwohl es um x86-Software geht.

[Coda]

Nein. Würde es nicht. Und es fehlt immer noch jeglicher Zusammenhang zu dem was ich gepostet hatte.

Es ging um die .NET/Java VMs, nicht um eine OS-VM.

[Bucklew]

Es ging um die .NET/Java VMs, nicht um eine OS-VM.
Wäre eben eine erweiterte VM.

Und natürlich würde so eine VM deutlich besser funktionieren, als das heute schon Win7 mit vielen alten Programmen tut. Wer viel ältere Software hat kommt an einer VM und/oder XP32 nicht vorbei. Teilweise ist sogar XP32 zu "neu".

[Coda]

Du willst garantiert nicht XP und x86 emulieren auf ARM. Die Performance wäre mehr als unterirdisch.

[Bucklew]

Du willst garantiert nicht XP und x86 emulieren auf ARM. Die Performance wäre mehr als unterirdisch.
Eine Mittelschicht, die kompatibel ist zu XP32 (ala Wine).

Was bringt dir eine x86-Emulation, wenn 99,99999% der Programme Bibliotheken und Systemfunktionen von Windows brauchen? Null.

Bei einer reinen x86-Emulation müsste man ja erst Recht ein XP drauf laufen lassen um darauf dann die Applikationen laufen zu lassen.

[Coda]

Was faselst du da für wirres Zeug? Die Systemfunktionen werden doch auf ARM portiert.

[deekey777]

...
PC jetzt mit Tegra2? Da könnte ich mir auch 'nen ganz kleinen DualCore-Atom reinschnallen. Macht bestimmt viel Freude. Nee, lieber nicht. Ich habe dann doch lieber etwas mehr CPU-Leistung.

Kann Tegras Videoprocessor mit dem Videoprocessor der aktuellen Fermis mithalten? Oder der Ion-Plattform?

...


Das sehe ich völlig anderes. Die riesige Latenz über den PCIe-Bus ist für viele Algorithmen die CPU und GPU nutzen absolut zerstörend. Man braucht gerade für HPC-Code die direkte Verbindung über einen L3-Cache.


Wie wurden eigentlich die PowerXCell-8i in den Blade-Servern angebunden? Oder wurden steckten sie auch auf Steckkarten?
Irgendwo hieß, dass IBM diese über einen HT-Link anbindet, da PCIe einfach zu träge ist, aber ich traue meinem Erinnerungsvermögen lieber nicht.

PS: Vielleicht entwickelt NV einfach einen eigenen CELL: ARM ist die PPE und die SMs dann die SPEs. X-D

[Bucklew]

Was faselst du da für wirres Zeug? Die Systemfunktionen werden doch auf ARM portiert.
Sag ich was anderes? Um Windowsprogramme laufen lassen zu können braucht man eine WINDOWS-emulation und keine x86-Emulation.

[Coda]

Sag ich was anderes? Um Windowsprogramme laufen lassen zu können braucht man eine WINDOWS-emulation und keine x86-Emulation.
Ja tust du. Windows wird nativ auf ARM portiert. Das ist keine Emulation.

Und was das alles mit der ursprünglich von dir zitierten Aussage von mir zu tun hat erschließt sich mir immer noch nicht.

[Bucklew]

Ja tust du. Windows wird nativ auf ARM portiert. Das ist keine Emulation.
Was noch lange nicht heißt, dass darauf x86-Software laufen wird (und was auch ziemlich unwahrscheinlich sein wird)

[N0Thing]

Warum sollte überhaupt groß emuliert werden? Falls das ARM Windows primär für Tablet-PCs entwickelt wird (und warum sollte es daß nicht?), wird es wie bei Apple und Google ja wohl auch für ein MS-System möglich sein, entsprechende, native Programme zu schreiben.

[Coda]

Was noch lange nicht heißt, dass darauf x86-Software laufen wird (und was auch ziemlich unwahrscheinlich sein wird)
Aha. Gerade hast du noch dir vorgeschlagen ein komplettes x86-Betriebsystem mit Software zu emulieren.

Dir ist anscheinend nicht klar, wie scheiße lahm das wäre. Unbenutzbar. Wenn überhaupt Emulation, dann Userspace-Translation wie Rosetta. Alles andere ist schlicht nicht umsetzbar.

Und im Gegensatz zu dir halte ich den Einsatz einer solchen Technologie für eine Übergangszeit für fast unabdingbar um ARM auf dem Desktop irgendeine Relevanz zu verschaffen. Ist jetzt auch nichts wofür Microsoft nicht das Know-How hätte. Itanium Windows emuliert x86-Userspace auch.

[Limit]

AMD wird frühsten 2012 in Bulldozer GPU-Funktionalitäten einbauen.

Bis dahin wird nVidia vermutlich nicht mal aller erste Prototypen haben.

Intel hat noch einen langen Weg, um auf Stand Ende 2009 zu kommen.

nVidia hat noch einen längeren Weg um zu einer auch nur halbwegs performanten CPU zu kommen.

Und trotzdem wird jetzt schon hier gesprochen, dass AMD und Intel beim erscheinen von "Denver" bei den GPU-Funktionalitäten mithalten können.

Intel kA, aber wieso sollte AMD das nicht können? Wenn man berücksichtigt, dass bei so einer APU die Leistungsaufnahme und die Die-Größe eine deutlich größere Rolle spielt, würde ich AMD hier zur Zeit sogar im Vorteil sehen.

Selbst AMD ist nicht auf dem Niveau von nVidia und in einigen Bereichen sind sie weit abgeschlagen.

Das musst du aber genauer ausführen. Ich halte das für vollkommenen Unsinn.

nVidia verkauft einen 520mm^2 Die. Es wird Jahre dauernd, bis Intel und AMD dieses Leistungsniveau erreichen.

Seit wann wir die Leistungsfähigkeit eines Chips nach seiner größe bemessen?

Und wenn sie es schaffen, sind nVidia und AMD mit ihren dedizierten GPUs schon wieder deutlich weiter. Und hier hat Gipsel ganz klar gesagt, wird es nVidia schwer haben. Darauf habe ich ihn auch gefragt, welche CPU mit den selben GPU-Fähigkeiten von nVidia denn als konkurrenz erscheinen werde.

Du begehst den Fehler zu denken, dass die Kombination aus schneller CPU + schneller GPU auch unbedingt ein schnelles Gesamtsystem ergibt. Für manche Anwendungsfälle mag das ja stimmen, aber es wird auch viele Anwendungsfälle geben, bei dem selbst eine Mittelklasse-APU schneller sein wird, nicht weil sie mehr Rohpower hätte, sondern weil der Overhead deutlich geringer ist. Ganz nach dem Sprichwort: Das Ganze ist mehr als die Summe seiner Teile.

Aber ich sehe auch, dass Low-End von ARM SoCs abgelöst wird, weil ein Großteil der Käufer eben keine Spieleanhänger sind. Und wer weiß, vielleicht bietet Apple auch in Zukunft ein Netbook mit iOS an. Ein Appstore mit Spielen? Dann fällt auch hier die letzte Bastion von Intel und AMD.

Nun, das würde voraussetzen, dass die ARM CPUs auch genügend Leistung für gescheite Spiele haben, wovon sie bis heute noch weit weg sind.

Eine andere Möglichkeit haben sie gar nicht. Ohne eine Rückwärtskompatibilität für bestehende Windows-Applikationen brauchen sie gar nicht antanzen.

Da stimme ich vollkommen zu.

Allerdings wird das natürlich nicht umsonst sein. Die Hoffnung ist halt, dass Entwickler endlich mal managed Sprachen einsetzen im 21. Jahrhundert und bestehender Code rekompiliert wird.

Managed Sprachen sind mittlerweile für viele Bereiche durchaus brauchbar und haben sogar vergleichbare Performance. Das Problem dabei ist, dass die wirklich rechenintensiven Bereiche nicht dazu gehören, denn da wird nach wie vor immer noch viel per Hand optimiert, vor allem für die Verwendung von SSE und demnächst AVX.

Sofern der Quellcode aller eingesetzten Bibliotheken vorhanden und plattform-unabhängig ist, ist rekompilieren die sauberste Lösung. Das Problem ist eben, dass die beiden o.g. Voraussetzungen vor allem bei kommerzieller Software nicht gegeben ist.

Außerdem werden Software-Entwickler ja nicht plötzlich anfangen all ihre Software zu portieren nur weil es eine neue Plattform gibt. Diese neue Plattform müsste so große Vorteile bieten, dass es die ganze Mühe wert wäre und da sehe ich das Problem, wo soll dieser Vorteil gegenüber z.B. Fusion herkommen?

Was die cacheauslastung des drystone benchmarks angeht. gerade was die caches betrifft sind die arms derzeit noch underpowered und da sollte noch einiges an potential drin stecken.
du kannst nicht einfach davon ausgehen dass eine arm cpu bei drystone ihr theoretisches maximum erreicht, eine x86cpu dagegen nicht. was, wenn es umgekehrt wäre?

So ein Benchmark ist ja ganz nett um die theoretische Leistung auszuloten, aber das Problem ist die Realität und da sieht es eben vollkommen anders aus.

noch n anderer plattformunabhängiger benchmark (ARM DC, atom SC+HT):
http://www.heise.de/imgs/18/4/0/3/7/0/5/731d1aeb578d64d6.png
~11.000 Coremarks entsprechen dabei in etwa der Leistung eines C2D mit 2Ghz (T7200) bei ebenfalls zwei Threads. Ein Tegra 250 1Ghz kommt auf 5800, 2700 mit einem thread. Knapp 4000 sind also für einen Dc mit 800mhz nicht übertrieben gemessen worden von ARM oder so und auch für den 2Ghz A9 gibt es unabhängige praxiswerte gemeldet.
http://www.coremark.org/benchmark/index.php

Das ist aber auch wieder ein Benchmark für Embedded Systems, was mit dem anvisierten Zielmarkt für Denver nichts am Hut hat.

Was die praxisleistung angeht sollte man aber auch bedenken dass die meiste software die man bisher testet (inkl. chrome webbrowser) von x86 stammt und daher portiert ist und seit jahrzenten auf x86 optimiert wurde, aber erst seit kurzem auf arm läuft. die compiler für x86 sind eben verdammt gut und die entwickler geben sich mühe das instruction set auch sinnvoll zu nutzen. Bei ARM dagegen steckt noch potential gerade in den compilern für die NEON SIMD engine, VFP, FPA, iwMMXt die in vielen anwendungen weitgehend brach liegen.

Das mag ja sein, aber wenn du keine Lösung dafür hast, die einfach und schnell umsetzbar ist, wird dir das jeder Kunde ankreiden, denn die interessiert im Normalfall nicht das "Was wäre wenn".

Das betrifft ebenfalls die PowerVr grafikchips, die ihre hardwarebeschleunigung nur selten nutzen können. derzeit gibts für ubuntu z.B. noch keine open source treiber für den SGX und nur rudimentäre binaries von denen man nicht weiß wieviel vom möglichen funktionsumfang wirklich in hardware läuft (ähnlich wi bei poulsbo damals9:

Zumindest das Problem sollte nVidia für seine GPU selbst lösen können

ich behaupte das gegenteil, welcher programmierer hat schon die zeit seine eigenen apis zu entwickeln?

Bei performance-kritischen Anwendungen ist es nach wie vor üblich per Hand zu optimieren, vor allem was die Benutzung von MMX/SSE/AVX angeht.

Denk mal drüber nach was man überhaupt für benches nehmen kann, wenn man die cpu-architektur, nicht den speicher, nicht den compiler, etc. testen will. da ist coremark schon ziemlich das einzige.

Der Haken daran ist, dass das eben an der Realität vorbei geht. Außerdem gehört die Cache- und Speicherarchitektur schon lange zur CPU-Architektur dazu, denn was nützten dir die besten Funktionseinheiten, wenn du es nicht schaffst sie auch auszulasten.

Ich kann mich nur wiederholen. Die Tatsache dass Coremark aus dem Cache läuft ist nur fair, denn ein 32bit LP-DDR Interface wollen wir nun wirklich nicht mit dem 192bit DDR3 Interface eines Bloomfields vergleichen.

Das mag kein fairer Vergleich sein, aber andererseits vergleichst du doch auch den Stromverbrauch eines ARM Cores mit den verschiedenen x86 CPUs ohne zu berücksichtigen, dass der Stromverbrauch deutlich ansteigen würde, wenn man ihm eben jenes bessere Speicherinterface mit allem was dazu gehört verpassen würde. Die Transistorzahl würde sich dadurch mal locker mehr als verdoppeln und packst du noch entsprechend große Caches dazu, dann ist der ARM Core gar nicht mehr so viel sparsamer.

Ja das ist Wahnsinn! bei 2-3mm² pro core in 40nm vs 32nm beim Atom. Wenn du dir jetzt vorstellst was die mit dem Atom machen wenn der A15 in 28nm kommt und neben dem Taktvorteil auch noch deutlich mehr IPC mitbringt.

Was bringt mir hohe IPC in Benchmarks wie Dhrystone und Coremark, wenn der Wert für reale Anwendungen dann vollkommen einbricht, weil das drumherum nicht passt. Die Stärke der heutigen x86 CPUs liegt nicht in ihrer hohen Rohperformance, sondern in ihrer "Fähigkeit" selbst bei ungünstigem Code die IPC hoch zu halten.


Richtig, das ist auch schon egal. Denn trotz all der Pfennigfuchserei sieht man nämlich das ARM bereits jetzt in ähnlichen Größenordnungen performt wie die Intel CPUs.

In rein synthetische Tests, die mit realen Desktop-Anwendungen überhaupt nichts am Hut haben.

Beim Energieverbrauch liegen noch mehrere Größenordnungen dazwischen, aber bei der performance liegt man zwar wenn auch nicht auf Augenhöhe, so zumindest schonmal auf Schussweite. Und das jetzt schon, ohne A15 Eagle und ohne Desktopausrichtung.

Die Performance bei realen Anwendungen ist nach wie vor weit weg, selbst von Zacate. Und bei der Betrachtung Energieverbrauch und Desktopausrichtung. Diese "Desktopausrichtung" ist ja gerade der größte Teil von dem, was bei den x86ern soviel Transistoren, Platz und Strom braucht. Packt man das bei den ARM Cores drauf, wird der Stromverbrauch und die Die-Größe entsprechend steigen.


In einem Protected Mode OS können Programme nur die zur Verfügung gestellten APIs nutzen und sonst nichts.

Hm? Das OS schützt nur den Speicher und einige wenige privilegierte Instruktionen. MMX/SSE/AVX Code ist z.B. x86-spezifisch und trotzdem von jedem normalen Anwendungsprogramm nutzbar.

Das ist heutzutage meiner Meinung nach kein Problem mehr. Die VMs haben in den letzten Jahren enorme Fortschritte gemacht. Und generell wird die Performance von .NET und Java maßlos unterschätzt. Vor allem ist das schöne, dass alle Programme mit einer besseren VM auf einmal schneller sind.

Die Geschwindigkeit bei "normalen" Anwendungen ist bei Java und .NET vollkommen in Ordnung, wenn man gescheit entwickelt. Das Problem ist eher die schlechte Optimierbarkeit, vor allem, wenn sehr viele Daten verarbeitet werden (z.B. Video(-filter/-encoding), oder typische HPC Anwendungen) und entsprechend viel mit der SSE/AVX Einheit gearbeitet wird. Denn da haben Compiler immer noch große Schwächen. Das sind aber auch die Bereiche, wo eine APU ihre Vorteile ausspielen könnte.


Das ein x86-System mit (aktuellem) Windows noch lange nicht jede x86-Software ausführt. Da könnte ein ARM-System mit einem guten Emulator durchaus Vorteile sogar gegen über dem x86-System haben, obwohl es um x86-Software geht.

Ähmm, absolut nein! Eine x86-VM tut im Prinzip nichts anderes als privilegierte Instruktionen rauszufischen und zu bearbeiten und alle anderen Instruktionen einfach durchzulassen. Bei unterschiedlichen ISAs müsste jeder einzelne Befehl "übersetzt" werden.

[Coda]

Außerdem werden Software-Entwickler ja nicht plötzlich anfangen all ihre Software zu portieren nur weil es eine neue Plattform gibt. Diese neue Plattform müsste so große Vorteile bieten, dass es die ganze Mühe wert wäre und da sehe ich das Problem, wo soll dieser Vorteil gegenüber z.B. Fusion herkommen?
Es geht nicht um Vorteile. NVIDIA hat keine andere Wahl.

Hm? Das OS schützt nur den Speicher und einige wenige privilegierte Instruktionen. MMX/SSE/AVX Code ist z.B. x86-spezifisch und trotzdem von jedem normalen Anwendungsprogramm nutzbar.
Tatsächlich. Das war mir jetzt aber neu :rolleyes:

stickedy klang so als wäre er der Meinung dass man in Windows wild an den Betriebssystem-APIs vorbeiprogrammieren könnte. Das ist natürlich nicht der Fall. Der Userspace hat eine exakt definierte Schnittstelle zu verwenden die vollständig auf ARM portierbar ist.

Die Geschwindigkeit bei "normalen" Anwendungen ist bei Java und .NET vollkommen in Ordnung, wenn man gescheit entwickelt. Das Problem ist eher die schlechte Optimierbarkeit, vor allem, wenn sehr viele Daten verarbeitet werden (z.B. Video(-filter/-encoding), oder typische HPC Anwendungen) und entsprechend viel mit der SSE/AVX Einheit gearbeitet wird. Denn da haben Compiler immer noch große Schwächen. Das sind aber auch die Bereiche, wo eine CPU+GPU Combi ihre Vorteile ausspielen könnte.
Das ist mir auch klar. Es geht primär um die 08/15 Programmbasis. Da muss nativer Code einfach ausgerottet werden. Viele Leute hängen da einfach noch einer falschen Romantik nach "direkt an der Maschine zu sein" und "die volle Kontrolle" zu haben.

Zudem bin ich der Meinung, dass sich gerade in diesem Forschungsbereich einiges tun wird und muss was SIMD angeht. Kann AVX nicht sogar scattered loads und stores? Das macht es für den Compiler sehr viel einfacher Schleifen damit zu parallelisieren. Letzteres wäre auch wichtig dafür, dass man nicht zwangsweise SoA nutzen muss nur um SIMD einsetzen zu können. Softwareentwicklung ist so schon komplex genug.

Und bevor ich wieder angeflamed werde, ich hab mehr als genug Erfahrung mit C/C++ und wenn's sein muss auch Maschinensprache - nicht nur für x86.

[Ailuros]

Kann Tegras Videoprocessor mit dem Videoprocessor der aktuellen Fermis mithalten? Oder der Ion-Plattform?

Nein. Aber das waere dann auch das einzige Problem. Im T2 hast Du eine GPU mit einer Fuellrate von 480MPixels/s.

***edit: zwar OT zum Thema hier aber dafuer finde ich einen getrennten Thread Ueberfluss:

http://www.xbitlabs.com/news/other/display/20110110164254_Intel_and_Nvidia_Settle_Legal_Dispute_Intel_to_Pay_Nvidia_1_5_Bil lion.html

Auf jeden Fall eine fette Summe fuer NV fuer weitere Investierungen in der Zukunft.

[Tiamat]

Pläne sind ja schön und gut. Aber wir wissen doch wie lange das im ARM-Umfeld dauert. Wo sind die Cortex A8 Netbooks, wo die A9 Netbooks? Bis auf ein paar Ausnahmen gab es da keine Massenverbreitung. Von den angekündigten Chrome Netbooks meines Wissens keine Spur, die Ankündigung von NV ist ohne Termin, d.h da geht noch viel Zeit ins Land.

[Ailuros]

Pläne sind ja schön und gut. Aber wir wissen doch wie lange das im ARM-Umfeld dauert. Wo sind die Cortex A8 Netbooks, wo die A9 Netbooks? Bis auf ein paar Ausnahmen gab es da keine Massenverbreitung. Von den angekündigten Chrome Netbooks meines Wissens keine Spur, die Ankündigung von NV ist ohne Termin, d.h da geht noch viel Zeit ins Land.

Natuerlich wird es einige Zeit vergehen.

Was jetzt die diverse Geraete-Kategorien betrifft so wie es aussieht wird sich einiges langfristig in der Landschaft hier aendern. Tablets werden sich zwischen smart-phones und netbooks etablieren und netbooks werden hoechstwahrscheinlich mehr in Richtung notebooks verschoben.

Tablets sind ja auch relativ neue "Tiere" die erst in 2010 mit dem iPad als erstes erschienen sind. NV hat hier sehr gute Chancen sich langfristig einen guten Marktanteil zu erobern und von da ab kann man Schritt fuer Schritt nach oben skalieren.

[Nighthawk13]

Wären nicht auch Denver-Grafik/Compute-Karten denkbar, die im x86 Host laufen?
(Also eine Art Geforce-Karte mit GPU/CPU-Hybridchip, wo auf der Arm-Cpu ein spezielles "Numbercruncher-Betriebssystem" läuft)

- Zumindest in der Anfangsphase hätte man nicht das Akzeptanzproblem wegen mangelnder Software, da 08/15-Programme weiter auf dem x86-Host laufen.
- Könnte aber trotzdem heterogene Spezialsoftware auf dem ARM/GPU-Kombi ausführen (z.B. Physikberechnung für Spiele oder Wissenschaft). Evtl. sogar besser weil das Betriebssystem darauf optimiert ist.
- Programme könnten nach und nach auf den ARM portiert werden => Man hätte den fliessenden Übergang. Irgendwann ist der Host überflüssig.

[Bucklew]

Aha. Gerade hast du noch dir vorgeschlagen ein komplettes x86-Betriebsystem mit Software zu emulieren.
Nein, habe ich nicht. Ich meinte eine zu XP32 kompatible VM, damit meine ich keine VM, in der XP32 läuft.

Und im Gegensatz zu dir halte ich den Einsatz einer solchen Technologie für eine Übergangszeit für fast unabdingbar um ARM auf dem Desktop irgendeine Relevanz zu verschaffen. Ist jetzt auch nichts wofür Microsoft nicht das Know-How hätte. Itanium Windows emuliert x86-Userspace auch.
Und wieder mal legst du mir irgendwas in den Mund, was ich nie gesagt habe - und was noch dazu absolut falsch ist, ich sehe das kein bisschen anders. Es geht mir auch nicht anders so. Ein System, dass meinen jetzigen PC nicht 100% ersetzen kann ist ein Spielzeug, ein zusätzliches Gerät (ala Tablet) aber kein Ersatz für diesen PC.

[iFanatiker]

Ich finde man sollte sich bei Spekus über Project Denver von Tablets, Thin Clients, Terminals, Smartphones usw. lösen. Dafür recht perfekte CPU IPs kann man eben direkt bei ARM für wenig Geld lizensieren und da ist ja nVidia schon tätig. Im schlimmsten Falle kann man eben das Design noch bißchen optimieren wie Qualcom um sich Wettbewerbsvorteile zu verschaffen, aber für diesen Markt entwickelt man keine eigenes Design IMHO.

Ebenso sollte man sich immer vor Augen halten, daß nVidia doch hier nur den ARM Befehlsatz verwendet (oder habe ich die Pressemeldung falsch verstand?) und somit es überhaupt gar nicht möglich ist irgendwas über die Leistungsfähigkeit oder Stromverbrauch zu schätzen, da nVidia hier ja ein ganz neues Desing macht was eben ARM-kompatibel ist, aber nichts mit den CPU IPs von ARM zu tun hat.

Project Denver kann eigentlich nur langfristig (sprechen wir hier mal von 5 bis 10 Jahren) als eben nVidias Antwort auf den momentanen Trend in Richtung der Vereinigung von immer mehr Funktionseinheiten im Hauptprozessor verstanden werden, was das nVidia Geschäftsmodell in diverseren Feldern ändern wird. Es ist doch klar, da es zwangsläufig daraufhinaus läuft auch im Workstation und Desktop Markt aktiv zu werden, da es große Synergieeffekte mit "Server" Markt gibt.

Interessant wird es wie Coda schon mehrfach anmerkte die nVidia die Kompatiblität mit älteren x86 Programmen erreichen wird. Ich glaube nicht, daß es nVidia bei einen Ansatz wie Apple belässt aus diversen Gründen. Glaube eine reine Emulation auf userland Niveau wäre zu wenig. Dazu hatte schon Rosetta zu viele Einschränkungen. Abhängig wie jetzt nVidia Deal mit Intel aussieht, könnte ich mehr oder minder doch durchaus vorstellen, daß einiges (aber eben nicht alles) aus dem x86 Befehlssatz doch in Hardware vorliegt.

[Coda]

Nein, habe ich nicht. Ich meinte eine zu XP32 kompatible VM, damit meine ich keine VM, in der XP32 läuft.
Das gibt's in Windows 7 bereits. Rechtsklick auf das Programm und "XP Kompatibilitätsmodus".

Mehr kannst du ohne vollständige Emulation von XP auch nicht wundersamerweise auf einmal mit einem ARM-Prozessor machen.

[davidzo]

Pläne sind ja schön und gut. Aber wir wissen doch wie lange das im ARM-Umfeld dauert. Wo sind die Cortex A8 Netbooks, wo die A9 Netbooks? Bis auf ein paar Ausnahmen gab es da keine Massenverbreitung. Von den angekündigten Chrome Netbooks meines Wissens keine Spur, die Ankündigung von NV ist ohne Termin, d.h da geht noch viel Zeit ins Land.

also das chrome OS nocht nicht bereit ist liegt wohl kaum an den arm CPUs.
A8 Netbooks waren nie angekündigt, das war eine reine highend handy CPU.
Was den A9MP angeht gibts den schon i einigen netbooks. Bis auf das toshiba ac-100 kommen diese innovativen Geräte aber selten in unseren konservativen Europäuschen Markt. Wenn man mal über den Tellerrand schaut wird man aber sehen dass es an Auswahl ganz gewiss nicht mangelt.

Wären nicht auch Denver-Grafik/Compute-Karten denkbar, die im x86 Host laufen?

Fände ich als Serverlösung sehr gut. Eventuell aber auch umgekehrt, ein ARM Host mit X86 Modulen. Man könnte dann die ganze VM und die flexiblen Betreibssysteme auf dem sparsamen ARM laufen lassen, der dann den X86 VMs bestimmte X86 Cores zuweist. Damit könnte man den Gebrauch von energiefressender X86hardware in Cloudcomputing minimieren, der Großteil der Anwendungen läuft dann nämlich in eigenen non-x86 VMs auf den sparsamen ARMs.

Als Anfangslösung könnte ich mir aber auch vorstellen, dass man mit relativ potenten ARM Thinclients beginnt (wie etwa dem nufront dualcore A9 2Ghz), einem ClientOS das die einzelnen Anwendungen seamless vom X86server streamen kann. Die Anwendungen werden dann nach und nach für den Nutzer unbemerkt auf ARM geported, so dass sich der Thin-Client nach und nach zu einem FAT-Client wandelt.

Fette Diskless Clients machen insbesondere Sinn wenn man geringere Latenzen benötigt und weil sie ausgezeichnet Skalieren, während ein Thinclientserver mit der Anzahl der Nutzer überhaupt nicht skaliert. Die Vorteile der zentralen Verwaltung kann man durch mehrschichtige transparente Dateisysteme mit massiven Verbesserungen bei der Sicherheit und Robustheit gegenüber Thinclients verbinden (Server Read only, Client schreibt in eine Ramdisk, abgleich ggf. beim logout auf eine andere Stelle auf dem Server). Bei einer zunemenden Virtualisierung kann man die Ressourcen gerade nicht ausgelasteter Fatclients ggf. anderen Fatclients und dem Server für Aufgaben zur Verfügung stellen. Die einem User zur Verfügung stehende Leistung steigt so mit der Anzahl der Fat-Clients. Eine umgekehrte Skalierung wie bei den Thinclients, die mit der Anzahl nur nach unten bei der Performance skalieren.
ARM CPUs wären für diesen Ansatz geradezu perfekt, da bei sowas nicht die Rechenleistung der einzelnen knoten limitiert, sondern die Latenz zwischen den knoten und danach die Bandbreite. Für Anwendungen in denen doch die Rechenleistung limitiert könnte man in einer heterogenen Umgebung immer noch spezielle CISC (x86) Cluster oder gar VLIW Cluster bereitstellen. Diese werden allerdings weniger benötigt als vorher, da die Grundlast nach und nach von den Fatclients abgenommen wird.

Ich finde man sollte sich bei Spekus über Project Denver von Tablets, Thin Clients, Terminals, Smartphones usw. lösen. Dafür recht perfekte CPU IPs kann man eben direkt bei ARM für wenig Geld lizensieren und da ist ja nVidia schon tätig. Im schlimmsten Falle kann man eben das Design noch bißchen optimieren wie Qualcom um sich Wettbewerbsvorteile zu verschaffen, aber für diesen Markt entwickelt man keine eigenes Design IMHO.

Naja gerade weil ARM da derzeit perfekt drin ist möchte man doch mitmischen. Wieso sollte man ARM in einem Feld einsetzen was bisher wenig lohnenswert und wenig realistisch erscheint wenn das andere doch auf der Hand liegt?

ich denke diese vollmundige Ankündigung man entwickle desktopprozessoren ist doch nur gemacht worden eben weil man gerne mit sparsameren clientlösungen als bishe rim desktop üblich sind eben mit den fetteren intel und amd desktops konkurrieren möchte.


Ebenso sollte man sich immer vor Augen halten, daß nVidia doch hier nur den ARM Befehlsatz verwendet (oder habe ich die Pressemeldung falsch verstand?) und somit es überhaupt gar nicht möglich ist irgendwas über die Leistungsfähigkeit oder Stromverbrauch zu schätzen, da nVidia hier ja ein ganz neues Desing macht was eben ARM-kompatibel ist, aber nichts mit den CPU IPs von ARM zu tun hat.

einen vollständig eigenen ARM-Prozessor, ala marvell? das bezweifle ich...

[Bucklew]

Das gibt's in Windows 7 bereits. Rechtsklick auf das Programm und "XP Kompatibilitätsmodus".
Ersetzt es nichtmal ansatzweise, vieles läuft auch damit nicht.

Oder meinst du die in Win7 integrierte XP-VM?

[Coda]

Ja, ersetzt es nicht. Aber man kann es ohne komplette Emulation nicht anders machen. Was genau verstehst du daran nicht?

Liest du auch mal was ich schreibe oder rotzt du nur patzige Antworten hin?

[Bucklew]

Ja, ersetzt es nicht. Aber man kann es ohne komplette Emulation nicht anders machen. Was genau verstehst du daran nicht?
Ohne Emulation wirst du kein x86-Programm auf ARM zum laufen kriegen.

Deshalb schrieb ich ja, dass ein Win7 auch weitab von perfekter Kompatibilität zu alten Programmen ist. Das könnte man zur Markteinführung ausnutzen.

[Coda]

Ohne Emulation wirst du kein x86-Programm auf ARM zum laufen kriegen.
Ich geb's auf :facepalm:

Wer nicht rafft, dass eine Translation von x86 auf ARM im Userspace etwas völlig anders ist als eine komplette Kernel-Emulation dem ist nicht mehr zu helfen. Nur weil du emulierst bekommst du nicht auf einmal alles was man sonst noch emulieren könnten umsonst dazu.

[Gipsel]

Vielleicht entwickelt NV einfach einen eigenen CELL: ARM ist die PPE und die SMs dann die SPEs. X-D
Na klar, Fusion soll ja auch mal so was in der Art werden, nur eben mit einer mit der Zeit immer stärker werdenden Integration der SIMD-Arrays in die CPU. Nur man mit Cell eben auch gelernt, daß das Ganze nicht so ganz einfach ist.
Nein. Aber das waere dann auch das einzige Problem. Im T2 hast Du eine GPU mit einer Fuellrate von 480MPixels/s.
Nun, nur DX9, keine unified shader, kein OpenCL (kein CUDA). Das kommt (hoffentlich) alles erst mit T3.
Wären nicht auch Denver-Grafik/Compute-Karten denkbar, die im x86 Host laufen?
(Also eine Art Geforce-Karte mit GPU/CPU-Hybridchip, wo auf der Arm-Cpu ein spezielles "Numbercruncher-Betriebssystem" läuft)
Na klar, genau so wird es wahrscheinlich laufen.
Übrigens hat/hätte Intels Larrabee auch nicht so viel anders funktioniert, nur haben da die GPU-Kerne selber x86 verstanden (und waren bei single thread code nicht gerade Sprinter).
Ebenso sollte man sich immer vor Augen halten, daß nVidia doch hier nur den ARM Befehlsatz verwendet (oder habe ich die Pressemeldung falsch verstand?) und somit es überhaupt gar nicht möglich ist irgendwas über die Leistungsfähigkeit oder Stromverbrauch zu schätzen, da nVidia hier ja ein ganz neues Desing macht was eben ARM-kompatibel ist, aber nichts mit den CPU IPs von ARM zu tun hat.AFAIK hat man nicht nur die ISA lizensiert, sondern auch den Cortex A15. Man wird also wahrscheinlich den als Basis nehmen.
Project Denver kann eigentlich nur langfristig (sprechen wir hier mal von 5 bis 10 Jahren) als eben nVidias Antwort auf den momentanen Trend in Richtung der Vereinigung von immer mehr Funktionseinheiten im Hauptprozessor verstanden werden, was das nVidia Geschäftsmodell in diverseren Feldern ändern wird.Ja. Man muß einfach auf den Trend reagieren (und am besten versuchen sich an die Spitze zu setzen), sonst geht das übel aus. Aber solche Veränderungen bergen natürlich auch immer Chancen.
Interessant wird es wie Coda schon mehrfach anmerkte die nVidia die Kompatiblität mit älteren x86 Programmen erreichen wird. Ich glaube nicht, daß es nVidia bei einen Ansatz wie Apple belässt aus diversen Gründen. Glaube eine reine Emulation auf userland Niveau wäre zu wenig. Dazu hatte schon Rosetta zu viele Einschränkungen. Abhängig wie jetzt nVidia Deal mit Intel aussieht, könnte ich mehr oder minder doch durchaus vorstellen, daß einiges (aber eben nicht alles) aus dem x86 Befehlssatz doch in Hardware vorliegt.
Nun, da bin ich ziemlich gespannt. Ich weiß überhaupt nicht, wie das laufen wird und im Gegensatz zu Coda bin ich mir noch nicht sicher, daß nvidia wirklich eine x86er-Kompatibilität anstreben wird. Wenn sie eine Chance sehen irgendwie drumherum zu kommen, werden sie es versuchen.

Die x86er-Geschichte ist übrigens ausdrücklich von dem Lizenzaustausch ausgenommen. Nvidia bekommt eine ganz ordentliche Finanzspritze über die nächsten 6 Jahre (knapp 300 Millionen $ pro Jahr) und darf dafür einige Intel-Sachen nutzen (ausdrücklich nichts, was direkt mit Intels CPUs zu tun hat). Der vielleicht interessante Punkt ist allerdings, daß Intel im Gegenzug Zugriff auf Alles von nvidia gewährt wird. Dies dürfte Intel die Entwicklung einer schlagkräftigeren GPU doch deutlich erleichtern (ich glaube im Rahmen des Lizenzaustauschabkommen darf man bereits die AMD-GPU Sachen nutzen). Denn im Prinzip ist ja alles, was dazu nötig ist von irgendwem patentiert worden. Neueinsteiger haben es daher doch schwer, will man nicht von allen verklagt werden.
Bei zwei Großen läuft das im Prinzip so ab, daß beide notgedrungen Patente des jeweils anderen verletzen (bestimmte Sachen in einer GPU kann man nur auf wenige Arten effizient machen). Da verklagt man sich höchstens einmal gegenseitig, dann stellt man fest daß beide jeweils grob 100 Patente vom jeweils anderen verletzen und man legt das wieder zu den Akten. Man benötigt also ein gewisses "Gegengewicht" an Patenten. Da steht Intel jetzt wirklich vollkommen auf der sicheren Seite. Das war Ihnen dann offensichtlich 1,5 Milliarden wert.

[Bucklew]

Wer nicht rafft, dass eine Translation von x86 auf ARM im Userspace etwas völlig anders ist als eine komplette Kernel-Emulation dem ist nicht mehr zu helfen. Nur weil du emulierst bekommst du nicht auf einmal alles was man sonst noch emulieren könnten umsonst dazu.
Nö, sag ich auch nirgends. Es führt nur schlicht kein Weg dran vorbei. Und man hätte in Sachen Kompatibilität sogar noch einen Vorteil gegenüber aktuellen Windowsversionen. Gibts ne bessere Werbung?

[Coda]

Nö, sag ich auch nirgends. Es führt nur schlicht kein Weg dran vorbei. Und man hätte in Sachen Kompatibilität sogar noch einen Vorteil gegenüber aktuellen Windowsversionen. Gibts ne bessere Werbung?
Wie oft muss ich eigentlich noch erklären, dass das was dir da vorschwebt ungefähr so wäre als würdest du Windows XP auf einem 386 laufen lassen?

Und natürlich "führt ein Weg daran vorbei". Man macht Userspace-Translation wie Apple bei der x86-Migration. Alles andere ist kompletter Schwachsinn.

[Limit]

stickedy klang so als wäre er der Meinung dass man in Windows wild an den Betriebssystem-APIs vorbeiprogrammieren könnte. Das ist natürlich nicht der Fall. Der Userspace hat eine exakt definierte Schnittstelle zu verwenden die vollständig auf ARM portierbar ist.

Sicher kannst du das OS portieren und damit auch dessen Schnittstelle, aber das reicht nicht aus. Du musst auch jedes Anwendungsprogramm portieren. Der Aufwand dafür reicht von einfachem Rekompilieren bis hin zum Neuschreiben ganzer Abschnitte, einfach weil die z.B. per Assembler für SSE & Co optimiert wurden. Außerdem brauchst du dafür natürlich jede benutzte Bibliothek als Quellcode und musst evtl. auch den noch anpassen, sofern deine Lizenzen das überhaupt zulassen.

Das ist mir auch klar. Es geht primär um die 08/15 Programmbasis. Da muss nativer Code einfach ausgerottet werden. Viele Leute hängen da einfach noch einer falschen Romantik nach "direkt an der Maschine zu sein" und "die volle Kontrolle" zu haben.

Zudem bin ich der Meinung, dass sich gerade in diesem Forschungsbereich einiges tun wird und muss was SIMD angeht. Kann AVX nicht sogar scattered loads und stores? Das macht es für den Compiler sehr viel einfacher Schleifen damit zu parallelisieren. Letzteres wäre auch wichtig dafür, dass man nicht zwangsweise SoA nutzen muss nur um SIMD einsetzen zu können. Softwareentwicklung ist so schon komplex genug.

Schön wäre es natürlich, wenn die Compiler irgendwann auch mal wirklich gescheiten Code für die SIMD Einheiten generieren könnten. Ich würde C oder gar Assembler sicher keine Träne nachweinen. Aber bisher sieht es da nach wie vor nicht besonders gut aus, obwohl es SSE z.B. nicht erst seit gestern gibt.

Wären nicht auch Denver-Grafik/Compute-Karten denkbar, die im x86 Host laufen?
(Also eine Art Geforce-Karte mit GPU/CPU-Hybridchip, wo auf der Arm-Cpu ein spezielles "Numbercruncher-Betriebssystem" läuft)

Wäre sicherlich eine Möglichkeit. Allerdings sehe ich da noch die Probleme der Performance dieser ARM Cores. Da muss man erst einmal abwarten, wie gut sie bei entsprechendem Code sind. Mit OpenCL hätte man auf jeden Fall schon eine entsprechende API dafür.

- Zumindest in der Anfangsphase hätte man nicht das Akzeptanzproblem wegen mangelnder Software, da 08/15-Programme weiter auf dem x86-Host laufen.
- Könnte aber trotzdem heterogene Spezialsoftware auf dem ARM/GPU-Kombi ausführen (z.B. Physikberechnung für Spiele oder Wissenschaft). Evtl. sogar besser weil das Betriebssystem darauf optimiert ist.


Dafür müsste man für die optimale Ausnutzung der Rechenleistung bereits für 3 Architekturen optimieren. Insbesondere die Partitionierung der Aufgaben und die Lastverteilung wird dann schon unangenehm. Da gibt es zwar einiges an Forschungsarbeit dazu, aber das könnte noch eine Weile dauern bis da was marktreifes bei rauskommt. Das Betriebssystem hat wenig Einfluss auf die Performance von hauptsächlich rechenintensiven Anwendeungen, weil die direkt auf die CPU zugreifen. Performance-kritisch wäre da bestenfalls der Scheduler, das I/O Subsystem und die Treiber, wobei die letzten beiden unabhängig von der benutzten CPU optimiert werden.

- Programme könnten nach und nach auf den ARM portiert werden => Man hätte den fliessenden Übergang. Irgendwann ist der Host überflüssig.

Die Frage ist dann halt nur wieder, warum sich jemand die Mühe machen sollte, wenn er das gleiche mit den APUs von Intel und AMD viel einfacher bekommen kann.

Fände ich als Serverlösung sehr gut. Eventuell aber auch umgekehrt, ein ARM Host mit X86 Modulen. Man könnte dann die ganze VM und die flexiblen Betreibssysteme auf dem sparsamen ARM laufen lassen, der dann den X86 VMs bestimmte X86 Cores zuweist. Damit könnte man den Gebrauch von energiefressender X86hardware in Cloudcomputing minimieren, der Großteil der Anwendungen läuft dann nämlich in eigenen non-x86 VMs auf den sparsamen ARMs.

Wo liegt denn darin der Sinn? Das würde ich ja bei Notebooks evtl. noch verstehen, aber bei Servern? Ins besondere bei Cloud Computing ist das noch relativ sinnlos. Wenn da die Auslastung auf einem Rechenknoten zu niedrig ist, migrierst du die Tasks auf andere Knoten und schaltest den einen Knoten ab. Außerdem brauchst du dafür auch erstmal ARM Kerne die leistungsfähig genug sind, auch was einen einzelnen Thread angeht, denn ein Problem wird nicht dadurch besser parallelisierbar, dass du es in die Cloud verlagerst.

[Ailuros]

Nun, nur DX9, keine unified shader, kein OpenCL (kein CUDA). Das kommt (hoffentlich) alles erst mit T3.

Welche DX9 Version denn genau bei 2048*2048 Texturen maximal? Uebrigens kommt vielleicht NV mit 16bit Z Praezision auf mobilen Geraeten heutzutage noch davon (obwohl man etliche Nebeneffekte sehen kann) aber fuer selbst eine low end desktop GPU waere so ein Ding total ungeeignet.

[Coda]

Sicher kannst du das OS portieren und damit auch dessen Schnittstelle, aber das reicht nicht aus. Du musst auch jedes Anwendungsprogramm portieren.
No shit, sherlock.

In einem Protected Mode OS können Programme nur die zur Verfügung gestellten APIs nutzen und sonst nichts.

Solange das OS komplett portiert wird - wovon ich ausgehe - ist es theoretisch wirklich nur eine Rekompilierung. Praktisch gibt's natürlich aber solche Probleme, dass 3rd party Libs nur für x86 zur Verfügung stehen oder Little vs. Big Endian.

Ich muss mich wirklich zurückhalten nicht deutlichere Worte zu finden, aber würdest du es bitte unterlassen mir hier etwas erklären zu wollen?

[Gipsel]

Für Anwendungen in denen doch die Rechenleistung limitiert könnte man in einer heterogenen Umgebung immer noch spezielle CISC (x86) Cluster oder gar VLIW Cluster bereitstellen. Diese werden allerdings weniger benötigt als vorher, da die Grundlast nach und nach von den Fatclients abgenommen wird.Mal ganz abgesehen von der doch sehr schwierigen und in absehbarer Zukunft allerhöchstens punktuell stattfindenden Realisierung eines solchen Konzepts (gibt es überhaupt in einer Firma genügend Probleme, die sich so umsetzen lassen, daß sich die Infrastruktur dafür lohnt?), aber was schwebt Dir beim Gefetteten denn eigentlich genau vor? Itanium? Was soll das bringen?

[Gipsel]

Welche DX9 Version denn genau bei 2048*2048 Texturen maximal?Na dann nicht DirectX9.0c mit SM3, das erfordert (neben den deutlich größeren Fähigkeiten der Shader) afaik 4096*4096. Aber SM2.0(a) wird Tegra doch hoffentlich schon erfüllen können. Und das reicht dann schon für DirectX9 (ohne c).
aber fuer selbst eine low end desktop GPU waere so ein Ding total ungeeignet.Das ungefähr wollte ich mit meinem Einwurf sagen. Wahrscheinlich hast Du in Deinem Post hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8501825#post8501825) nur das Wörtchen "nicht" vergessen. Denn der etwas schlechtere Videoprozessor im Tegra2 ist eben nicht das einzige Problem beim Vergleich mit aktuellen Einstiegslösungen, wenn man es nicht nur auf die Videowiedergabe bezieht. ;)

[Limit]

Nachdem meine Kommentare bei manchen nicht sonderlich gut angekommen sind (gruß an Coda, war nicht böse gemeint :redface:), werd ich das mal sein lassen und meinen eigenen "Mist" produzieren :cool:

Hier wurde ja viel über darüber diskutiert wie man das Problem der inkompatiblen Software behebt. Ich denke aber, dass man sich zuvor überhaupt erstmal überlegen sollte, wie nVidia die Leute überhaupt dazu bringen will ihre Software portieren zu wollen und damit landet man wieder bei der Hardware.

Mal angenommen nVidia gelingt es eine HP-CPU zu bauen und gleichzeitig gelingt es Intel eine HP-GPU zu entwickeln. Weiterhin nehme ich mal an, dass AMD bis dahin nicht pleite ist und seine CPU und GPU entsprechend weiterentwickelt hat.
Dann hätte man auf der einen Seite nVidia mit einer HP-ARM-APU und auf der anderen Seite zwei HP-x86-APUs. Man hätte dann also 3 mal das gleiche Konzept. Intel und AMD hätten große Vorteile wegen der existierenden Software, sie haben im Desktop-Markt praktisch ein Duopol bei den CPUs und bei integrierten GPUs und zumindest Intel hat deutlich mehr Ressourcen, sowohl finanziell als auch im Bereich F&E. Da das wohl der zukünftige Mainstream Markt wird, werden Intel und AMD diesen mit Zähnen und Klauen verteidigen, so dass ich für einen "Neuling" mit inkompatibler Architektur keinen Platz hier sehe. Wenn die CPU performant genug ist, könnte man sich eine Lücke z.B. bei den Konsolen suchen oder man fragt bei Apple an, ob sie nicht noch einmal die Architektur wechseln wollen.

Eine Alternative wäre es eine eher auf LP ausgelegte CPU mit niedrigere bis mittlerer Performance zu nehmen und dafür eine "dickere" GPU mit dazu zu geben. Als "CPU" ausgelegt, also mit dem ARM als Hauptkern des Systems hätte man das gleiche Problem wie beim ersten Fall. Bei der Variante, wo man praktisch einen oder mehrere ARM Kerne mit in die GPU integriert wäre die Software wiederum weniger ein Problem, da Software für GPUs sowieso noch kaum verbreitet ist und von vorne herein für den Betrieb auf heterogenen Systemen ausgelegt ist. Damit würde man allerdings hauptsächlich in Konkurrenz zu den reinen GPUs gehen und weniger zu den APUs oder CPUs. Ein Vorteil wäre, dass Intel wohl vorläufig wohl kein so großes Interesse an dem Markt hat, AMD dagegen könnte da durchaus mitziehen um nicht Marktanteile bei den Grafikkarten zu verlieren.

Fazit: Ich denke, dass Denver eher in einer Konsole oder auf einer Grafikkarte landet und nicht als direkten Konkurrent zu Intel's und AMD's APU.

[Deinorius]

Denn der etwas schlechtere Videoprozessor im Tegra2 ist eben nicht das einzige Problem beim Vergleich mit aktuellen Einstiegslösungen, wenn man es nicht nur auf die Videowiedergabe bezieht. ;)


Was bedeutet hier eigentlich schlechter? T2 kann sicher keine zwei Streams und auch keine 40 MBit/s AVC/VC1 dekodieren. Was kommt da noch hinzu? (Kann der überhaupt VC1 dekodieren? - Wäre ja kein Beinbruch, wenn nicht.)

[Label]

Was bedeutet hier eigentlich schlechter? T2 kann sicher keine zwei Streams und auch keine 40 MBit/s AVC/VC1 dekodieren. Was kommt da noch hinzu? (Kann der überhaupt VC1 dekodieren? - Wäre ja kein Beinbruch, wenn nicht.)
Kann er... Bei Google das 1. Ergebnis:
http://www.nvidia.de/object/tegra-2-de.html

[davidzo]

Die x86er-Geschichte ist übrigens ausdrücklich von dem Lizenzaustausch ausgenommen. Nvidia bekommt eine ganz ordentliche Finanzspritze über die nächsten 6 Jahre (knapp 300 Millionen $ pro Jahr) und darf dafür einige Intel-Sachen nutzen (ausdrücklich nichts, was direkt mit Intels CPUs zu tun hat). Der vielleicht interessante Punkt ist allerdings, daß Intel im Gegenzug Zugriff auf Alles von nvidia gewährt wird. Dies dürfte Intel die Entwicklung einer schlagkräftigeren GPU doch deutlich erleichtern (ich glaube im Rahmen des Lizenzaustauschabkommen darf man bereits die AMD-GPU Sachen nutzen). Denn im Prinzip ist ja alles, was dazu nötig ist von irgendwem patentiert worden. Neueinsteiger haben es daher doch schwer, will man nicht von allen verklagt werden.
Du unterschätzt wie alt die meisten 3D Verfahren wirklich schon sind. Was rasterizing, shading und Filtertechniken angeht, das sind alles Verfahren die von größeren Firmen wie SGI und co schon wissenschaftlich und militärisch in den 80er bis 90er Jahren entwickelt worden sind. Also sowohl die Berechnungen als auch erste Ansätze für Hardwarebeschleunigung. Und selbst das was wir in den letzten jahren in DirectX gesehen haben ist im Prinzip vorher auch schon alles mal in Software gemacht worden.
Ich Glaube dass man für eine schlagkräftige GPU gar nicht mal viele Patente braucht, ein Großteil davon wird sowieso von der Kronos group und Microsoft gehalten, andere von SGI, S3, etc. sind billig zu lizensieren oder bereits ausgelaufen.


Wo liegt denn darin der Sinn? Das würde ich ja bei Notebooks evtl. noch verstehen, aber bei Servern? Ins besondere bei Cloud Computing ist das noch relativ sinnlos. Wenn da die Auslastung auf einem Rechenknoten zu niedrig ist, migrierst du die Tasks auf andere Knoten und schaltest den einen Knoten ab. Außerdem brauchst du dafür auch erstmal ARM Kerne die leistungsfähig genug sind, auch was einen einzelnen Thread angeht, denn ein Problem wird nicht dadurch besser parallelisierbar, dass du es in die Cloud verlagerst.

Ich glaube du hast mich nicht ganz verstanden.
Ein Großteil der Anwendungen die Cloudservices derzeit nutzen sind massiv parallelisierbar, andere dagegen nicht. Derzeit läuft bei Amazon alles auf Quadcore Nehalems, auch die massiv parallelisierbaren Aufgaben. Eine "Small Instanz" wie sie von den meisten genutzt wird entspricht dabei einem 1-1.2Ghz Opteron aus 2007. Das heißt ein Core wird von einer Instanz üblicherweise gar nicht ausgelastet und womöglich gar von drei Instanzen gleichzeitig genutzt. Das ist Multithreading auf einem Core.
Da aber Manycores mit niedriger leistung und viel Parallelität viel effizienter sind, wäre es Sinnvoll alle diese Small Instances auf einzelnen kleineren Cores laufen zu lassen. Benötigt die Instanz mehr Leistung können entweder mehr virtuelle Cores zur Verfügung gestellt werden oder die Instanz des Gast OS auch auf eine stärker singlethread optimierte Maschine verschoben werden.
OK, die heterogene Serverlandschaft mag ja mit Xen noch gehen, wie löst man aber das problem mit den verschiedenen Architekturen? - Vorzugsweise führt man ARM binaries aus, vor allem wenn es um FOSS handelt. Für X86 binaries wird dann eine leere X86 OS Instanz schnell geklont, die die Anwendung ausführt und seamless mit der ARM Instanz verbindet. Dass eine seamless integration funktioniert zeigt schon suns virtualbox in der ich XP Anwendungen seamless neben gnone Anwendungen betreiben kann.
Der Vorteil wäre hier, dass die meisten typischen Cloud Workloads (Small Instance, FOSS) auf wesentlich billigerer energiesparender Hardware (ARM) ausgeführt würde, während die Vorteile von starken x86 Cores und Backwardskompatibilität nicht verloren gingen.

Mal ganz abgesehen von der doch sehr schwierigen und in absehbarer Zukunft allerhöchstens punktuell stattfindenden Realisierung eines solchen Konzepts (gibt es überhaupt in einer Firma genügend Probleme, die sich so umsetzen lassen, daß sich die Infrastruktur dafür lohnt?), ...

Ich hab schon an FAT-Clients gebastelt bevor du hier überhaupt angemeldet warst (herausgekommen ist da workroom in a box, siehe google).
Die Realisierung ist kein Problem, die Software ist bereits tauglich dafür, Infrastruktur (LAN) eigentlich schon vorhanden, aber wie bei so vielen Visionären Produkten fehlt den eintscheidenden Leuten mal wieder der Mumm es zu wagen.
Was das Diskless booten angeht und das transparente Dateisystem, funktioniert das im Prinzip genauso wie bei einer LiveCD oder dem LiveOS auf einem Stick. Nach dem PXEboot wird ein virtuelles Dateisystem gemountet, mit einem NFS als readonly filesystem (bei der liveCD CDFS) und eine dynamische Ramdisk für den write -Teil. Die programme starten also über NFS vom Server, laufen aber auf dem Client. Die etwas erhöhten Latenzen kann man mit großen caches geschickt verdecken. Am Ende einer Session kann selbige entweder verworfen werden oder einmalig an einen fileserver übermittelt werden von dem man sie nächstes mal auch wieder dazuladen kann.
Zusätzlich aber läuft auf dem ClientOS eine Virtualisierungslösung (damals Clustersoftware Open Mosix), die alle unbenötigte Rechenleistung anderen Threads anderer User im Netzwerk zur Verfügung stellt.


aber was schwebt Dir beim Gefetteten denn eigentlich genau vor? Itanium?
Gott bewahre, wie kommst du darauf?
Das funktioniert mit jeder Hardware, aber durch die nutzbaren Synergien kann man annembare leistung auch bei relativ schwacher hardware schon erziehlen.
Was soll das bringen?
Die Vorteile liegen auf der Hand.
Neben einem massiv verringerten Verwaltungsaufwand (genau wie bei Thinclients sind alle Datenspeicher zentralisiert, Softwareverteilung und Inkonsistenzen also kein problem mehr) steigt auch die Produktivität und die Sicherheit.
Die Ausfallsicherheit ist wesentlich größer wenn die Nutzer auf einzelnen Maschinen mit eigener OS-Instanz arbeiten, als wenn alle eine Session am terminalserver auf haben. Der Fatclient server muss überhaupt nicht schreibbar sein, Sessions können seperat gespeichert werden und jeder User hat immer die Chance zu einer standardsession zurückzukehren da alle Software auf dem Server unantastbar bleibt. Ein weiterer enormer Vorteil ist, dass der Fatclientserver als reiner Fileserver nur über mittlere Leistung verfügen muss, während Terminalserver über viel größere Kapazitäten verfügen müssen. Sicherheitstechnisch ist es von Vorteil einzelne NFS Server sowohl für die homeverzechnisse der User, deren Sessions und für die readonly gemoeunteten Systeminstanzen zu haben.
Und was die Vorteile bei der Leistung angeht, was würdest du mit mehreren hundert CPUcores unter einer betriebssysteminszanz anfangen, die dir alle zur verfügung stünden weil sie von den anderen usern nur ansatzweise ausgelastet werden? Mir fällt da einiges ein...






Hier wurde ja viel über darüber diskutiert wie man das Problem der inkompatiblen Software behebt. Ich denke aber, dass man sich zuvor überhaupt erstmal überlegen sollte, wie nVidia die Leute überhaupt dazu bringen will ihre Software portieren zu wollen und damit landet man wieder bei der Hardware.

Müssen sie nicht.
Werden sie nicht.
Nv ist keine Softwarefirma, auch wenn die bestrebungen bisher mit CUDA und co gar nicht mal schlecht waren.

Android, ChromeOS, iOS, WebOS, etc. sind sogar schon ohne Windows8 genug Plattformen um den Entwicklern das portieren schmackhaft zu machen.

Im Gegensatz zu Windows sind das außerdem wachsende Plattformen und zudem höchst dynamisch, sprich die Leute erwarten gar nicht erst dass ihre angesammelte Software aus dem regal darauf läuft sondern fragen explizit nach neuen frischen Anwendungen. Beste Bedingungen für Entwickler würde ich da sagen, da braucht nvidia ja gar nichts zutun. Auch bei den Mobilplattformen, iphone und Android sieht man sich ja wie sich auch renomierte Spieleentwickler geradezu darauf stürzen dafür zu entwickeln.
50cent oder 1$ für eine mini anwendunge die ein paar hundert mannstunden arbeit war, dann aber in kürzester zeit zigtausendfach verkauft wird ist eben ein verlockendes modell.

Bis auf Windows sind das übrigens alles mehr oder weniger ARM-only Plattformen (Android+ChromeOS theoretisch nicht, praktisch aber schon). Ich sehe Arm da also bei der Softwarekompatibilität gar nichtmal so enorm zurückliegen, Windows kann auch einiges schonmal nicht, was eigentlich heute Standard ist...

[Limit]

Ich glaube du hast mich nicht ganz verstanden.
Ein Großteil der Anwendungen die Cloudservices derzeit nutzen sind massiv parallelisierbar, andere dagegen nicht. Derzeit läuft bei Amazon alles auf Quadcore Nehalems, auch die massiv parallelisierbaren Aufgaben. Eine "Small Instanz" wie sie von den meisten genutzt wird entspricht dabei einem 1-1.2Ghz Opteron aus 2007. Das heißt ein Core wird von einer Instanz üblicherweise gar nicht ausgelastet und womöglich gar von drei Instanzen gleichzeitig genutzt. Das ist Multithreading auf einem Core.
Da aber Manycores mit niedriger leistung und viel Parallelität viel effizienter sind, wäre es Sinnvoll alle diese Small Instances auf einzelnen kleineren Cores laufen zu lassen. Benötigt die Instanz mehr Leistung können entweder mehr virtuelle Cores zur Verfügung gestellt werden oder die Instanz des Gast OS auch auf eine stärker singlethread optimierte Maschine verschoben werden.

Hmm, du sprichst hier einerseits von massiv parallelisierbaren Anwendungen und gleichzeitig davon, dass eine Instanz nicht einmal einen Core auslasten kann. :confused:
Was ich einsehe ist, dass Cloud Computing Anwendungen sicherlich keine homogene Gruppe sind, es gibt HPC Anwendungen, die fast beliebig viele Cores auslasten können, es gibt irgendwelche Office-Anwendungen, die selbst einen kleinen ARM Core nicht auslasten können und es gibt viele Anwendungen irgendwie dazwischen. Idealerweise hat man für jede Art von Task die passende Architektur in der Cloud und wählt immer die am besten geeignete, da bin ganz deiner Meinung.
Da nVidia aber selbst von Desktop, Workstation und Server Markt sprach, bin ich davon ausgegangen, dass du auch bzgl. der Cloud von solchen Anwendungen ausgehst und da hast du mit derzeitigen ARM Cores die gleichen Einschränkungen wie bei einem ganz normalen System, denn die Anwendung selbst ändert sich ja nicht.
Übrigens, die Tatsache, dass "Small Instances" am häufigsten benutzt werden, hat glaube ich weniger damit zu tun, dass man nicht mehr Leistung will/braucht, sondern eher damit, dass man sie gratis bekommt.


Müssen sie nicht.
Werden sie nicht.
Nv ist keine Softwarefirma, auch wenn die bestrebungen bisher mit CUDA und co gar nicht mal schlecht waren.

Hat der nVidia CEO nicht mal gesagt, sie seien in erster Linie eine Softwarefirma?

Android, ChromeOS, iOS, WebOS, etc. sind sogar schon ohne Windows8 genug Plattformen um den Entwicklern das portieren schmackhaft zu machen.

Hier wieder mein Einwurf. nVidia zielt nach eigenen Angaben auf Desktop, Workstation und Server und keines der Betriebssysteme (eigentlich sind doch Android und ChromeOS und auch WebOS einfach nur Linux Derivate) hat in diesen Märkten auch nur den kleinsten Marktanteil. Entsprechend werden auch keine Anwendungen aus diesem Marktsegment portiert. Da hat selbst ein Standard Linux deutlich mehr zu bieten.

Im Gegensatz zu Windows sind das außerdem wachsende Plattformen und zudem höchst dynamisch, sprich die Leute erwarten gar nicht erst dass ihre angesammelte Software aus dem regal darauf läuft sondern fragen explizit nach neuen frischen Anwendungen. Beste Bedingungen für Entwickler würde ich da sagen, da braucht nvidia ja gar nichts zutun. Auch bei den Mobilplattformen, iphone und Android sieht man sich ja wie sich auch renomierte Spieleentwickler geradezu darauf stürzen dafür zu entwickeln.
50cent oder 1$ für eine mini anwendunge die ein paar hundert mannstunden arbeit war, dann aber in kürzester zeit zigtausendfach verkauft wird ist eben ein verlockendes modell.

Bis auf Windows sind das übrigens alles mehr oder weniger ARM-only Plattformen (Android+ChromeOS theoretisch nicht, praktisch aber schon). Ich sehe Arm da also bei der Softwarekompatibilität gar nichtmal so enorm zurückliegen, Windows kann auch einiges schonmal nicht, was eigentlich heute Standard ist...

Das mag alles stimmen, ist aber ebenfalls nicht die richtige Baustelle. Die genannten Betriebssysteme bedienen eben einen neuen Markt, wo es bisher gar keine Konkurrenz gab, so dass Wachstum dort kein sonderliches Kunststück ist und die Anwendungen die du da ansprichst sind eben nur kleine Apps, keine ausgewachsenen Anwendungen und irgendwelche kleinen Causal Games sind auch was anderes als die typischen Games für den PC und Konsolen. Es streitet ja niemand ab, dass sich das noch entwickeln wird, aber Project Denver zielt eben nicht auf diesen Markt ab. Du gehst anscheinend davon aus, dass der Erfolg auf den Smartphones und Tablets sich einfach auf die Desktops, Workstations und Server ausdehnen lässt. Das haben viele auch schon bei den Netbooks gedacht und daraus ist auch nichts geworden. Die Anforderungen und Erwartungen sind eben unterschiedlich und nur weil ein Konzept in einem Markt funktioniert, heißt das nicht, dass es das auch in anderen tut.

[Ailuros]

Du unterschätzt wie alt die meisten 3D Verfahren wirklich schon sind. Was rasterizing, shading und Filtertechniken angeht, das sind alles Verfahren die von größeren Firmen wie SGI und co schon wissenschaftlich und militärisch in den 80er bis 90er Jahren entwickelt worden sind. Also sowohl die Berechnungen als auch erste Ansätze für Hardwarebeschleunigung. Und selbst das was wir in den letzten jahren in DirectX gesehen haben ist im Prinzip vorher auch schon alles mal in Software gemacht worden.
Ich Glaube dass man für eine schlagkräftige GPU gar nicht mal viele Patente braucht, ein Großteil davon wird sowieso von der Kronos group und Microsoft gehalten, andere von SGI, S3, etc. sind billig zu lizensieren oder bereits ausgelaufen.

IHVs sorgen aber auch dafuer dass wichtige Patente mit Aenderungen/Zusaetzen quasi verlaengert werden. LRB haette sein tiling so oder so in sw ausgelegt, aber so oder so handelte es sich wohl um stinknormales bounding box tiling wie alle anderen benutzen. Diesbezueglich hat NV sowieso nichts in ihrem portofolio, aber da ich weiss dass IMG's spezifische Patente fuer ihr tiling mehrere Male angefochten wurden (ohne Resultate) werden diese wohl nicht so unwichtig sein.

Erstens kann unter Umstaenden (z.B. duenne diagonal orientierte Dreiecke) bounding box tiling ziemlich viel Bandbreite fressen und zweitens ich bin immer noch ueberzeugt dass bei einer many-core Architektur wie LRB es wurscht ist wenn man keine Logik fuer tiling hat. Wuerde Intel mit so einem Ding nach unten skalieren wollen auf single core z.B. waere es eine Schnappsidee keine tiling Logik zu haben. Ihr GenX Zeug hat zwar tiling Logik aber das Zeug funktioniert ja sowieso nie wie es sollte.

Anders und vereinfacht man kann sehr vieles heutzutage theoretisch nur in sw implementieren; man sollte aber dann auch dafuer vorbereitet sein dass man davon keine besondere Leistung sehen wird. LRB hat zu viel Logik fuer den x86 Scheiss verplempert (low range 10%, high range 30% die area) und dabei z.B. am rasterizer gespart der als einzige Einheit bei einer GPU wohl schwer mehr als 5% der die area erreicht.

Insgesamt war Intel's groesstes Problem fuer LRB selber nicht irgendwelche Patente die sie von irgendwelcher Effizienz aufhalten wuerden, sondern eher die beschissenen Design-Entscheidungen von non-engineers (ie Management) die diesem aufgezwungen wurden. Wenn sich daran etwas geaendert hat oder aendern wird, dann hat Intel natuerlich auch kein besonderes Problem eine potente GPU in der Zukunft zu entwickeln.

Wie dem auch sei NV's crossbar Patente waren eine Weiter-entwicklung der ex-Gigapixel mo-Bus Patente. Allein von diesen etwas abzuleiten waere fuer Intel eine um weites bessere Idee als das alberne Zeug auf LRB.

Mag zwar bloed klingen, aber ich hab eher das Gefuehl dass NV darauf wettet/hofft dass sich Intel's verkorkste Philosophie wenn es zu Grafik kommt nicht so schnell aendern wird und dabei helfen selbst alle Patente nicht besonders viel.

Kann er... Bei Google das 1. Ergebnis:
http://www.nvidia.de/object/tegra-2-de.html

Ja aber bei welchen genau bit-Raten. Zwischen embedded und PC gibt es immer noch einige Welten an Unterschieden.


Hat der nVidia CEO nicht mal gesagt, sie seien in erster Linie eine Softwarefirma?

Wenn man es auch richtig interpretiert stimmt es auch. Ohne eine gute Balance zwischen hw und sw ist ein jegliches Produkt nicht besonders konkurrenz-faehig egal in welchem Markt. Es reicht wenn eine der beiden Seiten hapert. Wie wuerden als Beispiel Quadros aussehen ohne ihre uebliche sw Unterstuetzung?

Ueberhaupt bei einem SoC kann die unterliegende sw wichtiger werden eventuell als die hw selber. Eben weil eine relativ hohe Anzahl von Prozessoren sich um die gleiche Bandbreite reissen. Wenn ein SoC eine einzige Aufgabe ausfuehrt ist es ja unter normalen Umstaenden auch kein Problem; kritisch wird es erst wenn man zu multi-tasking kommt und man gleichzeitig Applikationen startet die von diversen verschiedenen Prozessoren bedient werden.

In solch einem Fall kommt es dann zu solchen Werbungs-Schlagworten:\

http://images.anandtech.com/doci/4098/tegra2_575px.jpg

http://www.anandtech.com/show/4098/nvidias-tegra-2-take-two-more-architectural-details-and-design-wins/2

Die gruenen Bloecke bilden da tatsaechlich ein heterogenes multi-core config. Und um dieses richtig auf die Beine zu stellen kann natuerlich sw wichtiger werden als die hw selber. Was koennte wohl passieren wenn man zur gleichen Zeit ein HD video decoding, web browsing, eine 3D Applikation und weiss der Geier noch gleichzeitig ausfuehrt, wenn die unterliegende sw die Resourcen nicht anstaendig verteilt.

Ich wuerde ja SoCs als Konzept aussen weg lassen, aber Projekt Denver klingt mir persoenlich eher nach so etwas als alles andere. Und ja ich weiss dass all dies den meisten bekannt ist, aber "software" ist IMO zweifellos einer der groessten Staerken bei NVIDIA. Man muss es nur richtig interpretieren und ja CUDA ist natuerlich ein weiteres Beispiel aber ein anderes Kapitel.

[Gipsel]

Du unterschätzt wie alt die meisten 3D Verfahren wirklich schon sind. [..]Da frage ich mich doch, warum es ständig Patentstreitigkeiten gibt, wenn es da nichts Patentwürdiges mehr gibt. :rolleyes:
Ich hab schon an FAT-Clients gebastelt bevor du hier überhaupt angemeldet warst (herausgekommen ist da workroom in a box, siehe google).Du meinst aber nicht das Jugend forscht Projekt von 2005, oder? Da hat ja auch ein David mitgemacht. :rolleyes: :lol:

Edit:
Na klar bist Du das, hast doch in 2005 schon in anderen Foren (bereits als davidzo) darüber geschrieben. Habt ihr eigentlich irgendwann später nochmal ausprobiert, ob PovRay in Eurer Schule dann schlußendlich schneller war als auf einem einzelnen AthlonXP, sprich ob diese Clusterskalierung geklappt hat? Zur Vorstellung des Projektes hattet ihr ja offenbar nur einen einzigen Client, so daß Ihr das dort schuldig geblieben seid.
Die Realisierung ist kein Problem, die Software ist bereits tauglich dafür, Infrastruktur (LAN) eigentlich schon vorhanden, aber wie bei so vielen Visionären Produkten fehlt den eintscheidenden Leuten mal wieder der Mumm es zu wagen.Das sehe ich ein wenig differenzierter. Wie willst Du singlethreaded Programme, oder welche, bei denen die einzelnen Threads mit geringer Latenz kommunizieren müssen, in der Cloud skalieren? Insofern taugt die Mehrzahl der Programme eben nicht dazu.
Gott bewahre, wie kommst du darauf?
Das funktioniert mit jeder Hardware, aber durch die nutzbaren Synergien kann man annembare leistung auch bei relativ schwacher hardware schon erziehlen.Was ist denn das für ein Gelaber auf die Frage, was genau bei Dir "VLIW-Cluster" sein sollen (offenbar besonders leistungsfähige Rechnerverbünde in der Cloud)?

[Nighthawk13]

Nvidia Maxwell Graphics Processors to Have Integrated ARM General-Purpose Cores: http://www.xbitlabs.com/news/cpu/display/20110119204601_Nvidia_Maxwell_Graphics_Processors_to_Have_Integrated_ARM_General _Purpose_Cores.html

(...)
Nvidia's initiative code-named Denver describes an Nvidia CPU running the ARM instruction set, which will be fully integrated on the same chip as the Nvidia GPU.

Nvidia Maxwell will be launched in 2013, it was revealed at Nvidia's GPU Technology Conference in September, 2010. Given the timeframe, it is logical to expect 20nm process technology to be used for manufacturing of Maxwell. The architecture due in almost three years from now will offer whopping 14 - 16GFLOPS of double-precision performance per watt, a massive improvement over current-generation hardware.

"Between now and Maxwell, we will introduce virtual memory, pre-emption, enhance the ability of GPU to autonomously process, so that it's non-blocking of the CPU, not waiting for the CPU, relies less on the transfer overheads that we see today.
(...)
Unfortunately, not all the details are clear at this point and it is unknown whether all members of the Maxwell family will have integrated GP ARM cores. General-purpose processing cores will bring mosts benefits for compute applications and therefore Nvidia may omit ARM from low-cost designs.

[LovesuckZ]

Verweise besser auf die ursprüngliche Quelle, ansonsten liest es eher wie eine Vorhersage von xbitlabs.com.

Von hexus.net:
Lastly we asked about Project Denver: the surprising announcement that NVIDIA will be designing a CPU in partnership with ARM, with a view to using it in high-end computers. We asked Rayfield to elaborate.

"As well as licensing Cortex A15, we also have an architectural license with ARM to produce an extremely high performance ARM CPU, which be combined with NVIDA GPUs for super-computing," he said. When we asked for timescales, Rayfield revealed: "The Maxwell generation will be the first end-product using Project Denver. This is a far greater resource investment for us than just licensing a design."
http://channel.hexus.net/content/item.php?item=28540&page=2

[stickedy]

Und in deutsch: http://www.heise.de/newsticker/meldung/Nvidia-bestaetigt-Auf-Maxwell-GPUs-sitzen-auch-ARM-Prozessorkerne-1172923.html

[Ailuros]

=/>3 Jahre klingen auch vollkommen normal fuer so ein kompliziertes Projekt.

[deekey777]

Was bedeutet hier eigentlich schlechter? T2 kann sicher keine zwei Streams und auch keine 40 MBit/s AVC/VC1 dekodieren. Was kommt da noch hinzu? (Kann der überhaupt VC1 dekodieren? - Wäre ja kein Beinbruch, wenn nicht.)
Wenn er wirklich nur max. 1080p Baseline beherrscht, dann ist ee schlecht.
Auf der anderen Seite ist das nur die Frage des Blickwinkels: Wenn Tegra2 eh nur Internetvideos wiedergeben wird/muss, dann ist es egal.

[merfu]

Schon bekannt?

Project Denver soll in Maxwell integriert werden.

http://ht4u.net/news/23259_nvidia_will_arm-cpus_in_maxwell-gpus_integrieren_-_erster_schritt_im_project_denver/
http://www.computerbase.de/news/hardware/prozessoren/2011/januar/neues-zu-project-denver-und-tegra-3/

Bei „Project Denver“ handelt es sich um ein „System-on-a-Chip“ – kurz SoC – basierend auf einer ARM-CPU und einem Grafikchip von Nvidia. Eingesetzt werden sollen die entsprechenden SoCs sowohl in kleinen Geräten wie Net- und Notebooks als auch in sogenannten Super-Computern.

Also doch keine High Performance CPU?

MfG
Merfu

[LuXon]

Da hast du wohl etwas durcheinander gebracht. Denver erscheint lediglich zur gleichen Zeit wie Maxwell und hat sonst nicht damit zu tun.

In deinem Zitiertem letzen Satz steht klipp und klar "Eingesetzt... blabla... als auch in sogenannten Super-Computern." Also sollte Denver schon High-Performance liefern.

[merfu]

Im ht4u Beitrag steht aber

Das ehrgeizige Ziel ist dabei ARM-Prozessoren mit Grafikbeschleunigern zu kombinieren und das Resultat in Desktop-Computer, Server und Hochleistungsrechner erfolgreich zu etablieren. Nun sickern die ersten Details zu diesem Projekt durch. Demnach sollen die für 2013 angekündigten Maxwell-GPUs bereits integrierte ARM-Prozessorkerne besitzen und damit den ersten Ableger des "Project Denver" darstellen.

"Maxwell" soll nach aktuellen Informationen seitens NVIDIA in einer 22-nm-Technologie entstehen und im Jahr 2013 auf den Markt kommen. Wie Hexus.net nun von dem NVIDIA-Mitarbeiter Michael Rayfield erfahren hat arbeitet man aktuell daran, ARM-Prozessorkerne in die Maxwell-GPUs zu integrieren.

Zum Thema Hochleistungscomputer:
Die kann man auch mit CPUs bauen die nicht Highperformance segment passen aber z.B. besondern effizient bestimmte Berechnungen durchführen können oder sich besondern Platzsparend verbauen lassen (siehe Blade Ansatz).

MfG

[Deinorius]

Wenn er wirklich nur max. 1080p Baseline beherrscht, dann ist ee schlecht.
Auf der anderen Seite ist das nur die Frage des Blickwinkels: Wenn Tegra2 eh nur Internetvideos wiedergeben wird/muss, dann ist es egal.


Zumindest die Codec-Vielfalt (http://www.nvidia.de/object/tegra-2-de.html) ist zufriedenstellend. Aber das alles in Hardware? Wohl kaum.
Aber du bringst mir grad auf die Idee, wegen den Profilen nachzuschauen. Baseline ist ja nicht so schwierig. Wenns nur um Internetvideos ginge, ok, aber da müsste ich jetzt mit den SGX Chips vergleichen.

[Ailuros]

Zumindest die Codec-Vielfalt (http://www.nvidia.de/object/tegra-2-de.html) ist zufriedenstellend. Aber das alles in Hardware? Wohl kaum.
Aber du bringst mir grad auf die Idee, wegen den Profilen nachzuschauen. Baseline ist ja nicht so schwierig. Wenns nur um Internetvideos ginge, ok, aber da müsste ich jetzt mit den SGX Chips vergleichen.

SoCs mit SGX decodieren video nicht auf der GPU. Semis waeren schoen bloed wenn sie die GPU mit so viel mehr Stromverbrauch quaelen wuerden als einen ff video decoder chip (genauso wie auf Tegra2). TI hat ihr eigenes decoding Zeug und andere wie Apple und Intel z.B. verwenden IMG's VXD IP.

Neuestes Zeug fuer die Zukunft:

http://www.imgtec.com/News/Release/index.asp?NewsID=597

[Deinorius]

Jo eh. Meins eh net anders. Ist halt ne blöde Angewohnheit vom Desktop-Markt. :redface:

Neuestes Zeug fuer die Zukunft:

http://www.imgtec.com/News/Release/index.asp?NewsID=597


Sehr geiles Zeug. Nur 70 MHz für ein H.264 HighProfile HD Stream, nicht schlecht. Hoffentlich meinen die damit FullHD. :D

[Ailuros]

Jo eh. Meins eh net anders. Ist halt ne blöde Angewohnheit vom Desktop-Markt. :redface:
Sehr geiles Zeug. Nur 70 MHz für ein H.264 HighProfile HD Stream, nicht schlecht. Hoffentlich meinen die damit FullHD. :D

H.264HP@L4.1 - 1920*1080@30fps <100MHz
H.264HP@L4.2 - 1920*1080@60fps <266MHz
Dual Stream H.264HP - 1920*1080@30fps =266MHz

[Deinorius]

Es wird wohl kaum schon Verbrauchs/TDP Werte bzw. vielleicht sogar Angaben geben, wie groß die IP werden könnte?

[deekey777]

Zumindest die Codec-Vielfalt (http://www.nvidia.de/object/tegra-2-de.html) ist zufriedenstellend. Aber das alles in Hardware? Wohl kaum.
Aber du bringst mir grad auf die Idee, wegen den Profilen nachzuschauen. Baseline ist ja nicht so schwierig. Wenns nur um Internetvideos ginge, ok, aber da müsste ich jetzt mit den SGX Chips vergleichen.
Seit VP1 sind alle Videodecoder eigentständige Einheiten innerhalb der GPU, die GPU selbst kümmert sich maximal um Deinterlacing und Postprocessing.

Das Szenario ist, dass man zB DVB-Stream auf ein Tablet streamt. Ist der Videodecoder eingeschränkt, was seine Fähigkeiten angeht (zB wenn ein bestimmter Apfel-IHV nur H.264@Baseline zulässt), muss dieser Stream in Echtzeit umgewandelt werden.

[Coda]

Ich muss hier mal pushen Sehr guter Artikel dazu:
http://arstechnica.com/business/news/2011/02/nvidia-30-and-the-riscification-of-x86.ars

[fondness]

Danke, damit bestätigt sich auch das was ich schon mehrmals gesagt habe, aber mir so manche NV-Fans nicht glauben wollte:

Huang was quite clear that NVIDIA could have chosen to produce an x86 processor—he described the licensing and technical problems associated with making an x86 CPU as "solvable" for NVIDIA.

Die x86 Lizenz ist nicht das Problem. Es ist nur einfach völlig unrealistisch anzunehmen, dass NV aus dem nichts eine CPU stampft, die mit Intel oder AMD konkurrieren könnte. Die ARM-Architektur ist hingegen die perfekte Gelegenheit den Markt von unter aufzurollen ohne direkt mit Intel konkurrieren zu müssen. Man bekommt fertige CPU-Cores und darf diese modifizieren. Wie sich das in Zukunft entwickelt wird man sehen. Der Artikel gefällt mir auch deshalb sehr gut, weil er eine realistische Sicht auf die tolle Perf/Watt der ARM-Architektur darstellt. Manche glauben ja hier ARM wären da irgendwie technologisch überlegen.

[Mancko]

Danke, damit bestätigt sich auch das was ich schon mehrmals gesagt habe, aber mir so manche NV-Fans nicht glauben wollte:



Die x86 Lizenz ist nicht das Problem. Es ist nur einfach völlig unrealistisch anzunehmen, dass NV aus dem nichts eine CPU stampft, die mit Intel oder AMD konkurrieren könnte. Die ARM-Architektur ist hingegen die perfekte Gelegenheit den Markt von unter aufzurollen ohne direkt mit Intel konkurrieren zu müssen. Man bekommt fertige CPU-Cores und darf diese modifizieren. Wie sich das in Zukunft entwickelt wird man sehen. Der Artikel gefällt mir auch deshalb sehr gut, weil er eine realistische Sicht auf die tolle Perf/Watt der ARM-Architektur darstellt. Manche glauben ja hier ARM wären da irgendwie technologisch überlegen.

Du interpretierst etwas aus deiner roten Brille hinein was er nicht gesagt hat. Ich quote mal den Teil der relevant ist:

First was the fact that there was already another company attempting to compete with Intel in the x86 market (AMD), mostly without success. Why, he asked, would NVIDIA want to jump in and make a type of product that AMD, whose processor designs he praised, had been struggling to turn a profit with for years? So in Huang's telling, there was simply no good business case for taking on Intel in x86, with AMD's troubles serving as concrete proof of the folly of trying to compete with Intel in making yet another x86 processor.


Mit anderen Worten er sagt nicht, das Nvidia nicht in der Lage ist einen konkurenzfähigen Prozessor zu bauen, sondern das es wenig Möglichkeiten gibt dort noch Geld zu verdienen. AMD ist der lebende Beweis eines seit Jahrzehnten erfolglosen Unternehmens.

[Exxtreme]

Man hätte durchaus die Chance den Markt aufzumischen. Hat man damals bei den Chipsätzen gesehen. Nur leider ist das so, dass Intel dann wohl wieder zu Mitteln greift, die nicht mit Kartellrechten kompatibel sind.

[fondness]

Du interpretierst etwas aus deiner roten Brille hinein was er nicht gesagt hat.

Schon arm wenn man nicht in der Lage ist sachlich zu bleiben. Und nein, ich werde mich jetzt nicht auf dein Niveau begeben.


Ich quote mal den Teil der relevant ist:


Mit anderen Worten er sagt nicht, das Nvidia nicht in der Lage ist einen konkurenzfähigen Prozessor zu bauen, sondern das es wenig Möglichkeiten gibt dort noch Geld zu verdienen. AMD ist der lebende Beweis eines seit Jahrzehnten erfolglosen Unternehmens.

Und wenn du jetzt mal ein bisschen über den Tellerrand schaust, dann könntest du dich fragen, warum sie glauben da kein Geld zu verdienen, obwohl der Markt dutzende Milliarden hergibt. Natürlich sagt er nicht das NV keinen konkurrenzfähigen Prozessor bauen kann, kein CEO der Welt würde das sagen. Die x86-Lizenz ist kein Problem, damit bleibt nur noch das Problem ein konkurrenzfähiges Produkt aus dem Boden zu stampfen, denn natürlich kann man nur so Geld verdienen.

Und richtig, auch AMD verdient nicht viel, doch auch die haben bereits jahrzehntelanges know-how in dem Bereich aufgebaut. Ich sage schon länger, das es töricht ist anzunehmen, mal eben so aus dem nichts mit AMD und Intel zu konkurrieren, deshalb macht ein Einstieg in den x86-Markt eben keinen Sinn. Das sagt ja auch der Artikel ganz klar, das wird selbst mit den ARM-Cores schwer genug. So haben sie eben einen Weg gefunden in den Prozessormarkt einzusteigen, ohne direkt mit Intel konkurrieren zu müssen. Für Nv eine einmalige Chance, die man natürlich nützen muss.

[Ailuros]

Der arstechnica write-up ist zwar insgesamt gut und bringt ein paar sehr gute Punkte zum Tisch, aber das Ganze ist trotz allem etwas unuebersichtlich geschrieben.

Hier mal eine andere Perspektive: http://www.xbitlabs.com/news/other/display/20110222224530_Post_PC_Era_Marks_the_End_of_Wintel_Monopoly_Chairman_of_Lenovo.h tml

So haben sie eben einen Weg gefunden in den Prozessormarkt einzusteigen, ohne direkt mit Intel konkurrieren zu müssen. Für Nv eine einmalige Chance, die man natürlich nützen muss.

NV geht es weniger um den CPU Markt, sondern eher um den notebook/PC SoC Markt. Eigentlich lag NV hier im Zugzwang zu einer Loesung denn irgendwo und irgendwie muessen auch IHVs weiterwachsen und mit jeglicher Art GPUs allein wird es eben nicht ausreichen langfristig.

Es ist kein Zufall dass der arstechnica Artikel oben mit zahllosen Thesen spielt; die Zukunft mit Sicherheit schon jetzt zu vorhersagen klingt mir zu gewant momentan. Ich erwarte aber durchaus dass sich einiges an der heutigen Landschaft in der weiteren Zukunft aendern wird, und nein ich sehe nirgends eine Garantie dass NV oder Intel (oder jegliche andere beliebige Kombination) hier wirklich der eigentliche Gewinner sein wird.

[Coda]

ahahahahhahahahahhaha der war gut. :D
Angeblich hat beispielsweise allein der Adobe Reader 16 Mio. Zeilen Code. Wurde zumindest auf dem 27C3 behauptet.

Wobei durch die Portierung auf eine andere Platform doch schon viel getan werden musste, beispielsweise Endianess-Probleme beseitigen.

[hell_bird]

Interessant finde ich die These, dass Intel mit seinem x86-Design zwar technisch überlegen sein wird, sich aber der summierten Macht des ARM-Ökosystems beugen werden muss. Ich glaube fast die Lizenzpolitik von ARM ist deutlich intelligenter als die von Intel.

[stickedy]

Ich glaube fast die Lizenzpolitik von ARM ist deutlich intelligenter als die von Intel.
Sie lässt sich vor allem überhaupt nicht vergleichen...

[Ailuros]

Interessant finde ich die These, dass Intel mit seinem x86-Design zwar technisch überlegen sein wird, sich aber der summierten Macht des ARM-Ökosystems beugen werden muss. Ich glaube fast die Lizenzpolitik von ARM ist deutlich intelligenter als die von Intel.

In einem Markt wo hauptsaechlich IP lizenziert wird sollte es wohl klar sein dass ARM als IP Lizenz-Firma den absoluten Vorteil hat. Intel konkurriert dann am Ende nicht gegen ARM selber sondern gegen alle anderen grossen Semi Hersteller die ARM CPU IP integrieren.

[LovesuckZ]

Die x86 Lizenz ist nicht das Problem. Es ist nur einfach völlig unrealistisch anzunehmen, dass NV aus dem nichts eine CPU stampft, die mit Intel oder
AMD konkurrieren könnte. Die ARM-Architektur ist hingegen die perfekte Gelegenheit den Markt von unter aufzurollen ohne direkt mit Intel konkurrieren zu müssen. Man bekommt fertige CPU-Cores und darf diese modifizieren. Wie sich das in Zukunft entwickelt wird man sehen. Der Artikel gefällt mir auch deshalb sehr gut, weil er eine realistische Sicht auf die tolle Perf/Watt der ARM-Architektur darstellt. Manche glauben ja hier ARM wären da irgendwie technologisch überlegen.

Zeige uns doch mal das ARM-Design, welches nVidia "lizensieren und modifzieren" kann.
Und wie nVidia mit ARM den Markt von "unten aufrollen" kann, ist schon erstaunlich. Haben sie doch explizit ausgedrückt, dass Denver von oben in den Markt gehen wird.

Schon arm wenn man nicht in der Lage ist sachlich zu bleiben. Und nein, ich werde mich jetzt nicht auf dein Niveau begeben.

Ändert nunmal nichts daran, dass er recht hat. Es steht explizit im Text, warum nVidia keinen x86 Prozessor bauen wollte. Ich zitiere nochmal für dich:


First was the fact that there was already another company attempting to compete with Intel in the x86 market (AMD), mostly without success. Why, he asked, would NVIDIA want to jump in and make a type of product that AMD, whose processor designs he praised, had been struggling to turn a profit with for years? So in Huang's telling, there was simply no good business case for taking on Intel in x86, with AMD's troubles serving as concrete proof of the folly of trying to compete with Intel in making yet another x86 processor.

Es ist ganz klar und eindeutig: Sie sehen keinen profitablen Markt. AMD hat eine Marge von 45%, nVidia steht zZ bei 48,1%.


Und wenn du jetzt mal ein bisschen über den Tellerrand schaust, dann könntest du dich fragen, warum sie glauben da kein Geld zu verdienen, obwohl der Markt dutzende Milliarden hergibt. Natürlich sagt er nicht das NV keinen konkurrenzfähigen Prozessor bauen kann, kein CEO der Welt würde das sagen. Die x86-Lizenz ist kein Problem, damit bleibt nur noch das Problem ein konkurrenzfähiges Produkt aus dem Boden zu stampfen, denn natürlich kann man nur so Geld verdienen.

Ach und das schaffen sie mit ARM?
Nur um das klarzustellen: Einerseits unterstellst du ihnen, keinen "konkurrenzfähigen" x86 Prozessor bauen zu können, gleichzeitig wären sie in der Lage einen "konkurrenzfähigen" ARM-Prozessor produzieren zu können.
Naja, Logik und so.

So haben sie eben einen Weg gefunden in den Prozessormarkt einzusteigen, ohne direkt mit Intel konkurrieren zu müssen. Für Nv eine einmalige Chance, die man natürlich nützen muss.

Achja? Und das ohne mit Intel konkurrieren zu können? Wie das denn?
Es gibt also einen so riesigen Servermarkt, der weder von Intel und AMD bedient wird? Man, AMD sollte dich einstellen. Dann klappt es bestimmt auch wieder mit einem höhreren Marktanteil bei den Server-CPUs. :freak:

[Tesseract]

Angeblich hat beispielsweise allein der Adobe Reader 16 Mio. Zeilen Code. Wurde zumindest auf dem 27C3 behauptet.

Wobei durch die Portierung auf eine andere Platform doch schon viel getan werden musste, beispielsweise Endianess-Probleme beseitigen.
die anzahl der codezeilen sagen aber nix über die qualität aus. mir fällt echt kein (großer) entwickler sein, der so miese portierungen abliefert wie adobe. man muss sich nur mal den flash-sauhaufen (insbesondere die 64bit version und insbesondere auf non-windows-systemen) ansehen.
Ich muss hier mal pushen Sehr guter Artikel dazu:
http://arstechnica.com/business/news/2011/02/nvidia-30-and-the-riscification-of-x86.ars
der artikel ist mir ein bischen zu spekulativ was die fähigkeiten von nvidia angeht und imho eine ziemlich falsche einschätzung des PC-marktes generell.

aus hardwaresicht bedient ein desktoptauglicher SoC einen großteil der PC-nutzer wahrscheinlich wesentlich besser als momentane systeme. im prinzip bestehen heute fast alle desktop-PCs nur noch aus einem mit cpu+ram bestücktem board mit lauter leeren erweiterungsslots und einer grafikkarte - und oft sogar ohne die. ein halbwegs potenter, hochskalierter SoC der ein paar prozente und nicht ganze größenordnungen langsamer ist, aber potenziell viele kosten sparen kann ist hier (vor allem im OEM-bereich) wahrscheinlich pures gold wert falls er vom markt angenommen wird und hätte zumindest aus hardwaresicht das potenzial einen großteil des kompletten weltweiten PC-marktes zu verschlingen. für laptops und als basis für konsolen sowieso.

klassische desktops sind inzwischen eher ein hat-man-aus-mangel-an-alternativen-produkt.

[LovesuckZ]

Nicht zu vergessen, dass die Leute keine Probleme haben sich mit einem anderen OS anzufreunden. Windows spielt eine immer geringere Bedeutung.

Man muss nur mal überlegen: Man kauft sich im (x-beliebigen) Market eine Schreibsoftware und kann sie gleichermaßen auf dem Smartphone, Tablet und SoC-Desktop verwenden und wenn dann eine Vielzahl des Contents ins Web ausgelagert wird, benötigt man nichtmal mehr riesige Datenträger.
Solch ein SoC-Desktop kommt mit weniger als maximal 5 Watt aus (das AC100 von Toshiba verbraucht mit LCD, WLAN und Android 2.2 knapp 2,5 Watt/h) und bietet ein "Erlebnis", dass mit Low-End Systemen mithalten kann. Und die nächste Generation an SoCs bringen dann auch Video-Dekoder mit, die 1080p entsprechend wiedergeben sollten ohne heutige Einschränkungen aufzuweisen.

[Tesseract]

Solch ein SoC-Desktop kommt mit weniger als maximal 5 Watt aus (das AC100 von Toshiba verbraucht mit LCD, WLAN und Android 2.2 knapp 2,5 Watt/h) und bietet ein "Erlebnis", dass mit Low-End Systemen mithalten kann. Und die nächste Generation an SoCs bringen dann auch Video-Dekoder mit, die 1080p entsprechend wiedergeben sollten ohne heutige Einschränkungen aufzuweisen.

ich habe eigentlich SoCs gemeint, die performant genug sind um es tatsächlich mit non-high-end-desktops aufnehmen zu können. also sowohl performancemäßig als auch vom verbrauch noch über z.B. AMDs bobcat angesiedelt sind und auch fähig sind windows und dergleichen ordentlich zu betreiben.
SoC-systeme mit vielleicht 80-100W, einem wesentlich kompakteren formfaktor als ATX und preisen, die normale desktop-PCs deutlich unterbieten, wären ein absoluter klassischer-desktop-killer.

und so wie ich das verstanden habe will nvidia ja sowas in die richtung bauen. zumindest den hardware-teil davon. einen SoC, der ein einfacher ausführung z.B. die meisten desktops, laptops und konsolen bedienen und in mehrfacher ausführung basis für supercomputer sein kann.

[LovesuckZ]

ich habe eigentlich SoCs gemeint, die performant genug sind um es tatsächlich mit non-high-end-desktops aufnehmen zu können. also sowohl performancemäßig als auch vom verbrauch noch über z.B. AMDs bobcat angesiedelt sind und auch fähig sind windows und dergleichen ordentlich zu betreiben.

Warum Windows?
Der Smartphone- und Tablet-Markt zeigt, dass Windows kein Muss mehr darstellt. Die Bedinung ist wesentlich einfacherer und komfortabler. Windows im Vergleich erscheint dagegen wesentlich komplizierter.


SoC-systeme mit vielleicht 80-100W, einem wesentlich kompakterem formfaktor als ATX und preisen, die normale desktop-PCs deutlich unterbieten, wären ein absoluter desktop-killer.

Abgesehen von Spielen und Encoding sind Desktop-Systeme doch heute schon viel zu komplex und überpowert. Ein entschlacktes OS, die nächste Generation an SoCs und man könnte Systeme bauen, die sehr klein sind und mit maximal 10 Watt keine Konkurrenz durch x86 fürchten müssen.

[Tesseract]

Warum Windows?
Der Smartphone- und Tablet-Markt zeigt, dass Windows kein Muss mehr darstellt. Die Bedinung ist wesentlich einfacherer und komfortabler. Windows im Vergleich erscheint dagegen wesentlich komplizierter.
das ist unsinn. für viele aufgaben kommst du momentan an einem desktop-system nicht vorbei. schon allein wegen der peripherie, den entwicklungsumgebungen, softwaresuites, großen monitoren usw.


Abgesehen von Spielen und Encoding sind Desktop-Systeme doch heute schon viel zu komplex und überpowert.
genau das macht SoC ja so interessant. allerdings nicht die modelle um die 10W. bei denen ist momentan die kluft zum desktop dann doch noch zu groß.

[LovesuckZ]

das ist unsinn. für viele aufgaben kommst du momentan an einem desktop-system nicht vorbei. schon allein wegen der peripherie, den entwicklungsumgebungen, softwaresuites, großen monitoren usw.

Ich rede auch nicht von Unternehmen. Wobei dort auch vieles über Server zur Verfügung gestellt wird und man an Thin-Clients arbeitet.
Ich fasste dein "Desktop-Rechner" für "den Größteil der PC-Benutzer" auf. Und diese Menschen machen kein Encoding oder benötigen entsprechende Hardware für gute bis sehr gut BQ in Spielen.
Surfen, Mails abrufen, Chatten, Twitter, Facebook, Flash, HTML5, Schreiben, Excel... lassen sich in absehbarer Zukunft alle über ARM-SoC und einem nicht Windows-OS in zufriedenstellender Geschwindigkeit erledigen. Und das bei unter 10 Watt.


genau das macht SoC ja so interessant. allerdings nicht die modelle um die 10W. bei denen ist die kluft zum desktop dann doch noch zu groß.

Die messbare. Aber die gefühlte Kluft kann deutlich darunter liegen. Und sobald einem die Arbeitsgeschwindigkeit nicht stört, hat die messbare Kluft auch keine Bedeutung mehr. Und wenn man dann erst anfängt Anschaffungskosten und Stromverbrauch gegen zu rechnen, sieht es dann vielleicht doch vollkommen anders aus.

[Tesseract]

Surfen, Mails abrufen, Chatten, Twitter, Facebook, Flash, HTML5, Schreiben, Excel... lassen sich in absehbarer Zukunft alle über ARM-SoC und einem nicht Windows-OS in zufriedenstellender Geschwindigkeit erledigen. Und das bei unter 10 Watt.
du vergisst, dass der PC sehr heterogen genutzt wird und sehr viele leute trotzdem szenarien dabei haben, die durchaus einiges an performance abverlangen können. zumindest genug um ein 10W-SoC an die grenzen zu treiben.
und in wahrheit sind spiele am PC im privatbereich immer noch ein verdammt großes einsatzfeld.


Wobei dort auch vieles über Server zur Verfügung gestellt wird und man an Thin-Clients arbeitet.
ich glaube du überschätzt das ein bischen. eine riesige gruppe mittelständischer unternehmen, viele bereiche die mit "content creation" zutun haben aber auch viele behörden und andere organisationen arbeiten garnicht oder nur teilweise mit thin-clients.

[LovesuckZ]

du vergisst, dass der PC sehr heterogen genutzt wird und sehr viele leute trotzdem szenarien dabei haben, die durchaus einiges an performance abverlangen können. zumindest genug um ein 10W-SoC an die grenzen zu treiben.

In diesem Fall könnte man sich ein Windows - x86 Desktop-System in den Keller stellen und bei Bedarf das Windows per VirtualerBox zum ARM-SoC senden - siehe z.B. auch Splashtop.


und in wahrheit sind spiele am PC im privatbereich immer noch ein verdammt großes einsatzfeld.

Da sehe ich kein Problem. Die Entwicklung ist rasant in diesem Bereich. Und mit Tastatur + Maus könnte man die selben Spiele anbieten wie auf dem x86 Desktop. Zwar mit schlechterer Grafik, aber die Konsolen zeigen ja, dass Grafik für viele nicht der entscheidene Punkt ist.



ich glaube du überschätzt das ein bischen. eine riesige gruppe mittelständischer unternehmen, viele bereiche die mit "content creation" zutun haben aber auch viele behörden und andere organisationen arbeiten nicht mit thin-clients sondern normalen pcs oder macs.

Ich kenne nur die Entwicklungsbranche in Dienstleistungsunternehmen. Und die arbeiten alle mit Thin-Clients. Aber das war ja auch nicht Ausgangspunkt.

/edit: Ein Beispiel mit dem Atrix 4G: http://www.youtube.com/watch?v=lzryaZwLqTo

[Tesseract]

In diesem Fall könnte man sich ein Windows - x86 Desktop-System in den Keller stellen und bei Bedarf das Windows per VirtualerBox zum ARM-SoC senden - siehe z.B. auch Splashtop.

klar, das wird auch jeder, der z.B. ein video zusammenschneidet tun. :freak:
und warum sollte der durchschnittsuser neben einem 10W-SoC überhaupt einen windows-PC rumstehen haben?
das ist doch absolut realitätsfern. wenn, dann steigen user bei ihrer nächsten PC-neuanschaffung auf ein derartiges system um und dazu muss es einfach potent und flexibel genug sein um überhaupt als ersatz in frage zu kommen.


Und mit Tastatur + Maus könnte man die selben Spiele anbieten wie auf dem x86 Desktop. Zwar mit schlechterer Grafik, aber die Konsolen zeigen ja, dass Grafik für viele nicht der entscheidene Punkt ist.
kA was du für vorstellungen über die leistungsfähigkeit eines chips mit 10W verbrauch hast. schau dir mal die benchmarks von bobcat an und vergleich das mit modernen mittelklasse-PCs.

[Ailuros]

Der mobile/embedded Markt skaliert zwar ziemlich schnell, aber damit man in vorhersehbarer Zeit so viel mit einem 10W SoC anrichten koennte muesste auch vorraussetzen dass der desktop Markt ueberhaupt keine Aenderung sehen wuerde fuer die Zukunft.

Die beiden Maerkte skalieren parallel.


kA was du für vorstellungen über die leistungsfähigkeit eines chips mit 10W verbrauch hast. schau dir mal die benchmarks von bobcat an und vergleich das mit modernen mittelklasse-PCs.

DX11 GPU block der bei nur 1024 mit mittleren settings entweder gerade noch am Rand oder unter diesem der Spielbarkeit liegt und das bei lediglich DX9/10 Spielen.

http://www.anandtech.com/show/4134/the-brazos-review-amds-e350-supplants-ion-for-miniitx/5

Und bevor mir jemand wieder mit dem Maerchen kommt dass zukuenftige hw den Zauberstab haben wird um N Male schneller zu sein, bleibt es immer noch dabei dass desktop nicht bei Stillstand ist. Es wird stets eine analoge Relation geben.

Das schlimmste ist natuerlich dass die meisten immer noch nicht zu schnallen vermoegen was in einem typischen heutigen smart-phone/tablet heute steckt. IHVs wie NVIDIA versprechen einen Haufen Scheiss durch Marketing, aber sehr viel steckt doch nicht dahinter eben weil der Stromverbrauch und Bandbreite bei embedded generell viel zu viel begrenzt.

Der obrigen C50 mit 80SPs@280MHz und den Bobcats liegt +/- auf Sony NGP Nivaeu wobei die beiden auch ziemlich schlecht vergleichbar sind. NGP liegt aber dem heutigen schnellsten SoC gute 4x Mal im Vorsprung, der low level API Vorteil gar nicht mitberechnet.

Machen wir es nochmal mit theoretischen Zahlen:

T2 ULP GF (240MHz): 3.84 GFLOPs, 70M Vertices/s (transformation only)*, 480MPixels/s, 1.92 GPixels/s z/stencil

NGP GPU (200MHz): 28.80 GFLOPs, 133M real Tris/s (2.3M Tris/frame complexity @60Hz), 1600MPixels/s, 12.8 GPixels/s z/stencil

* nein der trisetup gibt keine 20 oder sogar 30M Tris ab.

Beide sind unter 40nm; das zweite braucht lediglich 3x Mal so viel die area und verbraucht insgesamt als SoC (NGP) um die 4+W.

[fondness]

Zeige uns doch mal das ARM-Design, welches nVidia "lizensieren und modifzieren" kann.
Und wie nVidia mit ARM den Markt von "unten aufrollen" kann, ist schon erstaunlich. Haben sie doch explizit ausgedrückt, dass Denver von oben in den Markt gehen wird.

Jedes ARM-Design das sie lizenzieren. Und wenn du glaubst, dass sie mit diesem Projekt eine dann aktuelle Server-High-End-CPU schlagen können, bist du einfach nur naiv.


Es ist ganz klar und eindeutig: Sie sehen keinen profitablen Markt. AMD hat eine Marge von 45%, nVidia steht zZ bei 48,1%.

Bitte verwende kein Zahlenmaterial dessen Bedeutung du nicht verstehst. Ansonsten: Um einen Markt zu beurteilen nimmt man nicht den schwächsten Vertreter raus, es sei denn man glaubt auch nicht besser oder gar noch schlechter konkurrieren zu können. Der x86 Markt ist riesig und wirft gigantische Margen ab, weit mehr als NV aktuell mit ihren GPUs verdienen könnte.


Ach und das schaffen sie mit ARM?
Nur um das klarzustellen: Einerseits unterstellst du ihnen, keinen "konkurrenzfähigen" x86 Prozessor bauen zu können, gleichzeitig wären sie in der Lage einen "konkurrenzfähigen" ARM-Prozessor produzieren zu können.
Naja, Logik und so.

Entschuldigung, diese Schluss ist wohl zu hoch für dich, damit habe ich nicht gerechnet. Von ARM können sie fertige CPU-Designs lizenzieren, Intel wird ihnen keinen SandyBridge zum nachbauen geben, das ist der Unterschied. Wenn Projekt Denver nicht so gut läuft wie erhofft, ist für NV bei weitem nicht so viel verloren, wie wenn ein x86 Prozessor-Design schief laufen würde, denn dann würden sie mit nichts dastehen.


Achja? Und das ohne mit Intel konkurrieren zu können? Wie das denn?


Man hat eine ganze Armada an anderen ARM Lizenznehmern, die auch Endkundengeräte vertreiben und die Architektur pushen. Direkte Leistungsvergleiche werden durch die unterschiedliche Architektur schwierig, ARM rollt den Markt von unten auf. Es reicht gut genug zu sein, man muss Intel nicht schlagen. Auch Intel hat es zu beginn nicht anders gemacht, man war keineswegs besser, man war billiger.

Es gibt also einen so riesigen Servermarkt, der weder von Intel und AMD bedient wird? Man, AMD sollte dich einstellen. Dann klappt es bestimmt auch wieder mit einem höhreren Marktanteil bei den Server-CPUs. :freak:

Damit hast du mal wieder bewiesen das du nicht fähig bist vernünftig zu diskutieren. Wenn dir die Argumente ausgehen kommen Häme. Ich werden auch nicht mehr weiter auf deine Beiträge eingehen, das habe ich schon zu oft gemacht, und es ist leider völlig sinnlos.

[LovesuckZ]

Jedes ARM-Design das sie lizenzieren. Und wenn du glaubst, dass sie mit diesem Projekt eine dann aktuelle Server-High-End-CPU schlagen können, bist du einfach nur naiv.

Und welches ARM-Design können sie lizenzieren, um im Servermarkt bestehen zu können? A15? ;D
Ich weiß, es ist in diesem Forum verpöhnt die Wahrheit zu sagen, aber nVidia hat ganz klar den Servermarkt als Hauptziel ausgegeben. Wie sie das "von unten" schaffen sollen, ist sowas von unklar. Hier solltest du mal mehr Informationen liefern.


Bitte verwende kein Zahlenmaterial dessen Bedeutung du nicht verstehst. Ansonsten: Um einen Markt zu beurteilen nimmt man nicht den schwächsten Vertreter raus, es sei denn man glaubt auch nicht besser oder gar noch schlechter konkurrieren zu können.

Immernoch ist VIA der "schwächste Vertreter" mit einem Marktanteil wohl unter 0,0%. Aber anscheinend hast du mal wieder deine Meinung geändert, da nVidia mit ihrem ersten Prozessordesign locker mit AMD mithalten könnte - siehe auch:


Die x86 Lizenz ist nicht das Problem. Es ist nur einfach völlig unrealistisch anzunehmen, dass NV aus dem nichts eine CPU stampft, die mit Intel oder AMD konkurrieren könnte.


Und richtig, auch AMD verdient nicht viel, doch auch die haben bereits jahrzehntelanges know-how in dem Bereich aufgebaut. Ich sage schon länger, das es töricht ist anzunehmen, mal eben so aus dem nichts mit AMD und Intel zu konkurrieren, deshalb macht ein Einstieg in den x86-Markt eben keinen Sinn.


Der x86 Markt ist riesig und wirft gigantische Margen ab, weit mehr als NV aktuell mit ihren GPUs verdienen könnte.

Klar, wenn man Intel heißt und zich Milliarden in F+E investieren kann. Heißt man dagegen AMD, ist weder der x86 Markt riesig (Umsatz $1,2 Mrd.) noch werfe er für AMD "gigantische Margen ab" (45%).


Entschuldigung, diese Schluss ist wohl zu hoch für dich, damit habe ich nicht gerechnet. Von ARM können sie fertige CPU-Designs lizenzieren, Intel wird ihnen keinen SandyBridge zum nachbauen geben, das ist der Unterschied. Wenn Projekt Denver nicht so gut läuft wie erhofft, ist für NV bei weitem nicht so viel verloren, wie wenn ein x86 Prozessor-Design schief laufen würde, denn dann würden sie mit nichts dastehen.

Welches ARM-Design? Jaja, jetzt kommt er wieder mit der Wahrheit, aber: nVidia hat ganz klar gesagt, dass sie kein ARM-Design lizenzieren, sondern eine Lizenz gekauft haben, um ihr eigenes ARM-Design zu entwickeln.
Siehe dazu auch nVidia:
LAS VEGAS, NV -- (Marketwire) -- 01/05/2011 -- CES 2011 -- NVIDIA announced today that it plans to build high-performance ARM® based CPU cores, designed to support future products ranging from personal computers and servers to workstations and supercomputers.

Known under the internal codename "Project Denver," this initiative features an NVIDIA® CPU running the ARM instruction set, which will be fully integrated on the same chip as the NVIDIA GPU.

This new processor stems from a strategic partnership, also announced today, in which NVIDIA has obtained rights to develop its own high performance CPU cores based on ARM's future processor architecture.
http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F09&version=live&releasejsp=release_157&xhtml=true&prid=705184

Man hat eine ganze Armada an anderen ARM Lizenznehmern, die auch Endkundengeräte vertreiben und die Architektur pushen. Direkte Leistungsvergleiche werden durch die unterschiedliche Architektur schwierig, ARM rollt den Markt von unten auf. Es reicht gut genug zu sein, man muss Intel nicht schlagen. Auch Intel hat es zu beginn nicht anders gemacht, man war keineswegs besser, man war billiger.

Macht natürlich Sinn nicht Intel und AMD zu schlagen, aber in den selben Markt - Server - eintreten zu wollen.
Mal für dich alleine, weil du anscheinend nicht verstanden hast, wo nVidia mit Denver rein will:

As you may have seen, NVIDIA announced today that it is developing high-performance ARM-based CPUs designed to power future products ranging from personal computers to servers and supercomputers.
http://blogs.nvidia.com/2011/01/project-denver-processor-to-usher-in-new-era-of-computing/

[Nakai]

Und welches ARM-Design können sie lizenzieren, um im Servermarkt bestehen zu können? A15?

Mhh, wieso? Denver braucht CPU-Cores um die GPU-Cores schnell zu füttern, ergo die Lantenz zwischen CPU <-> GPU muss so niedrig wie möglich gehalten werden. A15 mit dementsprechende Veränderungen wäre hier passend.
Würde auch dazu passen, dass NV ihr "eigenes" Design verwenden wird.
Dazu sollte NV scho genug KnowHow haben.

Wie das Nv lösen wird, wird interessant. Mit CUDA hat man natürlich schon eine interessante Softwarebasis, die dementsprechend ausgebaut werden kann.


mfg

[LovesuckZ]

Mhh, wieso? Denver braucht CPU-Cores um die GPU-Cores schnell zu füttern, ergo die Lantenz zwischen CPU <-> GPU muss so niedrig wie möglich gehalten werden. A15 mit dementsprechende Veränderungen wäre hier passend.

Das funktioniert vielleicht im HPC-Markt, aber im Consumermarkt und Server-Bereich glaube ich nicht, dass ein modifiziertes A15 Design ausreichen sein würde. Immer benötigt man in dem Zielbereich auch eine entsprechende CPU-Leistung für Encoding, für Videobearbeitung, auch für grafisch anspruchsvolle Spiele.

[Ailuros]

Keine Ahnung ob ich es schon erwaehnt habe, aber afaik ist Project Denver erst ab TSMC 20HP.

Und nein natuerlich reicht Eagle nicht aus fuer high end. A15 hat lediglich eine ~40% Effizienz-steigerung gegenueber A9 und der groessere Leistungs-zusatz bei A15 kommt eher von der Frequenz-Seite die schon fuer bis zu 2.5GHz angegeben wurden von A15 lead Partner. Kommt mir jetzt bloss keiner mit irgend einer Bums =/>5GHz These fuer diesen.....

In einem zukuenftigen Supercomputer braucht uebrigens NV an fuer sich keinen Ultra-super-duper CPU block da sie wohl eher in Richtung von N FP64 GFLOPs aus einer GPU ueberreden wollen. Natuerlich wird ein solcher SoC nicht CPU bound sein, aber es koennte mit solch einem Ziel auch ziemlich wurscht sein wenn Intel's CPUs in dem Fall besser sein sollten.

[=Floi=]

DX11 GPU block der bei nur 1024 mit mittleren settings entweder gerade noch am Rand oder unter diesem der Spielbarkeit liegt und das bei lediglich DX9/10 Spielen.


nur ist die 1024er auflösung und kein AF/AA keine option für ein desktop system!
Das ist doch komplett fern jeglicher realität, wenn man echte 3d games spielen will. Da benötigt man gleich mal 10-30x mehr leistung!
---
es ist aber schon erstaunlich, was handys heute können! Wer von einem 486er kommt, für den ist es es schon ein kleines wunder, was mittlerweile auf den kleinen dingern alles läuft. :eek:

[Ailuros]

nur ist die 1024er auflösung und kein AF/AA keine option für ein desktop system!
Das ist doch komplett fern jeglicher realität, wenn man echte 3d games spielen will. Da benötigt man gleich mal 10-30x mehr leistung!

Der Link oben zeigte wie sich ein 80SP@280MHz/C50 mehr oder weniger in der Region verhaelt. Eine heutige T2 GPU liegt um die 10x-11x unter so einem Ding; gut mit T3 kommt noch ungefaehr nochmal 2x bis 2.5x GPU Leistung dazu, aber der Weg bis zu C50 Nivaeu ist immer noch sehr lang, von vergleichbarer heutiger desktop Leistung selbst einer mainstream standalone GPU noch einige Lichtjahre entfernt.


es ist aber schon erstaunlich, was handys heute können! Wer von einem 486er kommt, für den ist es es schon ein kleines wunder, was mittlerweile auf den kleinen dingern alles läuft. :eek:

Ja selbstverstaendlich ist es imposant wie der embedded Markt skaliert und ueberhaupt das eigentliche Tempo. Es hat mit vertex shadern irgendwo ueber DX7 angefangen und heute sind wir schon mit nur einer weiteren Generation bei DX9.0/SM3.0 und wer weiss wie OGL_ES3.0/Halti genau aussehen wird.

Ebenso beindruckend ist die Leistung, aber man sollte trotz allem nicht vergessen dass wenn bei einem smartphone alle X Jahre die Leistungskurve um N% steigt, steigt sie ebenso um Y% im desktop. Das ganze verlaueft wie ich schon sagte parallel.

Anders es sich vorzustellen waere dass ein heutige high end embedded GPU ein paar hundert milliWatt verdonnern kann, waehrend eine high end desktop GPU heute auf die 244W reicht.

Heutige tablet bzw. smart-phone GPUs haben in der breiten Mehrzahl lediglich 2 TMUs. Fuer anstaendigeres AF z.B. brauchen wir eher 4 TMU Designs, ausser die Spiel-entwickler wuerden die ALUs so radikal vollstopfen (*edit: anders so viele shader Instruktionen dass die TMUs cycli genug uebrig haben um keine Daumen zu drehen) dass man trilineares AF sogar fast umsonst bekommt.

[LovesuckZ]

Ganz frisch aus der Analysten-Konferenz:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=39065&stc=1&d=1299607823

[Coda]

Da wäre jetzt halt die Größe und der Herstellungsprozess interessant, sonst kann das alles und nichts bedeuten.

[hell_bird]

gibt es da noch weiterer folien?

[LovesuckZ]

gibt es da noch weiterer folien?

Eventuell im laufenden Tag.

[Ailuros]

Da wäre jetzt halt die Größe und der Herstellungsprozess interessant, sonst kann das alles und nichts bedeuten.

http://www.brightsideofnews.com/news/2011/3/8/nvidia-project-denver-is-a-64-bit-arm-processor-architecture.aspx

Theo macht zugegeben mehr Fehler als es jemand gern haben koennte, aber seine irgendwo mit Maxwell Spekulation duerfte schon getroffen sein. Keine Ahnung ueber die Groesse aber die Geruechtekueche spricht von 20HP@TSMC und das ist tatsaechlich Maxwell timeframe.

[Gauß]

Ganz frisch aus der Analysten-Konferenz:
http://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=39065&stc=1&d=1299607823Auch wenn es nicht viele Pixel sind - alles was zu sehen ist deutet darauf hin dass das Foto in keiner Weise zum Bauplan passt.

Sollte zumindest der Bauplan stimmen, würden die relativ großen L1-Puffer die äußerst naheliegende Vermutung bestätigen dass nicht mal versucht wird bei der superskalaren Leistung mit X86-64, POWER, z/Architecture, SPARC, IA64 usw. direkt zu konkurrieren.

Projekt Denver wird definitiv einzigst auf höchstparallele Aufgaben ausgelegt werden, wobei die Datenanbindung and die GPU das einzige valide Verkaufsargument für Nvidia sein wird.

[Trap]

Sollte zumindest der Bauplan stimmen, würden die relativ großen L1-Puffer[...]
Die großen L1-Puffer sind mir auch aufgefallen. Hab es mal nachgemessen, das sind ~15% der Fläche für L1D-Cache, beim K10 sind es nur ~10%, beim Bulldozer sind es ~5%.

Die Frage ist da ob der L1D-Cache größer als üblich, oder der Rest kleiner als üblich ist.

[Ailuros]

Auch wenn es nicht viele Pixel sind - alles was zu sehen ist deutet darauf hin dass das Foto in keiner Weise zum Bauplan passt.

Sollte zumindest der Bauplan stimmen, würden die relativ großen L1-Puffer die äußerst naheliegende Vermutung bestätigen dass nicht mal versucht wird bei der superskalaren Leistung mit X86-64, POWER, z/Architecture, SPARC, IA64 usw. direkt zu konkurrieren.

Projekt Denver wird definitiv einzigst auf höchstparallele Aufgaben ausgelegt werden, wobei die Datenanbindung and die GPU das einzige valide Verkaufsargument für Nvidia sein wird.

Klingt danach als ob Du den Nagel auf den Kopf getroffen hast. Jensen sprach selber nur ueber Energie-Effizienz uebrigens.

[Gipsel]

Auch wenn es nicht viele Pixel sind - alles was zu sehen ist deutet darauf hin dass das Foto in keiner Weise zum Bauplan passt.
Mal ein paar Quotes aus dem B3D-Forum dazu (http://forum.beyond3d.com/showthread.php?p=1533217#post1533217):
Is it just me, or does the silicon underneath that overlay look a lot like a zoomed-in mismash of a GF100 die shot?

The silicon doesn't seem to match the description for things like the L1.
yes the areas feel labelled at random, and now I can see the symetrical features that cry "nvidia SP".
the colored rectangles are totally non-sensical.

this is an utterly stupid picture
Yes, the presented die shot is a patchwork from the official GF100 die photo... meh!
It's not even a "patchwork", it's a crop-resize-job from Fermi:

http://img98.imageshack.us/img98/1112/youhavebeentrolled.jpg

Just splash some random coloured rectangles over it, add some boundaries of functional parts... :)
Das hat ja fast schon wieder Holzschraubenniveau. :|

Ich würde also aus dem veröffentlichem Photoshop-Bild erst mal gar keine Rückschlüsse ziehen. Deine Vermutung, sich zuerst auf eine Nische im HPC-Markt zu konzentrieren ist aber trotzdem plausibel. Das Thema hatten wir ja schon mal im Januar angeschnitten.

[Dural]

also ich gehe auch davon aus das es noch KEIN silizium von Denver gibt... eigentlich auch logisch da NV von frühestens 2013 (Maxwell) spricht :wink: auch wenn man es hätte zeigt man sicher nicht einen echten realen die shot von seinem CPU teil der erst 2013 kommen soll, welche firma wäre den so dumm?!


hat NV den irgend wo überhaupt gesagt das sie schon test muster davon haben?!? ich denke eher nicht!

[Ailuros]

also ich gehe auch davon aus das es noch KEIN silizium von Denver gibt... eigentlich auch logisch da NV von frühestens 2013 (Maxwell) spricht :wink: auch wenn man es hätte zeigt man sicher nicht einen echten realen die shot von seinem CPU teil der erst 2013 kommen soll, welche firma wäre den so dumm?!

Es gibt dumme Firmen die gar nichts vorzeigen bis etwas reales existiert und es gibt vollidiotische Firmen wie NVIDIA die glauben dass die Presse so bloed ist es nicht zu identifizieren. Wenn man noch nichts hat zeigt man auch nichts vor.

hat NV den irgend wo überhaupt gesagt das sie schon test muster davon haben?!? ich denke eher nicht!

Ich denke dass die Investoren (die sowieso ziemlich unruhig sind in letzter Zeit) nicht so bloed sind wie Du und NVIDIA glauben moechtet.

[dildo4u]

Projekt Denver bringt 64 Bit Erweiterung für ARM

http://www.pcgameshardware.de/aid,815676/Projekt-Denver-bringt-64-Bit-Erweiterung-fuer-ARM/CPU/News/

[Gauß]

... ist ja wohl absolut selbstverständlich.

Wenn man bedenkt das bereits die 32-Bit ARM-Platform bei der Software extremst zurückhängt, kann man garnicht skeptisch genug sein wenn Nvidia in zwei oder mehr Jahren mit einer völlig neuen Platform selbst einen Nischen-Server-Markt erobern zu hofft.

Bis dahin gibt es heterogene Bulldozer² Server-APUs mit 32 (oder mehr) Kernen. Eine Vielzahl an Anwendungen werden da bereits nicht mehr mit der SMP-Logik skalieren, sodass die generell effizienzfressende und hochgradig schwierig zu entwickelnde superskalare Leistung sowie die Speicheranbindung wieder an Bedeutung gewinnen wird und daher keine signifikanten Vorteile der ARM-Architektur, selbst x86-64 gegenüber, mehr möglich sein werden.

Also ich habe meine Nvidia-Aktien bereits letztes Jahr verkauft.

[stickedy]

Wobei aber ARM selbst erst kürzlich bekannt gegeben hat, dass sie in den nächsten Jahren keine 64-Bit-Erweiterungen planen bzw. entwickeln werden.

Das hört sich also erstmal so an, als würde nVidia da etwas eigenes kreieren, was dann das ganze dann im 64-Bit-Modus inkompatibel werden lassen würde.

[Coda]

Das hat ja fast schon wieder Holzschraubenniveau. :|
Hahaha, tatsächlich. Was für Schlawiner :D


Projekt Denver bringt 64 Bit Erweiterung für ARM

http://www.pcgameshardware.de/aid,815676/Projekt-Denver-bringt-64-Bit-Erweiterung-fuer-ARM/CPU/News/
Hab ich doch gesagt :tongue:

Ein Schlüsselelement für die dort anfallenden wissenschaftlichen Berechnungen ist 64-Bit-Genauigkeit. Da der verwendete ARM-Befehlssatz nur als 32 Bit Version existiert, wurde bislang darüber spekuliert, ob Denver die ARM-Einheiten für Verwaltungsaufgaben einsetzt und die eigentlichen Berechnungen in CUDA-kompatiblen Kernen auf Basis eines Fermi-Nachfolgers durchführt.
Oh die SCHMERZEN :facepalm:

64-Bit hat doch nichts mit der Rechengenauigkeit zu tun. Natürlich können ARMs mit FPUs schon lange Double Precision Floating Point verarbeiten.

Und der CUDA-Quatsch ist noch haarsträubender.

Wobei aber ARM selbst erst kürzlich bekannt gegeben hat, dass sie in den nächsten Jahren keine 64-Bit-Erweiterungen planen bzw. entwickeln werden.

Das hört sich also erstmal so an, als würde nVidia da etwas eigenes kreieren, was dann das ganze dann im 64-Bit-Modus inkompatibel werden lassen würde.
Eher unwahrscheinlich. Sie dürften sich da mit ARM schon über die 64-Bit-ISA geeinigt haben. Sowas kann man sehr gut ohne Silizium festlegen.

[stickedy]

Eher unwahrscheinlich. Sie dürften sich da mit ARM schon über die 64-Bit-ISA geeinigt haben. Sowas kann man sehr gut ohne Silizium festlegen.
Ja, natürlich, aber ARM hat ja dem in den nächsten Jahren eine Absage erteilt:

http://www.heise.de/newsticker/meldung/ARM-Chef-daempft-Spekulationen-ueber-Windows-Systeme-und-Server-1169698.html

bzw. http://www.networkworld.com/news/2011/011111-arm-ceo-pc-market-not.html

[Coda]

Ja, natürlich, aber ARM hat ja dem in den nächsten Jahren eine Absage erteilt
Sie haben Hardware eine Absage erteilt. Was im R&D passiert ist etwas völlig anderes.

Selbst wenn NVIDIA da einen Alleingang gewagt hat - was ich wie gesagt nicht glaube - ist die Chance sehr hoch, dass sie es wie Intel damals bei AMD64 adaptieren, weil die Software-Infrastruktur schon komplett darauf portiert wurde.

[AnarchX]

8-Core NV-ARM mit 256 CUDA-Cores?
http://www.brightsideofnews.com/news/2011/7/18/1st-silicon-with-nvidia-project-denver-is-an-8-core-arm2c-256-cuda-core-apu.aspx

[Mancko]

wenn auch ein wenig Off-Topic aber trotzdem interessant.

http://www.heise.de/newsticker/meldung/Marktforscher-sieht-2015-ein-Viertel-der-Notebooks-mit-ARM-Prozessoren-1281509.html

[Noebbie]

In Aussicht auf Windows 8 aber vollkommen logisch.

Wintel ist vorbei. Zieht euch Warm an. ;)

[HOT]

In Aussicht auf Windows 8 aber vollkommen logisch.

Wintel ist vorbei. Zieht euch Warm an. ;)
Pures Wunschdenken. Wenn sich NV hier genötigt fühlt wieder einen Sonderweg einzuschlagen und ARM 64Bit bis auf weiteres überhaupt nicht vorsieht, x64 aber langsam in Fahrt kommt, wirds nix mit der ARM-Konkurrenz im Desktop-Markt. Windows8 vereinigt nur Windows7 und Windows Phone.

[fondness]

wenn auch ein wenig Off-Topic aber trotzdem interessant.

http://www.heise.de/newsticker/meldung/Marktforscher-sieht-2015-ein-Viertel-der-Notebooks-mit-ARM-Prozessoren-1281509.html

Solche Hochrechnungen basierend auf heutigen Wachstumszahlen würde ich nicht all zu ernst nehmen. Im embedded-Markt hat ARM schlicht den Vorteil das es lange keine Konkurrenz gab und auch heute noch keine ernst zu nehmende gibt. Im Notebookmarkt hingegen muss man erst mal beweisen das man head-to-head gegen Intel/AMD ankommt, und selbst dann stellt sich die Frage warum man ARM verbauen sollte. Eine Win8-Unterstützung ändert nichts an der enormen Softwarebasis von x86.

[Avalox]

ARM 64Bit bis auf weiteres überhaupt nicht vorsieht, x64 aber langsam in Fahrt kommt..

Ich denke dieses ist erstmal nicht so das Argument, da es ja MS mit ihrem frischen ARM Windows ja offen steht die ARM Adresserweiterungen zu unterstützen. Ist ja eher ein Dilemma der Geschichte, dass dieses unter x86 32Bit Windows aus "Kompatibilitätsgründen" nicht für das Wald und Wiesen Windows freigeschaltet wurde.
Binärkompatibel sind die Windows x86 und ARM Windowsanwendungen eh nicht.

Etwas anderes ist am WArm viel weniger gesetzt als die Technik im groben, es ist das Windows als solches.
Natürlich hat die Arm Welt nicht auf Windows gewartet. Windows 8 ist der letzte Versuch von MS in der neuen Welt Fuß zu fassen, ob dieses nachhaltig gelingt ist eine ganz andere Frage.

Arm wird sicherlich immer weiter andere Bereichen bedienen, davon kann man sicherlich ausgehen. Aber ob dann ein Windows dabei ist, ist noch eine ganz andere Frage.

[Hugo78]

Natürlich hat die Arm Welt nicht auf Windows gewartet.

Das stimmt was den embedded Bereich angeht, aber letztlich bietet nur Windows die Möglichkeit in den (retail) PC Markt vorzudringen.
Man kann diese Vorstellung mögen oder auch nicht, aber Linux spielte nie eine Rolle für die breiten Masse der PC Käufer.
Für Nvidia, aber auch andere die Net-books/tops, Notebooks bedienen möchten, ist dieser Schritt von MS sicherlich ein Segen.

Windows 8 ist der letzte Versuch von MS in der neuen Welt Fuß zu fassen, ob dieses nachhaltig gelingt ist eine ganz andere Frage.

Microsoft bewegt sich entsprechend seiner Größe immer nur langsam, doch mit der schleichenden Übernahme (Unterwanderung) von Nokia und der Öffnung hinzu ARM mit Win8,
könnte aus der aktuellen "lame Duck" schon in wenigen Jahren der "Big Player" werden.
Es ist ja nicht so als ob sie nicht die finanzielen Mittel dafür hätten.
Was ihnen nur eventuell fehlt, ist Führungspersonal mit Visionen.

Ich hätte zb. gerne eine Win8 "Lite" Version.
Ein "basic" Win8 das nicht mehr als 1-2 GB belegt.

[Ailuros]

8-Core NV-ARM mit 256 CUDA-Cores?
http://www.brightsideofnews.com/news/2011/7/18/1st-silicon-with-nvidia-project-denver-is-an-8-core-arm2c-256-cuda-core-apu.aspx

Bevor ich erstmal so weit komme sollte mir jemand erstmal folgendes Raetsel loesen:

As always, take this rumors with a grain of salt.

Just a grain?....

The information we have at hand is that Project Denver CPU core is looking to be very much aligned with T40, i.e. "Tegra 4" i.e. Wayne. According to internal schedule, Wayne silicon is going to be taped out in the next couple of weeks, with developers getting their hands on prototype silicon in December 2011.Wayne silicon is consisted out of four ARM cores (NVIDIA is not disclosing the core type, teasing that it might be either A15 or PD) and up to 64 GPU cores.

1. Wayne ist afaik 28nm.
2. Projekt Denver ist erst ab 20HP afaik.
3. Wayne soll 10x schneller sein als Tegra2, ergo 2x Mal schneller als Tegra3.

http://www.anandtech.com/show/4181/nvidias-project-kalel-quadcore-a9s-coming-to-smartphonestablets-this-year

(siehe NV's roadmap)

Tegra3 hat 4*A9@1.5GHz und "12 cores" fuer die GPU bei hoeherer Frequenz. Wie zum Henker soll Wayne sprich Tegra4 nur 2x Mal schneller sein als das vorige mit 64 GPU cores? Unter 28nm gibt es keinen Grund eine GPU Frequenz unter 400MHz zu benutzen und 64/12 gleicht 5x Mal so viel GPU Leistung, ergo 3x Mal mehr als der SoC insgesamt schneller sein soll als T3. Ich frag lieber nicht was ich verpasse.

256 Cuda cores in Logan wuerden Sinn machen im Vergleich zu Tegra3. Erstens weil es tatsaechlich der Zeitpunkt sein koennte wo sie zu USC ALUs umschwingen, zweitens sagt mir eine solche sterile Anzahl gar nichts wenn es sich z.B. nur um DX10 ALUs handelt. In dem Fall ist es kein logischer Vergleich zu AMD's Fusion Loesungen.

[AnarchX]

http://img854.imageshack.us/img854/8323/002xd.jpg (http://imageshack.us/photo/my-images/854/002xd.jpg/)

http://www.4gamer.net/games/126/G012690/20110722062/screenshot.html?num=002

[Gipsel]

Gibt von Charlie so eine halbgare Serie von 3 Artikeln zu Tegra und Denver:
A look at Tegra 3, 3.3 and 4 (http://semiaccurate.com/2011/08/04/a-look-at-tegra-3-3-3-and-4/)
What is Project Denver based on? (http://semiaccurate.com/2011/08/05/what-is-project-denver-based-on/)
Project Denver is more than a T50 core (http://semiaccurate.com/2011/08/05/project-denver-is-more-than-a-t50-core/)

Während ich das x86-CodeMorphing-Zeug im Prinzip noch glauben könnte, was soll der Kram bei den jetzt geplanten ARM-Cores? Okay, man kann jetzt sagen, man macht es halt genau so wie heutige x86er: setzt einen Decoder davor, der die nativen Instructionen in die internen übersetzt, so daß man den eigentlichen Kern von der ISA abkoppelt (nv hat die passende Lizenz dafür), aber warum zur Hölle soll das in Software passieren?

[LovesuckZ]

Weil Scharlie es so will. Ich verstehe, wieso man darüber auch nur eine Sekunde seiner geistigen Kapazität verschwendet. Er bezeichnet Project Denver auch als T50. Was vollkommen falsch ist. Denver hat überhaupt nichts mit der Tegra Schiene zu tun.

[Coda]

aber warum zur Hölle soll das in Software passieren?
Man spart sich die x86-Lizenz.

[Gipsel]

Man spart sich die x86-Lizenz.
Wird doch jetzt sowieso nicht x86. Der Grund fällt ja gerade weg.

[Coda]

Ach Scharlie meinte sie müssen ARM code morphen? :ugly:

Hm nö, klingt so als meine er, sie gehen den Transmeta-Weg.

[mboeller]

Während ich das x86-CodeMorphing-Zeug im Prinzip noch glauben könnte, was soll der Kram bei den jetzt geplanten ARM-Cores?

Ach so, du meinst also, das Nvidia ihren vorhandenen, fast fertig entwickelten 64bit, Code-Morphing Denver-Core wegschmeißt und mit ARM-cores, die es noch gar nicht gibt (A15 ist kein 64bit Design) noch mal von vorne anfängt....Tja dann wird das mit 2012 oder 2013 aber nichts mehr werden. :freak: ;)

[LovesuckZ]

Ach so, du meinst also, das Nvidia ihren vorhandenen, fast fertig entwickelten 64bit, Code-Morphing Denver-Core wegschmeißt und mit ARM-cores, die es noch gar nicht gibt (A15 ist kein 64bit Design) noch mal von vorne anfängt....Tja dann wird das mit 2012 oder 2013 aber nichts mehr werden. :freak: ;)

Ich glaube, da ist ein Fehler:
Sie werfen den 1. selbstentwickelten Core weg, um dann einen 2. selbstentwickelten Core auf ARM-Selbstbaubasis (ergo kein A15) zu entwickeln, der das selbe macht wie Core #1.

[Captain Future]

Er erzählt dauernd was von Denver und Kepler??? War denn Denver nicht von vornherein als Maxwell-Teil geplant als NVidia es eräwhnte?

[AnarchX]

Maxwell: https://www.forum-3dcenter.org/vbulletin/showthread.php?p=8847287#post8847287

[Mancko]

Der Typ hat einfach nicht alle Tassen im Schrank. Vor allem wie er sich immer über das Management bei Nvidia auslässt.
Bloß gut für ihn und seine Webseite dass AMD ja so ein Glanzbeispiel von tollem Management ist...

[Ailuros]

Der Typ hat einfach nicht alle Tassen im Schrank. Vor allem wie er sich immer über das Management bei Nvidia auslässt.
Bloß gut für ihn und seine Webseite dass AMD ja so ein Glanzbeispiel von tollem Management ist...

Ich hab's schon im Tegra thread erwaehnt, dass seine letzten paar Tegra/Denver Artikel zwar durchaus Bloedsinn sind aber beim obrigen hat er leider nicht unrecht.

NV hat selbstverstaendlich unter den besten engineers in der Branche; wenn etwas verspaetet wird oder wenn es irgendwo hapert dann reflektiert es eben sehr vieles negatives auf die engineers die sich aber die Finger blutig schuften. Wenn dann das eigentliche Problem falsche Entscheidungen vom Management sind dann ist es fuer jeglichen hart arbeitenden engineer eben nicht schoen.

Aber wenn Du es schon parallelisieren willst: AMD hat mehrere kleine dedizierte Entwicklungs-teams waehrend NV im Grund (ja es grenzt an die Uebertreibung aber sonst kann man es nicht verstehen...) nur ein sehr grosses. Oder besser Aufgaben sind nicht so klar aufgeteilt wie bei AMD's GDP. So etwas ist erstmal ein Management-Problem und kann unter Umstaenden verdammt kontra-produktiv sein, ueberhaupt wenn virtuelle Abteilung A und B sich nicht ueber X einig werden koennen.

Klingt zwar verdammt merkwuerdig und es ist auch sehr schwer zu illustrieren ohne handfeste Beispiele, aber mehr als das obrige will ich nicht posten. IMHO wissen engineers genau wo es langgeht sowohl was hw als auch was sw betrifft. Es sollten diese eher die Entscheidungen fuer die Zukunft treffen und nicht irgendwelche PR/Management Herren die zu ihren Grossteil mehr als oefters nur die Basis von Grafik verstehen.

[Coda]

Was mich bei der Code-Morphing-Geschichte wundert: Würden sie damit nicht auch die x86-Lizenz umgehen? Ich glaube das es selbst in der USA nicht möglich ist einen Befehlssatz zu patentieren.

Falls das so tatsächlich so ist, warum dann ARM?

[Captain Future]

Weil Windows8 für ARM kommt. Damit überlassen sie Microsoft die Lizenzangelegenheiten, wenn in den ARM-Versionen tatsächlich x86-Software per Emulation laufen wird.

[Coda]

Möglich, aber ich bin auch da skeptisch. Das OS hat eigentlich auch bei so einem Verfahren keinen Zugriff auf den nativen Befehlssatz.

[Ailuros]

Was mich bei der Code-Morphing-Geschichte wundert: Würden sie damit nicht auch die x86-Lizenz umgehen? Ich glaube das es selbst in der USA nicht möglich ist einen Befehlssatz zu patentieren.

Falls das so tatsächlich so ist, warum dann ARM?

Code-morphing Geschichte von Charlie? Wenn ja ---> Abfalleimer.

[LovesuckZ]

Ich hab's schon im Tegra thread erwaehnt, dass seine letzten paar Tegra/Denver Artikel zwar durchaus Bloedsinn sind aber beim obrigen hat er leider nicht unrecht.

NV hat selbstverstaendlich unter den besten engineers in der Branche; wenn etwas verspaetet wird oder wenn es irgendwo hapert dann reflektiert es eben sehr vieles negatives auf die engineers die sich aber die Finger blutig schuften. Wenn dann das eigentliche Problem falsche Entscheidungen vom Management sind dann ist es fuer jeglichen hart arbeitenden engineer eben nicht schoen.

Aber wenn Du es schon parallelisieren willst: AMD hat mehrere kleine dedizierte Entwicklungs-teams waehrend NV im Grund (ja es grenzt an die Uebertreibung aber sonst kann man es nicht verstehen...) nur ein sehr grosses. Oder besser Aufgaben sind nicht so klar aufgeteilt wie bei AMD's GDP. So etwas ist erstmal ein Management-Problem und kann unter Umstaenden verdammt kontra-produktiv sein, ueberhaupt wenn virtuelle Abteilung A und B sich nicht ueber X einig werden koennen.

Klingt zwar verdammt merkwuerdig und es ist auch sehr schwer zu illustrieren ohne handfeste Beispiele, aber mehr als das obrige will ich nicht posten. IMHO wissen engineers genau wo es langgeht sowohl was hw als auch was sw betrifft. Es sollten diese eher die Entscheidungen fuer die Zukunft treffen und nicht irgendwelche PR/Management Herren die zu ihren Grossteil mehr als oefters nur die Basis von Grafik verstehen.

Im vergleich zu AMD ist das Management von nVidia doch God-Like. Ich habe keine Ahnung, wie man den Leuten, die es schaffen eine 15% Umsatzrendite zu erwirtschaften, Unfähigkeit vorwerfen könnte.

Aber darauf wollte ich eigentlich nicht hinaus, denn dies ist viel interessanter:

Danke, damit bestätigt sich auch das was ich schon mehrmals gesagt habe, aber mir so manche NV-Fans nicht glauben wollte:

Die x86 Lizenz ist nicht das Problem. Es ist nur einfach völlig unrealistisch anzunehmen, dass NV aus dem nichts eine CPU stampft, die mit Intel oder AMD konkurrieren könnte.

AMD hat eindrucksvoll bewiesen, dass heutzutage keiner mehr mit Intel im x86-Desktop mithalten kann. Die einzige Chance gegen Intel zu bestehen, ist dort in den Markt einzutreten, wo Intel Probleme hat oder aber durch ein entsprechendes Design Vorteile zu erlangen.
Jedenfalls ist der Schritt zu ARM von nVidia ein Zeichen, dass die Intel und Windows Kruste endlich aufgebrochen wird. Dabei geht es nichtmal nur um Leistung, sondern auch endlich um leistungsfähigere ARM-Designs, die Konkurrenz und dadurch niedrige Preise und mehr Innovationen bringen.

[Ailuros]

Im vergleich zu AMD ist das Management von nVidia doch God-Like. Ich habe keine Ahnung, wie man den Leuten, die es schaffen eine 15% Umsatzrendite zu erwirtschaften, Unfähigkeit vorwerfen könnte.

Aber darauf wollte ich eigentlich nicht hinaus, denn dies ist viel interessanter:

Project Denver hat sich intern verspaetet aber es wird so oder so keiner merken; um das ging es mir eigentlich. Es wurden ziemlich Resourcen in GF110, 28nm testruns, Kepler und was noch geschuettet; in der Zwischenzeit sollten die engineers wieder zurueck zu ihren eigentlichen Projekten sein, aber ich bin mir nicht so sicher ob die Projektionen eingehalten werden koennen.

Wie dem auch sei es ging mir hauptsaechlich ueber die GDP bei AMD, denn diese hat kein so brutales Problem wie das eigentliche CPU Kerngeschaeft. Dass AMD's Management in letzter Zeit wohl irgendwo den Ball verloren hat und es fast so aussieht dass sie nicht mehr wissen wo es langgeht brauch ich nicht bestaetigen. Die Frage ist hier eher wie sie ihre interne Krise bewaeltigen wollen; wenn ich den Thesen die im Hintergrund herumschwirren glauben schenken sollte, dann koennte es verdammt duester fuer AMD's Zukunft aussehen.


AMD hat eindrucksvoll bewiesen, dass heutzutage keiner mehr mit Intel im x86-Desktop mithalten kann. Die einzige Chance gegen Intel zu bestehen, ist dort in den Markt einzutreten, wo Intel Probleme hat oder aber durch ein entsprechendes Design Vorteile zu erlangen.
Jedenfalls ist der Schritt zu ARM von nVidia ein Zeichen, dass die Intel und Windows Kruste endlich aufgebrochen wird. Dabei geht es nichtmal nur um Leistung, sondern auch endlich um leistungsfähigere ARM-Designs, die Konkurrenz und dadurch niedrige Preise und mehr Innovationen bringen.

Ich bin mir aber trotz allem immer noch nicht ueberzeugt dass ARM CPU IP so weit gebracht werden kann selbst mit custom designs um irgend einen Vorteil zu haben im higher end. Hypothetisch gerade noch konkurrenzfaehig bei eventuell angepassten Preisen ist zwar schoen und gut ist aber nichtdestominder nicht mehr versprechend als das was AMD in letzter Zeit mit ihren CPUs auftischt.

Intel ist in letzter Zeit nicht nur noch aggressiver geworden was CPUs betrifft, sondern hat auch wie NV selber oeffentlich erwaehnte selbst im GPU Bereich zugelegt (obwohl das Zitat zugegeben sich hauptsaechlich auf benchmarks konzentrierte. Anders Intel wird nicht so leicht die weisse Fahne wedeln im low end desktop/notebook Bereich.

[LovesuckZ]

ARM ist für jeden lizenzierbar und "überall" fertigbar. Im Gegensatz zu x86 steigt so die Innovationsrate massiv. Intel hat doch jetzt überhaupt keine Konkurrenz mehr, weil der einzige Konkurrent weder design- noch fertigungstechnisch mithalten kann.

Und wie man im mobilen Bereich sehen kann, führt die freie Lizenzierbarkeit von ARM zu deutlich schnelleren Entwicklungen.

[Ailuros]

ARM ist für jeden lizenzierbar und "überall" fertigbar. Im Gegensatz zu x86 steigt so die Innovationsrate massiv. Intel hat doch jetzt überhaupt keine Konkurrenz mehr, weil der einzige Konkurrent weder design- noch fertigungstechnisch mithalten kann.

Und wie man im mobilen Bereich sehen kann, führt die freie Lizenzierbarkeit von ARM zu deutlich schnelleren Entwicklungen.

Kein Zweifel; ich will aber zuerst eine handangepasste (und nicht "standard IP") higher end ARM CPU sehen.

Intel braucht mehr Knie denn im embedded Bereich haben sie sich bis jetzt ziemlich alles selber abgeschossen; mir geht es hauptsaechlich um desktop/notebook SoCs. Ein solche ARM basierender SoC mit etwas schaecheren CPUs wie Intel's und etwas potentieller Grafik sieht mir momentan nicht nach etwas aus dass ohnehin schon AMD hat.

Wuerdest Du mir sagen dass Intel Konkurrenz braucht mit gesunderem insgesamt Management wie AMD unterschreibe ich es Dir sofort. Ich versuche in letzter Zeit herauszufinden was genau bei denen in letzter Zeit los ist denn irgend etwas stimmt wirklich nicht. Bulldozer eines der groessten Probleme.

Und nein dieses widerspricht nicht meinen vorigen Posts hier; Project Denver haette zeitig in praesentablem Zustand sein sollen um den PS4 Deal zu gewinnen.

[Hugo]

Projekt Denver soll doch eine 64bit Erweiterung haben.
Wird die kompatibel zur armv8 sein?
http://www.computerbase.de/news/2011-10/erste-informationen-zur-neuen-armv8-architektur/

[Ailuros]

Projekt Denver soll doch eine 64bit Erweiterung haben.
Wird die kompatibel zur armv8 sein?
http://www.computerbase.de/news/2011-10/erste-informationen-zur-neuen-armv8-architektur/

Prozessoren auf Basis von ARMv8 sollen im Laufe des nächsten Jahres enthüllt werden, Prototypensysteme für den Konsumenten- und Unternehmensmarkt erwartet ARM für 2014.

NV erwartet Denver ab 2012 (obwohl man es eher fuer 2013 erwarten sollte aber das ist nebensaechlich). ARMv8 wird auf jeden Fall nicht vor 2015 in komerziellen Geraeten erscheinen.

[Hugo]

die Frage für mich is eben ist NVs 64bit Erweiterung kompatibel?
nicht dass man dann 2 inkompatible Lösungen hat?
auf was basiert Denver eigentlich?

[Ailuros]

die Frage für mich is eben ist NVs 64bit Erweiterung kompatibel?
nicht dass man dann 2 inkompatible Lösungen hat?
auf was basiert Denver eigentlich?

Tja das ist eine interne Sorge bei NV und koennte auch der eigentliche Grund sein warum Denver nicht seine projezierte Launch-daten einhalten koennte. Da aber TSMC wohl wieder optimistisch mit ihren 20HP Projektionen war/ist bezweifle ich dass es jemand bemerken wuerde.

http://investor.appliedmicro.com/phoenix.zhtml?c=78121&p=RssLanding&cat=news&id=1622781

http://www.anandtech.com/show/5027/appliedmicro-announces-xgene-arm-based-socs-for-cloud-computing

AppliedMicro behauptet sampling in H2 2012, ergo waere es nicht unmoeglich dass NV zu dem Zeitpunkt oder leicht spaeter mit Denver zum sampling kommen koennte. ARMv8 zu benutzen waere eben IMHO die logischere Loesung als eine eigene A15 Variante mit 64bit zu entwickeln.

[Hugo]

eben denk ich auch. nicht dass wir sowas wieder erleben wie zw AMD und Intel bei ihrer 64Bit erweiterung
ich bin echt gespannt auf Denver. Wenn er auf Armv8 basiert is es doch eigentlich keine Eigentwicklung oder?

[LovesuckZ]

Natürlich. Man will kompartibel bleiben, aber eine High-Performance-Architektur entwickeln. Qualcomm's Snapdragons sind auch kompartibel.

[Hugo]

klar will man kompatibel bleiben, aber ist man das auch?
die frage ist ob zusammen an ARMv8 gewerkelt wurde oder NV selbst die 64Bit Erweiterung sich ausgedacht hat

[LovesuckZ]

klar will man kompatibel bleiben, aber ist man das auch?
die frage ist ob zusammen an ARMv8 gewerkelt wurde oder NV selbst die 64Bit Erweiterung sich ausgedacht hat

Siehe die Pressmitteilung:

Known under the internal codename "Project Denver," this initiative features an NVIDIA® CPU running the ARM instruction set, which will be fully integrated on the same chip as the NVIDIA GPU.

This new processor stems from a strategic partnership, also announced today, in which NVIDIA has obtained rights to develop its own high performance CPU cores based on ARM's future processor architecture.
http://pressroom.nvidia.com/easyir/customrel.do?easyirid=A0D622CE9F579F09&version=live&releasejsp=release_157&xhtml=true&prid=705184

[Hugo]

ok thx

[Man From Atlantis]

NVIDIAs Dan Vivoli
The combination of Nvidia's leadership in energy-efficient, high-performance processing and the new ARMv8 architecture will enable game-shifting breakthroughs in devices across the full range of computing - from smartphones through to supercomputers.

http://www.techpowerup.com/154357/ARM-Going-64-Bit-To-Compete-In-High-End-Desktop-Market.html

[LovesuckZ]

Huang über die Design Ziele von Denver:
64bit und Single-Thread-Leistung.


Project Denver, our focus there is to supplement, add to arms capabilities by extending the arms architecture to segments in a marketplace that they're not, themselves, focused on. And there are some segments in the marketplace where single-threaded performance is still very important and 64 bit is vital. And so we dedicated ourselves to create a new architecture that extends the ARM instruction set, which is inherently very energy-efficient already, and extend it to high-performance segments that we need for our company to grow our market. And we're busily working on Denver. It is on track. And our expectation is that we'll talk about it more, hopefully, towards the end of next year. And until then, until then I'm excited, as you are.
http://seekingalpha.com/article/307194-nvidia-s-ceo-discusses-q3-2012-results-earnings-call-transcript?part=qanda

[Nighthawk13]

www.heise.de/newsticker/meldung/Prozessortandems-von-ARM-1426462.html (http://www.heise.de/newsticker/meldung/Prozessortandems-von-ARM-1426462.html):
Nvidia bemüht sich bisher, die Details des eigenen CPU-Projektes mit Codenamen Denver unter Verschluss zu halten, doch nun enthüllt eine Folie aus der ARM-Präsentation, dass Denver die kommende 64-Bit-Architektur ARMv8-A nutzen wird. Außerdem sollen Denver-Chips in PCs, Servern und Supercomputern zum Einsatz kommen. Aus der Folie geht zudem hervor, dass die Firma Applied Mico X-Gene an einem Server-Prozessor mit vielen Kernen, 3 GHz Taktfrequenz und ARMv8-A arbeitet. Als möglicher Termin für ARMv8-A-Chips nennt ARM das Jahr 2014.
Also keine eigener NVarm64 Befehlssatz, gut so. 2014 passt zum angepeilten Maxwell Launch.
Wenns ein Server-Manycore mit 3Ghz gibt wird auch Nvidia in der Grössenordnung unterwegs sein.

[Ailuros]

www.heise.de/newsticker/meldung/Prozessortandems-von-ARM-1426462.html (http://www.heise.de/newsticker/meldung/Prozessortandems-von-ARM-1426462.html):

Also keine eigener NVarm64 Befehlssatz, gut so. 2014 passt zum angepeilten Maxwell Launch.
Wenns ein Server-Manycore mit 3Ghz gibt wird auch Nvidia in der Grössenordnung unterwegs sein.

20HP ist noch viel zu weit entfernt dass eine 3GHz Frequenz irgendwie gesichert ist momentan; als Design-Ziel und als "up to" kann ich es durchaus schlucken.

Also so eindeutig klingt mir der obrige Paragraph nun auch wieder nicht; ein ARM Partner kann entweder fertiges CPU IP von ARM lizenzieren oder lediglich das instruction set von spezifischem CPU IP und darauf basierend eine eigen angepasste Architektur entwickeln ala Snapdragon bzw. Krait/Qualcomm. Das zweite ist natuerlich insgesamt teurer.

[steve.it]

Also keine eigener NVarm64 Befehlssatz, gut so.

Nvidia dürfte überwiegen ASIC-Designer haben. Daher würde ich obiges auch nicht von denen erwarten.

[Ailuros]

http://www.xbitlabs.com/news/cpu/display/20120921010327_Nvidia_Develops_High_Performance_ARM_Based_Boulder_Microprocessor _Report.html

Nvidia Corp. is reportedly working on an ultra high-performance system-on-chip based on ARM architecture, which would challenge AMD Opteron and Intel Xeon microprocessors in the server space. The chip is called project Boulder and it is designed by Nvidia's graphics processing unit team.

[Coda]

Das wird spannend. NVIDIA hat einfach auch keine andere Wahl mehr. Intel wird immer stärker auf dem GPU-Feld und AMD wird hoffentlich auch irgendwann wieder gescheite CPUs hinbekommen.

Zudem ermöglichen APUs ganz andere Algorithmen, mit viel geringeren Latenzen zwischen CPU und GPU. Ewig kommen sie mit nur GPUs nicht weiter.

[Ailuros]

Tatsaechlich hat NVIDIA keine andere Wahl mehr, trotz allem erscheint mir das Risiko und die Investition (auch project Denver mitberechnet) nicht gerade klein. Mal sehen was daraus wird.

[Coda]

Vor allem kommt es auch auf die Akzeptanz von ARM an. Microsoft hätte gut getan mit Windows 8 "fat binaries" wie Apple einzuführen (x86/x64 & ARM) in einer EXE.

[Hugo78]

Nvidia wird in Sachen Software und OS nicht auf andere warten/hoffen.
Die basteln sicher an einem passenden Linux für Großkunden.

[Coda]

Wozu? Jede beliebige Linux-Distribution unterstützt auch ARM.

Das Problem ist nicht das Betriebssystem, sondern die Applikationen, die darauf laufen sollen.

[Hugo]

also versteh ich das jetzt richtig "Project Denver" ist eher Tablet/Subnotbook und "Project Boulder" für Server? Oder kann man vom Denver mehr als nur Tablet/Subnotbook erwarten?
Technische Spekudaten gibts keine oder?

[Hugo78]

Wozu? Jede beliebige Linux-Distribution unterstützt auch ARM.

Das Problem ist nicht das Betriebssystem, sondern die Applikationen, die darauf laufen sollen.

Mir gehts halt um die vermeidlichen Änderungen am ARM Design, die NV vornehmen muss um gegen x86 Server CPUs anstinken zukönnen, grade in Sachen IPC.
Ich denk mir dafür braucht es sicherlich ein angepasstes Linux, dass über die allgemeine ARM unterstützung hinaus geht.

Die weitergehende Softwareunterstützung werden sie dann natürlich auch von sich aus pushen müssen, aber bei NV weiß man das Software die Hardware verkauft, nicht andersrum.

[Ailuros]

also versteh ich das jetzt richtig "Project Denver" ist eher Tablet/Subnotbook und "Project Boulder" für Server? Oder kann man vom Denver mehr als nur Tablet/Subnotbook erwarten?
Technische Spekudaten gibts keine oder?

Denver ist zumindest afaik nicht nur auf small form factor begrenzt.

Aus dem obrigen xbitlabs Link welches auch nicht zum ersten Mal erwaehnt wird:

It is not a secret that Nvidia is already working on project Denver, an Nvidia high-performance central processing unit (CPU) running the ARM instruction set, which will be fully integrated on the same chip as an Nvidia graphics processing unit (GPU). The first implementation of project Denver is code-named Maxwell graphics processor.

Maxwell ist die GPU desktop high end Architektur die Kepler folgen wird, ergo hat dieses erstmal gar nichts mit Tegra und ULP GeForce zu tun. Technische details (zwar nicht viele und auf spekulativer Basis) gibt es einige im Link.

[AnarchX]

Wer sagt dass Maxwell nicht bis den SFF-Markt skaliert? Die 256SPs die man dem Denver-SoC nachgesagt hat, sind aus der nun aktuellen Non-Hotclock-Sicht ja auch nicht so besonders.

[Coda]

Mir gehts halt um die vermeidlichen Änderungen am ARM Design, die NV vornehmen muss um gegen x86 Server CPUs anstinken zukönnen, grade in Sachen IPC.
Ich denk mir dafür braucht es sicherlich ein angepasstes Linux, dass über die allgemeine ARM unterstützung hinaus geht.
Braucht es nicht.

Und wenn (für NUMA etc.) dann kommen die Änderungen in den Kernel-Tree und werden sowieso von allen übernommen.

[Ailuros]

Wer sagt dass Maxwell nicht bis den SFF-Markt skaliert? Die 256SPs die man dem Denver-SoC nachgesagt hat, sind aus der nun aktuellen Non-Hotclock-Sicht ja auch nicht so besonders.

Wie oft muss man denn noch erklaeren dass high end desktop und SFF so brutal verschiedene Welten sind was primaer den Stromverbrauch betrifft? Wenn man eine SFF GPU in einstellige Watt Grenzen bzw. ein paar mm2 quetschen muss, gibt es keinen anderen Ausweg als diverses Zeug eben fuer perf/mW und perf/mm2 zu opfern.

Es soll nicht heissen dass NV mit Kepler, Maxwell und co nicht Erfahrungen sammeln kann fuer SFF Architekturen, aber es sollte dann schon heissen dass es sich eben fuer die letzteren um speziell angepasste Architekturen handelt fuer SFF eben um gewisse perf/mW-perf/mm2 Werte zu garantieren.

Bis jetzt heisst der GPU block in Tegras Ultra Low Power GeForce aus gutem Grund und die bisherigen Bloecke sind eben nicht direkt mit keiner der desktop GPU Architekturen verwandt sondern eher eine kluge Mischung aus dem was man empfand das wirklich notwendig ist und dem was unter jeglichen Vorraussetzungen moeglich war. Bis jetzt wurde sogar komplett auf tiling relevante Logik verzichtet (welches auch der Grund ist warum kein Multisampling auf den Dingern moeglich ist, eben weil es ohne memory tiling unendlich viel Bandbreite fressen wuerde) und man stattdessen Bandbreite spart mit early Z, ziemlich grossen caches und nur coverage sampling AA.

Da kannst Du lange versuchen mich zu ueberreden dass Wayne oder jeglicher Nachfolger eine 1:1 Kopie von Kepler oder Maxwell clusters haben wird. Tut mir leid aber ich glaube es erst wenn ich es sehe.

[AnarchX]

Mit der Minimierung des Stromvebrauchs der Cluster in den Desktop-GPUs werden diese wohl langfristig durchaus geeignent sein für SFF-Designs. Der große Unterschied ist dann eben die Skalierung, worin man viel Stromverbrauch bei den Desktop-GPUs investieren muss.

Wenn die 28nm SoC die 200 GFLOPs überschreiten, dann sind wohl ~400GFLOPs für einen 20nm SoC nicht so unrealistisch.

[Ailuros]

Mit der Minimierung des Stromvebrauchs der Cluster in den Desktop-GPUs werden diese wohl langfristig durchaus geeignent sein für SFF-Designs.

Nein. Das Problem wird Latenz sein und sobald man versucht hier etwas in Logik anzupassen hat man schon einen fuer SFF angepassten GPU Design.

Der große Unterschied ist dann eben die Skalierung, worin man viel Stromverbrauch bei den Desktop-GPUs investieren muss.

Naechster Generation SFF GPUs werden in ihrer Mehrzahl 1 TMU pro computing cluster haben mit Aussnahme von Rogue mit 2 TMUs/cluster. NV's zukuenftige SFF GPUs werden im besten Fall 2 TMUs/cluster haben IMHO, sonst investieren sie zu stark in die area fuer Texel-Fuellraten und opfern hingegen ALUs bzw. GFLOPs. Der Trend geht deutlich in Richtung arithmetic.

Wenn die 28nm SoC die 200 GFLOPs überschreiten, dann sind wohl ~400GFLOPs für einen 20nm SoC nicht so unrealistisch.

Woher kommt denn der Masstab von >200GFLOPs fuer 28nm SoCs genau? Es entgeht Dir wohl dass GPU IP Entwickler nicht daran gebunden sind sich wie ein SoC Hersteller auf maximal 2 SoC Varianten zu begrenzen und die Skalierung der Einheiten den jeweiligen Lizenznehmern frei steht im ersten Fall?

[Coda]

Du meinst 2 Quad-TMUs, oder?

[Ailuros]

Du meinst 2 Quad-TMUs, oder?

Nein. Jeder Adreno320/T6xx compute cluster hat 1 einzige TMU, waehrend Rogue 2 TMUs per compute cluster hat (obwohl es auch nicht zu 100% stimmt da sich beim letzte 2 CCs einen 2 TMU block eigentlich teilen.

Adreno320 besteht aus 4 compute clusters, ergo 4 TMUs insgesamt. Gleich bei ARM T604.

[Coda]

Zwei TMUs sind unwahrscheinlich, normalerweise hat man immer Quad-TMUs. Ansonsten müssen die zwei TMUs loopen.

Dann macht man vorher eher die SMs wieder größer um ein höhere ALU:TEX-Ratio zu erzeugen.

[Ailuros]

Zwei TMUs sind unwahrscheinlich, normalerweise hat man immer Quad-TMUs. Ansonsten müssen die zwei TMUs loopen.

Dann macht man vorher eher die SMs wieder größer um ein höhere ALU:TEX-Ratio zu erzeugen.

Es gibt keine quad TMUs in SFF GPUs. Das ALU:TMU ratio rangiert momentan zwischen 1:1, 2:1 oder 4:1 je nach Fall.

SGX535 = 2 Vec2, 2 TMUs
ULP GF/T3 = 2 Vec4, 2 TMUs
Adreno225 = 8 Vec4, 2 TMUs
Mali400MP4 = 4 Vec4, 4 TMUs
SGX543/544 = 4 Vec4, 2 TMUs
SGX554 = 8 Vec4, 2 TMUs
Adreno320 = 4 SIMD16, 4 TMUs
ARM Mali T604 = 4 SIMD16, 4 TMUs

[dildo4u]

Nvidia paart acht 64-Bit-ARM-Kerne mit Tesla K20

http://www.computerbase.de/2014-06/nvidia-paart-acht-64-bit-arm-kerne-mit-tesla-k20/

[Skysnake]

Das ist mal MEGA langweilig.

Die haben einfach nen ARM System mit PCI-E genommen und ihre Treiber fit für ARM gemacht, was Sie ja eh schon mussten wegen Tegra. Das wars dann auch schon :ugly:

EDIT:
Und die GPUs sind nur mit 8x PCI-E 3.0 angeschlossen.
Das System hat auch nur 128GB RAM pro CPU. Das ist nicht gerade sehr viel.

Und es gibt nur die beide 10GE SFP Anschlüsse als NIC. Nen richtigen LowLatency NIC kannste gar nicht dran hängen, weil man keine PCI-E Lanes mehr hat :ugly:

Ganz abgesehen davon, ist es auch nur ein SOC+1GPU pro System. In einem 1U Einschub stecken einfach nur zwei Systeme drin, die unterscheiden sich bzgl Kommunikation aber überhaupt nicht von zwei einzelnen Kisten.

Der Airflow ist auch nicht toll durch die quer stehenden RAM-DIMMs.

Also das sieht echt wie schnell mal zusammengehackt aus. Schön/elegant ist echt was anderes.

[deekey777]

Das ist mal MEGA langweilig.

Die haben einfach nen ARM System mit PCI-E genommen und ihre Treiber fit für ARM gemacht, was Sie ja eh schon mussten wegen Tegra. Das wars dann auch schon :ugly:
Der übliche Tegra-Beißreflex?

http://www.heise.de/newsticker/meldung/ISC-14-Nvidia-paart-Tesla-Karten-mit-64-Bit-ARM-SoCs-2236520.html

Der Journalist Agam Shah von PCWorld sieht in der Nvidia-Ankündigung sogar das Eingeständnis, dass Nvidia die eigenen Pläne für ein Server-SoC mit ARMv8-Technik aufgibt: Das seit 2011 stets etwas unscharf angekündigte Project Denver hat oder hatte das Ziel, einen proprietären ARM-Kern zu entwickeln; dafür hat Nvidia eine Architektur-Lizenz von ARM erworben

[Skysnake]

Was hat das mit "Beisreflex" zu tun?

Die mussten die Treiber einfach nur nicht von Grund auf Anpassen an ARM, weil Sie das schon seit Jahren gemacht haben. Sonst würde kein Tegra laufen. :rolleyes:

Damit reduziert sich der "Server" aber wohl nur noch auf zusammenstecken, und Optimierungen (falls überhaupt vorhanden/nötig) unter der Haube.

Das ist jetzt nichts wirklich berauschendes, wenn man bedenkt, was mal mit Denver alles versprochen wurde.

Der Heise Artikel bringt es auch ziemlich knall hart auf den Punkt, was mir dazu durch den Kopf ging. So harsch hätte ich es selbst aber nie formuliert.

[ndrs]

Stand in irgend einer Meldung welche ARMv8-Kerne (A57?) bzw. welche CPU zum Einsatz kommen. Ist das überhaupt ein eigenentwickelter Chip oder eingekauft?

[Dural]

Vorbereitung für ihren "Denver" (GPU+CPU) hätte ich jetzt mal gesagt. Finde ich logisch und auch sinnvoll.

[Timbaloo]

Vorbereitung für ihren "Denver" (GPU+CPU) hätte ich jetzt mal gesagt. Finde ich logisch und auch sinnvoll.
War auch mein erster Gedanke.

[hasebaer]

Ich finde es erstaunlich was Heise sich alles zusammen reimt. :biggrin:

[Skysnake]

Stand in irgend einer Meldung welche ARMv8-Kerne (A57?) bzw. welche CPU zum Einsatz kommen. Ist das überhaupt ein eigenentwickelter Chip oder eingekauft?
Das ist wohl alles aingekauft. nVidia stellt die GPU und den GPU-Treiber für ARM unter Linux.

Das wars dann aber wohl auch schon.

Vorbereitung für ihren "Denver" (GPU+CPU) hätte ich jetzt mal gesagt. Finde ich logisch und auch sinnvoll.
Was soll daran Vorbereitung für "Denver" sein? Jedweder Tegra ist näher an Denver dran als das Teil.

Die einzige Gemeinsamkeit zu Denver ist, das die CPU auf den ARM-Befehlssatz setzt. Das wars dann aber auch. Ansonsten gibt es keinen Unterschied zu einem x86 Systen, außer das halt das ARM-System deutlich schlechter performen wird was die Maximalleistung anbelangt.

[Mancko]

Ansonsten gibt es keinen Unterschied zu einem x86 Systen, außer das halt das ARM-System deutlich schlechter performen wird was die Maximalleistung anbelangt.

Bei deutlich geringerem Verbrauch. Ist doch vollkommen klar, dass x86 langfristig nicht mehr die einzige Alternative sein wird. Sämtliche Hersteller tun auch sehr gut daran hübsch mitzuwirken, dass sich ARM weiter verbreitet. Ich finds gut.

[mboeller]

Der übliche Tegra-Beißreflex?

http://www.heise.de/newsticker/meldung/ISC-14-Nvidia-paart-Tesla-Karten-mit-64-Bit-ARM-SoCs-2236520.html

Und was ist jetzt an dem von dir verlinkten Heise-Artikel besser? Meine Übersetzung von dem Artikel lautet schlicht und einfach: Denver = Game over. Nvidia streicht die Server-Segel. Das ist hart! Dagegen ist der Kommentar von Skysnake ja harmlos.

Was besonders seltsam ist, ist das die Denver-Cores ja in das Nexus9 kommen sollen. Es hätte also mehr Sinn gemacht jetzt einen Denver-Server anzukündigen (die SoC sollten ja schon vorhanden sein) anstelle eines A57-SoC Servers.

[Ailuros]

Und was ist jetzt an dem von dir verlinkten Heise-Artikel besser? Meine Übersetzung von dem Artikel lautet schlicht und einfach: Denver = Game over. Nvidia streicht die Server-Segel. Das ist hart! Dagegen ist der Kommentar von Skysnake ja harmlos.

Was besonders seltsam ist, ist das die Denver-Cores ja in das Nexus9 kommen sollen. Es hätte also mehr Sinn gemacht jetzt einen Denver-Server anzukündigen (die SoC sollten ja schon vorhanden sein) anstelle eines A57-SoC Servers.

Da Samsung wohl auch ihre Server SoCs Plaene begraben musste, haette NV nie und nimmer damit irgendwelche Chancen gehabt.

[Triskaine]

Was besonders seltsam ist, ist das die Denver-Cores ja in das Nexus9 kommen sollen. Es hätte also mehr Sinn gemacht jetzt einen Denver-Server anzukündigen (die SoC sollten ja schon vorhanden sein) anstelle eines A57-SoC Servers.

Die CPU in diesem Server ist von Applied Micro (X-Gene), die eine eigene ARMv8 Mikroarchitektur entwickelt haben (4-Wide OoO in 28nm). Denver sollte bei nVidia ja nur bei den GPUs mit auf den Chip drauf und ist nicht als eigenständiger Serverprozessor konzipiert.

Applied Micro ist wohl am frühesten dran mit ARMv8 Serverprozessoren (AMD hat Seattle, der kurz vor dem Release steht, kommt aber aus offensichtlichen Gründen für so eine Kooperation nicht in Frage)