Indeed, this problems happen with Windows q3arena demo only. Ioquake3, and I believe that the latest windows full quake3 binary too, correctly handles the full extensions list.
However I suspect that quake2 and earliy releases of quake3 arena and quake3 arena demo suffer from limitation. The most worrysome thing here is not quake3 by itself, but the thought that other GL apps out there may too truncate the GL extension string. Jose ________________________________________ From: Xavier Chantry [chantry.xav...@gmail.com] Sent: Tuesday, March 16, 2010 19:40 To: Roland Scheidegger Cc: Keith Whitwell; Ian Romanick; Jose Fonseca; mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first. On Tue, Mar 16, 2010 at 7:13 PM, Roland Scheidegger <srol...@vmware.com> wrote: > On 16.03.2010 18:52, Keith Whitwell wrote: >> On Tue, 2010-03-16 at 08:32 -0700, Ian Romanick wrote: >> >>> I'm also a bit surprised that not detecting GL_EXT_compiled_vertex_array >>> has any impact on our Quake3 performance. After all, our CVA >>> implementation doesn't do anything! Looking at the list, it seems more >>> likely that GL_EXT_texture_env_add is the problem. Not having that will >>> cause Quake3 to use additional rendering passes in quite a few cases. >> >> I think if CVA isn't present, it falls back to glVertex() and friends... > Bad... > > I'm not sure though listing that extension first really solves all > problems. There's a quite famous bug when you bring up the information > with the extension string it'll actually segfault. I think though that > got fixed in later versions (though I don't know how, if by just copying > only the first n bytes of the extension string it obviously wouldn't > solve the problem that it doesn't recognize the CVA extension...). And > against this you can't really do anything other than app detection and > cut the string appropriately... > As far as I know, quake 3 code was open sourced 5 years ago. Though it sounds like we are talking about an evil proprietary game doing bad things. And not only it is GPL, but there is also a reference project maintaining that code :) http://ioquake3.org/ Now are we talking about q3 or ioq3 ? If it's q3, why do we care ? If it's ioq3, let's figure out the issues and work together with ioq3 people to fix them. The limit for GL_EXTENSION seems to be 8192, both for ioq3 and q3. Is any driver really exceeding that ? Here are the size I get : GL_EXTENSIONS: 2385 GL_RENDERER: Gallium 0.4 on NV84 GL_EXTENSIONS: 2407 GL_RENDERER: Gallium 0.4 on llvmpipe GL_EXTENSIONS: 3250 GL_RENDERER: Software Rasterizer Seems to be far from the limit. And with all 3 drivers, cva is detected and enabled fine : compiled vertex arrays: enabled Any information about the extension string segfault ? I never heard of it before, and never saw it happening either. Finally the only thing I can confirm is the big performance difference : r_ext_compiled_vertex_array=1 : 50 fps r_ext_compiled_vertex_array=0 : 10 fps That last point sounds like something that could be reported and could be easily fixed. I hope we can progress on the other issues too :) cheers Xavier ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
