shader compilation fails on Adreno 420/430
Johan Vos
johan at lodgon.com
Wed Jul 29 16:04:24 UTC 2015
Hi Jim,
I wrote a work-around, and tested it on javafxports. The patch is at
https://bitbucket.org/javafxports/8u60-rt/commits/595633bbaae36f98d85d47d276294442ea43488c
The pixcoord declaration was (conditionally) added in ES2Backend.java, in
the header. I removed it there.
It would be nice to add it conditionally in the main clause, but I couldn't
get that done easily (antlr complained about invalid syntax when processing
the source).
So for testing, I did a dirty replace (conditionally again, only when
pixcoords should be used) and insert the declaration inside the main
function.
At least HelloWorld with a default Button (which uses
FillRoundRext_LinearGradient_PAD.frag) now works fine.
- Johan
2015-07-28 20:42 GMT+02:00 Jim Graham <james.graham at oracle.com>:
> 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