om on the igep

**tripzero** · 10-06-2010, 12:19 AM

So firstly, this is what i did... Built a custom image of ubuntu 10.10 with the following:

Code:

sudo rootstock --fqdn ubuntu-igep --login kev --password secret --imagesize 4G --seed lxde,gdm,openssh-server,build-essential,libqt4-dev,network-manager --dist maverick

After that, I installed mono-runtime, libmono-sqlite2-cil, gtk-sharp, ndesk-dbus... grabbed the latest zip (please make deb packages for linux...).

Ran "mono Open\ Mobile.exe"

it brought up the UI however, I don't think gpu acceleration was enabled. It was unusable. Here's a pastie of top while idling:

Name: screenshot1.png
Views: 396
Size: 92.3 KB

Name: screenshot1.png
Views: 396
Size: 92.3 KB

Does OM have any sort of log file it uses? OM also complained that it couldn't connect to hal over dbus. both 10.04 and 10.10 have DeviceKit that replaces HAL.

That's my initial report for now. It's just a quick test before I go to bed. I'll run some other opengl demo's to make sure my drivers are properly installed/running.

EDIT: I ran some of the Qt QML demos and ran them. QML will use gpu/opengl acceleration if it's available and performance was surprising. I could get the cpu to shoot up to about 57% while flicking around the page enough to give someone a seizure. Because the cpu shot up, I'm not 100% sure i'm using the GPU via the drivers. I'll do more testing later. For now, sleep...

**justchat_1** · 10-06-2010, 02:09 AM

wow you work fast.... yea OM logs which graphics mode its running in right at the top of the debug log. That usually gives you a pretty good idea if its hardware acceleration or software. We do use device kit (based off of the udev running on 10.10-my development computer)....the error is a fallback when its detecting which services are running.

Debug log is located in the /home/UserName/.config/openMobile/Debug.txt.

edit:
any idea if thats an OpenGL or OpenGL ES system?

**tripzero** · 10-06-2010, 09:23 AM

Here's the debug output: http://pastebin.com/h97dCycu

as suspected it was using software rendering. On a funny note, om thought it was x86.

The GPU should be fully OpenGL ES 2.0 compatible.

**chunkyks** · 10-06-2010, 10:47 AM

Your load average doesn't correlate correctly with the cpu load . This is usually an indicator that you're io-bound somewhere.

Perhaps it was still in some phase where OM was sifting through the hard drive, and if you just give it a bit longer it'll settle down a bit?

Gary (-;

**tripzero** · 10-06-2010, 11:33 AM

Originally Posted by chunkyks

Your load average doesn't correlate correctly with the cpu load . This is usually an indicator that you're io-bound somewhere.

Perhaps it was still in some phase where OM was sifting through the hard drive, and if you just give it a bit longer it'll settle down a bit?

Gary (-;

I ran it for a few minutes just nosing around and checking random things on the system. maybe i'll do a strace on it and see what's going on...

**justchat_1** · 10-06-2010, 12:13 PM

its probably scanning the harddrive...it does a whole bunch of things when starting up....usually for only a second or two...but if 3/4 of the CPU is dealing with drawing it could take a good bit longer.

Yea up until recently the only options were x86 or x64 so if not one we assumed the other. The newest version uses our hardware framework so it should properly display ARM.

hmm..I was asking if the drivers were openGL or openGL ES (they may be openGL even though its an openGL ES card...which may or may not cause problems).

**tripzero** · 10-06-2010, 12:35 PM

Originally Posted by justchat_1

hmm..I was asking if the drivers were openGL or openGL ES (they may be openGL even though its an openGL ES card...which may or may not cause problems).

unsure... I'm afraid to install mesa-utils to get glxinfo/glxgears for fear that installing them may replace some files that the driver overrides (like nvidia, pvr installs it's own version of some EGL libraries). I'll buck up and install them tonight and paste the output.

**justchat_1** · 10-06-2010, 03:11 PM

Originally Posted by tripzero

unsure... I'm afraid to install mesa-utils to get glxinfo/glxgears for fear that installing them may replace some files that the driver overrides (like nvidia, pvr installs it's own version of some EGL libraries). I'll buck up and install them tonight and paste the output.

See if anythings changed in rev 393...i changed around alot of EGL stuff to see if that helps. I'm taking shots in the dark without something to actually test on...so it could be better or it could be worse.

**justchat_1** · 10-13-2010, 01:06 AM

Any updates on this?...some output from glxinfo would be a huge help

**tripzero** · 12-08-2010, 10:28 AM

i haven't tried the latest version of OM, but I did install the sgx drivers from the ubuntu repository to see if that made a difference. I verified that opengles2 works by running some of the sgx demos from their sdk. those ran without issue. OM produced the same result as before which leads me to think this is a GL vs GLES issue.

I'll try later versions later when I have more time...