[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-openjfx-dev
Subject: Re: shader compilation fails on Adreno 420/430
From: Jim Graham <james.graham () oracle ! com>
Date: 2015-07-30 0:08:10
Message-ID: 55B96AEA.5090204 () oracle ! com
[Download RAW message or body]
Hi Johan,
Now that I look at it, all source code substitutions generally happen
before compilation. The back ends are mostly translation processors and
work on antlr trees.
One issue with your fix is that you are doing it in the SLBackend which
works for all shaders, even D3D shaders - you want this exclusive to the
ES2BackEnd.
Another way to fix this is to do it in visitFuncDef() which is where
other funcion-specific properties are managed. Right now all that
ES2Backend does in visitFuncDef() is optionally emit a "lowp" modifier.
You can check the function name there and if it is main() then you
could modify the FuncDef statement to include an additional block of
code, but you'd have to express it as a compiler Tree node. It looks
like "GlueBlock" was created for this purpose. The following might work:
ES2Backend.visitFuncDef(FuncDef d) {
Function func = d.getFunction();
String name = func.getName();
...lowp stuff...
if (isPixCoordUsed && name.equals("main")) {
List<Stmt> newbody = new ArrayList<>();
newbody.add(new GlueBlock(PIXCOORD_SRC));
Stmt s = d.getStmt;
if (s instanceof CompoundStmt) {
newbody.addAll(((CompoundStmt) s).getStmts());
} else {
newbody.add(s);
}
d = new FuncDef(func, newbody);
}
super.visitFuncDef(d);
}
...jim
On 7/29/15 9:04 AM, Johan Vos wrote:
> 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@oracle.com
> <mailto:james.graham@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@oracle.com
> <mailto:james.graham@oracle.com>
> <mailto:james.graham@oracle.com <mailto:james.graham@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@lodgon.com
> <mailto:johan@lodgon.com>
> <mailto:johan@lodgon.com <mailto:johan@lodgon.com>>
> <mailto:johan@lodgon.com <mailto:johan@lodgon.com>
> <mailto:johan@lodgon.com <mailto:johan@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@oracle.com
> <mailto:james.graham@oracle.com> <mailto:james.graham@oracle.com
> <mailto:james.graham@oracle.com>>
> <mailto:james.graham@oracle.com
> <mailto:james.graham@oracle.com>
>
> <mailto:james.graham@oracle.com
> <mailto:james.graham@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@app
> @com.hell
> ogluon-1@base.apk@classes.dex
> W/ActivityManager( 804): Force
> finishing activity 1
> com.hellogluon/javafxport
> s.android.FXActivity
>
>
>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic