Intel SB IGP als OCL beschleuniger?

[=Floi=]

es kam im reviews thread die frage auf, warum man die igp einfach so mitschleppt. Es ist auch komisch, dass gerade die besseren "k"-Modelle 12EUs haben. Wäre es da nicht eine möglichkeit die 12EUs als OCL-Beschleuniger zu nutzen?
hällt man mit dem feature noch hinterm berg, um amd dann später damit richtig zu überfahren?
Es ist nur eine spekulation, aber es ist schon komisch wie intel hier vorgeht.

[iFanatiker]

Natürlich wäre es eben absolut sinnvoll wenn Intel wirklich den Hintergedanken bei Open CL ünterstüzen würde: CPU+GPU können zusammen an einer komplexen Aufgabe arbeiten und entsprechen der Anforderung der Unteraufgaben erledigen. Dadruch, daß ja die IGP auf den L3 zugreifen kann, ist es ja gar noch unverständlicher wieso Intel die 12 EU nicht untersützt. Die rohe Rechenleistung dürfte ja immerhin irgendwo zwischen GT218 und GT216 liegen (reine Spekulation Aufgrund der Leistung bei Shaderlastigen Spielen) und damit könnte man schon was anfangen.

Eventuell ist es aber eben alles nur eine Treiberfrage und die IGP 2000/3000 wird per Treiber Open CL fähig und sogar die Desktop SBs können es nutzen ohne, daß die IGP als GPU aktiv ist.

Noch unverständlicher ist, daß der Fix-Unit Video Encoder ja bei den Desktopvarianten auch nicht genutzt werden kann (ohne die Nutzung der IGP)....oder was falsch verstanden?

Aber wieso Intel die IGP überall rumschleppt ist doch nur eine ökonomische Entscheidung.

So braucht Intel für den gesamten Endkundenmarkt (Desktop+Mobile) ja faktisch nur zwei Produkte entwickeln und fertigen und diese entsprechend nach Fehler und/oder Bedarf "konfigurieren" (Würde fast wetten, daß alle SBs an sich 12 EUs haben und diese entsprechend deaktiviert werden....aber mal schauen). Es wäre also für Intel ungünstiger gewesen eine Variante ohne IGP zu fertigen, als die jetzige Situation.

Ich würde gar den Desktop SB als "Abfallprodukt" der mobilen Varianten sehen, da ja fast alle neuen Feuteres ja doch deutlich auf den mobile Markt abzielen. Es war ja Intel sogar diesmal wichtig die ULV und LV Modelle sofort am Anfang am Start zu haben und die "High-End" Desktop Retial CPU recht weit nach hinten zu schieben.

[deekey777]

es kam im reviews thread die frage auf, warum man die igp einfach so mitschleppt. Es ist auch komisch, dass gerade die besseren "k"-Modelle 12EUs haben. Wäre es da nicht eine möglichkeit die 12EUs als OCL-Beschleuniger zu nutzen?
hällt man mit dem feature noch hinterm berg, um amd dann später damit richtig zu überfahren?
Es ist nur eine spekulation, aber es ist schon komisch wie intel hier vorgeht.
Falsches Forum.
Mit Sand gemacht - Intels neue "Sandy Bridge"-Vierkerne Core iX 2000 im Test (http://ht4u.net/reviews/2011/intel_sandy_bridge_sockel_1155_quadcore/index23.php)
Die Antwort ist: Ja die iGPU unterstützt OpenCL. Allerdings sieht man bei Intel keine Notwendigkeit darin, OpenCL zu fördern. Somit kann es noch einige Zeit dauern, bis entsprechende Compiler verfügbar sind. Mehr wollte man uns leider nicht verraten.
Also Intel sagt, dass die iGPU OpenCL unterstützt, also nehmen wir das einfach hin. Dennoch glaube ich kaum, dass Intel "keine Notwendigkeit sieht, OpenCL zu fördern". Intel ist einfach noch nicht soweit: Was man nicht hat, ist Mist.

Warum Intel sie mitschleppt? Damit man Fertig-PCs bauen kann, die auf kleinere Grafikkarten verzichten. Denn Intel bietet ja keine Grafikkarten an.
Intel geht ja so weit, dass alles deaktiviert wird, wenn eine Grafikarte im PC steckt.

[y33H@]

(Würde fast wetten, daß alle SBs an sich 12 EUs haben und diese entsprechend deaktiviert werden....aber mal schauen)Das ist der Fall.

[davidzo]

Das ist der Fall.
jein, afaik sinds drei dies. ein dc mit 6 eus ist auch dabei, die anderen beiden haben 12. also alle qcs haben in silizium 12 eus vorhanden.

[y33H@]

Das meinte ich.

[=Floi=]

ich meine die GPU als coprozessor. also wenn eine richtige grafikkarte im pc steckt. Es macht einfach keinen logischen sinn die igp mitzuschleppen und nicht zu nutzen.

bei den stückzahlen und der größe der gpu macht es eine menge holz aus. Man will an allen ecken und enden sparen und ballert hier mal eben zum spass ~20% mehr DIE-fläche raus.

[Fabian_HT4U]

Moin,

ich habe Anfang Dezember auf einem Briefing von Intel sicher fast eine halbe Stunde mit einem etwas höheren Tier über dieses Thema gequatscht. Das Ergebnis ist so klar wie traurig. Intel hat imho kein Interesse an OpenCL (aktuell). Willst du was rechnen, nimm die CPU, die ist meist eh schneller. Wenn doch die GPU schneller ist, und du machst täglich so ein Zeug, kauf die eine NVIDIA-Karte. So in etwa lautete das Ergebnis.

Intel sieht die iGPU aktuell als Multimedia- und 2D/3D-Beschleuniger. Ersteres gelingt dabei - finde ich - sehr ordentlich. 3D - nun ja, wurde ja alles dazu gesagt.

grüße
Fabian

P.S Ich denke mittlerweile, dass Intel die iGPU in die Quads integriert hat, wegen den Notebooks. Da wird sich jeder OEM nun zweimal überlegen, ob er noch eine diskrete Karte dazu steckt oder nicht.

[deekey777]

ich meine die GPU als coprozessor. also wenn eine richtige grafikkarte im pc steckt. Es macht einfach keinen logischen sinn die igp mitzuschleppen und nicht zu nutzen.

bei den stückzahlen und der größe der gpu macht es eine menge holz aus. Man will an allen ecken und enden sparen und ballert hier mal eben zum spass ~20% mehr DIE-fläche raus.
Gibt es viele Rechner, wo die integrierte Grafikeinheit aktiv bleibt, wenn eine dedizierte Grafikkarte eingesteckt wird? Auch hier schleppen Chipsätze GPUs mit.

Bevor man sich solche Überlegungen macht, sollte man sich fragen, ob die iGPU überhaupt eine gute GPGPU ist. Da sie nur DX10.1-fähig ist, würde es mich nicht wundern, dass sie vielleicht den Fähigkeiten der HD4000-Serie entspricht. Wenn sie über kein Localmemory verfügt, wird dafür entweder LLC (unwahrscheinlich) oder gleich Arbeitsspeicher benutzt. Und so weiter.

Kurz und knapp: Wenn die iGPU eh eine schlechte GPGPU ist, warum sollte Intel Resourcen in die Entwicklung eines OpenCL-Treibers für die iGPU investieren?

[iFanatiker]

Wenn sie über kein Localmemory verfügt, wird dafür entweder LLC (unwahrscheinlich) oder gleich Arbeitsspeicher benutzt. Und so weiter.


Die IGP hat Zugriff auf den LLC. Hat Intel ja selbst bestätigt. Die IGP hängt am selben Bus wie die CPUs bzgl. des LLC. Ist ja gerade für die Einsatzzwecke von Open CL genial.

[deekey777]

Die IGP hat Zugriff auf den LLC. Hat Intel ja selbst bestätigt.
Meine Überlegung war, dass OpenCL entweder echtes Localmemory (LDS ab HD5000, Nvidias Shared Memory) oder die Auslagerung auf Globalmemory (VRAM, siehe HD4000) kennt.
Damit LLC benutzt werden kann, bedarf es einer herstellerspezifischen Extension. AMD hat's bisher nicht geschafft, das GDS über OpenCL nutzbar zu machen.

... Die IGP hängt am selben Bus wie die CPUs bzgl. des LLC. Ist ja gerade für die Einsatzzwecke von Open CL genial.
Ohne zu wissen, was die iGPU genau kann, wäre ich mit solchen Äußerungen vorsichtig.

[iFanatiker]

Meine Überlegung war, dass OpenCL entweder echtes Localmemory (LDS ab HD5000, Nvidias Shared Memory) oder die Auslagerung auf Globalmemory (VRAM, siehe HD4000) kennt.
Damit LLC benutzt werden kann, bedarf es einer herstellerspezifischen Extension. AMD hat's bisher nicht geschafft, das GDS über OpenCL nutzbar zu machen.

Was spricht denn dagegen, daß auch der LLC als Local Memory dient? Ist doch nur eine Frage wie Intel das ganze intern realisiert hat und wie der Treiber (sprich der Runtime Compiler) arbeitet? Klar..die Latenz und Bandbreite sind nicht mit dem "echten" Localmemory vergleichbar, geht ja aber mehr um Kompatibilität zu bestehenden Code.


Ohne zu wissen, was die iGPU genau kann, wäre ich mit solchen Äußerungen vorsichtig.

Jetzt mal abseits davon: für die meisten Open CL Belange dürfte eine Mitausführung auf den EU doch schneller sein als auf den CPU Kernen?

[Gipsel]

Was spricht denn dagegen, daß auch der LLC als Local Memory dient?Nichts. Das könnte Intel genau so machen, wie AMD bei der HD4000er-Serie, bei der local memory auch einfach auf das global memory gemappt wird (AMD hat sich nicht die Mühe gemacht, bei passenden Zugriffsmustern den schnelleren und physisch vorhandenen LDS zu benutzen). Durch das (hoffentlich) automatische Caching im LLC dürfte das sogar schneller als bei der HD4000er-Serie werden.

Das wahrscheinlich größere Problem für OpenCL (oder DX11) stellt wohl eher dar, daß die Intelschen EUs nicht mit voller FP32-Genauigkeit rechnen können, zumindest würde ich diese Aussage bei Anandtech (http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i5-2600k-i5-2500k-and-core-i3-2100-tested/9) so interpretieren:
There’s also one more basic difference between code running on the CPU vs. integrated GPU. At least in Intel’s case, certain math operations can be performed with higher precision on Sandy Bridge’s SSE units vs. the GPU’s EUs.
Wahrscheinlich fehlen so ein oder zwei Bits am Ende für volle IEEE-Compliance. Damit schafft man dann kein OpenCL oder auch DX11, die das nämlich vorschreiben, wann wie genau gerechnet werden muß.

[DavidC1]

From Intel's datasheet about Sandy Bridge graphics, it says it only supports the Compute Shader function in DX11.

The Intel HD Graphics controller features the following:
• 3D Features
⎯ DirectX10.1* and OpenGL* 3.0 compliant
⎯ DirectX11* CS4.0 only compliant
⎯ Shader Model 4.0

[Gipsel]

From Intel's datasheet about Sandy Bridge graphics, it says it only supports the Compute Shader function in DX11.

The Intel HD Graphics controller features the following:
• 3D Features
⎯ DirectX10.1* and OpenGL* 3.0 compliant
⎯ DirectX11* CS4.0 only compliant
⎯ Shader Model 4.0
That's a bit strange. DX10.1 but only shader model 4.0? Doesn't DX10.1 requires SM4.1 support? And the CS4.x and CS5.0 profiles are only usable with DX11. DX10 doesn't know them even if they should map to most (but not all) DX10.x hardware. So that is as expected.

Edit:
Übrigens erfordert bereits DX10.1 eine höhere Präzision der Recheneinheiten (und beim Blending) als DX10.0:
•Floating Point Rules - Uses the same IEEE-754 rules for floating-point EXCEPT 32-bit floating point operations have been tightened to produce a result within 0.5 unit-last-place (0.5 ULP) of the infinitely precise result. This applies to addition, subtraction, and multiplication. (accuracy to 0.5 ULP for multiply, 1.0 ULP for reciprocal).
•Formats - The precision of float16 blending has increased to 0.5 ULP. Blending is also required for UNORM16/SNORM16/SNORM8 formats.

Edit2:
Intel claims SM4.1 support in the slide deck for the press (http://www.overclockers.at/content/sandy-bridge/Sandy-Bridge-Press-Deck-Presentation.pdf) (page 43).

[deekey777]

Wenn iGPU CS 4.0 unterstützt, so muss es etwas wie LDS haben.

[Gipsel]

Wenn iGPU CS 4.0 unterstützt, so muss es etwas wie LDS haben.Wie gesagt, für die Feature-Checkbox würde das Mappen im globalen Speicher reichen (was durch Nutzung des Caches dafür auch halbwegs performant gehen könnte). Aber dann wäre eigentlich auch gleich CS4.1 drin, da mit DX10.1 auch SM4.1 Pflicht ist. Ich frage mich wirklich ob das nur eine fehlerhafte Angabe seitens Intel ist oder an was es scheitert.
Was hat eigentlich OpenGL4.0, was man mit einer DX10.1-GPU nicht hinbekommt? Oder liegt die Unterstützung von lediglich OGL3.0 nur am Treiber?

[deekey777]

Wie gesagt, für die Feature-Checkbox würde das Mappen im globalen Speicher reichen (was durch Nutzung des Caches dafür auch halbwegs performant gehen könnte). Aber dann wäre eigentlich auch gleich CS4.1 drin, da mit DX10.1 auch SM4.1 Pflicht ist. Ich frage mich wirklich ob das nur eine fehlerhafte Angabe seitens Intel ist oder an was es scheitert.
Was hat eigentlich OpenGL4.0, was man mit einer DX10.1-GPU nicht hinbekommt? Oder liegt die Unterstützung von lediglich OGL3.0 nur am Treiber?
Wenn ich mich nicht irre, ist da DirectX deutlich strenger als OpenCL: Kein LDS/Shared Memory = kein Compute Shader. Siehe kleinere HD4000, die kein LDS haben.

[Gipsel]

Siehe kleinere HD4000, die kein LDS haben.Seit wann denn das? Wenn Du damit nicht die HD4200 IGP meinst (die praktisch RV610 sind), findet sich in den mir bekannten Dokumentationen nichts dazu. Laut denen haben alle GPUs der R700-Generation einen LDS. Auch der CAL-Layer liefert entsprechende Informationen zurück:

Geräteeigenschaften:
Gerätename RV710
GPU Takt 600 MHz
SIMDs 2
UAVs 1
Shader Engines 1
Max Resource 1D Width 8192
Max Resource 2D Width / Height 8192 / 8192
Wavefront Size 32
Pitch Alignment 256 elements
Surface Alignment 4096 Bytes
CAL Version 1.4.696
CAL DLL aticalrt.dll (6.14.10.696)

Speichereigenschaften:
Speichertakt 400 MHz
Total / Free Local Memory 512 MB / 480 MB
Total / Free Uncached Remote Memory 1855 MB / 1838 MB
Total / Free Cached Remote Memory 1855 MB / 1839 MB

Gerät Besonderheiten:
Compute Shader Unterstützt
3D ProgramGrid Nicht unterstützt
Double-Precision Floating-Point Nicht unterstützt
Global Data Share Nicht unterstützt
Global GPR Unterstützt
Local Data Share Unterstützt
Memory Export Unterstützt

CAL Erweiterungen:
CAL/D3D9 Interaction Unterstützt
CAL/D3D10 Interaction Unterstützt
CAL/OpenGL Interaction Nicht unterstützt
CAL Counters Unterstützt
Compute Shader Unterstützt
Create Resource Unterstützt
Domain Parameters Unterstützt

[deekey777]

Hoffenlich habe ich das eine Posting im B3DF richtig in Erinnerung, leider habe ich es bisher nicht gefunden: Dort hieß es, dass DirectCompute deutlich restriktiver ist als OpenCL und so etwas wie Auslagerung auf Global-Memory nicht möglich ist, womit CS 4.1 nur auf HD4700/4800 möglich ist; auch steht in der Readme zu 9.12, dass nur HD4800/4700 DirectCompute kompatibel sind.

[Gipsel]

auch steht in der Readme zu 9.12, dass nur HD4800/4700 DirectCompute kompatibel sind.
In den Readmes so ziemlich aller Stream-SDKs (vor 2.1 oder so) stand auch nicht drin, daß was anderes als HD4700/HD4800 unterstützt wird. Trotzdem lief es praktisch auf allen kleineren auch. War halt bloß keine offizielle Unterstützung. Wenn CAL sagt, daß RV710 einen LDS hat, wird das schon so sein ;)

[deekey777]

Was sagt denn CLinfo zB bei einer HD4500?
Edit: Bestimmt das gleiche wie bei einer HD4800.
Noch einfache wäre, wenn jemand die CS-Tests aus SiSoft Sandra auf einer kleinen HD4000 laufen lässt.
Compute Shader sind die IL-Computeshader, wenn mich nicht alles täuscht, die mit dem RV770 und dem entsprechenden SDK eingeführt wurden (Oktober 2008 glaube ich).

[Gipsel]

Compute Shader sind die IL-Computeshader, wenn mich nicht alles täuscht, die mit dem RV770 und dem entsprechenden SDK eingeführt wurden (Oktober 2008 glaube ich).
Und genau die kann auch eine RV710 (siehe CAL-Ausgabe zwei Posts vorher, das ist der Support für die IL-Computeshader, der da gemeldet wird), auch wenn die alten SDKs das nicht explizit erwähnen (da stehen immer nur die großen Karten drin, die kleinen werden gar nicht erwähnt, also auch nicht, daß sie es nicht unterstützen). In den ISA-Manuals steht allerdings z.B. drin, daß die HD4000 "family" LDS und compute shader unterstützt. Das ist auf jeden Fall eine andere Formulierung als z.B. bei double precision, wo explizit darauf verwiesen wird, daß nur einige Modelle das können.

Edit:
Aber Du hast Recht, eigenartigerweise erwähnen einige Release Notes (z.B. die des Cat10.7, über die ich gerade gestolpert bin), daß DX CS-Support auf RV740/770/790-Modelle beschränkt ist. Hmm.

[Coda]

ich meine die GPU als coprozessor. also wenn eine richtige grafikkarte im pc steckt. Es macht einfach keinen logischen sinn die igp mitzuschleppen und nicht zu nutzen.
Natürlich tut es das. Man hat weniger verschiedene Masken.

[deekey777]

Und genau die kann auch eine RV710 (siehe CAL-Ausgabe zwei Posts vorher, das ist der Support für die IL-Computeshader, der da gemeldet wird), auch wenn die alten SDKs das nicht explizit erwähnen (da stehen immer nur die großen Karten drin, die kleinen werden gar nicht erwähnt, also auch nicht, daß sie es nicht unterstützen). In den ISA-Manuals steht allerdings z.B. drin, daß die HD4000 "family" LDS und compute shader unterstützt. Das ist auf jeden Fall eine andere Formulierung als z.B. bei double precision, wo explizit darauf verwiesen wird, daß nur einige Modelle das können.

Edit:
Aber Du hast Recht, eigenartigerweise erwähnen einige Release Notes (z.B. die des Cat10.7, über die ich gerade gestolpert bin), daß DX CS-Support auf RV740/770/790-Modelle beschränkt ist. Hmm.
Ich bestreite gar nicht, dass RV710 IL-CS können.

[Gipsel]

Ich bestreite gar nicht, dass RV710 IL-CS können.
Dann stellt sich die Frage, warum die DX11 ComputeShader mit CS 4.0 oder CS4.1 Profil nicht gehen sollen. Da fällt mir erstmal nichts zu ein. Ideen?

[Coda]

Vielleicht einfach eine politische Entscheidung?

[=Floi=]

Natürlich tut es das. Man hat weniger verschiedene Masken.

bei ~20% mehr fläche und dem volumen welches intel umsetzt sollte eine maske nicht das problem sein. die fertigen auch nicht nur ein einer fabrik und brauchen von haus aus mehr masken.
ich denke weniger fläche sollte unterm strich günstiger kommen.

[Coda]

Du kannst davon ausgehen, dass Intel das schon sehr genau durchgerechnet hat.