Hello all,

I'm trying to port some existing quake1 source code which support Open GL ES to my efika smartbook.
After some days & hacks (none GL ES source were for plain linux but more for iphone, android and other small linux based game console), i've been able to compile it and make it run, but strangely almost all texture are missing.

Here is some photo:





Moreover the smartbook is freezing very easily at exit...

I tried with a software rendering Open GLES 1 library (the mesa one available in Ubuntu) and it's working quite good: texture are here despite some do have glitches:


(And of course it's slow as hell)

The quake source use a kind of wrapper (nanogl) to emulate a Open GL API into a Open GL ES 1 one.

I'm still using september image. Imx Open GL ES 1 has 20110310 date in Ubuntu repository.

Is this lib version & system know to have a good GL ES 1 render quality ?

Thanks

Hi Chips,

I have never tried getting quake1 running on the Efikas (we prefer q3 here ;) and I'm running a newer revision of the GLES stack, but I don't see a reason why q1 should not run nicely on the Efikas - it's really a matter of OGL mappings (as I don't remember the 20110310 GLES stack being unable to show textures per se). A couple of questions re the issues you're getting there:

* Can you give more details on the means you used to get the OGL-to-GLES mapping - which version of nanoGL is that? If it's customized and you have it locally, can you please post it somewhere where we can see it? If it's a 'stock' version - any link to a repo would do.

* Have you tried looking at the gl error codes (glGetError) at code locations which try to specify a texture object - anything along the glBindTexture + glTex(Sub)Image* gl calls?

* Can you, please, give a quick uname -a just to verify what kernel version you're running there.

Thanks,
martin

Thanks for thoses hints. I need to learn some bits of open gl es...

I have same problem with debian+3d image. So i don't think it's my setup. I started from the wiz/canoo source code with the included nanogl .I forget where did i get original source...
My kernel: Linux chips-laptop 2.6.31.14-26-efikamx #4 Mon Oct 3 23:41:32 CEST 2011 armv7l GNU/Linux

I switched to glesquake source (no GL ES wrapper here but instead an in-deph porting) and this time I got a working Quake 1 :) ... which is slow :( I dunno why.

I will continue to debug... and my plan is to continue with q2 and of course q3 which is more the goal. Did you get a working q3 on efika ?

So the issues were a matter of GL-to-GLES mapping, as expected. Ok, now that you have proper output we can focus on more interesting things ; )

Speed-wise, I don't know what numbers you are getting there (some timedemo figures would do), but a couple of general remarks again:

* While the z430 GPU in the Efikas has impressive ALU power, it's not exactly breaking records in dumb pixel output. The absolute pixel rate maximum of the GPU is 166MPix/s (200MPix/s on the imx53). As q1/2/3 are all dated tech not using any fancy shaders (technically not using any shaders themselves, but still using shaders via the GLESv1 emulation), z430's advantages are somewhat wasted with that software. Bottomline being, don't go overboard with the resolution settings in quake - staying within sane bounds, i.e. 640x480 through 850x480 (AKA widescreen 480p) should give you best results.

* I don't remember if the Xorg driver in the 20110310 image had that particular issue, but at one point in the past the Xorg driver was taking a suboptimal path when doing eglBufferSwap, so regardless how quick the GPU would be at rendering a frame, the posting of that frame on screen took abnormally long (and maxed out the CPU usage along the way). The good news is, you can easily check if you have that version: run simple_draw (should be in /usr/bin) - you should be getting an fps in the 150-ish range (140-150) if the Xorg driver does not have the issue. Apropos, what is your desktop color setup? (run xdpyinfo, screen #0 section)

Mais oui : )

The version we have running is a quick adaptation of OpenPandora's version which, on its turn, is a port of an iphone q3, IIRC. Essentially, it's what you call an in-depth GLESv1 port (no 3rd party GL wrappers).

Cheers,
martin

I just did an install of maverick-20111010 version.
Nothing improved for Quake, however internet browsing seems slightly faster...

simple_draw tool seems not present in default ubuntu software.
screen #0 is 1024x600 and depth of root window is 16 planes.

I just added sound (but it has kind of overflow/underflow) and control (at least keyboard works but the grab fails at init from time to time...).

If some of you want to try it, you can find the source code:
http://darcelf.free.fr/linux_glesquake_v0_1.tgz
Dependencies are indicated in INSTALL.TXT. Then just do a make.

Between a get a lot of freeze with it. Even with glmark-es2, which has graphicals glitch too. Is my smartbook faulty ?

Why not releasing your q3 version ?

Ok, chances are you don't have the faulty xorg version, but again, what are the performance brackets we are talking about here?
My apologies, I thought we had it available off-the-shelf. Ok then, grab the Genesi GLES testsuite from here and give a go to one of its testcases named 'basic': Thanks, though I currently can't make any promises about when I will be able to look at that.
Not necessarily. Chances are your smartbook is suffering from a known GPU kernel issue, which occurred intermittently on kernel versions between 2.6.31.14.23 and 2.6.31.14.26, IIRC. While not necessarily a kernel's fault, issue was related to the enabling of the GPUs MMU in those kernel versions. I'd advise you to switch to a newer kernel.
Because it was a quick-n-dirty adaptation, which was done for a particular demo purpose, and hasn't received much attention ever since. But if the interest is there (as you show), we can pretty it up and release it. Unfortunately, the current GLESv1 stack has a stability issue with what seems to be an intermittent buffer overrun, which occasionally leads GLESv1 clients to crash with a heap corruption. So GLESv1 is somewhat unstable right now, and I'm not sure how much effort could be justified toward shaping up quake ports versus trying to actually fix that stack's issue.

Cheers,
martin

There are two problems here with glmark-es2 - older versions (like the one in the Maverick repo) have a definite glmark bug where it doesn't clear the depth buffer properly, so it draws cats inside out for example.

The other issue is some kind of weird memory consistency error with the GPU MMU where for instance the cats head and the horses legs "spread" to the top corner of the window. Disabling the GPU MMU does fix that.

We're working on a new memory manager for the GPU driver, it should fix everything and then one.. last.. Maverick image.

_________________
Matt Sealey

I got some time so i did some benchmark.
Here is what i got from timedemo command:
With latest ubuntu (+ latest kernel): 8.7 fps
with latest debian armhf: 9.4 fps

That quite low framerate.

In order to make it works in debian armhf i needed modify some part. File is here:
http://darcelf.free.fr/gl_vidlinuxesgl.cpp

Quake 3 source code used for rasperry is available here(should have gles):
git clone https://github.com/raspberrypi/quake3.git
I will look if i can make it works on genesi...