Renderscript. Discuss.
category: code [glöplog]
FICKEN!
Discuss.
Discuss.
Android. Didn't read any further. Sucks.
Joghurt to your point.... Wär mal ne Idee...das und...vielleicht TITTEN!
Just my 2 cents.
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?
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?
Android? <---> performance?
WTF?
And also what psonice said about trying optimizing something who can run on every possible different mobile hardware :)
WTF?
And also what psonice said about trying optimizing something who can run on every possible different mobile hardware :)
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 :)
But you know what? That's actually right up Android's alley :)
the articls sounds like a direct copy of a pr fix from the marketing deparment, uses only buzzwords, but lacks comprehensive detialed description.
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
http://developer.android.com/guide/topics/renderscript/index.html
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.
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.
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.
ماذا تعني
