point sprite + three vec4 varyings + SGX540 = bad rendering ?

This topic contains 6 replies, has 2 voices, and was last updated by  Joe Davis 4 years, 4 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #31307

    Koodler
    Member

    I had a very strange problem of using point sprite and three vec4 varyings on SGX540. The shader should draw a white point but I got a yellow point on
    SGX540. On desktop GPUs or other mobile GPUs, a white point is drawn as expected. The test shaders, listed at the bottom, are super simple.

    The problem is apparently caused by the 3rd varying (i.e. param3). If you play with the shader, you can easily find out that param1 and param2 are always
    good, but param3 is not (and is always 0). If you add a 4th vec4 varying, the value of param3 will change. The max number of verying vectors on SGX450
    is 8, so I should have more than enough to run this shader.

    This bug is killing me today. The original shader is 100x more complex than the test shader. I finally simplified it to the WTH moment…
    Any help or comment is appreciated. I tested the shader on Samsung Galaxy Tab 2.

    Thanks.

    Vertex shader:

    uniform mat4 mvp;
    attribute vec4 vert_pos;
    varying vec4 param1;
    varying vec4 param2;
    varying vec4 param3;
    void main()
    {
    param1 = vec4(1,0,0,1);
    param2 = vec4(0,1,0,0);
    param3 = vec4(0,0,1,0);
    gl_PointSize = 32.0;
    gl_Position = mvp*vert_pos;
    }

    Fragment shader:

    precision mediump float;
    varying vec4 param1;
    varying vec4 param2;
    varying vec4 param3;
    void main()
    {
    gl_FragColor = param1 + param2 + param3;
    }

    #37462

    Joe Davis
    Member

    Hi,

    I’ve not seen a problem like this before. Can you share the graphics driver version of the device with us? This can be queried with ‘adb shell cat /proc/pvr/version’.

    Also, have you tried explicitly setting precision qualifiers for your varyings? i.e.:

    mediump varying vec4 param1;
    mediump varying vec4 param2;
    mediump varying vec4 param3;

    Thanks,
    Joe

    #37463

    Koodler
    Member

    Hi Joe,

    Thanks for the reply.

    I checked the precision and the result is still not right.

    Here is the info of the driver:
    Version SGX_DDK_Android sgxddk 19 1.9@2120756 (release) omap4430_android
    System Version String: SGX revision = 1.2.0

    Just in case this makes difference. The shader is executed as a part of a native c++ library.

    Thanks.

    #37464

    Joe Davis
    Member

    Hi,

    Thanks for the information. I’ve filed a bug for our compiler team to investigate.

    Btw, have you tried explicitly setting your vec4() values as floats, e.g.

    param1 = vec4(1.0, 0.0, 0.0, 1.0);

    I’m not sure if this will effect the result, but it’s a simple test to try 🙂

    Thanks,
    Joe

    #37465

    Koodler
    Member

    Hi,

    Ok, I just did a test you suggested. Luckily, it’s not the cause of my problem; otherwise there will be a lot of broken shaders out there 😉

    Could you keep this post updated if you get any feedback from your devs? I would like to know the cause of this problem.

    Thanks a lot.

    #37466

    Joe Davis
    Member

    Yeah – always worth a try though 😉

    Will do.

    #37467

    Joe Davis
    Member

    The driver team have got back to me. From your description, it seems this is a bug was identified a few months ago and has since been fixed in our reference driver. The bug is caused by a broken optimization path that causes varying values to be lost when gl_PointSize is used.

    Unfortunately, there isn’t a shader-level workaround you can do to avoid this bug. The best alternative I can suggest is to screen aligned blended quads. Our SDK ParticleSystem Example source code demonstrates an optimal way of implementing this.

    Thanks,
    Joe

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.