Bug 24955 - Framebuffers not working as intended
Summary: Framebuffers not working as intended
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Eric Anholt
QA Contact:
Keywords: NEEDINFO
Depends on:
Reported: 2009-11-06 02:23 UTC by Edwin Moehlheihrich
Modified: 2009-12-10 14:49 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

test case (4.96 KB, application/octet-stream)
2009-11-06 02:23 UTC, Edwin Moehlheihrich
testcase with pass/deviation output to stdout (6.85 KB, text/x-csrc)
2009-11-17 05:33 UTC, Edwin Moehlheihrich

Description Edwin Moehlheihrich 2009-11-06 02:23:33 UTC
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
Comment 1 Edwin Moehlheihrich 2009-11-06 04:18:54 UTC
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).
Comment 2 Eric Anholt 2009-11-10 16:21:08 UTC
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?
Comment 3 Edwin Moehlheihrich 2009-11-17 05:33:26 UTC
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).
Comment 4 Eric Anholt 2009-12-10 14:49:39 UTC
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.