[Bug 87364] New: Flickering objects in Goat Simulator

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Dec 16 07:44:05 PST 2014


https://bugs.freedesktop.org/show_bug.cgi?id=87364

            Bug ID: 87364
           Summary: Flickering objects in Goat Simulator
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/i965
          Assignee: idr at freedesktop.org
          Reporter: neil at linux.intel.com
        QA Contact: intel-3d-bugs at lists.freedesktop.org

I tried running Goat Simulator (a Steam game based on the Unreal 3 engine) on
my Haswell laptop. It mostly works except some of the objects flicker where
they alternately appear in one frame and disappear in the next. For example,
right at the beginning of the game the fence panel near the goat does this a
lot and also the columns supporting the roof of the nearby petrol station.

The game seems to use a lot of occlusion queries with bounding boxes to
determine whether to render objects. It looks like it renders the initial frame
normally and then when the frame is complete it disables the colour mask and
depth writing, sets the depth func to GL_LEQUAL and renders a bounding box for
each object with an occlusion query. I guess it's trying to compare the
bounding boxes with the depth buffer values from the last rendered frame. The
depth buffer has the complete frame so the objects inside each bounding box
will also be there. At the start of the next frame it reads all of the query
objects and presumably uses this to determine whether to render each object.

I'm pretty sure the occlusion queries are the problem because if I hack Mesa to
always return 1000 for the samples passed then the flickering stops.

Interestingly the objects that flicker seem to all be cuboid shapes. Perhaps
this causes problems because in that case the bounding box would be exactly the
same shape as the object. However the depth function is set to GL_LEQUAL so
assuming it manages to generate exactly the same depth values for the fragments
then that should be ok. I'm not sure if the problem is just that the game is
relying on depth value repeatability that the GPU can't provide or there is
some bug which means Mesa is messing up the values slightly.

I tried making a simple test where I render a scene normally with a matrix in a
vertex shader and then render the same geometry again but transform it on the
CPU instead of the shader and it does seem to get the same depth values.

I have an apitrace but it is 552MB so I won't attach it here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20141216/721d8d82/attachment.html>


More information about the intel-3d-bugs mailing list