Prüfung eines Bitmaps auf Transparenz (gehts noch schneller)?

[Harry Stahl]

Zitat von Amateurprofi:

Ich mach das alles nur aus Jux und Dallerei, aus Spaß an der Sache eben.

Kann ich verstehen, betriebswirtschaftlich ist das für mich auch wenig sinnvoll, aber ist eben interessant.

Mir ist bei Deinem Testprogramm noch aufgefallen, dass bei SSEex die falsche Prozedur aufgerufen wird:

Delphi-Quellcode:

{------------------------------------------------------------------------------}
{ IsPartlyTransparentSSEex                                                     }
{------------------------------------------------------------------------------}
FUNCTION IsPartlyTransParentSSEex(Bmp:TBitMap):Boolean;
var P1,P2:Pointer;
begin
   with Bmp do begin
      if PixelFormat<>pf32bit then raise Exception.Create('Keine 32 Bit Bitmap');
      P1:=ScanLine[0];
      if Height>1 then P2:=ScanLine[1] else P2:=P1;
      Result:=IsPartlyTransparentAsm(P1,P2,Width,Height);
   end;
end;

Die SSEex ist hier übrigens bei mir die schnellste Variante, im Vergleich zu meiner Standard-Variante mit ca. 23 MS braucht die SSEex ziemlich zuverlässig nur ca. 17 MS, das ist schon eine erhebliche Steigerung.

Ab wann kann man SSE nutzen, bzw. wie kann ich das prüfen, ob diese Funktionalität auf dem Rechner vorhanden ist?

[Memnarch]

Die schwankungen zwischen Debug/Release kann ich mir nur so erklären:

Die Bitmap braucht im speicher mehr als 30MB. Der debugcode läuft (zumindest bei mir) langsamer. Fluktuationen beim fetchen der Daten und inteferenzen durch andere Prozesse die gerade arbeiten verlaufen auf dem längeren Zeitraum. Release ist aber (bei meiner Variante) dann deutlich schneller. Wenn es dann beim durchlaufen des speichers verzögerungen gibt sieht man das eher.

[Amateurprofi]

Zitat von Memnarch:

Die schwankungen zwischen Debug/Release kann ich mir nur so erklären:

Die Bitmap braucht im speicher mehr als 30MB. Der debugcode läuft (zumindest bei mir) langsamer. Fluktuationen beim fetchen der Daten und inteferenzen durch andere Prozesse die gerade arbeiten verlaufen auf dem längeren Zeitraum. Release ist aber (bei meiner Variante) dann deutlich schneller. Wenn es dann beim durchlaufen des speichers verzögerungen gibt sieht man das eher.

Nee, wie in meinem vorigen Beitrag beschrieben liegt das wohl eher daran dass das Programm auf mehreren CPUs läuft und jede der CPUs einen eigenen TSC hat. Harry verwendet ja QPF, ich sowohl QPF wie auch TSC.
Nach Fixieren des Hauptthreads auf eine CPU ist das Problem beseitigt, na ich bin mal vorsichtig, also : scheint das Problem beseitigt zu sein.

[Amateurprofi]

Zitat von Harry Stahl:

Zitat von Amateurprofi:

Ich mach das alles nur aus Jux und Dallerei, aus Spaß an der Sache eben.

Kann ich verstehen, betriebswirtschaftlich ist das für mich auch wenig sinnvoll, aber ist eben interessant.

Mir ist bei Deinem Testprogramm noch aufgefallen, dass bei SSEex die falsche Prozedur aufgerufen wird:

Delphi-Quellcode:

{------------------------------------------------------------------------------}
{ IsPartlyTransparentSSEex                                                     }
{------------------------------------------------------------------------------}
FUNCTION IsPartlyTransParentSSEex(Bmp:TBitMap):Boolean;
var P1,P2:Pointer;
begin
   with Bmp do begin
      if PixelFormat<>pf32bit then raise Exception.Create('Keine 32 Bit Bitmap');
      P1:=ScanLine[0];
      if Height>1 then P2:=ScanLine[1] else P2:=P1;
      Result:=IsPartlyTransparentAsm(P1,P2,Width,Height);
   end;
end;

Die SSEex ist hier übrigens bei mir die schnellste Variante, im Vergleich zu meiner Standard-Variante mit ca. 23 MS braucht die SSEex ziemlich zuverlässig nur ca. 17 MS, das ist schon eine erhebliche Steigerung.

Ab wann kann man SSE nutzen, bzw. wie kann ich das prüfen, ob diese Funktionalität auf dem Rechner vorhanden ist?

Hallo Harry,
oh wie peinlich, das mit dem Aufruf von IsPartlyTransparentAsm statt IsPartlyTransparentAsmSSEex, andererseits schön, dass da jemand ist, der meine Machwerke anschaut.

Ja, was "kann" die CPU?
Ich hab heute Nacht meine zweite Doktorarbeit geschrieben - über CPUID!
Also:
Diese Infos kriegst du über den Asm-Befehl CPUID.
Aber zunächst mal musst du prüfen, ob der überhaupt unterstützt wird.
Mit PUSHFD und POP EAX bzw. bei 64Bit mit PUSHFQ und POP RAX kopierst du das EFLAGS Register nach EAX bzw. RAX.
Wenn dann in EAX Bit 21 = 1 ist wird CPUID unterstützt.
Interessanterweise ist bei mir im 64 Bit Mode Bit 21 = 0, aber CPUID wird trotzdem unterstützt.
Das folgende gilt sowohl für 32 wie auch 64 Bit.
Mit
MOV EAX,1
CPUID
werden diverse Infos in EAX,EBX,ECX und EDX gestellt.
EDX Bit 0 : Auf dem Chip ist eine FPU
EDX Bit 23 : MMX wird unterstützt
EDX Bit 25 : SSE wird unterstützt
EDX Bit 26 : SSE2 wird unterstützt
ECX Bit 0 : SSE3 wird unterstützt
EBX Bits 16..23 : Anzahl logische CPUs
Das ganze ist etwa tricky, weil EBX bzw. RBX nicht verändert werden darf, musst also EBX/RBX vorher pushen und vor verlassen der Funktion wieder popen (nicht zu verwechseln mit "poppen").
Ich hab mein Programm aktualisiert.
In der Caption steht jetzt auch, was unterstützt wird und wieviel logische CPUs vorhanden sind.
Letzteres hole ich aber nicht über CPUId sondern über GetSystemInfo.

Bei Interesse kannst Du Dir bei Intel oder auch bei AMD die Manuals runterladen.
Bei Intel : "Intel 64 and IA-32 Architectures Software Developer's Manual Volume 2A und 2B"

Dann war da ja noch das Problem mit den recht großen Abweichungen.
Dass liegt daran dass das Programm auf mehreren CPUs läuft und jede CPU ihren eigenen Time Stamp Counter hat.
Ich wollte ja bisher nie so recht glauben, dass sich das auswirkt.
Aber nachdem ich den Hauptthread auf eine CPU festgelegt hatte, war das Problem mit den Abweichungen verschwunden.
Schau die die Prozedur TMain.btTestClick an, da siehst du wie das funktioniert.