BeagleBone and 3D printers

I've been messing around with a couple of 3D printers for the last few months, I'll write a post about those at some point, it's a really interesting technology, with interesting shortcomings that IMO reflect the nature of opensource development.
This post however is about my experiences with a BeagleBone and attempts to use one as a host for a 3D printer, it's a TI AM3359 development board, on the face of it it has more than enough CPU and more than enough IO to easily drive a 3D printer.
My vision was a compact host with a touch screen and ethernet that could do the slicing (produce the tool paths for the printer) as well as send signals to the stepper drivers.
Unfortunately this is going to turn into a rant about the stupidity of secrecy over GPU internals.
You basically have two options on a BeagleBoard, you can either use Linux as an OS or you can code straight to the metal using something TI calls Starterware.
Now we want to write a motion controller, and that will not tolerate latency in response to interrupts, that makes Linux a less than ideal solution. Yes there are Linux kernels with realtime extensions but I doubt any of them could meet the latency requirements on a single core 700MHz Arm Cortex8.
So I start to take a loot at Starterware, the tools are horrible, but more in the "nobody at TI could be bothered making them work properly way" as opposed to the lack of functionality way, still not the worst development environment I've ever used. So looking at the samples, all seems straight forwards , I can bang pins, turn LED's on and off make ethernet connections, great....
But absolutely no access to the GPU.
Why do I care?
Well creating tool paths from a polygon model is computationally expensive, and my plan was to leverage the GPU to do most of the work, it's trivial to render a slice of the model using a variation of the classic shadow volume algorithm, I'd then convert that to spans and extract the paths.
OK then after much bitching and asking around to try and get docs on the PowerVR SGX included in the BeagleBone I give up and start looking at Linux as a solution.
The TI AM3359 has two onboard IO processors called PRU2's which I should be able to use to drive steppers, of course TI have never released the PRU2 version of the assembler for them, but the PRU1 assembler does produce usable code, I defer looking at the details until later.
OK onto Linux, and using the GPU to slice models!
After a lot of messing around.
Finding a version of Linux that works with the GPU drivers
Figuring out which bits of OpenGLES don't work in drivers
Figuring out what exact combination of color, depth and stencil surfaces actually work with FBO's
Figuring out how to get Linux to not boot into X
Ok I write a couple of hundred lines of code and I can render slices of the model, now to convert those slices into spans.
I do the obvious GLReadPixels, which I wouldn't expect to have great performance, but in practice it was hideous, the GLES2 driver doesn't support PBO's so I can't do the read asynchronously...
I think about it a bit more and realize that I can do the span conversion using OpenCL, at which point I only have to read the relatively small span buffer from the GPU rather than the entire 2Kx2K framebuffer.
After much web searching I discover that although Imagination Technologies (the IP developer of the SGX GPU) have in fact demonstrated an OpenCL driver and in fact claim that SGX supports compute, TI do not license the driver (as far as I can determine no one does).
And there we are, no way to proceed other than the hideously slow GLReadPixels.
The proprietary drivers and secrecy surrounding the documentation lock me into Linux, and then it doesn't provide enough functionality to do what I want....
I just don't get the secrecy surrounding the register/command stream level documentation for GPU's, I just can't imagine there is anything there that would expose the IP holder. Back in the NV2x days I reverse engineered the command stream so we could disassemble them and build them offline, and it was stunningly uninteresting. The only reason I can imagine the secrecy is that the IP companies are making money off licensing the drivers, and it removes any chance of competition.
Either way it makes the TI AM3359 much less useful for my purposes, and I'd immediately rule out anything using an Imagination Technologies part when looking at alternatives.
UGH!