pouët.net

Renderscript. Discuss.

category: code [glöplog]
 
added on the 2012-05-18 19:23:49 by xernobyl xernobyl
FICKEN!

Discuss.
added on the 2012-05-18 19:28:37 by Joghurt Joghurt
Android. Didn't read any further. Sucks.
added on the 2012-05-18 20:31:42 by xTr1m xTr1m
Joghurt to your point.... Wär mal ne Idee...das und...vielleicht TITTEN!
Just my 2 cents.
I'm struggling to get what the point of it is. At first it's described as a new language to let you get 'closer to the metal' for 'performance critical stuff'.

But they they say your code can run on either the CPU or GPU, and that decision gets made on the device at runtime. If it's performance critical, that's exactly the kind of decision you need to make up front so you can optimise everything and keep the data flowing through. I write some very performance critical video processing apps for iOS, and if some parts of the engine decided to run on the CPU it would *utterly* fuck up the app.

I can see the benefit - if your 'performance critical' app is run on a device with a shitty GPU it'll run the GPU part on the CPU, and you end up with better performance (or at least not it runs). Your app will run like a bag of shit with broken pedals, but at least those broken pedals get a squirt of lube.

There's another issue though: the hardware varies so much. It's a language for people who're comfortable coding 'closer to the metal'. What they mean there is "coding closer to some kind of metal, could be an old tin can, could be a lump of gold".

I always took 'close to the metal' as meaning optimising heavily for the hardware and really taking advantage of it, but how can you do that if it has to run on amiga, atari, and c64? With that kind of setup I'd think it makes sense to go with openGL and let the drivers deal with the hardware differences as much as possible. And write code that can run on any number of cores.

Maybe I'm missing something?
added on the 2012-05-18 23:05:01 by psonice psonice
Android? <---> performance?

WTF?

And also what psonice said about trying optimizing something who can run on every possible different mobile hardware :)
added on the 2012-05-18 23:28:56 by rez rez
Looks like a conceptually misguided hack that has the very potential to create more complexity than it will solve.

But you know what? That's actually right up Android's alley :)
added on the 2012-05-18 23:39:20 by superplek superplek
the articls sounds like a direct copy of a pr fix from the marketing deparment, uses only buzzwords, but lacks comprehensive detialed description.
added on the 2012-05-19 12:51:11 by vectory vectory
The article is absolute garbage. Also remember, in the context of Android 'closer to the metal' can mean 'not Java'.
It seems to generate java code. I don't get the point...
http://developer.android.com/guide/topics/renderscript/index.html
added on the 2012-05-19 13:24:40 by MsK` MsK`
Forget what I just said, it's just-in-time compiled to native by llvm and compiled to some bytecode also by llvm. I still don't get the point though.
added on the 2012-05-19 13:26:22 by MsK` MsK`
What I liked about RenderScript was photo processing. Had some filters implemented for GLSL and run them in realtime using screen sized texture. And RenderScript is close enough to GLSL for maintaining pretty much the same code for generating final full sized photo.

But then again, guess NDK was faster when it comes to device I'm running this code on. Just liked the similarity and wanted to try RenderScript out.
added on the 2012-05-19 21:07:05 by harism harism
ماذا تعني
added on the 2012-05-19 22:56:57 by airc airc

login