News A350M und A370M: Intel Arc startet im Notebook, Desktop-GPUs ab Sommer

ghecko schrieb:
@Wolfgang was ich allerdings nicht verstehe:

Das ist doch dem Encoder völlig egal, wie viele Bilder das Material in einer Sekunde durchrattert, der arbeitet das ja linear ab. Oder meinen die damit so was wie "Live encoding", also in Echtzeit?
Jetzt nur als Spekulation, aber ich nehme auch einfach Mal an, daß hier AV1 Encode Echtzeit sein wird, also für Telekonferenz oder Livestream von Spielen oder YouTube Live Geschichten. Für derartige Anwendungen könnte AV1 deutlich Bandbreite reduzieren. Ansonsten stimme ich zu, für Off-Line wär das eher seltsam.
 
  • Gefällt mir
Reaktionen: ghecko und Jan
Wird neue Gpu. Ampere ist so langweilig zum tweaken. Rdna 2 meh. Bin gespannt wie Intel wird zum Oc/Uv.
 
Piktogramm schrieb:
Hast du dazu ne Quelle oder mehr Informationen?
Also, ich habe bis jetzt nur die News hier und auf anderen Seiten überflogen und Computerbase schreibt zum Beispiel:

"Darüber hinaus gibt es noch Informationen zu den Rechenkapazitäten der Xe-Cores. Dass diese 128 FP32-ALUs pro Takt berechnen können, ist bereits länger klar, Intel bestätigt nun aber auch separate 128 INT32-ALUs."

Das wären 128 FP32 + 128 INT32. Und wenn man nach den Folien geht:
6-2160.fc553bb1.png


Das ist in der Form dann durchaus vergleichbar damals mit Turing. So etwas ist gut für "Asynch"-Shader bei DX12, gleichzeitig liegt ein Teil der CPU damit brach.

NVIDIA hat ja nicht ohne Grund bei Ampere die 64-INT-Shader aus Turing zu FP32/INT32 umgemünzt, auch wenn sie aktuell die Shader nicht ausgelastet bekommen voll.

Es sieht ein wenig aus, als hätte Raja und sein Team ein wenig zu sehr bei NVIDIA geschaut. Wenn ich mir aktuell den Aufbau ansehe, dann ist auch die Frage, wie gut Intel wirklich mit ihrem Treiber arbeiten können, denn ich sehe auf sie ein ähnliches Problem zukommen, wie damals bei GCN.

AMD hat nicht umsonst im Treiber von Wave64 auf Wave32 umgestellt und die 4 * Vec16 zu 2 * Vec32 verändert. RDNA2 bietet nun nur noch Wave64 und Wave32.

NVIDIA arbeitet "intern" mit Vec4-Einheiten, steuert die aber über denselben Datenpfad an und hat den Datenpfad seit Kepler quasi konstant von 192 über 128 auf 64 verringert. (Ein Teil der tollen "Energieeffizient" ist darauf zurückzuführen, dass man kleinere Vektoren nutzt. Seit Turing gibt es einen zweiten Datenpfad mit noch mal 64-Werten, erst reserviert für INT, nun eben für beides.

Nimmt man es genau, dann hat Xe also nicht nur 128 Shader pro Xe-Core, sondern 256 und wenn der große Xe wirklich "nur" bei einer RTX 3060 landet, dann spricht das massiv für ein Auslastungsproblem. Intel kann das über den Treiber sicher fangen, aber die Frage ist dann, wie gut ist der Thread-Scheduler wirklich in den Xe-Cores und kann dieser mehrere Vec8 an einem größeren Vektor arbeiten lassen oder nicht (GCN-Problem).

NVIDIA arbeitet da ein Stück "anders" und da sind halt die Datenpfade wichtig: NVIDIA fasst in Cuda mehre Threads mit selben Operationen zusammen für die Datenpfade und haut die dann auf die beiden Datenpfade und dann rechnen die eben. Dadurch kann NVIDIA - auch bei Ampere - sehr gut die Vektoren skalieren pro Thread von 1 - 64 bei FP32/INT32 - wobei sie ein Minimum von 4 brauchen.

Bei Xe stelle ich mir halt die Frage, was passiert und ob sie wirklich am Ende die GCN-Problematik haben, dass man 4 unabhängigen Threads (bei Xe wären es bis zu 16) benötigt, damit man die ALUs auslastet, oder ob man einen Vektor auch auf mehre ALUs raus hauen kann.

Für mich - wenn ich jetzt AMD und NVIDIA zum Vergleich nehme - scheint Xe sogar relativ "komplex" zusein, auch was die Steuerlogik angeht. NVIDIA und AMD sind dagegen eigentlich sogar recht bemüht darum die Steuerlogik auf den GPUs möglichst gering zu halten.

Wenn man bis jetzt Intels GPUs heranzieht, dann waren diese - mit der Anzahl an Shader - nie wirklich gut ausgelastet und brachten recht wenig Leistung im Vergleich zur theoretischen Rechenleistung und Xe scheint an der Stelle nicht wirklich etwas gemacht zu haben.

Für mich sieht das ganze so aus, wie damals bei AMD als Raja kam: Er findet eine Architektur vor, statt aber deren Probleme wirklich zu beheben und auch mal grundlegend zu überarbeiten, bläht er alles nur auf und denkt mit mehr kommt auch mehr.
 
  • Gefällt mir
Reaktionen: Piktogramm, Onkel Föhn, Zarlak und 2 andere
Wie hier schon jemand so passend geschrieben hatte:

Raja das Trojanische Pferd.
Well played Lisa Su.
Mal eben hinterhältig den Raja bei Intel eingeschleust…. 😃
 
  • Gefällt mir
Reaktionen: Onkel Föhn
  • Gefällt mir
Reaktionen: konkretor und DevPandi
Volker schrieb:
Klar, irgend einen Einsatzfall wird man finden.

einzelfall vielleicht, aber mit enormer tragweite. h265 10bit 422 ist einer der standardcodecs für aktuelle videokameras. damit meine ich nicht nur smartphones, bridge und mirrorlesskameras (bspw. sony, canon, nikon), sondern auch die teuren cinema kameras wie die canon EOS cinema reihe, wenn nicht in raw oder xavhc aufgezeichnet wird. aber die datenmengen sind enorm. es gibt viele anwendungen, in denen eine "schnelle kleine" mp4 datei wirklich praktisch ist. problem ist nur: kann mit den "normalen" workstations kein mensch nutzen, weil nur apple m1 und intel igpus die nötigen hw decoder dafür mitbringen.

in der realität mit amd / nvidia siehts dann so aus: normale mediaplayer können die h265 10 bit 422 garnicht abspielen und in davinci resolve über cpu/software kann ich mit meinem 2920X threadripper + vega56 nichteinmal ruckelfrei 4k 60fps in echtzeit wiedergeben. die videos dann schneiden und mit effekten belegen kann man komplett vergessen.

die einen helfen sich mit 32 und 64 kern threadrippern, die dann den codec mit der brechstange verarbeiten, oder man arbeitet mit low res proxy dateien, die anderen steigen auf apple m1 oder intel desktop um, jeweils mit heftigen einschnitten an anderer stelle oder nutzen schlicht den codec nicht, obwohl raw oder xavhc in einigen fällen einfach nur massive platzverschwendung ist.

eine fette video-workstation ist nur solange toll, bis son läppisches 30w apple notebook für einen bruchteil des preises ne bessere performance liefert. die intel gpus werden hier durch den codec-support ein game-changer. wenn da jetzt noch ne ordentliche performance in opencl rauskommt, können sich amd und nvidia mit ihren beschnittenen gaming gpus warm anziehen - dann kommen nämlich die ganzen konstrukteure, vektorgrafiker und fotografen als kundschaft noch dazu. die gaming performance wäre dann für einen verkaufserfolg eher unerheblich.

und bevor man jetzt ins blaue hinaus direkt wieder gegen koduri schießt, sollte man erst einmal den release und tests abwarten und mal im auge behalten, dass sich die welt nicht nur um computerspiele dreht.

und selbst wenn die karten für decoding, gpgpu und opencl völlig ungeeignet wären, kann man die erste generation der karten trotzdem noch über den preis an gamer verkaufen.

wer ernsthaft erwartet, dass intel aus dem nichts amd und nvidia die gamingkrone abnimmt, sollte mal seinen erwartungskompass neu norden. das wird noch jahre dauern.
 
  • Gefällt mir
Reaktionen: TechFA
Bei den Auflösungen und Bildwiederholfrequenzen kann Intel wegen des DisplayPorts 2.0 dann aber sehr hohe Zahlen nennen und spricht unter anderem von zwei Mal 8K60 HDR und vier Mal 4K120 HDR.

In den Folien von Intel steht aber DP2.0 10G ready.

Und das 10G dürfte wohl bedeuten HBR10 bzw. DP40 bzw. 4x10G=40G statt der 4x20G=77G die man eigentlich mit DP2.0 verbindet.

Also eher kein kompressionsfreies unterabtastfreies 8K. Aber immerhin etwas mehr als DP1.4. Inkl. wohl 6K@60 je USB-C Port. 4K@120 könnte ja wohl auch mit DP1.4 schon so gerade eben gehen ? Dann mit DP40 sicher erst recht. Aber 8K@60 würde wohl zumindest HBR13.5 sprich 13.5G ready brauchen ?

Oder man braucht halt mehrere Ports für einen 8K Monitor ..

Und ready bedeuted ja wohl eher man könnte wenn man wöllte - aber ..

Aber immerhin - ein erster zarter Hinweis auf ein DP2.0 "ready" Produkt .. nach dem "Start" des Zertifizierungsprogramms von Vesa für die DP40 und DP80 Strippen.
 
Zuletzt bearbeitet:
Volker schrieb:
Hier gibs auch noch nen Community Post der Chefin von Intel der evtl hilft:
Danke Volker, ich bin das Interview jetzt kurz überflogen. Es ist auf der einen Seite viel PR und auch Buzzword-Bingo, auf der anderen Seite lassen die Informationen, die sie herausgibt, ein paar Schlüsse zu und ich glaube - was ich anfangs nur als Scherz meinte - Vega² - trifft leider zu und zeigt an der Stelle auch, dass Raja Koduri scheinbar nicht wirklich aus Vega gelernt hat und damit denke ich auch, dass er an Navi aka RDNA wirklich nicht beteiligt war.

Statt, dass sie wirklich einmal die Hardwarearchitektur überarbeiten - wie AMD es mit RDNA getan hat, wie es NVIDIA quasi "immer" macht - haben sie die bereits seit mindesten 10 Jahre bestehende Architektur übernommen und primär Funktionen hinzugefügt, mit den sie denken, dass sie die Oberhand gewinnen können, ich sage nur Primitive-Shader.

Man verlässt sich hier an der Stelle dann - wie bei Vega - auf die Softwareentwickler und hofft dann, dass diese mit Tricks im Treiber als auch in dem Shadercompiler dann alles so hinbiegen können, dass es ihrer GPU schmeckt und man die volle Leistung der Hardware ausfahren kann.

Damit man - und damit wird der Timespy-Wert, der hier im Update kursiert gleich vollkommen entwertet - in den ersten Runs gut dasteht, hat man den Compiler so weit mit Anweisungen versehen, dass er die Shader aus den gängigen Benchmarks, auf die eigene Architektur optimieren kann und man halbwegs Leistung bringt.

Intel hat sich hier also ein Software-Monster an das Bein gebunden, da sie für quasi jedes Spiel erst mal die Shader prüfen müssen und dann in ihrem Shadercompiler massive Anweisungen geben müssen, wie dieser die Shader zurechtbiegt für ihre Architektur.

Und das lustige ist, dass sie das sogar relativ offen kommunizieren. Sie haben bei XeHPC gemerkt - deren grober Aufbau und deren Organisation der Recheneinheiten immer noch 1:1 übernommen wurde - dass das Spielen nicht wirklich schmeckt. Statt das aber als Weckruf zu nehmen, die Hardwarearchitektur zu überdenken, wollen sie es in Software lösen.

Na Glückwunsch Intel und Glückwunsch Raja, aus dem Vega-Debakel hast du scheinbar nichts gelernt. Xe kann und wird in Compute-Workloads überzeugende Werte abliefern können. Wird aber bei Spielen unter ähnlichen Problemen leiden wie GCN und im speziellen Vega.

So, mal direkt an Raja, auch wenn er es nicht lesen wird:

Lieber Raja,

du magst durchaus ein genialer Kopf sein und tolle Ideen haben, aber du solltest bei Vega gemerkt haben, dass revolutionäre Ideen alleine nicht ausreichen. Manchmal muss man innehalten und auch einen oder zwei Schritte zurückgehen und sich auch mit der Basis befassen und die Basis umstrukturieren. Ich weiß, das ist unglaublich langweilig, da kann man nicht kreativ sein, sondern man muss teilweise einfach stur die Probleme ermitteln und dann mit langweiligen Handwerksmitteln diese Probleme lösen. Das ist scheinbar nicht dein Stil, aber wenn du für die ganze GPU verantwortlich bist, dann musst du manchmal genau DAS machen - nicht du direkt, aber du musst es dein Team machen lassen. Dann bringt man halt in eine GPU keine Primitive-Shader, dann bringt man halt kein HBCC, dann bringt man halt keine mega geilen XMX-Kerne mit XeSS heraus, sondern macht erst mal eine langweilige Überarbeitung, mit der man Schwachstellen der Architektur behebt!

Die grundlegende Architektur - Struktur - von Xe sowie nun XeHPG - existiert bei Intel bereits seit mindestens 10 Jahren und hat in all der Zeit nie wirklich gut performt und war für die Anzahl an Shader und ebenso für die Rechenleistung vergleichsweise schwach aufgestellt. Als du davon gesprochen hast, dass du bei Intel eine ganz neue Architektur bringst, hatte ich ja echt Hoffnung, dass du da was tolles zauberst, als ich dann die ersten Xe-Informationen sah und die sich mit Gen 11, Gen 10, Gen 9 , Gen 8 und Co deckten, wusste ich schon, dass du keine neue Architektur geschaffen hast und jetzt zeigt sich, dass du immer noch denkst, dass die Probleme alle sich dann per Software lösen lassen.

Ehrlich Raja: Solche Typen wie dich braucht man nicht als Leiter der ganzen GPU-Sparte, der alles verantwortet. Du bist besser in einer Forschungsabteilung aufgehoben, wo du dich kreativ ausleben kannst und tolle neue Techniken ersinnen kannst. Auf deinen Posten gehört jemand, der auch mal innehalten kann, der nicht "The-Next-Big-Thing" vor Augen hat, sondern auch mal nüchtern seinem Team sagt: Wir haben da ein Problem und das müssen wir erst lösen, erst dann können wir weiter gehen.

Ich hoffe ehrlich, dass die nächste Generation dann wirklich besser wird, das jetzt ist doch etwas enttäuschend!
 
  • Gefällt mir
Reaktionen: bad_sign und TechFA
Ich bin ja echt gespannt wie ein Flitzebogen auf die Desktopkarten.
 
  • Gefällt mir
Reaktionen: Onkel Föhn
Saros schrieb:
Raja das Trojanische Pferd.
Well played Lisa Su.
Mal eben hinterhältig den Raja bei Intel eingeschleust…. 😃
Und sowas kommt dann dabei raus ... :evillol:

MfG Föhn.
 

Anhänge

  • AMD INTEL.jpg
    AMD INTEL.jpg
    771,3 KB · Aufrufe: 268
Volker schrieb:
Und die 6500M ist ja schon nicht gut, aber die A370M eben richtig schlecht.
Gut, wenn man bedenkt, was AMD alles bei der 6500M falsch macht und auch weiß, dass die quasi am langen Arm verdurstet und ihren "Schlagkraft" nicht mal im Ansatz auf die Straße bringen kann. …

Dazu der Vorteil der Xe bei Async-Loads wegen der dedizierten INT-Einheiten. … Gut, in Compute-Workloads wird das Ding nicht schlecht sein, aber auch nicht überragend und da wird es auch einer 6500M sowie den GeForce-Karten nicht wirklich wegrennen.

Was für die Karte spricht, ist die Media-Engine, aber AMD und NVIDIA bringne ja bald neue Karten und mal sehen, was da dann kommt.

Ich sag mal: Zu wenig, zu spät Intel!
 
  • Gefällt mir
Reaktionen: TechFA
Volker schrieb:
Und die 6500M ist ja schon nicht gut
Ist sie das im mobilen Bereich denn wirklich? Immerhin sollte sie dort immer mit Alderlake oder Rembrandt gepaart werden, damit löst sich das das En-/Decode Problem und es gibt garantiert PCIe4. Auch werden die Taktraten nicht ans absolute Limit gepusht, durschnittlichen rdna2 Effizienz sollte möglich sein.
Die Probleme im Desktop stammen ja genau daher, dass man für den ursprünglichen Mobilgebrauch diese Dinge gut wegrationalisieren konnte
 
CDLABSRadonP... schrieb:
Was soll denn der fehlende HDMI-2.1-Support? Während sie anscheinend bereits DP 2.0-tauglich sind? Und vor allen Dingen: Wie kommt so etwas mal wieder zu Stande?
Das mit dem DP2.0 Support scheint ja auch wieder nur halb bis Viertel ernst gemeint zu sein. Zitat aus den Intel Folien: DP2.0 10G "ready".

Soll wohl heißen maximal 10G per lane statt der 20G die man eigentlich für vollwertiges DP2.0 bräuchte. Ready soll wohl bedeuten das Intel noch nicht so richtig damit auf den Markt los will. Sie aber schon könnten wenn sie wöllten - oder ein Graka Kunde denn unbedingt will ..

Wenn man sich mal die letzten Apples ansieht (z.B. macBook) scheinen die HDMI Ausgänge per Chip aus dem TB4 gewonnen zu werden .. ich interpretier das mal so das da eigentlich ein DP die Daten anliefert und das dann hinterher in HDMI umgesetzt wird. (Weiß aber nicht ob ich damit richtig liege - es könnte natürlich auch PCIe direkt sein). Da sich HDMI und DP bei Kompression (DSC und Farbunterabtastung) wohl schon grün sind geht das vermutlich auch ganz gut (Kompression läuft nicht im Konverterchip sondern auf der GPU?) solange die Rohdatenrate des Interfaces paßt.

Das war bis DP1.4 und HDMI2.0b wohl kein Problem - DP wuppt gut 8G je lane (32G insgesamt), während die HDMI bei 600Mx10=6G aber nur auf drei Lanes bietet. DP hat da nicht nur bei der Übertragungsrate die Nase vorn sondern auch bei Nutzung aller 4 Lanes für Daten mit embedded Clock (HDMI hat immer noch ne getrennte lane für den Clock) und HDMI nutzte immer noch 8/10 .. was die Gesamtrate dann auf magere 14.4G reduziert.

Bei HDMI2.1 versucht HDMI jetzt mit Gewalt rechts zu überholen (Torschulßpanik?), Rohdatenrate auf 667x16 je Lane erhöht, also etwa die 10.672G je Lane, jetzt plötzlich auch 4 Lanes, und plötzlich auch kein 8/10 mehr sondern 16/18 ..

Wenn jetzt also ARC DP2.0 10G (sprich DP 40G) liefert liegt die Datenrate also leicht höher als die kleinste Stufe von DP2.0 (10G) liefern kann. Wenn auch nur knapp daneben. Dürfte aber trotzdem ein Problem für das Konzept Rohdaten per DP anliefern und Konverterchip sein.

Ob das jetzt dazu führt das es HDMI 2.1 an Computern gar nicht geben wird oder erst dann wenn die DP2.0 alle mindesten HBR13.5 bzw. HBR20 können das sei dahingestellt. Vielleicht wird's aber HDMI an Computern auch nur noch als weitern Tranportcode im Multiplex von USB4/TB4 geben - ohne zusätzliche Hardware ? Das schiene zumindest vernünftig ..

Aber ich steck in der Technik nicht mehr so drin - das sind nur meine 2 ct - und als Quelle für die HDMI2.0b zu HDMI2.1 Veränderungen Infos hab ich ausschließlich mal Wikipedia geglaubt ..
4.1 HDMI 2.1
Vielleicht sind ja auch einfach die HDMI Konverterchips schlicht noch nicht fertig geworden oder zu teuer .. hat sich je von jetzt auf gleich bei dem "Schrittchen" eines Unterschrittes (.b->.0) einer Subversion(.0 auf .1) auch mal eben fast alles am Übertragungsformat geändert um zu DP und TB aufzuschließen äh zur 10G Version von DP/TB sprich dem halben DP/TB .. Hat HDMI vielleicht fertig ?

Angesichts der Tatsacche das Intel jetzt bei ARC IMMMERNOCHKEINDP2.0 zum Standard erklärt - hege ich die Vermutung das wir vielleicht in diesem Jahr nicht mehr als ein wenig DP2.0 - eben DP40 (aka DP2.0 10G) auf dem Markt sehen werden (Paßt z.B. zu 32" 6k 16:9 Retina Displays .. die es bislang nur mit Apple proprietärem geheimem Interface gibt). Und DP2.0 mit voller Datenrate (77G) dann erst im nächsten Jahr .. So das vielleicht USB5 mit 80G und seinen USB5-Hubs dann gerade noch fast rechtzeitig kommen kann um das ganz normal im USB5/TB5 Multiplex übertragen zu können .. und selbst an jedem USB5-Hub (nicht USB4-Hub) Port als alternate Mode für DP80 Kabel zur Verfügung stehen kann .. irgendwie sinnvoll wär das technisch schon. Und so haben alle Beteiligten bei dem 8k Monitordrama/DP2.0 noch ein drittes Jahr nach Release des DP2.0 Standards durch Vesa Zeit um endlich die große Marktoffensive zur Ablösung von 4K-Monitoren zu starten ..
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: TechFA
DevPandi schrieb:
Statt, dass sie wirklich einmal die Hardwarearchitektur überarbeiten - wie AMD es mit RDNA getan hat, wie es NVIDIA quasi "immer" macht - haben sie die bereits seit mindesten 10 Jahre bestehende Architektur übernommen und primär Funktionen hinzugefügt, mit den sie denken, dass sie die Oberhand gewinnen können, ich sage nur Primitive-Shader.
Ich habe mir schon des Öfteren darüber Gedanken gemacht und bin immer wieder geneigt, einer bestimmten These nach zu gehen (siehe Beitrag von mir hier, wo ich das ganze versuche auseinander zu klabüstern).

Auch die extrem nüchternden Kommentare von @Volker machen mich echt stutzig. Weil für Volker ist en Grafikkarten Launch seit Jahren täglich Brot! Und dann diese verhaltene Reaktion.

Was mich aber immer wieder stutzig macht oder mir zumindest ziemlich zu denken gibt, ist, daß es möglich ist, daß es gar nicht an eventuell schlechten Intel-Treibern oder Intel's/Raja's Inkompetenz liegen könnte, sondern daran, daß sie vielleicht gar nicht anders können. Stichpunkt Patente und so .. Siehe auch mein Beitrag hier.

Ich bin immer wieder schockiert, wie präzise, durchdacht und fundiert dieser dieser Beitrag vom Forumsmitglied @Smartcom5 ist, obwohl er von Ende 2018 ist! Scheint als hätte Derjenige selbst damals schon mehr Einsicht in Intel's Interna gehabt als manch ein Anderer. Liegts vielleicht daran, daß Intel gar nicht anders kann?

Kannst Du dir mal die Beiträge durchlesen (besodners den von @Smartcom5, "Wer nicht patentiert, verliert"!) und Deine Einschätzung zum Besten geben? Wäre echt lieb. Deine Meinung dazu interessiert mich wirklich brennend! ♥
DevPandi schrieb:
Intel hat sich hier also ein Software-Monster an das Bein gebunden, da sie für quasi jedes Spiel erst mal die Shader prüfen müssen und dann in ihrem Shadercompiler massive Anweisungen geben müssen, wie dieser die Shader zurechtbiegt für ihre Architektur.
Was das selbe Problem ist, daß Intel bereits bei Larrabee hatte und später auch bei Xeon Phi (Larrabee 2.0):
Es gab trotz aller Versprechungen kein vernünftiges Software-Universum und keine entsprechend potente Treiber-Unterstützung (was einer der Hauptgründe war, weswegen beide krachen scheiterten)!

Jetzt ists mit Xe/Arc der nächste Versuch und sie haben noch immer das identische Problem. Ergo, wieder nix gelernt.

TechFA
 
Zuletzt bearbeitet:
Was ich hier auch nicht ganz verstehe ist:

Intel hätte doch den A350M und A370M komplett auslassen können, und erst mit dem A550M beginnen. Der sieht von den Spezifikationen nämlich schon kompetitiv für Einstiegklasse aus. Und dann hätte es wahrscheinlich auch gar keinen Shitstorm gegeben.
Das müssen die (von Intel) doch gewusst haben. Wieso rücken die sich dann selber in ein schlechtes Licht...
 
@franzerich Sie haben die SKUs des Low-end-Segments präsentiert, weil Intel wahrscheinlich im Moment nichts anderes funktionierendes vorzuweisen hat und es das einzige ist, was man verkaufen kann.

Nüchtern betrachtet besitzen die vorgestellten SKUs eigentlich keine Daseinsberechtigung im Markt, da die gebotene Leistung für die Verbrauchswerte absolut schlecht sind (zu hoher Verbrauch bei im Verhältnis zu geringer Leistung; im Vergleich zum gescheuten Wettbewerb) und die Preis-Leistung wahrscheinlich ebenso Intel-typisch indiskutabel wäre (als alleinstehendes Produkt im Markt mal wieder zu teuer; deswegen kommst ja auch nur über die OEMs).

.. wobei eine schlechte Verbrauchs-Leistung-Metrik und obendrein indiskutable Preis-Leistungs-Verhältnisse ja in der Vergangenheit bedauerlicherweise öfter mal ein prägendes Alleinstellungsmerkmal von Intel-Produkten war, weil sie wieder mal am Markt und Anwender vorbeientwickelt haben, das Produkt aber trotzdem mit aller Macht in den Markt zu drücken versuchten. Schein also so langsam bei Intel Mode zu werden.

Manchmal kann man bei dem Verein einfach nur noch den Kopf schütteln, über die Borniertheit, Produkte die keine praktisch relevante Daseinsberechtigung besitzen (weil am Markt/Anwender vorbei entwickelt), trotzdem mit aller Macht in den Markt drücken zu wollen.

TechFA
 
Auch komisch das die Intel-Grafikkarten ebenfalls ständig verschoben werden. Die sollten erst Q1 2022 kommen, dann Q2 und nun spricht man von Sommer/Herbst.
 
Zurück
Oben