Closed kas1e closed 6 years ago
Not much things in that log, but the workaround is used. So without it, it will probably not run fine without the fix in the driver.
I'll build ioquake3 with GL driver on my side tonight also.
Uhm, last version can't build:
libgl4es.a(fpe.o): In function builtin_CheckVertexAttrib': fpe.c:(.text+0x1310): undefined reference to
isBuiltinAttrib'
libgl4es.a(fpe.o): In function builtin_CheckUniform': fpe.c:(.text+0x1400): undefined reference to
isBuiltinMatrix'
libgl4es.a(shader.o): In function redoShader': shader.c:(.text+0x1cb0): undefined reference to
ConvertShader'
libgl4es.a(shader.o): In function glShaderSourceARB': shader.c:(.text+0x20b0): undefined reference to
ConvertShader'
collect2: ld returned 1 exit status
Probably because of new changes about preproc.c stuff, etc ?
Ah, that because shaderconv.c can't compiles:
src/gl/shaderconv.c: In function 'ConvertShader': src/gl/shaderconv.c:220: error: 'pBuffer' undeclared (first use in this function) src/gl/shaderconv.c:220: error: (Each undeclared identifier is reported only once src/gl/shaderconv.c:220: error: for each function it appears in.)
Ok, it was DBG(printf("Shader source%s:\n%s\n", pBuffer, fpeShader?" (FPEShader generated)":""); , so commented out at moment, rebuild quake3_gl4es, run.
Visually almost the same, maybe little differences:
http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/screen2.jpg
And full debug output:
http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/output_full_debug.txt
Can be that it just other issues, not related to vertexattribs. All in all its just menu, not game itself..
As i can see from log, shaders are simple and primitive ones (so just for menu that understandable). And mostly only usage of textures going on. So probably it can be indeed some other issues
By the way, i tested Cadog without workoround : it of course draw a bit wrong things, but it works. Some parts just missed, but no mess of course like in quake3.
I have fixed the issue with DEBUG.
Now, for the menu, I have to check tonight at home. quake3 engine can use lots of different type of texture, so maybe one type is not bigendian friendly yes.
Mmmm, after checking the log, I see no exotic texture. Only regular RGBA/UBYTE here...
Yeah, there really not much happens, just a menu. Same quake code works ok with minigl, so code is ok too(what mean ppc related parts in games code also ok). Also if cadog and letters fall kind of works with my hacked sdl1, then quake should too, imho..
To add, i do not use pandora's settings from your makefile, but my own. But imho there is nothing gl4es special in quake's code was done, pure as pure ?
Yeah Pandora settings on the Makefile are for activating ARM Cpu optimisation, special keymap, and activating GLES 1.1 renderer. You need nothing of that so custom settings sounds good to me.
I'll test tonight with GLES2 backend to see what is happening. (you can try to run it with the environnement variable LIBGL_MIPMAP=1 maybe, to force all texture to use mipmap).
Tested with settins LIBGL_MIPMAP to 1 : no differences. Maybe a little different looks of distortion, but still the same.
It also need to be noted, that whole game's logic works: i.e. if i press "enter" few times, i can see changes in that distorted mess, etc (so i go to the game). I also can heard sounds.
I also can for example press "2 times enter, 1 times up, then "y" " , and so to exit from game.
I even can press after running "4 times enter, 6 times down, 2 times enter", and game kind of starts, but its all looks reall straaaaange: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/ingame3.jpg
And music start to be "jump" (probably because of sync with frame rates which broken).
But as you say that it works for you with GLES1.1 renderer, then it may be that GLES2 renderer need fixes ? But that to be seen once you build your version over GLES2, and we will know where to start :)
Some good news !
After i lower every possible settings to minimum, it starts !! Menu works, games works ! Through it slow like hell (1 fps), probably because of enabled debuggin.
So for first will try to disable debugging, and for second will try to found what options exactly give problems for us.
A texture size issue?
Note that you can trigger some internal texture shrinking also, with gl4es, using LIBGL_SHRINK=10 (10 is an example, there is a lot of possibility, refer to the USAGE.md file for detail). Shrink is not usefull here, as the engine as integrate downsizing, but it's interesting that reducing size of Texture make it work.
Ok, with disabled debugging, it give 5fps only :( On the same place where minigl give 22fps.
Thats very strange, i expect to have about 60-80 fps at least in compare with MiniGL...
Yeah, something is wrong. Also, I checked texture size with previous log, and they are not that big. Max is 512x512, so it's not big. All textures are POT. some are not sqare, but there is really not much pressure on the texture side.
What did you disabled in the config exactly?
Found also, that its the GL Extensions, which make it looks messy. Once i disable them, all works, once enable all in mess.
But most important question is : where is FPS :)
I mean, it should be about 50-100-150 fps, as MiniGL have 22 (at that with software TCL, etc)
It should at least be 20fps, and probably more, not 5.
What GL Extension seems to break rendering?
Do you think it should be on pair with MiniGL ? I mean, minigl are TCL in software, so, all gl4es stuff which use more that few arrays should be faster a lot. At lest in 2-3-4 times for sure ?
As for what GL Extensions : dunno, just ioquake3 have options "disable / enable gl extensions", which ones exactly dunno, i just do disable them from minigl version, and then can run gl4es version.
I also was able to build some version of quake3 we have on os4 without SDL1 at all (pure minigl), so there i swap on creating gl4es-ogles context, etc : same 5fps :( So we can rule out SDL1 as potential perfomance penalty.
Well, Transform and Lighting will be done in some Vertex Shader with gl4es. If vertex shader are executed in the GPU, then yes, you should see some improvement. But vertex shader can be implemented on the CPU (not the Fragment Shaders), in that case, speed will not change much.
I'm home, I'll build ioquake soon and see how it runs o the Pandora.
But vertex shader can be implemented on the CPU (not the Fragment Shaders), in that case, speed will not change much
But probably not with our case, as gl4es works over ogles2, which works over warp3d which all the shaders implement over GPU only.
That why i think it should be around 50 fps at minimum. Also our MiniGL is done a bit "wrong" in terms of coding, so not only TCL is impact, but just in whole all should be better.
I was thinking about SDL1 being problem, but as i post in previous message, i build version without SDL1 at all, which give same 5fps.
Through, from good news , is that there is almost no visual glitches. I.e. gl4es/ogles2 render all practically correctly.
Main problem for now is where FPS :))
About the extension, looking at the log, here is what ioquake find:
Initializing OpenGL extensions
...ignoring GL_EXT_texture_compression_s3tc
...GL_S3_s3tc not found
...using GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array
...GL_EXT_texture_filter_anisotropic not found
So there is 3 candidates: GL_EXT_texture_env_add, GL_ARB_multitexture and GL_EXT_compiled_vertex_array.
I also change in the quake3 option "lighting" , from "lightmap" to the "vertex", it then give 10 fps. But then, minigl with the same settings, give 40fps.
As for extensions, yeah.. but that for sure can't be reassons of low fps ?
No. I have no explanation for the low fps for now.
But it would be interested to understand wich extension. Multi-texturing may have a big impact on fps, and having it disabled is not good.
Related to extensions: from another side, when i press on "driver info" in the quakes3 settings, it bring me a lot of extensions from gl4es. But not sure if they will be used of course (but maybe it try, and crash because of it ?)
No, the "glinfo" gives all the extension present in the driver. The one used are simply the few I listed.
That what i have in MiniGL version when press on the "driver info" in quake3 settings: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/mgl_extensions.jpg
And that what i have in GL4ES version when press on the "driver info" in quake3 settings: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/gl4es_extensions.jpg
That's quite some extensions supported in gl4es ;)
Just to be sure it doesn't try to use an OpenGL 2.0 renderer, can you launch it with environement variable "LIBGL_GL=15" to force OpenGL 1.5 and not 2.0
Seeting LIBGL_GL enveronment to 15 make no differences. Also when i build quake objects, i can see that only "renderer1" ones is builded. Or you mean its gl4es may try to use opengl2.0 by default ?
But then, setting LIBGL_GL environment to 20, change nothing at all. Same looks, same 5 fps.
You should try to find wich extension break things: reactivate the extensions in ioquake3, and mess with the exentions string in gl4es so iq3 doesn't find them. It's in src/gl/getter.c
. Then reactivate the extensions one by one to see wich one break rendering.
Ok, will try now.
But interesting to know, how it runs for you over gl4es / gles2 :) Maybe there some general problem.
It's not built yet... The Pandora is just an Arm @1Gz, it's not super fast...
To add, in MiniGL i have 22 fps with disable extensions as well. With enabled it give 23 fps, which jump most of time back to 22, so probably no differences at all.
But i will try to find which one mess the things.
Ok, probably found right from begining, i just doing that in getter.c:
"GLEXT!!!!compiled_vertex_array "
So, when i enable gl extensions in quake, i have: multitexture: enabled compiled vertex arrays: disabled texenv addd: enabled compressed textures: disabled
And then, no trashing. Rechecked again with gl4es where i didn't mess that extension in the getter.c , and it trashes. So its cleary GL_EXT_compiled_vertex_array which mess things up. Will report that one to Daniel.
But then, as in case with MiniGL, those extensions almost make no differences.
By the way, in the MiniGL version compiled vertex arrays is disabled as well (just to rule out gl_extensions as perfomance penalty).
Finished building on my side.
Working perfectly on GLES2 backend on the Pandora. Graphics are just fine, and the demo runs at 40fps, with some parts lowing down to 22, and sometime up to 60fps...
That kind of bad news then ! My machine are 2ghz cpu, with some good radeon (2 years old only), so it should be about 100 fps then.
uhm ! strange !
So that GL_EXT_compiled_vertex_array extension ensable the use of glDrawElements(...)
. Without it it use glBegin(...)
/glEnd()
blocks. So this is consistant with the issue with vertex size.
I'm still unsure why it would be that slow. Are you able to do some profiling?
Daniel ask me to pack everything up, so he can profile it , let's see. But as you have on 1ghz machine results even better than with minigl.. Then it shows !
Btw, when i say "22 fps", i mean you just run the game, and go to the first strage, and once it loads, you didn't move. What you have then there ?
Also, you set no special environments ? All just works as it ? With latest commit of gl4es ?
Ah yes, at main menu I'm only at 10fps. Strange, I think I remember it was (much) faster on GLES1.1 backend.
Also yes, it run without setting enything, with all default settings (geometry high, light map...)
The slow down seems to be caused by the large mirror in front of starting point. If I move and look else were, fps jumps at 40fps.
Ok, 10 fps with lighting lightmap or vertex ? It can be, that gl4es give us that framerate for example ?
I mean its strangely the same fps for both of us
I have done a quick profile, and most time was spent in actual drawing (in gles2 driver). Nothing really wrong, I'll see if I can get an GLES2 Trace of that.
Same for me . If i move away from mirros, fps in some places can be even 70 (if you move back from mirror), and if you move left-right from mirros , around 30.
But that pretty bad values. Our minigl which is coded real bad, have 22 fps when i wath in the mirror, 80 when i move to the left, 100 when i move to the right, and 90 when i around so mirros at my back.
Can you check with GLES1.1 as well ? Maybe its just GLES2 rendering slow things down (some slow shaders, or something)
I have just checked with gl4es but using GLES1.1 backend. That should be equivalent to your MiniGL. I get 22fps looking at the mirror... I'll try to get a GLES2 Trace of that rendering, to see what is happening.
@ptitSeb Was able to build quake3 from your sources, for both, minigl and gl4es. In minigl version everything looks and works correct. In gl4es version, games starts , first image anymation come fine (that one with ID shoot in), and then when there should be shown "CD KEY , please enter your cd key, ACCEPT", i have instead nothing , just still ID there. If i then press "enter" again, so to go to menu, then i see, that something start changes visually, but all distorted and wrong. Have a look at screenshot:
http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/first_run.jpg
And there is console output: http://kas1e.mikendezign.com/aos4/gl4es/games/quake3/first_run_console_output.txt
At moment it is yesterdays's version with enabled workoround we do and almost without debug enabled (only fpe one seems so).
So i will for now try to build latest commit version (where we have no workorounds), as wel as will enable whole debug everywhere.