[Openpvrsgx-devgroup] how to run gles2test1
H. Nikolaus Schaller
hns at goldelico.com
Sat Nov 16 08:51:29 CET 2019
> Am 16.11.2019 um 02:46 schrieb Tony Lindgren <tony at atomide.com>:
> * H. Nikolaus Schaller <hns at goldelico.com> [191115 14:31]:
>> so far I have only used gles1test1 but now gound out how to run the gles2test1 (on OMAP5/Pyra):
>> It just did tell me:
>> root at letux:~# gles2test1 100
>> --------------------- started ---------------------
>> [ 42.561320] DSI: omapdss DSI error: VC(0) busy when trying to configure it!
>> [ 42.568784] DSI: omapdss DSI error: VC(1) busy when trying to configure it!
>> [ 42.576324] DSI: omapdss DSI error: VC(2) busy when trying to configure it!
>> [ 42.584949] DSI: omapdss DSI error: VC(3) busy when trying to configure it!
>> [ 42.767103] dmtimer posted=0
>> Error: Failed to open shader file 'glsltest1_vertshader.txt'!
>> [ 42.896790] dmtimer posted=0
>> --------------------- finished ---------------------
> Hmm have not seen that one.. But then again, I only just got
> droid4 working.
Congratulations! That is IMHO another important milestone for our project.
> Still no luck with the other boards :)
Time will find a solution :)
> For omap4, we need to use the old pvr-omap4-dkms kernel module
> built for for droid4 after backporting some of your patches
> from linux_openpvrsgx and fixing up the custom ioctl proxying
> But yeah for the droid4 demos, xgles1test1, xgles2test1, and
> xmultiegltest all do work now. And so does es2gears started
> with a LD_PRELOAD wrapper. So there might be a regression
> in the linux_openpvrsgx somewhere?
I can't exclude that...
> FYI, it's here in testing-v5.4 branch with a README_DROID4:
> I'll try to slowly make it work next with linux_openpvrsgx
> pvr-drv by adding a command translation layer.
I have looked into the testing-v5.4 tree and it is based on
DDK 1.9.2253347 which we also have in the linux_openpvrsgx tree.
I am almost done with rearranging the branch names and moving all
files to drivers/gpu/drm/pvrsgx so that we will have a cleaned up
(and hopefully stable) basis very soon.
Then you can add required patches to the (new) letux/pvrsrvkm-1.9.2253347
branch and it should work by choosing CONFIG_PVRSGX_1_9_2253347=y.
I'll write a description here to this list when it is done.
New patches for the command translation layer can then go to
BR and congrats and thanks,
More information about the openpvrsgx-devgroup