[Bug 83215] [SNB+]Ogles3conform ES3-CTS.shaders.struct.uniform.sampler_array_vertex crash

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=83215

Ian Romanick <idr at freedesktop.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #1 from Ian Romanick <idr at freedesktop.org> ---
I didn't know this test ever passed.  Was there ever a bisect?

There was a patch for this on the gles3conform-v5 branch.  Should we just land
it?

commit 4be2eb8bf6402bbe8aa640628464f00f992f53ff
Author: Anuj Phogat <anuj.phogat at gmail.com>
Date:   Fri Aug 8 20:50:45 2014 -0700

    i965: Make type_size()'s handling of samplers on vec4 and FS backends match

    Made following CTS tests to pass:
    ES3-CTS.shaders.struct.uniform.sampler_nested_vertex (crash)
    ES3-CTS.shaders.struct.uniform.sampler_array_vertex (crash)

    This is what Ken said about it:
    I noticed type_size() handles samplers differently between the vec4 and
    FS backends:

    brw_vec4_visitor.cpp:
    ---------------------
       case GLSL_TYPE_SAMPLER:
          /* Samplers take up one slot in UNIFORMS[], but they're baked in
           * at link time.
           */
          return 1;

    brw_fs.cpp:
    -----------
       case GLSL_TYPE_SAMPLER:
          /* Samplers take up no register space, since they're baked in at
           * link time.
           */
          return 0;

    Changing the vec4 backend to "return 0" makes that test pass.  It sure
    doesn't make sense to waste space for samplers.

    But, I've seen similar trouble in the FS backend: it doesn't count them
    in uniforms, but still tries to access arrays as if they took up space.
    The only reason it works out is because we reserve space for another 2 *
    MaxSamplerImageUnits uniforms for texture rectangle rescaling (in the FS
    backend only - texrect scaling is just broken in the vec4 backend, and
    always has been.)

    I think changing it to 0 is the right thing to do, but then we start
    calling virtual_grf_alloc(0) in some places, and that seems bad too.

    I'm not sure how the dynamic sampler stuff from ARB_gpu_shader5 affects
    this, if at all.

    Signed-off-by: Anuj Phogat <anuj.phogat at gmail.com>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20140910/f2d1ba2a/attachment.html>