[Openpvrsgx-devgroup] how to run gles2test1

H. Nikolaus Schaller hns at goldelico.com
Sat Nov 16 08:51:29 CET 2019


Hi Tony,

> Am 16.11.2019 um 02:46 schrieb Tony Lindgren <tony at atomide.com>:
> 
> Hi,
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [191115 14:31]:
>> Hi,
>> 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
> stuff.
> 
> 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:
> 
> https://github.com/tmlind/pvr-omap4-dkms/tree/testing-v5.4
> 
> I'll try to slowly make it work next with linux_openpvrsgx
> pvr-drv by adding a command translation layer.

Fine.

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
letux/pvrsrvkm.

BR and congrats and thanks,
Nikolaus



More information about the openpvrsgx-devgroup mailing list