More Details On The OpenGL Situation In KDE's KWin

[bridgman]

1. This doesn't seem to be the matter here. Were it so, the blobs would have faced the same issues (they run on the same silicon after all).

2. Kwin's issues seem to be with older "pretty much everything works" hardware, not with beta R800/Nouveau-level 3d support.

The blobs had access to a fairly sophisticated shader compiler that could deal with shader substitution, injection of code to get around hardware limitations, *and* (on a good day but not all days) funky things like Wine hard-allocating the maximum possible number of resources (which of course wreaks havoc if any workaround shader code is added by the driver). Even that code couldn't deal with all of the potential variables.

The older "pretty much everything works" hardware is exactly the "not quite OpenGL 2.x but everyone expects it anyways" hardware I talked about in (1). That is the worst case scenario for OpenGL support, since the DX and OpenGL specs diverged the most at that point (both in time and in granularity) and most of the hardware was designed around DX specs since the corresponding OpenGL specs did not exist.

[BlackStar]

...or recognize that when there is a mismatch between hardware granularity and OpenGL extension granularity you are going to have cases where partially implemented extensions are the most practical option (not exposing the extension => apps don't run, fully exposing the extension => apps run real slow because of software emulation).

If I may offer a couple of examples :

1. A lot of DX9-family chips don't exactly match the OpenGL 2.x requirements, since they were designed *after* DX9 was released but *before* OpenGL 2.x was released. They do, however, have enough functionality to implement a subset of GL2 extensions that works for most applications. In some cases the situation can be improved by patching in complex shader code, but that brings both performance and compatibility problems, and in most cases the only real solution is to fall back to software rendering for that extension.

What should the driver developers do ?

2. When developing support for new GPUs, the work tends to continue for a year or so, going from "a few apps work" to "pretty much everything works". Most of the time is spent in a "most apps work" state, where most of the advertised extensions work enough to let apps run well but the extensions don't pass all tests and all options, and probably won't for another 6-12 months.

Should the extensions be exposed ?

1. This doesn't seem to be the matter here. Were it so, the blobs would have faced the same issues (they run on the same silicon after all).

2. Kwin's issues seem to be with older "pretty much everything works" hardware, not with beta R800/Nouveau-level 3d support.

His blog is wrong. You can't do blur's and transparent windows without opengl 2.0. You can it's just too hard and not worth it. Which is why it was DONE differently on DX9 Opengl 2.0 2.1 gpu's.

You can implement blur all the way down to OpenGL 1.1. It won't look as good without shaders (no gaussian blur) but it's doable and easy - it's what games did before shaders were available!

You have many options: mipmap blur (GL1.1), render-to-texture blur (*), gaussian blur (GL1.4 with ARB shaders or GL2.1 with GLSL shaders), take your pick.

(*) render-to-texture is available on most GL1.5+ GPUs, as long as the drivers don't suck.

[bridgman]

...or recognize that when there is a mismatch between hardware granularity and OpenGL extension granularity you are going to have cases where partially implemented extensions are the most practical option (not exposing the extension => apps don't run, fully exposing the extension => apps run real slow because of software emulation).

If I may offer a couple of examples :

1. A lot of DX9-family chips don't exactly match the OpenGL 2.x requirements, since they were designed *after* DX9 was released but *before* OpenGL 2.x was released. They do, however, have enough functionality to implement a subset of GL2 extensions that works for most applications. In some cases the situation can be improved by patching in complex shader code, but that brings both performance and compatibility problems, and in most cases the only real solution is to fall back to software rendering for that extension.

What should the driver developers do ?

2. When developing support for new GPUs, the work tends to continue for a year or so, going from "a few apps work" to "pretty much everything works". Most of the time is spent in a "most apps work" state, where most of the advertised extensions work enough to let apps run well but the extensions don't pass all tests and all options, and probably won't for another 6-12 months.

Should the extensions be exposed ?

[liam]

Let me say that I don't have a horse in this race.

Templar, stop trolling.

It's incredible what this thread has turned into. The situation is quite simple, really:

- Mesa advertises features that are known to be broken. The driver guys should think about this
- The communication between the KWin team and the Mesa team was not really good in this case. All the devs should think about this instead of pointing fingers.

I mean, it's obvious that someone would march in here with a prepared "KDE=SATAN!" diatribe, but it's just a friggin optional eye-candy plugin, and you have to manually disable the blacklist to even run it.

I honestly don't care about the KWin situation (again, when I tried KDE 4.5 KWin worked in KDE) since I don't use KDE primarily. However, having read the X/Mesa devs/reps responses I think they made good points. Like it or not, this is how things are going to happen when you have limited resources. If the KWin dev is unable to compile a kernel (something he shouldn't have to do if he would just use a recent distro) then I fear for your desktop. Apparently, the knowledge required to write a window manager in KDE must not be very high (I suppose it's possible qt takes care of enough that it would only be a matter of using the libraries) given the previous, so I suggest someone else contribute to KWin so this dev can get their sleep.
Basically, driver development is, apparently, much harder than WM development, and these companies don't want to pay for more devs, so we have to work with them. So, replace/help your dev, or pay for some more X/mesa coders..

[liam]

Ugh, how many times must this be said?

Metacity supports compositing. This is trivial to look up. This has been around for years...
kraftman, didn't we have this discussion awhile ago?

[liam]

That number seems unlikely.

Damn troll. Check this in Gnome. It's made mainly in devs free time. So you want to tell me that Gnome tries to "compete" being developed mainly in free time? And about volunteers:



"So you want to tell me that Gnome tries to "compete" using only a small number of volunteer devs? Btw. how did you figure out such stupid conclusions?

Do you not recall Neary's census from a month ago, or so? IIRC, 37% is the number of volunteers (the single largest contribution block), while the remainder were from companies (hence, unlikely to be volunteers).
To argue that Gnome is less corporate seems a strange thing to attempt...

[Hephasteus]

His blog is wrong. You can't do blur's and transparent windows without opengl 2.0. You can it's just too hard and not worth it. Which is why it was DONE differently on DX9 Opengl 2.0 2.1 gpu's.

[RealNC]

Debian stable comes with 4.4. 4.6 and 4.7 is available from unstable and experimental. The whole point of a stable Debian release is that should be just that, stable.

Yes. But my point is that stable shouldn't mean hopelessly outdated :P Not as important to users, but very important to developers. Why do you think so many devs use Fedora? Because of its "stability"? :P

So this KWin developer is unable to test with the open drivers because Debian stable doesn't provide them. But he is a developer after all, so why not pull what's needed from Debian testing/experimental then?

People seem to think that driver devs should test their code with all apps out there (huge task). I say KWin devs should test theirs too with both the blob as well as the open drivers (small task). And then report back what doesn't work. Am I the only one to think that this is the best approach? There's a huge swarm of applications out there, but only a small set of drivers. Having the application devs test their code is much easier and quicker than having the driver devs test theirs with all apps out there.

[V!NCENT]

Sounds like MESA_EXTENSION_OVERRIDE

Problem _solved_! I'm outta this thread, happy flamewar boys...

[whizse]

I write the best code I can, but sometimes it's just impossible due to ancient libs. A specific (but off topic in this case) example I can give a project of mine that tries to work as best as it can using Qt 4.5, 4.6 and 4.7. But guess what? Debian comes with the outdated 4.4. No matter how good my code is, on Debian the application looks like ass on Gnome. But on Ubuntu, it looks as native as any Gtk app would.

So right back at ya: learn what it takes to develop software or shut up.

Using Debian for development is a bad idea unless you update it with new versions of libs (backports or whatever.)

Debian stable comes with 4.4. 4.6 and 4.7 is available from unstable and experimental. The whole point of a stable Debian release is that should be just that, stable.