CODEWITHSUNDEEP
androidrenderscriptandroid-renderscript
wz2b
wz2b

Reputation: 1025

RenderScript native library in aar/apk

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?

Upvotes: 0

Views: 514

Answers (1)

Larry Schiefer
Larry Schiefer

Reputation: 15775

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

Upvotes: 1

Related Questions