> > > > Intel bestätigt Core i7-8809G mit Vega-GPU, 100 W TDP und Übertaktbarkeit

Intel bestätigt Core i7-8809G mit Vega-GPU, 100 W TDP und Übertaktbarkeit

Veröffentlicht am: von

intelAnfang Januar wurde die Core-H-Serie mit Radeon-Grafikeinheit und HBM2-Speicher erstmals offiziell angekündigt. Bereits seit Monaten wurde darüber spekuliert, bisher hat sich Intel aber auch mit technischen Daten zurückgehalten. So war unbekannt, welche CPU-Kerne zum Einsatz kommen und welche GPU-Architektur Intel von AMD verwendet.

Nun ist der Core i7-8809G auf der Intel-Webseite aufgetaucht und damit sind auch die ersten handfesten technischen Daten bekannt. Bisher wurde erwartet, dass Intel auf der Consumer Electronics Show in der zweiten Januarwoche mehr über die ersten Core-H-Modelle verraten würde.

Geht es nach Intel, ist der Core i7-8809G ein übertaktbarer Prozessor, der bei einer Thermal Design Power von 100 W einen Basistakt von 3,1 GHz vorzuweisen hat. Vier Kerne und acht Threads sollen hier arbeiten. Der L3-Cache soll 8 MB groß sein und das Dual-Chanel-Speicherinterface unterstützt DDR4-2400. Hinsichtlich der integrierten Grafik führt die Tabelle von Intel die HD Graphics 630 und eine Radeon RX Vega M GH Graphics auf. Damit wird erstmals bestätigt, dass hier die Vega-Architektur zum Einsatz kommt – wie auch in den AMD-eigenen Raven-Ridge-APUs als Kombination aus Ryzen-CPU und Vega-GPU sowie den dedizierten Grafikkarten Radeon RX Vega 56 und 64.

Aus bisher unbestätigten Quellen stammen Informationen zum Shaderausbau der integrierten Vega-GPU sowie der verwendeten Prozessor-Architektur. So sollen der Dual-Channel-Speicher mit DDR-2400, die Nennung der Intel HD Graphics 630 sowie die Tatsache, dass es sich um einen Quad-Core-Prozessor auf Kaby Lake hindeuten. Bisher wurde der Prozessor auch inoffiziell als Kaby-G bezeichnet – ein weiterer Hinweis. Ein weiterer Informationsschnipsel aus inoffizieller Quelle ist der Boosttakt von 4,1 GHz.

Hinsichtlich des Shaderausbaus macht Intel keine Angaben. Inoffiziell ist von 24 Compute Units, also 1.536 Shadereinheiten die Rede. Diese sollen einen Takt von 1.190 MHz erreichen. Der HBM2 soll 4 GB groß sein und mit 800 MHz takten.

Mit den Core-H-Prozessoren zielt Intel auf den Markt für leistungsstarke Prozessoren mit integrierter Grafikeinheit. Bei einer Thermal Design Power von 100 W sollte auch klar sein, wo der Core i7-8809G sein Einsatzgebiet finden wird. Ein Großteil des Leistungsbudgets dürfte dabei auf die GPU und den HBM2 fallen. AMD verkauft den Ryzen 7 2700U mit 10 Compute Units bzw. 640 Shadereinheiten mit einer konfigurierbaren TDP von 25 W. Da der Core i7-8809G 24 CUs einsetzen soll, käme das von Intel angesprochene Leistungsbudget von 55 W für die GPU und die 45 W für die CPU-Kerne in etwa hin.

Interessant wird zu sehen sein, wie Intel innerhalb des Leistungsbudget jonglieren wird und welche Möglichkeiten es hier gibt. Neben dem Core i7-8809G scheint es auch noch die Modelle Core i7-8705G und i7-8706G zu geben. Details zu diesen Modellen gibt es aber noch nicht.

Auf der CES 2018 wird Intel vermutlich mehr über die Core-H-Prozessoren verraten. Die Keynote von Intel wird am 8. Januar stattfinden.

Update:

Ein baldiger Start der Core-H-Prozessoren bahnt sich an, denn nach dem Core i7-8809G tauchen auf der Webseite von Intel nun auch Hinweise auf weitere Modelle auf.

Der für die Erklärung der Namensgebung beispielhaft verwendete Core i7-8705G wird als Modell mit "Includes discrete graphics on package" geführt. Weitere Details nennt die Webseite hier aber nicht.

Social Links

Ihre Bewertung

Ø Bewertungen: 5

Tags

Kommentare (51)

#42
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 33945
Zitat oooverclocker;26068690
Nein. Intel mappt den Kernel-Speicher in den Speicherbereich des Nutzers, damit der Zugriff beschleunigt ablaufen kann. Soweit ich das nun korrekt mitbekommen habe, macht das AMD nicht, und ARM wohl nur beim neuesten Modell. Die Kernel-Speicherinhalte sind bei Intel jedoch in einem "geschützten" Bereich - leider ist dieser "Schutz" aber unwirksam. Der saubere Fix bedeutet, dass man die Adressbereiche physisch trennt, damit man erkennen kann, woher der Zugriff kommt. Aktuell geht das nicht und dafür müsste man eine neue Architektur entwickeln.
Die andere Möglichkeit wäre, das Ding so zu fixen, wie es jetzt wohl in Software gefixt wurde. Ob das in der CPU ohne Architekturänderung geht, weiß ich nicht, aber wenn ja, wird es sicherlich sehr viel komplexer sein, als Du es Dir jetzt vorstellst. Wie bereits geschrieben, kann man nicht so leicht feststellen, dass der Zugriff aus dem Nutzerumfeld kommt, weil es die gleichen Adressen sind. Beides kostet wahrscheinlich Leistung und ist höchstwahrscheinlich auch ein Mitgrund, warum Intel-Prozessoren gegenüber AMD-Prozessoren in der Vergangenheit für Datenbanken etc. mit mehr I/O-Leistung und geringeren Latenzen glänzen konnten. Es ist durchaus wahrscheinlich, dass sie diesen Vorteil durch das Beheben der Sicherheitsprobleme wieder teilweise einbüßen. (Bei Datenbanken wie PostgreSQL sind nach dem Softwarefix Performanceeinbußen von ca. 20% aufgetreten).


Es ist mühsam über derartige Details zu sprechen, da ich nach all den Kommentaren der letzten Zeit der Meinung bin, du hast an Softwareentwicklung, vor allem in derartigen Tiefen, keine Anteile. Das Verhalten bei AMD ist ähnlich. Bei AMD - weswegen AMD von architektonischer Differenz spricht -> wirft ein Access auf höher priviligierte Speicher aber sofort eine Exception. Bei Intel wird die Exception später geworfen - dies lässt sich dahingehend angreifen eben WEIL man gezielt Abbruchbedingungen in Schleife laufen lässt und sich der OoO Ausführung bedient - gepaart mit nem Offset Speicherbereiche zu lesen die nicht gelesen werden dürften. Intel betont hierbei klar, es funktioniere genau so wie es soll...
"Vulnerable CPUs: This attack requires that the CPU fails to promptly check security flags while performing L1 D-cache loads for a speculatively-executed instruction. Various Intel CPUs (everything from Nehalem and Silvermont onwards, including Coffee Lake and Xeon Phi) are vulnerable. AMD CPUs are not vulnerable."
Aus dem Whitepaper entnimmst du den Part zu Intel - und wenn nötig auch mehr Background über die Funktionsweisen.
Leider gibt sich Intel an der Stelle zwar einsichtig scheint aber zu versuchen das nicht als Hardwarefehler zu sehen. Kann man sicher drüber streiten


"Ob das in der CPU ohne Architekturänderung geht, weiß ich nicht, aber wenn ja, wird es sicherlich sehr viel komplexer sein, als Du es Dir jetzt vorstellst."
Du hast keinen Plan, gestehst dir das selbst ein, aber damit deine Aussage Rund wird behauptest du, es sei sicherlich komplexer als ich es mir vorstelle? Im Grunde beschreibe ich aber nur das, was AMD im Endeffekt macht(e). Nämlich das, siehe oben, sofortige Abfangen. Ich sehe hier keinen Grund zu einer vollständigen Architekturänderung. Da du ihn aber sehen willst - bitte ich dich doch einfach darzulegen an welcher Stelle die für dich zu einer Architektuänderung führen sollte und vor allem, warum dies ensprechend nicht in 6 Monaten +- x durchführbar sein sollte.
Aus meiner Sicht, entweder du urteilst objektiv - dann kannst du es begründen, oder eben nicht. Dann ists Wunschvorstellung, Einbildung oder ähnliches... Einfach zu behaupten - derartiges steht seit Jahren fest. Nunja, Stammtischargument, noch dazu eins, was sich nicht belegen geschweige denn widerlegen lässt. Und nur weil es möglicherweise dann doch eintritt oder eben gerade nicht - macht das schmücken mit so einer Diskusionsweise auch nicht gerade objektiv...

PS: auch wenn es nichts mit dem Thema zu tun hat:
Der Postgres Kommentar respektive das Bilden des Zusammenhangs ist auch nicht ganz treffend. Der Performanceverlust kommt durch das Kontextswitching. Vorher - ohne Fix - ging das schnell. Nach dem Switch MUSS der Speicher erst bemüht werden, die Daten wurden entsprechend ja entfernt, damit es nicht abgreifbar ist. Ich sehe da keinen Zusammenhang mit der AMD Umsetzung, zumal auch - nach Whitepaper auch die AMD Umsetzung den Speicher mappt, was das notwendige Switchen eben schnell macht. Deswegen sprach ich auch von dirty Workarround - es ist im Moment die Brechstangenmethode. Kritisiert im übrigen auch Kollege Torvalds...

Zitat oooverclocker;26068690
Hast Du dafür vielleicht einen Link zum Originalzitat? Ich könnte mir gut vorstellen, dass es so formuliert war, dass alle CPUs, die 2018 [U]designed[/U] werden, diesen Fix haben. Und zweitens muss man bedenken, dass Intel den Core H mit Vega-GPU schon letztes Jahr angekündigt hat. Da muss man auch differieren, wann Intel ein Produkt als "herausgekommen" sieht, und wann das der Leser des Statements sieht, wenn sie das Wort "herauskommen" benutzt haben. Nehmen wir mal an, es war "appear" im englischen, dann ist das auf Deutsch "in Erscheinung treten" und wenn Intel 2017 sagt, wir werden ab 2018 Core Hs mit Vega verkaufen, dann ist er schon 2017 "in Erscheinung getreten". Man sollte nie vergessen, dass das PR-Aussagen sind und die sind häufig mit Finessen gespickt, die am Rande der Legalität sind.


Stand im Luxx-Artikel - mittlerweile aber revidiert, leider aber in irgend nem Update mittendrin. Also nicht ganz direkt ersichtlich wann genau. Glaube Update 5 war es, was angepasst wurde...
Siehe Ausführung von unl34shed. Aber auch hier das gleiche, du wusstest selbst nichts davon. Warst ohne Faktenbasis aber überzeugt von der Nichtmachbarkeit? Zumindest soweit überzeugt eine Wahrscheinlichkeit zu beziffern?
Das Wiegen der Übersetzung oder Bedeutung auf der Goldwage stand übrigens nicht zur Debatte. Auch WENN es durch die korrekte Aussage nun klar unwahrscheinlicher ist, bleibt es immerhin im Rahmen des möglichen. Weiterhin gilt, abwarten. Wie bei jedem Release - meckern kannste doch immernoch? Warum nicht lieber über das Thema als solches diskutieren - anstatt hier Fehler einseitig zu suchen? Siehe oben, ist so ziemlich der Kritikpunkt meines Posts ggü. den deinigen der letzten Zeit.

Zitat oooverclocker;26069090
Edit: Ich hoffe, dass AMD und ARM den Spectre-Bug einfacher und schneller beheben können, als Intel den Meltdown aussitzen muss, sonst gibt es erst mal keine gescheiten CPUs mehr zu kaufen :D


Ironischerweise ist der dirty Workarround in Software zwar dreckig ohne Ende, dafür aber wirksam. Technisch gesehen kann ein gepatchtes System über diesen Weg nicht angegriffen werden, weil mit Workarround nix mehr zum abgreifen geladen ist. Der Spectre Bug in beider Form wirkt dahingehend eher problematisch, weil es eher ein "works as designed" ist - in wie weit uns das die nächsten Monate und Jahre begleiten wird, ist völlig offen. Nach bisherigen Erkenntnissen ist ein Hardwarefix für diese Lösung eher schwer möglich. Hier müsste man aber - siehe oben, mehr Details kennen.
Nach der Ausführung der Inteljungs gibts dafür von Intel auch keinen fix in Hardware - eher baut man auf das Zusammenspiel von Firmwareanpassungen und Softwareupdates.

Übrigens, diese Aussage ist ja doch objektiv :bigok:
#43
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Flottillenadmiral
Beiträge: 5635
Zitat fdsonne;26069933

Leider gibt sich Intel an der Stelle zwar einsichtig scheint aber zu versuchen das nicht als Hardwarefehler zu sehen. Kann man sicher drüber streiten

Ich denke, es ist relativ offensichtlich, warum Intel das in den nächsten 2 Jahren auch noch nicht als Hardwarefehler sehen möchte - und eventuell liegt ja in der out-of-order execution nicht mal der eigentliche Fehler begraben... PR-Abteilungen lenken gern vom Thema ab, um einen positiven Satz zu formulieren.


Zitat fdsonne;26069933
Ich sehe hier keinen Grund zu einer vollständigen Architekturänderung.

Während Du in Deinem Programmcode problemlos Zeilen einfügen kannst, weil Du unbegrenzt Speicher zur Verfügung hast, kannst Du nicht einfach mal eine Schaltungslogik in einer cpu hinzufügen, die folgendes macht.
if unpriviledged do jump xyz
Geschweige denn einen Pfad dort hin ziehen, wo dieser Wert benötigt wird und wo er hinhüpfen soll. Wenn das überhaupt schon alles wäre...
Die Schaltung ist doch schon längst feststehend und durchsimuliert. Da ist kein Nanometer Platz, wo Du noch irgendwas einfügen könntest! Sonst muss die ganze Schaltung neu berechnet werden und alle Simulationen, EM-Tests etc. müssen erneut laufen - das ist wie wenn Du komplett von vorn anfängst -> neue Architektur!
Naja, nicht total von vorn, deshalb bin ich auch etwas optimistischer gestimmt als der Ex-Intel-Mitarbeiter und hoffe, dass Intel die jüngste Architektur mit etwas Verlust noch in der Entwicklungsstufe zurückversetzt, damit schneller komplett fehlerfreie Intel-CPUs wieder auf dem Markt sind.

Du kannst immer nur destruktiv eingreifen, also Pfade löschen, oder allenfalls mit Glück irgendwo einfügen, falls es günstig läuft.
Die zweite Möglichkeit ist, ein Debugfeature zu nutzen, wenn Du schon ahntest, dass eine Stelle beispielsweise zu heiß werden und Fehler produzieren könnte und deshalb die Möglichkeit eingebaut hast, die Kapazität durch Löschen eines Pfads zu verringern. Wer mitdenkt, kann hier Verluste in Milliardenhöhe verhindern.
#44
customavatars/avatar92992_1.gif
Registriert seit: 10.06.2008
zuhause
Admiral
Beiträge: 11245
Na kommt wie relevant ist die Lücke?
Wird sich kaum jemand in einen htpc hacken damit. Zumal man sowieso erstmal Nutzerrechte benötigt um die entsprechenden Befehle auszuführen.
#45
Registriert seit: 05.11.2007
Neckar-Odenwald Kreis
Kapitän zur See
Beiträge: 3595
Zitat Hardwarekäufer;26071150
Na kommt wie relevant ist die Lücke?
Wird sich kaum jemand in einen htpc hacken damit. Zumal man sowieso erstmal Nutzerrechte benötigt um die entsprechenden Befehle auszuführen.


Es reicht ein einfacher Webbrowser, der ein Java Script ausführt, das kann ein Werbebanner sein oder durch eine kompromittierte Website geschehen.
Ob man die Daten vom HTPC von Tante Lisbeth braucht lässt sich drüber streiten, aber der Fehler erlaubt prinzipiell den Zugriff auf das gesamte System!

Das aber als irrelevant hinzustellen ist schon arg naiv.

Was es für VM Betreiber bedeutet, wo man einfach aus der eigenen VM ausbrechen kann und die anderen "ausspionieren" fang ich erst gar nicht an.
#46
customavatars/avatar92992_1.gif
Registriert seit: 10.06.2008
zuhause
Admiral
Beiträge: 11245
Ich habe es nicht als irrelevant bezeichnet sonder nach der Relevanz gefragt. Und die besteht beim htpc von Tante Lisbeth sicher nicht.
#47
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Flottillenadmiral
Beiträge: 5635
Naja, wenn sie auf dem HTPC im Browser Nachrichten anschauen möchte, und da ein Werbebanner kommt, das von der Werbefirma vorher nicht gut geprüft wurde(ist ja schon oft passiert), dann hat natürlich auch Tante Lisbeth ein Problem.
#48
customavatars/avatar92992_1.gif
Registriert seit: 10.06.2008
zuhause
Admiral
Beiträge: 11245
Solange sie mit dem htpc nicht online Banking macht sondern den nur als htpc nutzt passiert ihr nix. Niemand investiert in so einen Angriff um zu gucken was Tante Lisbeth in ihrem Youtube-Verlauf hat oder welche Serie sie schaut..
#49
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Flottillenadmiral
Beiträge: 5635
Das nicht, aber sie können auch ihren Netflix-Account und Amazon-Account etc. hacken, wenn sie das Passwort aus dem Speicher auslesen. Und dafür müssten sie sich natürlich nicht extra anstrengen, sondern würden ein Programm schreiben, das simultan viele Geräte gleichzeitig angreift. Dass das nur der Rechner von "Tante Lisbeth" ist, ist ja dem Programm gar nicht bewusst.
#50
customavatars/avatar92992_1.gif
Registriert seit: 10.06.2008
zuhause
Admiral
Beiträge: 11245
Trotzdem müsste derjenige aber erstmal als Nutzer auf den Rechner kommen und dort die erforderlichen Befehle ausführen wenn ich das richtig gelesen habe.
#51
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Flottillenadmiral
Beiträge: 5635
Nein, er kann JavaScript-Code ins Netz stellen, den man dann mit der Seite abruft. Man selbst ist Nutzer, hat den Browser gestartet und der Browser führt JavaScript aus. Folglich sind alle Bedingungen erfüllt. Das Skript kann die Attacke ausführen und die Passwörter auslesen und verschicken.
Zitat Golem.de
Normale Programme wie etwa Datenbanksoftware oder Javascript-Applets können auf eigentlich geschützten, dem Kernel zugewiesenen Arbeitsspeicher zugreifen

Quelle
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Intel kämpft mit schwerer Sicherheitslücke (Update: Intel veröffentlicht...

Logo von IMAGES/STORIES/2017/INTEL

Vor, während und zwischen den Feiertagen herrschte ein wildes Treiben in der Linux-Community. Zunächst war nicht ganz klar, was hier genau vor sich geht, inzwischen aber scheinen die Auswirkungen deutlich zu werden: Intel hat nach einer Lücke in der Management Unit eines jeden... [mehr]

Coffee Lake: Intel Core i7-8700K, i5-8600K und i5-8400 im Test

Logo von IMAGES/STORIES/2017/INTEL8GEN

Der sechste und letzte (?) CPU-Launch in diesem Jahr kommt von Intel: Mit den unter dem Codenamen Coffee Lake zusammengefassten Core-i7- und i5-Modellen kommen bei Intel erstmals Sechskern-Prozessoren in den Mainstream-Markt. Bedanken darf man sich aber wohl nicht bei Intel, sondern bei der... [mehr]

Coffee Lake: Overclocking-Check

Logo von IMAGES/STORIES/LOGOS-2016/KABYLAKE

Nach dem ausführlichen Overclocking-Check für Skylake-Prozessoren sowie dem Overclocking-Check für Kaby Lake-Prozessoren ist es nach Veröffentlichung der neuen Generation mit Codenamen Coffee-Lake erneut Zeit für einen Overclocking-Check. Wir werfen einen Blick auf die Übertaktbarkeit... [mehr]

Intel Core i5-8250U und i7-8550U im Test: Mal ein kleiner, mal ein großer...

Logo von IMAGES/STORIES/2017/MEDION_P7649_KABY_LAKE_REFRESH

Im Gleichschritt marschierten Intels Desktop- und Mobil-Prozessoren schon länger nicht mehr. Ein so gravierender Unterschied wie derzeit ist aber völlig neu - und für den Verbraucher einmal mehr irritierend. Denn mit der 8. Core-Generation spendiert Intel beiden Plattformen eine eigene... [mehr]

Gelungener Feinschliff: AMD Ryzen 7 2700X und Ryzen 5 2600X im Test

Logo von IMAGES/STORIES/2017/AMD_RYZEN_7_2700X

Rund ein Jahr nach dem Start der Ryzen-Prozessoren legt AMD nach und bringt die zweite Generation in den Handel. Die soll schneller und effizienter arbeiten und den Druck auf Intel weiter erhöhen. Allerdings lautet die Devise Evolution statt Revolution, statt gravierender Änderungen gibt es vor... [mehr]

AMD Ryzen 5 2400G und Ryzen 3 2200G im Test: Die Lücke ist gestopft

Logo von IMAGES/STORIES/2017/AMD_RYZEN_5_2400G

Während Notebook-Käufer sich bereits seit einigen Wochen von den Vorzügen der Zen-basierten Raven-Ridge-APUs überzeugen können, musste sich das Desktop-Lager noch gedulden. Nun aber heißt es auch hier: Intel erhält neue Konkurrenz. Und die könnte einen noch größeren Einfluss als die... [mehr]