shader compilation fails on Adreno 420/430
Johan Vos
johan at lodgon.com
Tue Jul 14 20:16:37 UTC 2015
I have to add that the Adreno 4xx uses ES 3.1. So far, we didn't see issues
on GPU's using ES 3.0
- Johan
2015-07-14 22:09 GMT+02:00 Johan Vos <johan at lodgon.com>:
> Hi Jim,
>
> Thanks for this info.
> The snippet is actually a part of FillRoundRect_LinearGradient_PAD.frag
> (in generated-src/jsl-prism/com/sun/prism/es2/glsl).
> If I understand it correctly, this is generated by the CompileJSL app with
> sources in jsl-prism and it is platform-neutral, so it should be the same
> on all platforms (using es2).
>
> We isolated it even more: if we remove gl_FragCoord.x and gl_FragCoord.y,
> we don't have a crash anymore. From what Google tells me, gl_FragCoord
> should be available, but apparently it isn't.
>
> It seems to me this is a bug in the Adreno 420/430 (there are more issues
> reported with it, e.g.
> https://code.google.com/p/android/issues/detail?id=163100) but if somehow
> we can avoid this crash with a workaround for the gl_FragCoord, that would
> solve many problems...
>
> - Johan
>
> 2015-07-14 21:55 GMT+02:00 Jim Graham <james.graham at oracle.com>:
>
>> I can't really speak to the android traces or the details of shader
>> compilation at runtime, but that shader code is the code that computes a
>> device coordinate from fragment coordinates, including the fact that device
>> coordinates are flipped in OpenGL. It's pretty straightforward math. The
>> only odd thing I can see about that code is that it is a computation
>> outside of any shader function (similar to a static variable in a C
>> program) and it is the only such variable like that in any of the shaders?
>> (All of the other shader variables are either uniform or varying
>> declarations and all calculations are inside the functions.)
>>
>> ...jim
>>
>>
>> On 7/14/15 12:14 PM, Johan Vos wrote:
>>
>>> Recently, we see crashes on recent Android devices that use an Adreno 420
>>> or 430 GPU.
>>>
>>> It turns out that those crashes occur while performing the native shader
>>> compilation
>>> (Java_com_sun_prism_es2_GLContext_nCompileShader)
>>> The crash really is a segmentation violation, which shouldn't happen
>>>
>>> More info is also here:
>>>
>>> https://bitbucket.org/javafxports/javafxmobile-plugin/issues/28/lollipop-51-and-error-with-gradient
>>>
>>> I managed to isolate the problem: In
>>> the FillRoundRect_LinearGradient_PAD.frag we have this:
>>>
>>> vec2 pixcoord = vec2(
>>> gl_FragCoord.x-jsl_pixCoordOffset.x,
>>>
>>>
>>> ((jsl_pixCoordOffset.z-gl_FragCoord.y)*jsl_pixCoordOffset.w)-jsl_pixCoordOffset.y);
>>>
>>> If I replace this into
>>>
>>> vec2 pixcoord = vec2(0.5,0.5);
>>>
>>> we don't see a crash anymore.
>>> Clearly this is not a solution.
>>>
>>> I'm trying to get a clue on what might be wrong, and how we can create a
>>> work-around. Unfortunately, my knowledge on shaders is extremely limited,
>>> so all help is very welcome.
>>>
>>> Thanks,
>>>
>>> - Johan
>>>
>>> fyi, the Android error is added here:
>>>
>>> F/libc (13998): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xc in
>>> tid
>>> 1402
>>> 1 (QuantumRenderer)
>>> I/DEBUG ( 354): *** *** *** *** *** *** *** *** *** *** *** *** ***
>>> ***
>>> *** *
>>> **
>>> I/DEBUG ( 354): Build fingerprint:
>>> 'google/shamu/shamu:5.1.1/LMY47Z/1860966:u
>>> ser/release-keys'
>>> I/DEBUG ( 354): Revision: '33696'
>>> I/DEBUG ( 354): ABI: 'arm'
>>> I/DEBUG ( 354): pid: 13998, tid: 14021, name: QuantumRenderer >>>
>>> com.hellog
>>> luon <<<
>>> I/DEBUG ( 354): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr
>>> 0xc
>>> I/DEBUG ( 354): r0 00000000 r1 aa9ba96b r2 00000000 r3 ffffffff
>>> I/DEBUG ( 354): r4 9f715abc r5 aec99cf0 r6 9f70f7f8 r7 00000014
>>> I/DEBUG ( 354): r8 aec99d04 r9 aaaf4b8b sl ffffffde fp 9f70fa10
>>> I/DEBUG ( 354): ip aab235a8 sp 9f70f7e0 lr aaa09205 pc aaa09218
>>> cpsr
>>> 60070030
>>> I/DEBUG ( 354):
>>> I/DEBUG ( 354): backtrace:
>>> I/DEBUG ( 354): #00 pc 005bb218
>>> /system/vendor/lib/libllvm-glnext.so (TP
>>> arseContext::handleIdentifier(TSymbol*, llvm::StringRef const&, int)+275)
>>> I/DEBUG ( 354): #01 pc 005d727d
>>> /system/vendor/lib/libllvm-glnext.so (yy
>>> 2parse(TParseContext&)+972)
>>> I/DEBUG ( 354): #02 pc 005dcd3d
>>> /system/vendor/lib/libllvm-glnext.so (yy
>>> 2PaYYParse(TParseContext&)+16)
>>> I/DEBUG ( 354): #03 pc 005e481d
>>> /system/vendor/lib/libllvm-glnext.so (YY
>>> Parser::ParseStrings(char**, long*, int, TParseContext&, int)+276)
>>> I/DEBUG ( 354): #04 pc 005b305b
>>> /system/vendor/lib/libllvm-glnext.so (Sh
>>> Compile+1326)
>>> I/DEBUG ( 354): #05 pc 00552399
>>> /system/vendor/lib/libllvm-glnext.so (LL
>>> VMCompiler::parse(QGLC_SRCSHADER*)+1188)
>>> I/DEBUG ( 354): #06 pc 005557ed
>>> /system/vendor/lib/libllvm-glnext.so (Co
>>> mpilerContext::CompileToIRShader(QGLC_SRCSHADER*,
>>> QGLC_COMPILETOIR_RESULT*)+168)
>>>
>>> I/DEBUG ( 354): #07 pc 00105903
>>> /system/vendor/lib/egl/libGLESv2_adreno.
>>> so (EsxShaderCompiler::CompileShader(EsxContext const*, EsxShader const*,
>>> EsxInf
>>> oLog*)+526)
>>> I/DEBUG ( 354): #08 pc 00103ced
>>> /system/vendor/lib/egl/libGLESv2_adreno.
>>> so (EsxShader::Compile(EsxContext*)+72)
>>> I/DEBUG ( 354): #09 pc 000b2201
>>> /system/vendor/lib/egl/libGLESv2_adreno.
>>> so (EsxContext::GlCompileShader(unsigned int)+60)
>>> I/DEBUG ( 354): #10 pc 000e4ef9
>>> /system/vendor/lib/egl/libGLESv2_adreno.
>>> so (EsxGlApiParamValidate::GlCompileShader(EsxDispatch*, unsigned
>>> int)+40)
>>> I/DEBUG ( 354): #11 pc 000a947d
>>> /system/vendor/lib/egl/libGLESv2_adreno.
>>> so (glCompileShader+44)
>>> I/DEBUG ( 354): #12 pc 00005431
>>> /data/app/com.hellogluon-1/lib/arm/libpr
>>> ism_es2_monocle.so (Java_com_sun_prism_es2_GLContext_nCompileShader+112)
>>> I/DEBUG ( 354): #13 pc 00518ea5 /data/dalvik-cache/arm/data at app
>>> @com.hell
>>> ogluon-1 at base.apk@classes.dex
>>> W/ActivityManager( 804): Force finishing activity 1
>>> com.hellogluon/javafxport
>>> s.android.FXActivity
>>>
>>>
>
More information about the openjfx-dev
mailing list