Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
30 user(s) are online (18 user(s) are browsing Forums)

Members: 2
Guests: 28

icbrkr, pvanni, more...
Support us!
Recent OS4 Files
OS4Depot.net
Report message:*
 

Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress

Subject: Re: GL4ES: another OpenGL over OpenGLES2 emulation - some tech. info and porting progress
by kas1e on 2019/7/25 12:04:47

@Hans
Quote:

I had to disable compiler optimizations because boost shared pointers somehow lost track of their usage counters with optimization enabled, resulting in objects being destroyed while they're still in use. That alone probably has a noticeable impact.


Oh, that no surprise of course !

Is NOVA's shader compiler and says endian-conversion code are different "programms" which builds with different optimisation ? Why i ask , is that I remember that you disable optimisation before for endian-conversion code, which was almost main reassons for slow endian-conversion and low fps in quake3 , but then you fix something and it made FPS in quake3 almost be on pair with Daniel's patching code for ubyte endian conversion, but still slow (remember the needs for some some new TAG for ?:) ). I was in hope that you enable optimisation back and deal with those boost's shared ptr problems..

Or optimisation is back for endian-conversion, but didn't for shader compiler ?


Quote:

I'm sure there are ways that it could be optimized. However, right now I'm just glad that the compiler works (although I still have some bugs to fix).


Doesn't you mind if i will create BZ called "turn on optimisation for shader's compiler and deal with loosing of shared boost pointers", with all necessary info, so it can at least will be not forgotten, with all examples and explains what/where/etc ?

And from my past expirience : if enabled optimisation (expectually -O3) show some bug, which didn't happens without optimisation, it mean that code have bug, and optimisation only help to make it visibly, so that one for sure need to be taken care of.

Quote:

That's not so easy because more needs to be saved than just the raw shader code. There are various register settings that need to be preserved. So, I'd have to come up with another file format to save the binary.


Yeah, same as do ptitSeb for gl4es (his own format), and Daniel in ogles2. If you will ever consider adding such functionality (through, if CompileShader() will be optimised better that functionality may be not need it) i can create another BZ , so it will be not forgotten , with all the info. If you doesn't mind of course.

At least better to have BZ and give a dim about , than not have BZ and when time will come forgot to consider it :)

Quote:

I'm totally swamped with other work, so I'm unlikely to have time for looking into this, sorry.


That pity of course .. Hope it doesn't mean you will have no time for updating/fixing/optimizing NOVA in next year or two :) There is already few necessary to fix bugs waiting you few months :)

Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project