shader compilation fails on Adreno 420/430
Jim Graham
james.graham at oracle.com
Tue Jul 28 18:42:01 UTC 2015
We may have to teach the JSL compiler to inject the code into the main()
function instead of having it in the initializer then.
Johan, did you want to try to look at that? A good place to start would
be the two "CompileJSL.Java" files, one in Prism and one in Decora and
how they process WINCOORD/pixcoord in the files. It wouldn't require
any compiler expertise since that is all handled by Antlr and the Java
files are more glorified source code substitution mechanisms - it would
simply be transferring the substitution from a block that goes into the
declaration into a chunk of code inserted into the main method...
...jim
On 7/23/15 5:29 AM, Johan Vos wrote:
> Hi,
>
> As a follow-up on this issue, I posted the problematic shader on the
> Qualcomm developer network. There is a reply now that states the shader
> is wrong, as we are initializing pixcoord using a non-constant
> expression. See
> https://developer.qualcomm.com/comment/9245#comment-9245 for the
> comment, including a reference to the spec which states:
> /"In declarations of global variables with no storage qualifier or with
> a const qualifier, any initializer must be a constant expression."/
>
> - Johan
> /
> /
> /
> /
>
> 2015-07-15 1:44 GMT+02:00 Jim Graham <james.graham at oracle.com
> <mailto:james.graham at oracle.com>>:
>
> 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>
> <mailto: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>
> <mailto: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