Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPGPU particles example performance #205

Open
jkozniewski opened this issue Jul 30, 2022 · 5 comments
Open

GPGPU particles example performance #205

jkozniewski opened this issue Jul 30, 2022 · 5 comments

Comments

@jkozniewski
Copy link

jkozniewski commented Jul 30, 2022

I've been playing with the code for GPGPU example (https://github.com/greggman/twgl.js/blob/master/examples/gpgpu-particles.html) and I'm surprised of how fast and dramatically the performance degrades wit the amount of the particles - with default 256x256 (about 65 000 particles) it runs smoothly - 60fps but with 400x400 (~160 000 particles) it's more like 30 fps. I'm kind of surprised since I've seen webgl based examples pulling like a milion of particles (so about 5x more) with no sweat...

Is there any caveat with this example that I'm missing that prevents better performance and/or there are any optimisations / different approaches to get ~ 200 000 particles with some rudimentary physics performing better ?

@jkozniewski
Copy link
Author

jkozniewski commented Jul 30, 2022

hmmm... it's interesting - I've got an intuition (based on some previous experiences) that actually sometimes using webgl1 context instead of webgl2 surprisingly provides better performance, and indeed using dirty hack to trick twgl to use webgl1 - https://stackoverflow.com/a/42848865 (btw - no way to do this cleanly ?) I have now stable 60fps with 160 000 (or even 1 milion!) particles...

Still, curious - why is this the case ?
And also feature request - give the option to choose webgl1 in twgl.getContext() method

@greggman
Copy link
Owner

If you want webgl1 just get the context yourself.

gl = canvas.getContext("webgl")

to be honest I never use twgl.getContext and I kind of regret it exists.

As for the speed issue that is suprising that the speed would change .

As for lots of particles here's a million

webgl2

https://jsgist.org/?src=94e9058c7ef1a4f124eccab4e7fdcd1d

webgl1

https://jsgist.org/?src=c4e91cff94b0543a7c4287f18c06a78b

@jkozniewski
Copy link
Author

jkozniewski commented Jul 30, 2022

thanks @greggman - figured out that I can use getContext directly, so I'd propose to either add the webgl version option to twgl.getContext or ditch it's usage in examples (the GPGPU example was the one and only I've referred to and thought that twgl.getContext is the proper way)

regarding the examples you have provided - it's the same story, webgl1 runs super smoothly, webgl2 barely
for reference I'm on Mac Book Pro 15" (late 2017), macOS Monterey, Chrome - what's your setup ?

edit - quickly checked in Firefox and Safari - seems that's some sort of Chrome-related bug (on Mac?), as in other browsers both webgl1 and webgl2 runs smoothly...

@JeffreyPalmer
Copy link

JeffreyPalmer commented Aug 4, 2022

I've been experiencing these types of performance issues with MacOS/Chrome and instanced rendering. The problem seems to be this Chrome bug: https://monorail-prod.appspot.com/p/chromium/issues/detail?id=1245448.

You may be having the same problem. Doesn't seem like there's a lot we can do about it at the moment, however.

@jkozniewski
Copy link
Author

jkozniewski commented Aug 4, 2022

@JeffreyPalmer - thanks for the link, I've referred to this issue there, hope that would help the Chromium team to fix the problem, although the motivation for it might be rather low as Apple is moving to M1 hardware so AMD configuration is gonna get negligible in next few years.. anyway still it would be great if they fix this :)

BTW - @greggman - have the examples you provided include any type of array instancing behind the scenes ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants