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.
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
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.