Jammer-Thread

[Krishty]

Allein meine Anwesenheit erzeugt schon eine Aura von Melancholie und Weltschmerz, dass es Sofia Coppola in den Wahnsinn treiben könnte … aber bitte:

PIX ist unnütz für HDR-Rendering. Einfach nicht zu gebrauchen. Der Gipfel ist aber: Es bietet die Möglichkeit, Texturen im .hdr-Format zu speichern. Yippie!, denkt man sich. Dann öffnet man die „.hdr“-Datei und sieht, dass PIX vor’m Speichern die ganze schöne *32_FLOAT-Textur zu 8-bit-UNORM konvertiert hat. Das ist nicht mehr (wie sonst) fahrlässig, sondern schon mutwillig. Die wollen, dass ich mich freue, nur, damit sie mich auslachen, wenn ich mich zwanzig Sekunden später fühle wie eine versiffte alte Hure der man die Gebärmutter rausgenommen hat. Die lieben das doch, wenn sie meine Hoffnungen und Träume brutalstmöglich vergewaltigen und mich dann nackt und blutend im Schnee liegen lassen. Ich wette, die machen den ganzen Tag nichts anderes als zu planen, wie sie es nach außen wie guten Willen aussehen lassen könnten wenn sie versuchen, mich zu ficken und zu schlagen.

Da das DirectX-SDK seit neuestem eine Connect-Seite hat, gibt das noch einen schönen Hassbrief.

[Alexander Kornrumpf]

Jo, und wenn dank JMStV Websites bald eine Alterskennzeichnung brauchen, wissen wir dank wem wir mindestens "ab 16" sind. :)

[Krishty]

Hier werden Opfer zu Tätern gemacht … nicht meine Tiraden sind ab 16, sondern die Welt ist es. Jedenfalls der DirectX-Teil von ihr. Und wenn ich mal einen von denen in die Finger kriege, wird das ab 18 (nach nordkoreanischem Jugendschutzverständnis).

[kimmi]

Bezüglich der Templates und neubauen: da gibt es ein ganz gutes Buch namens Large-Scale-C++ Design. Man kann nämlich durch etwas Arbeit gerade hier einen kompletten Neucompile vermeiden.

Und wegen PIX: Ich habe es bereits gesagt und sage es wieder: du nimmst das zu persönlich :). Wenn die bei MS genau so viel realistische Zeitpläne haben wie in meinem Laden, ist das ein Wunder, dass der Save-Button überhaupt was tut :o).
Gruß Kimmi

[Krishty]

Wenn die bei MS genau so viel realistische Zeitpläne haben wie in meinem Laden, ist das ein Wunder, dass der Save-Button überhaupt was tut :o).

Wenn der Zeitdruck so groß ist dass PIX nicht einmal zu DDS voll kompatibel ist, soll es aber nicht fünf Dateiformate (davon drei exotische) anbieten, deren Sinn mitunter genau darin liegt, Dinge zu speichern, die PIX ganz genau nicht implementiert. Das stinkt nach allen Seiten.

[Aramis]

Vielleicht ist es auch die Tatsache, dass PIX ein enorm komplexes Tool ist, aber sicher nicht mehr als ein Entwickler Vollzeit dran arbeitet.

[Jörg]

Man munkelt ja von einem PIX-Plugin Example im SDK.....

[Krishty]

Ich will mich nicht mehr stundenlang damit rumärgern, dass eine Variable in einem inneren Scope nochmal deklariert wurde und jetzt einen anderen Wert hat, sich der Compiler einen Scheiß drum schert und deshalb ein Compute-Shader nur in einen statt drei Kanäle schreibt und man das in PIX nicht prüfen kann weil das für jeden Compute Shader mit einer Länge von mehr als 16 Befehlen einfach schwarz ausgibt

Macht’s gut

[Schrompf]

Was wirst Du denn jetzt tun? Auf OGL wechseln? Oder nach Tahiti auswandern?

[anonym]

Hast Du Dir schon mal nVidia Parallel Nsight bzw. den nVidia Visual Profiler angeschaut (zumindest habe ich bei Dir eine HD5770 und den GPU Shader Analyzer schwach in Erinnerung)? Ich konnte zwar bisher nur den Graphics Debugger verwenden, weil CUDA Debugging zwei GPUs benötigt, allerdings kann ich mir nicht vorstellen, dass sich nVidia in ihrer neu ausgerufenen "Paradedisziplin" einen allzugroßen Schnitzer erlaubt. Der "Leidensdruck" erscheint mir langsam ausreichend hoch, einen Hardwarewechsel in Betracht zu ziehen. :)

[Schrompf]

Unser internes Entwicklerforum ist tot. Der Betreiber der Forenwebseite hat sich anscheinend schon seit Monaten abgesetzt und bezahlt seine Leute nicht mehr - gemerkt haben wir es erst an "Datenbankserver nicht erreichbar". Jetzt sind die ganzen Diskussionen, Entwürfe und Bilder über den Jordan. Scheiße.

Schaumermal, wo das neue Forum hinkommt. In ein paar Wochen hab ich VDSL daheim, dann kann ich das theoretisch auch einfach selbst hosten. Oder halt auf dem Webserver, auch wenn der Strato-Datenbankserver nicht der Schnellste zu sein scheint.

[kimmi]

Ich hatte letztens Abends frei und war auf einer Firmenfeier ( die hier als Klassiker gilt ). Und wann war ich fertig mit der Schicht? 18:00 Uhr! Oh mann, Kinder schlauchen doch etwas.

Gruß Kimmi

[joggel]

Unser internes Entwicklerforum ist tot. Der Betreiber der Forenwebseite hat sich anscheinend schon seit Monaten abgesetzt und bezahlt seine Leute nicht mehr - gemerkt haben wir es erst an "Datenbankserver nicht erreichbar". Jetzt sind die ganzen Diskussionen, Entwürfe und Bilder über den Jordan. Scheiße.

Boah... Sachen gibts! Na hoffentlich waren es nicht allzu wichtige Entwürfe.

In ein paar Wochen hab ich VDSL daheim,...

Cool. Da wir beide ja fast in der selben Ecke wohnen, scheint das ja bei mir auch möglich zu sein.
Darf ich fragen, was das kostet?

[opligatorisches Jammern]
Verdammter Montag... würde sooo viel gerne machen (Projekte), aber die Zeit reicht nicht aus, man möchte sich ja auch nach arbeit etwas erholen.
[/Jammern]

[Schrompf]

VDSL ist straßenweise verfügbar - es gibt eine interaktive Karte irgendwo auf der Telekom-Webseite. Kostet für 50MBit down und 10MBit up 50€ pro Monat. Enthält Telefonanschluss mit Deutschland-Festnetz-Flatrate und eine Internet-Flatrate (bis 200GB, dann gedrosselt auf 6MBit).

[Schrompf]

Nachtrag zu meinem letzten Gejammer: unser Forum ist wieder da. Leider bietet das PHPBB-Adminpanel keinen Datenbank-Dump an. Ich vertraue den Leuten nicht mehr... ich werde mir wohl mit so einem rekursiven Webseitenausleser eine statische Kopie des Forums als Archiv ziehen und auf eigenem Webspace ein Neues aufmachen.

[eXile]

Mmmh? Durch Preloading startet der Firefox doppelt so schnell?

Basic idea is that the sequential flag + bullshit read tricks windows into reading xul in 2mb chunks instead of stupid 32k (or smaller) ones. Have to do it this way because there is no fadvise() on Windows (that I know of). A big sequential read cuts down on a lot of seeks.

-.-

[Aramis]

WTF :-)

[Krishty]

Ich habe einen Shader erschaffne, der im Treiber endkos zum kompileieren braucht

Wirklich jetzt: WTF

Programmiert nie mit DirectCompute
Es ist scheiße
Und auch nicht mit OpenCL
Das ist scheiße und dazu scheiße schwer einzubinden
Und glaubt nicht diesen Scheiß von wegen GPGPU
Alles Lüge
Nichts funktioniert
NICHTS
Es ist wie 1998
Egal, bei welchem Hersteller und mit welcher API

LÜGE LÜGE GLÜE ÜGEL EGÜL EGLÜ ÜGLE

teh cayke is a laih

Stück Callstack, was jetzt schon seit 30 min ausgeführt wird

Code: Alles auswählen

 	atidxx64.dll!000000005e0868fa() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for atidxx64.dll]	
 	atidxx64.dll!000000005e08a790() 	
 	atidxx64.dll!000000005e080098() 	
 	atidxx64.dll!000000005e078c5d() 	
 	atidxx64.dll!000000005e0784f0() 	
 	atidxx64.dll!000000005e005618() 	
 	atidxx64.dll!000000005e004664() 	
 	atidxx64.dll!000000005e002ffe() 	
 	atidxx64.dll!000000005dfc4c38() 	
 	atidxx64.dll!000000005e1fa8b1() 	
 	atidxx64.dll!000000005e1e6c3d() 	
 	atidxx64.dll!000000005e1e6de9() 	
 	atidxx64.dll!000000005e1e6d66() 	
 	atidxx64.dll!000000005e1e6b90() 	
 	atidxx64.dll!000000005df9032f() 	
 	atidxx64.dll!000000005df89f1b() 	
 	atidxx64.dll!000000005df7dfe5() 	
 	atidxx64.dll!000000005df890f8() 	
 	atiuxp64.dll!000007fef7f2448d() 	
 	d3d11.dll!CComputeShader::CLS::FinalConstruct()  + 0x1c6 bytes	
 	d3d11.dll!CLayeredObjectWithCLS<CComputeShader>::CreateInstance()  + 0x178 bytes	
 	d3d11.dll!CDevice::CreateLayeredChild()  + 0xa6b bytes	
 	d3d11.dll!CBridgeImpl<ID3D11LayeredDevice,ID3D11LayeredDevice,CLayeredObject<CDevice> >::CreateLayeredChild()  + 0x2e bytes	
 	d3d11.dll!NDXGI::CDevice::CreateLayeredChild()  + 0x290 bytes	
 	d3d11.dll!CBridgeImpl<ID3D11LayeredDevice,ID3D11LayeredDevice,CLayeredObject<NDXGI::CDevice> >::CreateLayeredChild()  + 0x2e bytes	
 	D3D11SDKLayers.dll!CD3D11LayeredChild<ID3D11DeviceContext,NDebug::CDevice,32>::FinalConstruct()  + 0x40 bytes	
 	D3D11SDKLayers.dll!NDebug::CDeviceChild<ID3D11UnorderedAccessView>::FinalConstruct()  + 0x52 bytes	
 	D3D11SDKLayers.dll!NDebug::CComputeShader::FinalConstruct()  + 0x3c bytes	
 	D3D11SDKLayers.dll!CLayeredObject<NDebug::CComputeShader>::CreateInstance()  + 0x87 bytes	
 	D3D11SDKLayers.dll!NDebug::CDevice::CreateLayeredChild()  + 0x8cf bytes	
 	D3D11SDKLayers.dll!CBridgeImpl<ID3D11LayeredDevice,ID3D11LayeredDevice,CLayeredObject<NDebug::CDevice> >::CreateLayeredChild()  + 0x2e bytes	
 	d3d11.dll!NOutermost::CDeviceChild::FinalConstruct()  + 0x3c bytes	
 	d3d11.dll!CUseCountedObject<NOutermost::CDeviceChild>::CreateInstance()  + 0xd7 bytes	
 	d3d11.dll!NOutermost::CDevice::CreateLayeredChild()  + 0x15a bytes	
 	d3d11.dll!CDevice::CreateComputeShader()  + 0x197 bytes	
 	D3D11SDKLayers.dll!NDebug::CDevice::CreateComputeShader()  + 0x239 bytes	
>	core.exe!Cric::D3D11::createShaderFromBytecode<ID3D11ComputeShader>(ID3D11Device & GPU, ID3D11ComputeShader * & result, const void * const toItsBytecode, const unsigned __int64 itsBytecodesSize)  Line 103	C++
 	core.exe!Cric::D3D11::TCShader<ID3D11ComputeShader>::fromByteCode(ID3D11Device & itsGPU, const void * const toItsBytecode, const unsigned __int64 itsBytecodesSize)  Line 166 + 0x19 bytes	C++
 	core.exe!Cric::D3D11::TCShader<ID3D11ComputeShader>::TCShader<ID3D11ComputeShader>(ID3D11Device & itsGPU, const Cric::memory::IReadableMemory & itsBytecode)  Line 183 + 0x56 bytes	C++
 	core.exe!Cric::D3D11::cached<ID3D11ComputeShader>(ID3D11Device & itsGPU, const Cric::types::TCMultiByteString<char> & itsSourceFilesPathWithoutExtension, const char * itsEntryPointsName)  Line 486 + 0x1d bytes	C++
 	core.exe!Cric::D3D11::cachedComputeShader(ID3D11Device & itsGPU, const Cric::types::TCMultiByteString<char> & itsSourceFilesPath, const char * itsEntryPointsName)  Line 525 + 0x19 bytes	C++
 	core.exe!Cric::Bieder::Plugins::CD3D11::CGPU::CGlare::CGlare(ID3D11Device & GPU, const Cric::types::TCMultiByteString<char> & sourceFilesNameWithoutExtension)  Line 58 + 0xb5 bytes	C++
 	core.exe!Cric::Bieder::Plugins::CD3D11::CGPU::CGPU(const unsigned __int64 itsSystemIndex, IDXGIAdapter1 & itsDXGIAdapterObject, D3D_FEATURE_LEVEL minimalFeatureLevel)  Line 186 + 0x29f bytes	C++
 	core.exe!Cric::Bieder::Plugins::CD3D11::CD3D11(const Cric::Bieder::IPlugin::CInitializer & itsInitializer)  Line 58 + 0x3b bytes	C++
 	core.exe!BiederFactory4Direct3D11(const Cric::Bieder::IPlugin::CInitializer & initializer)  Line 22 + 0x30 bytes	C++
 	core.exe!Cric::Bieder::CCore::CPlugin::CPlugin(const Cric::Bieder::CCore::CPluginLocation & itsLocation, Cric::Bieder::ICore & theCore, const unsigned int itsIdentifier)  Line 54 + 0x28 bytes	C++
 	core.exe!Cric::Bieder::CCore::CCore(const Cric::Bieder::CEnvironment & itsEnvironment, const unsigned __int64 numberOfPlugins, const Cric::Bieder::CCore::CPluginLocation * toPluginsLocations)  Line 990 + 0x39 bytes	C++
 	core.exe!Cric::main()  Line 86 + 0x62 bytes	C++
 	core.exe!CricCRTMain()  Line 155 + 0x5 bytes	C++
 	kernel32.dll!BaseThreadInitThunk()  + 0xd bytes	
 	ntdll.dll!RtlUserThreadStart()  + 0x21 bytes	

Ich habe jetzt zwei blockierende Bugs

Fünf Gemeldete

ca. 30 nicht gemeldete, weil ich keinen Bock habe die Scheiße zu reprodudzuieren
(Lustig: Compiler-Abstürze, wenn man Multisampling auf variable Kanalzahl ausführen will dun zufällige Ergebnisse wenn man nur einen Kanal auflöst; Synchronisierungsfehler; Systemcrashes, interne Compilercrrashes, Treibercrashes, Koppcrashes; falsch dokumentiert Parameter; nicht implementierte Funktionalität; unnötige Anweisungen)

WEder Microsoft noch MAD noch die DX-Mailingslist antworten mir

Jeder, der da seine Finger drin hat ist ein Idoit
Und ich auch, weil ich mich so ficken lasse

Egal, wsa ihr machen müsst:
Benutzt keine Compuite Shader
NIE
Von vorne bish inten verkackter Hype-Mist
Lass teuch besser glech von einer Pyramide penetrieren bis es euch zerreißt

[joggel]

WTF?
Alles Lüge.... das macht mir Angst.
Ich fande das Thema immer so "Man, damit muss ich mich unbedingt mal beschäftigen!!"
Aber okay, suche ich nach Alternativen...

Lass teuch besser glech von einer Pyramide penetrieren bis es euch zerreißt

geht klar...

[j.klugmann]

Jetzt habe ich Angst bei meinem Vorhaben meinen LPPR im Compute-Shader zu implementieren.

[Alexander Kornrumpf]

Und glaubt nicht diesen Scheiß von wegen GPGPU
Alles Lüge
Nichts funktioniert
NICHTS
Es ist wie 1998
Egal, bei welchem Hersteller und mit welcher API

Sorry aber GPGPU mit CUDA funktioniert. Ja es ist proprietär, aber manchmal ist proprietär ja auch gleichbedeutend mit "es funktioniert".
Mir wurde von Bugs in nvcc berichtet, aber ich habe bislang keine hier gehabt. Die Anwendung die ich hier habe ist mit CUDA bis zu 30 mal schneller als auf der CPU. 30 MAL, nicht 30%. Das ist der Unterschied zwischen 12h und 24min Laufzeit und das spielt dann schon eine Rolle. Und dass du 1998 für den Preis von heute nirgendwo die schiere Anzahl von GFLOPS geschweige denn den Speicher dazu bekommen hättest ist wohl auch klar.

[Lynxeye]

Verdammter Mist!

Ich habe vor einem Monat einen Linuxkernelpatch geschrieben und dabei vergessen eine Releasefunktion anzupassen. Dadurch kracht der Kernel im seltenen Fall, dass man im laufenden Betrieb das Modul entlädt und wieder lädt. Jetzt habe ich irgend einem armen Wesen drei Stunden seiner Zeit geklaut, in der er das Problem eingegrenzt hat, bis raus kam das mein Commit der böse war. Ich hatte natürlich auch mit keiner Hirnzelle mehr daran gedacht, dass ich an diesen Funktionen geschraubt hatte... Shit! :x

[Krishty]

Jetzt habe ich Angst bei meinem Vorhaben meinen LPPR im Compute-Shader zu implementieren.

Compute Shader können zwar aus multisampled Texture2D laden, aber nicht reinschreiben. D.h: Wenn du Anti-Aliasing haben willst, darfst du bei Pixel Shadern bleiben. Gut, dass ich dir das jetzt sage und du nicht erst alles implementierst und das dann erst bemerkst und dir die Faust wieder aus dem Popo ziehen darfst wie ich letztens.

Sorry aber GPGPU mit CUDA funktioniert. Ja es ist proprietär, aber manchmal ist proprietär ja auch gleichbedeutend mit "es funktioniert".

Na klasse. Warum haben sie nicht das als OpenCL genommen. Btw hoffe ich, dass deine Anwendung wenigstens „echt“ GPGPU war – also schön mit lokalem Speicher, Synchronisierung und mehr als zehn Zeilen Rechenaufwand. Dieser bescheuerte „ich kopiere ein Array von A nach B und multipliziere es dabei mit einer Matrix; das könnte ich zwar auch im Pixel Shader machen aber so spare ich mir das Vollbildrechteck und die Rasterizer States“-Kram den sie uns verkaufen wollen als hätten wir Jahrzehnte drauf warten müssen ist nämlich dsa einzige, was sie erstaunlicherweise auf die Reihe kriegen.

Die Anwendung die ich hier habe ist mit CUDA bis zu 30 mal schneller als auf der CPU. 30 MAL, nicht 30%. Das ist der Unterschied zwischen 12h und 24min Laufzeit und das spielt dann schon eine Rolle. Und dass du 1998 für den Preis von heute nirgendwo die schiere Anzahl von GFLOPS geschweige denn den Speicher dazu bekommen hättest ist wohl auch klar.

30× ist keine Kunst. Und die GFLOPS darf ich erstmal durch acht teilen, weil der Compiler die falsche Speicheranbindung benutzt. Dann nochmal durch zwei, weil die Sprache Überlappungen nicht richtig ausschließen kann. Dann nochmal durch zwei, weil die GPU keine Conditionals kann und alle Pfade einmal ausführen muss. Dann nochmal durch zwei, weil die GPU dumme kurze Shader schneller ausführen kann als intelligente Lange und es deshalb performanter ist, die Arbeit auf mehrere Passes aufzuteilen die insgesamt doppelt so viel Arbeit durchführen.
Und dann sind wir in GFLOP-Bereichen, die heute jede GPU für <50 € stemmen könnte wenn nur der bekackte Compiler das Scheißprogramm kompilieren könnte ohne mit einem internen Invalid Opcode-Fehler abzustürzen.

Und den Speicherbedarf lassen wir hier mal raus, da reagiere ich ganz empfindlich drauf seit ich rausgefunden habe, dass ich den Bedarf verdoppeln muss um die Geschwindigkeit vollkommen ungerechtfertigt zu verveirfachen. Wenn 500 MiB für Postprocessing draufgehen, ist dein GiB nämlich so viel wert wie ein Menschenleben in einer mexikanischen Schleuserbande.

[j.klugmann]

Jetzt habe ich Angst bei meinem Vorhaben meinen LPPR im Compute-Shader zu implementieren.

Compute Shader können zwar aus multisampled Texture2D laden, aber nicht reinschreiben. D.h: Wenn du Anti-Aliasing haben willst, darfst du bei Pixel Shadern bleiben. Gut, dass ich dir das jetzt sage und du nicht erst alles implementierst und das dann erst bemerkst und dir die Faust wieder aus dem Popo ziehen darfst wie ich letztens.

Das ist mir schon klar. Allerdings kann man da doch ganz nette Ergebnisse erzielen. Siehe Frostbite 2. Da gibt's auch einen experimentellen LPPR im Compute-Shader. :)

[Alexander Kornrumpf]

Btw hoffe ich, dass deine Anwendung wenigstens „echt“ GPGPU war – also schön mit lokalem Speicher, Synchronisierung und mehr als zehn Zeilen Rechenaufwand. Dieser bescheuerte „ich kopiere ein Array von A nach B und multipliziere es dabei mit einer Matrix; das könnte ich zwar auch im Pixel Shader machen aber so spare ich mir das Vollbildrechteck und die Rasterizer States“-Kram den sie uns verkaufen wollen als hätten wir Jahrzehnte drauf warten müssen ist nämlich dsa einzige, was sie erstaunlicherweise auf die Reihe kriegen.

Ich mache vor allem reduce-operationen (summe, max, min usw) auf großen Datenmengen. Also Operationen die nicht besonders gut inhärent parallelisierbar sind. Wie das geht ist hier beschrieben:
http://gpgpu.org/static/sc2007/SC07_CUD ... Harris.pdf

Natürlich berechne ich die Werte auch bevor ich sie reduziere, das sind aber typischerweise wirklich 10 Zeiler. Ich bin bandbreiten limitiert und nicht GFLOP limitiert, steht auch in dem Paper. Die Bandbreite einer GPU ist aber typischerweise auch höher.

30× ist keine Kunst.

Naja es sind 5 (log(32)) * 18 Monate Moores Law in einem Nachmittag. Ich finde das schon viel. Die Argumentation ist ja wohl hier auch eher dass Moore's Law bei seriellen Prozessoren an seine Grenze stößt und wir daher sowieso parallel werden müssen. Durch Wechsel der Hardwarearchitektur auch noch einen Geschwindigkeitsvorteil zu haben nehme ich da gerne billigend in Kauf. :)

Und die GFLOPS darf ich erstmal durch acht teilen, weil der Compiler die falsche Speicheranbindung benutzt. Dann nochmal durch zwei, weil die Sprache Überlappungen nicht richtig ausschließen kann. Dann nochmal durch zwei, weil die GPU keine Conditionals kann und alle Pfade einmal ausführen muss. Dann nochmal durch zwei, weil die GPU dumme kurze Shader schneller ausführen kann als intelligente Lange und es deshalb performanter ist, die Arbeit auf mehrere Passes aufzuteilen die insgesamt doppelt so viel Arbeit durchführen.
Und dann sind wir in GFLOP-Bereichen, die heute jede GPU für <50 € stemmen könnte wenn nur der bekackte Compiler das Scheißprogramm kompilieren könnte ohne mit einem internen Invalid Opcode-Fehler abzustürzen.

Genau das verstehe ich eben nicht, bzw. habe ich schon im anderen Thread nicht verstanden. Die gesamte Scheduling, Branching, Synchronisierungs und Speicherzugriffslogik von NVIDIA GPUs (Testla/Fermi) ist so unglaublich simpel dass der Compiler meiner Ansicht nach quasi nichts falsch machen kann. Das ist ja eigentlich der Vorteil von GPUs dass anders als bei der CPU nicht ein wesentlicher Anteil der DIe-Fläche für Meta-Logik drauf geht, sondern 99% der Die-Fläche in Rechenpower investiert wird. Das bedeutet natürlich dass der Programmierer es selbst richtig machen muss. Ich kann damit ganz gut leben. Es gibt Anwendungsfälle für die die GPU einfach scheiße ist und man eine CPU braucht. Aber so what?

Und den Speicherbedarf lassen wir hier mal raus, da reagiere ich ganz empfindlich drauf seit ich rausgefunden habe, dass ich den Bedarf verdoppeln muss um die Geschwindigkeit vollkommen ungerechtfertigt zu verveirfachen. Wenn 500 MiB für Postprocessing draufgehen, ist dein GiB nämlich so viel wert wie ein Menschenleben in einer mexikanischen Schleuserbande.

In der Allgemeinheit lass ich das nicht gelten. Das müsstest du dann schon näher erläutern.

[Krishty]

Genau das verstehe ich eben nicht, bzw. habe ich schon im anderen Thread nicht verstanden. Die gesamte Scheduling, Branching, Synchronisierungs und Speicherzugriffslogik von NVIDIA GPUs (Testla/Fermi) ist so unglaublich simpel dass der Compiler meiner Ansicht nach quasi nichts falsch machen kann.

Tut er aber. So leistungsfähig die GPUs auf dem Papier auch sind – alles darüber ist scheiße. Das fängt beim High-Levle-Compiler an (HLSL hat eine Zerreißgrenze bei 100 Register, alles darüber produziert kompilierfähige aber vollkommen falsche Programme. OpenCL unterstützt atm kein restrict und geht deshalb davon aus, dass sich alle Speicheroperationen des Programms gegenseitig überlappen. Da freut man sich, wenn die Bandbreite eh schon limitiert), geht über den Low-Level-Compiler (der dann erneut den falschen Speicherpfad aussucht, hunderte Scratch-Register allokiert statt eine riesige dreimal durchlaufene Schleife zu behalten, wahrscheinlich wegen ,001 % kürzerer Ausführungszeit) und endet beim Treiber, der bei bestimmten Registerzahlen hängt, abstürzt und der eine Endlosschleife im Shader das ganze System einfrieren lässt weil sich die großen IHVs aus den Windows-Treiberrichtlinien freikaufen. Nichts von der Toolchain ist auch nur annähernd zuverlässig einsetzbar, produziert oft völlig unberechenbare Ergebnisse und ist in den meisten Fällen garantiert nicht einmal mit mehr als drei Zeilen Quelltext getestet worden. Und ich wette: wenn die ganze Tool-Chain durch einen magischen Faustfick von heute auf morgen funktionieren würde, würde ich dann feststellen, dass die Hardware ähnlich dicke Patzer innehat.

In der Allgemeinheit lass ich das nicht gelten. Das müsstest du dann schon näher erläutern.

Weil weder der HLSL-Compiler noch der Treiber kapieren, dass sich meine Schreiboperationen nicht überlappen, muss ich im Ping-Pong-Muster arbeiten statt die Quelle überschreiben zu können. Nun läuft es vier Mal so schnell weil die GPU endlich rafft wie sie aus dem Speicher zu lesen hat, aber es verbraucht halt eben doppelt so viel Speicher, der mir eh schon knapp ist wie nix. Willkommen in der wunderbaren Welt der Scattered Reads/Writes.

[Lynxeye]

Und ich wette: wenn die ganze Tool-Chain durch einen magischen Faustfick von heute auf morgen funktionieren würde, würde ich dann feststellen, dass die Hardware ähnlich dicke Patzer innehat.

Da kannst du dir sicher sein. Beim Fermi geht das soweit, dass ein GPU interner Mikrocontroller ganze Teile der GPU zwischen bestimmten Statechanges resetet, nur um ein komplettes abschmieren selbiger zu verhindern.

Die Realität sieht oft noch etwas anders aus, als die heile, bunte Welt, die AMD und NVidia uns in ihren GPGPU Präsentationen zeigen wollen. Außerdem wird immer noch mit zweierlei Maß gemessen: aktuelle Highend GPUs verbrauchen zwei- bis dreimal soviel Strom wie eine Highend CPU. Wenn man nur GPUs mit max. 150W Verbrauch als Vergleich heranzieht, relativiert sich der Vorteil schon wieder ein ganzes STück.

[Alexander Kornrumpf]

Das fängt beim High-Levle-Compiler an (HLSL hat eine Zerreißgrenze bei 100 Register, alles darüber produziert kompilierfähige aber vollkommen falsche Programme. [...]

Hmm. Ich hab das jetzt alles nicht ganz auswendig parat, aber die Zahlen laufen ungefähr so dass die G80 8192 Register pro Streaming Multiprocessor (SM) hat, typischerweise willst du auf jedem SM >128 Threads laufen lassen und kommst damit auf maximal 64 Register pro Thread. Flüchtiges googlen hat ergeben dass die Compiler (auch nvcc) nicht besonders gut darin sind die Anzahl der Register pro Thread zu optimieren, aber wenn du >100 brauchst benutzt du die GPU einfach falsch schätze ich. (Bei neueren Architekturen hast du zwar mehr register, brauchst aber auch mehr Threads um den SM einigermaßen auszulasten, da tut sich also nichts.

Was nicht in die Register passt liegt wenn ich mich recht erinnere im Shared Memory. Die 16K sind jetzt auch nicht die Welt, zumal du die ja auch als Cache ersatz brauchst. Wenn die auch voll sind was soll der Compiler deiner Meinung nach tun? Da hat die Hardware halt ne Grenze.

Weil weder der HLSL-Compiler noch der Treiber kapieren, dass sich meine Schreiboperationen nicht überlappen, muss ich im Ping-Pong-Muster arbeiten statt die Quelle überschreiben zu können. Nun läuft es vier Mal so schnell weil die GPU endlich rafft wie sie aus dem Speicher zu lesen hat, aber es verbraucht halt eben doppelt so viel Speicher, der mir eh schon knapp ist wie nix. Willkommen in der wunderbaren Welt der Scattered Reads/Writes.

Also unter scattered read/writes verstehe ich dass der Speicherbereich in den geschrieben wird nicht kontinuierlich ist ("pointer-chasing"). Und davon ist einfach bekannt dass es auf GPUs arschlahm ist. Das hab ich im Vorpost schon versucht anzudeuten, könnten GPUs das schnell, wären sie CPUs. Die Quelle en-bloc zu überschreiben sollte dagegen kein Problem sein. Was du eigentlich machen willst, ist einen Block aus der Quelle in Shared-Memory lesen, irgendwas damit machen und dann den ganzen Block wieder zurück schreiben. Das sollte schnell sein bzw. ist schnell. Wenn deine Daten sich nicht soweit granulieren lassen dass das möglich ist, hast du eben Pech gehabt.

Vielleicht reden wir aneinander vorbei, aber ich habe das Gefühl du erwartest einfach etwas dass die Hardware nicht kann. Ob die ATI Toolchain zudem auch noch buggy ist kann ich natürlich nicht beurteilen.

[Krishty]

Flüchtiges googlen hat ergeben dass die Compiler (auch nvcc) nicht besonders gut darin sind die Anzahl der Register pro Thread zu optimieren, aber wenn du >100 brauchst benutzt du die GPU einfach falsch schätze ich.

Jaa, lustige Sache: Also ich habe einen Shader, der 30 GPRs verbraucht. Das ist zwar über dem Optimum und nicht mehr weit von der empfohlenen Obergrenze von 16384 Registern pro Thread-Gruppe, aber egal. Ich füge 15 % Rechenoperationen hinzu. Wie viele Register verbraucht der Shader jetzt? 36? 36 stimmt zwar, jetzt aber zusätzlich noch 57 Scratch. Und schon ist die Registerzahl in Bereichen, wo Variablen anfangen, mittendrin ihre Werte ändern. Nun ahnst du vielleicht, worüber ich mich hier aufrege.

Die 16K sind jetzt auch nicht die Welt

Dass ich bei D3D11 32 KiB habe ist der Hauptgrund, warum ich überhaupt noch dortbleibe.

Also unter scattered read/writes verstehe ich dass der Speicherbereich in den geschrieben wird nicht kontinuierlich ist ("pointer-chasing"). Und davon ist einfach bekannt dass es auf GPUs arschlahm ist. Das hab ich im Vorpost schon versucht anzudeuten, könnten GPUs das schnell, wären sie CPUs.

Natürlich können sie es schnell. Man muss ja sogar streuen, um verschiedene Bänke simultan zu treffen und so. Ich habe auch schon gebencht, dass exakt gleiche Schreiboperationen acht Mal schneller werden, wenn ich die Deklaration des Puffers RWBuffer<float> zu RWStructuredBuffer<float> ändere – was nicht den geringsten Unterschied machen dürfte und wenn doch, dann einen gegenteiligen. Ich will ja auch nicht die 80 % Peak Bandwidth, die perfekt optimierte Algorithmen aus Papern versprechen – mir würde schon reichen, wenn ich über 5 % käme. Aber der Compiler lässt mich nicht.

Wenn deine Daten sich nicht soweit granulieren lassen dass das möglich ist, hast du eben Pech gehabt.

Dochdoch, die Daten sind toll, das Schreib-Layout ist optimiert. Der Grund ist, dass die Compiler einen Speicherpfad erzwingen, der normalerweise für Daten ungerader Größe vorgesehen ist, die global synchronisiert werden müssen. Aber was der Sinn dahinter ist, darüber schweigen mich alle nur an. Ich sage: menschliches Versagen.

[Alexander Kornrumpf]

Natürlich können sie es schnell. Man muss ja sogar streuen, um verschiedene Bänke simultan zu treffen und so.

Das wage ich mal ganz stark zu bezweifeln, erstens weil es in ungefähr jedem Paper was ich bislang gelesen habe anders steht, und zweitens weil das Bankargument wenn ich mich recht erinnere einfach Blödsinn ist. Wenn ich mich jetzt nicht schwer täusche ist das Adressierungsschema im Shared Memory so, dass konsekutive Speicheradressen in verschieden Bänken liegen um genau das Problem zu vermeiden.

Ich verstehe auch nicht was das "der Compiler lässt mich nicht" heißen soll. Jeder Thread soll "sein" Element lesen, verarbeiten und schreiben. Das ist binär. Entweder man macht es "richtig" oder eben nicht. Ich weiß nicht was dein Compiler dir dabei verspricht, aber der nvcc macht diesbezüglich keinerlei Versprechen. Man muss (und kann) es selbst so organisieren.

Dochdoch, die Daten sind toll, das Schreib-Layout ist optimiert. Der Grund ist, dass die Compiler einen Speicherpfad erzwingen, der normalerweise für Daten ungerader Größe vorgesehen ist, die global synchronisiert werden müssen. Aber was der Sinn dahinter ist, darüber schweigen mich alle nur an. Ich sage: menschliches Versagen.

CUDA unterstützt keine globale Synchronisierung. Es geht einfach nicht. Weil es langsam wäre. Wenn ATi/AMD das verbockt haben sollten dann erklär doch nicht deshalb GPGPU für gescheitert.