Let's recap: - Renderscript Graphics has always been hardware accelerated - Renderscript Compute is currently CPU bound but with the for_each construct it will take advantage of multiple cores immediately - Renderscript Compute was designed to run on the GPU and/or the CPU - Renderscript Compute avoids having to write JNI code and gives you architecture independent, high performance results - Renderscript Compute can, as of Android 4.1, benefit from SIMD optimizations (NEON on ARM)
If you want to write apps that benefit from hardware acceleration you can either: - Use the Java OpenGL ES 1.x/2.x bindings - Use OpenGL ES 1.x/2.x from native code with the NDK (at the cost of having to target specific CPU architectures) For data processing you can: - Write normal Java code - Use the NDK/JNI - Use Renderscript Compute Renderscript Compute is likely to give you the best performance as well as portability. I recommend you watch Jeff Sharkey's "Doing More With Less" talk that he gave this year at Google I/O. He shows an example of Renderscript Compute for data processing. On Sat, Jun 30, 2012 at 1:39 PM, Morrison Chang <morrison.ch...@gmail.com>wrote: > *I also didn't realize that the Renderscript Graphics API was > 'experimental'.* > * > * > *Let me preface this that right before Google IO 2012, I started > researching Renderscript to see what could be done with it (in the > expectation of compute on GPU in Jelly Bean - sadly nothing announced that > I’m aware of). > > I find it interesting (and humorous) that the Renderscript Graphics which > was only introduced in Honeycomb and more fleshed out in Ice Cream Sandwich > is already depreciated BUT is included in the ICS Compatibility Definition > Document (CDD) in section 7.1.4. Given that Renderscript Graphics was > created back in the 2.1 (Eclair) timeframe as an internal API for > implementing multi-platform live wallpapers and throughout the 2.x series > OpenGL 1.0 hardware acceleration was optional so perhaps CPU bound was > okay(?). When ICS (and by extension HC) came out, the CDD pretty much > requires hardware acceleration. And now that JB has deeper integration of > hardware acceleration with the UI system (Project Butter/Jank Busting) I > think Renderscript Graphics became the odd man out as it is one more path > for Google/ODMs to regress beyond the standard Java and NDK APIs. > > So now we are back to Java if we want to write multi-platform code for > graphics (as intended) but would need to write with NDK and compile > multiple binaries if we want to squeeze out performance. Of course now that > we have faster CPUs, bigger apk sizes, and multiple apk support so it may > not be an issue anymore. > > If anything at least the compute part of Renderscript survives. > > I look forward to when the JB CDD is released as Google/ODMs will have to > support to older HC/ICS path, but perhaps there may be more detailed > specification for the compute part if not in JB then in K. > > Still it would be nice to get a blog post from Chet and/or Romain on the > rational behind releasing Renderscript graphics API for about a year and > half before dropping it (and with only a 10% device base). Frankly I liked > the idea of being able to not deal with JNI if I wanted performant graphics. > > Hmm this is getting long and I apologize if you've gotten this far.* > * > tl;dr - Renderscript for compute will eventually get to the GPU, > Renderscript graphics API has been sacrificed on the altar of support.* > > Morrison > > On Saturday, June 30, 2012 12:54:25 PM UTC-4, JP wrote: >> >> >> >> On Jun 30, 9:26 am, Rutton <rut...@web.de> wrote: >> >> > No one ever mentioned before, that it was "experimental". >> >> Huh, correct in my book. Although it was always supposed to be >> understood that the underlying graphics engine today is running CPU >> bound only, which makes it somewhat pointless in its actual >> implementation. In the documentation, this goes easily overlooked. >> >> ----------- >> >> Just a few short months ago I've attended a presentation by Romain Guy >> and one of his colleagues that praised Renderscript as *the* way >> forward, in my impression anyways. It would probably be a good idea >> for Google to clarify what deprecation of the graphics engine means >> going forward. Perhaps a new graphics engine is in the works, that >> actually utilizes the GPU. Perhaps using deprecation was just a poor >> choice of word? >> > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
