News Erste Lebenszeichen von AMDs Fiji-Grafikkarte

Nai schrieb:
Jemineh; dein Post stößt mir relativ sauer auf,
Mir deiner auch
[Quoteda du den Programmierern unrecht tust.[/Quote]
Nein, er zeigt ein Problem auf
Denn das Optimieren ist selbst für gute Programmierer hauptsächlich eine zeitfrage, gerade da GPU Programmierung und Optimierung sowieso ein Gefriggel für sich ist. Will man ein GPU-Programm performant haben, so kostet das hauptsächlich viel Zeit und damit Geld. Und wieso sollte man das aufwenden, wenn das Programm bereits schnell genug auf moderner Hardware läuft?
Weil es ein Qualitätsmerkmal ist? Weil der Kunde für das bezahlt?
Schonend mit Ressourcen umgehen, wozu? Der Kunde hat ja die Software gekauft und schon wenigstens einmal benutzt.
Rückgabe nicht möglich. Da lacht sich der Entwickler ins Fäustchen. Im Zweifel macht man dann die klitsche dicht und eröffnet eine neue.

Aber stell dir vor du rufst nen Klempner. Er soll dir eine Abwasserleitung neu verlegen zB dem Klo.
Dem ist aber ein Wand/Decken Durchbruch zu umständlich. Kostet Zeit und Werkzeug kostet Geld.
Stattdessen legt er dir die Ableitung vom Klo durch den Flur, die Treppe runter und eben dann ins Waschbecken von der Küche.
Funktioniert schließlich auch. Und hast ja zwei gesunde Beine un drüber zu klettern, musst halt nur mehr Kraft anwenden als wenn du freie Bahn hast.
Und die Kacke schwimmt halt ne zeitlang in deiner Spüle.
Aber hey, der Klempner hat versprochen irgendwann nochmal vorbeizukommen, sogar gratis, und behebt das Problem das die Kacke in der Spüle schwimmt.

So gestalten Ptogrammierer ihre Arbeit oft, und der Kunde soll damit leben. Dem Klempner würdest du wohl den Vogel zeigen
 
wer optimiert heutzutage noch etwas selbst?
bei HSA muß man es auch nur ganz normal durch den kompiler jagen.
 
Aber stell dir vor du rufst nen Klempner. Er soll dir eine Abwasserleitung neu verlegen zB dem Klo.
Dem ist aber ein Wand/Decken Durchbruch zu umständlich. Kostet Zeit und Werkzeug kostet Geld.
Stattdessen legt er dir die Ableitung vom Klo durch den Flur, die Treppe runter und eben dann ins Waschbecken von der Küche.
Funktioniert schließlich auch. Und hast ja zwei gesunde Beine un drüber zu klettern, musst halt nur mehr Kraft anwenden als wenn du freie Bahn hast.
Und die Kacke schwimmt halt ne zeitlang in deiner Spüle.
Aber hey, der Klempner hat versprochen irgendwann nochmal vorbeizukommen, sogar gratis, und behebt das Problem das die Kacke in der Spüle schwimmt.

Du vergleichst hier eine persönliche Dienstleistung mit einem Massenprodukt. Was würdest du machen wenn der Klempner dir sagen würde:" Also ich kann die Heißwasserleitung zwischen Durchlauferhitzer und Waschbecken auch besser mit moderem Hightechisoliermaterial isolieren. Dieses müsste ich schichtweise herumwickeln was mir sehr viel Zeit kostet. Dann kommt das Wasser allerdings 0.5 ° C heißer raus. Das würde dich insgesamt 5000 € mehr kosten." Würdest du da noch zustimmen? Ähnlich verhält es sich mit der Optimierung im Spielen, nur dass man hier den Preis für die Kundschaft selbst festlegen muss . Ja man kann mehr Zeit aufwenden. Aber dann würde das Spiel bei einer konstanten Anzahl an Käufern nicht mehr 50 € sondern eben 70 € kosten. Die Anzahl kann man dann aber wegen des höheren Preises nicht mehr erreichen.


in zeiten von HSA nicht mehr nötig!
wer optimiert heutzutage noch etwas selbst?
bei HSA muß man es auch nur ganz normal durch den kompiler jagen.
Jemmineh. Das Optimieren bei GPU-Programmierung nimmt einem KEIN Compiler der Welt ab. Es gibt nicht umsonst 100te von Optimierungstechniken mit wissenschaftlichen Veröffentlichungen bei der GPU-Programmierung. Diese existieren sowohl in Massen nur für das klassische Rendering, als auch für modernes GPGPU. Viele der Optimierungen sind zudem problemspezifisch (E.G. bei einer Flüssigkeitssimulation kannst du dieses und dieses verbessern um x prozent mehr Performance zu haben). Einige Optimierungsansätze kannst du zum Beispiel hier lesen:
http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/#axzz3ItRmitaC
http://gamedev.stackexchange.com/qu...ization-techniques-for-the-geometry-pass-in-a
http://de.slideshare.net/DevCentral...mization-for-nextgen-and-dx11-by-emil-persson
 
Zuletzt bearbeitet:
auch ohne selbst optimieren kann man die GPU nutzen, ist immer noch besser als nur die CPU zu nutzen...
 
Irgendwie ist es hier wieder wie im Kindergarten...

AMD User: Mimimi, Nvidia ist alles scheiße, viel zu teuer, scheiß P/L, und die AMD R9 3xx schlägt die GTX980 eh locker
Nvidia User: Mimimi, AMD ist totaler dreck, billig aber total heiß, die AMD R9 3xx wird NIE an die GTX980 rankommen.

Merkt ihr nicht mal langsam, das es nicht DIE ultimative Karte gibt, und jeder subjektiv das für sich anders beurteilt.
Ich habe jetzt 4 Jahre lang eine HD 5770 genutzt, die keine großen Probleme gemacht hat, gehe jetzt aber dennoch mal wieder zu Nvidia (GTX760). Und? Who chares?

Man sollte vielleicht mal allgemein damit beginnen einfach zu akzeptieren das der eine eben AMD bevorzugt, und der andere eben Nvidia, und wieder anderen ist es egal ob die Karte nun grün oder rot ist.
Dafür sprechen auch die Stabilen Marktanteile seit Jahren, AMD immer um die 37% und Nvidia um die 63%.
http://de.statista.com/statistik/da...rafikkarten-weltweit-seit-dem-3-quartal-2010/

Man wird weder die AMD Nutzer von Nvidia überzeugen können, noch die Nvidia Nutzer von AMD.
Jeder soll einfach das nehmen womit er glücklich wird, oder ist das schlimm? :freak:
 
Zuletzt bearbeitet:
Krethi & Plethi schrieb:
in zeiten von HSA nicht mehr nötig!
+ weitere Postings

du disqualifizierst dich gerne oder? An Code-Optimierung ändert auch HSA nichts. In welcher Milchmädchenwelt lebst du?

Es ist und bleibt wie Nai sagt. Ein Zeit und damit Geld Thema. Ohnehin ist Nai einer der in der Qualität seiner Beiträge sicher 99% hier weit hinter sich lässt und auch wirklich Ahnung von der Materie hat ;)
Sowas ist hier leider selten...

@Topic.

Vielleicht werden es ja 16nm gepaart mit HBM.
http://www.sisoftware.eu/rank2011d/...dbe6deeddaeed6f082bf8fa9cca994a482f1ccf4&l=de

ist durchaus interessant. Sofern 3520 SP wirklich von einer AMD Karte kommen mit nem SingleChip könnte das sogar noch gut ein 28nm Chip sein.

Edit:
http://www.sisoftware.eu/rank2011d/...dbe6deedd4e7d3f587ba8aacc9ac91a187f4c9f9&l=en

wobei das (4096 SP) wiederum bei 28nm schon knapp wird. Könnte in der Tat ein Fuji sein. In 28nm wäre das etwa so groß wie der GK110 würde ich annehmen. Bei dem Takt kaum möglich.
 
Zuletzt bearbeitet:
Ja klar kostet es Geld.
Na und?
Wir zahlen ja auch Laenge mal Breite Geld fuer das Produkt.

Aber entspricht dem Bild, das ich von Spiele und Programmentwicklern habe.

1. So schnell wie moeglich hinrotzen, Zeit ist Geld.
2. Jedes weitere Feature extra verkaufen.
3. Bugs ausbessern nur, wenn der Druck der Kunden unangenehm wird.

Dass der Kunde dann ein qualitativ minderwertiges Produkt kauft, und noch dazu teurere Hardware braucht um das ganze zum Laufen zu bekommen, kann dem Entwickler aber egal sein. Immerhin wurde ihr Produkt schon verkauft.

Wenn Friseure so arbeiten wuerden wie Programmierer, dann wuerden sie mit dem Bunsenbrenner Haare entfernen. Geht am schnellsten! Alles andere ist ja unwichtig!

Edit: Ja schau. Ubisofts Aktienkurs ist um 10% eingebrochen, nachdem sie ihren neuesten Misthaufen released haben. Anscheinend zuviel Bugs fuer die leidgeprueften Opfer .... aehm Kaeufer.
 
Zuletzt bearbeitet von einem Moderator:
Ja klar kostet es Geld.
Na und?
Wir zahlen ja auch Laenge mal Breite Geld fuer das Produkt.
Du zahlst in etwa so viel Geld, dass die Entwicklungskosten über alle Käufer gesehen wieder reinkommen. Hoher Gewinn fällt bei der Spieleprogrammierung selten ab. Betrachtet man sich die Gewinnzahlen von den meisten Publishern und Entwicklern, so stellt man fest, dass die ganze Spieleentwicklung meist ein Nullsummenspiel ist. Siehe zum Beispiel:
http://www.finanzen.net/bilanz_guv/Electronic_Arts
Zudem hat so ein Spieleprogrammierer nur eins bis zwei große Projekte am Laufen. Ein einziger Fehlschlag kann ausreichen, um die gesamte Firma zu ruinieren. Deshalb ist die Entwicklung extrem Risiko reich. Man schaue sich nur die Spieleentwickler an, die es vor 10 Jahren mal gab. Die meisten davon gibt es heute nicht mehr.

Aber entspricht dem Bild, das ich von Spiele und Programmentwicklern habe.

1. So schnell wie moeglich hinrotzen, Zeit ist Geld.
2. Jedes weitere Feature extra verkaufen.
3. Bugs ausbessern nur, wenn der Druck der Kunden unangenehm wird.

Hier wird einiges zusammengeworfen. In der Spieleprogrammierung sind mehrere Bereiche beteiligt:
-Geldgeber (Banken, Aktionäre oder Publisher): Geben den Entwicklern selbst Geld, wollen aber in gegebener Zeit ein Ergebnis sehen oder es zurück haben. Wenn nicht, dann ziehen sie vor Gericht.
-Wirtschaftsabteilung (meist Teil des Publishers) in Kombination mit der Projektleitung: Beide versuchen das ganze finanziell *irgendwie* zu managen. Dabei sind sie an die Wünschen und Fristen der Geldgeber gebunden. Wollen die Geldgeber, dass das Spiel zu einem bestimmten Zeitpunkt releast wird, dann haben beide keine andere Wahl außer dem Folge zu leisten. Auch muss ein verfrühter Release statt finden, wenn die Geldmittel ausgehen. Alternativ kann die Projektleitung alle Angestellten entlassen, ihre Firma dicht machen, und eventuell sich noch mit Schadensersatzklagen der Geldgeber beschäftigen. Auch bestimmt die Wirtschaftabteilung und die Projektleitung das Bezahlungsmodell des Spiels, wie DLCs oder Mikrotransaktionen. Würdest du als Wirtschaftler oder Projektleitung, wenn du deine geliebte Firma inklusive Mitarbeitern *irgendwie* am Leben halten willst, nicht auch versuchen umfangslose oder herausgeschnittene Sachen als DLCs zu verkaufen, um noch *irgendwie* in die Gewinnzohne zu rutschen damit du wieder deine Schulden zurückzahlen kannst? Da kann man noch so hohe moralische Standards haben - um zu überleben tut man so einiges.
-Spieleprogrammierer und Spieledesginer: Beide stehen ganz unten in der Hierarchie. Sie sind zudem hoch spezialisiert und verstehen ihr Handwerk sehr gut. Denn wenn man 5 Tage die Woche sich immer mit dem selben, wie KI-Programmierung oder Graphikprogrammierung, beschäftigt, dann beherrscht jeder das nach etwas längerer Zeit auf einem professnonellem Niveau. Allerdings sind sie bei ihrer Arbeit an die Fristen ihrer Projektleitung gebunden. Reicht die Zeit nicht aus, was am Schluss der Entwicklungszeit heutzutage meist standard ist, so hat der Arbeitstag für diese Menschen 24 Stunden und eine Nacht. Da kann man so gut sein wie man will, wenn die Zeit zu knapp ist, dann reicht sie dennoch nicht, damit man alle Fehler fixen und das Spiel gut optimieren kann. Eben deshalb besitzen Spiele zum Release noch viele Fehler.

Was ich damit sagen will: Die Programmierer in der Spieleentwicklung sind sehr gut. Lediglich die äußeren und finanziellen Umstände führen dazu, dass Spiele so verkauft werden, wie sie verkauft werden.

Wenn Friseure so arbeiten wuerden wie Programmierer, dann wuerden sie mit dem Bunsenbrenner Haare entfernen. Geht am schnellsten! Alles andere ist ja unwichtig!
Was sagte ich in meinem letzten Post noch einmal über Vergleich zwischen einem Produkt für den Massenmarkt und persönlicher Dienstleistung? Ich komme mir unverstanden vor. :(
 
Zuletzt bearbeitet:
Krautmaster schrieb:
Ohnehin ist Nai einer der in der Qualität seiner Beiträge sicher 99% hier weit hinter sich lässt und auch wirklich Ahnung von der Materie hat ;)
Sowas ist hier leider selten...

Und dein Kommentar ist ein Gütesiegel für Nai:D ?

Was das HSA zeugs angeht. Will in die Richtung nichts dazu sagen. Aber falls der Compiler laut K&P die Aufgaben erledigen soll, bleibt es eben die Aufgabe eines anderen Programmierer, nämlich den, der den Compiler entwickelt xD

Aber so unrealistisch ist das nicht, immerhin wurde HSA in Zusammenhang mit Mantle und auch Spielen bereits erwähnt.

Und K&P Aussage war wohl eher die. Wenn ich ein etwas in einer Hochsprache Programmiere, dann wird eine HSA fähige Hardware selbst entscheiden was für die GPU oder CPU ist.
Nai hat aber nicht von einer Hochsprache gesprochen, sondern davon, wenn man direkt eine GPU, dessen Register ect programmiert.
Klar wird das dann aufwendig, aber dafür gibt es ja auch Schnittstellen, Engine ect.

Spieleentwickler beginnen ja auch nicht immer von Null. Man kann also eine gewisse Optimierung je nach Spiel durchaus verlangen.
Heute setzten viele Pubisher/Entwickler offensichtlich eher auf eine teure Engine, wo man sich dann selbst um nichts mehr kümmern muss. Quasi wie ein Editor einfach alles zusammenbasteln, die Engine bestimmt dann die Möglichkeiten und Umsetzung.
Weiterentwicklungen sind dann eben Aufgabe, der jeweiligen Engine-Entwickler. Eventuell wird aber noch etwas hinzugefügt, was für das Spielprinzip wichtig ist.

Das ist wohl auch der Grund, wieso wir fast immer nur die selben Games sehen, die sich kaum unterscheiden. Activsion hat es ja mit COD super vorgezeigt.

Ist übrigens mein Eindruck, kann mich natürlich irren ^^
 
Zuletzt bearbeitet:
Ulukay schrieb:
Dass der Kunde dann ein qualitativ minderwertiges Produkt kauft, und noch dazu teurere Hardware braucht um das ganze zum Laufen zu bekommen, kann dem Entwickler aber egal sein. Immerhin wurde ihr Produkt schon verkauft.

Du hast den Schlüssel selbst benannt - der Kunde. Kauft er wie bei Egosoft jahrelang die giftgrüne Banane (X-Serie) und schaut dann dankbar zu wie sie unendlich langsam heran reift dann hat der Hersteller alles richtig gemacht. Er kann schneller liefern als die Konkurrenz und billiger liefern als die Konkurrenz. Weigert er sich die noch nicht einmal giftgrüne Banane auch nur mit dem Arsch anzuschauen (X-Rebirth anyone?) dann kann er den Sondermüll höchstens am Grabbeltisch verramschen und muß sich mittelfristig mal mit den dem Thema "Konkurs" vertraut machen.

WIR haben das in der Hand. DIE sind nicht unsere Herren sondern tanzen nach unserer Pfeife. Leider nicht immer nach meiner Pfeife, aber das Gesamtkonzert bewegt was.

Ich habe Egosoft (aus den besagten Gründen) ebenso wie Ubisoft (nach dem völlig verschissenen GR FS für die XBOX360) auf meiner internen Sperrliste der Kategorie "eher taut die Hölle dreimal wieder auf bevor ich nochmal auf diese Abzocker reinfalle". Wenn genügend andere folgen würden würde das Beispiel andere Abzocker abschrecken.
 
@ AMD-Mafiosi

Wenn einer hier keine Ahnung hat, dann bist doch DU das.

Momentanzustand (Leistung) messtechnisch erfassen bei Schaltungen, die im GHz Bereich takten? Soll ich lachen oder weinen? Geht technisch nicht, interessiert auch nicht. Was glaubst du denn, was dein Stromzähler im Haus erfasst?

Ich: Diplom-Ingenieur Elektrotechnik (Nachrichten- und Informationstechnik), jahrelang Messungen an hochfrequenztechnischen Systemen gemacht.
Ich: Zweites Staatsexamen als Lehrer für Elektrotechnik und Physik

Und DU? Was sind deine Qualifikationen, dass du glaubst hier mitreden zu können?


DU kannst glauben, was du willst. Ich weiß, wovon ich rede.


Und deine Fanboy-Diskretitierung kannst du getrost stecken lassen. Als ich jung war, gab es sowas nicht, und im Alter werde ich sicherlich nicht mit so einem Scheiß anfangen.
 
@kisser: Vielen Dank für diese eindrucksvolle Demonstation ...von was eigentlich? Der Unfähigkeit zum Punkt zu kommen und Argumente zu liefern? Sich selbst den Bauch zu pinseln weil es parout sonst keinem einfällt? Sich aufs erbärmlichste auf seine Diplome zu reduzieren?
Schwache Leistung jedenfalls, unabhängig von möglichen Inhalten eures kindischen Gezänks. Das es sinnlos ist die Leistung 1 Mrd. Mal pro Sekunde zu Erfassen dürfte klar sein, das es sinnfrei ist sie einmal während eines zweitägigen Tests zu erfassen ebenfalls. Irgendwo zwischen 1000000000 und 1 liegt die sinnvolle Anzahl der Messungen pro Stunde. Leb damit.
 
Was das HSA zeugs angeht. Will in die Richtung nichts dazu sagen. Aber falls der Compiler laut K&P die Aufgaben erledigen soll, bleibt es eben die Aufgabe eines anderen Programmierer, nämlich den, der den Compiler entwickelt xD

Aber so unrealistisch ist das nicht, immerhin wurde HSA in Zusammenhang mit Mantle und auch Spielen bereits erwähnt.

Und K&P Aussage war wohl eher die. Wenn ich ein etwas in einer Hochsprache Programmiere, dann wird eine HSA fähige Hardware selbst entscheiden was für die GPU oder CPU ist.
Nai hat aber nicht von einer Hochsprache gesprochen, sondern davon, wenn man direkt eine GPU, dessen Register ect programmiert.

Wenn ich mir anschaue, wie man das mit einer Hochsprache wie C++-AMP programmieren soll (siehe zum Beispiel http://download.microsoft.com/downl...B640F28/CppAMPLanguageAndProgrammingModel.pdf), so ist das im Prinzip programmiertechnisch wie eine Kombination aus CUDA und OpenCL, mit einer weiteren neuen Terminologie für ein und die selben GPU spezifischen Gegebenheiten :freak:. Zwei Terminologien (oder vier wenn man OpenGL und Direct Compute mit einrechnet) reichen ja noch nicht aus. Deshalb muss man, um mit C++-AMP irgendetwas auf einer GPU zu programmieren, weiterhin zuerst die selben Frickeleien machen, damit es auf einer GPU ersteinmal überhaupt läuft. Dann kommt noch die selbe weitere Arbeit auf einen beim Optimieren zu. Die Arbeit abnehmen tut einem das C++-AMP momentan kaum, und ich bezweifle, dass das Abhnehmen der Arbeit jemals automatisch bei einer Programmierung mit Hochsprachen geschehen wird.
 
Kenneth Coldy schrieb:
@kisser: Vielen Dank für diese eindrucksvolle Demonstation ...von was eigentlich? Der Unfähigkeit zum Punkt zu kommen und Argumente zu liefern? Sich selbst den Bauch zu pinseln weil es parout sonst keinem einfällt? Sich aufs erbärmlichste auf seine Diplome zu reduzieren?
Schwache Leistung jedenfalls, unabhängig von möglichen Inhalten eures kindischen Gezänks. Das es sinnlos ist die Leistung 1 Mrd. Mal pro Sekunde zu Erfassen dürfte klar sein, das es sinnfrei ist sie einmal während eines zweitägigen Tests zu erfassen ebenfalls. Irgendwo zwischen 1000000000 und 1 liegt die sinnvolle Anzahl der Messungen pro Stunde. Leb damit.

Wo ist der Verdammte LikeButton wenn man ihn Braucht.
An den Lieben Herrn Narchichteningenieur. Ich bin Techniker, Elektro und Radio und Rundfunk, weiß also wovon ich rede. Aber einen Relativen Messfehler kennst du natürlich nicht ;) Klar ein 20€ Messgerät bildet einen Momentanverbrauch ab, der war gut. Sorry aber du bestätigste nur das Bild eines Theoretikers, der so ein Gerät weder in der Hand hatte noch weiß was es kann.
Achja und den Stromzähler der eine Frequenz im GHz Bereich noch sauber erfassen kann, den will ich sehen. Zu deiner Info, Herr Ingenieur: Stromnetze haben im Hausnetz 50hz.. Setzen 6
 
kisser schrieb:
Ich: Diplom-Ingenieur Elektrotechnik (Nachrichten- und Informationstechnik), jahrelang Messungen an hochfrequenztechnischen Systemen gemacht.
Ich: Zweites Staatsexamen als Lehrer für Elektrotechnik und Physik

Und DU? Was sind deine Qualifikationen, dass du glaubst hier mitreden zu können?

Als ich jung war, gab es sowas nicht, und im Alter werde ich sicherlich nicht mit so einem Scheiß anfangen.

Wann hast du deine Abschlüsse gemacht? 1920? Und du hast ICH: reiner Theoretiker vergessen.
Immer diese neunmalklugen Möchtegern-Oberlehrer hier... So ein Forum ist dazu da, Wissen konstruktiv zu teilen, und nicht, um Andere altklug zu korrigieren, um sich selbst überlegen zu fühlen. Das können hier aber viele leider nur allzu gut.
Jedes Muttersöhnchen will der Ober-Nerd sein... :freak:
 
Nai schrieb:
Dann kommt noch die selbe weitere Arbeit auf einen beim Optimieren zu. Die Arbeit abnehmen tut einem das C++-AMP momentan kaum, und ich bezweifle, dass das Abhnehmen der Arbeit jemals automatisch bei einer Programmierung mit Hochsprachen geschehen wird.

Lines-of-Code-and-Performance.jpg


Aktuell hast du auch recht, weil du von C++AMP sprichst, was auch übrigens von MS selbst ist. (also soviel ich weiß)

HSA-Bolt ist aber, fallls ich mich nicht täusche erst mit Carrizo möglich, weil dieser Context Switching unterstützt. Somit das HSA gerede ist und bleibt immer noch Zukunftsmusik. Nur ist eben mit C++AMP und anderen Schnittstellen eben HSA-Features bereits jetzt möglich.

Ich verlinke gerne die Grafik, weil es ja auch die Unterschiede aufzeigen soll, besonders der Aufwand in Relation zum Output.
Inwiefern die Grafik aber stimmt, wird sich wohl erst zeigen müssen. Aber bei HSA Bolt sieht man schon, dass der Kompiler offensichtlich viel Arbeit übernehmen dürfte.
Btw, vergleiche mal serial CPU mit HSA Bolt.
Natürlich damit der Balken stimmt muss die passende Anwendung gegeben sein, die auch neben der CPU von anderen Elementen im SoC profitieren. Am Interessantesten sind ja dann Anwendungen die dann ständig Aufgaben wechseln.
PC Mark zeigt eventuell, irwann mal auch den Vorteil diverser neueren APUs, mal sehen.
 
Zuletzt bearbeitet:
HSA-Bolt ist aber, fallls ich mich nicht täusche erst mit Carrizo möglich, weil dieser Context Switching unterstützt. Somit das HSA gerede ist und bleibt immer noch Zukunftsmusik. Nur ist eben mit C++AMP und anderen Schnittstellen eben HSA-Features bereits jetzt möglich.

HSA-Bolt ist eine Template Library, welche das Standard CPP-Feature der Templates verwendet, um die Berechnungen, welche man auf der GPU ausführen möchte, zu definieren. Diese Art von Template-Support gibt es in CUDA bereits seit 2009 (?). Allerdings weiß ich nicht ob es in CUDA eine ähnliche Template-Bibliothek gibt, welche ähnliche Funktionalitäten per Template ermöglicht. Die Beschreibung mit "Bolt is a C++ template library optimized for GPUs. Bolt provides high-performance library implementations for common algorithms such as scan, reduce, transform, and sort." liest sich etwas nach dem CUDA-Thrust, welches es auch bereits seit Jahren gibt. Aber da CUDA an sich komplett Template-fähig ist, kann man sich zur Code-Ersparnis oft selbst soetwas ähnliches ohne überhaupt irgendeine Bibliothek zu verwenden schreiben.

Ich wollte mir auch mal den Quelltext anschauen, wie sie in ihrem Beispiel auf die Code-Ersparnis kommen, da sie es hier ja auch online veröffentlicht haben:
https://github.com/HSA-Libraries/Bolt/tree/master/examples/Hessian

Doch die spezifische Bolt-Datei sieht so aus:
https://github.com/HSA-Libraries/Bolt/blob/master/examples/Hessian/hessian_boltcl.cpp

Großes Kino, bei einem Beispiel für eine Bibliothek, wo man eben diese Bibliothek mit anderen Verfahren vergleicht, ausgerechnet denjenigen Teil, wo man die Bibliothek verwendet, nicht zu implementieren (oder zu veröffentlichen) :freak:
 
Zuletzt bearbeitet:
stoneeh schrieb:
Nach den Vorsprüngen bei von der HD3870 bis zur 5870 hat AMD nun deutlich nachgelassen, und ist bei dieser Generation erstmals seit langem sowohl zeitmässig als auch leistungsmässig hinter Nvidia.

Ich hoffe AMD's derzeitige Architektur war kein One Hit Wonder ala K7.


ähhhmmm, ja :rolleyes:
Schwachsinn!
 
stoneeh schrieb:
Nach den Vorsprüngen bei von der HD3870 bis zur 5870 hat AMD nun deutlich nachgelassen, und ist bei dieser Generation erstmals seit langem sowohl zeitmässig als auch leistungsmässig hinter Nvidia.

Nachgelassen? Gut, die 4870&50 hatten nicht die Leistungskrone, aber dafür ein exellentes P/L, und die 7970/50 boten eine sehr gute
GPU-computing-Leistung und seinerzeit exorbitante 3GB VRAM, beim GPU-computing lassen auch Nvidias aktuelle 900er, obwohl brandneu, noch zu wünschen übrig. Technologisch lag AMD oft vorn, NV macht das mit dickerem Budget und unseligen Absprachen (Ubisoft) wett.
Zeitmässig hinken sie zwar grad etwas, da gebe ich dir Recht.
Das lässt aber nur vermuten, dass der neue Chip sehr gut wird und sicher kein Schnellschuss.
Und dass Tahiti /Hawaii sich so lange am Markt halten konnten, spricht auch nur für die Qualität des Konzepts.
Ich denke, wer jetzt Geduld hat und nicht schon zu Weihnachten eine neue Karte haben muß, wird Anfang 15 mit der besseren (roten) Karte belohnt.
 
Pippi, ja, Nai beeindruckt mich immer wieder, Daumen hoch!:D

@Kisser

Ich denke du wolltest damit sagen, dass diese Messreihen mit hochfrequenten Geräten um Peaks darzustellen zwar nett sind, in Summe ja aber eh die Leistungsaufnahme über Zeit das Interessante ist, und hier reißt die Karte nicht das TDP Limit - nicht mit dem 20 Euro Messgerät hinterm Netzteil ergo sollte es auch passen (nicht wie einem manche Reviewseiten mit exquisiter Test Hardware bei der GPU Spannungsversorgung weiß machen wollen). Ich finde diese Tests nett, aber wenn es weder das Messgerät hinter dem PC noch der Stromzähler abbildet...

Extrem kurzzeitig zieht meine rechnerinterne Hw sicher auch 2kw oder geht gegen Unendlich :)
 
Zuletzt bearbeitet:
Zurück
Oben