Threaded GL Dispatch Code For Mesa Sent Out For Review

[dungeon]

Well I accept your opinion but I disagree in this point. In my opinion bugs or bad behavior of code should never be worked around.

That is your wish, but in reality some apps are improper and sometimes run unoptimaly for particular drivers, hardware combo, etc... so it is a must

Your wish is fine if PC is PlayStation, but PC is not PlayStation... it is diversity of various vendors, various hardware combinations, faster or slower, various drivers, various OSes... so things just does not work always by default and profiles are needed to fix default sometimes.

Also PC users unlike Playstation users much more like and need to configure things to better fit their needs... that because we don't all run have same CPU, same GPU, same OS and same OS version, same driver version... PC is utter diverfied thing and gaming people always trying to make random better PlayStation of it

[geearf]

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.

I think part of the reason he doesn't care about it being broken with glxgears, is that he considers the current code-base as not enough and so it's spending time on fixing that crash vs changing more of the underlying code, which might fix the crash or add another one...

It seems strange to me to check in something in that condition, but keeping your feature branch up to date can be a time-waster and if it doesn't break anything by being disabled... I suppose as long as the patches are reviewed...

[oooverclocker]

Well I accept your opinion but I disagree in this point. In my opinion bugs or bad behavior of code should never be worked around(except hardware bugs you can't change anymore or when everything relies on the current state so correcting it(e.g. an Interface) would break a lot) because it just hides the bugs and has the potential to introduce new bugs or reduce the performance for example when you have to execute: if (gamename="Borderlands") do X else if (gamename="...")...

[dungeon]

But the whitelist isn't comparable because if you have to name specific games in your code you are obviously doing something wrong.

Well obviosly you don't do it wrong, sometimes yes driver could be wrong but much more times apps do things wrong also , with appprofiles you just workaround something, improve something, force something you wish on particular app... that is not wrong, but good

Only time when it might go wrong for user is if or when that app is upgraded but also change render behavior for example, so it looks like broken by default... but you can disable profiles if that happens so that is it

[oooverclocker]

Blender will be fixed in next release, that issues is ixed already in its git and it is already fixed for example here in Debian Stretch version of blender, so no DRI3 disablement is needed... that is only temporary

That's very nice news!

[dungeon]

Yeah. The whitelist is in dri and DRI3 causes total render crap at the startup of The Talos Principle with OpenGL and breaks the Blender menu and perhaps in other games/applications as well... (LIBGL_DRI3_DISABLE=1)

Yes, for AMD proprietary drivers that would be also app profile, they handle everything via appprofiles, any variables and xml workarounds per app are profiles.

Blender will be fixed in next release, that issue is fixed already in its git and it is already fixed for example here in Debian Stretch version of blender, so no DRI3 disablement is needed there... that is only temporary

[oooverclocker]

Yeah. The whitelist is in dri and DRI3 causes total render crap at the startup of The Talos Principle with OpenGL and breaks the Blender menu and perhaps in other games/applications as well... (LIBGL_DRI3_DISABLE=1)
Doesn't mean that it had something to do with this list but I just want to point out that not all code on mesa is perfect and I also think that it's no justification to do things a specific (probably worse) way just because it has been done that way somewhere before. I have nothing against your user checkbox idea. But the whitelist isn't comparable because if you have to name specific games in your code you are obviously doing something wrong.

[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

[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]

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.