PowerVR SDK Updated - Includes stunning new Benchmark !

[Ailuros]

Chalnoth,

I severely doubt that. If one sets aside the lack of a T&L unit and other factors, it's raw fillrate and/or bandwidth are way too low to get "good" performance. Maybe it will do surprisingly well for it's class, but nothing more than that.

 

[Jerry Cornelius]

No AA, bit I just checked and had Anisotropic forced in the drivers. It usually cuts frame rates in half.

 

[Jerry Cornelius]

I'm really interested to see how Kyro is going to fair with Doom III. Assuming all the required HW can be faked, it may only be about 4 times as stressfull as QIII. My Kyro 1 can get over 80 fps staring at generic dual textured scenes in Quake III (800 600). If it's just a matter of 8 textures instead of 2, and no hopeless slow downs from stencil buffering, it autta run at 640 480 at least.

 

[Jerry Cornelius]

Jerry,

Got any AA enabled? I verified my results 3 times for each resolution and colour depth and 1x7 was consistantly over 34 for both 16 and 32bpp

Actually I thought I had Anis enabled, but that was OGL. Maybe you have a Kyro II?

 

[Malo]

hehe nice to see a company breaking out of the norm for their benchmarks. very cute....

-----------------------------------------------------------------------------
D3DFableMark v1.0

Average FPS: 26.7
Benchmark: 2804 frames

Driver: nv4_disp.dll
Description: NVIDIA GeForce4 Ti 4400
Version: 6.13.10.2832

Resolution: 1024x768x32
Texture compression: ON
Max. Texture used: 1024x1024

CPU Description: AMD K7 (Athlon)
CPU Speed: 1.300GHz


Time: 2002/6/7 02:26:02 Coordinated Universal Time (UTC)
Command Line: "E:\Downloads\Nvidia\D3DFableMark\PowerVR SDK\DX8\Apps\D3DFableMark\D3DFableMark.exe" -Width=1024 -Height=768 -Bpp=32 -Benchmark
-----------------------------------------------------------------------------


and with 2xAA on


-----------------------------------------------------------------------------
D3DFableMark v1.0

Average FPS: 19.7
Benchmark: 2804 frames

Driver: nv4_disp.dll
Description: NVIDIA GeForce4 Ti 4400
Version: 6.13.10.2832

Resolution: 1024x768x32
Texture compression: ON
Max. Texture used: 1024x1024

CPU Description: AMD K7 (Athlon)
CPU Speed: 1.300GHz


Time: 2002/6/7 02:34:01 Coordinated Universal Time (UTC)
Command Line: "E:\Downloads\Nvidia\D3DFableMark\PowerVR SDK\DX8\Apps\D3DFableMark\D3DFableMark.exe" -Width=1024 -Height=768 -Bpp=32 -Benchmark
-----------------------------------------------------------------------------

AA didnt seem to help much, even 4x could not remove stepping on those trees..... am I missing something here?

 

[Grue]

Isn't the Kyro sort of screwed when it comes to Doom3, because it doesn't support cube maps?

--Chris

 

[KnightBreed]

The volumetric fire in the fire demo is rather FUBARed - it produces large rainbow colored flashing artifacts.

Kristof, if you don't mind me asking, what are the best set of Win 9x Kyro(II) drivers? I'm downloading the 1.5 (Build 1.05.15.0084) drivers now. I hope they work ok.

Edit: Nevermind, the 1.5 build worked like a champ. Cool demos. Thanks, Kristof.

Jerry, who's sig are you talking about?

 

[Jerry Cornelius]

lol, haven't seen that sig in a while.

EDIT
"The day I can't do my job drunk..."

 

[Kristof]

Yes, I think there is a well known up-coming engine that also makes extensive use of stencils...

And besides, DOOM3 will be great for cards with memory bandwidth-savings tech (Radeon+, GF3+), since it only writes to the z-buffer once.

Even though he might only do a single Z pass, he is doing multiple stencil passes just like this demo does. The lighting model used, while not exacty like DoomIII, does show quite a few similarities. Remember this quote from JC :

Several hardware vendors have poorly targeted their control logic and memory interfaces under the assumption that high texture counts will be used on the bulk of the pixels. While stencil shadow volumes with zero textures are an extreme case, almost every game of note does a lot of single texture passes for blended effects.

Stencil tests are simple but tradition immediate mode renderers are pushing them through their whole expensive slow pixel pipes... KYRO only sends them through the visibility processing and is done with it.

I think its too early to discuss how any budget card might perform on DoomIII.

K-

 

[KimB]

I think its too early to discuss how any budget card might perform on DoomIII.

I just do have to say that all of those PVR demos are optimized for the Kyro. Never have vendor-specific benches been any good. DOOM3, on the other hand, is being optimized for immediate-mode renderers, particularly the GeForce4, and so there's little chance that the Kyro will do very well.

I particularly doubt that it will be able to handle the polycounts.

 

[Dave Baumann]

DOOM3, on the other hand, is being optimized for immediate-mode renderers, particularly the GeForce4, and so there's little chance that the Kyro will do very well.

Haven't we already been over this before? If it was optimised for GeForce 4 the it would have had a code path more suited to GeForce4 - you could say its was optimised for Radeon 8500 seeing as the code path suits that best! Primary development platform is not necessarily equal to optimised for.

 

[KimB]

Haven't we already been over this before? If it was optimised for GeForce 4 the it would have had a code path more suited to GeForce4 - you could say its was optimised for Radeon 8500 seeing as the code path suits that best! Primary development platform is not necessarily equal to optimised for.

Why do you say that the codepath suits the Radeon 8500 the best? JC has continually stated that the GF4 is the best current card for DOOM3, and that's the card that all the people at id software are using.

 

[Gollum]

Why do you say that the codepath suits the Radeon 8500 the best? JC has continually stated that the GF4 is the best current card for DOOM3, and that's the card that all the people at id software are using.

He sais that because Carmack said so himself in one or several of his many comments about current Video cards: "For programmers, the 8500 has a much nicer fragment path than the GF4, with more general features and increased precision". As for the GF4, he said "However, in practice, the GF4 consistently runs faster due to a highly efficient implementation." and that its still the card he reccomends everybody.

In another quote I remember reading that currently there was no noticable difference in IQ between the two, even with the Radeon's higher precision, but that this might change if he decided to add some specific instructions to the code before Doom3's release...

 

[Dave Baumann]

He sais that because Carmack said so himself in one or several of his many comments about current Video cards: "For programmers, the 8500 has a much nicer fragment path than the GF4, with more general features and increased precision". As for the GF4, he said "However, in practice, the GF4 consistently runs faster due to a highly efficient implementation." and that its still the card he reccomends everybody.

Well, thats not the comment I’m actually talking about, but it is related to the fragment pipeline, and how its increased functionality/flexibility suits the Doom3 engine better. JC has said a number of times that the way the fragment path works enables him to do the operations on DoomIII that he requires in one pass, whereas all other cards (currently) require 2 or more, and he also states that becuase of this Radeon should be fastest for rendering the DoomIII engine – the fact that its not is down to GF4’s speed and other factors. However, if the game were ‘optimized’ (i.e. designed to perform optimally) for GF3/4 then I doubt that the game would be coded in such a fashion; which is why I say that JC isn’t necessarily optimizing the engine for any one specific card but just coding for his needs – but as it stands it would look to an outsider (considering his comments) the engine is more optimal for Radeon 8500’s fragment path than any others.

 

[Reverend]

Back to the topic. Just ran the benchmark and I fail to see the relevance this benchmark has with regards to popular games. It's fine for what it is (actually it is fine for showing me the shadows, which is the first time I'm seeing such) but let's be realistic and think about games....

 

[Simon F]

Back to the topic. Just ran the benchmark and I fail to see the relevance this benchmark has with regards to popular games. It's fine for what it is (actually it is fine for showing me the shadows, which is the first time I'm seeing such) but let's be realistic and think about games....

Rev, since current games don't seem to be doing much with stencils, you may well be correct. OTOH for future games that start doing shadowing in a serious way, I would think it would be quite relevant.

 

[Reverend]

Simon, what's a "serious way"? If I'm guessing correctly, your serious way (or as per this benchmark) will never be in any games within two years.

 

[Kristof]

Rev, DoomIII and FableMark have a lot in common in how they do lighting. FableMark also does an initial pass with no textures (as can be seen on a Radeon 8500 which occasionally manages to only show that pass) and then does additional passes per Light Source to fill in correct lighting information in the framebuffer. This is not just "some" stencil shadow demo... its a complete lighting model where each light adds something to the scene (multipass technique), the last thing added is the actual texture data. Rather than use 5 similar volumes that create the soft edge effect you could just as well have used 5 completely different volumes indicating different lights (as probably DoomIII will do).

Will a game look like FableMark ? No, probably not... will similar principles be used in games ? Yes... Carmack has already indicated that cards are fairly slow when executing the simple stencil operations (stencil clears while maintaining other information, stencil compares and updates, etc). This demo shows how effective cards handle stencil operations, as used typically in a game engine that uses multipass lighting (as is the case with DoomIII).

K~

 

[KimB]

but as it stands it would look to an outsider (considering his comments) the engine is more optimal for Radeon 8500’s fragment path than any others.

My point still stands that all of the people that are developing with the engine are using GeForce4's. That means that they'll see how effects perform on the GF4 first, and use it as a basis to judge performance by. Thus, effects that, say, might indeed be faster on a Radeon 8500 but slow down a GF4 will be avoided by default.

 

[Dave Baumann]

Thus, effects that, say, might indeed be faster on a Radeon 8500 but slow down a GF4 will be avoided by default.

Thats not optimising the engine for it though!