If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
Open-Source GPU Drivers Causing Headaches In KDE 4.5
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.
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.
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.
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 ?".
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.
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.
If the KWin dev decided to write new features in OpenGL 3 because that is easier for him -- i.e. more time for something else -- how could this be bad?
It's also worth saying that Mesa and therefore all open source drivers will not probably support GL3 because GL3 depends on some patented technologies. For example, there are floating point textures and renderbuffers already implemented in a branch for Mesa but merging this branch is postponed until all related patent issues are resolved. We might as well end up being stuck with GL2 for a couple more years. No one knows.