Do Devs play games or test what they do ?

[ForkedPython]

Im running

x.server x.org 1.7.2.0
Kernal 3.13
and Mesa 9.2

I have noticed On Mesa 10.1 and above adding AA to source engine games slows the framerate to unplayable. Also On Mesa 10.1 the overal FPS is higher than 9.2 but it is not as smooth by far, also 10.2 is even worse.

So the question I have is how can one make a change that ruins a game such as a source engine game and not actually play test to see if that was a positive change? It seems like a chef not tasting the stew before serving.

So at the moment, I wont run Oibaf or Edgers just incase it screws the performance up, but i would like some Opengl support for newer games.

[curaga]

I will have to ask: what do you think makes Source special. Sure, it's important to you, but what should make it important to dev foo?

inb4 it's popular. By that argument everyone would have to test (and buy!) the top 10 games each year, including such shining examples as Minecraft or WoW.

[ForkedPython]

I will have to ask: what do you think makes Source special. Sure, it's important to you, but what should make it important to dev foo?

inb4 it's popular. By that argument everyone would have to test (and buy!) the top 10 games each year, including such shining examples as Minecraft or WoW.

I dont see a problem with that argument. It's not totally out of the question to test your work it happens in all industries.

now, do they test against a benchmark when complied at all? if not then there litterally is no testing other than a basic soak test. Which is appaling.

[ForkedPython]

noticed that is it actually the X.org Edgers PPA that slows down performance lots.

1.7.2.0 is fine, 1.7.3.0 is slow and chuggy.

anyone going to test and fix?

[agd5f]

We try and test as many cases as possible, but we can't test every combination of hw, apps, distros, kernels, drivers, and libs. If you are having a particular problem or notice a regression, please report a bug (https://bugs.freedesktop.org).

[ForkedPython]

We try and test as many cases as possible, but we can't test every combination of hw, apps, distros, kernels, drivers, and libs. If you are having a particular problem or notice a regression, please report a bug (https://bugs.freedesktop.org).

for some reason even though i havent added a PPA i have now noticed a large frame drop and stuttering. So i checked

glxinfo | grep "OpenGL version"

and it was 10.2 again

before this it was butter smooth on 9.2

What's the easiest way to regress to 9.2 again please? All source 1 and source 2 engine games are effected.

Also, i wont report a bug, it should be plain as day when the main games for testing TF2 (even phoronix has a TF2 benchmark) L4D2 et al.. are going much slower with 10.2. Why should I bother when 9/1000 i get no response for months and then smooth, and then slow and then smooth and then slow

10.2 =
10.3 =
10.4 =
10.5 =

etc...

this has happened for quite a number of years. It's the reason Canoical and Valve are taking their own approach and release schedules to stuff as there is no quality control in the opensource world. Excusing a few dev's who care and Torvalds.

So what is the easiest way to go back to 9.2 please..

[bridgman]

AFAIK 10.2 is not released so you would only be able to get testing builds -- if you are seeing problems in 10.2 that don't have existing clear bug tickets then it is really important to get one in -- every combination of hardware & distro is going to behave slightly differently, so it's not uncommon for a change to improve behavior on hardware the developer owns but cause problems on another hardware/software combination.

One of the huge benefits of open source development is that users do have real-time access to the tips of development branches (this is what oibaf and xorg-edgers builds give you) so users can test on a wide range of configurations and report bugs before the code is released.

The best way to downgrade depends on how you upgraded in the first place. You mentioned that you are not using the oibaf or xorg-edgers testing repositories -- how did you get from mesa 9.2 to 10.1 / 10.2 ? Did you build from source (in which case the best approach is probably to delete/rename the files you built and then remove/re-install the corresponding packages from the original distribution) or upgrade from a PPA ? You seemed to be surprised that your version was 10.2 so that suggests you may be getting them from a PPA.

[ForkedPython]

AFAIK 10.2 is not released so you would only be able to get testing builds -- if you are seeing problems in 10.2 that don't have existing clear bug tickets then it is really important to get one in -- every combination of hardware & distro is going to behave slightly differently, so it's not uncommon for a change to improve behavior on hardware the developer owns but cause problems on another hardware/software combination.

One of the huge benefits of open source development is that users do have real-time access to the tips of development branches (this is what oibaf and xorg-edgers builds give you) so users can test on a wide range of configurations and report bugs before the code is released.

The best way to downgrade depends on how you upgraded in the first place. You mentioned that you are not using the oibaf or xorg-edgers testing repositories -- how did you get from mesa 9.2 to 10.1 / 10.2 ? Did you build from source (in which case the best approach is probably to delete/rename the files you built and then remove/re-install the corresponding packages from the original distribution) or upgrade from a PPA ? You seemed to be surprised that your version was 10.2 so that suggests you may be getting them from a PPA.

Thanks for the reply.

The drivers were out of the box for Mint 16 Cinnamon.

I am running a very standard AMD opensource setup with no funnies. I must confess somewhere along a 10.1 release it got worse and carried on into 10.2

I wouldnt even know how to begin bug hunting when technically its just slow performance. Im sure its openGL related though.

[bridgman]

When you say "the drivers were out of the box" are you talking about Mesa 9.2 or the more recent ones ? My impression was that Mint 16 shipped with a 3.11 kernel and 9.2 Mesa but you seem to have a newer kernel as well as newer Mesa, and Mint doesn't seem to be particularly aggressive in terms of driver updates.

The Mint Debian version (based on Debian testing) seems to have a newer kernel but it's still not obvious to me where you could be getting 10.2 Mesa from if you don't have a testing PPA enabled somehow...

[asdfblah]

hyperz was disabled in 10.2, did you enable it? you have to set a environment var:

R600_DEBUG=hyperz