OpenGL ES compatible desktop environments?

schmidtbag · 2013-10-22 15:48:54

I have a Beagleboard XM, an ARM platform with an SGX GPU that only supports OpenGL ES. Beagleboard's CPU isn't too shabby, but it immensely struggles with anything graphical. I've tried LXDE since that is very easy on system resources, but it has no GPU acceleration, making all programs run terribly slow. So what I'm wondering is, are there any DEs out there with OpenGL ES support, and would getting one of these DEs help with the performance issue (assuming I don't do any big special effects)? I heard Mutter (for GNOME 3) might but I can't seem to get a definite answer on that.

drcouzelis · 2013-10-22 16:03:31

schmidtbag wrote:

I've tried LXDE since that is very easy on system resources, but it has no GPU acceleration, making all programs run terribly slow.

I don't think anything runs faster than Openbox (or similar). Trying to find a graphical environment that needs higher hardware requirements (OpenGL / Accelerated graphics) seems counter intuitive to me.

What do you mean by "all programs run terribly slow"?

schmidtbag · 2013-10-22 16:21:09

drcouzelis wrote:

schmidtbag wrote:
I've tried LXDE since that is very easy on system resources, but it has no GPU acceleration, making all programs run terribly slow.
I don't think anything runs faster than Openbox (or similar). Trying to find a graphical environment that needs higher hardware requirements (OpenGL / Accelerated graphics) seems counter intuitive to me.
What do you mean by "all programs run terribly slow"?

Not necessarily - benchmarks have proven that some DEs with GPU accelerated compositing can perform slightly better than non-composited DEs (such as LXDE or XFCE without compiz). This is because non-composited DEs depend on the CPU to draw the screen, even if you have GPU drivers with openGL 2D and 3D support. The problem is X is taking up all the CPU cycles, so even if I use something heavier like GNOME 3 with GPU acceleration, CPU cycles won't be wasted on X.

To answer your question, programs really only run slow when they're refreshing the majority of the screen, such as scrolling the page in a web browser, or watching a video. If I run any CLI based programs, they perform great.

Last edited by schmidtbag (2013-10-22 16:22:46)

skottish · 2013-10-22 16:30:42

schmidtbag wrote:

To answer your question, programs really only run slow when they're refreshing the majority of the screen, such as scrolling the page in a web browser, or watching a video. If I run any CLI based programs, they perform great.

If you want to fix your actual problem, then you may want to let everyone know about your hardware, drivers, and how things are setup. It seems that you're trying fix symptoms and not working on the problem itself.

schmidtbag · 2013-10-22 16:38:08

skottish wrote:

schmidtbag wrote:
To answer your question, programs really only run slow when they're refreshing the majority of the screen, such as scrolling the page in a web browser, or watching a video. If I run any CLI based programs, they perform great.
If you want to fix your actual problem, then you may want to let everyone know about your hardware, drivers, and how things are setup. It seems that you're trying fix symptoms and not working on the problem itself.

I mentioned I have a Beagleboard-xM with an SGX GPU and I can only use openGL ES and I need a desktop environment compatible with OGLES. Based on that information, it is pretty safe to assume the platform is not x86 (it's ARM). That's all that's necessary to know. Specifying anything else is completely irrelevant, and I'm willing to start a fresh new install. The problem at hand is I'm not aware of any DEs (except maybe GNOME 3) that can utilize OGLES, so my way of working on the problem is to know which DE is proven to work with OGLES. Setting up beagleboard is a somewhat tedious process and I really don't feel like wasting time with trial and error.

drcouzelis · 2013-10-22 16:38:26

schmidtbag wrote:

programs really only run slow when they're refreshing the majority of the screen, such as scrolling the page in a web browser, or watching a video. If I run any CLI based programs, they perform great.

So... You need a web browser and a video player with OpenGL support then?

I'm still skeptical that changing the window manager will make that much of a difference.

schmidtbag · 2013-10-22 16:42:09

drcouzelis wrote:

schmidtbag wrote:
programs really only run slow when they're refreshing the majority of the screen, such as scrolling the page in a web browser, or watching a video. If I run any CLI based programs, they perform great.
So... You need a web browser and a video player with OpenGL support then?
I'm still skeptical that changing the window manager will make that much of a difference.

No, I need a way for X to draw the display without the CPU doing all of the work. The platform has a GPU, it's NOT openGL, but openGL ES. That limits what I can use in terms of a desktop environment. I could have a video player (or a web browser for that matter) OGLES compatible, but it will still run slow because X isn't GPU accelerated. By using a composited DE that is OGLES compatible, that should eliminate this issue.

Last edited by schmidtbag (2013-10-22 16:42:33)

drcouzelis · 2013-10-22 16:53:58

Good luck with it!

My coworker has a Beaglebone Black which is apparently similar hardware. He said yeah, the graphics are just slow.

Shark · 2013-10-22 16:57:16

KDE?

http://userbase.kde.org/Desktop_Effects … GL_Version

skottish · 2013-10-22 16:58:08

schmidtbag wrote:

skottish wrote:
schmidtbag wrote:
To answer your question, programs really only run slow when they're refreshing the majority of the screen, such as scrolling the page in a web browser, or watching a video. If I run any CLI based programs, they perform great.
If you want to fix your actual problem, then you may want to let everyone know about your hardware, drivers, and how things are setup. It seems that you're trying fix symptoms and not working on the problem itself.
I mentioned I have a Beagleboard-xM with an SGX GPU and I can only use openGL ES and I need a desktop environment compatible with OGLES. Based on that information, it is pretty safe to assume the platform is not x86 (it's ARM). That's all that's necessary to know. Specifying anything else is completely irrelevant, and I'm willing to start a fresh new install. The problem at hand is I'm not aware of any DEs (except maybe GNOME 3) that can utilize OGLES, so my way of working on the problem is to know which DE is proven to work with OGLES. Setting up beagleboard is a somewhat tedious process and I really don't feel like wasting time with trial and error.

Understood. I setup a netbook with an Intel 1.2GHz processor with poulsbo (GMA-500) using the xf86-video-modesetting driver and scrolling isn't an issue under XFCE. There is no hardware acceleration at all. That's why I posted what I did.

schmidtbag · 2013-10-22 17:09:50

Shark wrote:

KDE?
http://userbase.kde.org/Desktop_Effects … GL_Version

Hmm I wasn't aware there was a GLES alternative to kwin, I may have to check that out.

@skottish
I get the impression x86 is overall a lot more "prepared" to handle video commands than ARM. The additional hardware instructions and the extra 200MHz ought to be enough to go from annoyingly slow to "slow but very usable" (I highly doubt you have a smooth experience, but still good enough to not feel a need to complain).

@drcouzelis
Yes, the beaglebone black does have very similar hardware. The graphics are fine, the problem is linux largely revolves around openGL but not OGLES.

schmidtbag · 2013-10-26 04:03:07

So I have managed to confirm that GNOME 3 does support OGLES. However, unfortunately, beagleboard doesn't actually create a display when it boots up. GNOME starts and it shows up on my monitor, but it goes to fallback mode because it can't find display :0. The SGX drivers are proven working. Anybody know a way around this? If I can just get it to identify the screen then I'm sure everything will work fine.

Honestly, I don't even understand how gnome works at all if there isn't a display :0

I'm sure KDE will suffer the same issue.

Last edited by schmidtbag (2013-10-26 04:04:29)

jrussell · 2013-10-26 07:19:55

i3?

fjvinal · 2013-10-26 21:38:04

KDE works fine with OpenGL ES.
A script must be included in .kde4/env with the next content

#!/bin/bash
KDEWM=kwin_gles

schmidtbag · 2013-10-27 00:48:25

fjvinal wrote:

KDE works fine with OpenGL ES.
A script must be included in .kde4/env with the next content
#!/bin/bash
KDEWM=kwin_gles

Do you know for sure if this works on Beagleboard? Because GNOME 3 and compiz with XFCE have already failed due to that display :0 issue.

MrCode · 2014-01-14 21:15:06

Just my 2¢: even if you're using an OpenGL (ES) compositor, most programs that use a standard widget toolkit (Qt/GTK) still draw into their window buffers using the CPU most of the time. I'm not sure, maybe some 2D drawing ops are/can be GPU-accelerated (an NVIDIA driver update sped up Murrine gradients for me, for example), but AFAIK a lot of 2D drawing is still CPU-bound, whether it's directly to the screen or to an offscreen compositing buffer.

schmidtbag · 2014-01-14 21:19:29

MrCode wrote:

Just my 2¢: even if you're using an OpenGL (ES) compositor, most programs that use a standard widget toolkit (Qt/GTK) still draw into their window buffers using the CPU most of the time. I'm not sure, maybe some 2D drawing ops are/can be GPU-accelerated (an NVIDIA driver update sped up Murrine gradients for me, for example), but AFAIK a lot of 2D drawing is still CPU-bound, whether it's directly to the screen or to an offscreen compositing buffer.

I figured that was the case, and I was expecting as such. However, I figured the X process would take less of a hit on the CPU. On ARM platforms, sometimes just dragging a window around can eat up as much as 30% CPU. It's a bit difficult to know whether or not the X process is actually less CPU intensive with proper GPU drivers along with a properly rendered display.

Last edited by schmidtbag (2014-01-14 21:20:06)

jasonwryan · 2014-09-22 01:03:42

dukzcry wrote:

Null

Don't do that: https://wiki.archlinux.org/index.php/Fo … way_Street

ewaller · 2014-09-22 01:04:10

dukzcry wrote:

Null

We regard blanking posts as rude. It was also your only post and was months old.
That, and the message in your signature, gives me the idea you are not planning on being an active member of our community. Regardless, I'll keep your account active, but please consider this to be a warning.

Our policy

Arch Linux

#1 2013-10-22 15:48:54

OpenGL ES compatible desktop environments?

#2 2013-10-22 16:03:31

Re: OpenGL ES compatible desktop environments?

#3 2013-10-22 16:21:09

Re: OpenGL ES compatible desktop environments?

#4 2013-10-22 16:30:42

Re: OpenGL ES compatible desktop environments?

#5 2013-10-22 16:38:08

Re: OpenGL ES compatible desktop environments?

#6 2013-10-22 16:38:26

Re: OpenGL ES compatible desktop environments?

#7 2013-10-22 16:42:09

Re: OpenGL ES compatible desktop environments?

#8 2013-10-22 16:53:58

Re: OpenGL ES compatible desktop environments?

#9 2013-10-22 16:57:16

Re: OpenGL ES compatible desktop environments?

#10 2013-10-22 16:58:08

Re: OpenGL ES compatible desktop environments?

#11 2013-10-22 17:09:50

Re: OpenGL ES compatible desktop environments?

#12 2013-10-26 04:03:07

Re: OpenGL ES compatible desktop environments?

#13 2013-10-26 07:19:55

Re: OpenGL ES compatible desktop environments?

#14 2013-10-26 21:38:04

Re: OpenGL ES compatible desktop environments?

#15 2013-10-27 00:48:25

Re: OpenGL ES compatible desktop environments?

#16 2014-01-14 21:15:06

Re: OpenGL ES compatible desktop environments?

#17 2014-01-14 21:19:29

Re: OpenGL ES compatible desktop environments?

#18 2014-09-22 01:03:42

Re: OpenGL ES compatible desktop environments?

#19 2014-09-22 01:04:10

Re: OpenGL ES compatible desktop environments?

Board footer