Knowing that you are busy with everything, but just to remind after 2 months, is it possible that you can find some time soon to working on nova again ?

Also, what you can suggest of how can we debug why Nova fail to made FrickingShark shaders works correctly, while compile them fine ? (taking in account, that shaders are ok, and that on win32 and linux version the same code which use those shaders works correctly).

i was able to build old supertuxkart (that 0.6.2a version) over gl4es

Does that mean the game would run on Polaris cards, where minigl is currently a no-go?

It is 469 draw calls per frame (!). Visually when you play , it vary from 5 to 20 fps. 5 fps when many cars close to you, and 20 fps when you draw alone on track.

What i also notice now (after i able to play full track, thanks to new PROFILE option in glsnoop), that actual timewaster are W3DN_BufferUnlock() (if take in account, that we add already most usable functions and that this % do not include ogles2 values).

Back in August of 2016, the Sam460ex managed about 25.6k draw-calls/s (measured using Daniel's boingtest).** IIRC, the X1000 managed about double that, but I can't find the data to confirm.

Your test had about 9.2K draw calls/s with the driver using about 47.12% of CPU time (scales up to about 19.6K calls/s if GLES2 + Nova were using 100% of CPU time).

The number of draw calls/s goes down as the amount of data that's transferred to VRAM increases. So, more shader constants will slow it down, as will more and more vertices. This is why developers should use VBOs instead of vertex arrays...

What system was this test on? If it's a Sam460, then the draw-calls/s bottleneck is probably a big factor. If you're using an X1000 or X5000, then the number of vertices/s being copied to VRAM is probably having a sizeable effect.

That's to be expected. Data is copied to VRAM when the buffer is unlocked, so this is probably the slowest operation. We still lack GART support, so the transfer is slow...

Yes, lot of time spent in the creation of buffers. Does this operation really necessary? I mean, can't NOVA works without buffer (with just main CPU memory) via some environment or something ?

Also what he say about missing of GART on our side, that its unfortunate the reassons for slow gameplay in STK0.6.2a, he say that :

---
Mmm. I see, but that's unfortunate. Most of those legacy games are not using VBO, so need to transfert data every times (and even if they were using VBO, gl4es would not anyway). VBO are bit special. Testing on the Pandora showed me that use of VBO actualy slowed down things on graphic intensive game (that was Doom III). And because gl4es is targetted to embedded SoC and SoC mostly have shared memory for VRAM, I'm still not convinced VBO would speed up anything. I still have some idea on were use VBO easily, but I don't much incentive to spent time on something that I'm not confident will improve anything (except complexity on gl4es).
---

Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 0, internalformat 6407, width 64, height 64, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call
Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 1, internalformat 6407, width 32, height 32, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call
Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 2, internalformat 6407, width 16, height 16, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call
Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 3, internalformat 6407, width 8, height 8, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call
Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 4, internalformat 6407, width 4, height 4, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call
Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 5, internalformat 6407, width 2, height 2, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call
Shell Process 'foobillardplus': OGLES2_glTexImage2D: target 34069, level 6, internalformat 6407, width 1, height 1, border 0, format 6407, type 5121, pixels 0x67098748
Shell Process 'foobillardplus': GL error 1280 (GL_INVALID_ENUM) detected after call

Shell Process 'prototype': W3DN_FBBindBuffer: frameBuffer 0x63be2aa8, attachmentPt 0, tags 0x66cf1c18. Result 4 (W3DNEC_NOVRAM)
Shell Process 'prototype': W3DN_FBBindBuffer: frameBuffer 0x63be29e8, attachmentPt 0, tags 0x66cf1c18. Result 4 (W3DNEC_NOVRAM)
Shell Process 'prototype': W3DN_FBBindBuffer: frameBuffer 0x63be2928, attachmentPt 0, tags 0x66cf1c18. Result 4 (W3DNEC_NOVRAM)
Shell Process 'prototype': W3DN_FBBindBuffer: frameBuffer 0x63be2868, attachmentPt 0, tags 0x66cf1c18. Result 4 (W3DNEC_NOVRAM)

"44 % of total context life-time" means that if context exists for 100 milliseconds, then known calls used 44 milliseconds of that.

Let's see if it can be simplified somehow. (my head is spinning too)

Added a check for W3DN_Submit() return value, and it seems that Foobillard+ and Prototype have one-shot errors where Submit (first, maybe?) returns 0.