Thread auf mehrere Core verteilen

[EWeiss]

Zitat:

Zitat von glotzer (Beitrag 1229189)

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

[glotzer]

Zitat:

Zitat von EWeiss (Beitrag 1229190)

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

Sind doch bestens zu lesen ;)

[Uwe Raabe]

Zitat:

Zitat von glotzer (Beitrag 1229192)

Sind doch bestens zu lesen ;)

...wenn man drauf klickt...

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1229194)

Zitat:

Zitat von glotzer (Beitrag 1229192)

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

[Mikkey]

Zitat:

Zitat von EWeiss (Beitrag 1229201)

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

[EWeiss]

Danke für die Informationen.
Ich habe es mal getestet nur mit einem zusätzlichen Thread.
So wie es aussieht scheint es zu funktionieren werden nun alle Kerne vergleichsweise ausgeglichen verwendet.

Allerdings hab ich nun schwierigkeiten beim verändern der Fenstergröße.
OGL ist da ziemlich pingelig wenn der Contex incl. GL-Befehle nicht ausschließlich aus dem Thread
heraus behandlet werden.
Fenster resitz.. crash ;)

Muss da wohl noch einiges optimieren.

gruss

[Phoenix]

Zitat:

Zitat von EWeiss (Beitrag 1229235)

Allerdings hab ich nun schwierigkeiten beim verändern der Fenstergröße.
OGL ist da ziemlich pingelig wenn der Contex incl. GL-Befehle nicht ausschließlich aus dem Thread
heraus behandlet werden.
Fenster resitz.. crash ;)

Das ist der Punkt mit der Synchronisierung.
Da versucht dann ein Thread (z.b. Berechnung) was zu verändern, wo in dem Moment ein anderer Thread (z.b. Anzeige) darauf zugreift. Das knallt.
Du musst also also Übergabepunkte zwischen den Threads synchronisieren (z.B. Mutex drumrum packen).

Willkommen in der schweren, steinigen Welt des Multithreadings ;-)

[EWeiss]

Zitat:

Willkommen in der schweren, steinigen Welt des Multithreadings

Danke auch Herzlichst :-D
Jetzt mal unabhängig von den Kernen OGL hat ein grundsätliches problem mit Threads
Wenn man dann noch bedenkt das die Plugins ein mismatch aus GDI/OGL sind kommt man letztendlich
zum schluss das die Schnittstelle nicht gerade durchdacht ist.

Ok.. Das ist ne andere sache wird langsam OT ;)

gruss

[Namenloser]

Zitat:

Zitat von EWeiss (Beitrag 1229170)

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:

Zitat von EWeiss (Beitrag 1229170)

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?

[EWeiss]

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.

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

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)

Delphi-Quellcode:

DC := GetDc(ParentHandle);

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

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

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

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

Delphi-Quellcode:

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

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