| Summary: | Framebuffers not working as intended | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Edwin Moehlheihrich <moehlheinrich> |
| Component: | Drivers/DRI/i965 | Assignee: | Eric Anholt <eric> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | Keywords: | NEEDINFO |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
test case
testcase with pass/deviation output to stdout |
||
Well the behavior changed while i switched from an external texture to a smaller testcase-conform inline-texture. With the external texture asd3.bmp after rendering in hardware was all black, with the new smaller texture asd3.bmp has the same colors as the input texture. (which is still wrong behavior, the correct result as rendered in software would be the original texture with some added blue). Works fine for me on Mesa 7.5, 7.6, and master on GM45. I'm going to need more details. What hardware? What version of Mesa? Also, could you make this into a piglit test (http://people.freedesktop.org/~nh/piglit/) so that it can report pass/fail and I can tell when behavior deviates from expected? Created attachment 31258 [details]
testcase with pass/deviation output to stdout
The testcase outputs a deviation in the third and fourth extracted texture if run in hardware(thinkpad t500's gma 4500) and mesa git (since 3 weeks or so ago).
Still couldn't reproduce it even with your testcase before my change: libGL: OpenDriver: trying /home/anholt/src/mesa-7.7/lib/i965_dri.so first bitmap passed second bitmap passed third bitmap passed fourth bitmap passed But my guess is that it's fixed by this commit in mesa 7.7 branch: commit 539a14a1dd5a0d277b193d9cd2d06423ed98dc8a Author: Eric Anholt <eric@anholt.net> Date: Wed Dec 9 11:36:45 2009 -0800 intel: Flush the render/texture cache when finishing render to texture. Back when we were flushing the entire batch at BindFramebuffer, the kernel would notice the domain transition when someone went to texture from it and flush for us. We no longer do the batch flushing every time, so we get to do aggressive flushing until we move batchbuffer handling to libdrm. Fixes piglit fbo-flushing. Bug #25377. No noticeable performance loss on cairo-gl (so this is better than batch flushing). Please reopen if the problem continues with that fix. |
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.
Created attachment 31007 [details] test case Under certain circumstances, objects aren't rendered into the bound framebuffer. Everything works fine with the software rasterizer. Compile with: gcc -g -std=c99 main.c -o testcase -lGL -lGLEW -lSDL Run with: LIBGL_ALWAYS_SOFTWARE=1 ./testcase # expected behavior ./testcase # actual behavior Compare asd[123].bmp