Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

More abstract GPU access / Compute shaders

edited January 2014 in General Posts: 68

I was going to put this in the shaders category, but it isn't really about the more graphical aspect which shaders focus on.

Anyways, I wonder if there are any plans to implement a more abstract access to the great parallel processing of the GPU. I ask this, because after developing a complex particle system, I came across several bottlenecks. I very quickly managed to speed it up after switching the particles from using Sprite to a single mesh for the emitter as a whole, and then agonized more about how to further speed it up.

I did the intelligent thing and tried some benchmarking, and came across a pretty staggering conclusion, after all my work on a PC using the software renderer of SDL (which was always very slow, as rendering on a CPU isn't great):

The rendering wasn't the bottleneck! - the basic, simplistic, barebone integration was; that is, just moving the particles using very cheap Euler integration. After disabling it, the system made a dramatic leap, even when rendering the same amount of particles, to doubling in FPS. This should've been obvious, but the CPU of my iPad 2 was pathetic compared to the CPU of my (very old) desktop, which doesn't even shrug at 10 times the amount of particles being integrated.

{EDIT: I'm probably going to change to Verlet integration, as it's (supposedly - I'll need to check) slightly faster and more stable meaning connected particle streams would be easier}

Of course, integration is easily stuck onto a GPU. Order doesn't matter, especially when particles don't collide with anything - and even if they did, it could be done after the integration is finished, by the CPU.

A fragment or pixel shader don't hand themselves to this task easily. They simply aren't designed for it. A compute shader, or an OpenCL-like interface, however, does! So, what I'm asking for, is a more abstract way to use the GPU, not on pixels or vertexes, but simple data.

Thanks very much for reading this all... and for those who don't, TL:DR:

Is a more general way to access the GPU in Codea planned, or even possible? I'd be very useful.

Comments

  • Posts: 2,042

    What is TL:DR:?

  • @JakAttak It's short for Too long: Don't Read - essentially a summary of what I'm saying.

  • Posts: 2,042

    I see, well I read it all anyways

  • Posts: 502

    Do you have a link to any iOS example code using this? It might clarify a bit on what you are after. The openGl chipset might be a to limited on the iPad?

  • edited January 2014 Posts: 68

    I have no idea on how possible it is on an iDevice, which is why I'm asking. I've not done any actual app development outside of Codea, partially because I don't own a Mac.

    It'll be possible to do in the fragment shaders anyways, but there is interesting potential if some more abstract access to the GPU will become possible.

    Edit: I have found this, which at least indicates it's possible. Probably. https://github.com/linusyang/opencl-test-ios

Sign In or Register to comment.