Bug 93048

Correction:  my bisect finished, and the commit which triggers the regression is:

b8547a50631649bf19fc29cb339bdb3992537607

Author:     Boyan Ding <boyan.j.ding@gmail.com>
AuthorDate: Fri Nov 20 11:11:19 2015 +0000
Commit:     Emil Velikov <emil.l.velikov@gmail.com>
CommitDate: Fri Nov 20 11:14:05 2015 +0000

    mesa: re-enable KHR_debug for ES contexts
    
    With the earlier issues resolved we can expose the extension.
    
    Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
    Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

Pushed with the same series.

Mark are you sure that these are regressions ? The extension wasn't enabled prior so the test should not have been executed then.

Either way - I'm syncing my CTS tree, can you let me know which branch and revision you're using and if there are any other affected tests.

Ian, as mentioned to Mark on IRC - I'll be taking a look tomorrow at this issue. In the meanwhile if things are urgent feel free revert.

We have some patches on top of CTS, to enable GBM and fix up some warnings.

Unfortunately, our branch is on an internal repo due to the restrictions for distributing CTS.

Our patches are on top of
b6d38dcbf5ef7aa09cb4dee0e4830694be2a0173
Author:     Jon Leech <oddhack@sonic.net>
AuthorDate: Wed Sep 30 14:26:21 2015 -0400
Commit:     Jon Leech <oddhack@sonic.net>
CommitDate: Wed Sep 30 14:26:21 2015 -0400

    Merge branch 'bug_14807' into 'master'
    
    Fixed bug #14807. Using DEQP_SUPPORT_OPENGL instead of GTF_API == GTF_GL
    
    See merge request !55

Should have mentioned it before - the initial batch of fixes in on the ML. Some patches need minor work, but overall we're in the right direction.

Still not there though :\


[1] http://lists.freedesktop.org/archives/mesa-dev/2015-November/101092.html

With Rev2 the test now passes. Currently ongoing a spin on the Jenkins setup.

http://patchwork.freedesktop.org/series/1052/

Considering that rev2 fixes the issue on my end and Jenkins did not notice any regressions (comparing to previous run against master) I've pushed the series.

Mark, please re-enable the test again and shout if there are any issues.

I don't disable tests in the CI unless they fail intermittently.  Instead, I instruct the CI to treat the expected failure as a pass.

When you push this commit, it should generate "failures" in the CI for the tests, which passed when the CI expected fail.  You can look at the output in your results.tgz, and should see a message to this effect in the stdout of each test that has been fixed.

Emil: can you explain why the cts test still fails on g33?  
This doesn't seem like the kind of test that would be hardware specific.

g33 wouldn't be in the CI results that you got, because the machine is to old/slow to complete in a reasonable time.  The test failed on a nightly run.

/tmp/build_root/m64/bin/cts/glcts --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.debug.debug
dEQP Core GL-CTS-2.0 (0x0052484b) starting..
  target implementation = 'intel-gbm'

Test case 'ES2-CTS.gtf.GL2ExtensionTests.debug.debug'..
#+ Initial value for GL_DEBUG_GROUP_STACK_DEPTH is 0 but it should be 1
#+ Initial state for GL_DEBUG_OUTPUT is not enabled
  Fail (Fail)

DONE!

Test run totals:
  Passed:        0/1 (0.00%)
  Failed:        1/1 (100.00%)
  Not supported: 0/1 (0.00%)
  Warnings:      0/1 (0.00%)

(In reply to Mark Janes from comment #9)
> Emil: can you explain why the cts test still fails on g33?  
> This doesn't seem like the kind of test that would be hardware specific.
> 
Indeed it's not.

> g33 wouldn't be in the CI results that you got, because the machine is to
> old/slow to complete in a reasonable time.  The test failed on a nightly run.
> 
Can you point me out to a PCI ID, so that I can check which path gets executed on the said platform. I doubt that I'll find such a platform in the wild to do some actual debugging.

> /tmp/build_root/m64/bin/cts/glcts
> --deqp-case=ES2-CTS.gtf.GL2ExtensionTests.debug.debug
> dEQP Core GL-CTS-2.0 (0x0052484b) starting..
>   target implementation = 'intel-gbm'
> 
> Test case 'ES2-CTS.gtf.GL2ExtensionTests.debug.debug'..
> #+ Initial value for GL_DEBUG_GROUP_STACK_DEPTH is 0 but it should be 1
And here comes the strange part... the default (1) stack is allocated via _mesa_lock_debug_state/debug_create, which gets executed by all khr_debug entry points (iirc). Thus I'm wondering how it's possible for this to fail.

> #+ Initial state for GL_DEBUG_OUTPUT is not enabled
>   Fail (Fail)
> 
While this one is even stranger - as we attempt to set DEBUG_OUTPUT (via the dri layer), _mesa_set_debug_state_int gets called, which fails to set the flag only if the _mesa_lock_debug_state/debug_create combo above also fails.

Can you set MESA_DEBUG=1 and LIBGL_DEBUG=verbose and attach (or email) the output.

Hmm the only thing that I can see is the fubar'd handling in _mesa_error(). Namely we have two cases where we return without setting the error state, although those have assert(0) so they would have triggered. Then again you are using a release mesa build aren't you ?

we have assertions enabled in out CI, because the engineers consider assertions to be an important category of failure.

The builds lack symbols and are optimized though.

Created attachment 120398 [details]
cts debug output

Ouch... i915 does not call driContextSetFlags() thus the debug output (and forward compatible) flag is not set and things go pair-shaped. Will send a patch first thing in the morning.

fixed by 72fda2b710d864d23aec1e8f959147d05c5ff3f3