KDE SC 4.5 is about to be released and KDE SC 4.6 is being discussed. However, Martin Graesslin has revealed some details about what they are planning for KDE 4.7.
According to Martin’s blog post, they are looking at OpenGL 3.0 to provide the compositing effects in KDE SC 4.7. OpenGL 3.0 provides support for frame buffer objects, hardware instancing, vertex array objects, and sRGB framebuffers.
Read more here
To my knowledge, OpenGL 3.0 isn’t supported by any open source graphics drivers at the moment.
And the linked article state as much, but current support for OpenGL 3.0 is not particulary important. Of course the timeframe when such support emerege is.
Since this is about planning a future KDE release, KDE 4.7, estimated to be released more than 12 months from now. Driver support oucht to beome widespread by then, as OpenGL 3.0 has been avalible for some time already.
That may not really matter. OpenGL 3.0 is basically the same as OpenGL 2.x but with many required extensions. In order for an implementation of OpenGL to be OpenGL 3.0, it has to implement all those extensions.
The Mesa OpenGL 3.0 status page (http://cgit.freedesktop.org/mesa/mesa/plain/docs/GL3.txt) shows that most of the extensions are already completed (some of them still need the drivers to provide the functionality, even though the feature is present in core Mesa).
KDE is unlikely to use all those extensions. They will probably only use a few of them. If they do it the correct way, which is to check for the presence of each extension, rather than blindly require all of OpenGL 3.0, there’s a good chance that it would already work with the open source drivers (and if not now, probably it will by the time KDE SC 4.7 is released).
3.3 or 4.1 would be a better fit. 3.0 had a huge lack of polish and a lot of things that were essential were later were added in in 3.1
4.1 rivals Direct 3D pretty well as far as feature parity.
http://arstechnica.com/software/news/2010/07/khronos-group-releases…
Edited 2010-07-29 19:27 UTC
Yea, but full 3.3 support is many years away, full 4.1 is probably 5 years away.
Once 3.0 is completed in Mesa, I wouldn’t be surprised if it could get to 3.3 in six months. 4.1 within a year or two (it requires graphics cards which barely exist right now, anyway). 2.x -> 3.0 is by far the largest hurdle.
Cause you couldn’t use official binaries from Nvidia or AMD. Nope! Can’t do that!
Well, you can’t use official binary Linux drivers from Nvidia or AMD to get support for OpenGL 4.1, if that is what you mean.
Edited 2010-07-30 10:16 UTC
Sure you can, at least with Nvidia: http://developer.nvidia.com/object/opengl_driver.html
However I think you missed tyrone’s point – which is to remind people Mesa isn’t the only game in town, so it definitely won’t take 5 years to get OpenGL 4.1 in Linux.
Soon you can:
http://www.phoronix.com/scan.php?page=news_item&px=ODQ2NQ
I actually can not do that. The official Linux drivers are always a few x.org or kernel versions behind of what I run.
I use the proprietary drivers, but Applications as a whole can’t rely on it, as many ATI users use the Free driver and Intel users still have 2.x, even with the official driver.
A little less than five years
http://developer.nvidia.com/object/opengl_driver.html
Edited 2010-07-31 19:54 UTC
I’m not sure how you think 3.3 or 4.1 would “be a better fit”. The best fit is the lowest version that does all the things they want it to do. Requiring newer versions for the sake of “newness” is idiotic.
OpenGl 3.0 is the biggest change. Going from 2.x to 3.0 is a lot harder than going from 3.0 to 4.1. OpenGL 3.0 was the big release that fixed the major architectural problems. All the releases after that were minor incremental improvements (just new extensions).
As I said in my previous comment, if KDE is smart (which I’m sure they are), they will only require the specific extensions that they use, not a certain OpenGL version. This means that, for example, an OpenGL 2.x driver that provides nearly all of the OpenGL 3.0 extensions except for one unimportant one (and thus it can’t be called OpenGL 3.0) that KDE doesn’t use, would still be able to run KDE SC. Mesa is already nearly to this point. Most of OpenGL 3.0 is implemented, it’s just missing a few parts.
“OpenGl 3.0 is the biggest change. Going from 2.x to 3.0 is a lot harder than going from 3.0 to 4.1”
yes but going from 2.x to 3.3 (an incremental release on the 3 series) would make sense to bring it to that level of fixes in the 3 series since the first 3.0 release was deemed “incomplete” by most OpenGL coders who work on games (and CAD and other stuff), myself included.
Going from 2 to 4 would have a huge leap, but going from 2 to 3.3 wouldn’t be terribly more difficult as the architecture is fundamentally the same as the previous few 3 series releases.
That’s true, but it’s not going to happen all it once. Each extension has to be implemented separately, and it makes a lot more sense to do the 3.0 extensions before the 3.3/4.1 extensions. However, once Mesa gets full OpenGL 3.0 support, I don’t think 3.3 will be far off (contrary to the people who say that it will take another five years).
From what I understand one of the benfits would be if one is using Mesa/LLVM the software path might actually be faster and smoother than if they tried to do all the compositing not using OpenGL.
The disappointing thing is that here we are discussing KDE 4.7 and they still haven’t removed HAL dependency – something that should actually be at the top of the priority list rather than an after thought.
It seems hal is still a gnome dependency for gnome, as well:
# yum remove hal
Dependencies Resolved
=======================================================
Package Arch Version Repository Size
=======================================================
Removing:
hal x86_64 0.5.14-3.fc13 @released/$releasever 1.2 M
Removing for dependencies:
banshee x86_64 1.6.1-3.fc13 @updates-testing 11 M
banshee-musicbrainz x86_64 1.6.1-3.fc13 @updates-testing 63 k
compiz-gnome x86_64 0.8.6-1.fc13 @released/$releasever 2.2 M
desktop-effects x86_64 0.8.7-2.fc13 @updates-testing 263 k
gdm x86_64 1:2.30.2-1.fc13 @released/$releasever 4.6 M
gdm-plugin-fingerprint x86_64 1:2.30.2-1.fc13 @released/$releasever 75 k
gdm-user-switch-applet x86_64 1:2.30.2-1.fc13 @released/$releasever 119 k
gnome-applets x86_64 1:2.30.0-1.fc13 @released/$releasever 15 M
gnome-packagekit x86_64 2.30.3-1.fc13 @updates-testing 9.0 M
gnome-panel x86_64 2.30.0-4.fc13 @updates-testing 9.8 M
gnome-power-manager x86_64 2.30.1-1.fc13 @released/$releasever 7.4 M
gnome-session x86_64 2.30.0-1.fc13 @released/$releasever 1.7 M
gnome-session-xsession x86_64 2.30.0-1.fc13 @released/$releasever 4.6 k
gnome-shell x86_64 2.29.1-4 @fedora 1.4 M
hal-info noarch 20090716-3.fc12 @released/$releasever 310 k
hal-storage-addon x86_64 0.5.14-3.fc13 @fedora 23 k
…
Transaction Summary
=======================================================
Remove 45 Package(s)
Reinstall 0 Package(s)
Downgrade 0 Package(s)
That sounds like a Archlinux issue more than a GNOME issue given that officially the only thing still requiring HAL these days GIMP (whose maintainers refuse to replace the HAL depedency with something else). What ever the case maybe HAL is an ugly translation layer that would be best replaced with udev/upower/udisks as soon as possible for the sake of creating a smoother desktop without the many hicks up I’ve faced at the hands of HAL bugginess.
yum is a Fedora/Red Hat command line package manager program, for RPMs.
Archlinux uses the pacman package manager program, which in turn uses .tgz files I think.
In the context of this text:
=======================================================
Package Arch Version Repository Size
=======================================================
The word “Arch” here is a column heading which lines up to ocurrences of the string “x86_64”, which is a reference to the CPU architecture targeted by the RPM files. The string “fc13”, which appears in the package names, is a reference to Fedora Core version 13.
Edited 2010-07-30 04:18 UTC
Yes I already know that so there is no need to be a condescending prick about it. I quickly had a look and missed the yum command at the top. I was under the impression that HAL dependencies had been removed based on the Ubuntu halsectomy page but it appears on closer inspection that it relies on custom patches rather than being part of the mainline.
No condescension was intended (I am only being careful to support my points, given the propensity for people to try to attack what I say, just as you have joined in). The only point I was intending to convey was that HAL is probably more entrenched than you may realise.
Edited 2010-07-30 06:37 UTC
Aren’t udev/udisks/upower Linux only? What about the BSDs?
BSD’s will need to implement their own Solid backend which uses BSD specific subsystems.
There is no such thing as a HAL dependency.
The whole point of Solid was to not depend on a certain hardware information system implementation, despite the HAL people claiming that HAL would be the way to go, even on other platforms such as OSX.
Luckily the people designing Solid didn’t buy into that and can now nicely create new backends based on udisk and friends.
There is a dependency as so far if you want the features such as thumb drivers automatically mounting or autodetection of hardware you need to have HAL install. You either have a full experience or a crippled experience so yes HAL is a dependency as so far as delivering a full desktop experience.
Hence I ask where is the udisk/upower/udev backends? It has been how long and we’re still waiting for them to make the move?
Edited 2010-07-30 13:55 UTC
Udisk – http://osdir.com/ml/kde-hardware-devel/2010-07/msg00017.html
Upower – http://osdir.com/ml/kde-hardware-devel/2010-04/msg00039.html
Thank you for the heads up – the last time I checked was in June and saw zero activity in regards to the udisks backend. Unfortunately the timetable for completion is about as clear as mud at the moment – it would be nice if at the very east someone created a sexy website and progress chart.
I’m tracking along the kernel development and things appear to be progressing nicely; it’ll be interesting to see the shape of KDE at around this time next year taking into account KOffice, K3B and Amarok.
KDE 4.5 is due to be released in the very near future.
Here are some screenshots for anyone who might be interested:
http://blog.abhitux.com/2010/07/kde-4-5-screenshot-tour/