GNOME Is Also Getting Fixed Up For Lower CPU Usage With NVIDIA Graphics

[ChristianSchaller]

The drivers from NVidia is implented according to spec.
KDE and GTK are relying on undocumented features of the Mesa drivers.
The error is not in the Nvidia drivers, but in the GTK and KDE implementation. This is the reason that the solution is a patch in KDE and GTK.

Sorry, which spec are you referring to here? There is no such thing as an official specification for how to implement Linux graphics drivers. There is of course the OpenGL specification which both NVidia and Mesa tries to implement according to, but from what I could see here this issues are not related to differences in OpenGL support.

[carewolf]

The closed-source driver strictly followed a spec I'm guessing the open-source ones didn't?

It followed a unique interpretation of the spec, the other drivers and every implementation followed the common interpretation of the spec.

[duby229]

Why are these problems only happening with the NVIDIA closed source driver, and not with the open source drivers? That seems weird.

I don't have any knowledge about this particular instance, but there are many others where nvidia's opengl driver is not compliant with opengl spec. I wouldnt be at all surprised if the spec is ambiguous and nvidia didn't bother -at all- to check other implementations for compatibility. They make every move as if their move -is- the precedent.

It's pretty bad.

[duby229]

The closed-source driver strictly followed a spec I'm guessing the open-source ones didn't?

It's actually far more likely the other way around. nVidia's opengl driver is -not- opengl compliant.

[duby229]

All though i would much rather have open source drivers for my Nvidia GFX card, I must say that their drivers works very well. In fact this performance problem is not due to Nvidia drivers, it is due to a wrong implementation in KDE and GTK.

No, that's highly unlikely. Nvidia's opengl drivers are not opengl compliant. And while I don't have any knowledge about this particular case I can say for sure this exact same scenario has played itself out dozens of times over in the past.

[bearoso]

Sorry, which spec are you referring to here? There is no such thing as an official specification for how to implement Linux graphics drivers. There is of course the OpenGL specification which both NVidia and Mesa tries to implement according to, but from what I could see here this issues are not related to differences in OpenGL support.

The argument is that because glXSwapBuffers is an implicit glFlush and not glFinish that nvidia’s forced triple buffering is ok. But there’s no provision for triple buffering in the OpenGL spec, and the implicit glFlush should ensure the previous SwapBuffers, which is in the command queue, has completed before proceeding. So a deep queue of swaps like the nvidia driver does isn’t necessarily correct behavior.

The new __GL_MAX_FRAMES_ALLOWED environment variable is only one two simple ways to limit that behavior. Using glFinish or glXWaitGL would incur a busy wait in the driver, necessitating setting the __GL_YIELD env variable to “USLEEP” to work around it.

I believe the way Mutter uses the glx_video_sync_sgi extension for frame pacing (when OML_sync_control is missing) also works around it. The patch mentioned in this article is just one of vanvugt’s trying to fix edge cases where Mutter manages to accrue extra latency, but not specifically on nvidia. This isn’t a direct analogue to the kwin problem.

I don’t think the problem is there with nvidia/egl, only glx/X11.

[jukk]

As much as I hate nvidia as the next OSS supporter I have to say Gnome devs are pretty arrogant when it comes to nvidia users.

I've reported a nvidia specific bug (which I included as being so in the report since I have an AMD desktop as well) which prevented the GDM "stupid-windows-clone-go-up-curtain-crap" from going up when clicking or pressing a button. There's a twitchy reaction only on nvidia setups where it blinks over to the "whats-behind-the-stupid-curtain" and possibly even types whatever you pressed in a password field but then it blinks back and you're at square one.

This effectively prevents you from removing the useless piece of curtain-crap unless you actually do a "drag" with your mouse (good luck mouseless setups I guess?).

They weren't even able to ack the issue because guess what, "no nvidia here buddy".

It's ridiculous. If gnome was a 1-5 person thing I'd accept that but this way it's just retard land.

I've noticed this issue in the past. Can't remember when it went away, but at least it works in Fedora 29.

[Aeder]

As much as I hate nvidia as the next OSS supporter I have to say Gnome devs are pretty arrogant when it comes to nvidia users.

I've reported a nvidia specific bug (which I included as being so in the report since I have an AMD desktop as well) which prevented the GDM "stupid-windows-clone-go-up-curtain-crap" from going up when clicking or pressing a button. There's a twitchy reaction only on nvidia setups where it blinks over to the "whats-behind-the-stupid-curtain" and possibly even types whatever you pressed in a password field but then it blinks back and you're at square one.

This effectively prevents you from removing the useless piece of curtain-crap unless you actually do a "drag" with your mouse (good luck mouseless setups I guess?).

They weren't even able to ack the issue because guess what, "no nvidia here buddy".

It's ridiculous. If gnome was a 1-5 person thing I'd accept that but this way it's just retard land.

Oh boy, the irony of calling the Gnome devs arrogant.

How dare those devs working on a project on a voluntary basis not buy the same card as me, even if the company that manufactures it makes it unnecessarily hard to support it or even use the thing?

Feel free to ask for a refund.

[Almindor]

Oh boy, the irony of calling the Gnome devs arrogant.

How dare those devs working on a project on a voluntary basis not buy the same card as me, even if the company that manufactures it makes it unnecessarily hard to support it or even use the thing?

Feel free to ask for a refund.

Except gnome has paid contributors. This isn't some shack-a-project. They can more than easily affort "a" nvidia card from the last 5 years to test these bugs. This is not something specific to "this particular high end card" you know. Any nvidia card from a couple generations would do.

I suspect they need to spend their money more on outreachy and other crap than trying to get a proper QA

[stormcrow]

Oh boy, the irony of calling the Gnome devs arrogant.

How dare those devs working on a project on a voluntary basis not buy the same card as me, even if the company that manufactures it makes it unnecessarily hard to support it or even use the thing?

Feel free to ask for a refund.

Conveniently forgetting that Gnome backed by some of the biggest names in the computing industry with both financial and human resources? People and corporations are actually paying for Gnome through IBM/RH, SUSE Enterprise, Canonical, and other support contracts. Gnome is literally PAID to handle these problems and they're not doing it, so yeah, go ahead and call for boycotts. Works for me. I've had nothing but grief with Gnome 3 crashes - even on Intel graphics which is supposed to be it's best supported platform.