Kann es sein, dass da eine Klammer zuviel reingerutscht ist? Nur um dir den nächsten Jammer-Post zu ersparen. ;)
Re: Jammer-Thread
Verfasst: 18.02.2011, 12:29
von Krishty
Jaa, war aus dem Kopf geschrieben. Ist korrigiert; danke.
Nachtrag: Die Sache ist quatsch. Da kommt keinefloat-Repräsentation bei raus – aber da ich die Funktion benutze, um einen Winkel zu berechnen, mit dessen Sinus und Kosinus ich weiterrechne, und weil Sinus und Kosinus periodisch sind, ist mein Endergebnis richtig obwohl die Konvertierung selber um Dekaden daneben liegt. m[
In der ALU acht Takte lang vier der fünf Rechner leer laufen lassen und währenddessen munter mit dem fünften poppen (scheinbar abgeschobene Register aus lokalem Speicher lesen oder so). Nett.
Re: Jammer-Thread
Verfasst: 20.02.2011, 02:40
von Krishty
Ich verstehe echt nicht mehr, was in AMDs Compiler abgeht. Mein Maschinentext ist voller Move-Conditionally-If-Equal- (CNDE bzw. CNDE_INT) und Floating-Point-Fraction-(FRACT-)Anweisungen. Obwohl ich nirgends auch nur eine ähnliche Anweisung einsetze. Die Operanden werden aus den obskursten Registern geladen (u.a. aus dem Programmstapel im Wavefront-lokalen Speicher, der auch für Scratch Registers genutzt wird) und die Ergebnisse werden mehrfach durchgeCNDEt, bevor sie dann einfach mit was Sinnvollem überschrieben werden.
Allein die CNDE und FRACTs zusammen belaufen sich auf 10 % des Maschinentexts und sind einfach sinnlos. Einige davon landen in der Transcendental Unit, die eigentlich schon genug damit zu tun haben müsste, Sinus und Kosinus zu berechnen und dadurch sinkt dann gern mal über sechs Takte die ALU-Auslastung in den Keller.
Das ist aber immernoch das geringste Problem – Optimierungen im Promillebereich, weil der Shader so ca. 80 % seiner Zeit nicht mit den 400 Rechenanweisungen verbringt, sondern mit den acht Schreiboperationen in den Hauptspeicher, da der tolle Compiler sich ja noch immer vehement weigert, die richtige Schreiboperation anzuwenden.
Zumindest scheine ich nicht der Einzige zu sein, der Probleme damit hat …
http://forum.beyond3d.com/showthread.php?t=54842 hat geschrieben:The major difficulty is to trick ATi's horrible compiler (which reflects the current quality of their `GPU computing' software stack well) into producing decent machine code.
Ich liebe das „called at least twice“. Im D3D-Forum wollten sie mir ja nicht glauben, dass ihr Scheißteil kaputt geht, wenn man Dinge öfter als einmal tut. Was aber eigentlich der Sinn von Funktionen ist.
Re: Jammer-Thread
Verfasst: 20.02.2011, 21:28
von Krishty
float2 temp[4] = { foo(0), foo(1), foo(2), foo(3) };
global[delta * 0 + base] = length(temp[0]) / bar;
global[delta * 1 + base] = length(temp[1]) / bar;
global[delta * 2 + base] = length(temp[2]) / bar;
global[delta * 3 + base] = length(temp[3]) / bar;
liefert komplett andere (lies: falsche) Ergebnisse gegenüber global[delta * 0 + base] = length(foo(0)) / bar;
global[delta * 1 + base] = length(foo(1)) / bar;
global[delta * 2 + base] = length(foo(2)) / bar;
global[delta * 3 + base] = length(foo(3)) / bar;
Und zwar nicht in temp, sondern in den Indizes, mit denen der globale Speicher adressiert wird …
Okay; als ich den Bytecode für meine Fehlermeldung auseinandergenommen habe, fiel mir auf, dass ich eine Wirkung übersehen hatte. Diesmal waren sie also unschuldig. Muss man dann ja auch zugeben.
Weitergejammert:
Ich habe zwei Shader mit einem Absturz und einer Endlosschleife im Treiber verloren – die hatte ich aufbewahrt, weil ich direkt drei Fehler auf einmal melden wollte. Mist. Also wieder bei Null anfangen.
Eine 27-%-Leistungsverbesserung schrumpft bei vierfacher Auflösung auf 13 %. Ich hasse falsche Hoffnung.Jede Hoffnung ist falsch; ich hasse Hoffnung.
Re: Jammer-Thread
Verfasst: 22.02.2011, 17:24
von Krishty
Heute mal kein Gejammer! Ich will nur zum Ausdruck bringen, wie froh ich bin. Froh, dass 2D-UAVs in Compute Shadern mit einem Achtel der Leistung laufen.
AMD ist in jeder Hinsicht professionell und kompetent, wenn es um GPGPU-Anwendungen geht. Mindestens marktführend, vielleicht sogar wegweisend. Von einem Compiler, der nahezu zufällige Ergebnisse produziert, über Analyse-Tools, die im besten Fall widersprüchliche und im schlimmsten falsche Informationen ausgeben, über Profiler, die nicht starten, bis hin zu Kunden-Support, der einen über Monate mit geradezu euphorischem Engagement ignoriert.
Ich verstehe auch beim besten Willen nicht, warum folding@home seit fünf Jahren einen funktionierenden Nvidia-Client hat, der ATI-Client aber schon seit drei Generationen (Brook+, CAL, OpenCL) in einem Sumpf von Fehlern, unzumutbarem Installationsaufwand und unerklärlichen Leistungstiefs dahindümpelt.
Re: Jammer-Thread
Verfasst: 23.02.2011, 20:29
von Krishty
Jetzt direkt mal weiter mit Nvida: Die bieten überhaupt keinen nennenswerten Support. Abgesehen von einigen Seiten Geschwafel, wie marktführend ihre breiten Angebote zu DirectCompute seien, gibt es absolut nichts außer einem verwaisten Forum. Die Tools, die mit HLSL arbeiten, sind seit einem Jahr nicht mehr aktualisiert worden und kennen überhaupt keine Compute Shader. Während der Compute Shader-Support bei AMD unaussprechlich schlecht ist, ist er bei Nvidia nicht einmal existent.
Wer doch Compute Shader-Werkzeuge von Nvidia kennt (für die man kein registrierter Partner sein muss), der möge mich bitte umgehend etwas Besserem belehren.
AMD hat sowas btw auch (APP Profiler). Stürzt aber bei mir jedes Mal in D3D11CreateDevice() ab, oh Freunde -.-
Re: Jammer-Thread
Verfasst: 01.03.2011, 14:48
von Krishty
Um auf die Print-Taste zu reagieren muss man nicht VK_PRINT abfragen, sondern VK_SNAPSHOT. Von mir aus. Aber dann wird der Code niemals für Key-Down-Ereignisse geschickt, sondern ausschließlich für Key-Up. Wie soll man da drauf kommen?!
estimated frame time is 8.96645e-002 ms (11.1527 fps)
estimated frame time is 8.50109e-002 ms (11.7632 fps)
estimated frame time is 1.63844e-003 ms (610.336 fps)
estimated frame time is 8.55667e-002 ms (11.6868 fps)
estimated frame time is 1.9216e-002 ms (52.0399 fps)
estimated frame time is 2.09322e-002 ms (47.7733 fps)
estimated frame time is 2.08897e-002 ms (47.8706 fps)
estimated frame time is 2.09381e-002 ms (47.7599 fps)
Am Ende kommen bei beidem 50 fps raus. Allerdings wird die vertikale Synchronisation bei aktivem Flash vier Frames lang komplett zurückgehalten, geschieht dann vier Mal quasi in Nullzeit, dann wieder vier Mal träge wie nichts. Das Resultat sind extrem unrunde Bewegungen und Flackern. Ich drehe irgendwann noch durch.
Dieses Diagramm über die Frame-Zeit hatte ich vor ein paar Monaten aufgenommen (sry, dass es so schwarz ist, aber es war nachts):
timegjsd.png (6.87 KiB) 5403 mal betrachtet
Sowas kann man auch nicht mehr glätten. Einfach furchtbar.
Re: Jammer-Thread
Verfasst: 01.03.2011, 15:15
von CodingCat
Bedeutet Flash "aktiv", dass du irgendwelche Flash-Sachen im Browser offen hast, oder läuft da was im Hintergrund? Ich hatte nämlich solche extremen Zeitvarianzen auch schon mehrfach in meinen Programmen, die ich dann witzigerweise durch "Normalisierung" der Frame-Zeit, sprich Obergrenze für die Frame-Rate, relativ gut in den Griff bekommen habe. Allerdings hing das noch mit V-Sync zusammen, Present ist mit V-Sync schlicht enorm unregelmäßig zurückgekehrt, nach allgemeiner Begrenzung der Frame-Zeit auf den zuvor gemessenen Durchschnitt dagegen dann recht zuverlässig regelmäßig, was den Bewegungsfluss extrem verbessert hat. Das war allerdings auch DX9. ;-)
Ich habe vor, das demnächst, wenn ich mal Zeit habe, in eine Art automatische Zeit-Glättung umzubauen, praktisch Frame-Zeit-Begrenzung mit Live-Feedback.
EDIT: Könnte es sein, dass Flash da irgendwas an irgendwelchen internen Timern dreht? Irgendwie scheint die automatische Synchronisation ja vollends zerstört, der beschriebene Workaround "übernimmt" im Grunde genau diese "Synchronisation".
Re: Jammer-Thread
Verfasst: 01.03.2011, 15:20
von Krishty
Flash aktiv bedeutet, dass das Flash-Plugin meines Browsers läuft.
Noch schlimmer ist das übrigens mit YouTube-Videos – da habe ich nicht nur extrem unregelmäßige Framerates, sondern außerdem nur noch 50 % der theoretischen GPU-Leistung. (Andere Videoportale machen nicht so viele Probleme; wenn ich das Flash-Plugin abschieße kann ich mir auch zehn Videos in HTML5 angucken ohne, dass die Framerate zuckt. Ist dann regelmäßig wie die Periode einer russischen Bibliothekarin.)
CodingCat hat geschrieben:EDIT: Könnte es sein, dass Flash da irgendwas an irgendwelchen internen Timern dreht? Irgendwie scheint die automatische Synchronisation ja vollends zerstört, der beschriebene Workaround "übernimmt" im Grunde genau diese "Synchronisation".
Bestimmt. Was mir aber Angst macht ist, dass das außer mir niemand reproduzieren kann. Meine Maschine scheint die einzige zu sein, wo Flash so amok läuft.
Re: Jammer-Thread
Verfasst: 07.03.2011, 01:35
von eXile
Wirklich, Microsoft, wirklich?
Re: Jammer-Thread
Verfasst: 07.03.2011, 01:46
von Chromanoid
ähnlich geil von Adobe (natürlich per default aktiviert):
wirft irgendwie auch kein gutes licht auf die sicherheit von flash :)
Re: Jammer-Thread
Verfasst: 07.03.2011, 01:49
von Aramis
Na wenigstens sind beim DX SDK die Nutzungsbedingunge n verlinkt.
Re: Jammer-Thread
Verfasst: 07.03.2011, 01:53
von Krishty
@Bing: War schon lustig, als das vor vier Monaten angekündigt wurde. Wer sich (außer auf Chucks Blog noch sonstwo) beschweren möchte: DirectX 11-Forum (Zurkenntnisnahme am wenigsten unwahrscheinlich) Mailing-List (Kaum Leser, also kümmert es sie einen Scheiß) Connect (Live-ID erforderlich; wird nur einmal im Jahr gelesen und dann im übertragenen Sinne mit fuck you beantwortet)
Wenn man auf allen Kommunikationswegen genug nervt ändert sich im überübernächsten Release vielleicht wieder was.
Re: Jammer-Thread
Verfasst: 07.03.2011, 16:20
von Top-OR
Ooooh, ein Jammer-Thread - toll! Den werd ich bestimmt bald mal in Anspruch nehmen.
Leider [<-- hihihihihihi ;-) ] habe ich gerade nichts zu jammern. Wirklich schade eigentlich...
Re: Jammer-Thread
Verfasst: 07.03.2011, 16:31
von Aramis
Du strengst dich nicht genug an. Auf geht's, jammern! ;-)
Re: Jammer-Thread
Verfasst: 10.03.2011, 13:54
von Krishty
saturate() im Shader ist nicht kostenlos
An was kann ich jetzt überhaupt noch glauben
Re: Jammer-Thread
Verfasst: 10.03.2011, 14:51
von Lynxeye
Was? Seit wann das denn? Sowas wäre mir neu, auch wenn ich mich schon länger nicht mehr damit befasst habe.
Re: Jammer-Thread
Verfasst: 10.03.2011, 14:51
von Schrompf
Nicht? Du rüttelst an meinem Weltbild!
Re: Jammer-Thread
Verfasst: 10.03.2011, 14:53
von Matthias Gubisch
Du rüttelst hier an einigen Weltbildern, ja auch an meinem :P
Kannst du uns mitteilen wie du zu dieser weltverändernden Erkenntnis gekommen bist?
float4 computeTexel(
in const float4 unreferenced : SV_Position, // unable to access 'Texcoord0' without a dummy for 'SV_Position'
in const float2 itsTexturePosition : Texcoord0
) : SV_Target0 {
// The sprite's coordinate system has its origin on the negative Z axe, where height and azimuth are both zero. The
// texture's coordinate system, however, has its origin on the *positive* Z axe. Therefore, we must perform a 180°
// rotation around the Y axe, which can be expressed as a multiplication by (-1, 1, -1).
const float3 cubicPosition = float3(
-itsTexturePosition.x,
itsTexturePosition.y,
/*===========>*/ -sqrt(saturate(1.0f - dot(itsTexturePosition.xy, itsTexturePosition.xy)))
);
// Use the cubic position to sample the albedo. The scale factor is used to store MDR data in a LDR texture.
const float3 albedo = albedoTextureCube.Sample(anisotropic, cubicPosition);
// Use the cubic position to sample the normal from the object-space normal map. The minimum erases all normals facing
// away from the observer. Without it, craters on the back of the moon would lighten up the sprite unrealistically.
const float3 normal = min(float3(1.0f, 1.0f, 0.0f), normalTextureCube.Sample(anisotropic, cubicPosition));
const float3 sunshine = pow(saturate(dot(normal, sunshinesDirection)), 0.55f) * sunshinesIlluminance;
const float3 earthshine = earthshinesIlluminance;
return float4((earthshine + sunshine) * albedo, 1.0f);
}
Name,GPR,Scratch Reg,Interp,VTX,ALU,TEX,CF,EMIT,EXP,Throughput(Pt)
Radeon HD 5870,3,0,1,0,18,2,4,0,1,15111 M Threads\Sec
Radeon HD 6970,3,0,1,0,18,2,5,0,1,18773 M Threads\Sec
Maschinentext:
Name,GPR,Scratch Reg,Interp,VTX,ALU,TEX,CF,EMIT,EXP,Throughput(Pt)
Radeon HD 5870,3,0,1,0,17,2,4,0,1,16000 M Threads\Sec
Radeon HD 6970,3,0,1,0,17,2,5,0,1,19878 M Threads\Sec
Maschinentext:
Schuld ist MIN_DX10 gegen 1.0f in ALU-Takt #3 – was ironisch ist, weil saturate() an dieser Stelle vor allem negative Werte verhindern sollte, und nicht etwa Werte über 1
Aber hey – in vier von fünf Fällen ist es immernoch gratis! Ich hasse alles
Re: Jammer-Thread
Verfasst: 10.03.2011, 15:53
von Lynxeye
Oh man, du hast mal wieder einen Bug im AMD Shadercompiler getroffen, denn auch die aktuellen Radeons können sat() als kostenlose Postop. Allerdings scheint der schon seit 2009(!) zu bestehen. Diese Abteilung von AMDs Treiberteam scheint öfters mal ziemlichen Müll zu verzapfen.
Ja, heute ist hochfrequent … aber: An meinem Das Keyboard II sind die NumLock-, CapsLock- und Weißnichtwasdasdrittebedeutet-Dioden kaputtgegangen. Das ist der Anfang vom Ende von allem. Das wird nämlich nicht mehr produziert. Und ich habe versäumt, mir ein Zweites auf Halde zu kaufen. Ihr könnt mir also auch gleich die Finger abhacken, denn mit was anderem tippe ich nicht.
Sieht so aus, als müsste ich ab nächstem Monat im Stephen-Hawking-Style programmieren.
Re: Jammer-Thread
Verfasst: 10.03.2011, 16:45
von Chromanoid
Krishty hat geschrieben:Ja, heute ist hochfrequent … aber: An meinem Das Keyboard II sind die NumLock-, CapsLock- und Weißnichtwasdasdrittebedeutet-Dioden kaputtgegangen. Das ist der Anfang vom Ende von allem. Das wird nämlich nicht mehr produziert. Und ich habe versäumt, mir ein Zweites auf Halde zu kaufen. Ihr könnt mir also auch gleich die Finger abhacken, denn mit was anderem tippe ich nicht.
Sieht so aus, als müsste ich ab nächstem Monat im Stephen-Hawking-Style programmieren.
Ich selber habe einige Ausflüge ins Kernel-Land unternommen, sogar mich mal mit dem WDM unter Windows XP befasst. Es ist einfach unglaublich, zu denken, dass entry level Entwickler mit sowas zurechtkämen -- man muss alles selber machen, wenn es einem nicht gerade von Windows gegeben wird. Verkettete Listen per Hand basteln? Warum nicht!
Krishty hat geschrieben:Ja, heute ist hochfrequent … aber: An meinem Das Keyboard II sind die NumLock-, CapsLock- und Weißnichtwasdasdrittebedeutet-Dioden kaputtgegangen.
Die Weißnichtwasdasdrittebedeutet-Taste ist die Scroll-Lock-Taste. Wenn man die aktiviert, bewegt man mit den Pfeil-Hoch- bzw. Pfeil-Runter-Tasten den gesamten Bildausschnitt, und nicht den Cursor. Das ist extrem praktisch, wenn man kurz (fremden) Code überfliegen möchte. Leider unterstützen das die wenigsten Programme, noch nicht einmal Visual Studio. Dafür gibt es dort aber die Strg+Pfeil-Nach-Oben- bzw. Strg+Pfeil-Nach-Unten-Taste ;)
Ich selber präferiere übrigens Notebook-ähnliche Tastaturen mit flachen Tasten, aber das ist ja eine individuelle, subjektive Einstellung.
