Linked by David Adams on Thu 29th Jul 2010 17:44 UTC, submitted by Debjit
Graphics, User Interfaces 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
Order by: Score:
More importantly
by Narishma on Thu 29th Jul 2010 18:22 UTC
Narishma
Member since:
2005-07-06

To my knowledge, OpenGL 3.0 isn't supported by any open source graphics drivers at the moment.

Reply Score: 4

RE: More importantly
by Morty on Thu 29th Jul 2010 18:59 UTC in reply to "More importantly"
Morty Member since:
2005-07-06

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.

Reply Score: 4

RE: More importantly
by Zifre on Thu 29th Jul 2010 19:13 UTC in reply to "More importantly"
Zifre Member since:
2009-10-04

To my knowledge, OpenGL 3.0 isn't supported by any open source graphics drivers at the moment.

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).

Reply Score: 4

3.0 or 3.3?
by poundsmack on Thu 29th Jul 2010 19:25 UTC
poundsmack
Member since:
2005-07-13

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

Reply Score: 1

RE: 3.0 or 3.3?
by Elv13 on Thu 29th Jul 2010 19:57 UTC in reply to "3.0 or 3.3?"
Elv13 Member since:
2006-06-12

Yea, but full 3.3 support is many years away, full 4.1 is probably 5 years away.

Reply Score: 1

RE[2]: 3.0 or 3.3?
by Zifre on Fri 30th Jul 2010 00:32 UTC in reply to "RE: 3.0 or 3.3?"
Zifre Member since:
2009-10-04

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.

Reply Score: 2

RE[2]: 3.0 or 3.3?
by tyrione on Fri 30th Jul 2010 07:16 UTC in reply to "RE: 3.0 or 3.3?"
tyrione Member since:
2005-11-21

Yea, but full 3.3 support is many years away, full 4.1 is probably 5 years away.


Cause you couldn't use official binaries from Nvidia or AMD. Nope! Can't do that!

Reply Score: 3

RE[3]: 3.0 or 3.3?
by lemur2 on Fri 30th Jul 2010 10:15 UTC in reply to "RE[2]: 3.0 or 3.3?"
lemur2 Member since:
2007-02-17

"Yea, but full 3.3 support is many years away, full 4.1 is probably 5 years away.


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

Reply Score: 2

RE[4]: 3.0 or 3.3?
by Gusar on Fri 30th Jul 2010 15:18 UTC in reply to "RE[3]: 3.0 or 3.3?"
Gusar Member since:
2010-07-16

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.

Reply Score: 1

RE[4]: 3.0 or 3.3?
by vivainio on Sat 31st Jul 2010 20:07 UTC in reply to "RE[3]: 3.0 or 3.3?"
vivainio Member since:
2008-12-26

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.


Soon you can:

http://www.phoronix.com/scan.php?page=news_item&px=ODQ2NQ

Reply Score: 2

RE[3]: 3.0 or 3.3?
by Bill Shooter of Bul on Fri 30th Jul 2010 15:35 UTC in reply to "RE[2]: 3.0 or 3.3?"
Bill Shooter of Bul Member since:
2006-07-14

I actually can not do that. The official Linux drivers are always a few x.org or kernel versions behind of what I run.

Reply Score: 2

RE[3]: 3.0 or 3.3?
by Elv13 on Fri 30th Jul 2010 22:02 UTC in reply to "RE[2]: 3.0 or 3.3?"
Elv13 Member since:
2006-06-12

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.

Reply Score: 2

RE[2]: 3.0 or 3.3?
by aaronb on Sat 31st Jul 2010 19:53 UTC in reply to "RE: 3.0 or 3.3?"
aaronb Member since:
2005-07-06

A little less than five years ;)

http://developer.nvidia.com/object/opengl_driver.html

Edited 2010-07-31 19:54 UTC

Reply Score: 2

RE: 3.0 or 3.3?
by Zifre on Fri 30th Jul 2010 00:29 UTC in reply to "3.0 or 3.3?"
Zifre Member since:
2009-10-04

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

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.

Reply Score: 3

RE[2]: 3.0 or 3.3?
by poundsmack on Fri 30th Jul 2010 16:13 UTC in reply to "RE: 3.0 or 3.3?"
poundsmack Member since:
2005-07-13

"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.

Reply Score: 2

RE[3]: 3.0 or 3.3?
by Zifre on Fri 30th Jul 2010 20:27 UTC in reply to "RE[2]: 3.0 or 3.3?"
Zifre Member since:
2009-10-04

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).

Reply Score: 2

Comment by kaiwai
by kaiwai on Fri 30th Jul 2010 00:29 UTC
kaiwai
Member since:
2005-07-06

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.

Reply Score: 3

RE: Comment by kaiwai
by mojo-raisin on Fri 30th Jul 2010 03:33 UTC in reply to "Comment by kaiwai"
mojo-raisin Member since:
2010-07-30

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)

Reply Score: 4

RE[2]: Comment by kaiwai
by kaiwai on Fri 30th Jul 2010 03:48 UTC in reply to "RE: Comment by kaiwai"
kaiwai Member since:
2005-07-06

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.

Reply Score: 1

RE[3]: Comment by kaiwai
by lemur2 on Fri 30th Jul 2010 04:12 UTC in reply to "RE[2]: Comment by kaiwai"
lemur2 Member since:
2007-02-17

That sounds like a Archlinux issue more than a GNOME issue


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

Reply Score: 4

RE[4]: Comment by kaiwai
by kaiwai on Fri 30th Jul 2010 05:40 UTC in reply to "RE[3]: Comment by kaiwai"
kaiwai Member since:
2005-07-06

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.

Reply Score: 2

RE[5]: Comment by kaiwai
by lemur2 on Fri 30th Jul 2010 06:35 UTC in reply to "RE[4]: Comment by kaiwai"
lemur2 Member since:
2007-02-17

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

Reply Score: 3

RE[3]: Comment by kaiwai
by chmeee on Fri 30th Jul 2010 12:10 UTC in reply to "RE[2]: Comment by kaiwai"
chmeee Member since:
2006-01-10

Aren't udev/udisks/upower Linux only? What about the BSDs?

Reply Score: 2

RE[4]: Comment by kaiwai
by kaiwai on Fri 30th Jul 2010 14:29 UTC in reply to "RE[3]: Comment by kaiwai"
kaiwai Member since:
2005-07-06

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.

Reply Score: 2

RE: Comment by kaiwai
by anda_skoa on Fri 30th Jul 2010 11:09 UTC in reply to "Comment by kaiwai"
anda_skoa Member since:
2005-07-07

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.


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.

Reply Score: 3

RE[2]: Comment by kaiwai
by kaiwai on Fri 30th Jul 2010 13:53 UTC in reply to "RE: Comment by kaiwai"
kaiwai Member since:
2005-07-06

There is no such thing as a HAL dependency.


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.

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.


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

Reply Score: 2

RE[4]: Comment by kaiwai
by kaiwai on Fri 30th Jul 2010 14:18 UTC in reply to "RE[3]: Comment by kaiwai"
kaiwai Member since:
2005-07-06



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.

Reply Score: 2

Slightly OT, but it might be of interest
by lemur2 on Fri 30th Jul 2010 03:28 UTC
lemur2
Member since:
2007-02-17

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/

I found KDE 4.5 RC2 a lot more stable than I expected it to be(for a testing version). Though there are not as many ‘new’ features as usually there are with a major KDE release,the amount of stability is very impressive. This version will surely succeed in silencing the Kritics who are still calling KDE 4 slow,buggy and hard to use. Also when it comes to usability, devs have paid attention to those ‘little things’ which matter. KDE 4.5 is surely the desktop of the future, in case you haven’t switched what are you waiting for?

Reply Score: 3