Is this conversion stuff really a good thing in any case ? I mean as in most case we must peek the data and read them manually to write them in the vbo then perhaps we can order them during the process
I mean if we read XYZ then copy it elsewhere in vbo then read UVW then copy it elsewhere in vbo then RGBA then perhaps can reorder them too...
I mean : disabling the auto-reorder feature can help in some case
Is this conversion stuff really a good thing in any case ? I mean as in most case we must peek the data and read them manually to write them in the vbo then perhaps we can order them during the process
In most cases, you upload the data to the GPU once, and leave it there. So there's zero speed advantage to shifting where the endianness conversion is done beyond the initial copy. This is true even with skeletal animation, which can be done entirely on the GPU.
The one exception I see, is older games like Quake 3, which were created before hardware skeletal animation was possible. In that case, the character models have new poses uploaded every frame.
Quote:
I mean if we read XYZ then copy it elsewhere in vbo then read UVW then copy it elsewhere in vbo then RGBA then perhaps can reorder them too...
I mean : disabling the auto-reorder feature can help in some case
Do you really want the responsibility of doing all the endianness conversion? Bear in mind that you're not guaranteed that the GPU will even need it. Right now, yes, all GPUs are little-endian and we use big-endian CPUs. In future... who knows?
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).
That on x5k with some RadeonHD verde (250 or 250x is it). Strange that is _that_ slow things down .. You may try that test q3 archive i send you before, as well as those ogles2.libraries (public and with removed workoround) to see how it behave on your hardware (and probabaly will be easer to debug if it need any debugging).
Probably when Daniels patch sitting on top of wap3dnova conversion code, ogles2 send already patched data to warp3dnova, so conversion code in nova skips as nothing to convert, and because of this we have same fps as in case with previous nova versions.
@Daniel Is that test ogles2.library with removed patching code compiled as usual, and nothing else disabled ?
Yes, Daniel's patch bypass the new endianness code, and uses the "everything is 32-bit" copy-convert code.
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.
Suggestions from those who are experienced in these kind of optimizations are welcome.
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?
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
