You are not logged in.
I wonder if with Arch KDE SC 4.7 packages there will be an option to choose package with OpenGL ES 2.0 backend as the KWin backend chosen at compile-time, as suggested in this post by leading KWin developer:
On Mesa enabled desktop systems there is also the possibility to go a step further and leave GLX completely behind by compiling KWin for OpenGL ES/EGL only. My personal experience is that it is often a much better experience to use the OpenGL ES build. If you compile KWin from sources ensure that the OpenGL ES 2.0 and EGL development libraries are around and enable the CMake option “KWIN_BUILD_WITH_OPENGLES”. If everything is setup correctly, CMake will tell you “Compiling KWin for mobile”.
Offline
is not enabled. http://projects.archlinux.org/svntogit/ … k/PKGBUILD
Give what you have. To someone, it may be better than you dare to think.
Offline
But can additional package with this option enabled be made? Like Kubuntu guys did, as Gräßlin wrote in his post?
Offline
Well, the kde guys decided to create one big kdebase-workspace package which also contains kwin. Building this package twice for this does not sound that sane. But I guess we might want to test the gl es version first. There might be good reasons why it's disabled by default.
Offline
Well, the kde guys decided to create one big kdebase-workspace package which also contains kwin. Building this package twice for this does not sound that sane. But I guess we might want to test the gl es version first. There might be good reasons why it's disabled by default.
AFAIK GLES support can be patchy especially in closed drivers, Martin Gräßlin has recommended that distros provide two versions of kwin to allow people to test but as you say that might not be all that practical for arch. It a shame that his changes to allow building a kwin_gles binary alongside the ordinary kwin didn't make it to 4.7 because that would seem to be an ideal way to allow testing without breaking peoples' systems.
Offline
Pierre wrote:Well, the kde guys decided to create one big kdebase-workspace package which also contains kwin. Building this package twice for this does not sound that sane. But I guess we might want to test the gl es version first. There might be good reasons why it's disabled by default.
AFAIK GLES support can be patchy especially in closed drivers, Martin Gräßlin has recommended that distros provide two versions of kwin to allow people to test but as you say that might not be all that practical for arch. It a shame that his changes to allow building a kwin_gles binary alongside the ordinary kwin didn't make it to 4.7 because that would seem to be an ideal way to allow testing without breaking peoples' systems.
Wouldn't this be solved by someone just creating an AUR package for it, for those that want it?
Offline
Well, the kde guys decided to create one big kdebase-workspace package which also contains kwin. Building this package twice for this does not sound that sane. But I guess we might want to test the gl es version first. There might be good reasons why it's disabled by default.
But why it doesn't sound sane to have two versions of this package in the repos? In light of Martin Gräßlin's statement that he strongly recommends to use OpenGL ES 2.0 version for those whose drivers allow it (i.e. most people)? Another several dozens of MB do not look like an unbearable burden for the repos.
Or maybe splitting of kdebase-workspace can be considered in view of this issue? Because recompiling entire kdebase-workspace locally to enable this option, even if someone makes an AUR package, will be a pain, especially on netbooks.
Offline
SO wait, this is one of the features in this release but its not enabled in Arch??
Certified Android Junkie
Arch 64
Offline
SO wait, this is one of the features in this release but its not enabled in Arch??
Do you really need this or do you know, what it does?
Offline
smakked wrote:SO wait, this is one of the features in this release but its not enabled in Arch??
Do you really need this or do you know, what it does?
KWin performance becomes better, as stated by KWin leading developer:
My personal experience is that it is often a much better experience to use the OpenGL ES build.
And KWin performance improvements are really much welcome, especially on netbooks where it is little bit sluggish.
Offline
Do you really need this or do you know, what it does?
It's a must-have feature, because of truly BIG performance difference on powersaving GPU modes.
ArchLinux x86_64 (passively cooled): Xeon E3 1230v2 - 32GB - GTX1050Ti KalmX - Samsung 850 EVO 1TB - 3x2TB Seagate - Creative X-Fi Titanium - Cheiftec GPS-500C
ArchLinux x86_64 (FrankenPad T420): i7 2720QM - 16GB - NVS 4200M - Samsung 840 EVO 1TB - FullHD IPS mod - Intel 7260AC - Sierra Wireless MC7304
Offline
Its just that i thought that this was the biggest thing in this release of KDE , thats what all the developers were talking about ?
Certified Android Junkie
Arch 64
Offline
Its just that i thought that this was the biggest thing in this release of KDE , thats what all the developers were talking about ?
Well its certainly the biggest thing for KWin, but even if Arch doesn't get it this time by 4.8 it should be possible to build both versions in one package.
Offline
smakked wrote:Its just that i thought that this was the biggest thing in this release of KDE , thats what all the developers were talking about ?
Well its certainly the biggest thing for KWin, but even if Arch doesn't get it this time by 4.8 it should be possible to build both versions in one package.
I don't really see where is the problem in providing additional OpenGL ES 2.0 kdebase-workspace package in [extra]. Are several dozens of MB that much that repos can't bear the addition of it?
Even better would be splitting kdebase-workspace and providing two separate kwin packages as Kubuntu guys do, but it's the choice for developers.
Offline
As an avid KDE users (and sluggish netbook owner), I'll be following this topic closely. If the developers choose not to implement these feature in the repos, I'll likely be providing a prebuilt package for this feature set. It's silly to require users that most require this feature (those on underpowered machines) to build the somewhat hefty kdebase-workspace. In short, a package will be available for OpenGL ES 2.0 support one way or another.
Offline
I tried it with fglrx and it is unable to activate the effects. Probably because it doesn't properly support egl.
But with r600g and mesa from git it works quite well. But the performance doesn't seem to be really as good as I expected. Maybe mesa's gles2 isn't as good yet?
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
Hi all, I disabled Open GL ES because on some proprietary hardware it's unable to enable compositing (works fine here on an Intel). Anyway, I'll push soon a kdebase-workspace 4.7.0-3 in [kde-unstable] with Open GL ES enabled to get some extra-feedback.
Offline
bash;
Is there any chance of a kdebase-workspace-gles package (which provides+conflicts the ordinary kdebase-workspace package) with GLES enabled being added to [extra] with the rest of 4.7?
This would allow people to choose which type of compositing they would like without adding unstable repos (I assume [kde-unstable] will eventually be providing 4.8 betas/rcs), recompiling large parts of kde or breaking existing setups which don't support GLES.
Offline
@George
I guess is better to disable (or enable) Open GL ES in kdebase-workspace and upload a PKGBUILD on AUR with Open GL ES enabled (or disabled).
Since Kwin + GLES works on _some_ systems, but Kwin + OpenGL works on _most_ system I guess I'll disable it in the official kdebase-workspace. Anyway, I'm open to hints.
BTW, I don't plain to keep kdebase-workspace (built with GLES) on [kde-unstable] until 4.8, but just for a couple of days; then we'll decide if it goes in [extra] or dropped.
Offline
bash;
I have a feeling we may be misunderstanding each other here; I'm not suggesting enabling GLES in the existing kdebase-workspace package but asking if you'd consider creating a separate kdebase-workspace-gles package with gles enabled. This would mean two different kdebase-workspace packages in extra one with the old OpenGL kwin and the other with the new GLES kwin. I have a feeling the I've read somewhere that this "solution" would be against Arch's policy but you're in a better position to know that than I am.
EDIT: Having re-read your post, it appears that I am the on doing the misunderstanding. If your opinion is that there should only be one kdebase-workspace package in the repos then thats obviously up to you. As I said I don't think enabling gles by default would work now, much better to wait for support for building both to appear in 4.8,
Last edited by George (2011-07-28 15:55:35)
Offline
@George
I guess is better to disable (or enable) Open GL ES in kdebase-workspace and upload a PKGBUILD on AUR with Open GL ES enabled (or disabled).Since Kwin + GLES works on _some_ systems, but Kwin + OpenGL works on _most_ system I guess I'll disable it in the official kdebase-workspace. Anyway, I'm open to hints.
BTW, I don't plain to keep kdebase-workspace (built with GLES) on [kde-unstable] until 4.8, but just for a couple of days; then we'll decide if it goes in [extra] or dropped.
It is known that some people won't have GLES version working, on systems with proprietary drivers. So most probably the OpenGL version will be needed to stay in extra.
But the problem is that having GLES package is most important on Atom netbooks, where Intel drivers support GLES. And if you choose that GLES will be supported only through AUR, it will mean that we will need to compile kdebase-workspace on netbooks, which is a real pain.
So maybe you can consider having both kdebase-workspace and kdebase-workspace-gles in extra?
Last edited by jerf (2011-07-28 16:09:58)
Offline
I just tested the gl es version and it wont work with the nvidia driver.
Startup mesages are:
libEGL warning: DRI2: failed to authenticate
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/xorg/modules/dri)
libEGL warning: DRI2: failed to open swrastg (search paths /usr/lib/xorg/modules/dri)
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe
OpenGL version string: OpenGL ES 2.0 Mesa 7.11-rc3
Driver: LLVMpipe
GPU class: Unknown
OpenGL version: 2.0
Mesa version: 7.11
X server version: 1.10.3
Linux kernel version: 3.0
Direct rendering: yes
Requires strict binding: yes
GLSL shaders: no
Texture NPOT support: yes
kwin(2162): Required extension EGL_KHR_image_pixmap not found, disabling compositing
kwin(2162): Failed to initialize compositing, compositing disabled
kwin(2162): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up
Using the regular OpenGL version from testing gives me the following output:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 460/PCI/SSE2
OpenGL version string: 4.1.0 NVIDIA 275.21
OpenGL shading language version string: 4.10 NVIDIA via Cg compiler
Driver: NVIDIA
Driver version: 275.21
GPU class: GF100
OpenGL version: 4.1
GLSL version: 4.10
X server version: 1.10.3
Linux kernel version: 3.0
Direct rendering: yes
Requires strict binding: no
GLSL shaders: yes
Texture NPOT support: yes
Offline
Pierre;
If you are interested the GLES version you could try using the nouveau driver as that is what it was developed using. On the other hand if you were simply reporting that it doesn't work and don't have any particular interest in GLES please ignore this.
Offline
If this means that GL ES simply wont work with the nvidia driver we cannot enable it by default. Or is there anything I miss here? I thought ES was just a subset of OpenGL.
The nouveau driver doesn't support my card yet. And even when it will, I guess the nvidia blob using GL2 will still be faster than nouveau and GL ES.
Offline
If this means that GL ES simply wont work with the nvidia driver we cannot enable it by default. Or is there anything I miss here? I thought ES was just a subset of OpenGL.
Yes thats right, the nvidia driver doesn't AFAIK support GLES.
The nouveau driver doesn't support my card yet. And even when it will, I guess the nvidia blob using GL2 will still be faster than nouveau and GL ES.
The only thing that might be in nouveau's favour is that I seem to recall reading that the GLES code is much cleaner than the ordinary GL code.
Offline