Wie sieht es mit HSA Unterstützung auf Intel und NVidia GPUs aus?
-
Also das da:
http://en.wikipedia.org/wiki/Heterogeneous_System_ArchitectureWas ist der aktuelle Stand der Dinge bezüglich der jeweiligen GPU Hersteller?
Unterstützt OpenGL das schon?
-
falls du dich damit auf den addressspace beziehst, war intel glaube ich die ersten deren igpu das konnte. nvidia's gpus bieten zugriff darauf seit CUDA4 (ca 2010 glaube ich).
der opengl standard bietet das nicht. du kannst bei nvidia ueber die persistent mapped buffers extension darauf zugreifen.
-
rapso schrieb:
falls du dich damit auf den addressspace beziehst, war intel glaube ich die ersten deren igpu das konnte. nvidia's gpus bieten zugriff darauf seit CUDA4 (ca 2010 glaube ich).
AMDs Kaverie kam doch erst 2014 heraus, wie kann das NVidia daher vorher gekonnt haben?
Genauso wurde auch AMDs Mantle erst 2014 veröffentlicht.der opengl standard bietet das nicht.
Ist da diesbezüglich etwas geplant?
-
HSA schrieb:
rapso schrieb:
falls du dich damit auf den addressspace beziehst, war intel glaube ich die ersten deren igpu das konnte. nvidia's gpus bieten zugriff darauf seit CUDA4 (ca 2010 glaube ich).
AMDs Kaverie kam doch erst 2014 heraus, wie kann das NVidia daher vorher gekonnt haben?
wieso sollte unified addressspace nicht vorher gemacht worden sein? (falls du dich darauf beziehst, falls du etwas anderes meinst, dann liste es auf. HSA selbst ist nur ein marketing name fuer mehrere technologieen).
Genauso wurde auch AMDs Mantle erst 2014 veröffentlicht.
2014 wurden viele dinge veroeffentlicht, das hat aber 0 relevanz zum thema.
der opengl standard bietet das nicht.
Ist da diesbezüglich etwas geplant?
ich denke du musst teil des opengl standardisierung kommites sein um ueber die planung zu erfahren/wissen.
-
rapso schrieb:
wieso sollte unified addressspace nicht vorher gemacht worden sein? (falls du dich darauf beziehst, falls du etwas anderes meinst, dann liste es auf. HSA selbst ist nur ein marketing name fuer mehrere technologieen).
Der verlinkte Wikipedia Artikel schreibt:
Heterogeneous System Architecture (HSA) is a type of computer processor architecture that integrates central processing units and graphics processors on the same bus, with shared memory and tasks. [...]relieving the programmer of the task of planning the moving of data between devices' disjoint memories (as must be done with OpenCL or CUDA).[4]
Das ist ein wenig mehr.
-
otze schrieb:
Das ist ein wenig mehr.
ich sehe kein weiteres hardware feature und ich gehe davon aus dass der threadstarter nach hardware support fragt (und nicht nach dem intermediate language compiler oder der task queueing runtime), weil
-er explizit GPUs ins topic schreibt
-weil ich ihm unterschlage faehig zu sein die liste der hersteller mit support der HSA api auf der hauptseite der HSA foundation selbst zu ergooglen und dort ist intel und nvidia nicht.uebersehe ich etwas?
-
Ich habe mich vor ein paar Wochen schonmal darueber informiert und es scheinen wohl erstmal nur die APUs unterstuetzt zu werden. Bis man Berechnungen auf die Grafikkarten mit ihren mehreren tflops auslagern kann, vergeht wohl noch Zeit.
OpenGl unterstuetzt es erstmal gar nicht. Vielleicht kommt mit OpenGl Next etwas in die Richtung, aber HSA ist erstmal fuer beschleunigte Berechnungen ausgelegt und OpenGls Shader laufen schon lange auf der GPU.
Auch sonst habe ich den Eindruck, dass Spiele gar nicht die Zielgruppe sind, sondern eher der Mobilbereich (energiesparender Hauptprozessor im Normalbetrieb + leistungsfaehige GPU fuer rechenintensive Anwendungen) und Profi-Anwendungen wie Photoshop. Ich weiss auch nicht, ob Spiele davon ueberhaupt viel profitieren wuerden, ausser vielleicht bei den Ladezeiten, den auch jetzt wird schon vieles so programmiert, dass die Rechenleistung der Grafikkarte der limitierende Faktor ist.
-
Marthog schrieb:
Ich habe mich vor ein paar Wochen schonmal darueber informiert und es scheinen wohl erstmal nur die APUs unterstuetzt zu werden. Bis man Berechnungen auf die Grafikkarten mit ihren mehreren tflops auslagern kann, vergeht wohl noch Zeit.
OpenGl unterstuetzt es erstmal gar nicht. Vielleicht kommt mit OpenGl Next etwas in die Richtung, aber HSA ist erstmal fuer beschleunigte Berechnungen ausgelegt und OpenGls Shader laufen schon lange auf der GPU.
Danke
Auch sonst habe ich den Eindruck, dass Spiele gar nicht die Zielgruppe sind, sondern eher der Mobilbereich (energiesparender Hauptprozessor im Normalbetrieb + leistungsfaehige GPU fuer rechenintensive Anwendungen) und Profi-Anwendungen wie Photoshop. Ich weiss auch nicht, ob Spiele davon ueberhaupt viel profitieren wuerden, ausser vielleicht bei den Ladezeiten, den auch jetzt wird schon vieles so programmiert, dass die Rechenleistung der Grafikkarte der limitierende Faktor ist.
Wie sieht es mit Physik-, KI- und Kollisionsberechnungen aus? Das wäre doch durchaus auch für Spiele von Vorteil.
Momentan ist es ja so, dass man im Worst Case Fall die Daten zwischen RAM der CPU zum VRAM der GPU hin und herkopieren muss und das kostet Zeit.
Würde man nur Adressen austauschen müssen, dann würde das recht fix gehen.
-
Wie ich sehe geht es dir wirklich um den unified address space.
HSA schrieb:
Wie sieht es mit Physik-, KI- und Kollisionsberechnungen aus? Das wäre doch durchaus auch für Spiele von Vorteil.
Momentan ist es ja so, dass man im Worst Case Fall die Daten zwischen RAM der CPU zum VRAM der GPU hin und herkopieren muss und das kostet Zeit.Man kann mit openCL und CUDA jetzt schon addressspace zwischen CPU und GPU sharen, das macht aber in seltennen faellen sinn, da dann zwei processoren einen speicherkontroller belasten und cache trashing etc. betreiben. Es ist oft effizienter den speicher zu kopieren.
aus CPU sicht bedeutet es eh dass die GPU alle daten im buffer mal lesen wird, alles am stueck lesen macht mehr sinn als ab und zu, denn das hat viel overhead.
aus GPU sicht bedeutet es dass daten im lokalen, schnellen, speicher sind, sie stallt also weniger als beim zugriff auf CPU memory. Das kopieren uebernehmen copy-units die einzig aus diesem grund verbaut werden. Diese haben zudem eine kleinere priority als CPU und GPU, die kopieren also zu allermeist wenn sonst der memory controller idle waere.
Würde man nur Adressen austauschen müssen, dann würde das recht fix gehen.
nur mit den addressen kannst du keine kollisionsberechnung machen. Du musst irgendwie die daten aus den CPU registern in die GPU register verschieben. das langsammste ist dabei PCIe.
-
rapso schrieb:
Man kann mit openCL und CUDA jetzt schon addressspace zwischen CPU und GPU sharen
Mit OpenCL 2 geht das und das ist eng mit HSA verwoben. Einmal haben die gleichen Firmen daran mitgearbeitet und zum anderen wird OpenCl zum Teil ueber HSA implementiert.
Soweit ich gehoert habe, ist unified memory in CUDA lediglich eine annehmlichkeit fuer den Pogrammierer und letztendlich kuemmert sich der Treiber um das rueberkopieren, also so dass es geschwindigkeitsmaessig keinen unterschied macht. Ich habe aber auch noch nie mit CUDA gearbeitet und es auch sobald nicht vor.
-
Marthog schrieb:
rapso schrieb:
Man kann mit openCL und CUDA jetzt schon addressspace zwischen CPU und GPU sharen
Mit OpenCL 2 geht das
auch openCL 1.0 bietet mittels CL_MEM_ALLOC_HOST_PTR die moeglichkeit opencl speicher zu allokieren der direkt von der CPU und GPU bearbeitet werden kann.
und das ist eng mit HSA verwoben. Einmal haben die gleichen Firmen daran mitgearbeitet
Nope: Intel und NVidia sind teil von OpenCL aber nicht von HSA.
und zum anderen wird OpenCl zum Teil ueber HSA implementiert.
zum teil ueber CUDA z.b. http://techreport.com/r.x/2008q4/cuda_arch.jpg
Intel implementiert es ueber deren driver, FPGA hersteller implementieren OpenCL ueber deren backend. vermutlich hat nur AMD (wenn ueberhaupt) OpenCL ueber HSA implementiert.Soweit ich gehoert habe, ist unified memory in CUDA lediglich eine annehmlichkeit fuer den Pogrammierer und letztendlich kuemmert sich der Treiber um das rueberkopieren, also so dass es geschwindigkeitsmaessig keinen unterschied macht. Ich habe aber auch noch nie mit CUDA gearbeitet und es auch sobald nicht vor.
Das kommt auf die hardware und cuda (runtime) version an. Manchmal wird das paging vom treiber gemacht, manchmal von der hardware. Aber das paging ist nicht das entscheidene, sondern dass der addressspace unified ist.
Auch mit HSA wird es noch synchronisationsarbeit geben. z.B. bedeutet unified address space noch lange nicht, dass caches coherent sind. Und wenn du HSA flags hast um speicher cache coherent zu markieren, heisst es ebenfalls noch lange nicht dass es waerend das tasks coherent ist (du kannst also nicht zwischen zwei tasks so einfach daten austauschen), sondern dass es cache flushes gibt vor/nach dem task wenn noetig.
Du kannst memory als non-cached angeben, aber auch das hat tuecken. so ist die schreibreihenfolge absolut nicht garantiert sofern du nicht atomics nutzt. kann also sein, dass dein atomic schon etwas signalisiert und die daten selbst noch nicht gespeichert wurden.Ich denke es wird nicht wirklich lange dauern bis die prozessor hersteller CPU und GPU zu einem verschmelzen. Es mag zwar sein, dass ein photoshop filter auf der GPU schneller laeuft, aber du hast dann trotzdem noch einen anderen riesen teil vom chip der idle ist, transistoren kostet und nichts macht.
Dabei unterscheiden sich CPUs und GPUs in sachen compute nicht mehr wirklich viel. ende des jahres kommt Intel Skylake, der hat 512bit breite register (16float) das ist zufaellig auch die groesses die NVidia's GPUs als registerbreite nutzen. Alle operationen die die GPU fuer GPGPU kann, kann die vector unit von intel dann auch (z.B. scatter/gather/lane-masking). und nun hast du 4 Cores (oder mehr) die solche monster verbaut haben, ~ 512GFlops und du hast eine GPU die 500-1000GFlops hat. welchen teil moechtest du dafuer ungenutzt lassen? oder moechtest du CPU und GPU denselben task abarbeiten lassen damit der memory controller durcheinander ist?
Ich hoffe dir ist dann auch klar, dass du fuer beide architekturen optimieren musst. einfach nur einen generischen task schreiben und laufen lassen wird dir auf GPUs locker mal 3% der moeglichen performance geben. siehe z.B. http://developer.download.nvidia.com/compute/cuda/1.1-Beta/x86_website/projects/reduction/doc/reduction.pdfum das beste rauszukratzen, gerade bei GPUs, musst du ganz genau wissen was und wie. dabei wird einer GPU etwas gut tun was einer anderen schaden wird. Einfach nur HSA intermediate language und unified task queue wird dich nicht gluecklich machen.
