00:17.36 | *** join/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ayrzqtxnckggwsqd) |
00:17.36 | BZnotify | [13bzflag] 15allejo pushed 1 new commit to 062.4: 02https://git.io/vxo5L |
00:17.36 | BZnotify | 13bzflag/062.4 14899992b 15Vladimir Jimenez: Update ChangeLog with changes since 2.4.12 |
00:17.36 | *** part/#bzflag BZnotify (BZnotify@gateway/service/github.com/x-ayrzqtxnckggwsqd) |
01:36.14 | macsforme | what kind of system/OS/GPU was the 4% increase demonstrated on? |
01:38.17 | macsforme | I wonder if it also depends on what is being displayed, e.g. lots of flags |
01:39.10 | blast007 | I was using my Decks server, in observer, with /roampos 0 |
01:39.49 | blast007 | only place I saw a performance increase (thus far) was Intel HD 2500 on Linux |
01:40.14 | blast007 | need to hook up my system with a radeon tomorrow |
01:40.26 | blast007 | I should try my laptop too |
05:57.27 | *** join/#bzflag I_Died_Once_ (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
07:17.25 | *** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001) |
07:33.23 | tupone | i did measuring time not frame rate. and from 17 msec went to 16. but i am not so sure |
07:34.50 | *** join/#bzflag gustavo (uid290782@gateway/web/irccloud.com/x-iyuisxuyzklwuxdm) |
09:58.42 | blast007 | no performance difference (on Decks) with a Intel GMA 4500MHD on Debian (both were getting 85FPS) |
10:00.01 | *** join/#bzflag catay (~smertens@valyria.catay.be) |
10:30.24 | tupone | however both client array and list are deprecated on latest openGL. i would like to go in that direction. maybe i will remove my jitter |
10:31.40 | blast007 | "latest" being what? talking about 4.6? |
10:33.18 | blast007 | do you have vsync turned on by chance? 16-17ms is about 60FPS |
10:35.48 | blast007 | lowest FPS I can hit at 1920x1200 resolution (with Intel HD 2500) is 70 FPS, and that's on a mesh-heavy map (Rats Nest) |
10:50.33 | tupone | vsync turned on |
10:54.10 | tupone | latest is i think any where fixed pipeline is removed. non in compatibility mode |
10:54.46 | blast007 | so turn vsync off... otherwise you're just going to be limited to 60FPS |
10:55.33 | tupone | i knew that y and t measure two different things. |
10:55.48 | tupone | i need to check |
10:58.17 | blast007 | 1000ms / framerate = average frametime vs 1000ms / average frametime = framerate |
11:42.51 | tupone | ok. then i need to change that here. i wanted to know the cpu time to elaborate a scene |
12:42.05 | macsforme | that method of benchmarking seems very specific to your own GPU and driver |
12:44.58 | blast007 | macsforme: I wouldn't even call it a benchmark since he had vsync enabled and was hitting the limit before and after the changes |
12:47.11 | macsforme | does the frame time include the buffer swap and vsync delay? |
12:48.09 | macsforme | I get a 1-2ms frame time with vsync enabled on the quick test I just did |
12:48.38 | blast007 | I get 16-17ms with vsync enabled on linux |
12:49.21 | blast007 | 4-5ms with vsync off (and around 160FPS) |
12:51.17 | macsforme | huh, so maybe another implementation-specific issue (so yes, you're right, not really a benchmark at all) |
13:35.45 | blast007 | with an AMD card on linux, with vsync on (still trying to figure out how to disable) it does show 4-5ms even though it's running at 60FPS |
13:37.52 | blast007 | or maybe it's 3-4ms |
13:38.13 | blast007 | and oddly, I can get the FPS to drop to 47, but it's still showing a 3-4ms frame draw time |
13:55.16 | blast007 | okay, managed to disable vsync on that system.. FPS drops from 75 with the old code to 67 with the new code (though both are saying 5ms frame draw time.. so I don't know how that works) |
13:56.49 | blast007 | so everywhere except Linux+Intel, I'm seeing a 5 to 10% performance hit with the new GL1.5 code. |
14:03.50 | blast007 | (and I don't have a Windows+Intel system to test with) |
14:08.04 | macsforme | odd... I wonder what is contributing to the slowdown |
15:02.29 | blast007 | got a few hundred packages to update on my Debian+nVidia system, and then I'll test there too |
15:15.55 | blast007 | oh, I guess it was over 1600 packages... |
16:57.30 | *** join/#bzflag nadir (uid134094@gateway/web/irccloud.com/x-fyssxxtduoqyfqhu) |
17:30.11 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
17:50.37 | tupone | the change is dropping list and using vbo. so it seems that compiling list is better then using vbo |
17:51.48 | tupone | but is not the path to go opengl 3 or gles |
17:51.54 | macsforme | or possibly switching between the two methods is more expensive than using one or the other exclusively |
17:55.24 | tupone | the flag code and the mesh code is different. flag did not use by default list. but vbo are created and deleted each frame. |
17:58.03 | tupone | maybe measuring only one of the two can give hints. |
17:58.53 | tupone | i cannot do now cause i am away from home |
18:18.41 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
18:18.58 | macsforme | if it's re-creating the VBOs every frame then I don't think the GL_STATIC_DRAW usage hint is correct... should probably be GL_STREAM_DRAW |
18:20.40 | macsforme | you're also using the GL_STATIC_READ usage hint for the MeshFragSceneNode... that doesn't seem correct to me either |
18:22.19 | macsforme | so perhaps with better usage hints there would be improved performance |
18:34.35 | blast007 | hmm, can't seem to get my nVidia driver to be stable on Debian. Super flaky just in Gnome, and when I try to run the game it just crashes Xorg back to the login screen. |
18:47.36 | *** join/#bzflag disco- (~disco@unaffiliated/disco-) |
19:52.28 | *** join/#bzflag zuii (~cauchy@BC9C5B1F.mobile.pool.telekom.hu) |
22:57.02 | macsforme | I tried changing the two buffer hints to GL_STREAM_DRAW and that didn't reduce the mild performance reduction on my machine |
23:45.58 | *** join/#bzflag Notify (~notify@104.225.5.10) |