The Particle System, why not CUDA/OpenCL enable it?

General Forums Blender and CG Discussions
1

Looking at other apps, and even some creative coders pet projects. I´ve seen particle systems up to ~1million run smooth in 60fps using OpenCL.

For the next open movie project, if they´re gonna have massive crowd sims (guess PSys boids) what could be worth considering is the possibility to re-write the system with OpenCL/CUDA compute possbilities.

I guess where to start is to get simple emission, and simple gravity forces working. A bottle neck could be caching, but it´s probably solvable. If GPUs take lots of time transporting and writing down to disk cache files.

Anyways getting 100.000s particles in the viewport at interactive frame rates when doing massive particle systems would be sweet. Then caching the sim, CPU could handle the playback. OpenCL/CUDA could be only used when experimenting with settings.

2

Even several hundred thousand particles run reasonably smoothly using OpenCL on my Mobility Radeon 5470, and that’s about 1/20th the compute performance of a mid-high end GPU.

However, I’m not sure whether it’s a good idea to put priority on GPU accelerated particles as of now, and possibly take away resources from other areas like Cycles. Of course, I have no idea how the dev team is set up, but my point being if developing GPU accelerated particles slows down development in other areas, I don’t think I want.

3

Ignoring pet projects, what production application has OpenCL-based particle systems? With GPUs, it’s usually all-or-nothing. You need the entire system running on the GPU (with all the drawbacks that brings) or else the speedup becomes negligible.

Are particles really such a bottleneck in your workflow that you’d be willing to have a more limited particle system if only it was faster?

You don’t just wave the GPGPU wand at some existing code and magically get speedups. You need to rewrite stuff from scratch.

4

I agree in that there are far more pressing issues than this, however it is worth pointing out something called Popcorn FX http://www.popcornfx.com/samples/

I have seen it in action with art creation tools as well. Impressive stuff when used right.

5

Particles has several time become the bottle neck for me at least. It´s cool for smaller motion graphic stuff, but as soon you want to scale up to something really impressive it´s almost impossible. You have to display 1-10% of the real amount, then go back to 100% to see the real result if everything is ok. It´s not just that interactive as you would like to have an artistic control over it.

Just google it, I´ve seen several Maya vids with OpenCL enabled particles.

anyways it´s irrelevant what other apps has it, when it´s possible. But yeah resources, AFAIK Brecht and Joerren is the ones that knows OpenCL/CUDA. It would take a special kind of developer, having that knowledge and also the interest in particle systems.

Well Brecht said that for 2.71 Cycles might be feature complete, have volumetrics, SSS and SMoke all on GPU code. Maybe he could help some particle system developer get into it.

Regarding re-writing the entire code from scratch I don´t think that´s necessary. The examples of C/CUDA code comparisons I´ve seen some of the force calcs could remain. But that´s for a developer to decide. What could be done quickly is check out Brechts code for Cycles and compare how much different the CUDA/C code is compared to the C code that´s being run instead on CPUs.

Anyways just wanted the idea aired :slight_smile: if particle systems is gonna get some loving in the next movie project, or re-written it would be maybe time to considering having it from the ground up CUDA/OpenCL compatible. or the general framework behind it, as the impression Brecht has done with OpenCL for Cycles even though hardware/drivers are the issue why it´s not working currently.

6

im sure we will have something like this one day but not anytime soon… unless we have some amazing guy in the community who makes it. that actually happens a lot

1 Like
7

I am quite sure thar these videos only show how opencl /cuda accelerate the particle fluid simulation but not the display of them, thats probably done in opengl/directx.
The first time you play a particle system it gets calculated and saved in a point cache to then be displayed on screen. There are at least 2 bottle necks in blender: calculating the sim and displaying the cached pointcache.
When you play the particle system a second time its faster because it reads from the pointcache but if you have to reduce the display to 10% to get realtime playback then getting opencl particle won’t change anything, it would only be good for the initial creation of the cache.

I think first of all Blender needs a speed up in displaying particles from the pointcache. Currently all pointaches in blender are beeing rewriten to use Alembic, I dont know if it will speed up reading of the data but it would be nice. Also there is the multithread depsgraf update/rewrite thats comming soon which should speed up animation display and hopefully also particle. And of course the opengl viewport probably needs a speedup too! Maybe the gsoc project Viewport FX might be the first step for it.

For particles itself, i think its more likely that they first going to integrate particle nodes and break back-forward compatibility before it going to be gpu accelerated.

8

These are small demos for isolated systems, I have yet to see somebody ship a full solution using OpenCL.

anyways it´s irrelevant what other apps has it, when it´s possible.

It’s not irrelevant, at all. We need to leverage having others bite out their teeth on getting a fully-featured OpenCL solution shipped. If “they” can’t do it, that’s a sign that “we” probably shouldn’t even bother. I have very little confidence in OpenCL, so far.

Regarding re-writing the entire code from scratch I don´t think that´s necessary. The examples of C/CUDA code comparisons I´ve seen some of the force calcs could remain.

It is necessary. Maybe you can copy over some routines, but you still need to completey redesign it to work for the GPU computation model, which is the bulk of the work. Then cross your fingers and hope driver bugs don’t get in your way.

But that´s for a developer to decide. What could be done quickly is check out Brechts code for Cycles and compare how much different the CUDA/C code is compared to the C code that´s being run instead on CPUs.

The kernel part of it is almost identical, but that’s because Cycles was designed to work within GPGPU limits.
EDIT: To be a bit more specific, the problem isn’t the language, but the computation/memory model. C and OpenCL are for the most part the same language, you just cannot use things like dynamic memory, recursive function calls or function pointers. You also can’t just code something as you would for the CPU and expect it to be fast.

On a side note:
´ <- this is not an apostrophe, it is an acute accent
` ← this is not an apostrophe, either, it is a grave accent
’ ← this is an apostrophe

People, please use the correct character for apostrophes, it shows you have a firm grasp on the English language and it makes reading your stuff much more pleasant (at least to me).

Compare the following sentences:

I’ve never had a problem using apostrophes!
I´ve come at least close!
I`ve really got a problem with them!

Which one do you like better? (It actually doesn’t matter, the last two are just wrong.)

9

Off topic but damn… I don’t even know where to find the other two on my keyboard…

10

It’s the initial creation of the cache that’s most important for speed for me at least. The bit where you customize and play around with settings to achieve an wanted look.

Maybe to keep in vram as long as possible until user bake/caches to ram/disk. Then the CPU can handle the display. Looking at OpenSubDiv GPU videos, a similar approach could be good. CPU can handle the framework of the particle system, but GPU handles the upscaling and render.

11

On European keyboards we have tons of stuff, have all the ´`’ easy available :slight_smile: just the correct one is dangerously close to enter.
åäöÅÄÖ, you guys should be thankful for not having all these extra characters.

12

Just my 2 cents, i actually search for sph particle for personal projet and found this http://fluids3.com/. Looking at the code its a quite independent lib doing only one purpose and doing it well.

BulletFluid was based on v2 but v3 improved a lot in term of performance.

Based on http://pub.ist.ac.at/group_wojtan/projects/2013_Ando_HALSoTM/index.html, improvements can be made so it refine smaller areas, generate new particules (reactor) and mesh the sph to one mesh on fly.

13

i think we need opencl for bullet before the particles… its already supported on bullet just not blender. i dont know its an official release that supports it or a beta one but i know it does it :stuck_out_tongue:

:edit:
here have a link http://bulletphysics.org/wordpress/

14

@tyctyc75
I as unaware of bullet physics having a fluid sim, that lib looks really impressive and able to run fully on GPU as CPU is very impressive. If it can do SPH calculations, easier force fields as attractions and wind must be way easy to implement or? anyways that looks a great lib to build upon blenders particles.

I mean it could be implemented as experimental and you could choose it for the particles and have a limited feature base. I rather have that and interactive framerates with 100.000s of particles in the viewport.

@LordOdin I know, I think Sergej Reich knows about it. I even think I asked him once about that. The idea was to be easier to update BulletPhysics lib now to newer versions than it was before his GSoC project.

I also am eager to await Bullet 3.x it should be first stable release with OpenCL acc. physics.
http://bulletphysics.org/wordpress/?p=381

Why it’s not in Blender is because official version is 2.8 or something.

15

These guysworked on GPU based SPH for blender. Don’t know what happened to it…

16

I e-mailed with Ian just yesterday, I think he is into javascript development nowdays. Their OpenCL code was only for the game engine particles afaik.

that fluid3d lib looks super promising, I would considering using it under the hood for the particles all together.

17

What is ‘particles’ in regard to this specific question…? Sure, Houdini implemented OCL acceleration in the Pyro solver, RealFlow’s got their HyFLIP solver, you got the Glu GPU plugin for 3ds Max, but the rest is GPU previewing, like in FFX and PhoenixFD…

But I don’t really get how GPU can help with non-fluid type particle acceleration accept in the viewport… As I understood it, GPU is beneficial for calculation fluids - and to some extent, soft bodies - but hard body sims and such are less suited for GPU acceleration…

Or this is at least as I understood it.

18

ah cool cool

19

Erwin Coumans demonstrates 100% GPU Bullet Physics, wow just wow. I know there’s been talk about the particle system in blender being able to have bullet physics objects as particles. Just interesting to see where Bullet Physics is taking it with GPU acceleration. Can’t wait until version 3 and I really hope it’s quickly implemented in Blender.

Same guy made this demo about SoftBodies in Bullet, I don’t know if Bullet is being used for Soft Bodies in Blender, if not I really hope a GSoC or someone with interest in Bullet and Blender is able to replace Blenders current soft body solver to Bullet.

And that video is with Bullet 2.7, currently there’s no way to have that interactive frame rates in blenders Soft bodies. They’re painfully slow as last time I tried doing anything with softbodies a while back.

20

A note on blender vs bullet softbodies.
This is not just a matter of performance, they have different feature sets. Also the way blender handles simulations currently makes it awkward to integrate.
We need to have a decent simulation framework in blender first.