Different approaches to compute APIs: Renderscript and Filterscript from Google

Share on linkedin
Share on twitter
Share on facebook
Share on reddit
Share on digg
Share on email

Compute APIs are a new evolution in the mobile and embedded market space, and are subject to quite a range of different conceptual approaches compared to the evolution of 3D graphics API. The mobile-optimised OpenGL ES API for 3D graphics evolved from a market-tested and well-proven OpenGL API for desktop PCs; this allowed a rapid API evolution with fairly little risk. In the mobile space, two offerings are currently competing for developer attention: the Khronos developed OpenCL API (OS agnostic) and the Google Android-specific Renderscript API. While the goal of both APIs is the same in exposing parallel compute functionality, the approach and vision behind both APIs is very different, as I’ll discuss below.

Compute is far newer as an API concept, and the desktop market is still in the early days of API evolution, where a hardware-specific proprietary API called CUDA is playing a significant role. Custom APIs though are an approach long-abandoned in the 3D space. As a result, compute APIs are all still very young and are going through the usual growing pains, as the software and hardware vendors find the most optimal approaches and balanced feature sets.

Renderscript – a top-down development approach

Renderscript is a proprietary API developed by Google and specific to Android OS. Unlike OpenCL, there is no consortium-style approach where multiple hardware and software vendors agree and vote on features. Instead, the API is driven and set by a single company. As Google has mainly a software background, their approach to API development is driven from a somewhat different vision than the Khronos Group, which has a hardware-centric approach due to its membership.

In their API design, Google focussed on ease of application development. This means their approach was to create an API with an relative extreme feature set. The idea behind this vision is that by exposing all possible features, a developer can write an application once, and over time hardware will evolve and provide better and higher-performance implementations of the API. Thus, older applications will get faster without additional software development effort.

This is an interesting approach, but it is completely different from most APIs available today that expose hardware functionality. This approach can also only work if all of the features can always be supported. A software fallback safety net is required to enable all functionality, even on hardware limited devices. With Renderscript, the fallback option is to execute parallel compute operations on the CPU. This is unlikely to be the fastest path, but the CPU is the most flexible compute unit in mobile devices, and extreme functionality can always be emulated slowly using software paths.

The initial version of Renderscript was released with Android 3.0, and was completely focussed on supporting only a single type of compute device – the CPU. Later versions of Android enabled more devices, starting with the NEON unit, a SIMD floating point unit available with most ARM CPUs. The issue is that this hardware unit lacked the required ALU precision to enable acceleration of the Renderscript API, and hence Google had to make the first concession in their API design approach. This included exposing pragma options that allowed relaxed precision and feature set requirements, thus allowing the faster-than-the-CPU NEON unit to be used to speed up the Renderscript experience on devices.

Android version 4.1 jumped onto the GPU compute bandwagon, enabling Renderscript acceleration on GPU devices. However, it quickly became clear that performance was an issue. As a result, GPU-based Renderscript acceleration was an unpredictable experience. One GPU versus another and GPU versus CPU scenarios could lead to rather unexpected behaviours, where a software developer might not know if their script would run fast enough by using a GPU, or would end up using the fallback path, and thus would end up running quite slowly.

Again, the pragmas brought some help, and relaxing precision requirements allowed much more extensive and fast path modes for GPUs (as well as enabling the ARM NEON SIMD unit). However, using pragmas is something which developers easily forget, as they are used to the OpenCL model. They expect that everything works, is supported and runs fast. This was not what Renderscript offered which was a wide fragmentation of performance level across CPU types, CPU counts and numerous different GPUs.

Filterscript – a sensible selection of features and precision requirements

As a result, with Android version 4.2, we have seen the introduction of Filterscript, a sensible selection of features and precision requirements that aligns with the balanced feature sets offered by mobile GPUs. Developers now have two options:

  • they can develop a Renderscript script and deal with massive fragmentation where a script is unlikely to be run accelerated on the GPU in most devices (remember the low cost and mainstream markets are far larger than the superphone/tablet market)
  • they can develop a Filterscript script, which has a very high chance of running at extremely fast speeds as expected from GPU acceleration.

In a simplified way, Filterscript is a bit like the bottom-up approach where the feature set matches the capabilities of the majority of the hardware out there, thus ensuring developers a consistently high-performance accelerated experience, whereas Renderscript is a superset approach mostly there to abstract between different CPU types (MIPS, x86, ARM).

The top-down software development centric concept for Android’s Renderscript is shown below, demonstrating the evolution of bringing the API in line with a feature set optimal for power-efficient execution on mobile GPUs through pragmas, and ultimately through the introduction of the Filterscript variant:

PowerVR - mobile GPU computing - Renderscript Filterscript evolution

The initial top-down approach has led to some confusion among developers regarding the level of support for CPU/GPU architectures. Key to remember is that all PowerVR devices, based on the SGX or ‘Rogue’ architecture, support both Renderscript and Filterscript. GPU acceleration will be difficult to predict, as it depends on the features used in the script, but also on how busy the GPU is (e.g. with graphics or other compute tasks). By using Filterscript, you will in general have a higher chance of acceleration on GPUs from Imagination or other vendors.

Have you used Renderscript/Filterscript acceleration in your applications? What do you think about Google’s API for mobile compute? For more articles, news and announcements on GPU compute, keep coming back to our blog and follow us on Twitter (@ImaginationTech, @GPUCompute and @PowerVRInsider).

 

Kristof Beets

Kristof Beets

Kristof Beets is the senior director of product management for PowerVR Graphics at Imagination Technologies where he drives the product roadmaps to ensure alignment with market requirements. Prior to this, he was part of the business development group and before this, he led the in-house demo development team and the competitive analysis team. His engineering background includes work on SDKs and tools for both PC and mobile products as a member of the PowerVR Developer Relations Team. His work has been published in many guides game and graphics programmers, such as Shader X2, X5 and X6, ARM IQ Magazine, and online by the Khronos Group, Beyond3D.com and 3Dfx Interactive. Kristof has a background in electrical engineering and received a Master's degree in artificial intelligence. He has spoken at GDC, SIGGRAPH, Embedded Technology, MWC and many other conferences.

5 thoughts on “Different approaches to compute APIs: Renderscript and Filterscript from Google”

  1. Its frustrating Google continues to support Renderscript and should just keep Filterscript and support OpenCL for things where you want precisions and control. The same reasons listed here as negatives for Renderscript are some of the arguments used by Google to not support OpenCL and some are handled better by OpenCL. And please stop with the OpenCL ES non-sense please. Other vendors (Two now) are supporting Full profile on mobile. The full profile has a fast-math option which should allow for lower power uses when needed. There are huge benifits to running similar code to the desktop and then just tweaking performance for each platform. WHy does Google have to release APIs like Renderscript Graphics then fail so they push that effort into Renderscript Compute then fail, then push that effort into Filterscript. When that fails we will just be back at using compute shaders. I’m sorry but anyone work their dirt writting optimized GPU code is going to have a reference C implementation which they start with so the “We have to have a failback option” is just silly. Thank you for your article and pointing to the failures of Renderscript compute. I hope you will encourage Google to stop preventing APIs which developers want and need.

    Reply
  2. Its frustrating Google continues to support Renderscript and should just keep Filterscript and support OpenCL for things where you want precisions and control. The same reasons listed here as negatives for Renderscript are some of the arguments used by Google to not support OpenCL and some are handled better by OpenCL. And please stop with the OpenCL ES non-sense please. Other vendors (Two now) are supporting Full profile on mobile. The full profile has a fast-math option which should allow for lower power uses when needed. There are huge benifits to running similar code to the desktop and then just tweaking performance for each platform. WHy does Google have to release APIs like Renderscript Graphics then fail so they push that effort into Renderscript Compute then fail, then push that effort into Filterscript. When that fails we will just be back at using compute shaders. I’m sorry but anyone work their dirt writting optimized GPU code is going to have a reference C implementation which they start with so the “We have to have a failback option” is just silly. Thank you for your article and pointing to the failures of Renderscript compute. I hope you will encourage Google to stop preventing APIs which developers want and need.

    Reply
  3. It sounds like Google’s compute API is somewhat messy as they try to make up for their API’s shortcomings based on previous presumptions by introducing another more restricted API (that annoyingly requires sources be placed in a separate .fs file).
    Would it be possible to achieve filterscript like performance from renderscript, by adhering to filterscript rules (eg. no pointers, relaxed float pragma (if available), root definition attribute, lack of globals, etc)? Moreover, perhaps it would be of benefit for GPU vendors to provide a list of the renderscript functions that are accelerated, to help performance driven devs to know what to use and what to steer clear of.
    In any event, I’m glad that filterscript exists. Sure it hardly seems the most elegant solution, but at least there is an API that has a higher chance for higher performance at the expense of a bit of convenience!
    This blog post is invaluable. Thank you kindly.

    Reply
  4. I knew there were issues holding usage of Renderscript back and leading to the addition of Filterscript for more reliable GPU compute, but I had picked up on very little in the way of details until reading this article. Thanks!

    Reply
    • You can find some technical details and examples of Renderscript code in the Android SDK.
      But we wanted to offer developers the background story on how compute APIs have evolved, where they are headed next and the level of support we offer on PowerVR and MIPS.
      Regards,
      Alex.

      Reply

Please leave a comment below

Comment policy: We love comments and appreciate the time that readers spend to share ideas and give feedback. However, all comments are manually moderated and those deemed to be spam or solely promotional will be deleted. We respect your privacy and will not publish your personal details.

Blog Contact

If you have any enquiries regarding any of our blog posts, please contact:

United Kingdom

[email protected]
Tel: +44 (0)1923 260 511

Search by Tag

Search by Author

Related blog articles

Beaglebone Black

Fun with PowerVR and the BeagleBone Black: Low-Cost Development Made Easy

Development boards are cool and the BeagleBone® Black (BBB) is one of the more interesting ones around. This widely available tiny board costs around £35 and will boot Linux is only 10 seconds so anyone interested in development can get stuck in quickly. The Introduction to Mobile Graphics course has been recently revamped for 2020 for the Imagination’s University Programme and the widely available, low-cost BBB is an ideal platform for student teaching and exercises based on OpenGL® ES2.0, instead of an expensive standard PC.

Read More »
Apple M1 image

Why you should be running your iOS apps on your new Apple M1 laptop

Towards the end of last year, Apple released the latest version of its Apple MacBook Pro and Macbook Air laptops. This release was notable as with these brand-new laptops Apple made a significant change – the processor inside was based on its own M1 chip rather than the Intel architecture that it had been using since 2006. Since its release, the Apple M1 has been widely hailed for its performance, outstripping Intel in all the major benchmarks and all in a cool, quiet package with low power consumption.

Read More »
android background

The Android Invasion: Imagination GPU IP buddies up with Google-powered devices

Google Android continues to have the lion share of the mobile market, powering around 75% of all smartphones and tablets, making it the most used operating system in the world. Imagination’s PowerVR architecture-based IP and the Android OS are bedfellows, with a host of devices based on Android coming to market all the time. Here we list a few that have appeared in Q4 2020.

Read More »

Connect

Sign up to receive the latest news and product updates from Imagination straight to your inbox.