Ja das stimmt, eine GPU rechnet nicht schneller dank HSA. Man kann aber durch HSA einfacher als Programmierer die Ressourcen nutzen. Es wird kein Overhead für das Ansprechen mit OpenGL/DirektX/Cuda und auch keine Zeit durch kopieren von Daten in die entsprechenden Adressräume "verschwendet", sondern die GPU zählt fast als zusätzlicher Kern.
Da gebe ich dir natürlich recht. Es macht aber irgendwie eher den Eindruck, als würden die Leute hier davon ausgehen, das wenn HSA drauf steht, auf einmal auch alles irgendwie schneller wird. -> und hier versuche ich eben einzuhaken. Ohne Zutun wird da nicht viel passieren. Da die Software sowie die Hardware lange noch nicht soweit ist, "selbstständig" sowas zu beschleunigen.
Das ganze in Hardware würde große Änderungen am Decoder verlangen und das größte Problem wird sein, dass der Decoder ein "dummes" Stück Hardware ist, dass nicht weiß, ob ein Code abschnitt gut parallelisierbar ist oder nicht. Bzw. weiß er nicht mal, welcher Befehl als nächstes kommen wird geschweige denn eine realtime Codeanalyse ausführen kann.
Für HSA wird man vermutlich immer einen angepassten Compiler verwenden müssen, der sagen kann, ob sich der Codeabschnitt lohnt auf der GPU auszuführen oder nicht und zusätzlich dazu hat der Programmierer noch die Möglichkeit selbst mittels OpenCL etc. auf die GPU bzw. mit C++ AMP sogar direkt zuzugreifen.
Ich denke hier wird sich zeigen, wohin sich die Software entwickeln wird. Ich sehe potentiell aber erstmal das kleinere Problem, das AMD eben nicht ganz in der Marktstellung ist, sowas auf biegen und brechen durchzudrücken, schon gleich dann nicht, wenn Intel da nicht mitspielt. -> ich mein, machen können die ja viel. Ob die Programmiererschaft es annimmt und drauf aufbaut, steht aber auf einem ganz anderen Blatt.
Aber im Endresultat will doch AMD quasi diese "unter der Decke" Version irgendwie auf die Beine stellen. Ob man dann den Code durch nen speziellen Compiler jagen muss, oder wie auch immer das schlussendlich mal ausschauen wird, steht zumindest aus meiner Sicht noch etwas in den Sternen. Und auch aus diesem Grund bin ich eher skeptisch solchen "elementaren" Änderungen gegenüber. Da ich durchaus einschätzen kann, das der Softwaremarkt sehr sehr träge agiert
Zum Thema die GPU hat was besseres zu tun: Bei den beiden Consolen werden meines Wissens spezielle Ausführungseinheiten für das ganze Computing integriert sein, die unabhängig von der GPU Last agieren. Wie das später mit Kaveri im Desktop aussieht weiß ich nicht, aber auch hier werden sich ein paar Ressourcen finden, da eine GPU nie zu 100% Ausgelastet ist. Und wenn man von einem Highend gamingrechner ausgeht, dann wird die iGPU nur zum berechnen (KI/Physik) und die dGPU zur Anzeige des Spiels verwendet. Und bei 2D kram ist hat die GPU sowieso nichts zu tun.
Gibts dazu irgendwelche Infos? Klingt ja erstmal nicht verkehrt...
Würde dann aber wiederum den Konzept wohl etwas im Wege stehen... Zumindest dem aktuellen Plan, die GPU zur Beschleunigung ranzuziehen. Geht man den Weg auf nochmals dedizierte andere Einheiten (ich hörte irgendwie in Verbindung mit ARM irgendwas, aber ich glaube nicht auf die Konsole bezogen), hätte man ja nochmal ein ganz anderes Konstrukt.
Ansonsten wie gesagt, ein Verkaufsargument bei den APUs sind ja die hohe GPU Leistung. Und man verkauft das direkt auf Games bezogen... Schmeißt mit Benches um sich usw.
Die GPU dann noch mit Berechnungen löchern, die eigentlich auf der CPU hätten berechnet werden sollen und somit die GPU Leistung abermals etwas drücken, halte ich für ungünstig.
Zumindest wenn die Games da überhaupt irgendwann mitmachen. Denn machen sie das nicht, bringt das ganze auch in Games nichts greifbares
hab ich hsa jetzt nicht verstanden, oder du?
wenn ich als cpu speicheradressen mit der gpu teile, entfällt doch das nervige daten hin und her geschiebe vom ram in den vram, oder nicht?
ich weiss, dass man davon ausgeht, das pcie3 von der speicherbandbreite noch lange nicht ausgeschöpft ist. aber wenn mit hsa die cpu direkt in den vram schreiben kann, hört sich das doch sehr nach performance gewinn an.
auch bezweifle ich, dass hsa nur etwas mit opencl oder "cuda" zu tun haben könnte. es wird sich tatsächlich auf den betrieb einer gpu im klassischen sinn, als 3d beschleuniger, positiv auswirken. es geht nicht darum die gpu mit irgendwas anderem zu beschäftigen, sondern um wege (ram->cpu->pcie->vram->gpu) so kurz wie möglich zu halten.
Neja, ansich ist das schon so. (du meinst aber wohl denke ich hUMA)...
Aber dennoch halte ich stand heute den Performancevorteil durch etwaiges Enfallen der Datentransfers für äußerst gering. Zumindest beim Thema Games bezogen... Da eben nicht ständig riesige Texturedatenmengen hin und her geschaufelt werden müssen. Sondern das aus meiner Sicht eher "selten" passiert. Denn alles was im VRAM drin ist, ist schnell zugreifbar. Da kann hUMA nichts mehr Beschleunigen. Oben siehst du die Ausführungen zu Skyrim. Der VRAM Datenbestand ändert sich wärend des Spielens genau dann essentiell, wenn du nen Ladescreen zu Gesicht bekommst oder wenn der VRAM voll ist. Nur beim Laden kannst du sowieso nix machen. -> ergo interessiert die FPS Leistung wärend der Ladephase auch nicht sonderlich. Ist das Laden durch, ist auch ein Größteil der benötigten VRAM Daten eben im VRAM zu finden.
Klassische Nachladeruckler mit wirklichen FPS Aussätzern (die genau von solchen Transfers kommen!) gibts heute eher selten (bei massiv zu wenig VRAM). -> Diese würde man durch hUMA weitestgehend eliminieren, zumindest wenn die Daten schon im RAM liegen.
Da diese aber heute eher selten bis gar nicht auftreten, fällt auch dieser Vorteil weg.
Unterm Strich bleibt sowas, wie why_me schon sagte. Programme, die dediziert die GPU ansprechend und mit Daten arbeiten, die von einem "CPU Programm" kommen.
An der Geschichte gibts aber Stand heute nicht wirklich viel Software, die überhaupt die GPU ansprechen kann und andererseits ist es alles eine Frage der Aufwandsabschätzung. Als Programmierer muss man stand heute wohl zweigleisig fahren. Dazu kommt die ganze Vielfalt von Schnittstellen usw. Das könnte Aufwand sein, der abschreckt. Speziell für Programmierer, die mal einfach fix ne Idee in irgend ner Weise umsetzen wollen.
Wenn ich mir beispielsweise ansehe, wie viele Tools und Programme ich auf meinen Arbeitsnotebook installiert habe, kann ich die, welche die GPU überhaupt erstmal ansprechen können, an einer Hand abzählen -> und brauch dabei wohl nichtmal alle Finger. All die anderen Programme werden durch HSA so gar keinen Vorteil haben.
@fdsonne
Den Schalter kenne ich selbst, bringt sogar in manchen Spielen wenige % an CPU-Leistung. Was ich mit dem Xeon vergleich ausdrücken möchte: Echte Kerne (oder Module) und echte Threads sind durch SMT nicht ersetzbar, deshalb ist der i7 im PCGH Artikel etwas stärker eingeknickt als der FX 8350 trotz höherer IPC pro Kern.
Nur soll eben SMT auch dafür nicht da sein!?
SMT soll für mehr Auslastung der Einheiten sorgen. Das heist, es liegen weniger Teile der CPU brach als ohne SMT. Im Optimalfall braucht man kein SMT, wenn der Code so derart gut programmiert ist, das NULL Leerlauf entsteht. -> das kommt faktisch aber sogut wie gar nicht vor. Und so erzeugt SMT in nahezu allen Fällen etwas mehr Performance durch höhere Last.
Simples Beispiel:
Das ist wie wenn du sagst, du fährst ein Auto mit vier echten Sitzen und vier Notsitzen.
Und vergleichst dieses gegen ein Auto mit sechs echten Sitzen, aber ausgebauten Notsitzen.
Wärend der erste Wagen bei acht Personen deutlich mehr zu transportieren hat, hätte der andere potentiell noch "Luft"...
Huma ist zwar Bestandteil von HSA, aber nur der geteilte Adressraum. Dadurch findet nicht zwingend zwingend GPU-Computing statt. Zumal ich bezweifeln möchte, dass HSA-Konzepte in Spielen groß Anwendung finden werden. Die GPU ist da schon damit beschäftigt ein Bild in HD mit Konstanten FPS aufs Bild zu buttern, wo sollen da die Ressourcen herkommen um die CPU noch massiv zu entlasten? Irgendwie habe ich das Gefühl du hast wirklich zu viele HSA-Werbe-Folien geguckt, ist nicht böse gemeint, aber das was du hier schreibst deckt sich nicht wirklich mit dem Ist-zustand.
. Kann einfach simuliert werden, weil der Grafikspeicher variabel einstellbar ist:
