Question

20

Which graphics driver set is better to test in the long run?

rated 0 times [ 20] [ 0] / answers: 1 / hits: 432 / 2 Years ago, sun, april 24, 2022, 4:53:58

So, my computer has a Radeon mobility card and Compiz doesn't seem to want to play nice with it. The nets me a tradeoff: I can use the proprietary drivers and get the boosted performance and take a hit to several usability items, or I can use the "standard" drivers and take the hit to performance in favor of everything working properly.

I also happen to do a lot of alpha testing on a spare partition on this machine. This leaves me wondering, which driver should I be using? Is it more important to get the "standard" drivers to actually perform better? Or should I be filing bugs against Unity because it doesn't work with the proprietary set properly? Or both.

What do developers suggest that I run to benefit the project more in the long term? Regardless of what type of graphics card is used. Or is that a factor in what set should be used?

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

cisccla

Add To Favorites

Follow

Total Points: 66

Total Questions: 134

Total Answers: 115

Location: Croatia

Member since Fri, Sep 11, 2020

4 Years ago

answered 2 Years ago utschang · Accepted Answer

As one of the Ubuntu X maintainers I can say: testing on both the open-source and proprietary drivers is valuable; we have lots of users of both, and it's important the Unity runs well on both the free stack and the proprietary stack.

However, if you want your testing to have the biggest impact, testing the free stack would be the way to go - at least for AMD cards.

The open-source radeon driver has a reasonable set of developers - it's not large and can always do with more, but it's supported by AMD. Barring the influx of hundreds of full-time developers these drivers won't achieve the same performance as fglrx, but it's entirely possible they'll achieve 90-95% of the performance; it's the last couple of percent that's extremely expensive.

They're also much easier to improve - because they're open-source, we have visibility into fixes and can much more easily justify fixing bugs in stable releases. With the fglrx driver we just get a code-dump mixing features and fixes, with unknown regression potential. This makes it difficult for us to update the proprietary drivers in a stable release.

Finally, there's more prospect of improvement for radeon than for fglrx. Radeon developers care about the whole desktop stack, fglrx is largely targetted at workstation users.

For nouveau the answer is a bit murkier. There's still more prospect of improvements in nouveau than nvidia - again, nvidia is largely targetted at the workstation market - but nouveau has a harder time making progress than radeon, as they additionally need to reverse-engineer everything.

All this applies mostly to bugs rather than performance. It's generally harder to generate a good performance bug than it is to generate a good crash or incorrect rendering bug. Rendering and crash bugs are generally isolated to a small section of code, whereas performance problems generally involve a whole stack of code. Where you find isolated performance problems they can be worthwhile to report, but that's not the common case.

In short, performance problems generally require active effort to identify - you're unlikely to stumble across an actionable performance problem. Bugs - both crashers and misrendering - you can easily identify during normal use.