• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 3370 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP5 - GLESv2/EGL issue

Jesper Larsen2
Prodigy 30 points

Hi,

We are using the OMAP5432 uEVM, and trying to get a basic GLESv2/EGL stack working. The board is running from a SD card prepared according to the GLSDK 6.00.00.07 Software Developers Guide.

A small "Hello World" GLESv2 application from Immagination SDK is used to test the stack. The source code is attached to this post.

This example is tested and works on the AM335x EVM with the TI Graphics SDK, but does not work on the OMAP5 uEVM.

I start by loading the omapdrm_pvr module with

$ modprobe omapdrm_pvr

Then I run pvrsrvinit, but this seems a bit buggy. First time I run it I get the following ouput

root@localhost:~# pvrsrvinit
[ 1184.736175]
[ 1184.737731] =============================================
[ 1184.743408] [ INFO: possible recursive locking detected ]
[ 1184.749084] 3.8.4-100-omap5 #3glsdk5 Tainted: G C O
[ 1184.754913] ---------------------------------------------
[ 1184.760589] pvrsrvinit/1881 is trying to acquire lock:
[ 1184.765991] (psPVRSRVMutex){+.+.+.}, at: [<bf0914a0>] DebugMemAllocRecordAdd+0x2c/0x120 [omapdrm_pvr]
[ 1184.775817]
[ 1184.775817] but task is already holding lock:
[ 1184.781951] (psPVRSRVMutex){+.+.+.}, at: [<bf08fce0>] PVRSRVOpen+0x18/0xec [omapdrm_pvr]
[ 1184.790588]
[ 1184.790588] other info that might help us debug this:
[ 1184.797454] Possible unsafe locking scenario:
[ 1184.797454]
[ 1184.803680] CPU0
[ 1184.806243] ----
[ 1184.808807] lock(psPVRSRVMutex);
[ 1184.812377] lock(psPVRSRVMutex);
[ 1184.815979]
[ 1184.815979] *** DEADLOCK ***
[ 1184.815979]
[ 1184.822174] May be due to missing lock nesting notation
[ 1184.822174]
[ 1184.829315] 2 locks held by pvrsrvinit/1881:
[ 1184.833801] #0: (drm_global_mutex){+.+.+.}, at: [<c02fbe38>] drm_stub_open+0x38/0x138
[ 1184.842254] #1: (psPVRSRVMutex){+.+.+.}, at: [<bf08fce0>] PVRSRVOpen+0x18/0xec [omapdrm_pvr]
[ 1184.851348]
[ 1184.851348] stack backtrace:
[ 1184.855957] [<c001a194>] (unwind_backtrace+0x0/0x11c) from [<c0080014>] (print_deadlock_bug+0xc8/0xf8)
[ 1184.865722] [<c0080014>] (print_deadlock_bug+0xc8/0xf8) from [<c0081868>] (validate_chain.isra.27+0x4e0/0x534)
[ 1184.876251] [<c0081868>] (validate_chain.isra.27+0x4e0/0x534) from [<c0082658>] (__lock_acquire+0x70c/0x7e4)
[ 1184.886566] [<c0082658>] (__lock_acquire+0x70c/0x7e4) from [<c0082d64>] (lock_acquire+0x128/0x14c)
[ 1184.895996] [<c0082d64>] (lock_acquire+0x128/0x14c) from [<c055836c>] (mutex_lock_nested+0x4c/0x3a8)
[ 1184.905609] [<c055836c>] (mutex_lock_nested+0x4c/0x3a8) from [<bf0914a0>] (DebugMemAllocRecordAdd+0x2c/0x120 [omapdrm_pvr])
[ 1184.917358] [<bf0914a0>] (DebugMemAllocRecordAdd+0x2c/0x120 [omapdrm_pvr]) from [<bf0916b0>] (_KMallocWrapper+0x38/0x44 [omapdrm_pvr])
[ 1184.930114] [<bf0916b0>] (_KMallocWrapper+0x38/0x44 [omapdrm_pvr]) from [<bf08d138>] (OSAllocMem_Impl+0x50/0x68 [omapdrm_pvr])
[ 1184.942138] [<bf08d138>] (OSAllocMem_Impl+0x50/0x68 [omapdrm_pvr]) from [<bf09a87c>] (PVRSRVPerProcessDataConnect+0x54/0x148 [omapdrm_pvr])
[ 1184.955383] [<bf09a87c>] (PVRSRVPerProcessDataConnect+0x54/0x148 [omapdrm_pvr]) from [<bf08fcf0>] (PVRSRVOpen+0x28/0xec [omapdrm_pvr])
[ 1184.968139] [<bf08fcf0>] (PVRSRVOpen+0x28/0xec [omapdrm_pvr]) from [<bf0a9d98>] (PVRSRVDrmOpen+0xb8/0xd8 [omapdrm_pvr])
[ 1184.979522] [<bf0a9d98>] (PVRSRVDrmOpen+0xb8/0xd8 [omapdrm_pvr]) from [<c0410394>] (dev_open+0x94/0xf0)
[ 1184.989410] [<c0410394>] (dev_open+0x94/0xf0) from [<c02fba40>] (drm_open_helper+0x178/0x2f0)
[ 1184.998382] [<c02fba40>] (drm_open_helper+0x178/0x2f0) from [<c02fbd7c>] (drm_open+0xa0/0x124)
[ 1185.007415] [<c02fbd7c>] (drm_open+0xa0/0x124) from [<c02fbebc>] (drm_stub_open+0xbc/0x138)
[ 1185.016204] [<c02fbebc>] (drm_stub_open+0xbc/0x138) from [<c00fc644>] (chrdev_open+0x11c/0x144)
[ 1185.025360] [<c00fc644>] (chrdev_open+0x11c/0x144) from [<c00f7014>] (do_dentry_open+0x1ac/0x268)
[ 1185.034667] [<c00f7014>] (do_dentry_open+0x1ac/0x268) from [<c00f72c8>] (finish_open+0x38/0x4c)
[ 1185.043823] [<c00f72c8>] (finish_open+0x38/0x4c) from [<c01050bc>] (do_last.isra.19+0x4e0/0x5e0)
[ 1185.053039] [<c01050bc>] (do_last.isra.19+0x4e0/0x5e0) from [<c0105260>] (path_openat+0xa4/0x420)
[ 1185.062377] [<c0105260>] (path_openat+0xa4/0x420) from [<c0105890>] (do_filp_open+0x2c/0x78)
[ 1185.071228] [<c0105890>] (do_filp_open+0x2c/0x78) from [<c00f8180>] (do_sys_open+0xe4/0x170)
[ 1185.080108] [<c00f8180>] (do_sys_open+0xe4/0x170) from [<c0012c60>] (ret_fast_syscall+0x0/0x3c)

Any further calls gives another output

root@localhost:~# pvrsrvinit
PVR:(Error): SrvInit: PVRSRVInitSrvConnect failed (129) [37, /srvinit.c]
PVR:(Error): main: SrvInit failed (129) [47, /pvrsrvinit.c]

If I try to run the GLESv2 example I get the following output

root@localhost:~# ./glesv2-test
PVR:(Warning): LoadWSModule: Window system module libpvrws_KMS.so did not validate native display [98, /generic_ws.c]
PVR:(Warning): LoadWSModule: Window system module libpvrws_WAYLAND.so did not validate native display [98, /generic_ws.c]
PVR:(Warning): LoadWSModule: Window system module libpvrws_OMAPDRI2.so did not validate native display [98, /generic_ws.c]
Error: eglInitialize() failed.

Has anyone had any luck getting GLESv2/EGL working outside X?

Best Regards,
Jesper Larsen 

OGLES2HelloAPI_NullWS.cpp
  • 0
    TI__Expert 7015 points

    Jesper,

    The second call to pvrsrvinit is failing, because it is already initialised when the first call was made.

    The kernel log regarding the recursive deadlock is a known issue. However, it is not supposed to create problems when running GL examples.

    It may be verified that EGL stack is properly initialised if kmscube runs succesfully. kmscube is provided along with GLSDK package.

    The applications from IMAGINATION SDK doesnot support the null window system. They can be built and run on X. outside X, KMS applications will work, but the SDK examples are not built with kms.

    Regards,

    Subhajit

  • 0 in reply to Subhajit Paul
    Prodigy 40 points

    Subhajit,

    Actually, the attached OGLES2HelloAPI_NullWS.cpp is taken directly from the IMAGINATION SDK and works perfectly with the latest TI Graphics SDK 4.09.00.01 package tested on TMDSSK3358 - it links with libEGL.so and libGLESv2.so only and there is no KMS nor X involved.

    Now, the frustration is that the OMAP5 graphics stack does not provide the same basic null window functionality.

    Regards, Martin

  • 0
    TI__Intellectual 880 points

    Jesper,

    did you export the display and start Xorg?

    try,

    root@localhost:~# modprobe omapdrm_pvr

    root@localhost:~# export DISPLAY=:0

    root@localhost:~# Xorg &

    root@localhost:~# pvrsrvinit

     

    I was then able to run sucessfully the below.

    root@localhost:~# es2gears

    3741 frames in 5.0 seconds = 748.200 FPS

    root@localhost:~# xgles1test1

    root@localhost:~# xgles2test1 -f 1000

     

    Hopefully this helps,

    LT

  • 0 in reply to LT Thomas
    Prodigy 30 points

    LT Thomas said:

    Jesper,

    did you export the display and start Xorg?

    No, I did not, as this would defy the purpose of getting a GLESv2/EGL application to run without X.
    This is know to work on the Sitara as mentioned above.

    We currently have QT5 applications running on the Sitara using the eglfs platform, and the aim was to do the same on the OMAP5.
    We have managed to get QT5 with the kms platform running, though the support does not seem to be as good as the eglfs on the Sitara. 

  • 0 in reply to Jesper Larsen2
    TI__Expert 5130 points

    Jesper,

    The display infrastructure on OMAP5 is managed through DRM/KMS. FBDev is not supported. eglfs inherently requires FBDev support.

    We have Qt5 on OMAP5 and Jacinto6 with KMS available here:

    http://tigraphics.blogspot.in/2013/08/qt5-with-kms-omap5-jacinto6.html

    Can you let me know specific feature support that's lacking on KMS platform? As mentioned in the blogpost, certain features still to be enabled with KMS platform.


    Regards,

    Anand Balagopalakrishnan

  • 0 in reply to Anand Balagopalakrishnan
    Prodigy 30 points

    Thank you for clearing the eglfs situation.

    Anand Balagopalakrishnan said:

    Can you let me know specific feature support that's lacking on KMS platform? As mentioned in the blogpost, certain features still to be enabled with KMS platform.

    Besides from the TODO issues from the blog, I see a different error, if I try to run the browser/fancybrowser examples from qtwebkit.

    PVR:(Error): PrepareToDraw: Invalid drawable [1058, /sgxif.c]
    PVR:(Error): glDrawArrays: Can't prepare to draw [2403, /drawvarray.c]