Bug 24471 - Rendering Artefacts in Nexuiz
Summary: Rendering Artefacts in Nexuiz
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ian Romanick
QA Contact:
Keywords: NEEDINFO, regression
Depends on:
Reported: 2009-10-12 03:07 UTC by Tobias Hain
Modified: 2010-04-18 13:00 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Tobias Hain 2009-10-12 03:07:35 UTC
distribution: Kubuntu 9.10
platform : x86 + x86_64
chipset: GM965

Intel 2009Q3 graphics package:
X-Server : 1.6.4 (xserver-xorg-core 2:1.6.4-2ubuntu1)
intel 2D : 2.9.0 (xserver-xorg-video-intel 2:1.6.4-2ubuntu1)
Mesa     : 7.6 (libgl1-mesa-dri 7.6.0-1ubuntu2)
libdrm   : 2.4.14 (libdrm-intel1 2.4.14-1ubuntu1) 
kernel   : 2.6.31 (linux

Textures, Characters, Weapons all missing in Nexuiz 2.5.1 and 2.5.2. Only a fraction of the actual szene is rendered - immediately recognizable even without provided screenshot.

press shift + Esc for commandline
timedemo demos/demo1

Mesa 7.5 works flawless (same x-server, intel2d, libdrm, kernel). And Mesa git always had rendering artefacts, after branching off Mesa 7.6 beta/rc they still existed. I thought maybe some patches from 7.5 weren't applied yet. However now that Mesa 7.6 is final, I wanted to report this bug.

I don't play that game and I don't want to. However I use it to trace mesa regressions similar to what Eric did some time ago:

Does it make sense in addition to performing OpenGL conformance tests to install a testbed of a couple of games/3D apps at intel and include for each quarter release of intel drivers and three chipset archs (i8xx, i9xx, X3100/X4500) a matrix of basic test results?

I chose Nexuiz as one of my regression observing tools, since it's open source and if one really wanted, could debug it.
Comment 1 Gordon Jin 2009-10-12 23:23:58 UTC
We did test some 3d games/apps in release testing: http://intellinuxgraphics.org/results/2009-09-28__0/result.htm
But I didn't add Nexuiz as in my impression it's never playable (too slow).

As for this bug, is it the same as bug#22743?
Comment 2 Tobias Hain 2009-10-13 01:06:19 UTC
Yes, seems to be a dup.

Thanks for including some sanity game/application OpenGL tests in your release cycle! That's really helpful!

*** This bug has been marked as a duplicate of bug 22743 ***
Comment 3 Forest Hale 2009-10-13 03:04:37 UTC
Nexuiz ought to be playable on this chipset with appropriate settings in the Options - Effects menu, for example the Low settings should be playable.

I do not have any Intel GMA chipset machines to test with here, but have personally witnessed it being played on Low settings on Intel GMA chipsets older than i965 in Windows so I am certain the hardware is capable, I do not know how DRI performance compares.

As author of the DarkPlaces engine which powers Nexuiz I am very interested in use of Nexuiz as a conformance test, it has unusual OpenGL usage patterns such as mixing VBO and non-VBO rendering features on a per-array basis, it makes heavy use of element array buffer offsets, and it uses 100% GLSL by default, but scales all the way back to OpenGL 1.1 feature sets.

A couple features of interest for testing are demo playback and savegames (also the ability to freeze game time with the slowmo 0 command), so particularly rare but consistent bugs can be reproduced with different combinations of rendering features enabled, every OpenGL extension can be individually disabled on commandline (see GL_CheckExtension function calls in vid_shared.c to find the disable options).

Feel free to email me with any questions about Nexuiz rendering behavior or other topics related to it.
Comment 4 Tobias Hain 2009-10-18 06:37:02 UTC
Although the observed artecfacts such as missing enemies, walls and weapons are the same as in #22743. And even some of the walkarounds proposed over there such as disabling Vertex Buffer Objects fix the problem, it turns out this bug here is unrelated and NOT a duplicate.

The current status on X3100 with the latest Nexuiz SVN build 9337 (which in fact includes fixes for #22743) still suffers from the artefacts as depicted in first posting here.

We have applied a couple of options to the Nexuiz darplaces rendering engine to trigger certain rendering paths with the following outcome. One at a time:

+gl_mesh_drawrangeelements 0

no bug:
+gl_mesh_testmanualfeeding 1
+gl_mesh_testarrayelement 1

The bug shows up in the default VBO settings "Vertices some Tris (compatible)". But is NOT present when selecting VBO [off|vertices].


My testing sheet reveals this bug was not present in mesa 7.5. Will bisecting work or will it be very cumbersome because one has to go back to older libdrm as well as kernel drm modules?
Comment 5 Forest Hale 2009-10-18 07:34:19 UTC
Does +gl_mesh_prefer_short_elements 0 have any effect on the behavior of the modes that use triangles (not just vertices)?

It is worth noting that -nocva may be redundant, as the default behavior is to not use cva even if the extension is enabled (+gl_lockarrays 1 will enable use of cva).

It is also worth noting that I disabled use of VBO with gl_mesh_testarrayelement due to an assert failure mentioned in bug #22743 (where the glArrayElement implementation was asserting that ctx not have any mapped vbos) - so it is effectively the same as the None setting when gl_mesh_testarrayelement is on, I can restore use of VBO with glArrayElement if this is desired for testing.

Be sure to delete ~/.nexuiz/data/config.cfg between tests, or mark it read-only so it remains at defaults, some of these settings are normally saved.
Comment 6 Tobias Hain 2009-10-21 04:36:37 UTC
. deleted ~/.nexuiz/data/config.cfg
. upgraded Nexuiz 2.5.2 with darkplaces engine svn r9371
. repeated all tests of comment #4 while making config.cfg readonly after first Nexuiz launch and verfied it didn't alter

Basically I'm running default program settings on everything including VBO settings "Vertices some Tris (compatible)".

Observed behavior is exactly as reported in comment #4. Running with "+gl_mesh_prefer_short_elements 0" results in the artefacts that this thread is about. Actually no visible difference to not using this option.
Comment 7 Adam Williamson 2009-11-26 09:25:11 UTC
We have a report of this issue in Fedora here:

Comment 8 Eric Anholt 2010-01-30 15:48:59 UTC
No, you never have to go back to older libdrm or kernel modules (unless the bug you're hunting for is in those, of course, in which case you end up having to drag Mesa and 2D back as well).

I just tested nexuiz 2.5.2 starting the second single player option with default settings on Mesa master, and everything looks OK.  Can you confirm and close if so?
Comment 9 Gordon Jin 2010-04-12 00:58:10 UTC
Closing as lacking of response. Please reopen when you could respond.
Comment 10 Tobias Hain 2010-04-18 13:00:10 UTC
WORKSFORME: Didn't have time to bisect. Seems to be resolved in later releases such as this one:

distribution: Kubuntu 10.04 beta
platform : x86 + x86_64
chipset: GM965

Intel 2009Q4 graphics package:
X-Server : 1.7.6 (xserver-xorg-core 1.7.6-2ubuntu3)
intel 2D : 2.9.1 (xserver-xorg-video-intel 2.9.1-3ubuntu4)
Mesa     : 7.7.1 (libgl1-mesa-dri 7.7.1-1ubuntu2)
libdrm   : 2.4.18 (libdrm-intel1 2.4.18-1ubuntu3) 
kernel   : 2.6.32 (linux 2.6.32-21.32 including 2.6.33 drm backport)

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.