glScissor stopped working correctly in Mesa 9.2 (it only affects Intel driver). It seems that once scissor gets set it can't be disabled, nor changed. It worked on: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL version string: 3.0 Mesa 9.1.7 OpenGL shading language version string: 1.30 Stopped working with: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.1 OpenGL core profile shading language version string: 1.40 OpenGL core profile context flags: (none) OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 9.2.1 OpenGL shading language version string: 1.30 And doesn't work on: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL version string: 3.0 Mesa 10.0.0-devel (git-ff337bc) OpenGL shading language version string: 1.30 Here is some more info about the issue: https://github.com/bkaradzic/bgfx/issues/48 Apitrace was created on SandyBridge, and it replays correctly with the same Mesa 9.2 Nouveau and NVIDIA 319.32 propriatery drivers. Also I tested my code on OpenGL on Windows and OSX (let me know if you need more info about these drivers). I don't have code sample of this problem but you could glretrace attached trace, to see the issue. Also github issue mentioned above has screenshots.
I think you forgot to attach the apitrace - there doesn't seem to be one here or on the linked issue.
It failed to attach (it's 11MB): https://drive.google.com/file/d/0B0LrJeUgazHzNW9FXzR0R2VqZHM/edit?usp=sharing
As pointed out in the linked github discussion, the first bad commit in the Mesa tree is 1d4dbeeaec8490a14dafefa9c647ae48b56ab952 which enables ARB_texture_multisample on Gen6+.
I found actual issue... My code was passing invalid number of samples to glRenderbufferStorageMultisample. SandyBridge returns 4 for GL_MAX_SAMPLES, and my code was erroneously passing 2. Anyhow probably still worth looking into this because it might lead to some other issue.
According to github issue discussion there was a fix to the application. I've also tested with a simple app that renders some objects and toggles scissor on/off with a random scissor area, everything works OK (tested on SNB), I'm resolving this as fixed.
Sorry for confusion, fix on my side is that my lib used MSAA errorneously, even when not requested specified. But the issue in Mesa still exist with MSAA and scissor. Can you add MSAA in your test?
(In reply to comment #6) > Sorry for confusion, fix on my side is that my lib used MSAA errorneously, > even when not requested specified. > > But the issue in Mesa still exist with MSAA and scissor. Can you add MSAA in > your test? I managed to miss that detail, yes I can add MSAA, so is your use case basically fbo blit with MSAA enabled and scissoring that blit?
Actually scissoring needs to be enabled for something that's getting rendered into MSAA FBO, and after that it seems it gets into state where turning off or changing scissor doesn't work always. There is some other condition that re-enables this, but I didn't figure out what.
Also if you can try replaying that attached apitrace (in comment #2).
(In reply to comment #9) > Also if you can try replaying that attached apitrace (in comment #2). will do, thanks, I'll take a look at this
(In reply to comment #9) > Also if you can try replaying that attached apitrace (in comment #2). With the trace I see application calling glScissor with these parameters: glScissor (x=1020, y=498, width=232, height=206) glScissor 0,0 coordinate is the bottom-left corner, so I think the image looks correctly clipped (small box in top right corner)?
so what happens is that skybox + bunny gets clipped and only the UI control part is visible, is this the expected result?
Last night at SteamDevDays I was talking with devs, someone mentioned that it might be related to glBlitFramebuffer. I just tested it on SandyBridge and disabling scissor right before blit fixes it. I also checked specs here https://www.opengl.org/registry/specs/EXT/framebuffer_blit.txt also mentions it's correct: The pixel copy bypasses the fragment pipeline. The only fragment operations which affect the blit are the pixel ownership test and the scissor test. I think it's bug completely on my side, so you can resolve this as not a bug.
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.