Hash: SHA1

Jose Fonseca wrote:
> Module: Mesa
> Branch: mesa_7_7_branch
> Commit: 93e77b0028170fafd176c3a80a99287343c946b4
> URL:    
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=93e77b0028170fafd176c3a80a99287343c946b4
> Author: José Fonseca <jfons...@vmware.com>
> Date:   Fri Mar 12 17:59:10 2010 +0000
> mesa: List Quake3 extensions first.
> Quake3 truncates the extension string, and GL_EXT_compiled_vertex_array
> wasn't being detected, making it very slow.
> This is a quick fix. The IMHO best way to address this in a more general
> fashion is to sort by year.

Shame on id! :)  I never understood why applications had fixed-size
buffers to store the GL extension string.  Was the extra call to strlen
and malloc during start-up really that expensive?!?

I think providing a way to work around buggy apps is good, but I'd like
to make it optional.  I much prefer, for example, to see glxinfo output
extensions in the current order.  I think the right idea, and sorting by
year is the right start, is to add an alternate sort field to the
existing table.  If a certain driconf variable is set, extensions will
be sorted by the alternate ordering.  This will make it easy to
blacklist buggy apps in the default driconf.

All of this would be handled in the routine that generates the extension
string.  We'd just wrap the generator with a loop over years.  Emit all
the supported extensions from 1992, emit all the supported extensions
from 1993, emit all the supported extensions from 1994, emit all the
supported extensions from 1995, ...

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.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Download Intel&#174; 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.
Mesa3d-dev mailing list

Reply via email to