[Arm-netbook] x11 for a10 cpu

[Nicolas Aguirre]

2012/7/3 cnxsoft <cnxsoft at cnx-software.com>:
> 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).
>
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk

0x3003 == 12291 make sense :-)

-- 
Nicolas Aguirre
Mail: aguirre.nicolas at gmail.com
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/