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?

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 ***

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.

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:

artefacts:
----------
-notexturenonpoweroftwo
-nocva
+gl_mesh_drawrangeelements 0
-nofragmentshader

no bug:
------
-safe
-novbo
+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?

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.

. 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.

We have a report of this issue in Fedora here:

https://bugzilla.redhat.com/show_bug.cgi?id=533759

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?

Closing as lacking of response. Please reopen when you could respond.

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)