Threaded GL Dispatch Code For Mesa Sent Out For Review

[smitty3268]

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.

The slippery slope is having a bunch of complicated, unmaintained, poorly tested code in master, that's what. It's a slope because 1 thing like this is fine, but 10? Or 50? That's when trouble is bound to happen.

[suberimakuri]

By sending it through the review process at least those interested can check it and if they feel that strongly they can point out specific issues they have, which in turn can be handled.
sounds like Marek wants to merge so more people can easily test like us and provide appropriate bug reports. Seems reasonable.

[dungeon]

The slippery slope is having a bunch of complicated, unmaintained, poorly tested code in master, that's what. It's a slope because 1 thing like this is fine, but 10? Or 50? That's when trouble is bound to happen.

But that is how development happens also, no one just dump out of nowhere final 100% working solution Reason for this to be in mesa is not just to fix one game (even if initially just looks like that) it is there to show you at least with one game working proof of concept is avaliable and that its code can easier evolve there step by step.

It does not affect anything by default and it is disabled by default, so why not

[dungeon]

When nvidia driver introduced back in 2012. that __GL_THREADED_OPTIMIZATIONS variable it was also like that, some apps see improvment, other get worse perf, third ones segfaults with it, etc... that is all normal

[smitty3268]

Who cares, Amd workers have fixed kernel and mesa driver bugs in a week or two. Nobody has such resources that can test with every game and hardware configuration. Add there hundreds of Linux distributions, you will get the picture.

That's exactly what fglrx developers said 10 years ago.

Anyway, nobody is saying things have to be exhaustively tested. But when glxgears is broken, it shouldn't be that tough to figure out.

[smitty3268]

But that is how development happens also, no one just dump out of nowhere final 100% working solution

But they usually develop it in a separate branch until at least glxgears is working.

[dungeon]

But they usually develop it in a separate branch until at least glxgears is working.

Yep usual, but this one is unusual as even if it is 100% complete (where currently it is very far from that) shouldn't speed up everything, no . So, there is no need every GL app to work with it and it won't work for any app.

Some apps won't see any improvment (these should be skipped), some should see something by default or just in certain settings scenario, some will get worse perf, some should see segfaults... that is what people should expect from enabling this and that it is normal

[dungeon]

He, he, people better to follow what Marek said there and test only with GL3 apps exclusively for the beggining, even among these it won't work for everything... basically don't expect it should do anything for anything else

Apps based on OpenGL 3.3 Core should work. Some OpenGL 4.x apps might work too, but it's not certain. There is a lot of work to do.

[oooverclocker]

I think there is consent that the code shouldn't be abandoned just because it's not in a perfect shape. On the other hand I also think that it's very reasonable not to implement a white list with specific names on in universal driver code for some features.

So as long as it stays an option to be enabled by the user so he gets better performance but is disabled for all games by default not many people would disagree, I'm quite sure about that.
But the code itself should also be commented being ugly and the specific feature should be handled on a list of ugly parts for people that like to contribute to the drivers in my opinion. Perhaps there could also be a bug report for every case that describes the issue so the list can link to it.

If it's not done this way I'm afraid it will never reach an acceptable state to work for all cases.

[dungeon]

On the other hand I also think that it's very reasonable not to implement a white list with specific names on in universal driver code for some features.

But you already have whitelist in mesa , see these apps works by default only because they are workarounded via drirc

https://cgit.freedesktop.org/mesa/me...i/common/drirc

If you wanna Unigine to not work, etc... just remove drirc and you will be proper.

With AMDGPU-PRO just don't install 'libgl1-amdgpu-pro-appprofiles' package and you will be again proper

Or with FGLRX just uncheck this box and you will be proper