Bug 106881

Summary:	glUniform4fv does not work
Product:	Mesa	Reporter:	xinghua <xinghua.cao>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED DUPLICATE	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	yang.gu, yunchao.he
Version:	git
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	attachment-8101-0.html

Description xinghua 2018-06-11 10:57:47 UTC

Steps:
1. Download chrome and install it on your Ubuntu, https://www.google.com/chrome/?platform=linux&extra=devchannel;
2. Open chrome on command line, "google-chrome-unstable --use-gl=egl --user-data-dir=./caghe_local_debug";(If cannot reproduce this issue again, please rm caghe_local_debug in current directory, chrome has cache mechanism)
3. Open the link, https://www.khronos.org/registry/webgl/sdk/tests/conformance/programs/program-test.html?webglVersion=2&quiet=0
4. one case fails.

Notes:
1. This case was reproduced by our QA team, but I could only reproduce it on mesa git master, could not reproduce on system driver(Ubuntu 17.10). May our latest code introduced some regression?
2. This case only tests "Program's uniforms should be cleared when re-linking program successfully". You can check https://www.khronos.org/registry/OpenGL-Refpages/es3.0/ , there is more information about "glUniform", Quate a number of sentences,
 "All active uniform variables defined in a program object are initialized to 0 when the program object is linked successfully. They retain the values assigned to them by a call to glUniform until the next successful link operation occurs on the program object, when they are once again initialized to 0."
3.  This case code is very simple,
    Shader code:
    VS:
    attribute highp vec4 webgl_613687ebc2d92685;
    void main(){
        (gl_Position = vec4(0.0, 0.0, 0.0, 0.0));
        (gl_Position = webgl_613687ebc2d92685);
    }
    FS:
    uniform mediump vec4 webgl_8463902250c1a4db;
    void main(){
    (gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0));
    (gl_FragColor = webgl_8463902250c1a4db);
    }
    API code: 
    var prg = wtu.setupProgram(gl, ["vshader", "fshader-settable"], ["a_position"]);  //This statemenet includes shader compile, program link and use program APIs
    var colorLoc = gl.getUniformLocation(prg, "u_color");
    gl.uniform4f(colorLoc, 1, 0, 0, 1);
    wtu.clearAndDrawUnitQuad(gl);
    wtu.checkCanvas(gl, [255, 0, 0, 255], "should be red");
    gl.linkProgram(prg);
    // Program's uniforms should be cleared at this point without calling useProgram
    wtu.clearAndDrawUnitQuad(gl, [0, 255, 0, 255]);
    wtu.checkCanvas(gl, [0, 0, 0, 0], "should be tranparent black");   // Error happened here, [0, 0, 0, 0] color was expected, but got [255, 0, 0, 255], it seemed that uniform in FS shader was not modified.
    wtu.glErrorShouldBe(gl, gl.NO_ERROR, "should be no errors");
    According spec, when calling "gl.linkProgram(prg)", all uniforms will be again initialized to 0.
4. Because these shaders were not changed, linkProgram had no effect here for some implementations. What is the behavior for this situation?
   In order to avoid depending on implementations to again initialize uniforms to 0, chrome does not call glLinkProgram again for "gl.linkProgram(prg)" statement, it explicitly calls "glUniform4fv" to clear this uniform, but the case still fail on mesa, seems that glUniform4fv does not work.

Comment 1 Lionel Landwerlin 2018-06-11 11:09:46 UTC

This test passes on Firefox, could this be a chrome bug?

Comment 2 Lionel Landwerlin 2018-06-11 11:10:44 UTC

If you can reproduce this using GL/GLES directly, we could look into it.
But this sounds more like a browser issue.

Comment 3 Tapani Pälli 2018-06-12 05:28:59 UTC

IMO this looks like a shader cache issue that got fixed by following commit. Please pull the latest Mesa and test again.

--- 8< ---
commit e266b320590ebbeadf7c98b0b493d89886534ccb
Author: Jordan Justen <jordan.l.justen@intel.com>
Date:   Wed Jun 6 01:57:15 2018 -0700

    mesa/program_binary: add implicit UseProgram after successful ProgramBinary
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106810
    Fixes: b4c37ce2140 "i965: Add ARB_get_program_binary support using nir_serialization"
    Ref: 3fe8d04a6d6 "mesa: don't always set _NEW_PROGRAM when linking"
    Ref: c505d6d8522 "mesa: use gl_program for CurrentProgram rather than gl_shader_program"
    Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
    Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
    Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Comment 4 xinghua 2018-06-12 06:25:03 UTC

(In reply to Tapani Pälli from comment #3)
> IMO this looks like a shader cache issue that got fixed by following commit.
> Please pull the latest Mesa and test again.
> 
> --- 8< ---
> commit e266b320590ebbeadf7c98b0b493d89886534ccb
> Author: Jordan Justen <jordan.l.justen@intel.com>
> Date:   Wed Jun 6 01:57:15 2018 -0700
> 
>     mesa/program_binary: add implicit UseProgram after successful
> ProgramBinary
>     
>     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106810
>     Fixes: b4c37ce2140 "i965: Add ARB_get_program_binary support using
> nir_serialization"
>     Ref: 3fe8d04a6d6 "mesa: don't always set _NEW_PROGRAM when linking"
>     Ref: c505d6d8522 "mesa: use gl_program for CurrentProgram rather than
> gl_shader_program"
>     Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
>     Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
>     Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>

Hi, Tapani, Thank you for your reply. I had tested this case again, the patch could resolve this issue.
Could you give our more information about the root-cause in mesa, thank you.

Comment 5 Tapani Pälli 2018-06-12 06:36:45 UTC

(In reply to xinghua from comment #4)
> (In reply to Tapani Pälli from comment #3)
> > IMO this looks like a shader cache issue that got fixed by following commit.
> > Please pull the latest Mesa and test again.
> > 
> > --- 8< ---
> > commit e266b320590ebbeadf7c98b0b493d89886534ccb
> > Author: Jordan Justen <jordan.l.justen@intel.com>
> > Date:   Wed Jun 6 01:57:15 2018 -0700
> > 
> >     mesa/program_binary: add implicit UseProgram after successful
> > ProgramBinary
> >     
> >     Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106810
> >     Fixes: b4c37ce2140 "i965: Add ARB_get_program_binary support using
> > nir_serialization"
> >     Ref: 3fe8d04a6d6 "mesa: don't always set _NEW_PROGRAM when linking"
> >     Ref: c505d6d8522 "mesa: use gl_program for CurrentProgram rather than
> > gl_shader_program"
> >     Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
> >     Reviewed-by: Plamena Manolova <plamena.manolova@intel.com>
> >     Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
> 
> Hi, Tapani, Thank you for your reply. I had tested this case again, the
> patch could resolve this issue.
> Could you give our more information about the root-cause in mesa, thank you.

Chrome browser implements a shader program cache using ARB_get_program_binary, we had a bug in program binary code. Loading new binary was not binding the shaders of the binary in to use (so old ones were still used). This is now fixed.

Comment 6 Tapani Pälli 2018-06-12 06:37:05 UTC

by commit e266b320590ebbeadf7c98b0b493d89886534ccb

Comment 7 Tapani Pälli 2018-10-24 05:12:23 UTC

(was duplicate)

*** This bug has been marked as a duplicate of bug 106810 ***

Comment 8 Yang Gu 2018-10-24 05:12:38 UTC

Created attachment 142167 [details]
attachment-8101-0.html

Yang is OOO from Oct 15 to 26 for vacation and TPAC 2018. Please expect slow response.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.