Ausschließlich GPU verwenden

[Medium]

Dann wird der Flaschenhals wohl wirklich (vermutlich) in dem Erzeugen des Inhaltes des VisInfo^.VisBuf liegen. Alles was da passiert ist ja noch konventionelle GDI nehme ich an. Das bloße Ändern des Weges zum Framebuffer alleine wird da minimal an CPU Zeit sparen. Kommst du mit deinen FPS ans VSync ran, oder liegst du darunter? Wenn drunter, dann nudelt die Bilderzeugung höchstwahrscheinlich zu langsam und braucht definitiv Magnituden länger als sowohl das BitBlt als auch ein OGL Quad.

Alles das was zur Erzeugung des Inhaltes von VisBuf passiert einfach so auf die GPU auszulagern geht nicht. GPUs arbeiten völlig anders als herkömmliche CPUs und verstehen kein x86 oder x64 Code. Das müsste man in Handarbeit in Shader oder OpenCL portieren, und höchstwahrscheinlich auch stark umstrukturieren, da man sonst aus der Parallelität von GPUs keinen Nutzen ziehen kann. (Und ohne das sind die auch nicht schneller als eine CPU - im Gegenteil.)

Einfach zur Ausgabe das Bild auf ein Quad werfen bringt im Vergleich zu einem BitBlt verschwindend wenig. Beides sind sehr flotte Operationen, und werden durch die Bilderzeugung sehr wahrscheinlich zum Zwerg im Gesamtvorgang. Je nach dem was du da so alles malst natürlich.

[EWeiss]

Danke für die Ausführlichen Informationen.
Theoretisch würde es gehn (vermutung) wenn ich OpenCL mit einbinden würde.
Aber ne extra DLL dafür? Dann lass ich es mal so wie es ist.

Zitat:

Alles was da passiert ist ja noch konventionelle GDI nehme ich an.

Jo das ist korrekt.

Delphi-Quellcode:

  FillChar(BmpInfo, SizeOf(BITMAPINFO), 0);
  BmpInfo.bmiHeader.biSize     := SizeOf(BITMAPINFOHEADER);
  BmpInfo.bmiHeader.biWidth    := nw;
  BmpInfo.bmiHeader.biHeight   := -nh -2;
  BmpInfo.bmiHeader.biPlanes   := 1;
  BmpInfo.bmiHeader.biBitCount := 32;

  VisBmp := CreateDIBSection(0, BmpInfo, DIB_RGB_COLORS, VisBuf, 0, 0);
  VisDC  := CreateCompatibleDC(0);
  if (VisBmp = 0) or (VisBuf = nil) or (VisDC = 0) then
  begin
    if (VisBmp <> 0) then
      DeleteObject(VisBmp);
    if (VisDC <> 0) then
      DeleteDC(VisDC);

    BassFuncs^.SetError(DWORD(BASS_ERROR_UNKNOWN));
    Exit;
  end;

Hab da aber durch das testen noch einen Schwerwiegenden fehler entdeckt.
Das

Delphi-Quellcode:

   glTexSubImage2D (GL_TEXTURE_2D, 0, 0, 0, VisInfo^.w, VisInfo^.h,
     GL_BGRA_EXT, GL_UNSIGNED_BYTE, VisInfo^.VisBuf);

kann nicht gehn
dabei war es vorher richtig

Delphi-Quellcode:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, VisInfo^.w, VisInfo^.h, 0,
       GL_BGRA_EXT, GL_UNSIGNED_BYTE, VisInfo^.VisBuf);

War eins der probleme zum Beispiel beim resitz.

Zitat:

Kommst du mit deinen FPS ans VSync ran

Sorry wie kann ich das feststellen?
Grundsätzlich denke ich erstmal nein weil ich das Timing auf 25 ms gesetzt habe.
Bei 16ms komme ich an die 60 FPS nur im Vollbild läßt sich dann die Anwendung nicht wieder zurückschalten
Key eingaben schlagen dann fehl.



gruss

[Medium]

Zitat von EWeiss:

Theoretisch würde es gehn (vermutung) wenn ich OpenCL mit einbinden würde.

Ganz so einfach ist es leider nicht. OpenCL ist eine komplett eigene Sprache, d.h. man müsste völlig neuen Code fabrizieren, der zudem auch noch nach einem etwas anderen Paradigma als klassisches Delphi arbeitet. Auch das Drumrum würde man höchstwahrscheinlich massiv umstricken müssen.

Zitat:

Grundsätzlich denke ich erstmal nein weil ich das Timing auf 25 ms gesetzt habe.
Bei 16ms komme ich an die 60 FPS nur im Vollbild läßt sich dann die Anwendung nicht wieder zurückschalten
Key eingaben schlagen dann fehl.

Das spricht dafür, dass meine Befürchtung zutrifft. Vermutlich rauscht du mit den 16ms so gerade ans Limit, so dass dein Programm so gerade keine Zeit mehr findet ab und an die Windows-Nachrichtenschleife abzuarbeiten. Auf langsameren Kisten oder mit höherer Auflösung könnte das auch mit 25ms u.U. wieder problematisch werden. (Üblicherweise verlässt man sich auf die Nachrichtenschleife in Anwendungen die eine eigene Render-Loop haben aber auch nicht auf diese, sondern baut mittels GetAsyncKeystate() und Konsorten eine komplett eigene Tastatur- und Mausbehandlung. Dann hat man auch bei 100% CPU immer in jedem Frame eine Behandlung von Eingaben.)

[EWeiss]

Zitat:

sondern baut mittels GetAsyncKeystate() und Konsorten eine komplett eigene Tastatur- und Mausbehandlung. Dann hat man auch bei 100% CPU immer in jedem Frame eine Behandlung von Eingaben.)

Das problem dabei ich habe keinen einfluss auf das was andere in ihrer Anwendung so ausführen.
Sicher ist nur das wenn diese meine DLL verwenden auf irgendetwas Rendern müssen was über ein Handle verfügt.
Daszu kommt auch noch das die Sonique Plugins eigentlich für eine Auflösung von 512x512 geschrieben wurden
und einfach Programmtechnisch mit den heutigen Vollbild Auflösungen nicht mehr zurecht kommen.

Solange ich im Rahmen bleibe komme ich schon mit 16ms(10) an die 99 FPS und drüber.

Die Leute möchten gerne 0% CPU max FPS und wenn möglich das ganze noch unter Win95 Anwendbar.

gruss

[EWeiss]

Hab immer noch ein performance problem.

Meine vorgehensweise ist folgende.

Erstelle ein VisWindow innerhalb meiner DLL das ParentWindow ist das der Anwendung welche die DLL verwendet.
Beim Initialisieren des Plugin wird das Handle übergeben (PAnel oder was auch immer) auf dem das VisWindow als Parent gesetzt wird.

Wenn das Timing auf 25ms (Timer) gesetzt wird funktioniert soweit alles
will ich aber in realzeit min 10ms rendern bin ich nicht mehr in der lage die Anwendung zu beenden
ohne das vorher das Plugin beendet wird.
Ich kann aber nicht in der Renderfunktion Peekmessage(DoEvents) verwenden das verursacht jede menge anderer probleme.

Was bleiben dann noch für andere möglichkeiten damit die Anwendung bedienbar bleibt?
Die CPU auslastung ist gerade mal 30% trotzdem kann ich die Anwendung nicht beenden.

gruss

[Medium]

Wie schon zuvor genannt kannst du mit GetAsyncKeystate() in deiner Loop eine eigene Quasi-Message-Behandlung einbauen. Dann ist sichergestellt, dass die wirklich in jedem Frame 1 Mal durchlaufen wird, und man muss sich nicht mehr auf das Durchkommen von Windows-Messages verlassen. Das machen Spiele in aller Regel genau so / verflucht ähnlich.

[EWeiss]

Zitat von Medium:

Wie schon zuvor genannt kannst du mit GetAsyncKeystate() in deiner Loop eine eigene Quasi-Message-Behandlung einbauen.

GetAsyncKeystate?
Hat das nicht eher mit behandlungen von Key eingaben zu tun?

Hab mir jetzt auf dieser weise geholfen.
Ein selbstgebautes doevents welches bei der WM_QUIT Message ein "PostQuitMessage(0)" sendet.

Aber würde mich doch einmal interessieren was , wie du dir das vorstellst mit GetAsyncKeystate.
Denn mit meiner MEthode habe ich leichte Artefakte beim resitz.

Ein DoEvents mit GetAsyncKeystate?
Ohne innerhalb des Renderevents wird die Zeit nicht mehr gerendert.
PAnsiChar(ansistring(strSongpos + ' / ' + strSongLength)), fLargeFontID, TS_ALIGN_LEFT);

Zitat:

damit die Anwendung bedienbar bleibt?

GetAsyncKeystate hat keinerlei einfluss auf das Paint/refresh event der Anwendung welches
durch den loop verhindert wird. Das kann ich widerrum nur mit einem DoEvents oder processmessagen erreichen.


gruss