Cogs slow on Linux

[DeXPeriX]

Cogs slow on Linux. Especially, menu/options etc. Yes, my intel x3100 video is weak, but under Windows game runs fast. Another 3d games (Postal 2, Penumbra) runs correctly under my Linux.

I have only some sound errors in stdin:
ALSA lib pcm.c:7223:(snd_pcm_recover) underrun occured

[admin]

Make sure you have the latest version of the graphics and audio drivers.  Note that even if you're using a 64-bit system, you'll need to install the 32-bit drivers.  You may need to go to the graphics card manufacturer's website to get them.

[DeXPeriX]

Yes, I have the latest graphics and audio drivers (via Debian Testing repository). My system is 32-bit. Maybe I need to change some X.org config's device options?

[Paulie88]

Hi, this appears to be a Cogs issue after all. Cogs slowness was brought up at Mesa (linux video drivers) bugzilla several times, and response from developers was this is a Cogs fault. According to Vadim Girlin the problem is:

Uploading excessive amounts of vertex data with indexed rendering when indices count is much less than index range (max_index-min_index+1). E.g. with "Cogs" game typical case is 4 indices and >4000 range.

There is a patch for mesa available which makes Cogs more than 10x faster, but it won't get accepted:

I think it's not a mesa problem, it's a problem of the game which uses opengl in the way which is clearly described in the gl spec as the way to get reduced performance. This patch is a workaround for the game problem and it was written just to check that I located the problem correctly. All other (properly optimized) apps won't benefit from this patch, probably they'll become a bit slower due to additional overhead with this workaround. That's why I'm not sure that I want to submit such patches to mesa.

The best solution is to fix the game itself, so I think it makes sense to ask the game developers about it (or to open the sources).

I suppose open-sourcing at this moment is not an option ;-) however it would be nice if some optimization could be done to the vertex data uploads.
At the moment I'm getting about 1-2fps with my RV530 (mesa r300g driver) and with that mesa debug patch applied I get little over 20fps!

Related bugreports:
https://bugs.freedesktop.org/show_bug.cgi?id=40401
https://bugs.freedesktop.org/show_bug.cgi?id=39572

This is with the latest version from the bundle (12.8.2011).

[admin]

The Cogs vertex data is already very heavily optimized into triangle strips using nVidia's algorithms to greatly reduce the amount of data that needs to be sent to the GPU.  If modifying a driver can result in a 10x performance improvement, the problem is the original driver.

[Paulie88]

The Cogs vertex data is already very heavily optimized into triangle strips using nVidia's algorithms to greatly reduce the amount of data that needs to be sent to the GPU.  If modifying a driver can result in a 10x performance improvement, the problem is the original driver.

OK, I did reopen the mesa bug https://bugs.freedesktop.org/show_bug.cgi?id=40401 . Can you please subscribe to it and maybe make a more detailed explanation of what is going on with that vertex data uploads and make some arguments why this is a mesa fault, so they can fix it properly?

[admin]

Who is the manufacturer of your graphics card?  I highly recommend trying out the first-party drivers available from their website.

[Paulie88]

It is Radeon Mobility X1600, support from Catalyst driver was dropped about 2 years ago, so my only option at this point  is Mesa.

[Paulie88]

Hi, forwarding more developer comments from the mesa bug:

When I was fixing original bug 39572, I downloaded and tried the demo on their
site first (with wine). Running build of this game for another OS through
additional layer (wine) results in excellent performance with the *original*
driver. If without modifying the driver we can get a 10x performance
improvement, I think the problem is not in the driver.

In hope that the game developers are reading this: IIRR, when running through
wine, vertex data is in the gl buffer objects, instead of client arrays, so
that it's not needed to upload it with every draw call (and it's not needed to
filter this data in the driver as these patches do). I'm not sure if it's
wine's optimizations, or the game itself does it this way through d3d. Why not
to do the same with opengl in the native linux build? This will make the game
fast for *all* drivers, without the need for any patches or workarounds. IIRR
the draw call which is so slow in the native linux build comes from
Mesh::draw().

[aliancemd]

So you are basically saying that the experienced drivers developers are wrong when they detect that it's not their fault and even tell you the reason why the game has bad performance? I have i7-2630qm with Intel HD Graphics 3000(Sandy Bridge processor), and I know for sure that Sandy Bridge drivers are performing very well and are developed very well by the Intel engineering team, but the game is still lagging on this pretty powerful integrated graphics processor... Intel HD Graphics 3000 can run some pretty graphic intense games...
There is one more problem, on install on Ubuntu(from the deb file) the game(/usr/local/games/cogs) is not added to the PATH variable and you can't call it from terminal for example... Good thing the find command is extremely fast... I ran it on my nVidia GT 540M external video card and it runs good...
I didn't intend to be rude(It kind of sounds like this, so...), I just wanted to make my point that the drivers are not really the problem(in case of nVidia card it is just to powerful to lag).