5

I can't seem to find any documentation on how to check if RenderScript is actually parallelizing code. I'd like to know whether the CPU or GPU is being utilized and the number of threads dispatched.

The only thing I've found is this bug report: http://code.google.com/p/android/issues/detail?id=28662

The author mentions that putting rsForEach in the script resulted it it being serialized by pointing to the following debug output:

01-02 00:21:59.960: D/RenderScript(1256): = 0  0x0
01-02 00:21:59.976: D/RenderScript(1256): = 1  0x1

I tried searching for a similar string in LogCat, but I haven't been able to find a match.

Any thoughts?

Update: Actually I seem to have figured it out. It just seems that my LogCat foo isn't as good as it should be. I filtered the debug output by my application information and found a line like this:

02-26 22:30:05.657: V/RenderScript(26113): rsContextCreate dev=0x5cec0458
02-26 22:30:05.735: V/RenderScript(26113): 0x5d9f63b8 Launching thread(s), CPUs 2
icebreeze
  • 113
  • 5

3 Answers3

2

This will only tell you how many CPUs could be used. This will not indicate how many threads or which processor is being used. By design RS avoid exposing this information

In general RS will use all the available CPU cores unless you call a "serial" function such as the rsg* or time functions. As to what criteria will result in a script being punted from the GPU to CPU, this will vary depending on the abilities of each vendors GPU.

The bug you referenced has been fixed in 4.1

R. Jason Sams
  • 1,469
  • 9
  • 10
2

I came across the same issue, when I was working with RS. I used Nexus 5 for my testing. I found that initial launch of RS utilized CPU instead of using GPU, this is verified using Trepn 5.0s application. Later I found that Nexus-5 GPU doesnt support double precision (Link to Adreno 330), so by default it ports it onto CPU. To overcome this I used #pragma rs_fp_relaxed top of my rs file along with header declarations.

So if you strictly want to port it onto GPU then it may be best way to find out your mobile GPU specs and try above trick and measure GPU utilization using Trepn 5.0s or equivalent application. As of now RS doesnt expose thread level details but during the implementation we can utilize the x and y arguments of our root - Kernel as thread indexes.

Kaliuday
  • 110
  • 8
  • was there any discernible change in the LogCat output when RS started running on the GPU? I'm experimenting with a Mali GPU (Mali doesn't seem to offer any GPU profiling tools like Trepn, and Trepn doesn't seem to recognize Mali GPUs) and the LogCat output remains the same no matter what `rs_fp_xxx` pragma I use. I even tried `FilterScript`s as suggested in http://stackoverflow.com/questions/13917106/where-is-the-filterscript-documentation-and-how-can-i-use-it but to no avail. – Janaka Bandara Mar 05 '16 at 02:23
1

Debugging properties

RenderScript includes the debug.rs.default-CPU-driver and debug.rs.script debugging properties.

debug.rs.default-CPU-driver

Values = 0 or 1

Default value = 0

If set to 1, the Android Open Source Project (AOSP) implementation of RenderScript Compute is used. This does not use any GPU features.

debug.rs.script

Values = 0 or 1

Default value = 0

If set to 1, additional diagnostic information is printed in the logcat. This information includes the actual device a kernel is running on, either GPU or application processor. If a kernel cannot be run on the GPU more detailed information is provided explaining why. For example: [RS-DIAG] No support for recursive calls on GPU

Arm® Mali™ RenderScript Best Practices_pdf

Yessy
  • 1,172
  • 1
  • 8
  • 13