ZDoom

I'd say the cards are decent enough if only closing the CCC is enough to speed things up significantly - that's a clear case of a VERY BAD software problem.

Sorry for reviving old topic but I found an unexpected solution to this same problem with my Radeon Mobility 4650 video card.
Long story short: close Catalyst Control Center on the taskbar...
I have Win XP SP3 now, I closed all other programs that were running (Chrome and VLC Media Player) and ran Gzdoom. Slowdowns were the same, getting 5 to 6 fps on any Pirate Doom map where there is a wide open area with lots of architecture features. Unplayable. Disabling everything wouldn't solve it, resizing to low-res wouldn't either.
THEN, I had the idea of closing Catalyst Control Center on the taskbar, as someone mentioned on another tech support forum.
BOOM! Just closing CCC stopped with all the slowdowns! I use an external program to cap my fps to 30 called DxTory (so my GPU temps remain under control). Further experimentation showed that after closing CCC, I can run GzDoom alongside other programs without any problem or slowdown. Another proof that ATI sucks major ass! Avoid ATI video cards as hard as you can. Not the first game which has ATI-exclusive problems.

W=walls, F=flats, S=sprites.
Render and Setup are the two different passes, these times are exclusive.

the things I'd like to know is what does W: stand for, F: and also S: - the render and setup is clear, though - does the render time include the setup-time - or do they add up?
And last I wonder what the 'Finish' count

Which specific value may indicate too many sprites though? and does static non-animated non-moving sprites take less than animated moving ones?

You can see if it's too many sprites. But the rest: no.

So I can't really tell from any of those numbers if its too many 3d-floors, too many dynamic lights, too many sprites, too many reflective surfaces, too many surfaces etc. in view?
I hoped to get some insight to the values to be able to analyse various maps and situations myself

Those values measure separate parts of the OpenGL render code, they do not add up because some numbers are the sum of others.

To understand them a bit you have to know that the GL renderer is running two passes: A setup pass and a render pass. This is necessary because some data needs to be sorted and other stuff needs to be rendered in a specific order.
For a normal user most of what gets displayed there is rather meaningless, this is there so that I can check of certain code changes affect performance.

Maybe I'm just not good at searching, but I can't find anywhere an explenation of what the various stats are when using stat rendertimes..
W, F, S - are those walls, flats?? are all values in milliseconds?
Why does total be more than all the other values combined?
I'd like to know what each of the values mean - so I can analyse them

Ok, so the feature doesn't work with ATI. Too bad. I'll leave it in anyway because it works great on NVidia. I'll investigate a better method later but everything I can think of right now is prohibitive in terms of maintenance.

Tested the latest beta (1.3.13) with hexen, I tried to see if "use shaders for lights" finally worked this time (before it just removed all the dynamic lights!) It still doesn't seem to have any good effects though. Random areas of the map gets this black color and there's a huge fps drop when looking at certain directions, here's a screenshot:
http://img253.imageshack.us/img253/572/ ... 091113.png

I tried Cold as Hell again on the airplane. 25-28 fps with the new beta, while previously I had 22-25.
I haven't tried hc20 yet, should do it sometime.

GZDoom 1.3.13 beta, I got 47-48fps at hc20 map09. Awesome work Graf!

I don't have all the bench information. But I just tested 1.3.11 and I was getting 39-41fps on map09 hc20.

I'm going to need more time to do these benchmarks when I get a chance. So I guess I will gradually give you benchmarks on what you want tested.

Project Dark Fox wrote:Though I fail to see what's "crude" about a straight answer. >>;

Crude:

vid_fps

Straight:

The CVAR is vid_fps.

(Alright, now I'll shut up.)

I made one important ATI related change in 1.3.10 and would like to check if it makes any difference.

Randy, could you please run the test again? It should be easier now because I added a 'bench' CCMD that outputs the result directly to a text file.

On a related note, exl has posted some ATI results over at Doomworld that are significantly better than anything else I saw so far using a HD 4870 so I'm wondering if this might all be caused by a badly preconfigured driver.

I can't explain why this one system is so significantly better than anything else that was tested.