I was able to get this running on a high cpu instance on AWS EC2. Built an AMI and I'm tweaking it so that the AMI boots up a server instance and powers down/terminates the instance if CPU activity falls below a certain level (to save money). I sent back an x-session just to get an idea of performance and it made quick work of the sample STL files. This is very encouraging. Great work, guys!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, used the distributed processing and the gui standalone. It would appear that the gui w/ distributed processing drives the backend/distributed processing better. I was able to send an x-session back to my laptop (expensive on bandwidth) and the distributed processing was much more light weight on network utilization. I was able to do SampleScene3.stl fairly quickly and another lad was able to see significant speed up as well at his office.
What do you think about using GPU/CUDA for handling triangle collision? I think it's probably ideal for it. I was going to give that a try soon where the parallel loops. Instead of forking off a thread/core…just write the polygons to gpu memory and let the streams processors have at it for collision detection.
This is very exciting!
Cheers,
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess, I am confused now :)
Probably you are using the linux version of PyCAM, right?
(I usually used the term "standalone" for the single-file Windows executable of PyCAM)
The distributed processing settings allow you to connect two (or more) instances of PyCAM over a network, thus you could even run the remote instance without the GUI (reducing the traffic for the X-session).
Thanks for the hint regarding GPU processing. I did not think of this before.
A quick research turned up PyGPU (which seems to be quite dead) or PyOpenCL - which seems to be well under development. Probably I will just wait for the Bullet physics engine to finish OpenCL support and then integrate its collision detection engine. Direct support for GPU coding would probably not be worth the effort for PyCAM, I think.
But if you can put together some quick and dirty sample code, then I will be happy to take a closer look at it …
cheers,
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My mistake though, I meant a linux pycam gui running on a remote server with the x-session kicked back to my laptop.
For the CUDA I was looking at the ContourFollow->get_collision_waterline_of_triangle and putting the for edge in outer_edges piece into a CUDA kernel. However, pysco might be doing pretty good on optimizing that already.
I'm still looking through the code though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to get this running on a high cpu instance on AWS EC2. Built an AMI and I'm tweaking it so that the AMI boots up a server instance and powers down/terminates the instance if CPU activity falls below a certain level (to save money). I sent back an x-session just to get an idea of performance and it made quick work of the sample STL files. This is very encouraging. Great work, guys!
Hi btribit,
it is great to hear that PyCAM works easily on AWS!
Did you use the distributed processing feature of PyCAM? Or do you want to use the GUI remotely?
cheers,
Lars
Hi Lars,
Yes, used the distributed processing and the gui standalone. It would appear that the gui w/ distributed processing drives the backend/distributed processing better. I was able to send an x-session back to my laptop (expensive on bandwidth) and the distributed processing was much more light weight on network utilization. I was able to do SampleScene3.stl fairly quickly and another lad was able to see significant speed up as well at his office.
What do you think about using GPU/CUDA for handling triangle collision? I think it's probably ideal for it. I was going to give that a try soon where the parallel loops. Instead of forking off a thread/core…just write the polygons to gpu memory and let the streams processors have at it for collision detection.
This is very exciting!
Cheers,
Bob
Hi Bob,
I guess, I am confused now :)
Probably you are using the linux version of PyCAM, right?
(I usually used the term "standalone" for the single-file Windows executable of PyCAM)
The distributed processing settings allow you to connect two (or more) instances of PyCAM over a network, thus you could even run the remote instance without the GUI (reducing the traffic for the X-session).
Thanks for the hint regarding GPU processing. I did not think of this before.
A quick research turned up PyGPU (which seems to be quite dead) or PyOpenCL - which seems to be well under development. Probably I will just wait for the Bullet physics engine to finish OpenCL support and then integrate its collision detection engine. Direct support for GPU coding would probably not be worth the effort for PyCAM, I think.
But if you can put together some quick and dirty sample code, then I will be happy to take a closer look at it …
cheers,
Lars
Just had a post and SF kicked me out.
My mistake though, I meant a linux pycam gui running on a remote server with the x-session kicked back to my laptop.
For the CUDA I was looking at the ContourFollow->get_collision_waterline_of_triangle and putting the for edge in outer_edges piece into a CUDA kernel. However, pysco might be doing pretty good on optimizing that already.
I'm still looking through the code though.