Note that this hardware does not support occlusion queries, so ARB_occlusion_query2 should not even be enabled.

Version of Piglit being used:
http://cgit.freedesktop.org/piglit/commit/?id=1f39e07d44f7d78557d69c505168afb8eab913c6

Here's the failure output from the test:
06/13 08:38:48.586 DEBUG|        base_utils:0239| [stdout] + Running test [spec/ARB_occlusion_query2/api] of expected runtime 0.0 sec: [bin/arb_occlusion_query2-api -fbo -auto]
06/13 08:38:48.691 DEBUG|        base_utils:0239| [stderr] GL_CURRENT_QUERY(GL_SAMPLES_PASSED) returned 0 while GL_SAMPLES_PASSED active
06/13 08:38:48.692 DEBUG|        base_utils:0239| [stdout] Unexpected GL error: GL_INVALID_OPERATION 0x502
06/13 08:38:48.694 DEBUG|        base_utils:0239| [stdout] (Error at ../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:119)
06/13 08:38:48.696 DEBUG|        base_utils:0239| [stdout] Unexpected GL error: GL_INVALID_OPERATION 0x502
06/13 08:38:48.698 DEBUG|        base_utils:0239| [stdout] (Error at ../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:128)
06/13 08:38:48.699 DEBUG|        base_utils:0239| [stdout] Unexpected GL error: GL_INVALID_OPERATION 0x502
06/13 08:38:48.703 DEBUG|        base_utils:0239| [stdout] (Error at ../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:63)
06/13 08:38:48.704 DEBUG|        base_utils:0239| [stdout] Unexpected GL error: GL_NO_ERROR 0x0
06/13 08:38:48.707 DEBUG|        base_utils:0239| [stdout] (Error at ../../../../../../piglit-2014.07.23/tests/spec/arb_occlusion_query2/api.c:66)
06/13 08:38:48.708 DEBUG|        base_utils:0239| [stdout] Expected GL error: GL_INVALID_OPERATION 0x502
06/13 08:38:48.709 DEBUG|        base_utils:0239| [stdout] PIGLIT: {"result": "fail" }
06/13 08:38:48.711 DEBUG|        base_utils:0239| [stdout] + fail :: spec/ARB_occlusion_query2/api

The following two piglit commits are probably necessary:

commit 49e326474d5ed487d04ff6bef1efae376e4a2492
Author: Eduardo Lima Mitev <elima@igalia.com>
Date:   Mon Feb 16 11:10:30 2015 +0100

    arb_occlusion_query2: Checks that query obj passed to glBeginQuery matches target
    
    From the OpenGL 3.3 spec, section "2.14. ASYNCHRONOUS QUERIES", page 94:
    
        "[...] if id is the name of an existing query object whose type does not
         match target, [...] the error INVALID_OPERATION is generated."
    
    Similar wording exists in the OpenGL ES 3.0.0 spec, section "2.13.
    ASYNCHRONOUS QUERIES", page 82.
    
    This patch adds a check for this situation.
    
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

commit 0eff6819639d8c84c98f8fa0bd0b254a69aead60
Author: Eduardo Lima Mitev <elima@igalia.com>
Date:   Sat Feb 14 13:29:52 2015 +0100

    arb_occlusion_query2: expect an error when target mismatch in glBeginQuery()
    
    From the OpenGL 3.3 spec, section "2.14. ASYNCHRONOUS QUERIES", page 94:
    
        "[...] if id is the name of an existing query object whose type does not
         match target, [...] the error INVALID_OPERATION is generated."
    
    Similar wording exists in the OpenGL ES 3.0.0 spec, section "2.13.
    ASYNCHRONOUS QUERIES", page 82.
    
    Hence, trying to call BeginQuery on a query object which has already
    been bound to a different target should return GL_INVALID_OPERATION.
    
    Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

Brian Wilson said:
> It fails in the following Mesa commit:
>   c2a0600 i965: Don't set NirOptions for stages that will use the vec4 backend [May 2015-ish]

Incorrect. The actual Mesa tree that Brian's team is validating is commit c1a0600 plus many patches. I've the pushed the full tree, patches included, to 

  git://github.com/chadversary/mesa refs/tags/chadv/cros-gerrit-262788-patched

Also, the Piglit being tested is the following commit plus a few incosequential patches.

  commit 4069bec62a8a99c44573395ea1597694eeee760f
  Author:     Marek Olšák <marek.olsak@amd.com>
  AuthorDate: Thu Apr 30 14:11:26 2015 +0200
  Commit:     Marek Olšák <marek.olsak@amd.com>
  CommitDate: Thu Apr 30 22:41:02 2015 +0200
  Subject: framework: use the correct executable for GLES parser tests

Building that Piglit against recent Mesa, however, produces an error at linktime. The fix requires backporting Piglit commit 845ba0e4dfb9372307f5d3032abdd0860e76731b.

I was able to reproduce this bug using the old versions of piglit and mesa

  piglit:  1f39e07d44f7d78557d69c505168afb8eab913c6
  mesa:    c2a0600

After updating piglit to the latest revision, the test skips.  This
seems to be the correct behavior, since g33 does not support occlusion
query.

Based on this information, it seems safe to conclude that this bug is
the result of running an obsolete/buggy version of piglit, and does
not indicate a regression in mesa.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/666.