shader compilation fails on Adreno 420/430
Jim Graham
james.graham at oracle.com
Tue Jul 14 23:44:41 UTC 2015
We have an optimization that is sitting on the back burner which would
get rid of the use of pixcoord in the primitive shaders:
https://bugs.openjdk.java.net/browse/JDK-8090226
Fixing that bug may improve performance of gradients even on desktop,
but it would take a bit of rework of the shader compilation code. A
side effect is that gradients would no longer refer to the
"wincoord/pixcoord" variable that is causing problems here.
wincoord/pixcoord is still used in the PhongLighting effect shaders,
though...
...jim
On 7/14/15 1:16 PM, Johan Vos wrote:
> 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
> <mailto: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
> <mailto: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