gles without x11

[Rob Clark]

Hi, I figured a few of you might be interested in this..

I created a simple spinning cube app running on kms/gbm. The idea is
basically the same as:

http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_

but updated to use gbm_surface:

git://github.com/robclark/kmscube.git
https://github.com/robclark/kmscube

This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
wayland patches so it should work as soon as these wayland patches are
merged and PPA is updated.

Perhaps someday I'll make it more fancy to detect hotplug, support
multiple displays, configurable resolution, overlay planes, etc.

BR,
-R

[ChuckMcM]

Very nice. Very nice indeed. 

[Andre Renaud]

Hi Rob,

> This works on my laptop (i915, w/ latest mesa) and on the panda w/ pvr
> wayland patches so it should work as soon as these wayland patches are
> merged and PPA is updated.

You talk about wayland here, but this doesn't seem to really depend on
it. What patches do you mean for wayland that are a requirement for
this demo? It would appear that this is only dependant on libdrm, and
mesagl.

Regards,
Andre

[Rob Clark]

well, the dependency is on gbm support in the gl driver, which is part
of the wayland patches (since weston compositor also uses gbm+kms, in
a similar way to this test app)

BR,
-R

> Regards,
> Andre

[Andre Renaud]

> well, the dependency is on gbm support in the gl driver, which is part
> of the wayland patches (since weston compositor also uses gbm+kms, in
> a similar way to this test app)

Right, I think I understand - can you point me to where those patches
are sitting at the moment?

Thanks,
Andre

[Rob Clark]

unfortunately, no.. they are patches on the closed src pvr driver
code, so they probably wouldn't do you much good. But I'll work with
the folks who maintain the OMAP PPA to try to get the updated drivers
released soon

BR,
-R

> Thanks,
> Andre

[Andre Renaud]

> unfortunately, no.. they are patches on the closed src pvr driver
> code, so they probably wouldn't do you much good. But I'll work with
> the folks who maintain the OMAP PPA to try to get the updated drivers
> released soon

Ah, sorry, I hadn't thought that all the way through. I was thinking
of the MesaGL stuff, not the SGX/PVR stuff.

Thanks,
Andre

[Dan MacDonald]

This sounds very cool Rob.

I've been wondering about all your PVR patches - how does it work? Do
(some/most/a few) of your patches make it upstream? If so, do you
retain any ownership or do IMG repay you/TI or do they automatically
gain the rights or what?

Although I'm as excited about seeing the follow up to Pandaboard as
anyone I'm worried that if it gets released too soon the bulk of the
OMAP teams attention will go on that when we don't have a stable DDX
driver for Panda Precise yet although I expect the follow up to Panda
will just be using a faster version of the PVR so it will be largely
the same driver if not the same?

I filed a few bug reports about the current precise driver on the PPA
a month or so ago and not one of them has had any reply yet - I should
hope someone has at least read them?

[Nicolas Dechesne]

On Tue, Sep 4, 2012 at 8:46 AM, Dan MacDonald <all...@gmail.com> wrote:
> I filed a few bug reports about the current precise driver on the PPA
> a month or so ago and not one of them has had any reply yet - I should
> hope someone has at least read them?

hmm... we all see them... we are just fighting against the clock...
can you please highlight the one which are really critical to you
which you opened?

[Dan MacDonald]

Hi ndec!

Hehe! I'd held out chasing you up on my bug reports as I was expecting
a PPA update soon and then a few hours after I do the update arrives
so I'll report back to you when I've tried the latest which prob won't
be until the weekend now.

All of the bugs I've reported for the OMAP PPA are pretty much equally
important but seeing as there seems to be an increasing demand for
OpenGLES on here the bug that causes a black screen when starting a
full-screen OGLES/EGL app is likely the most visible but hopefully
thats no longer the case now.

[Rob Clark]

fyi, the stuff you need is now in the "trunk" PPA, thanks to Xav!

So for those interested in living on the bleeding edge:

sudo add-apt-repository ppa:tiomap-dev/omap-trunk
sudo aptitude update
sudo aptitude upgrade

or apt-get if you prefer..

probably want to reboot at this point if kernel was updated in the process

sudo aptitude install libgbm1 libgbm-dev libgles2-sgx-omap4-dev
libegl1-sgx-omap4-dev libgles1-sgx-omap4-dev

then if you want to take it for a spin:

git://github.com/robclark/kmscube.git
cd kmscube
./autogen.sh && make && ./kmscube

You should be able to run kmscube as your normal user (not root)
assuming your user is in 'video' group. Of course, stop x11 first if
it was running.

Weston itself isn't in the PPA, but you can build latest from git if
you want to try that too

BR,
-R

[ChuckMcM]

No joy, what  I've got:

cmcmanis@pandaboard:~/hacks/kmscube$ ./kmscube

trying to load module i915...failed.

trying to load module radeon...failed.

trying to load module nouveau...failed.

trying to load module vmwgfx...failed.

trying to load module omapdrm...success.

failed to load module: /usr/lib/gbm/gbm_dri.so: cannot open shared object file: No such file or directory

failed to load module: /usr/lib/gbm/gbm_gallium_drm.so: cannot open shared object file: No such file or directory

loaded module: gbm_pvr.so

gbmpvr: screen_create:57: dev=0x122a2b8

gbmpvr: pvr_device_create:328: dev=0x122a2b8, fd=3

gbmpvr: gbm_pvr_surface_create:215: dev=0x122a2b8, width=1920, height=1080, format=875713112, flags=5

gbmpvr: gbm_pvr_bo_create:169: dev=0x122a2b8, width=1920, height=1080, format=875713112, usage=5

gbmpvr: gbm_pvr_bo_create:169: dev=0x122a2b8, width=1920, height=1080, format=875713112, usage=5

gbmpvr: WSEGL_IsDisplayValid:77: hNativeDisplay=0x122a2b8

gbmpvr: GetDisplay:32: hNativeDisplay=0x122a2b8

gbmpvr: WSEGL_InitialiseDisplay:106: wsdpy=0xb6c750c4, refcnt=0

gbmpvr: OpenDisplay:140: wsdpy=0xb6c750c4

gbmpvr: OpenPVR:149: wsdpy=0xb6c750c4

PVR:(Error): PVRSRVBridgeCall: Failed to access device.  Function ID:3223086848 (Bad address). [294, /pvr_bridge_u.c]

PVR:(Error): PVRSRVEnumerateDevices: BridgeCall failed [523, /bridged_pvr_glue.c]

PVR:(Error): PVRSRVConnect: Unable to enumerate devices. [380, /bridged_pvr_glue.c]

gbmpvr: ERROR: OpenPVR:153: PVR2DCreateDeviceContext failed

gbmpvr: ClosePVR:219: wsdpy=0xb6c750c4

gbmpvr: CloseDisplay:198: wsdpy=0xb6c750c4

failed to initialize

failed to initialize EGL

cmcmanis@pandaboard:~/hacks/kmscube$ lsmod

Module                  Size  Used by

omapdrm_pvr           336597  0

omapdce                23304  0

omaprpc                18485  0

omap_remoteproc         5503  0

rpmsg_resmgr_common     3281  0

remoteproc             25653  2 omap_remoteproc,rpmsg_resmgr_common

dm_crypt               18016  0

omap_rpmsg_resmgr       9585  0

rpmsg_resmgr            7049  2 rpmsg_resmgr_common,omap_rpmsg_resmgr

virtio_rpmsg_bus       11932  3 omapdce,omaprpc,rpmsg_resmgr

virtio                  5489  2 remoteproc,virtio_rpmsg_bus

virtio_ring             8364  2 remoteproc,virtio_rpmsg_bus

wl12xx                 13333  0

wlcore                163942  1 wl12xx

mac80211              529582  1 wlcore

cfg80211              204323  2 wlcore,mac80211

nfsd                  258336  2

nfs                   319022  2

lockd                  73315  2 nfsd,nfs

auth_rpcgss            40066  2 nfsd,nfs

nfs_acl                 2895  2 nfsd,nfs

sunrpc                241955  17 nfsd,nfs,lockd,auth_rpcgss,nfs_acl

wlcore_sdio             3701  0

gpio_keys               9031  0

leds_gpio               3788  0

usbhid                 38793  0

hid                    76894  1 usbhid

cmcmanis@pandaboard:~/hacks/kmscube$ uname -a

Linux pandaboard 3.4.0-1486-omap4 #10-Ubuntu SMP PREEMPT Thu Sep 6 15:08:52 UTC 2012 armv7l armv7l armv7l GNU/Linux

cmcmanis@pandaboard:~/hacks/kmscube$

[Rob Clark]

Oh, sorry, I left out one important step.. if you didn't start x11
first, you need to run 'pvrsrvinit' (xf86-video-omap-pvr normally does
this)..

And I just noticed, it seems like pvrsrvinit is maybe not added to the
pvr package. So I guess the temporary workaround is start and kill
x11.

All the init code is actually in /usr/lib/libsrv_init.so, so you might
be able to make a simple program that links against that and just
calls SrvInit(void), and run this as root.

BR,
-R

[Chuck McManis]

Cool, starting X and then killing it worked a treat. Very nice.

[He-Jie Shih]

I'm using pandaboard es with linaro 12.09 ubuntu,
and I rewrite our game to run my opengl es 2.0 app without x11 just like the kmscube sample.

The FPS at pandaboard is lower than my test board. ( pandaboard 45 fps vs my device 75fps up)
Our test device is single core arm1176@900mhz with ddr3@800mhz and mali-200@400mhz.

I think pandaboard is better than our device (cpu performance, memory bandwidth, 3D graphic chip).
Is the mali-200@400mhz better than powervr sgx540?
How can I improve our game's performance at pandaboard?


I have another question.
When our game is running, we get a lot of message just like the following.

gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
...

Is it normal?

Thanks!

[Rob Clark]

On Wed, Oct 3, 2012 at 9:03 AM, He-Jie Shih <bigno...@gmail.com> wrote:
>
> I'm using pandaboard es with linaro 12.09 ubuntu,
> and I rewrite our game to run my opengl es 2.0 app without x11 just like the
> kmscube sample.
>
> The FPS at pandaboard is lower than my test board. ( pandaboard 45 fps vs my
> device 75fps up)

I expect the difference is your test board is not vsync locked but
pandaboard/kms is. Also, currently kms/gbm winsys is only double
buffered. Possibly with triple buffered you would hit 60fps (or
whatever your monitor refresh rate is).

An EGL extension needs to be invented so that weston can figure out
the # of buffers. Until then, we can enable triple buffering without
screwing up weston's dirty region tracking.

If you need triple buffering, you should use x11 fullscreen for now.

> Our test device is single core arm1176@900mhz with ddr3@800mhz and
> mali-200@400mhz.
>
> I think pandaboard is better than our device (cpu performance, memory
> bandwidth, 3D graphic chip).
> Is the mali-200@400mhz better than powervr sgx540?
> How can I improve our game's performance at pandaboard?
>
>
> I have another question.
> When our game is running, we get a lot of message just like the following.
>
> gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
> gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
> gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
> gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
> gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
> gbmpvr: WSEGL_SwapDrawable:435: hDrawable=0x72e508
> ...

There are still a lot of debug traces that are enabled for the gbm
code.. these will be removed later, but for now we left them in case
there are any issues to debug

BR,
-R

[He-Jie Shih]

On Wednesday, October 3, 2012 3:16:04 PM UTC+8, rob wrote:

On Wed, Oct 3, 2012 at 9:03 AM, He-Jie Shih <bigno...@gmail.com> wrote:  

I expect the difference is your test board is not vsync locked but
pandaboard/kms is.  Also, currently kms/gbm winsys is only double
buffered.  Possibly with triple buffered you would hit 60fps (or
whatever your monitor refresh rate is).

I remove the "waiting_for_flip" mechanism as in kmscube sample, and then I get 63~7x fps.
I don't know that the "waiting_for_flip" mechanism is necessary or not.

I found some hardware spec.

Mali-200 fill rate: 275M pixels/s at 275hmz (from arm mali website)
Our device: perhaps 400M pixels/s at 400mhz

powervr sgx 540 fill rate: 1G pixels/s at 200mhz
pandaboard: 1G up pixels/s at 384mhz

I think the pandaboard should do better. (1xx fps up)
 

An EGL extension needs to be invented so that weston can figure out
the # of buffers.  Until then, we can enable triple buffering without
screwing up weston's dirty region tracking.

If you need triple buffering, you should use x11 fullscreen for now.

I found some sample to trigger full screen in x11. The code is just like:

atom=XInternAtom(x_display,"_NET_WM_STATE_FULLSCREEN",True);
XChangeProperty(x_display,win,XInternAtom(x_display,"_NET_WM_STATE",True),
    XA_ATOM,32,PropModeReplace,(unsigned char*)&atom,1);

The error message is like:

X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0x0
  Serial number of failed request:  14
  Current serial number in output stream:  18

Can I get some sample to create full screen in x11 with powervr?

Thanks!

[Emmanuel Deloget]

Le mercredi 3 octobre 2012 13:14:44 UTC+2, He-Jie Shih a écrit :

I found some sample to trigger full screen in x11. The code is just like:

atom=XInternAtom(x_display,"_NET_WM_STATE_FULLSCREEN",True);
XChangeProperty(x_display,win,XInternAtom(x_display,"_NET_WM_STATE",True),
    XA_ATOM,32,PropModeReplace,(unsigned char*)&atom,1);

The error message is like:

X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0x0
  Serial number of failed request:  14
  Current serial number in output stream:  18

Can I get some sample to create full screen in x11 with powervr?

Thanks!

NeHe has some very simple code to setup a X window to use with OpenGL. I guess the window setup part can be reused. 

See http://nehe.gamedev.net/tutorial/simpleglxwindow_class/35003/

(I'm not an X + GL expert, so I won't promise you that it works). 

Best regards, 

-- Emmanuel Deloget  

[Rob Clark]

On Mon, Oct 15, 2012 at 12:49 PM, Philippe H <phar...@sta.samsung.com> wrote:
>
> Hello,
> I am having difficulties doing triple buffering with the new kms/gbm gles
> mode. AFAIK, the EGL driver only does double buffering in this mode so

yes.. the problem is that using triple buffering will confuse weston's
dirty-region tracking, as it needs to know how frequently a buffer is
reused. (Basically, it takes the union of the current damage region
and the damage of the previous frame, to figure out what the minimal
area to re-render is. Which breaks down when you add a 3rd buffer.)

> instead of using eglSwapBuffers, I tried allocating renderbuffers or
> textures backed by gbm buffer objects, using eglCreateImageKHR, and
> attaching them to a FBO. That works but the EGL driver seems to do extra
> copying around internally when I do that, costing 3ms per frame looking at
> pvrtune traces, and the result is vertically flipped. The flipping is
> probably manageable but the extra rendering time is a problem for me.

well, if it is an option, the easiest way to get triple buffering
right now would be to use X11. For a fullscreen app (especially if
you don't have a silly window manager in the way), there really is no
fps overhead. Although it is extra stuff to have in your filesystem..

With gbm, you might be able to hack around this by alternating between
two difference surfaces? For each surface you'll get a flipchain of
two buffers. KMS doesn't really care if you are passing fb's from
different surfaces to drmModePageFlip().

BR,
-R

> Any ideas?
> Thanks.