![]() |
AW: Thread auf mehrere Core verteilen
Zitat:
|
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. |
AW: Thread auf mehrere Core verteilen
Zitat:
Zitat:
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:
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 |
AW: Thread auf mehrere Core verteilen
Zitat:
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 |
AW: Thread auf mehrere Core verteilen
Zitat:
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 ![]() |
AW: Thread auf mehrere Core verteilen
Zitat:
Und Multithreading funktioniert auch mit OpenGL ;) gruss |
AW: Thread auf mehrere Core verteilen
Zitat:
Hast du denn mal gemessen, ob es mit OpenGL wirklich schneller ist als nur mit der GDI? Zitat:
|
AW: Thread auf mehrere Core verteilen
Zitat:
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 |
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...
|
AW: Thread auf mehrere Core verteilen
Zitat:
Delphi-Quellcode:
allerdings kannst du dann nicht über Device rendern.
{
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; } 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 02:15 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz