Summary: | glScissor doesn't work with Mesa 9.2 on Intel GPUs | ||
---|---|---|---|
Product: | Mesa | Reporter: | Branimir Karadzic <bk> |
Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
Status: | RESOLVED NOTOURBUG | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | major | ||
Priority: | medium | CC: | lemody |
Version: | 9.2 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Branimir Karadzic
2013-12-11 06:08:20 UTC
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.