0

I am trying to troubleshoot this:

E/RenderScript: Unable to open shared library (/data/user_de/0/com.xxxx/code_cache/com.android.renderscript.cache/librs.yuv2rgbframes.so): (null)

I've set up renderscript in build.gradle as instructed by the documentation:

android {
    ...
    defaultConfig {
        ...
        renderscriptTargetApi 18
        renderscriptSupportModeEnabled true
    }
}

At first I thought that it was because the renderscript itself is in another module (which makes an .aar that is linked in by the application project) but that doesn't seem to be the problem. I tried putting the above into both the .aar module and the application module - no difference.

My next step was to look at the contents of the .aar and the .apk which leads to my question: should I be able to see the generated .so files in there somewhere? I expected to see an .so for arm7 and another one for x86, but no.

There's some SO questions about this but they aren't the same thing. But my main question here has to do with how I troubleshoot this: where does this .so file end up. I think the tools must actually be set up OK because it successfully generates the java stubs for the renderscript ....

...

EDIT: maybe I misundestand what is going on here. After the error I pasted there are two more messages:

E/RenderScript: Unable to open shared library (/data/user_de/0/com.xxx.powerscan/code_cache/com.android.renderscript.cache/librs.yuv2rgbframes.so): (null) V/RenderScript: Invoking /system/bin/bcc with args '/system/bin/bcc -unroll-runtime -scalarize-load-store -rs-global-info -rs-global-info-skip-constant -o yuv2rgbframes -output_path /data/user_de/0/com.xxx.powerscan/code_cache/com.android.renderscript.cache -bclib /system/lib64/libclcore.bc -mtriple aarch64-none-linux-gnueabi -O 3 -aarch64-fix-cortex-a53-835769 -load libbccQTI.so -fPIC -embedRSInfo /data/user_de/0/com.xxx.powerscan/code_cache/com.android.renderscript.cache/yuv2rgbframes.bc -build-checksum abadcafe' V/RenderScript: Invoking /system/bin/ld.mc with args '/system/bin/ld.mc -shared -nostdlib /system/lib64/libcompiler_rt.so -mtriple=aarch64-none-linux-gnueabi --library-path=/system/vendor/lib64 --library-path=/system/lib64 -lRSDriver_adreno -lm -lc /data/user_de/0/com.xxx.powerscan/code_cache/com.android.renderscript.cache/yuv2rgbframes.o -o /data/user_de/0/com.xxx.powerscan/code_cache/com.android.renderscript.cache/librs.yuv2rgbframes.so'

Does it actually generate that .so on platform?

wz2b
  • 1,017
  • 7
  • 24
  • Interestingly, in my project directory I found a directory build/generated/renderscript_source_output_dir that contains some .java files. One of them contains a static byte[] method that is just a bunch of numbers - I'm guessing the actual compiled renderscript. – wz2b Jan 16 '19 at 16:05
  • Were you able to resolve this? I'm developing a library and thinking of implementing some logic in renderscript so that it's re-usable. – user3689913 Jun 24 '20 at 12:30
  • I did, I eventually got a project that built and worked. The tooling still felt a little brittle to me, though. Generally though the process does work - you write the code, it generates native libraries for various platforms and architectures. If one doesn't match, it runs the code through some kind of interpreter, I guess, so it'll be slow but still work. – wz2b Jun 24 '20 at 16:47

1 Answers1

1

Yes, Renderscript code is compiled on target from it internal bitcode format. It's done this way because each Android device is different and supports RS in different ways. Very basic platforms will provide a CPU "driver" layer, which will only leverage the CPU to do the RS work (using multiple threads). In this case, your RS bitcode is compiled into native code. Most modern Android platforms will leverage the GPU or an onboard DSP instead. In this case the bitcode for your specific RS code is "compiled" into GPU/DSP instructions and the platform "driver" layer for RS will offload your RS operations to the GPU/DSP.

This talk has some info about how this works and will hopefully provide you with some helpful information: https://youtu.be/3ynA92x8WQo

Larry Schiefer
  • 15,687
  • 2
  • 27
  • 33