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

[Otavio Salvador]

On Wed, Feb 27, 2013 at 12:11 PM, Thomas Senyk
<thomas.senyk at pelagicore.com> wrote:
> 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 :)

Great you found it. I am working in a v5. I will send it later today/tomorrow.

> 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?

Yes; it is.

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

Good will fix it for v5.

> **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...

Welcome :-) It is hard to fix problems when we do not have access to
source code to look at ;-)

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

Yes; it checkes the symbols used and put a rdepends on the packages
providing those. The problem here is that the library most probably is
load at runtime (dlopen or so) and thus breaking this.

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

I agree.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br