Mesa OpenGL Threading Messed Up Cursor Handling With KDE Wayland - Fixed Now

[abott]

What are you on about?

I'm quoting your moronic bullshit that says OpenGL threading is defacto broken. It's not. The driver has bugs, but the threading is GENERALLY stable. It's issues are to be ironed out in the driver ONLY. Valid OpenGL should ALWAYS work. If it doesn't, it's a bug, and threading triggering bugs elsewhere means absolutely fuck all about KDE's issues. KDE is either hitting someone else's bug, or their own, but if it's their own, it was ALWAYS broken.

Vulkan isn't what's being talked about. The concurrency issues are a non-issue when your code/driver isn't bugged. Vulkan is much better at it, but your claims about OpenGL generally being fucked with threading are COMPLETELY incorrect, provided it worked as it should. They've got other issues, yes, but they're not anything to do with OpenGL's spec. The OpenGL spec should be followed, and that's the rule. If it breaks the rules, the driver is to blame.

[oiaohm]

I'm quoting your moronic bullshit that says OpenGL threading is defacto broken. It's not. The driver has bugs, but the threading is GENERALLY stable. It's issues are to be ironed out in the driver ONLY. Valid OpenGL should ALWAYS work. If it doesn't, it's a bug, and threading triggering bugs elsewhere means absolutely fuck all about KDE's issues. KDE is either hitting someone else's bug, or their own, but if it's their own, it was ALWAYS broken.

Vulkan isn't what's being talked about. The concurrency issues are a non-issue when your code/driver isn't bugged. Vulkan is much better at it, but your claims about OpenGL generally being fucked with threading are COMPLETELY incorrect, provided it worked as it should. They've got other issues, yes, but they're not anything to do with OpenGL's spec. The OpenGL spec should be followed, and that's the rule. If it breaks the rules, the driver is to blame.

The catch the opengl covers a very long time frame. Early opengl there is no idea of multi threaded because the systems it was being developed on you had a single thread for drawing that was it. VBO and other parts appear after 1.4 opengl as addons to opengl and in specification at opengl 3.2 that allow multi threaded functionality with opengl with reasonable safety.

Some opengl functions are not thread safe.

https://github.com/RPCS3/rpcs3/commit/ebbf329b6aea41a42daf96902b4f19375c05c67d

This leads to work arounds like above adding fences.

Abott opengl threading is more case works due to applications altering their code bases adding extra functions that you don't need for single threaded opengl. Yes the specification of opengl is written that everything will be done in order by the way as in single threaded. Those implementing opengl take the directive in the opengl standard that it should be single threaded as only a guideline.

The fact how opengl handles threading it not clearly written in the opengl standard is what leaded to Vulkan.

There are tones of examples of applications that work with opengl threading enabled but these applications are really using a subset of Opengl and obeying particular rules on how to do things like including fences.

[piotrj3]

As a KDE user I would agree on that. On Wayland KDE cursor movement is really buggy. For example, a game locked to 60 fps and minimized cripples cursor movement on desktop to the same 60 fps - just because it is opened. Though any other windowed app can run 144 FPS at the same time. That never happens on X11 session.

This is more due to poor synchronization aspect of Wayland. Generally speaking, in Wayland you might often face situation of sort, hey i have complex blender scene that will of course lag, but because it is lagging it brings lag on entire desktop. Mouse also is rendered this way (by default) and you have those sort of issues.

There is some proposals to fix it ( one by nvidia employee) some involve explicit sync some involve hacks on implicit sync.

[abott]

Some opengl functions are not thread safe.

https://github.com/RPCS3/rpcs3/commit/ebbf329b6aea41a42daf96902b4f19375c05c67d

This leads to work arounds like above adding fences.

If it's not thread safe to do, then the driver shouldn't do it. That's the whole idea here. DOH. And that fence doesn't mean shit if it's never used or optimized out, which is an option in the pipeline. NON-ISSUES.

[oiaohm]

If it's not thread safe to do, then the driver shouldn't do it. That's the whole idea here. DOH. And that fence doesn't mean shit if it's never used or optimized out, which is an option in the pipeline. NON-ISSUES.

Non thread safe behavior is part of the opengl standard. So driver don't do it the function that way the driver is non conformant. Never used would be ideal but when working on hardware that does not support opengl 3.2 as some embedded systems kde implementation has attempted to support the newer multi thread safe functions are not there. Optimized out again is not option.

Correctly placed fences and alternative code paths both require application modifications not driver. This is just a case opengl is down right old with lots of legacy crud.

Opengl driver developers are seriously between rock and hard place due to the Opengl standard.