- October 6, 2011 at 4:21 am #30652
I have trying to use the PVRTune(LinuxX86 package) tracer on my linux device(SGX 535) for the graphic analysis.
however, I cannot redirect my apps’s graphic library to the PVRTrace by check it with ldd command.
( I’d export the LD_LIBRARY_PATH to where the PVRTrace libraries is, and the ‘pvrtrace.cfg’ do created after I execute my Apps first time. )
Can anyone give me a clue where I did it wrong?
Here is my test environments:
(*) EGL/GLES library link of my Apps:
libEGL.so.1 => /usr/lib/libEGL.so.1 (0x4e2c8000)
libGLESv2.so.2 => /usr/lib/libGLESv2.so.2 (0x4f3f5000)
(*)device EGL/GLES library under /usr/lib/ :
lrwxrwxrwx 1 root root libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root libGLESv2.so.18.104.22.16843 -> pvr/platform/libGLESv2.so.22.214.171.12443
lrwxrwxrwx 1 root root libGLESv2.so.2 -> libGLESv2.so.126.96.36.19943
lrwxrwxrwx 1 root root libEGL.so -> libEGL.so.1
lrwxrwxrwx 1 root root libEGL.so.1 -> libEGL.so.188.8.131.5243
lrwxrwxrwx 1 root root libEGL.so.184.108.40.20643 -> pvr/mrst/libEGL.so.220.127.116.1143
(*) Also changed the lib path in pvrtrace.cfg to link as my apps does:
[root@localhost ]# cat pvrtrace.cfg
EglLibraryPath = /usr/lib/libEGL.so.1
Es1LibraryPath = /usr/lib/libGLES_CM.so
Es2LibraryPath = /usr/lib/libGLESv2.so.2October 6, 2011 at 11:07 am #35149
The problem is likely that your app is looking for symbolic links with specific names, which won’t appear in your LD_LIBRARY_PATH. I’d suggest generating sym links for the pvrtrace libraries so that the names match up (i.e. libEGL.so -> libEGL.so.1, libGLESv2.so -> libGLESv2.so.2).
This should solve the problem, and allow you to use PVRTrace correctly.
TobiasOctober 7, 2011 at 7:08 am #35150
thanks….that do helps me to fixed the link issue!
BTW, Can PVRTrace run in the user mode(not root user)?
( there will have a file open error happens(must be opening the trace.pvrt) and caused the test apps terminated when I run it in general user mode. )October 7, 2011 at 6:14 pm #35151
It can run in user mode, you just need to make sure that the “TraceFile” key in the pvrtrace.cfg points to a location that the application can write to at run time. If you don’t have a pvrtrace.cfg set up already then this may also be causing a problem, so you may need to create this file manually as root as well. Once that’s all done then you should be good to go in user mode.
TobiasOctober 12, 2011 at 7:57 am #35152
the problem is resolved!
Although I’ve still met a segment fault (dmesg:error 4 in libPVRTrace.so) when I launch some specific apps written by QT, I might need to figure out the root cause of the fault in next stage.
Anyway, I have to thanks you for the clue ^____.^
maceo1975 2011-10-12 08:04:47October 12, 2011 at 12:34 pm #35153
Glad that worked for you – we’re still working on the kinks in trace, the chances are that the apps that cause these problems are simply putting a lot of strain on the trace library. In some cases this can cause problems. If you would be able to send us (firstname.lastname@example.org) either a binary app or some test code which causes this issue (or both!) we will be able to look at fixing the issues you’re seeing.
TobiasOctober 14, 2011 at 8:33 am #35154
I am afraid not able to send you due to it is confidential concerning.
very sorry about that! (I wish I could!)
Actually, I can run glmark2-es benchmark and log GLES API with PVRTrace without error on my side.
I will send to you if I have meet the same kind of issue on a free GLES benchmark or apps.
thanks you again!