[Arm-netbook] x11 for a10 cpu

[cnxsoft]

On 03/07/2012 17:06, Iain Bullard wrote:
> On 3 July 2012 10:53, cnxsoft<cnxsoft at cnx-software.com>  wrote:
>> Did you try :
>> LD_PRELOAD=/usr/lib/mali.so glmark2-es2
>>
>> (mali.so or everything containing your GL ES binary)
>>
>> I did no try on the mele yet, but with the Cubox i do :
>> LD_PRELOAD=/usr/lib/libGLESv2.so:/usr/lib/libXrender.so.1:/usr/lib/libEGL.so
>> DISPLAY=:0 /opt/e17/bin/expedite -e gl -a -p 720p
>>
>> The probleme is that without LD_PRELOAD, libs are the one provides by
>> Mesa, so you get a Direct Rendering : Yes, but it's a sofware
>> fallback, and it's slow.
>> You can check which .so are loaded at runtime by using ldd, to check.
>>
>> I just got mesa out of the way by renaming
>> /usr/lib/arm-linux-gnueabihf/mesa-egl to something else.
>> So now it's using the armhf libs provided by Tom/AllWinner (checked with
>> ldd), but it fails to open the UMP driver:
>>
>> ./es2_info
>> UMP: ump_arch_open() failed to open UMP device driver
>> *********************************************************************
>> ERROR: In file: src/base/common/mem/base_common_mem.c  function:
>> initialize_memory_system()   line:1521
>> Could not open UMP memory system. Shutdown.
>>
>> If you use strace against your test program you should be able to see
>> if it is attempting to open a particular device that is not present on
>> your system.
>>
>> I can't believe I never used strace before... It turned out to be a
>> permission issue on /dev/ump and /dev/mali.
>> I got a little further and now it fails when calling eglInitialize() in
>> src/egl/egl_platform_x11.c    __egl_platform_init_display:272. I'm not sure
>> strace (http://pastebin.com/ThCGzd84) can help here, although we get a lot
>> of "Resource temporarily unavailable" when using (UNIX) sockets.
>> As mentioned a few posts above, all needed modules (mali, mali_drm, ump...)
>> are already loaded.
>>
> Looking at the strace your process seems to be communicating (at the
> very least reading and writing data) over via fd's 3 and 5 which is
> /tmp/.X11-unix/X0 socket. The EAGAIN responses tell us that there
> isn't any more data to read on the socket at the point in time so we
> go back into poll until data is available. So I wouldn't be too
> concerned about those.
>
> As you said, I think it will be difficult to tell what the problem is
> now with the strace.
>
> Iain.
Just one last point. When using glmark2-es2 instead of es2_info, we can 
see a proper error code: 12291 which corresponds to "BAD_ALLOC" (The 
same as Nicolas).