Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-17 Thread Xavier Chantry
On Tue, Mar 16, 2010 at 4:32 PM, Ian Romanick i...@freedesktop.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 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 +

 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 don't really have interest in investigating further to check/verify
these claims , but this might be an answer :

21:26 @kevlarman oh and it's not nearly as simple as just use malloc()
21:27 @kevlarman the structure with the extensions string is passed
to the cgame and ui modules,
   which are usually run in a sandbox without a
malloc() implementation
21:28 @kevlarman and even if they had it, the client has no way of
communicating to them how much
   memory they should allocate for it to write the
extension string
21:29  shining kevlarman: why isnt there all freedom to change that ?
21:30 @kevlarman shining: because then it won't work with q3 anymore

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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-17 Thread Xavier Chantry
On Wed, Mar 17, 2010 at 1:01 AM, Jose Fonseca jfons...@vmware.com wrote:
 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.


Then sorry for the noise, maybe the commit could have made it a bit clearer :)

It does seem that latest version of quake 3 (and ioquake3) use a large
enough buffer of 8192.
But earlier versions of q3 might have used something as short as 512.
Unfortunately, I could not find when exactly it was fixed.

I somehow forgot the obvious fact that there are 20 or more q3 based
proprietary games
(thanks to Patrice Mandin for pointing that out)
http://en.wikipedia.org/wiki/Id_Tech_3#Uses_of_the_engine

We would need to test them all in their latest version to know which
ones are still affected and were not fixed. I could not find any
report / information about that either.

Patrice also pointed me to the workaround that nvidia driver provides itself :
http://us.download.nvidia.com/freebsd/190.42/README/chapter-09.html

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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-17 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jose Fonseca wrote:

 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.

Yes.  I have heard other people in the ARB mention that some apps do
that.  I'm sure the games in the Quake family aren't the only ones.  I
usually hate hacks to work around app bugs, but I think that some form
of this hack is okay because there are a bunch of apps that do the wrong
thing.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuhTvwACgkQX1gOwKyEAw/DbgCghoL1RB0Psh6gSjiNLndw8g7r
cBgAn0x5ZQ8hFS9CGahCZ7+n+nC5ZXOd
=MQZG
-END PGP SIGNATURE-

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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-17 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xavier Chantry wrote:

 Patrice also pointed me to the workaround that nvidia driver provides itself :
 http://us.download.nvidia.com/freebsd/190.42/README/chapter-09.html

Their solution is roughly analogous to a driconf variable.  I think we
should do the same.  I was initially thinking the configuration variable
should change the sorting, but now I'm thinking that it should limit the
extensions exposed.  Something like only advertise extension from 1998
or before.  That would be even easier to implement than the alternate
sorting rule.

Perhaps someone should file an enhancement bug to track this.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuhT+MACgkQX1gOwKyEAw8MGACfWQ2w6jpZ0RNkXR6F+52BbyX5
CSoAoIyo/TYsw4Cw9aCZ7qaz9rBeDPE/
=VZoU
-END PGP SIGNATURE-

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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-16 Thread Keith Whitwell
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...

Keith


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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-16 Thread Roland Scheidegger
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...

Roland

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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-16 Thread Xavier Chantry
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#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.
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


Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.

2010-03-16 Thread Jose Fonseca
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#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.
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