Open-Source GPU Drivers Causing Headaches In KDE 4.5

[marek]

And a slightly off-topic question: does Mesa implement the noise*() functions for GLSL?

No, it doesn't, since proprietary drivers don't implement it either. A driver is allowed to return 0.5.

[deanjo]

With the fucking intel driver it still doesn't work properly(and I'm using latest graphic stack from git). With latest stable intel driver I even cannot start kde to disable compositing!

Log in without starting X, use nano or your favorite editor to open ~/.kde4/share/config/kwinrc, look for the section called [Compositing] and look for the line saying Enabled=true and change that to Enabled=false, reboot or start X and your in.

[smitty3268]

Again, they are mostly concerned with getting a forward-compatible GL2 version working. That's so they can also run it on mobile devices, and get all the GLSL goodness that 2.0 brings.

The 2 pieces of OpenGL 3 that were mentioned on his blog were:

FBOs, which are already in the open drivers. Also, they have a wrapper around their use, so it transparently falls back on drivers which don't support them. (unless, of course, the drivers lie and simply crash)

Geometry shaders - this sounded much more speculative, and would likely only be used in a couple fancy effects, accompanied with alternatives to run on older versions that might be slightly lower quality if necessary.

[smitty3268]

Also, I should mention they aren't even 'requiring' the use of OpenGL2. That's what started this whole mess, is that they are trying to fallback to 1.x but failing because the drivers say they work with 2. They'll even fall further down into XRender and non-composited mode if they are able to detect problems, and that's the current issue.

[bridgman]

There's a really simple but important point that is still being missed. When a driver is in development it is *going* to expose extensions & GL levels which work in some cases but not others, since typically the exposed features *do* work for enough applications that users are better off having the features exposed.

That suggests one of three approaches :

- application developer communities using driver features known to be in development should coordinate with the driver development community to make sure they use GL features in ways which are known to work - or -

- applications should avoid using driver features known to be in development (this isn't real practical) -or -

- applications should provide a user option to choose between a couple of levels of driver feature usage

The driver developers are working on the 4th option (finish working on GL 2.x) but getting through something as big as GL 2.x is going to take a year or two (although it started a while ago). The unfortunate reality is that GL versions have *not* historically aligned well with consumer hardware functionality, so "almost full" GL implementations are going to be a fact of life until all of the pre-GL 4 hardware has disappeared from the user base.

GL 3-ish hardware can usually run a full GL 2 implementation but there is a lot of very capable "not quite GL2" hardware in use today and for the forseeable future.

Again, the problems here are probably a mix of systemic issues (described above) and good 'ol bugs. The only way I see to close the loop is for app developers to say "I'm doing X with the driver and expecting A, but I'm getting B instead", to which the driver developer will either say "oh crap, it's not supposed to do that" and try to fix the behaviour or will say "that's probably not going to work for you in the forseeable future, how about doing Y instead ?".

[agd5f]

Another thing to keep in mind: while certain GL specs may have been available for years, the support for them in mesa in many cases was only recently completed, or in others, is not complete yet. GL is a huge, often ugly API and it takes a lot of work to implement it properly.

The GL 3.x and 4.x specs may be out but it will be a while before mesa (much less open drivers) gets support for them. And, while the GL 2.x and GLSL specs have been out for years, mesa has not supported them for that long. In fact the GLSL stack in mesa (which only supports GLSL 1.20 right now) is in massive flux at the moment.

It seems to me that if the KDE developers want to target systems using open drivers they might want to at least get some sense of the current state of those drivers and the associated mesa stack.

[BlackStar]

No, it doesn't, since proprietary drivers don't implement it either. A driver is allowed to return 0.5.

Fair enough!

[V!NCENT]

Fair enough!

x'D

67890

[pingufunkybeat]

Give me a list of graphics techniques (requiring GL3) we should have in desktop effects. Then we can talk.

I think that the only GL3 technique that has ever been mentioned in the context of desktop rendering were FBOs.

Then some people blew it out of proportion.

[bridgman]

The main pushback from developers was more related to GL2 features. KDE developers are basically saying "if you expose the extension then it needs to be fully implemented" but that doesn't work from a driver development POV for a couple of reasons :

- a lot of the target hardware does not fully support GL 2.x but is close enough for 95% of apps

- most apps which require (and check for) GL 2 support only use a small subset of the capabilities of the extensions, so exposing features once they are sufficiently implemented to work for most apps is generally the most beneficial for users

This doesn't make either side *wrong*, it just means that if they are both going to be working in the same area at the same time they probably should communicate more.