EGL_KHR_image_pixmap and GL_OES_EGL_image extensions are advertised but don't seem to work

[Alexandros Frantzis]

The drivers advertise support for the EGL_KHR_image_pixmap and GL_OES_EGL_image extensions that are needed for accelerated texture from pixmap support. However, they don't seem to be functioning properly:

A simple example application exhibits the issue:
http://people.canonical.com/~afrantzis/texture-from-pixmap-glesv2/texture-from-pixmap-glesv2.tar.gz

In the texture-from-pixmap-glesv2 example, whatever is drawn in the left side should be displayed on the faces of the spinning cube, but in this case nothing is displayed.

[Jammy Zhou (jammy-zhou)]

The tfp example works well on my system, which was refreshed recently with the maverick-installer released in March. And the GPU driver version is:
libegl1-imx: 1.0.2-20110213
libgles2-imx: 1.0.2-20110213
xserver-xorg-video-imx: 1.0.0-20110228

[Jesse Barker (jesse-barker)]

Seems to work for me. I'm using a very recent maverick-installer (maverick-20110302.img.xz) and had also run the efikamx-updater (efikamx-updater.img.xz) before running the installer; both downloaded last week. I have updated the gles/egl packages. Here's what I'm running:

uname -r: 2.6.31.14.20-efikamx
libegl1-imx: 1.0.3-20110310
libgles2-imx: 1.0.3-20110310
xserver-xorg-video-imx: 1.0.0-20110228

cheers,
Jesse

[Alexandros Frantzis (afrantzis)]

In my case with:
uname -r: 2.6.31.14.20-efikamx
libegl1-imx: 1.0.3-20110310
libgles2-imx: 1.0.3-20110310
xserver-xorg-video-imx: 1.0.0-20110228

The tfp example doesn't show anything on the cube when it is run normally and crashes when run with --no-egl-image.

With the 20110312 experimental packages, the tfp example crashes when it is run normally and shows some corrupted visuals on the faces with --no-egl-image.

The backtrace for the crash is:

Program received signal SIGSEGV, Segmentation fault.
0x2afd324c in free () from /lib/libc.so.6
(gdb) bt
#0 0x2afd324c in free () from /lib/libc.so.6
#1 0x2b0925f6 in os_free () from /usr/lib/libkgsl.so.1.0
#2 0x2aae44a4 in eglDestroyImageKHR () from /usr/lib/libEGL.so.1.4
#3 0x00009e14 in app_reshape (data=0x7ecbd4ec) at texture_from_pixmap_glesv2.c:308
#4 0x0000a724 in app_run (data=0x7ecbd4ec) at texture_from_pixmap_glesv2.c:565
#5 0x0000ae64 in main (argc=1, argv=0x7ecbd754) at texture_from_pixmap_glesv2.c:78

[Alexandros Frantzis (afrantzis)]

A difference I see from Jammy's and Jesse's setup, is that I installed the image a while back (I don't remember exactly) and just updated since. Could this cause the problem?

[Matt Sealey (mwsealey)]

This is really confusing as it simply doesn't run here. Fetching the visual from Xorg just fails. I'm using 20110302 on a clean Smarttop (since it's more comfortable to test).

It seems we have better luck on the Smartbook, and this may be entirely down to fragmentation of GPU memory by GSL and Xorg offscreen pixmaps. We are looking into a better (and better-performing) memory allocator as using glibc for GPU memory seems like a terrible idea. We tried tlsfmalloc already..

[Matt Sealey (mwsealey)]

Updating should cause zero problems. We just update the SD card image by doing a package update and retarballing...

I changed the behavior of eglDestroyImageKHR so it might work better with the 1.1.0 versions I sent you over the weekend. Can you re-test and see if there is a significant difference in the backtrace?

[Alexandros Frantzis (afrantzis)]

Sorry, I wasn't clear: the crash mentioned in #3 happens with the 1.1.0 drivers you sent me (1.1.0-20110312) when using EGLImage s (running the example normally).

Also, with these drivers, when using the fallback mode (--no-egl-image), I do get some output on the cube faces but it is corrupted.

[Matt Sealey (mwsealey)]

Was it a different backtrace with the previous driver?

[Alexandros Frantzis (afrantzis)]

Yes they are different. With the previous driver I get the backtrace noted in https://bugs.launchpad.net/efikamx/+bug/733410 when running in *fallback* (XImage) mode. In this case I am getting a crash when running with EGLImage support (normal mode).

[Matt Sealey (mwsealey)]

Okay crash bug fixed..

[Matt Sealey (mwsealey)]

BTW I still can't confirm this benchmark breaks outside of our own test programs due to the "Error: couldn't get X Visual" error.

   if (!eglGetConfigAttrib(data->dpy, config, EGL_NATIVE_VISUAL_ID, &vid)) {
      printf("Error: eglGetConfigAttrib() failed\n");
      exit(1);
   }

   /* The X window visual must match the EGL config */
   visTemplate.visualid = vid;
   visInfo = XGetVisualInfo(data->xdpy, VisualIDMask, &visTemplate, &num_visuals);
   if (!visInfo) {
      printf("Error: couldn't get X visual\n");
      exit(1);
   }

Can anyone explain what is going on here so I can work out how we fix it? It doesn't make sense to me that eglGetConfigAttrib() succeeds but then you can't XGetVisualInfo on the returned data..

[Matt Sealey (mwsealey)]

Crash definitely fixed, benchmark still doesn't work. Alexandros!?

[Jammy Zhou (jammy-zhou)]

For "Error: couldn't get X visual", could you please print out the visual id number returned by eglGetConfigAttrib? And compare it with supported visual list returned by xdpyinfo.