Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.
-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® 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.
-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® 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.
On Wed, Mar 17, 2010 at 1:01 AM, Jose Fonseca 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® 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.
On Tue, Mar 16, 2010 at 4:32 PM, Ian Romanick 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 >> 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® 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.
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 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
Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.
On Tue, Mar 16, 2010 at 7:13 PM, Roland Scheidegger 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
Re: [Mesa3d-dev] Mesa (mesa_7_7_branch): mesa: List Quake3 extensions first.
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® 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.
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® 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.
-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 > 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 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkufpJcACgkQX1gOwKyEAw/o3QCeMmXtkbQTp8I/yb0G7zNbotIs 0pYAn06BHrhmgc6rva4tqq9KfyNHaDXy =Uh49 -END PGP SIGNATURE- -- 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
