[PD-dev] Functional Programming & C code generation

[Tom Schouten]

On 05/17/2013 06:47 AM, Claude Heiland-Allen wrote:
> On 16/05/13 16:32, Tom Schouten wrote:
>> What I want to do is to get the image processing part of PDP to run on
>> the GPU.
>> Target platforms: desktop, Android, iOS, something like raspberry pi, ...
>> Currently probably Android as first attempt.
> OpenGL ES2 is probably the best thing to target first for phones and rpi:
>
> http://www.khronos.org/opengles/2_X/
>
> The pdf spec seems to be quite readable.
>
> I think ES2 is vaguely the intersection of OpenGL 2 and OpenGL 3, with
> some parts removed and other parts adapted to embedded systems.
>
> There's an ARB_ES2_compatibility extension for full OpenGL, so it should
> be simpler to port from GLES to GL than the other way around.  Plus Mesa

I see.
A bottom up approach seems best then.
See what is there, then see what it can be used for..

>> = 8 apparently supports GLES.
>> Also, PDP is 16 bit integer pixel depth.
> 16bit per channel or per pixel?

Per color channel.

>> Is that something that can be done easily these days?
> In OpenGL, yes - but OpenGL ES 2 only goes up to 8bit per channel (apart
> from Depth which goes up to 16bit I think) and there are some packed
> formats with fewer bits per channel (pages 63 and following in the spec
> pdf).  There are probably extensions to GLES that support more stuff.
> Also computation is specified as "floating point with accuracy to around
> 1 part in 10^5", with precision modifiers for less/more
> accuracy/speed...  Desktop OpenGL also uses mainly floating point for
> computation, with more storage formats (eg float textures).

That is a bit limiting..
8 bit isn't much when you start playing with feedback.
Though still possible to do something interesting I guess.


I had a look at GLSL too for GPGPU computation using the pixel shaders.
I think I get the point now, but it sure isn't straightforward to work with!

Porting the RAI C code gen stuff to create shader kernels seems quite 
straightforward.

However, the texture juggling for composing multiple shader programs 
when the memory access can't be parallellized is something that would 
require some new approaches.

Apart from image processing, I can see this have some application for 
generating complex dynamic wavetable synths (i.e. scanned synthesis).