Bug 93048

Summary: [CTS regression] mesa af2723 breaks GL Conformance for debug extension
Product: Mesa Reporter: Mark Janes <mark.a.janes>
Component: Drivers/DRI/i965Assignee: Emil Velikov <emil.l.velikov>
Status: RESOLVED FIXED QA Contact: Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity: normal    
Priority: medium CC: idr, kenneth, mark.a.janes
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 93185    
Attachments: cts debug output

Description Mark Janes 2015-11-20 16:41:45 UTC
The following test regressed this morning:

es2-cts.gtf.gl2extensiontests.debug.debug


Regressed by: af272368547600e1db87d4dd5d718e41ea9db6c0

Author:     Emil Velikov <emil.l.velikov@gmail.com>
AuthorDate: Thu Nov 5 20:22:25 2015 +0000
Commit:     Emil Velikov <emil.l.velikov@gmail.com>
CommitDate: Fri Nov 20 11:14:05 2015 +0000

    mesa: use the correct string for the ES GL_KHR_debug functions
    
    As defined in the spec
    
        when implemented in an OpenGL ES context, all entry points defined
        by this extension must have a "KHR" suffix.
    
    Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>



Standard Output

/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'..
#+ Could not query GL_DEBUG_CALLBACK_FUNCTION
#+ Could not query GL_DEBUG_CALLBACK_USER_PARAM
#+ Initial value for GL_DEBUG_GROUP_STACK_DEPTH is 0 but it should be 1
#+ GL_DEBUG_SEVERITY_NOTIFICATION should be initially enabled
#+ Query for GL_DEBUG_CALLBACK_FUNCTION does not work
#+ Query for GL_DEBUG_CALLBACK_USER_PARAM does not work
#+ Could not replace callback
#+ Unexpected error with glDebugMessageInsert
#+ Callback didn't get expected data
<snip>
#+ Pop group message didn't have expected data
#+ Unexpected glPushDebugGroup error while testing stack limits
#+ Query for GL_DEBUG_STACK_DEPTH didn't produce expected results 63 64

Standard Error

Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
Mesa: User error: GL_INVALID_OPERATION in unsupported function called (unsupported extension or deprecated function?)
Mesa: User error: GL_INVALID_ENUM in bad values passed to glDebugMessageInsertKHR(source=0x8246, type=0x824c, severity=0x9146)
Mesa: User error: GL_INVALID_ENUM in bad values passed to glDebugMessageInsertKHR(source=0x8246, type=0x824c, severity=0x9147)
<snip>
Mesa: User error: GL_INVALID_VALUE in glDebugMessageInsertKHR(length=4096, which is not less than GL_MAX_DEBUG_MESSAGE_LENGTH=4096)
Mesa: User error: GL_INVALID_VALUE in glDebugMessageInsertKHR(length=4096, which is not less than GL_MAX_DEBUG_MESSAGE_LENGTH=4096)
Mesa: User error: GL_INVALID_ENUM in bad values passed to glDebugMessageControlKHR(source=0x0, type=0x1100, severity=0x1100)
Mesa: User error: GL_INVALID_ENUM in bad values passed to glDebugMessageControlKHR(source=0x1100, type=0x0, severity=0x1100)
Mesa: User error: GL_INVALID_ENUM in bad values passed to glDebugMessageControlKHR(source=0x1100, type=0x1100, severity=0x0)
Mesa: User error: GL_INVALID_OPERATION in glDebugMessageControlKHR(When passing an array of ids, severity must be GL_DONT_CARE, and source and type must not be GL_DONT_CARE.
Mesa: User error: GL_INVALID_OPERATION in glDebugMessageControlKHR(When passing an array of ids, severity must be GL_DONT_CARE, and source and type must not be GL_DONT_CARE.
Mesa: User error: GL_INVALID_OPERATION in glDebugMessageControlKHR(When passing an array of ids, severity must be GL_DONT_CARE, and source and type must not be GL_DONT_CARE.
Mesa: User error: GL_INVALID_VALUE in glDebugMessageControlKHR(count=-1 : count must not be negative)
Mesa: User error: GL_INVALID_ENUM in bad value passed to glPushDebugGroupKHR(source=0x8246)
Mesa: User error: GL_INVALID_ENUM in bad value passed to glPushDebugGroupKHR(source=0x8248)
Mesa: User error: GL_INVALID_ENUM in bad value passed to glPushDebugGroupKHR(source=0x8247)
Mesa: User error: GL_INVALID_ENUM in bad value passed to glPushDebugGroupKHR(source=0x824b)
Mesa: User error: GL_INVALID_VALUE in glPushDebugGroupKHR(length=4096, which is not less than GL_MAX_DEBUG_MESSAGE_LENGTH=4096)
Mesa: User error: GL_INVALID_VALUE in glPushDebugGroupKHR(length=4096, which is not less than GL_MAX_DEBUG_MESSAGE_LENGTH=4096)
Mesa: User error: GL_STACK_OVERFLOW in glPushDebugGroupKHR
Mesa: User error: GL_STACK_OVERFLOW in glPushDebugGroupKHR
glcts: /mnt/space/jenkins/jobs/Leeroy/workspace@3/repos/mesa/src/mesa/main/errors.c:609: debug_log_message: Assertion `len >= 0 && len < 4096' failed.
Comment 1 Mark Janes 2015-11-20 17:41:50 UTC
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.
Comment 2 Emil Velikov 2015-11-20 18:59:13 UTC
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.
Comment 3 Emil Velikov 2015-11-20 19:10:32 UTC
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.
Comment 4 Mark Janes 2015-11-20 19:17:14 UTC
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
Comment 5 Emil Velikov 2015-11-25 17:57:10 UTC
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
Comment 6 Emil Velikov 2015-11-26 00:37:28 UTC
With Rev2 the test now passes. Currently ongoing a spin on the Jenkins setup.

http://patchwork.freedesktop.org/series/1052/
Comment 7 Emil Velikov 2015-12-03 19:27:14 UTC
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.
Comment 8 Mark Janes 2015-12-03 19:48:56 UTC
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.
Comment 9 Mark Janes 2015-12-04 21:29:44 UTC
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%)
Comment 10 Emil Velikov 2015-12-05 11:28:42 UTC
(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.
Comment 11 Emil Velikov 2015-12-05 11:30:32 UTC
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 ?
Comment 12 Mark Janes 2015-12-07 18:07:25 UTC
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.
Comment 13 Mark Janes 2015-12-07 22:10:52 UTC
Created attachment 120398 [details]
cts debug output
Comment 14 Emil Velikov 2015-12-18 00:12:40 UTC
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.
Comment 15 Mark Janes 2016-01-22 16:35:43 UTC
fixed by 72fda2b710d864d23aec1e8f959147d05c5ff3f3

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.