glshim

[lunixbochs]

To render the comment you just posted would be 231 such calls. Letters add up really fast

 

[nighteagle]

Hi,


so can you see the difference between both pictures?


Lunixbochs:





ptitSeb:

 

[nighteagle]

And i mean not the Text-Issue.


On the second one there is no rendered IR_Image... only an blue screen.. first i have tought is while the CAM is not moving.. but when i close the app.. i see only 10 of my FPS Calls  from 27-0,2fps showing on the console... by using ptitSeb and i see 50 of that fps calls on my terminal in quickly response show me 30-40 fps if i use lunixbochs.

 

[nighteagle]

So i think the software is stopped or extremly slow... but is thre slow because of to many calls? But thre is no rendering image from the CAM...

 

[ptitSeb]

Ok, so the issue is probably comming from some format conversion bug regarding the video feed. Is this software opensource (so I can look at how that feed is handled)?

 

[petevine]

There's definitely some sort of performance problem; the code snippet @lunixbochs linked to (attached) is causing system loads around 1.0 with his own glshim whereas @ptitSeb's is eliciting around 2.0 (Mali driver on Odroid C1)


The immediate difference seems to be the huge amount of scrolling on the terminal that printing


libGL: warning, gles_glBlendFuncSeparate is NULL


  is probably causing (even when you completely cover that xterm window)


View attachment bitfont.c

 

[nighteagle]

I can send to you the sources if you give me the Mail-Adress.. i'm wait here for minutes.. can post and delete your adress.

 

[ptitSeb]

I can send to you the sources if you give me the Mail-Adress.. i'm wait here for minutes.. can post and delete your adress.

I sent you a PM...

 

[nighteagle]

Yes.. Mail send.

 

[nighteagle]

Here you can see lunixbochs branch i have testet for 2 minutes and then quit the app to see my fps output. You see from 30 to maximum 40fps. Is enough for me.


Interesting is some glGetError 0x500 at the beginning...

 

[petevine]

@ptitSeb


Bingo! I've just squashed the printf's in src/gl/loader.h which brought performance in line with @lunixbochs's version.


I have no idea if it's only affecting Mali but clearly it was very CPU intensive. (didn't impact rendering performance but worked a full core needlessly)

 

[ptitSeb]

@ptitSeb


Bingo! I've just squashed the printf's in src/gl/loader.h which brought performance in line with @lunixbochs's version.


I have no idea if it's only affecting Mali but clearly it was very CPU intensive.

The printf in the WARN_NULL macro? It was triggering on the ODroid? On which function?

 

[petevine]

Did you miss my post above? (libGL: warning, gles_glBlendFuncSeparate is NULL)

 

[ptitSeb]

Did you miss my post above? (libGL: warning, gles_glBlendFuncSeparate is NULL)

Yes I did miss it. Ok, I'll do a workaround to avoid the repeted printf for the Odroid.

 

[nighteagle]

Today i have test something but not this:


 

[SIZE=12.8px]glBindTexture(GL_TEXTURE_2D, _texture);[/SIZE]


[SIZE=12.8px]before the glTexImage2D [/SIZE]


 


[SIZE=12.8px]Hope i can check it asap...[/SIZE]

 

[Cartridge]

Would anyone have a bit of time to post a brief tutorial on how PitSeb's Glshim remote version works, it has changed much from lunixbochs. I want to test it out on some old games and see if it's noteworthy for the magazine.

 

[ptitSeb]

Would anyone have a bit of time to post a brief tutorial on how PitSeb's Glshim remote version works, it has changed much from lunixbochs. I want to test it out on some old games and see if it's noteworthy for the magazine.

Unfortunatly It doesn't. I haven't merged with lunixbochs work on remote use, so only lunixbochs version has this ability.


Out of curiosity, on what plateform are you using that, and for what magazin?

 

[Cartridge]

I have almost all the ODROID family of computers and I experiment with them. I have had not much to contribute to the magazine these past few months but I post for ODROID Magazine. Your fork seems a bit more perfected and I have been unsuccessful to use the remote libs from lunix on Exagear. This is just for experimentation purposes.

 

[ptitSeb]

I have almost all the ODROID family of computers and I experiment with them. I have had not much to contribute to the magazine these past few months but I post for ODROID Magazine. Your fork seems a bit more perfected and I have been unsuccessful to use the remote libs from lunix on Exagear. This is just for experimentation purposes.

Thanks for the anwsers (I have looked at a couple of issue of that pdf Magazine, it's a nice one)


I don't have Exagear myself, so I cannot help here. But other have tried exeperiments on the Pandora with Exagear and glshim I think. Maybe they will give some feedback.

 

[lunixbochs]

I have almost all the ODROID family of computers and I experiment with them. I have had not much to contribute to the magazine these past few months but I post for ODROID Magazine. Your fork seems a bit more perfected and I have been unsuccessful to use the remote libs from lunix on Exagear. This is just for experimentation purposes.

PtitSeb's fork has support for more games, because he uses it for his game releases on Pandora. I've ported over a large number of his improvements to the upstream glshim, but I'll probably need his help to finish them all.


My upstream version has remote rendering, support for TinyGLES, most of the same features, and a much cleaner codebase (I re-architected and significantly cleaned up display lists a couple of times, which he hasn't merged). I believe it would be harder to implement remote rendering in PtitSeb's fork than to merge his improvements with upstream.


The original remote branch only works with a modified QEMU or Exagear to add a passthrough syscall, which was never made public. The upstream glshim remote rendering works using shared memory and a second process, which makes it more stable and works without modifying Exagear or QEMU. If you had a problem using Exagear with remote rendering and my unstable glshim branch from these instructions, I'd be happy to help.