Dr. Lehman, please consider creating an easy to use GUI, or a port to Blender so that those that lack your intelligence can use your gift to the world ! I have tried over and over, but get stumped at a certain point. Happy Christmas !
still waiting for the basic tutorial for those of us that cant code, just want a basic setup with walkthrough, and maybe some examples for moving parts or getting/extracting forces. Just some basic functionality from the this for us normies... :(
Hallo Moritz, ich versuche mich aktuell auch etwas an Simulationen. Ich rendere meine Daten mit OpenCl Funktionen direkt auf der GPU, habe aber noch keine Lösung gefunden, wie ich mein fertiges uchar Array mit RGB Werten tatsächlich auf den Bildschirm bekomme. Aktuell versuche ich es mit OpenGl, aber das führt bis her nur zu Blackscreens und Neustarts. Du meintest in dem Vortrag 2022, dass du die Bilder an den CPU zurückschickst und dann anzeigst. Dabei stellen sich mir zwei Fragen. Wie zeigst du das Bild dann vom CPU aus an ? Und wäre es nicht schneller das Bild auf dem GPU zu lassen und irgendwie von dort aus anzuzeigen ? Ich meine wenn ich ein Bild anzeigen möchte läuft das doch sowiso über die GPU, oder ? Ich habe schon versucht aus deinem Code schlau zu werden, aber mit meiner begranzten Erfahrung finde ich mich da ehrlich gesagt nicht zurecht. Wäre super, wenn du mir da einen kleinen Tipp geben könntest. Viele Grüße Björn
Servus Björn, das rauszufinden hat mich auch viel Nerven gekostet. Man braucht letztendlich externe Bibliotheken - auf Windows und auf Linux - um das Bild mit SetBitmapBits()+BitBlt() bzw. XPutImage() auf den Bildschirm zu zeichnen. Drum herum braucht es noch einen Haufen Gedöns, um ein Vollbild-Fenster zu erstellen, in das man das Bild dann gemalt bekommt, und für Maus- und Tastatur-Input. Findest du als Minimal-Implementierung alles hier: github.com/ProjectPhysX/FluidX3D/blob/master/src/graphics.cpp#L440-L749 Die externen Bibliotheken könnten noch mehr, z.B. Linien und Dreiecke zeichnen, das hab ich aber alles selbst implementiert, auch auf CPU Seite, damit es schneller läuft (bzw. denn überhaupt gescheit funktioniert) und ich für Windows/Linux nicht alles doppelt machen muss. Das einzige was ich aus den Bibliotheken nutze ist wirklich die Bitmap zu zeichnen und Maus-/Tastatur-Input. Das Bild über OpenCL-OpenGL interoperability direkt aus dem VRAM auf den Bildschirm zu zeichnen wäre vermutlich etwas schnellere Latenz, spielt aber letztendlich keine Rolle weil es so schon schnell genug ist. Vorteil ist, dass dann das Rendern auch klappt wenn man den Bildschirm über die iGPU betreibt und auf einer dGPU rechnen/rendern lässt. Und das funktioniert auch mit z.B. einer A100 die selbst gar keine Display Anschlüsse hat. Die X11 Implementierung hinzubekommen war besonders grässlich, weil X11 segfaultet bei jeder Gelegenheit, z.B. wenn man einen Tastendruck mit XNextEvent() abfragt während gerade der frame gezeichnet wird. Dafür braucht es extra XLockDisplay()/XUnlockDisplay(). Und für unterschiedliche Tastaturlayouts muss man eine extra X11-Erweiterung laden. Um Größe und Offset des primären Monitors bei mehreren Bildschirmen rauszufinden braucht es auch eine extra Erweiterung. Und nichts ist ordentlich dokumentiert... VG Moritz
@@chaos3088 it's a physically accurate computational fluid dynamics software, for research and engineering, with a huge range of applications from microfluidics to aircraft aerodynamics. The rendering is just a small part of it.
Yes, I actually tested this with (Intel UHD 630 + Titan Xp) and it worked. But the slower iGPU is the bottleneck then and it all will be super slow. With faster iGPUs in the future, pairing with an older dGPU could be a viabnle option. What I also tried was pairing CPU and iGPU. This also works, but is not practical as it's slower than using either one alone. CPU+iGPU share the same memory interface and only slow each other down when they fight for bandwidth.
Santa's sleigh with some X-wing and laser cannon modifications. Merry Christmas! The CAD model is from Zannyth / Kevin Piper: www.thingiverse.com/thing:2632246/files
Haters will say this isn't what Santa's sleigh looks like
The only good Netflix adaptation.
its so good to not rely entirely on CUDA!!
Congratulations, your work on this project gets better and better! May I know how soon a nice tutorial on configuration and use will be available?
@@lucamagni99 thanks! Please see here: github.com/ProjectPhysX/FluidX3D/blob/master/DOCUMENTATION.md
what a setup lol, your work is very impressive!
Dr. Lehman, please consider creating an easy to use GUI, or a port to Blender so that those that lack your intelligence can use your gift to the world !
I have tried over and over, but get stumped at a certain point.
Happy Christmas !
still waiting for the basic tutorial for those of us that cant code, just want a basic setup with walkthrough, and maybe some examples for moving parts or getting/extracting forces. Just some basic functionality from the this for us normies... :(
bro calls me broke in 3 different languages, love the sim tho 👍
Cool. Can you run a known model side by side to see similarities? Automotive?
Dr Lehman, maybe im start to planning to make gui for your cfd code
How is PyTorch performance for training physics informed neural networks on B580?
Hallo Moritz,
ich versuche mich aktuell auch etwas an Simulationen. Ich rendere meine Daten mit OpenCl Funktionen direkt auf der GPU, habe aber noch keine Lösung gefunden, wie ich mein fertiges uchar Array mit RGB Werten tatsächlich auf den Bildschirm bekomme. Aktuell versuche ich es mit OpenGl, aber das führt bis her nur zu Blackscreens und Neustarts. Du meintest in dem Vortrag 2022, dass du die Bilder an den CPU zurückschickst und dann anzeigst. Dabei stellen sich mir zwei Fragen. Wie zeigst du das Bild dann vom CPU aus an ? Und wäre es nicht schneller das Bild auf dem GPU zu lassen und irgendwie von dort aus anzuzeigen ? Ich meine wenn ich ein Bild anzeigen möchte läuft das doch sowiso über die GPU, oder ?
Ich habe schon versucht aus deinem Code schlau zu werden, aber mit meiner begranzten Erfahrung finde ich mich da ehrlich gesagt nicht zurecht.
Wäre super, wenn du mir da einen kleinen Tipp geben könntest.
Viele Grüße
Björn
Servus Björn,
das rauszufinden hat mich auch viel Nerven gekostet. Man braucht letztendlich externe Bibliotheken - auf Windows und auf Linux - um das Bild mit SetBitmapBits()+BitBlt() bzw. XPutImage() auf den Bildschirm zu zeichnen. Drum herum braucht es noch einen Haufen Gedöns, um ein Vollbild-Fenster zu erstellen, in das man das Bild dann gemalt bekommt, und für Maus- und Tastatur-Input. Findest du als Minimal-Implementierung alles hier: github.com/ProjectPhysX/FluidX3D/blob/master/src/graphics.cpp#L440-L749
Die externen Bibliotheken könnten noch mehr, z.B. Linien und Dreiecke zeichnen, das hab ich aber alles selbst implementiert, auch auf CPU Seite, damit es schneller läuft (bzw. denn überhaupt gescheit funktioniert) und ich für Windows/Linux nicht alles doppelt machen muss. Das einzige was ich aus den Bibliotheken nutze ist wirklich die Bitmap zu zeichnen und Maus-/Tastatur-Input.
Das Bild über OpenCL-OpenGL interoperability direkt aus dem VRAM auf den Bildschirm zu zeichnen wäre vermutlich etwas schnellere Latenz, spielt aber letztendlich keine Rolle weil es so schon schnell genug ist. Vorteil ist, dass dann das Rendern auch klappt wenn man den Bildschirm über die iGPU betreibt und auf einer dGPU rechnen/rendern lässt. Und das funktioniert auch mit z.B. einer A100 die selbst gar keine Display Anschlüsse hat.
Die X11 Implementierung hinzubekommen war besonders grässlich, weil X11 segfaultet bei jeder Gelegenheit, z.B. wenn man einen Tastendruck mit XNextEvent() abfragt während gerade der frame gezeichnet wird. Dafür braucht es extra XLockDisplay()/XUnlockDisplay(). Und für unterschiedliche Tastaturlayouts muss man eine extra X11-Erweiterung laden. Um Größe und Offset des primären Monitors bei mehreren Bildschirmen rauszufinden braucht es auch eine extra Erweiterung. Und nichts ist ordentlich dokumentiert...
VG
Moritz
@@ProjectPhysX Vielen Dank für die Antwort. Das werde ich auf jeden fall mal probieren.
Do you know how pci express speed affect performance ? Because there's a lot of cheap used crypto mining computers with a lot of GPUs but in 1x.
Don't use these, PCIe x1 is too slow. Should be at least PCIe 3.0 x4.
Is your software only meant to assist rendering? What other function it has?
@@chaos3088 it's a physically accurate computational fluid dynamics software, for research and engineering, with a huge range of applications from microfluidics to aircraft aerodynamics. The rendering is just a small part of it.
@ProjectPhysX that's really cool! So it's more meant for simulation studies eh?
i want to ask about how it compare to 4060, 4060ti 16gb ,3070 .
Would you be able to combine an integrated GPU with a discrete GPU? Amazing to see this, hope you get a few MI300 under your Christmas tree!
Yes, I actually tested this with (Intel UHD 630 + Titan Xp) and it worked. But the slower iGPU is the bottleneck then and it all will be super slow. With faster iGPUs in the future, pairing with an older dGPU could be a viabnle option.
What I also tried was pairing CPU and iGPU. This also works, but is not practical as it's slower than using either one alone. CPU+iGPU share the same memory interface and only slow each other down when they fight for bandwidth.
is that a wheelchair or something
Santa's sleigh with some X-wing and laser cannon modifications. Merry Christmas!
The CAD model is from Zannyth / Kevin Piper: www.thingiverse.com/thing:2632246/files
@@ProjectPhysX Are the laser cannons for the naughty?