Carrizo - volles HSA, UVD6/VCE3.1/ACP2, HDMI 2.0 - und: SOC, aber immernoch DDR3?
- Ersteller nazgul99
- Erstellt am
Pirx
Admiral Special
2GB sind "selbst" für diese Klasse heute schon zu wenig.
G
Gast11062015
Guest
was würde gegen 2gb HBM +2GB günstige verlötete ddr3 chips sprechen?
Und wer übernimmt die Entscheidung, wo welche Daten abgelegt werden sollen? Das könnte man dann entweder strikt trennen, was den HSA-Gedanken verletzen würde oder man nutzt HBM als LLC, was ich aber latenzmäßig kritisch sehen würde.
Das widerspricht eigentlich nicht dem HBM Gedanken, denn der Speicher sind für die Prozessoren nur Adressen, ob die Daten daraus schnell oder langsame aus dem RAM gelesen werden ist egal.
Das Entscheiden, wo die Daten landen, übernimmt das BIOS, indem es beim Systemstart den VRAM reserviert. Die GPU braucht ja nur die Bandbreite, um Daten darin zu cachen. Für reine CPU Workloads reicht DDR3 ja dicke. Falls Daten aus dem DDR3 von der GPU gelesen werden müssen, dann dauert es halt etwas länger, dürfte aber immer noch schneller sein, als bei dGPUs, wo alles über den PCIe geschickt werden muss.
Im allgemeinen müsste die Leistung der APU aber deutlich gesteigert werden können damit.
Das Entscheiden, wo die Daten landen, übernimmt das BIOS, indem es beim Systemstart den VRAM reserviert. Die GPU braucht ja nur die Bandbreite, um Daten darin zu cachen. Für reine CPU Workloads reicht DDR3 ja dicke. Falls Daten aus dem DDR3 von der GPU gelesen werden müssen, dann dauert es halt etwas länger, dürfte aber immer noch schneller sein, als bei dGPUs, wo alles über den PCIe geschickt werden muss.
Im allgemeinen müsste die Leistung der APU aber deutlich gesteigert werden können damit.
G
Gast11062015
Guest
das mein ich auch,
den zwischen 384 und 512shader merkt man nicht viel unterschied da limitiert der ram
den zwischen 384 und 512shader merkt man nicht viel unterschied da limitiert der ram
Complicated
Grand Admiral Special
Hängt davon ab ob die Tonga GPU derzeit noch als "Brandnew" gilt. Ich muss ehrlich sagen, dass AMD mit ihrer Sprache deutlich Marketin-orientierter geworden ist. Die Sprachregelung hat sich deutlich verbessert im Unternehmen...
G
Gast11062015
Guest
<----Arsch 8)
so mal sehe ob amd bereit ist weitere Details rauszurücken.
hab sie gerade mit dem Premium Acc. eines freundes kotaktiert
(Inhaber von 18x Fire W9100)
"normal sind sie da auskunfts freudiger wie z.b. vor dem Gcn release, damals noch mit 6990er"
1 woche später zog pcgh nach, und löschte meine thread, diese kinder ein.. ....
so mal sehe ob amd bereit ist weitere Details rauszurücken.
hab sie gerade mit dem Premium Acc. eines freundes kotaktiert
(Inhaber von 18x Fire W9100)
"normal sind sie da auskunfts freudiger wie z.b. vor dem Gcn release, damals noch mit 6990er"
1 woche später zog pcgh nach, und löschte meine thread, diese kinder ein.. ....
Zuletzt bearbeitet:
Unbekannter Krieger
Grand Admiral Special
Bitte? Ich verstehe nicht, was du uns mitteilen möchtest.
G
Gast11062015
Guest
ich auch nicht so ganz, sollte im rausch weniger schreiben
ich hab amd angeschrieben, weitere Details folgen in kürze
ich hab amd angeschrieben, weitere Details folgen in kürze
Unbekannter Krieger
Grand Admiral Special
Ich meine den letzten Satz von wegen "nachziehen".
G
Gast11062015
Guest
achso du meinst den scheiss mit pcgh ?!
ich hab damals weitere Details zu gcn geliefert,
per screenshot aus den mails mit amd als beweis.
ca. 6tage danach wurde mein thread gelöscht und die News wurde als pcgh eigene von unbekannter quelle ausgegeben,
klickgeile arschlöcher
sowas finde ich erbärmlich, aber normal recht so einen scheiß auch das Schicksal der anderen
------------------------------------------------------------------------------------------------------------
Aber hey sieh dir mal CB an jemand fragt ob sein NT für einen 9590 reicht, will nicht mehr wissen,
wird aber von kauf Intel xyz zugespamt.
sowas interessiert die newbie auf dauer auch nicht.
ich hab damals weitere Details zu gcn geliefert,
per screenshot aus den mails mit amd als beweis.
ca. 6tage danach wurde mein thread gelöscht und die News wurde als pcgh eigene von unbekannter quelle ausgegeben,
klickgeile arschlöcher
sowas finde ich erbärmlich, aber normal recht so einen scheiß auch das Schicksal der anderen
------------------------------------------------------------------------------------------------------------
Aber hey sieh dir mal CB an jemand fragt ob sein NT für einen 9590 reicht, will nicht mehr wissen,
wird aber von kauf Intel xyz zugespamt.
sowas interessiert die newbie auf dauer auch nicht.
Zuletzt bearbeitet:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/hsa10.pdf sagt folgendes:
3. Memory Model
3.1.Overview
A key architectural feature of HSA is its unified memory model. In the HSA memory model, a combined
latency/throughput application uses a single unified virtual address space. All HSA-accessible memory
regions are mapped into a single virtual address space to achieve Shared Virtual Memory (SVM)
semantics.
Memory regions shared between the LCU and TCU are coherent. This simplifies programming by
eliminating the need for explicit cache coherency management primitives, and it also enables finer-
grained offload and more efficient producer/consumer interaction. The major benefit from coherent
memory comes from eliminating explicit data movement and eliminating the need for explicit heavyweight
synchronization (flushing or cache invalidation). The support of existing programming models that
already use flushing and cache invalidation can also be supported, if needed.
3.2. Virtual Address Space
Not all memory regions need to be accessible by all compute units. For example:
• TCU work-item or work-group private memory need not be accessible to the LCUs. In fact, each work-
item or work-group has its own copy of private memory, all visible in the same virtual address space.
Private memory accesses from different work-items through the same pointer result in accesses to
different memory by each work-item; each work-item accesses its own copy of private memory. This is
similar to thread-local storage in CPU multi-threaded applications. Access to work-item or work-group
memory directly by address from another accessor is not supported in HSA.
• LCU OS kernel memory should not be accessible to the TCUs. The OS kernel must have ownership of
its own private data (process control blocks, scheduling, memory management), so it is to be expected
that TCUs should not have access to this memory. The OS kernel, however, may expose specific
regions of memory to the TCUs, as needed.
When a compute unit dereferences an inaccessible memory location, HSA requires the compute unit to
generate a protection fault. HSA supports full 64-bit virtual addresses, but currently physical addresses
are limited to 48 bits, which is consistent with modern 64-bit CPU architectures.
3.2.1. Virtual Memory Regions
HSA abstracts memory into the following virtual memory regions. All regions support atomic and
unaligned accesses.
• Global: accessible by all work-items and work-groups in all LCUs and TCUs. Global memory embodies the main advantage of the HSA unified memory model: it provides data sharing between CUs and TCUs.
• Group: accessible to all work-items in a work-group.
• Private: accessible to a single work-item.
• Kernarg: read-only memory used to pass arguments into a compute kernel.
• Readonly: global read-only memory.
• Spill: used for load and store register spills. This segment provides hints to the finalizer to allow it to generate better code.
• Arg: read-write memory used to pass arguments into and out of functions.
3.3.Memory Consistency and Synchronization
3.3.1. Latency Compute Unit Consistency
LCU consistency is being dictated by the host processor architecture. Different processor architectures
may have different memory consistency models, and it is not the scope of HSA to define these models.
HSA needs to operate, however, within the constraints of those models.
3.3.2.Work-item Load/Store Consistency
Memory operations within a single work-item to the same address are fully consistent and ordered. As a
consequence, a load executed after a store by the same work-item will never receive stale data, so no
fence operations are needed for single work-item consistency. Memory operations (loads / stores) at
different addresses, however, could be re-ordered by the implementation.
3.3.3. Memory Consistency across Multiple Work-Items
The consistency model across work-items in the same work-group, or work-items across work-groups,
follows a “relaxed consistency model”: from the viewpoint of the threads running on different compute
units, memory operations can be reordered.
• Loads can be reordered after loads.
• Loads can be reordered after stores.
• Stores can be reordered after stores.
• Stores can be reordered after loads.
• Atomics can be reordered with loads.
• Atomics can be reordered with stores.
This relaxed consistency model allows better performance. In cases where a stricter consistency model
is required, explicit fence operations or the use of the special load acquire (ld_acq) and store release
(st_rel) is needed.
Complicated
Grand Admiral Special
Und was soll das jetzt aussagen? Ich habe keine Ahnung was du damit sagen willst, mit dem langen Zitat aus dem hier jedem bekannten Whitepaper.
Der Poster auf den ich antwortete, kannte das Paper jedenfalls nicht.
Das Paper kannte ich zwar nicht, bzw. habs mit nicht durchgelesen, aber das Zitierte beschreibt auch nur die ganz normale Speicherverwaltung, wie sie mehr oder weniger in jeder Multithreaded Software genutzt wird und hat mMn. nichts mit dem von mir geschriebenen zu tun.
Richtung Software sieht der Zugriff gleich aus, allerdings können bestimmte Zugriffsmuster einiges an Performance kosten, weil plötzlich page faults kommen können wo bei "normalen" Cpus keine wären.
Zum Beispiel kann der HSA Scheduler entsprechende Speicher Bereiche in der MMU für die CPU auf page fault setzen, um weniger Coheränz zur GPU zu haben. Sobald der page fault kommt, kann das OS die entsprechenden pages auf stärkere Coheränz stellen.
Mit schlauer Programierung im OS kann die Bandbreite zum snoopen reduziert werden. Snoopen kostet auch Strom, weniger Coheränz = längerer Akku.
NVDimms könnten möglicherweise auch von HSA profitieren.
Zuletzt bearbeitet:
Complicated
Grand Admiral Special
Ah ok, ich glaube du bezogst dich auf diesen Teil mit deiner Antwort. Der Zusammenhang war für mich nicht klar.
Das stimmt so natürlich nicht. Besonders nicht, dass das BIOS den VRAM reserviert in HSA Systemen. Das widerspricht diesem Teil des Whitepapers insbesonders, den Meckel ja hervorgehoben hatte:
Wie man an den gelisteten möglichen Speichertypen sehen kann, wird das zur Laufzeit generiert. Sprich es wird kein fester VRAM zugewiesen bei Systemstart, sondern alle HSA Compute Units belegen den gesamten Speicher und deklarieren je nach Bedarf den Workload als privat oder global oder einen der anderen Typen. Dies kann vor allem zum Vorteil werden, wenn unterschiedlich angebundener Speicher zusammen adressiert werden soll, wie das ja z.B. wäre bei DDR3+HBM oder bei DDDR3+GDDR5 via PCIe (wenn GPU VRAM in den gesamten virtuellen Speicher integriert würde). Die Bandbreiten und Latenzen der Speicher unterscheiden sich ja deutlich, doch mit den Speichertypen kann der Workload auch dynamisch dem besten geeigneten zur Verfügung stehenden Speicher übergeben werden.
Möglicherweise wird dann aber doch zu memcopys im pagefault handler kommen, wenn z.b. LCU-Speicher an eine TCU übergeben wird. Für die Applikation bleibt das transparent.
Complicated
Grand Admiral Special
Soweit ich mich jetzt frei erinnere sind das Zerocopy Situationen (wenn selber physikalischer Speicher, oder auch bei remote RAM als Pointer?) - hab mich damit aber zu wenig eingelesen bisher zum pagefault handler.
Es geht um denn Fall das Daten für einen TCU Job zum Startzeitpunkt im normalen DDR3 RAM liegen, aber die Daten für die Laufzeit des TCU Jobs besser im HBM RAM mit zusätzlich weniger Coheränz aufgehoben wären.
Complicated
Grand Admiral Special
Ich denke in diesem Szenario gibt es drei Möglichkeiten. Daten im DDR3 belassen und mit LCU berechnen, Daten in HBM kopieren und mit TCU berechnen aber auch Daten im DDR3 belassen und mit TCU berechnen. Auch hier wird wohl on the fly entschieden welche Kombination schneller geht - wohl auch abhängig vom Parallelisierungsgrad der sehr hoch sein muss mit vielen Daten um das umkopieren lohnend zu machen. Wenn weniger Coheränz benötigt wird für die TCU müssten das typische GPGPU Berechnungen sein - dann lohnt es sich wohl.
Denkbar wäre vielleicht ein Zähler im TLB, der Zugriffe auf das "falsche RAM" zählt und beim Erreichen einer bestimten Zahl eine pagefault Exception auslöst, um den Rest kümmert sich dann das VM Subsystem im Kernel.
Evtl. wäre das auch ein interessantes Feature für NUMA Maschinen?
Zuletzt bearbeitet:
Complicated
Grand Admiral Special
Ähnliche Themen
