There's no bug in the way; it's all about optimization. However, I'm not sure why it's 30% slower, or how to optimize it. We don't have tools that could identify the bottlenecks (e.g., cache misses, etc.), so it's more guess work than anything else. I suppose I could try insert some cache prefetching instructions to see if that helps.
Its even not 30%, but almost 35% slow down.. Anyway i am ready to do any tests in fast time line :) Just send me any version with inserting cache prefetching instructions so we can see how it will behave and will there be any change.
In general, even if it will be not faster than with Daniel's patching code, it at least should be the same at minimum (i mean it can be even a little bit faster, as warp3dnova is more low-level than ogles2).
I also do check serial output , in hope you may forget to remove debugging stuff which make it slow down, nope, all clean on serial.. (if only you have some internal debugging code for patching left ?)
@Daniel,Hans I already asked about Capehill in SDL2 thread, but that can be and not because of SDL2, so maybe some of you may have some ideas what can cause that:
I build quake3 via SDL2/gl4es , and some time (not all the time, but from time to time, mostly when there is something else running which use warp3d/ogles2, like Candy for example, or Spencer, i.e.to fill VRAM more), then on running it looks like this:
(for all images press open image in new tab for full size)
Another time it may looks like this:
If i switch resolution, distortion removes, but then, mouse movement leave such trails:
It even can be like this:
I.e. can be seen some part of previous background from video, like it didn't erased fully.
I ask ptitSeb for help, and he do trace of how that black background draws in the q3 , and there noothing spectacular:
It's drawn using a fully white texture (the 2nd loaded texture) that is 8x8 RGB. It's setup as GL_REPEAT (if both direction). The color is applied is obviouvly black (using 4 GL_UNSIGNED_BYTE arrays), the vertices are 3 GL_FLOATS and textures coord are 2 GL_FLOAT.
Blend is activated, with GL_BLEND_SRC_ALPHA / GL_BLEND_ONE_MINUS_SRC_ALPHA, so with and RGB texture is the same as no blend. Depth text is also activated.
Of course, he on Pandora didn't have anything of that sort. And he say they (ioquake3) didn't change the way how it draws. He use some older build of Quake3 based on SDL1 , so, i can't rule out gl4es as well of course (but, most of time, it wasn't gl4es in end , so it is probabaly something on our side).
Quick answer: try inserting code to clear the depth buffer to a constant value when it's first created. You may wish to stick that code in GL4ES (or GLES2), because there are multiple programs using the Q3 engine that make this mistake.
Longer answer: That reminds me of something we saw with the old W3D_SI driver and OpenJK (which is based on the Q3 engine). Basically, the game doesn't clear the z-buffer prior to use. Since we're using a floating-point depth buffer, that means it may contain illegal floating-point values, which causes some pixels to fail the depth-test when they shouldn't. Pandora may well use an integer depth-buffer, in which case this can't happen.
In the W3D_SI driver I worked around this by clearing the depth buffer on allocation. I tried to do that too in Warp3D Nova, but Warp3D Nova is more complicated, e.g., you can have depth-textures. So I guess the workaround doesn't actually work.
@Hans But then it should be the same and when i compile quake3 via SDL1/gl4es. With SDL1 it for sure didn't happens. I tried hard : running spencer, some gl4es game and then sdl1 version of quake3 compiled via gl4es : all fine. But with SDL2, its enough to run one single instance of something which use warp3dnova/ogles2, and then running quake3 compiled via SDL2 will cause that distortion.
Maybe in SDL1 there is some hack for it was done ?
@Hans Ptitseb says that yeah, that make sense, and also SDL1 and SDL2 may create the context slightly differently, get a depth+stencil in a side and only depth in another side, or with different bits 16 against 24.
I then check what kind of values have SDL1 and SDL2 for depth and buffer when create context, and while stencil always TRUE (0) , in both cases, DEPTH for SDL1 was 16, and 24 for SDL2. But when i set hardcode 16 for SDL2 as well, it didn't help at all too.
That strange , but maybe in SDL2 somewhere else something related to depth/stencil done, which didn't for SDL1.
Anyway, to test that theory we just after swapbuffer do: glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
And it did the trick. But that mean its kind of hack, will give a little speed loss where it don't need as well as still strange why SDL1 behave different in that respect..
Another little issue i notice also , is that in the same menu, i can see a little small white point when run in window mode : it is where real amiga cursor stays. But that probabaly related just to SDL2 itself..
That little dot where the hotspot of the mouse pointer is, is known since SDL2 got released the first time (I have it in ScummVM aswell), that isn't a problem in SDL1.
Normally you wouldn't see it as the pointer used would draw over it, but whenever there is some lag and the pointer behaves sluggish it's very good to see as the little dot moves faster.
There seems to be something not 100% erased when drawing/erasing the pointer gfx or SDL2 handles the pointer differently.
@Raziel Oh, that good ! I mean that good that its SDL2 issue and not minigl or gl4es ones. In the quake3 i can notice it pretty well! Is it reported already or should i create bugreport for ?
@Hans Probabaly Mattew still not fix bug-report site and still no notification come when bugreports created.. So i just duplicate it here : i found another issue in the array's support, and made as small as possible test case. Check this out plz there:
I then check what kind of values have SDL1 and SDL2 for depth and buffer when create context, and while stencil always TRUE (0) , in both cases, DEPTH for SDL1 was 16, and 24 for SDL2. But when i set hardcode 16 for SDL2 as well, it didn't help at all too.
Warp3D Nova always uses floating-point depth buffers.
Quote:
Anyway, to test that theory we just after swapbuffer do: glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
And it did the trick. But that mean its kind of hack, will give a little speed loss where it don't need as well as still strange why SDL1 behave different in that respect..
No need to clear the depth buffer every frame; just do it right after it's created.
Perhaps SDL1 does this, as I can't think of any other reason why this would only happen with SDL2.
dprintf("OpenGL ES 2 context %p created for window '%s'\n",
data->glContext, window->title);
// Some games (like q3) doesn't clear the z-buffer prior to use. Since we're using a floating-point depth buffer in warp3dnova,
// that means it may contain illegal floating-point values, which causes some pixels to fail the depth-test when they shouldn't,
// so we clear the depth buffer to a constant value when it's first created.
// Pandora may well use an integer depth-buffer, in which case this can't happen.
// On MiniGL it didn't happens as there is workaround inside of warp3d (and probabaly inside of MiniGL itself too).
// in SDL1 it didn't happens probabaly because SDL1 doing something like that (but not glClear).
@Hans I also found today a crash in warp3d (well, its last line in stack trace, it can be ogles2 too of course). At moment i didn't have small test case to reproduce, but crash happens in code which call glPushAttrib(0xFFFFF) (i.e. mask mean to push everything), and it crashes like this:
Please send me the rest of the crash log. The stack trace alone is not enough.
It's crashing in GetStencilFunc(), but I'd like to know exactly where. I have spotted a potential issue, but the stack trace suggests that it might actually be an invalid Warp3D Nova context pointer.
Probabaly its indeed problem when getting/settings stencil stuff and there is no stencil buffer, as it is allowed to query stencil status even if no stencil buffer is present and change are also permited (but they'll have no effect with no stencil buffer) , but probabaly as we do not have buffer , nova just crashes.
while considering that r7 and r8 are both 0 in this stack trace, I'd like to place a bet on the following Did you maybe forget to check the optional pointer-return-parameters of GetStencilFunc being NULL or not?
Do you really want the responsibility of doing all the endianness conversion?
No, the driver knows best which endianness is needed.
Quote:
If there's enough interest, I could add the ability to check the GPU's endianness and disable the endianness conversion, making it the app's/game's responsibility (or the GLES2 wrapper's).
The only thing that comes to my mind where it could in theory result in somewhat better performance is if you are updating a VBO every frame and have direct access to the VRAM (if you don't then another internal copy is required anyway and then e.g. a tight stwbrx loop is likely better) and if you can do the conversion without poluting your code. IMHO it's not worth the trouble. Althoug... if you can offer that feature for free and optional and if you don't have more important things to do, then go ahead
Quote:
There's no bug in the way; it's all about optimization. However, I'm not sure why it's 30% slower, or how to optimize it. We don't have tools that could identify the bottlenecks (e.g., cache misses, etc.), so it's more guess work than anything else. I suppose I could try insert some cache prefetching instructions to see if that helps.
Maybe the opposite is better. Did you by accident call dcbz on the (VRAM) destination? This could probably result in such a dramatic slowdown. Also: are you 100% sure that there aren't any debugging artefacts remaining?
Other than that: we are talking about Roman's performance numbers here. He has an X5000 and from my experience (!) its automatic cache prefetching works pretty well, in contrast to other PPCs. So, unless you have any weird access pattern (which you should not have?) manual prefetching shouldn't change the picture toooo much in this case here.
But it's hard to come up with concrete hints without source, of course
@Hans I feel your pain, but there is another shader's issue: Just porting another game, and it fail right in the face: this time is fragment one (for fogging), and pretty small one. I attach all the stuff to the ticket (all info, shader, plain output of w3dnshaderinfo, and verbose one). There is:
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
