[meta-freescale] BSP 1.1.0 vs. OpenGL ES2.0/Qt5

[Thomas Senyk]

On Tue, February 26, 2013 19:25:41 Thomas Senyk wrote:
> Hi,
> 
> I think it's time to start a independent thread about (my) inability to get
> anything OpenGL ES2.0 related running on the new BSP (aka.: "[PATCH v4 0/9]
> iMX6Q BSP 1.1.0 upgrade")
> 
> fyi: I'm always building without 'x11' in DISTRO_FEATURES
> 
> 
> My findings so far:
> 1. Someone mentioned that it's possible to deploy/unpack the 1.1.0 drivers
> on top of a 12.04.01-image and still run Qt5.
> I can confirm this!
> This means it's NOT the libraries (aka. driver?) which are causing this
> problem!
> 
> (From here on everything is based on a "PATCHv4"-build!)
> 
> 2. I can't get any of the viv_samples running!
> Their behavior is rather erratic
> (sometimes errors and crashes, something just black screen nothing on
> stdout) ... I guess it's because they "pollute" the drivers-state if they
> crash...
> 
> Anyway: Very often I get errors like:
> 
> VertexShader: chiclet.vert: comiple error
> FragmentShader: chiclet.frag: comiple error
> ShaderProgram: null vertex program
> Segmentation fault
> 
> 
> .. which look very similar to the Qt errors I have:
> QOpenGLShader::compile(Vertex): failed
> Problematic Vertex shader source code ***
> attribute mediump vec4 vertexCoord;
> attribute mediump vec4 vertexColor;
> uniform mediump mat4 matrix;
> uniform mediump float opacity;
> varying lowp vec4 color;
> void main() {
>     gl_Position = matrix * vertexCoord;
>     color = vertexColor * opacity;
> }
> 
> 
> 
> Can anyone confirm or contradict* this?
> 
> *can you build a image bases on the PATCHv4, and any of viv_samples (which
> use es2.0) on the screen?
> 
> 
> 
> 3. It's not because of former "highp"-error (I replaced all 'highp' within
> the Qt code with 'mediump')
> 
> 
> 
> 
> ... The next thing I'll do is build without PATCHv4 ... as some patches have
> already gone in (e.g. kernel) it might be that it's not about PATHv4, but
> rather about the patches already in.
>   ... I'll give a update tomorrow.


...I found it...this is...annoying :)

The way to solve a "broken build"* is to deploy: usr/lib/libGLSLC.so
 ...libglslc-mx6-1.1.0-r5.0.imx6qsabrelite.rpm does get created, but nobody 
depends on it (=> he is not installing it)
 ... why? because** no other lib links against it(?***)

So the solution (or rather workaround****) is to manually add a dependency 
somehow?... I guess the libGLESv2-package should depend on libGLSLC-package or 
something?


*"broken build" == meta-fsl-arm HEAD + [PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade


**this is the fist reason I'm annoyed .. why would you not link against it if 
you obviously going to need a GLSL-compiler?.. or not?
  ... the second reason is that their isn't even the a tiny little error-
message pointing me in the right direction...


*** Is how the packaging works?.. does it check what missing libraries-links a 
package has and creates rpm-dependencies out of that...?


****I think this is a error in the GPU-driver and should be fixed upstream 
eventually






> 
> 
> 
> Greets
> Thomas