Very nice. We will endeavour to release a new GL library once we've worked through a few issues, and make sure we keep your code working :)
Thanks, Matt. I would truly appreciate a new GL drop. And generally, thank you, Genesi, for the commitment to keep efikaMX hospitable to guys like me. Re the viability of ntsh-jass, it really does not take much, as code has the ability to 'auto-repair' itself, when I'm nearby a keyboard, anyway ; )
What is the performance like in your opinion? You said you didn't have to dumb it down, does this mean you got better than you expected?
Well, it did very much in line with what I expected, from the background of my earlier experiments on the platform. I did not have to dumb down any shaders in terms of shader programming model - the z430 has a 'grown-up'-enough model that it can take low-to-mid-complexity desktop shaders unmodified, and execute them diligently (i.e. at the original precision, etc).
About speed bottlenecks - those do not appear to be currently on the GPU side - the CPU was constantly using a good portion of the frame time; CPU load never dropped much below 30%, for the heaviest of GPU workloads (same would normally sit at around 2% CPU on a well-greased GL pipeline, as the app does next to nothing on the CPU, per frame), and would rise as high as 70% for the lightest of GPU workloads, while not hitting a particularly high FPS (in comparison, figure would be at ~15, to 20% on a streamlined GL pipeline). These observations speak of the CPU's 'over-involvement' in the frame cycle somewhere down the pipeline. But I don't think I'm telling you anything new here.
Re shader complexity - the most complex of shaders I've thrown at the z430 yet was the one from the other thread with the little benchmark app, and efikaMX did well for such a complex shader (as in 'for a benchmark, not for practical applications'); despite the software blitting hampering the z430, only one other embedded platform I've tested on has been able to top that so far (and it wasn't the tegra250 ;). In ntsh-jass, though, I used more practical shaders (but still desktop-grade meshes), doing 32-bone skinning, with and without morphing, and also multi-light per-pixel illumination with up to 3 phong lights, and they all showed enough potential that if the rest of the pipeline was not dragging the framerate down, those shaders would've been usable in practical scenarios on the efikaMX (at becoming SD resolutions, naturally). Generally, if a real-life shader setup, run at SD resolutions, does low-to-mid teen's FPS, while consuming 30% or more of CPU, then there's reason to expect hitting 20's of FPS at 'good' CPU behaviour, before
any developer's effort to actually optimise for the platform. That's already talking business to me.