Delphi-PRAXiS
Seite 5 von 5   « Erste     345   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Thread auf mehrere Core verteilen (https://www.delphipraxis.net/176642-thread-auf-mehrere-core-verteilen.html)

Uwe Raabe 20. Sep 2013 09:53

AW: Thread auf mehrere Core verteilen
 
Zitat:

Zitat von Phoenix (Beitrag 1229237)
Willkommen in der schweren, steinigen Welt des Multithreadings ;-)

:-D

Namenloser 20. Sep 2013 12:47

AW: Thread auf mehrere Core verteilen
 
Liste der Anhänge anzeigen (Anzahl: 1)
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.

EWeiss 20. Sep 2013 13:28

AW: Thread auf mehrere Core verteilen
 
Zitat:

Also mit anderen Worten, das Rendern selbst im Plugin findet gar nicht mit OpenGL statt?
Ja und nein.

Zitat:

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.
Ja gerade deshalb um die CPU zu schonen.
Ob ich nun den Viewport 512x384 also gestretcht auf die weite von 1920x1200 render
oder einen im format 1:1 macht schon einen riesen unterschied.

Das gestretche Format wird dann natürlich auch in OGL übernommen.
Das ist bedingt durch die Plugins selbst weil diese eigentlich für ein Bildformat von 512x512 ausgelegt sind.
Die Leute wollen aber VollBild.

Zitat:

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.
Bedingt vielleicht..
Ist auch eine frage der Ansicht ob ich nun einen schriftzug in OGL Render oder einen in GDI macht doch schon einen recht großen Unterschied.
Zumal über BitBlt dieser dann auch noch in die Renderscene mit eingebunden wird (GDI)und das will ich nicht.
Da dies bei OGL-Plugins unansehnlich aussieht.

Zwischen Bass.dll und Plugin käme dann noch mein Wrapper und darum gehts ;)

gruss

EWeiss 20. Sep 2013 13:44

AW: Thread auf mehrere Core verteilen
 
Zitat:

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.
Drüber war eine falsche Aussage!
Nein Blite nur dann wenn GDI verwendet wird ansonsten über texturierte Quads
Natürlich trotzdem gestretcht abhängig vom Viewport.

Bin jetzt soweit das es funktioniert.

gruss

Namenloser 20. Sep 2013 13:45

AW: Thread auf mehrere Core verteilen
 
Zitat:

Zitat von EWeiss (Beitrag 1229278)
Ja gerade deshalb um die CPU zu schonen.
Ob ich nun den Viewport 512x384 also gestretcht auf die weite von 1920x1200 render
oder einen im format 1:1 macht schon einen riesen unterschied.

Das gestretche Format wird dann natürlich auch in OGL übernommen.
Das ist bedingt durch die Plugins selbst weil diese eigentlich für ein Bildformat von 512x512 ausgelegt sind.
Die Leute wollen aber VollBild.

Ja aber StretchBlt wird doch auf der CPU ausgeführt! Also so bringt das einfach gar nichts; dein Ziel, die CPU zu entlasten, verfehlst du komplett.

Wenn dann müsstest du dir das StretchBlt schon sparen, dann würdest du wenigstens das Skalieren von der CPU auf die GPU verlagern. Aber selbst dann würde ich noch bezweifeln, dass das den Overhead von OpenGL rechtfertigt, denn: Die Bitmap-Daten werden, bevor sie an die GPU gelangen, mehrfach im Speicher herumkopiert, und dann müssen sie auch noch über den PCI-Port wandern, der ein berüchtigter Flaschenhals ist.

Faustregel: Generell ist es immer extrem langsam, irgendwas von der CPU auf die GPU zu transferieren oder umgekehrt.

Ich würde mit dir wetten, dass, wenn du OpenGL komplett rausschmeißt, du ein schnelleres Programm kriegst. Oder zumindest eines, das leichter zu warten ist und gleich schnell ist.

Und danach könntest du vielleicht über Multithreading nachdenken. Aber auch Multithreading ist, ebenso wie OpenGL, kein Silver Bullet.

EWeiss 20. Sep 2013 13:52

AW: Thread auf mehrere Core verteilen
 
Zitat:

Ja aber StretchBlt wird doch auf der CPU ausgeführt! Also so bringt das einfach gar nichts; dein Ziel, die CPU zu entlasten, verfehlst du komplett.
Nein habe es doch über deinen Beitrag berichtigt.
Und Multithreading funktioniert auch mit OpenGL ;)

gruss

Namenloser 20. Sep 2013 14:01

AW: Thread auf mehrere Core verteilen
 
Zitat:

Zitat von EWeiss (Beitrag 1229284)
Zitat:

Ja aber StretchBlt wird doch auf der CPU ausgeführt! Also so bringt das einfach gar nichts; dein Ziel, die CPU zu entlasten, verfehlst du komplett.
Nein habe es doch über deinen Beitrag berichtigt.

Aber das Plugin rendert immer in VisBuf, oder? Ich weiß nicht so recht, was ich unter deinem „Ja und Nein“ zu verstehen habe. Zumindest steht es so im Code, den du gezeigt hast.

Hast du denn mal gemessen, ob es mit OpenGL wirklich schneller ist als nur mit der GDI?
Zitat:

Zitat von EWeiss (Beitrag 1229284)
Und Multithreading funktioniert auch mit OpenGL ;)

Ja, aber spaßig ist es nicht gerade. Bevor ich mich da ins Gefecht stürze, würde ich mir lieber überlegen, ob das wirklich ein guter Ansatz ist.

EWeiss 20. Sep 2013 14:17

AW: Thread auf mehrere Core verteilen
 
Zitat:

Hast du denn mal gemessen, ob es mit OpenGL wirklich schneller ist als nur mit der GDI?
Es geht um das Aussehen deshalb habe ich OGL addiert.

Hab das Beispiel angehängt.. allerdings ohne Quelltext von BassVis
Quelltext der Anwendung selbst ist dabei.

Wenn man die Exe ausführt kann man den Unterschied sehen von OGL und GDI.
Doppelklick auf das Panel dann gehts ins Vollbild mit den eingestellten Vollbild Mode.
Denke das andere ist selbsterklärend.

Ein Kern sollte jetzt nicht mehr voll ausgelastet sein.
Den Viewport muss man von Hand im Code ändern hab da id der GUI nix addiert
dieser sollte aber im Format 4:3 sein

Anhang gelöscht.

gruss

Namenloser 20. Sep 2013 14:48

AW: Thread auf mehrere Core verteilen
 
Funktioniert bei mir lieder nicht, gleich zu Anfang kommt die Meldung „Cannot start default recording device!“. Liegt aber wohl an meiner Soundkarte, die blöderweise kein Loopback kann...

EWeiss 20. Sep 2013 14:53

AW: Thread auf mehrere Core verteilen
 
Zitat:

Zitat von NamenLozer (Beitrag 1229301)
Funktioniert bei mir lieder nicht, gleich zu Anfang kommt die Meldung „Cannot start default recording device!“. Liegt aber wohl an meiner Soundkarte, die blöderweise kein Loopback kann...

geht schon das auskommentieren.
Delphi-Quellcode:
{
  if (not BASS_RecordInit(-1)) or (not BASS_Init(-1, 44100, 0, Handle, nil))
    then
  begin
    BASS_RecordFree;
    BASS_Free();
    MessageDlg('Cannot start default recording device!', mtError, [mbOk], 0);
    Halt;
  end;
}
allerdings kannst du dann nicht über Device rendern.
geht eh nicht hab da noch was vergessen in der bassvis kommt davon wenn man sich nur auf eins konzentriert

gruss


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:58 Uhr.
Seite 5 von 5   « Erste     345   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz