Jammer-Thread

[RustySpoon]

float toFloat(const uint integer) { // 0…2047
return asfloat(asuint(2048.0f) | integer)) - 2048.0f;
}

Kann es sein, dass da eine Klammer zuviel reingerutscht ist? Nur um dir den nächsten Jammer-Post zu ersparen. ;)

[Krishty]

Jaa, war aus dem Kopf geschrieben. Ist korrigiert; danke.

Nachtrag: Die Sache ist quatsch. Da kommt keine float-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[

[Jörg]

float toFloat(const uint integer) { // 0…2^23-1
return asfloat(0x4B000000 | integer) - 8388608.f;
}

[Krishty]

(In einem langen Shader)

Code: Alles auswählen

const float cache[2] = { … };
for(uint i = 0; i < 2; ++i)
	groupSharedMem[x + i] = cache[i];

Die Schleife wird vom Compiler abgerollt – Programm benutzt 10 Register und 156 ALU-Takte

Code: Alles auswählen

const float cache[2] = { … };
groupSharedMem[x + 0] = cache[0];
groupSharedMem[x + 1] = cache[1];

Programm benutzt 8 Register (-20 %) und 188 ALU-Takte (+21 %)

Ich habe das Gefühl, dass AMDs Optimizer sehr oft rand() benutzt. Ist GPGPU nicht was Schönes? Total ausgereift, konstistent und idiotensicher.

Diese frisch gesprossene Textstelle sieht auch schön aus:

Code: Alles auswählen

     64  y: MOV         R2.y,  QA[60]      
     65  y: MOV         R3.y,  QB[60].pop      VEC_120 
     66  y: MOV         R1.y,  QA[61]      
     67  y: MOV         R0.y,  QB[61].pop      VEC_120 
     68  x: MOV         R0.x,  QA[62]      
     69  x: MOV         R1.x,  QB[62].pop      VEC_120 
     70  x: MOV         R2.x,  QA[63]      
     71  x: MOV         R5.x,  QB[63].pop      VEC_120 

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.

[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 …

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.

Ach, und weil Direct3D auch nicht besser ist:
static const bool inverse = true; // error X4555: cannot use casts on l-values
static const uint inverse = 1; // OK
Möge Gott ihren armen Seelen gnädig sein; ich bin es jedenfalls nicht: cannot hide bool parameter with static const bool variable of same name in inner scope if the constant is passed to a function expecting a const bool and the affected function is called at least twice (Live-Anmeldung erforderlich weil die nicht wollen, dass man öffentlich sieht, wie sie uns auf den Kopf kacken)

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.

[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.

[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.

Unter OpenCL sind 2D-UAVs nämlich unterstützt, aber überhaupt nicht implementiert.

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.

[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.

[anonym]

Hast Du das hier gesehen?

[Krishty]

Dafür braucht man einen Nvidia-Karte :/

AMD hat sowas btw auch (APP Profiler). Stürzt aber bei mir jedes Mal in D3D11CreateDevice() ab, oh Freunde -.-

[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?!

————

Flash aktiv:

Code: Alles auswählen

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)

Flash deaktiviert:

Code: Alles auswählen

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) 5386 mal betrachtet

Sowas kann man auch nicht mehr glätten. Einfach furchtbar.

[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".

[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.)

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.

[eXile]

Wirklich, Microsoft, wirklich?

[Chromanoid]

ähnlich geil von Adobe (natürlich per default aktiviert):

wirft irgendwie auch kein gutes licht auf die sicherheit von flash :)

[Aramis]

Na wenigstens sind beim DX SDK die Nutzungsbedingunge n verlinkt.

[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.

[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...

[Aramis]

Du strengst dich nicht genug an. Auf geht's, jammern! ;-)

[Krishty]

saturate() im Shader ist nicht kostenlos

An was kann ich jetzt überhaupt noch glauben

[Lynxeye]

Was? Seit wann das denn? Sowas wäre mir neu, auch wenn ich mich schon länger nicht mehr damit befasst habe.

[Schrompf]

Nicht? Du rüttelst an meinem Weltbild!

[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?

[Krishty]

saturate() in Zeile 11:

Code: Alles auswählen

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:

Code: Alles auswählen

 --------  Disassembly --------------------
00 ALU: ADDR(32) CNT(22) 
      0  x: INTERP_XY   T0.x,  R0.y,  Param0.x      VEC_210 
         y: INTERP_XY   T0.y,  R0.x,  Param0.x      VEC_210 
         z: INTERP_XY   ____,  R0.y,  Param0.x      VEC_210 
         w: INTERP_XY   ____,  R0.x,  Param0.x      VEC_210 
      1  x: MOV         T1.x, -PV0.x      
         y: MOV         T1.y,  PV0.y      
         z: MUL_e       ____,  PV0.x,  PV0.x      
         w: MOV         R2.w,  (0x3F800000, 1.0f).x      
      2  y: MULADD_e    ____,  T0.y,  T0.y,  PV1.z      
      3  x: MIN_DX10    ____,  PV2.y,  1.0f      
      4  w: ADD         ____, -PV3.x,  1.0f      
      5  t: SQRT_e      ____,  PV4.w      
      6  z: MOV         T1.z, -PS5      
      7  x: CUBE        R0.x,  PV6.z,  T1.y      
         y: CUBE        R0.y,  PV6.z,  T1.x      
         z: CUBE        R0.z,  T1.x,  PV6.z      
         w: CUBE        R0.w,  T1.y,  PV6.z      
      8  t: RCP_e       ____,  |PV7.z|      
      9  x: MULADD      R0.x,  R0.x,  PS8,  (0x3FC00000, 1.5f).x      
         y: MULADD      R0.y,  R0.y,  PS8,  (0x3FC00000, 1.5f).x      
01 TEX: ADDR(80) CNT(2) VALID_PIX 
     10  SAMPLE R1.xyz_, R0.yxwy, t1, s0
     11  SAMPLE R0.xyz_, R0.yxwy, t0, s0
02 ALU: ADDR(54) CNT(25) KCACHE0(CB0:0-15) 
     12  x: MIN_DX10    ____,  R1.x,  1.0f      
         y: MIN_DX10    ____,  R1.y,  1.0f      
         z: MIN_DX10    ____,  R1.z,  0.0f      
         w: MUL_e       T0.w,  R0.x,  KC0[0].z      VEC_120 
         t: MUL_e       T1.z,  R0.y,  KC0[0].z      
     13  x: DOT4_e      ____,  PV12.x,  KC0[1].x      CLAMP 
         y: DOT4_e      ____,  PV12.y,  KC0[1].y      CLAMP 
         z: DOT4_e      ____,  PV12.z,  KC0[1].z      CLAMP 
         w: DOT4_e      ____,  (0x80000000, -0.0f).x,  0.0f      CLAMP 
     14  w: MUL_e       T1.w,  R0.z,  KC0[0].z      
         t: LOG_e       ____,  PV13.x      
     15  w: MUL_e       ____,  PS14,  (0x3F0CCCCD, 0.5500000119f).x      
     16  t: EXP_e       ____,  PV15.w      
     17  x: MUL_e       ____,  PS16,  KC0[2].y      
         y: MUL_e       ____,  PS16,  KC0[2].x      
         w: MUL_e       ____,  PS16,  KC0[2].z      
     18  x: MULADD_e    ____,  PV17.w,  (0x3EA2F983, 0.3183098733f).x,  KC0[3].z      
         y: MULADD_e    ____,  PV17.x,  (0x3EA2F983, 0.3183098733f).x,  KC0[3].y      
         z: MULADD_e    ____,  PV17.y,  (0x3EA2F983, 0.3183098733f).x,  KC0[3].x      
     19  x: MUL_e       R2.x,  T0.w,  PV18.z      
         y: MUL_e       R2.y,  T1.z,  PV18.y      
         z: MUL_e       R2.z,  T1.w,  PV18.x      VEC_120 
03 EXP_DONE: PIX0, R2
END_OF_PROGRAM

Ohne dieses saturate():

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:

Code: Alles auswählen

 --------  Disassembly --------------------
00 ALU: ADDR(32) CNT(21) 
      0  x: INTERP_XY   T0.x,  R0.y,  Param0.x      VEC_210 
         y: INTERP_XY   T0.y,  R0.x,  Param0.x      VEC_210 
         z: INTERP_XY   ____,  R0.y,  Param0.x      VEC_210 
         w: INTERP_XY   ____,  R0.x,  Param0.x      VEC_210 
      1  x: MOV         T1.x, -PV0.x      
         y: MUL_e       ____,  PV0.x,  PV0.x      
         w: MOV         T1.w,  PV0.y      
         t: MOV         R2.w,  (0x3F800000, 1.0f).x      
      2  x: MULADD_e    ____,  T0.y,  T0.y,  PV1.y      
      3  w: ADD         ____, -PV2.x,  1.0f      
      4  t: SQRT_e      ____,  PV3.w      
      5  z: MOV         T1.z, -PS4      
      6  x: CUBE        R0.x,  PV5.z,  T1.w      
         y: CUBE        R0.y,  PV5.z,  T1.x      
         z: CUBE        R0.z,  T1.x,  PV5.z      
         w: CUBE        R0.w,  T1.w,  PV5.z      
      7  t: RCP_e       ____,  |PV6.z|      
      8  x: MULADD      R0.x,  R0.x,  PS7,  (0x3FC00000, 1.5f).x      
         y: MULADD      R0.y,  R0.y,  PS7,  (0x3FC00000, 1.5f).x      
01 TEX: ADDR(80) CNT(2) VALID_PIX 
      9  SAMPLE R1.xyz_, R0.yxwy, t1, s0
     10  SAMPLE R0.xyz_, R0.yxwy, t0, s0
02 ALU: ADDR(53) CNT(25) KCACHE0(CB0:0-15) 
     11  x: MIN_DX10    ____,  R1.x,  1.0f      
         y: MIN_DX10    ____,  R1.y,  1.0f      
         z: MIN_DX10    ____,  R1.z,  0.0f      
         w: MUL_e       T1.w,  R0.x,  KC0[0].z      VEC_120 
         t: MUL_e       T1.z,  R0.y,  KC0[0].z      
     12  x: DOT4_e      ____,  PV11.x,  KC0[1].x      CLAMP 
         y: DOT4_e      ____,  PV11.y,  KC0[1].y      CLAMP 
         z: DOT4_e      ____,  PV11.z,  KC0[1].z      CLAMP 
         w: DOT4_e      ____,  (0x80000000, -0.0f).x,  0.0f      CLAMP 
     13  w: MUL_e       T0.w,  R0.z,  KC0[0].z      
         t: LOG_e       ____,  PV12.x      
     14  w: MUL_e       ____,  PS13,  (0x3F0CCCCD, 0.5500000119f).x      
     15  t: EXP_e       ____,  PV14.w      
     16  x: MUL_e       ____,  PS15,  KC0[2].y      
         y: MUL_e       ____,  PS15,  KC0[2].x      
         w: MUL_e       ____,  PS15,  KC0[2].z      
     17  x: MULADD_e    ____,  PV16.w,  (0x3EA2F983, 0.3183098733f).x,  KC0[3].z      
         y: MULADD_e    ____,  PV16.x,  (0x3EA2F983, 0.3183098733f).x,  KC0[3].y      
         z: MULADD_e    ____,  PV16.y,  (0x3EA2F983, 0.3183098733f).x,  KC0[3].x      
     18  x: MUL_e       R2.x,  T1.w,  PV17.z      
         y: MUL_e       R2.y,  T1.z,  PV17.y      
         z: MUL_e       R2.z,  T0.w,  PV17.x      VEC_120 
03 EXP_DONE: PIX0, R2
END_OF_PROGRAM

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

[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.

[Krishty]

http://blogs.msdn.com/b/oldnewthing/arc ... 49735.aspx
Mittlerweile bin ich mir sicher, zu wissen, welche Firma das war

[Krishty]

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.

[Chromanoid]

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.

http://www.daskeyboard.com/products/ ?

[eXile]

http://blogs.msdn.com/b/oldnewthing/arc ... 49735.aspx
Mittlerweile bin ich mir sicher, zu wissen, welche Firma das war

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!

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.

[Krishty]

@C ds st ales mdel s
ds wll ich ncht
wll dk2

(spare anshlge; mtrialschonung)