What with one thing or another I haven't got much done recently, so here's another performance milestone that's worth noting.
The scene above (from ne_tower) is my standard "Engine Crusher" - chosen because it places huge stress on both MDL and BSP drawing, with about 6,000 brush surfaces and over 20,000 MDL triangles being drawn in it, and a substantial amount of overdraw. As good a test as any for determining how efficient you're going to be.
Again, this one demonstrates the leap forward that the D3D11 move is going to be. Here we're running it at just over 600 FPS on reasonably low-powered laptop hardware. By comparison, a more traditional GLQuake-style renderer barely scrapes 60 FPS, and the old D3D9 code could manage close to 300 on the same hardware. It's worth noting that the D3D9 code used some extra tricks - in particular hardware instancing - which are actually not used by the D3D11 code.
There are no dynamic lights or lightstyles in this scene, so what we're seeing here is pure polygon and pixel pushing power. An odd thing about the performance characteristics of this code is that it really likes it when you sneak up on it with something like this. More typical scenes certainly won't give you a 10x performance improvement over GLQuake-style code (or even 2x over the old D3D9 versions of DirectQ - although I have measured this magnitude of improvement in some other test scenes). This is the way things should be - the heavy guns come out when the going is tough.
I'm not certain at the moment if that kind of jump is specific to D3D11 itself or is down to the new code structure I was able to write (which wouldn't have been possible with D3D9) - most likely a combination of both.
I've a few other test scenes that I regularly use for benchmarking performance under stress, so I'll probably post some figures from them later.
Wednesday, April 11, 2012
Meet The Engine Crusher
Subscribe to:
Post Comments (Atom)
8 comments:
I've never understood the need for these ridiculous FPS counts. Our eyes can only process from 24-60 FPS, I think, so why the need for such ridiculous numbers. 300? 600? 1000? 1,000,000,000,000,000,000? Who gives a damn; our eyes aren't going to notice a difference. It it some kind of 'PC Elitist' thing? "Well, my FPS is higher than YOUR FPS, so there!"
On the FPS counts, from a gamer perspective it doesn't make much sense to go on about the FPS once it's over 60 because it doesn't really matter.
However from a engine developer perspective it makes sense as it's a way of measuring the optimisation of your engine. It gives you something to compare how you are doing. For running old maps it isn't really much a of deal but imagine if someone used all the extra headroom that has been created by the work done on DirectQ, it would allow for some rather intricate levels much more detailed level design than could ever be done with the original GlQuake.
Coranth, you are simply mistaken.
http://www.pvcmuseum.com/gpu/human-eye-frames-per-second-fps.htm
Side by side it is very easy to see the difference between 90 and 120fps. Ask any serious Q3A player. There's a reason so many esports players resisted lcd panels and their (compared to crt) low refresh rates.
I would love it if a Quake port could stack frames, so its rendering 300 but only pushing 60 to the monitor. Kinda absurd though, I don't expect to ever see it happen.
Labman pretty much nailed one of the reasons. There's nothing much to be gained from going to stupidly high FPS with a combination of low-detail id1 content and reasonably modern hardware. If it's already fast enough then it's already fast enough.
So the extra speed is about headroom. If I know that I can handle a certain scene extremely fast then it means that I can handle a much more complex scene and still maintain good perf. I know that the impact of having a few more dynamic lights go off during a heavy deathmatch is going to be sustainable. I know that a map that can't get a good PVS is going to run well, I know that a mapper going nuts with high monster counts isn't going to stress the renderer too much, and so on.
There's also the fact that as well as the human eye seeing frames beyond 60, going higher than 60 allows for more responsive input, which is extremely important to the MP folks. It means that you're more likely to be able to hit a framerate that is a nice multiple of your mouse polling rate and your refresh rate.
Stacking frames could be done by e.g. drawing to a different render target each frame, then after a certain number of them have been used, average them all out to the back buffer. It would look very nice and smooth, give perfect sub-pixel motion blur, but would be enormously expensive in terms of video memory and bandwidth. You could also fake an accumulation buffer by adding multiple frames to a 64-bit render target, then average them out, which would be cheaper. I kinda do like the idea, might be something worth experimenting with sometime.
Ah, so it's like, 'if I can get an ID1 map running at 1000FPS, then I know that a complex map like Marcher should run well at (insert lower FPS count) and it'll be playable with no lag." Gotcha. Basically, the higher the FPS count, the heftier the maps you can strain the thing with 'cause you know they'll run well due to the massive headroom. Thanks for clearing that up.
Got it in one. :)
An extension of that goes something like: "if I can get Big Map X running at 500 fps, then I can sit back and whistle this time next year when Even Bigger Map Y comes out".
Plus it's fun.
I am finally going back on my engine archive (and list of technical features) stuff and would love to know some good engine crushers. Can you give me the coordinates of that place?
I will use demos that trigger screenshots to automate it for easy comparison.
It's just after you shoot out the wooden boards and hit the switch to lower the bars at the start. Turn right and go to the corner behind you, then look up. It's at -367, -335, -1873.
Post a Comment