Threaded GL Dispatch Code For Mesa Sent Out For Review

[phoronix]

Phoronix: Threaded GL Dispatch Code For Mesa Sent Out For Review

Marek Olšák volleyed the 26 patches needed for Mesa supporting threaded OpenGL dispatch onto the Mesa mailing list for some additional public review...

http://www.phoronix.com/scan.php?page=news_item&px=GL-Dispatch-Mesa-Review

[M@GOid]

If things got ugly, just let us enable it with Environment Variables. I never understood why Borderlands games were so difficult to keep minimum FPS above 60, even with high end GPUs, now I understand. I hope this code also helps ATS/ETS2 games, both stuck in OpenGL3 era and in badly need of some performance improvements.

[oooverclocker]

Yeah what about enabling it that way and leaving it to the users and game providers?
As long as it has a negative impact on several games it shouldn't be activated by default but I also don't want bugfixes for specific games in the driver. In the end it will become as heavy and buggy as Windows drivers are

It can be activated for all games without any exclusions as soon as the quality of the code ensures that no game will suffer from it anymore. And that should be the goal without addressing every game in particular.

[crymsonpheonix]

Half baked code shouldn't go into master, it's bad development practice. It doesn't pass tests, it causes a number of programs to segfault, and it hurts performance on *all* feral games. The last thing just means you need a whitelist, but causing segfaults and regressing a huge number of tests means that the code is *not ready* for prime time.

[Hibbelharry]

Thats why it will be hidden behind a flag, disabled by default. Many features do make their way using that practice. You sometimes need to get experience, to make things good.

[duby229]

Half baked code shouldn't go into master, it's bad development practice. It doesn't pass tests, it causes a number of programs to segfault, and it hurts performance on *all* feral games. The last thing just means you need a whitelist, but causing segfaults and regressing a huge number of tests means that the code is *not ready* for prime time.

I don't have any experience with this myself, but if it is as you say, then I agree with you. On the other hand the one thing driconf is good at is setting environment variables per application so I don't see a problem having it built and not used by default.

[Strunkenbold]

I dont see the point letting this code rod in a git branch till forever. The execution is protected by an env variable. So it actually hurts nothing. User who try can finally enjoy a more stable Borderlands experience.
The patches are almost 4 years old and since one year Marek is trying to merge those patches in master. This alone shows that there are probably no resources available to develop the code to a level it reaches a full satisfying experience in all circumstances.
Things might be different when there would be enough developers working on mesa, but the reality is, the existing devs could spend their time alone just for fixing bugs in existing games, which there are plenty!

[dungeon]

Yeah what about enabling it that way and leaving it to the users and game providers?

This is no about enabling anything, it is just question should be this code in mesa git or not.

As long as it has a negative impact on several games it shouldn't be activated by default but I also don't want bugfixes for specific games in the driver. In the end it will become as heavy and buggy as Windows drivers are

It is not that only Windows drivers are like this, but also Linux blob drivers too . nvidia driver has variable since 2012. and after 5 years recently as latest beta driver they enabled it by default, fglrx/amdgpu-pro has also this enabled via profiles. In both cases using this is optional.

[smitty3268]

I dont see the point letting this code rod in a git branch till forever. The execution is protected by an env variable. So it actually hurts nothing. User who try can finally enjoy a more stable Borderlands experience.
The patches are almost 4 years old and since one year Marek is trying to merge those patches in master. This alone shows that there are probably no resources available to develop the code to a level it reaches a full satisfying experience in all circumstances.
Things might be different when there would be enough developers working on mesa, but the reality is, the existing devs could spend their time alone just for fixing bugs in existing games, which there are plenty!

I think the main concern is that if Marek can't spend the time to even just fix up the crashes that piglet tests cause, then he's basically just dumping a bunch of half-baked code into master and washing his hands of it. Who's going to be the code maintainer? It seems like Marek doesn't want to be that person, and no one else has tried merging it in 4 years either so...

I don't know. I get the pragmatic side that it helps out 1 game so why not just add it in. But that can be a very slippery slope to disaster. It's the way you end up with drivers like fglrx that no one can understand or fix without breaking half a dozen other supposedly unrelated things.

[dungeon]

I don't know. I get the pragmatic side that it helps out 1 game so why not just add it in. But that can be a very slippery slope to disaster. It's the way you end up with drivers like fglrx that no one can understand or fix without breaking half a dozen other supposedly unrelated things.

What slippery slope or disaster, for user this is just enable or disable variable or checkbox if you have a GUI It is entirely optional and does not affect main "currently proper" paths neither for developers.