R800 Spekulationsthread
- Ersteller p4z1f1st
- Erstellt am
Die Texture-L1 und L2-Caches werden eigentlich immer genutzt. Solange man die Daten in Texturen rumliegen hat, kann man das gar nicht verhindern
Beim Zugriff auf den linearen Global-Memory cached nv aber nicht (weswegen auch CUDA-Arrays mit texture references empfohlen werden, ist meist schneller), bei ATI weiß ich es gerade nicht (solange man aber nicht den Local-Datahare benutzt, kommt bei ATI auch Global Memory nicht ins Spiel).
Mir ging es darum, daß der CAL-Compiler jetzt auch schon für unterschiedliche Hardware unterschiedlichen Code erzeugt
Das tun sie aber gerade nicht. Um mal Wikipedia zu zitieren:
Genau das alles ist für den Local Data Share nicht erfüllt. Das meinte ich, als ich sagte, daß es für den Programmierer nicht transparent ist, sondern explizit angesprochen werden muß. Es ist einfach ein zusätzlicher Speicherbereich, aber kein Cache im herkömmlichen Sinne. Mit entsprechender Programmierung kann man den auch dazu benutzen, Daten zu cachen, das macht aber die Hardware nicht zu einem Cache. Die Register sind bei Dir ja auch kein CacheWikipedia zu Cache schrieb:
Die müssen wie schon gesagt vom Programm explizit da rein geschrieben und genauso explizit auch von dort wieder gelesen werden.Irgendwoher müssen die Daten in den "Data Shares" doch auch gelesen/geschrieben werden, die fallen nicht vom Baum, oder werden durch ein umherschwirrendes Gamma Teilchen erzeugt
Da ist nv offensichtlich ziemlich unsauber bei der Namensgebung. Jetzt weiß ich auch warum viele CUDA-Anfänger nicht kapieren, wie shared memory funktioniert und am besten genutzt werden sollteUm die Diskussion vielleicht abzukürzen, ich hab die "Cache" Floskel von nVidia, die sprechen bei CUDA sowohl von Cache also auch von shared memory:
Sollte also egal sein
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Jetzt lasset uns raten was ATI mit einer eigenen SDK für die GPUs vorhatte ... Nvidia-Chips mit angepasster Software optimieren? Natürlich nicht. In so fern ist das Tool-Bündel sehr wohl für bestimmte Hardware gedacht. Die kurzzeitige Umwidmung in der letzten Betaversion ausschliesslich für AMD CPUs anstatt der ATI-GPUs zeigt das ja.
Die ATI Stream-SDK ist eine Toolsammlung mit der Schnittstelle CTM (Close to Metal) und auch OpenCL, um sie optimal für eigene Produkte einzusetzen.
Das entwertet NICHT die Eigenständigkeit von OpenCL. Und OpenCL ist in so fern vergleichbar mit CUDA und Stream/CTM, weil so Multicores für allgemeine Anwendungsfälle verwendet werden können.
Übrigens macht Nvidia nichts anderes mit ihrer eigenen CUDA-Toolsammlung. Dort wird unter dem Dach CUDA eine sehr breite Entwicklerumgebung angeboten. Neben der PhysX-Technik mit der APEX-Umgebung preisen sie jüngstens die Integration von Tools für OpenCL an
Ich erinnere dich gerne daran, dass du fast ausgeschlossen hast, dass die OpenCL-Optimierung für Prozessoren und GPUs zugleich genutzt werden können
Wie das im Detail aussieht kann ich dir nicht sagen.
MFG Bobo(2009)
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Tja so gehts, wenn das Übel an der Wurzel sitztDa ist nv offensichtlich ziemlich unsauber bei der Namensgebung. Jetzt weiß ich auch warum viele CUDA-Anfänger nicht kapieren, wie shared memory funktioniert und am besten genutzt werden sollte
Ansonsten, Charie vermeldet 1600 Shader + 1,25 GHz GDDR5 als sicher:
http://www.semiaccurate.com/2009/09/03/and-cypress-shader-count/
War zwar schon vor 2 Tagen, aber fiel wohl keinem auf.
ciao
Alex
gruffi
Grand Admiral Special
Sry, aber ich glaube nicht, dass du den Unterschied zwischen OpenCL und Stream verstehst. An der Stelle macht es dann auch keinen Sinn, weiter darüber zu diskutieren.
Dir sollte nur klar sein, dass deine vorhergehende Frage unberechtigt war. Das ist alles.
Nein. OpenCL ist eine eigenständige und unabhängige Spezifikation. AMD könnte Stream komplett über Bord werfen. Das hat auf OpenCL ansich erstmal keine Auswirkungen, maximal auf AMD Internas. Aber das ist nicht das Thema für Leute, die mit OpenCL entwickeln wollen.
Nochmal, du solltest dich von der hardwarebezogenen Denkweise lösen. Es sind Softwareschnittstellen und unterliegen ganz anderen Paradigmen. Lass dir das von jemanden sagen, der damit seit über 15 Jahren zu tun hat und sei bitte einmal einsichtig.
Das eine hat mit dem anderen nichts zu tun. Es gibt viele Unternehmen, die ganze Suiten mit diversen Inhalten zur Softwareentwicklung anbieten.
Was soll ich fast wo ausgeschlossen haben?
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Habe ich was anderes behauptet? Du scheinst gerne das Wort "firmeneigen" (-> proprietär) bei mir zu überlesen.
Natürlich kann AMD Stream über Bord werfen. Der Witz ist ja, dass das Marketing bei AMD Stream als Worthülse verwendet, um damit eine Entwicklungsumgebung nun auch für OpenCL für eigene Hardware zu bewerben.
Mir ist klar, dass die API OpenCL nun mal von einem Konsortium definiert wird. Die Entwicklung geschieht offen an einem runden Tisch, wo AMD/ATI ebenso Vorschläge einreichen wie Nvidia und Intel.
Darüber hinaus schmeissen AMD und Nvdia nicht den eigenen Markenbegriff Stream und CUDA einfach weg. Sie nutzen das als Mantel, um damit auch firmeneigene Tools für firmeneigene Schnittstellen zusammen mit OpenCL unter einem gemeinsamen Dach anzubieten. Bei AMD ist das die Stream-SDK, bei Nvidia ist das CUDA.
Und bei OpenCL gibt es, wie OpenGL auch, die Möglichkeit firmeneigene Erweiterungen zu definieren. Sie sind dann nur nicht Pflichtbestandteil der jeweils gültigen API.
->
So viel zum vom von dir vermuteten nicht möglichen Verzahnen von GPU- und CPU-Rechenpower unter OpenCL. AMD hat Interesse beides zu nutzen.
Also wenn ich mit OpenCL Physik-Effekte im Stil vom PhysX-Chip für Spiele nachstelle, die denen von Ageia gleichen, womöglich mit den gleichen Satz an Physikalischen Grundformeln, dann hat "das Eine" sehr wohl mit "dem Anderen" was damit zu tun. Der Unterschied ist, das eine ist proprietär, das andere eine firmenübergreifende Schnittstelle.
Der Witz ist ja, dass Ageias APEX in Nvidias CUDA integriert wurde. Es ist dummerweise zu 100 Prozent unter Kontrolle von Nvidia, so dass schon viel geschehen muss, wenn AMD und Intel das in eigenen Produkten berücksichtigt.
MFG Bobo(2009)
Zuletzt bearbeitet:
Nein, wie auch - die Leute hier sind ja mit dem vollposten von OpenCL-Zeugs beschäftigtTja so gehts, wenn das Übel an der Wurzel sitzt
Ansonsten, Charie vermeldet 1600 Shader + 1,25 GHz GDDR5 als sicher:
http://www.semiaccurate.com/2009/09/03/and-cypress-shader-count/
War zwar schon vor 2 Tagen, aber fiel wohl keinem auf.
ciao
Alex
Ich hats schon gelesen. Wust nur nicht ob es sich lohnt etwas zu posten bei der hitzigen Diskussion
Da es jetzt langsam auf den Release zu geht würde ich die Herren der Diskussion CUDA/OpenCL/Stream darum bitten etwas das Schreibtempo runter zu fahren damit wir auch nicht die Infos zur R800 verpassen bzw. sich vielleicht einen eigen Thread zu erstellen für das weitreichende Thema.... wundert mich eh das es dazu noch keinen Spekulationsthread gibt.
Edit: @Opteron: nV hat derzeit echt nicht leicht mit Charlie, sobald es auch nur ansatzweise um GPUs geht haut er auf ihnen rum
Zuletzt bearbeitet:
gruffi
Grand Admiral Special
Unter welchem Begriff AMD die eigenen SDKs zusammenfasst, spielt keine Rolle. Was uns besser zur ursprünglichen Frage von dir zurückkommen lassen sollte:
Das OpenCL SDK war eben nie ausschliesslich für GPU-Computing vorgesehen. Ganz einfach, weil OpenCL selbst nicht ausschliesslich auf GPU-Computing beschränkt ist. Zumal es ein OpenCL SDK bisher auch nicht gab. Was das bisherige Stream SDK beinhaltet, ist dabei unerheblich. Die Sinnfrage ist somit überhaupt nicht gegeben.
Ich hoffe, du akzeptierst das jetzt endlich mal, anstatt hier noch ewig darauf rumzureiten.
Unter "Verschmelzen" verstehe ich aber etwas anderes als beides zu nutzen. Separate Pfade sind nicht verschmolzen. Deshalb kann ich trotzdem beides zugleich nutzen. Da hast du scheinbar etwas wirr interpretiert.
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Bezogen auf die OpenCL API habe ich auch nie andersartiges behauptet.
Historisch genetisch gesehen war die ATI SDK eine Entwicklungsumgebung für GPGPU und GPU-Computing. Punkt.
Was unsere Postings angeht, da scheinen wir uns generell immer anders zu verstehen.
Nein, wir sollten uns da aus dem Thread herausklinken, weil unsere Diskussion keine Sau hier interessiert.
themk
Grand Admiral Special
Ich glaube eher, dass man einer Bienenallergie vorsorgen möchte.
Oder man möchte verhindern, dass die neue Karte in den Eröffnungsbenchmarks hinter der 4870x2 liegt.
Ich glaube, die Karte wird einschlagen wie ein Hammer, und dann immer noch funktionieren. Neues DX, wieder September - das erinnert ein wenig an den R300 / Radeon 9700pro Launch.
Oder man möchte verhindern, dass die neue Karte in den Eröffnungsbenchmarks hinter der 4870x2 liegt.
Ich glaube, die Karte wird einschlagen wie ein Hammer, und dann immer noch funktionieren. Neues DX, wieder September - das erinnert ein wenig an den R300 / Radeon 9700pro Launch.
Zuletzt bearbeitet:
Ich dachte das Thema 384bit sein nun endgültig vom Tisch?! Da hat wohl jemand ein altes Gerücht neu auftische wollen
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ich dachte das Thema 384bit sein nun endgültig vom Tisch?! Da hat wohl jemand ein altes Gerücht neu auftische wollen
Ja ist es, die Info gilt als gesichert:
Weiß zwar nicht, wiese der anfangs "over" schreibt, obwohls 1600 Shader sind, aber egal.
http://alienbabeltech.com/main/?p=11135
ciao
Alex
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Hast Du nach den TSMC Yield Problemen mit was anderem gerechnet ?
.. ich nicht.
In 3DC hat noch jemand schnell die FLOPS ausgerechnet:
Thx @mboeller
ciao
Alex
Dr@
Grand Admiral Special
Mich irritiert etwas, dass die sonst üblichen Verdächtigen bisher schweigen... 
Edit:
Fuad gehört nicht dazu. Die schreiben jeden Tag was anderes!
Edit:
Fuad gehört nicht dazu. Die schreiben jeden Tag was anderes!
Zuletzt bearbeitet:
Also weißt Du, die ganzen Gerüchteküchen haben doch die ganze Zeit fast nur Müll erzählt. Wenn man ein wenig drüber nachgedacht hat, war sehr früh klar, daß alles andere als eine aufgebohrte RV770-Architektur sehr unwahrscheinlich ist. Im Prinzip bewegte sich der Spielraum nur zwischen 16 und 20 SIMDs und damit zwischen 1280 bzw. 1600 ALUs mit 64 bzw. 80 TMUs.Fuad hat unabhängig von uns eigentlich heute recht ähnliche Specs rausgebracht..
Meine Überlegungen vom April bei 3DCenter kann ich gerne dazu verlinken. Meine vermuteten Spezifikationen von damals waren 16 bzw. 20 SIMDs (jetzt werden es 18 bzw. 20 für 5850/5870), 1280/1600 SPs (jetzt 1440/1600) mit entsprechend 64 bzw. 80 TMUs (jetzt 72 bzw. 80) mit 32 ROPs (stimmt genau) an einem 256Bit Speicherinterface, was mit 1,2 GHz oder etwas mehr getaktet ist (stimmt auch).
Also die ganzen Insider-Quellen scheinen ja nicht viel wert zu sein
Zuletzt bearbeitet:
mibo
Grand Admiral Special
Interessant sind natürlich die Details, die auch noch fehlen.
z.B. wieviel an den ALUs geändert/verbessert wurde. Die müssen jetzt ja mindestens DX11 können.
Von daher ist die Anzahl alleine nicht die ganze Wahrheit.
Ich freue mich auf die ersten richtigen Tests, mit Verbrauchsmessungen natürlich
z.B. wieviel an den ALUs geändert/verbessert wurde. Die müssen jetzt ja mindestens DX11 können.
Von daher ist die Anzahl alleine nicht die ganze Wahrheit.
Ich freue mich auf die ersten richtigen Tests, mit Verbrauchsmessungen natürlich
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Jupp so siehts aus .. dann noch die ulkigen Gerüchte über MCMs ...Also die ganzen Insider-Quellen scheinen ja nicht viel wert zu sein
Da wird soviel Sch....lechtes geschrieben .. nicht zum aushalten.
Mit gesundem Menschenverstand kommt man weiter ...
Bekommst Du eingentlich ne Karte fürs Boinc Projekt ? ^^
ciao
Alex
