City of Villains (Beta) Tests
Update: We would like to clarify that the beta version of City of Villains was stated as non-optimized in the release notes. The test server is open to any CoV subscriber and it does support PhysX hardware, but it is very possible for performance improvements to be made to the implimentation before their production release of the Issue 7 patch. In fact, we have been told by AGEIA that performance on the final code will absolutely be better than on the test server. We look forward to testing and reporting on PhysX support under production CoV code/servers as soon as possible.As with any MMOG, City of Villains has been difficult to test. The fact that PhysX hardware is only supported in a very specific area of gameplay makes it even more complicated. Luckily, we found a way around these issues. As City of Villains makes use of instanced areas for missions (multiple parties entering a single zone will each play the game in their own copy of that area), we were able to eliminate any outside influence from other players and go on a mission solo. Also key in our ability to test the Mayhem Missions (the part of City of Villains in which the PhysX hardware is used) is the fact that it is currently on the test server.
Normally, before a gamer gets a Mayhem Mission, he or she will have to do a bunch of other missions, level up a bunch of times, and unlock a contact called a "broker." The broker gives you access to "newspaper missions." After doing 3 of the newspaper missions, a broker will offer you a special job: a heist. In the future, and on the test server, this is where mayhem missions will be available. Each mayhem mission, once begun, has a 15 minute time limit. This limit can be extended by destroying things in the city, but there is no way to get enough time to actually benchmark multiple configurations of hardware. Doing 3 other newspaper missions and getting another mayhem mission isn't an option because this takes a huge amount of time (the missions can be different every time as well).
Fortunately, NCSoft offers the ability to copy your character to the test server at any time, multiple times. Our solution was to do enough missions to get to a point where we could be offered a mayhem mission (even though the missions are currently only on the test server). Then we copy our character over to the test server a bunch of times. Now we are able to accept the same mission any time we want.
This is great for testing a feature like PhysX, but doing a full test of the game is still hard. Working with a team fighting a huge number of enemies is a key element in the game. It's something that just can't be reliably repeated barring the assembly of an AnandTech guild built solely for choreographing, reenacting, and benchmarking scenes hundreds of times. For now, this is all we need. We included a screenshot of the game options with and without a PhysX card installed:
We created a couple videos to show the difference between hardware accelerated and software physics. Here are the numbers that resulted from our tests.
What we see clearly shows that the PhysX card is putting quite a strain on performance. Yes we get more mail or packing peanuts spewing forth from our rampant destruction. Yes, we do think it looks great with more stuff going on. But we are really not happy with the performance we are seeing here. It appears that our GPU is not overly loaded at these resolutions, as the difference between 800x600 and 1600x1200 gives very little in the way of performance gain without PhysX hardware installed. This implies that the bottleneck in performance is in the rest of the system. This is confirmed by the fact that performance drops considerably when running the test on a much slower CPU.
Whether on a low resolution with a fast CPU or a high resolution with a slow CPU, the PhysX hardware gives us low average framerates, very low minimum instantaneous framerates, and adds a bit of stutter to the movement of the game. Unlike the Ghost Recon test we showed last week, playing the game with the PhysX card feels much less satisfying. Multiple frames seem to take a long time to render (rather than just one or two) giving movement a choppy feel to it.
That being said, it is very important that we point out the fact that we are benchmarking code running on a test server. NCSoft makes it clear that code running on this server is not optimized and players may see degraded performance. We hope very sincerely that the performance issues will be resolved; right now it just isn't worth it.
So why include these numbers at all if it's on a test server? Well, the fact that they back up the results we saw in GRAW last week do lend some credibility the tests. What we seem to be seeing is that games which use the PhysX processor to tack on special effects physics take a performance hit when those effects are triggered. Of course, that only holds if the driver didn't fix the performance issues we saw in Ghost Recon.
Facebook
Twitter
RSS
67 Comments
View All Comments
yanyorga - Monday, May 22, 2006 - link
Firstly, I think it's very likely that there is a slowdown due to the increased number of objects that need to be rendered, giving credence to the apples/oranges arguement.However, I think it is possible to test where there are bottlenecks. As someone already suggested, testing in SLI would show whether there is an increased GPU load (to some extent). Also, if you test using a board with a 2nd GPU slot which is only 8x and put only 1 GPU in that slot, you will be left with at least 8x left on the pci bus. You could also experiment with various overclocking options, focusing on the multipliers and bus.
Is there any info anywhere in how to use the PPU for physics or development software that makes use of it?
Chadder007 - Friday, May 26, 2006 - link
That makes wonder why City of Villans was tested with PPU at 1500 Debris objects comparing it to software at 422 Debris objects. Anandtech needs to go back and test WITH a PPU at 422 Debris objects to compare it to the software only mode to see if there is any difference.rADo2 - Saturday, May 20, 2006 - link
Well, people have now pretty hard time justifying spending $300 on a decelerator.I am afraid, however, that Ageia will be more than willing to "slow down a bit" their future software drivers, to show some real-world "benefits" of their decelerator. By adding more features to their SW (by CPU) emulation, they may very well slow it down, so that new reviews will finally bring their HW to the first place.
But these review will still mean nothing, as they compare Ageia SW drivers, made intentionally bad performing, with their HW.
Ageia PhysX is a totally wrong concept, Havok FX can do the same via SSE/SSE2/SSE3, and/or SM 3.0 shaders, it can also use dualcore CPUs. This is the future and the right approach, not additional slow card making big noise.
Ageia approach is just a piece of nonsense and stupid marketing..
Nighteye2 - Saturday, May 20, 2006 - link
Do not take your fears to be facts. I think Ageia's approach is the right one, but it'll need to mature - and to really get used. The concept is good, but execution so far is still a bit lacking.rADo2 - Sunday, May 21, 2006 - link
Well, I think Ageia approach is the worst possible one. If game developers are able to distribute threads between singlecore CPU and PhysX decelerator, they should be able to use dualcore CPUs for just the same, and/or SM3.0 shaders. This is the right approach. With quadcore CPUs, they will be able to use 4 core, within 5-6 yers about 8 cores, etc. PhysX decelerator is a wrong direction, it is useful only for very limited portfolio of calculations, while CPU can do them as well (probably even faster).I definitely do NOT want to see Ageix succeed..
Nighteye2 - Sunday, May 21, 2006 - link
That's wrong. I tested it myself running Cellfactor without PPU on my dual-core PC. Even without the liquid and cloth physics, large explosions with a lot of debree still caused large slowdowns, after which it stayed slow until most of the flying debree stopped moving.On videos I saw of people playing with a PPU, slowdowns also occurred but lasted only a fraction of a second.
Also, the CPU is also needed for AI, and does not have enough memory bandwidth to do proper physics. If you want to get it really detailed, hardware physics on a dedicated PPU is the best way to go.
DigitalFreak - Thursday, May 18, 2006 - link
Don't know how accurate this is, but it might give the AT guys some ideas...http://www.hardforum.com/showthread.php?t=1056037">HardForum
Nighteye2 - Saturday, May 20, 2006 - link
I tried it without the PPU - and there's very notable slowdowns when things explode and lots of crates are moving around. And that's from running 25 FPS without moving objects. I imagine performance hits at higher framerates will be even bigger. At least without PPU.Clauzii - Thursday, May 18, 2006 - link
The German site Hartware.de showed this in their test:Processor Type: AGEIA PhysX
Bus Techonology: 32-bit PCI 3.0 Interface
Memory Interface: 128-bit GDDR3 memory architecture
Memory Capacity: 128 MByte
Memory Bandwidth: 12 GBytes/sec.
Effective Memory Data Rate: 733 MHz
Peak Instruction Bandwidth: 20 Billion Instructions/sec
Sphere-Sphere collision/sec: 530 Million max
Convex-Convex(Complex) collisions/sec.: 533,000 max
If graphics are moved to the card, a 12GB/s memory will be limiting, I think :)
Would be nice to see the PhysiX RAM @ the specced 500MHz, just to see if it has anything to do with that issue..
Clauzii - Thursday, May 18, 2006 - link
Not test - preview, sorry.