Is glFinish really the answer? about kwin-lowlatency

[markg85]

KWin desktop effects can be unstable with OpenGL 3.1, at least this is true for some older Intel iGPUs I'm using, and also for some older NVIDIA proprietary drivers (tho I didn't see any problems with current drivers). So at least OpenGL 2.0 should stay. Your patches could use different code paths depending on which implementation is used.

Why would KWin (and this fork) maintain compatibility for hardware that old or crappy?
I personally would just say: use another lightweight desktop environment that would be more suitable anyhow or use a still active LTS version. But again, that's just me :)

[tildearrow]

Why would KWin (and this fork) maintain compatibility for hardware that old or crappy?
I personally would just say: use another lightweight desktop environment that would be more suitable anyhow or use a still active LTS version. But again, that's just me :)

Sorry, I don't break compatibility.

[kakra]

KWin desktop effects can be unstable with OpenGL 3.1, at least this is true for some older Intel iGPUs I'm using, and also for some older NVIDIA proprietary drivers (tho I didn't see any problems with current drivers). So at least OpenGL 2.0 should stay. Your patches could use different code paths depending on which implementation is used.

[markg85]

You forgot about one thing: KWin has 2 OpenGL backends, which are OpenGL 2.0 and OpenGL 3.1. Of course the GL_ARB_sync isn't present in any of the aforementioned versions.

You're absolutely right!
I noticed that just a minute ago when installing your version of KWin :)

But... to be honest... I think it's very safe to require OpenGL 3.2 or even higher these days.

[tildearrow]

What would take more work to do either short or long term? Adding support to Kwin's backend for a newer opengl version OR supporting this fork.

The former.

[tildearrow]

Hmm, so maintaining the OpenGL 2.0 code path and upgrading the 3.1 code path to 3.3 would make sense, by retaining compatibility with old hardware and making use of required newer features ?

It would, but would take me more effort (I will do this at some point in the future).

[tildearrow]

You forgot about one thing: KWin has 2 OpenGL backends, which are OpenGL 2.0 and OpenGL 3.1. Of course the GL_ARB_sync isn't present in any of the aforementioned versions.

[qwertychouskie]

Are there even any drivers that support OpenGL 3.1 but not 3.3? There's Intel HD 3000 on Windows, but that's the only one I know of, and I don't think Windows is a target of Kwin ;) It's probably safe to require 3.3.

[markg85]

I think that 3.1 requirement was a conservative requirement in the time that Mesa drivers were just inching towards 3.0 support. That's years ago, now they fully support all of OpenGL 3.3. Even the software implementations!

I'd say that requiring 3.3 (and kicking out 2.0 and 3.1 if they become an issue) is fine.

[agates]

The only issue is I think I've seen kwin default to OpenGL 2.0 -- likely not an issue for users like us -- and maybe it doesn't actually matter -- but perhaps something to note before installing if 3.3 becomes required.

[joder666]

Out of pure ignorant curiosity, since apparently updating the backed support would solve a bunch of issues or help solve them in a more modern, efficient(?) manner.

What would take more work to do either short or long term? Adding support to Kwin's backend for a newer opengl version OR supporting this fork.

[kakra]

Why would KWin (and this fork) maintain compatibility for hardware that old or crappy?

This is a very subjective answer. How can you define something as "old or crappy" if you even didn't know what it is?

I personally would just say: use another lightweight desktop environment that would be more suitable anyhow or use a still active LTS version. But again, that's just me :)

That's also not why I use Linux. If I wanted an OS that simply throws away compatibility with somewhat older hardware, I'd go for Windows or MacOS.

Also, how can you pretend that the system I am using has LTS versions? It doesn't.

The distribution itself supports my hardware just fine but drivers may have bugs, or that particular support branch of the driver just doesn't implement some fancy new graphics APIs. Why should KWin force-fully break compatibility with such drivers? If it cuts away some effects that's okay. But it shouldn't show any obscure bugs like freezes and crashes. That's why a feature-limited fall-back implementation should remain.

And just calling the NVIDIA proprietary driver crap (which from the context you probably meant) because you may be an open source activist is just punching the open source devs at NVIDIA in the face. After all, they contributed a KWin patch to finally support wayland - and BTW: Wayland is far far from feature complete in KWin - and that does say nothing about how it could be superior or not. So how to continue? Just throw away a "crappy" wayland implementation? Or better throw away a working Xorg implementation? Such arguments help no one.

Don't get me wrong: I'm not a fan of closed source drivers, too. But these drivers particularly (in contrast to many others) show a very high quality in stability and performance. And looking at projects like DXVK, NVIDIA devs are working more and more closely with open source developers to improve the driver.

[markg85]

And just calling the NVIDIA proprietary driver crap (which from the context you probably meant) because you may be an open source activist is just punching the open source devs at NVIDIA in the face. After all, they contributed a KWin patch to finally support wayland - and BTW: Wayland is far far from feature complete in KWin - and that does say nothing about how it could be superior or not. So how to continue? Just throw away a "crappy" wayland implementation? Or better throw away a working Xorg implementation? Such arguments help no one.

Wow, your comment really is nasty and fully out of context. You're even blaming me for things i never even said! Really, comments like that are a thorn in the eye of FOSS development. Out of context crap. Go re-read your insanity and apologize for it.

To quickly moot your arguments.
I did not say Nvidia is crap, you made that up.
I said that if you require opengl 2.0 or 3.1 that you have crappy old hardware and that you should be better off running a distro aimed for old hardware. I did not say you were running an LTS version, just that you might be better off if you did.

So cut the assumptions and spreading of fud.

But now that we're on the opengle version subject (again, that is the topic).. OpenGL 3.1 was released in 2009.
3.2 in 2009 as well
3.3 in 2010.

I really don't think there are any gpu drivers that do support 3.1, but don't support 3.3. And given that 3.3 has the potentially better glFinish alternative, it might be worth just tweaking the current 3.1 driver and require 3.3 instead.

[bidinou]

Hmm, so maintaining the OpenGL 2.0 code path and upgrading the 3.1 code path to 3.3 would make sense, by retaining compatibility with old hardware and making use of required newer features ?

[bidinou]

Yeah, it definitely shouldn't solely lie on your shoulders :-)
Thank you so much for your efforts.

[tildearrow]

Closing as KWin-lowlatency 5.22+ does not use glFinish anymore.