Die GPU hat gerade mal 9% (vom gesamten System natürlich) die probleme macht die CPU ein Kern!

Weiss nicht was dir ein Bild jetzt sagt habe es aber mal angehängt.
Habe es in einem Archiv gepackt weil es sonst hier im Forum verkleinert wird.

gruss

für alle die wie ich darüber genervt sind/waren das archiv erst entpacken zu müssen... :

Zitat von glotzer:

für alle die wie ich darüber genervt sind/waren das Archiv erst entpacken zu müssen... :

Du Spassvogel!

Dir ist wohl klar das du nun die relativen Dinge um die es geht nun nicht mehr siehst?
Es hatte schon einen grund das ich es in einem archiv gepackt habe.
Die Auslastung der resourcen GPU/CPU usw.. kann man auf deinen Shot nicht mehr erkennen.

gruss

Zitat von EWeiss:

Dir ist wohl klar das du nun die relativen Dinge um die es geht nun nicht mehr siehst?

Sind doch bestens zu lesen

Zitat von glotzer:

Sind doch bestens zu lesen

...wenn man drauf klickt...

Zitat von Uwe Raabe:

Zitat von glotzer:

Sind doch bestens zu lesen

...wenn man drauf klickt...

logisch nur vorher hatte er es nicht ausgeschnitten.. und extra hochgeladen.
Aber egal hab keine zeit zum spielen.

Ok Danke trotzdem hab das Archiv gelöscht.

gruss

Zitat von EWeiss:

Aber egal hab keine zeit zum spielen.

Um auf das Eingangsproblem zurückzukommen...

ich sehe hier eine relativ einfache Möglichkeit zur Parallelisierung. Du solltest einen Kern(=Thread) den Frame rendern lassen und einen anderen Kern bereits den nächsten.

Wenn Du so die Arbeit auf 4 Kerne verteilst, hat jeder Kern die vierfache Zeit für seine Arbeit. Du musst natürlich die Soundausgabe soweit verzögern, dass sie zeitgleich mit der Anzeige kommt.

Das ganze erfordert natürlich einen ziemlichen Verwaltungsaufwand.

Mit anderen Worten:
Die Kerne werkeln gleichzeitig an vier aufeinanderfolgenden Frames. Sie stellen ihr Ergebnis in eine kurze Warteschlange, die von der Grafikausgabe aufgenommen und auf den Bildschirm gebracht wird. Kern1 bearbeitet also die Frames 1,5,9..., Kern2 2,6,10..., Kern 3 3,7,11... und Kern 4 4,8,12...

Zitat von EWeiss:

Weiss nicht was dir ein Bild jetzt sagt habe es aber mal angehängt.

Weil Bilder weniger missverständlich als Beschreibungen sind. Ist mir z.B. schon oft so gegangen, dass ich Leuten versucht habe, bei irgendwelchen Computerproblemen zu helfen und sie stundenlang per Messenger ausgefragt habe und wir völlig aneinander vorbeigeredet haben, und nach einem Screenshot war sofort klar, was Sache ist...

Zitat von EWeiss:

Die GPU hat gerade mal 9% (vom gesamten System natürlich) die probleme macht die CPU ein Kern!

Und das macht mich stutzig. Also wenn du sagst, dass das Rendern bei größerer Auflösung langsam wird, dann würde das bedeuten, dass die GPU der Flaschenhals ist, weil diese sich ja um das Rendern kümmert. Der CPU ist es ja egal, wie groß die Ausgabe der GPU ist, denn auf der CPU laufen unabhängig von der Auflösung immer die gleichen Befehle.

Aber da die GPU nur zu 14% (laut deinem Screenshot) ausgelastet ist, kann das nicht das Problem sein. Jetzt ist die Frage, was macht dein Programm bei höheren Auflösungen auf der CPU anders? Und welche Stationen durchläuft bei dir ein Frame genau, bevor es auf dem Bildschirm ausgegeben wird? Läuft das alles über OpenGL direkt? Oder – Gott bewahre – liest du etwa den OpenGL-Framebuffer mit glReadPixels aus, damit du das Gezeichnete mit der GDI weiterverwenden kannst?

Ich erstelle einen GDI-VideoBuffer(VisBuf) abhängig vom Viewport = bsp. 512x384 außerhalb des Threads.
Die Visualisierung wird dann also in VollBild 1920x1200 auf den Viewport 512x384 gestretcht.
Das schont CPU resourcen.

markieren

Delphi-Quellcode:

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

  VisBmp := CreateDIBSection(0, BmpInfo, DIB_RGB_COLORS, VisBuf, 0, 0);

Dann wird der Record VisData mit den Wave/FFT Daten gefüttert
und anschließend im Plugin selbst gerendert wo ich keinen Einfluss drauf habe

markieren

Delphi-Quellcode:

        if (not VisInfo^.VisPointer^.Render(VisInfo^.VisBuf, StretchWidth,
          StretchHeight, StretchWidth, @VisData)) then

anschließend hole ich mir das DC vom OpenGL Contex (RenderWindow)

DC := GetDc(ParentHandle);

Danach verwende ich StretchBlt um die Daten auf das DC vom Source VisDC zu zeichnen

markieren

Delphi-Quellcode:

        if (not StretchBlt(DC, VisInfo^.x, VisInfo^.y, VisInfo^.w, VisInfo^.h, VisInfo^.VisDC, 0,
          0, StretchWidth, StretchHeight, SRCCOPY)) then

Anschließend wird der inhalt vom VisBuf in eine OGL-Texture kopiert

markieren

Delphi-Quellcode:

        
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, StretchWidth, StretchHeight, 0,
GL_BGRA_EXT, GL_UNSIGNED_BYTE, VisInfo^.VisBuf);

Der rest sind noch ein paar OGL sachen

markieren

Delphi-Quellcode:

glEnable(GL_TEXTURE_2D);
glBegin(GL_QUADS);
...
glFlush();
SwapBuffers(glDC);

Das wars dann.

Nach meiner änderung von Timer auf Thread geht es jetzt soweit und die Kerne werden
gleichmäßig ausgelastet.
Wenn aber nun aus der Anwendung heraus die resitz Message geschickt wird die außerhalb des threads läuft

Result := BASS_SONIQUEVIS_Resize(Param^.VisHandle, Left, Top, Width, Height);

dann kracht es gewaltig in irgendeiner OGL .dll

so sieht es im moment aus.

Zitat:

liest du etwa den OpenGL-Framebuffer mit glReadPixels aus

Nein die Pixels werden in Rechtecke zerlegt aus der glTexImage2D Texture

zusammenfalten · markieren

Delphi-Quellcode:

        glColor4f(1, 1, 1, 1);
            glEnable(GL_TEXTURE_2D);
            glBegin(GL_QUADS);
              glTexCoord2d(0.0, 0.0);
              glVertex2f( 0.0, 0.0);
              glTexCoord2d(0.0, 1.0);
              glVertex2f( 0.0, LastHeight);
              glTexCoord2d(1.0, 1.0);
              glVertex2f(LastWidth, LastHeight);
              glTexCoord2d(1.0, 0.0);
              glVertex2f(LastWidth, 0.0);
        glEnd();

gruss

Also mit anderen Worten, das Rendern selbst im Plugin findet gar nicht mit OpenGL statt? Was ich jetzt nicht verstehe: Wozu verwendest du überhaupt OpenGL?

Ich bin jetzt nicht gerade als Freund von UML bekannt, habe mir jetzt aber trotzdem mal die Mühe gemacht, ein Sequenzdiagramm von deinem Ablauf zu machen, so wie ich ihn verstehe.

So wie ich das sehe, ist OpenGL bei dir völlig redundant, da du nur 1:1 die Daten auf den Bildschirm ausgibst, die du vorher schon auf der CPU berechnet und gezeichnet hast. Du blittest sogar das gleiche zwei mal, indem du erst mal mit der GDI die Visualisierung auf das OpenGL-DC zeichnest, und dann noch mal mit OpenGL selbst als texturierter Quad.

Die ganze Arbeit macht bei dir die CPU, durch die Verwendung der GPU erhöhst du hier nur den Overhead und machst das ganze langsamer.

Sorry, wenn ich es missverstanden habe, aber so erschließt es sich aus deinem letzten Beitrag.