OGLES2 often passes in a nullptr for errCode. I passed my own variable instead of and yes, it was an empty queue. For example, running Boingtest gives some empty queues. The first one is with submit ID 0, the rest have non-zero IDs.
@Capehill On glClear a Nova-Submit is being issued even if no "real" drawing or so is queued, I asume that's what you see here. If that's necessary or not, I don't really know. Hans does this in his Nova examples.
@Hans The question is: is Nova's Clear command executed immediately or is the actual execution queued like other draw-commands?
Your examples indicate the latter. If that's true then this "empty" Submit() in ogles2 should remain as it is to keep the GPU busy (in real world apps a glClear is often issued long before other drawings). Otherwise I'll remove it.
Edited by Daytona675x on 2019/7/24 10:25:54 Edited by Daytona675x on 2019/7/24 10:28:36
@Hans The question is: is Nova's Clear command executed immediately or is the actual execution queued like other draw-commands?
Your examples indicate the latter. If that's true then this "empty" Submit() in ogles2 should remain as it is to keep the GPU busy (in real world apps a glClear is often issued long before other drawings). Otherwise I'll remove it.
In GL4ES ptitSeb add precompiled shader archive support (PSA), which mean that we can use precompiled binaries, and not compile shaders anymore. Daniel add to recent ogles2 necessary stuff to make it works, and so we meet with some problem.
For first, to explain, precompile shaders archive (PSA), mean to collect all the compiled shaders as binaries in some place, which is then on running of programm loaded to the memory, and then used just as glUseProgramm() without needs to compile them => no speed loss.
In our, amigaos4 case, shader compilation and execution looks like this:
- gl4es generate a GLSL shader, and send it to ogles2. - ogles2 translate GLSL shader to SPIRV + add necessary patching and stuff (so by logic heavy things). - NOVA translate that ready to use SPIRV to assembly machine code of gfx card, which then execute (don't know how heavy is it).
Ideally, PSA binaries should be of that last translation (after NOVA have machine code ready from SPIRV), but as Nova didn't provide any public functions for us to save/get them , we at least trying to get rid of ogles2's step: compiling GLSL to SPIRV + patching.
So, we doing all this, just to understand that all the problems is not sending GLSL shader to ogles2, and not ogles2 doing translation from GLSL to SPIRV + patching (which is heavy thing!), but NOVA's CompileShader() :(
I do 2 profiling tests:
1. without PSA support (so, all steps there, including ogles2's GLSL to SPIRV + patching):
As you can see, CompileShader() there take almost the same amount of time, showing that most of time spend in NOVA's version. But that all can be misleading of course, and so,
2. second result WITH PSA support, i.e. binaries placed in the SPIRV format on the disk, loaded to the memory on running, and then ogles2 don't do any CompileShader() thing (as can be seen from the next profiling file), but only UsePRogramm() which take nothing:
As can be seen, all the time still catched by the Nova's compileshader().
@Hans
Have you any idea why the translation / patching etc. of GLSL only takes a tiny fraction of the time of the Nova's SPIR-V assembly step (by tiny fraction means 5% only). Because i can understand if it was other way around, but not like it now.
The much-much more complex GLSL translation and all the internal source-code-patching in ogles2 only wasts 200 ms there.
Is there anything which can be taken care of ?
Also Nova's CompileShaders does not upload the stuff to the actuall hardware, right ? At least it should be that way. It should really be just something like an assembler / low-level-compiler with register mapping which should works more or less fast (at least on level of how ogles2's GLSL->SPIRV+patching compiling happens).
So.. if there is any reall reassons why should Nova's CompilerShader() be that slow and can't be optimized by any of reassons, can you made some public functions, by which we can generate ready to use assembly code in binary, and use the those binaries via something like useprogramm() , etc. Yes, those binaries will be different on all machines because of different gfx cards, and need to be generated on each, but then, only one time when first time plays.
It can be just kind of the same 2 functions as Daniel add lately to ogles2:
- W3DN_GetProgramBinary() to extract such a binary representation of the respective successfully linked shader program.
- W3DN_ProgramBinary() to supply the NOVA with such a cached binary
But together with this, of course taking look at why W3D's CompileShader() is that slow as it now will help a lot too.
Thanks!
Edited by kas1e on 2019/7/25 5:45:32 Edited by kas1e on 2019/7/25 5:56:36 Edited by kas1e on 2019/7/25 6:00:14
Have you any idea why the translation / patching etc. of GLSL only takes a tiny fraction of the time of the Nova's SPIR-V assembly step (by tiny fraction means 5% only). Because i can understand if it was other way around, but not like it now.
The much-much more complex GLSL translation and all the internal source-code-patching in ogles2 only wasts 200 ms there.
Is there anything which can be taken care of ?
I have no idea if the parsing front-end of other compilers takes up much CPU time or not. Parsing source-code into a syntax tree and outputting in another format (SPIR-V) is a relatively straightforward task, so it wouldn't surprise me if compiler time is dominated by the processing that takes place later.
Quote:
Also Nova's CompileShaders does not upload the stuff to the actuall hardware, right ? At least it should be that way. It should really be just something like an assembler / low-level-compiler with register mapping which should works more or less fast (at least on level of how ogles2's GLSL->SPIRV+patching compiling happens)./
Actually, yes, it does upload the code to the GPU.
Quote:
So.. if there is any reall reassons why should Nova's CompilerShader() be that slow and can't be optimized by any of reassons,
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.
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).
Quote:
It can be just kind of the same 2 functions as Daniel add lately to ogles2:
- W3DN_GetProgramBinary() to extract such a binary representation of the respective successfully linked shader program.
- W3DN_ProgramBinary() to supply the NOVA with such a cached binary
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.
I'm totally swamped with other work, so I'm unlikely to have time for looking into this, sorry.
Shell Process 'a.out': W3DN_Submit: errCode 15 (W3DNEC_QUEUEEMPTY). Submit ID 0 Shell Process 'a.out': W3DN_WaitIdle: timeout 0. Result 0 (W3DNEC_SUCCESS)
I became a bit more curious because my ogles2 code only calls Submit() if there's sth. queued, with Clear being the only kind-of "exception". Also, I actually only have one W3DN_WaitIdle in my code, at a location that's certainly not triggered at this point.
So I took your glSnoop and the Nova's Gears example. Voila: you'll find the very same Submit-with-empty-Warning + WaitIdle afterwards in the log - only that this code is not inside the W3DNGears.c code.
To sum it up: this empty Submit() is produced by Nova itself internally Hans?
boost is a toolset, just like the STL. You can build slow or fast things with it depending on whether you put it to good and correct use or not. And no, boost::shared_ptr is neither slow nor buggy. However it's certainly deprecated and you should probably prefer std::shared_ptr. Such a shared_ptr is certainly slower than a raw-pointer at some operations, but that's because it does much more work.
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 :)
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 ?
I enabled optimization specifically for the endianness-conversion code because it does *not* use shared pointers.
Quote:
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 ?
Sure. Using std::shared_ptr<> would be preferred.
Quote:
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.
Well, I looked extensively for a bug in my code. All I could see, is that it was screwing up the reference counting when casting between types (meaning I end up with an extra shared_ptr, but with a different type). That's supposed to work.
Quote:
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.
it wouldn't surprise me if compiler time is dominated by the processing that takes place later.
By a factor of up to 20?! You're kidding. Unless it's written in AmigaBASIC or so it should have a similarly low footprint as the GLSL/preprocessing-compilation-part. Okay, an alternative reason for that extreme slowness here would be your disabled optimizer. That explains it, of course.
Quote:
Well, I looked extensively for a bug in my code.
Then, with almost absolute certainty, you simply didn't look extensively enough. I definitely second kas1e on this:
Quote:
kas1e: 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.
Your approach "I got issues with boost when optimizer turned on, so I globally disable the optimizer" is certainly not a good way of doing things. Keep in mind that in 99% of all such situations the reason for failure is the programmer, not boost, not the stl, not the compiler (that's especially true for "it works if optimizer disabled"). Use the optimizer as a tool to validate your code, not the other way around like "disable the optimizer to hide my bugs". Failures in high optimizer levels are (almost always) indicators for subtle self-made bugs that otherwise simply are less likely to show symptoms, which is most likely what you achieved by turning off optimizations - but you didn't fix anything.
Quote:
Using std::shared_ptr<> would be preferred.
Is there a reason why you didn't do this replacement a long time ago, especially if you believe that the problem is because of a boost-pointer-casting issue? Should be very quick and unproblematic operation.
Quote:
All I could see, is that it was screwing up the reference counting when casting between types (meaning I end up with an extra shared_ptr, but with a different type).
Out out curiosity: how does this code snippet look like? And what means "screwing up ref counting"? One too high? One too low? Two independent ref-counters all of a sudden? Random value?
However, if you just cannot find and fix the bugs and disabling the optimizer at least improves stability to the current state then I strongly suggest to try to keep a high optimizer level for some critical units or functions. Or, maybe even easier: use -O3 and then manually remove single potentially critical optimizations again via -no-XXX etc. This could also help you to get an idea of the type of your bug. Or the other way around: use the low -O you use now and manually add the respective optimization flags until it becomes unstable. Everything is better than to fully disable optimizations!
And if at the end of the day it really should turn out that you tapped into a true boost or compiler bug, then concentrating on changing the critical construct should be the chosen approach, not global optimizer deactivation.
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.
It's an every-day serialization problem, it's certainly much less harder than you think at first glance. But yes, it isn't something with high priority. Especially if we could get some optimizer, please.
Edited by Daytona675x on 2019/7/26 9:10:00 Edited by Daytona675x on 2019/7/26 9:11:04
Your approach "I got issues with boost when optimizer turned on, so I globally disable the optimizer" is certainly not a good way of doing things...
Actually, my approach was to spend days trying to figure out what was going on before finally considering that maybe our rather old version of boost** plus a much newer compiler might be to blame.
Quote:
Is there a reason why you didn't do this replacement a long time ago, especially if you believe that the problem is because of a boost-pointer-casting issue? Should be very quick and unproblematic operation.
Because I have a huge to-do list and limited time. I did start changing it at one point, but it quickly became clear that the slight differences between boost and std are just enough to be a pain, and I couldn't spare the time. So, I reverted the code and shelved that for sometime in future.
Quote:
Out out curiosity: how does this code snippet look like?
No idea; it's been years since I looked at it. Besides, if I knew exactly what code triggered it, then I'd have fixed/worked-around the problem. The crash does *NOT* occur where things go wrong, but is delayed to wherever the counter ends up being 0.
Quote:
And what means "screwing up ref counting"? One too high? One too low? Two independent ref-counters all of a sudden? Random value?
Either one (or more) too low, or two separate ref counters. Otherwise the object wouldn't be deleted while it's still in use...
I consider ending up with two separate ref counters to be unlikely. The only way to do that is to do something stupid like: shared_ptr<Obj> newPtr = oldPtr.get(). That's guaranteed to crash even with the optimization level at 0. Copying/casting one shared pointer to another should *NOT* split the ref count (or mess up the ref count, for that matter).
Quote:
It's an every-day serialization problem, it's certainly much less harder than you think at first glance.
Of course it isn't that hard. However, it's a whole lot more work than just dumping the binary to disk.
I consider ending up with two separate ref counters to be unlikely.
Consider to be unlikely? If you had spent enough time with the issue and came to the conclusion you came to which resulted in the sledge-hammer action you did, that's a bit vague.
Quote:
Otherwise the object wouldn't be deleted while it's still in use...
Actually, that would only be true if your program's state wouldn't be so corupt that you don't really know anymore what's the cause and what's a symptom and deactivation of the optimizer is your only way out...
Quote:
my approach was to spend days trying to figure out what was going on before finally before finally considering that maybe our rather old version of boost** plus a much newer compiler might be to blame
If that was your final consideration some years ago after just days then ...
Quote:
but it quickly became clear that the slight differences between boost and std are just enough to be a pain
... this is even less understandable. What differences should that be which cost so much time and pain? This is not comprehensibly at all. I mean, maybe (although unlikely) it's indeed a bug inside that shared_ptr and not your own somewhere. But then one would expect that you do everything to get rid of it, especially if the "workaround" is causing insane slowdowns and it's not your fault! It's just a smart_ptr replacement, no rocket science. If you used them correctly replacing should be easy and painless. Or you could write your own with the same interface (doesn't even have to have fancy inplace alloc of the control block or so, just good enough to be a replacement to rule in / out boost or to help further analyzing).
A pain is the current "solution" for apparently years now, namely to practically fully deactivate the optimizer! And a pain is to hear that this decision was made based on a vague guess because analyzing was stopped too early and what's supposed to be a temporary workaround became standard for years.
Quote:
However, it's a whole lot more work than just dumping the binary to disk.
Yes, it's probably a one day job. And good news: you don't even have to dump it to disk
Quote:
Because I have a huge to-do list and limited time.
All this doesn't make sense. I will talk to Matthew, maybe he isn't aware of this and its severity. Clearly this bug-fix issue should have the top priority that it deserves and it should be the other way around: all your other stuff should be on hold to give you the neccessary time to truely analyze and fix this issue.
Sometimes a man has to do what a man has to do, yes, even if that means to get out the sledge-hammer. I did so myself more than once in the past to get things up and running quickly. But only if the price was reasonable. Unfortunately here it's not.
What about the partial optimizing hints from above at least? No time to try these neither? Would probably get us an equally potentially broken but at least faster lib.
If you need only boost::shared_ptr, I would imagine you can import a more recent version to your project in a reasonable time. It shouldn't require porting.
I noted in that bugreport the way how to find out which exactly kind of optimisation make it all behave badly + all the info we discuss. Hope it will help more.
Btw, is -O1 already cause problems ? I assume it is, as if you disable whole optimisation as you say.. via -O0 probabaly ? If -O1 already start to make it bad, then all flags which contain -O1 level can be added one by one manually as Daniel said , and in end find out the guilty one (or ones), which will point out on the roots of problem. At least you will know what exactly optimisation cause it.
And even, if you will not able to fix issue in acceptable timeframe, you at least can find quickly what optimisation flags can be added from -O1, -O2 and -O3 (again as Daniel says before:) ). Maybe alsmost all of them, just without some from -O1.
All the flags which containt those O1,O2 and O3 described for example there:
I.e. generally, you even can not fix issue right now, but you can find out which optimisation flag is guilty, skip it, but enable all the other ones, which for sure will make it all faster.
There i descibe what it and for what, give a link on opengles2() description of the same kind of functions. By link there also example of code, which mean that those functions don't need to save or load anything to/from disk, they doing all in the memory, its coder who save/load it. Also binary format can be choice any, its up to driver's coder.
Of course, firstly first bug need to be deal with. Because, it possible that in end, after fixing issue and/or turning on all (or almost all) optimisation may make warp3dnova's compilershader() works that fast, that we can't see problems visually, then that enhancement request can be forgotten for better times. But if compilershader() optimisation will be not enough, then those new functions will be need it.
As usuall i am ready to any tests.
Just Mattew should know that more work on warp3dnova need it, as bugs keep collecting and optimisation need to be enabled everywhere. Probabaly he think all is fine already, and not thinking it is worth to pay for more warp3dnova work :)
I feel you already burnout a bit with all those new projects Mattew throw at you, maybe keep them all on pause, and instead focus for 3-4 weeks on NOVa again ? :) Just asking, as you know how to do it all yourself, of course :)
Maybe, but I'd much rather migrate to std::shared_ptr<>.
@kas1e
Quote:
Btw, is -O1 already cause problems ? I assume it is, as if you disable whole optimisation as you say.. via -O0 probabaly ? If -O1 already start to make it bad, then all flags which contain -O1 level can be added one by one manually as Daniel said , and in end find out the guilty one (or ones), which will point out on the roots of problem. At least you will know what exactly optimisation cause it.
From memory, -O1 used to work until I updated GCC to yet a newer version. After that, I had to disable optimization entirely. I never had the time to look into specifically which optimization triggered it, and nor do I have that time now.
I do hope to take another look at this at some point, but for now it's working reliably and I really do have other priorities.
[quote]I feel you already burnout a bit with all those new projects Mattew throw at you, maybe keep them all on pause, and instead focus for 3-4 weeks on NOVa again ? :) [quote] I have more work than only what Matthew gives me. My top priority right now is to increase my income, and that's *not* going to come from A-EON.
@Hans De nada, you know that you're always welcome, although there wasn't sooo much of an opinion inside but rather questions that got skipped (e.g. what's so hard about shared-ptr replacement), hints on how to easily get back some speed, analysis of the situation.
@Capehill Quote:
If you need only boost::shared_ptr, I would imagine you can import a more recent version to your project in a reasonable time. It shouldn't require porting.
Very very very good point!
@Hans Quote:
Maybe, but I'd much rather migrate to std::shared_ptr<>.
And very very very sad answer, considering that you already said to have given up on this before for unknown reasons, despite being so convinced in this old boost::shared_ptr being the culprit. Capehill's approach would likely be a matter of some minutes! This shouldn't interphere too much with any other stuff on the todo-list, even less than the try-manually-adding-optimizer-flags.
But well, I see that you won't move no matter what, so be it so.
Are you able to provide a test build with instructions? I built the latest ScummVM but cannot get the themes work - only the built-in green/black works for me.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
Hans?
