1. I use treetest.pk3 to test performance. (The trees which are only behind a slightly lower wall make gzdoom "suffer".) treetest.pk3 file https://zandronum.com/tracker/file_down ... 4&type=bug , https://zandronum.com/tracker/view.php?id=1541 .
2. The last build which runs on my machine is 1905 (July 30, 2016) (see: http://forum.drdteam.org/viewtopic.php?f=25&t=7072 for details). This build gives me 16 fps when I look in the direction of trees and 500 fps when I look in the opposite direction. When I run this build with the parameter +gl_renderbuffers 0 the performance is the SAME (ie 16/500).
3. Builds from 1958 (Aug 06,2016) to 2025 (Aug 19, 2016) run only when I pass the parameter +gl_renderbuffers 0 . The performance then is 5 / 225 (more than 3 time slower than in the previous case. It cannot be due to +gl_renderbuffers 0 parameter because I also passed that parameter in the previous case - see point 2)
4. Builds from 2052 (Aug 21,2016) to 2090 (Aug 27, 2016) do not run at all (again, see: http://forum.drdteam.org/viewtopic.php?f=25&t=7072 for details)
5. Build 2099 (Aug 28, 2016) runs only when I pass the parameter +gl_renderbuffers 0 . The performance then is also 5 / 225
Why is the build 1905 better in performance than later builds when the parameter +gl_renderbuffers 0 is passed? It seems to me that either build 1905 ignores that parameter or one of the commits between July 30, 2016 and August 06, 2016 causes that performance drop.
Performance drop
Moderator: Graf Zahl
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Performance drop
+gl_renderbuffers 0 disables all post processing steps (you shouldn't need to do that anymore after PR91 is merged, it will do it automatically for you).
Why you have a sudden perf drop I cannot say, but +gl_renderbuffers 0 effectively rules out that it has anything to do with the post processing stuff. Based on your description it sounds like it was something that changed between build 1905 and 1958.
Why you have a sudden perf drop I cannot say, but +gl_renderbuffers 0 effectively rules out that it has anything to do with the post processing stuff. Based on your description it sounds like it was something that changed between build 1905 and 1958.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Performance drop
The reason for this is that in the recent builds shaders are always on, and it's very clear that this hardware cannot deal with it.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Performance drop
This should be better with the next build. I again disabled shaders for such old hardware and fixed the issues that prevented that code path from working.
-
- Posts: 18
- Joined: Wed Aug 10, 2016 19:28
Re: Performance drop
Ok, now (build 2105) the performance is 16 / 200 . It runs without the parameter. So it is good. Is 200 an fps cap in this build?
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Performance drop
Yes. ZDoom's default framerate capping feature was added recently and this defaults to 200.
-
- Posts: 18
- Joined: Wed Aug 10, 2016 19:28
Re: Performance drop
I have not been here for a while. I have just tested x64 build 2.5pre-281. I get about 80fps in this treetest map. I do not know what you did but this is a huge improvement. Thanks a lot.
EDIT: Today I run gzdoom and I cannot get 80 fps anymore. I get just 16 again. That is very strange...
EDIT: Today I run gzdoom and I cannot get 80 fps anymore. I get just 16 again. That is very strange...