Further Tests

With four DX9 compliant Vertex Shaders we would expect Parhelia to have a good hardware geometry throughput. We'll test the processing using hardware and CPU based geometry processing to see what kind of performance gains can be attained by using Parhelia's geometry processing opposed to the geometry throughputs from the P4 2.53GHz CPU.

The 3DMark2001SE tests are all showing pretty good gains in performance when running hardware geometry processing as opposed to running it via the CPU. Even at high resolutions two of the tests are still showing good percentage increases, the only exception to this being the 'Nature' test.  But as explained before this is probably because the test is becoming quite fill-rate/bandwidth limited, thus minimising the improvements that hardware geometry processing would be able to show.

As is always the case, though, 3DMark2001SE's tests are only demos and hence not representative of an actual game, which has many more calculations running on the CPU than just geometry processing. Let's take a look at the performance of a couple of game titles using software and hardware geometry processing

As we've said before, Dungeon Siege is quite a CPU bound title and here we can see that using hardware geometry processing accounts for nearly a 20% improvement over software processing in the lower resolutions. As the resolution goes up, this advantage is scaled back as Parhelia is becoming a little more fill-rate limited in this game.

Max Payne shows even larger performance gains than Dungeon Siege at lower resolutions, but this is almost negated at high resolutions where fill-rate is of paramount importance.

Parhelia offers 4 texture units per pipeline, meaning that up to 4 texture maps can be sampled simultaneously and Serious Sam can handle up to four layer in a single pass, which should be a good fit for Parhelia. SS:SE also provides the ability to alter the number of texture layer applied per pass, so we can see how much benefit the 3D architecture is gaining from the number of texture layers applied in a single pass.

SS:SE's Citadel demo was used, with Trilinear filtering enabled

Why there is such a large performance difference at 640x480 without any multi-texturing is a mystery. In theory we would expect multi-passing at low resolution to perform poorly because the geometry needs to be resent multiple times and hence would put more load on the Vertex Processors.

The gains in the higher resolutions here are quite large, but because of the texture unit arrangement on Parhelia, in a title like Serious Sam, removing the number of texture layers applied per pass has direct impact on its fill-rate and not just bandwidth. With future games a flexible number of texture layers per pass is very important for Parhelia.

We can see that the largest single gain is from going from no multi-texturing to dual texturing. Parhelia's texture units are capable of sampling bilinear samples in a single clock, so for Trilinear sampling two texture units will be used per map; hence at two texture maps per pass with Trilinear filtering all of Parhelia's texture units are being used simultaneously.

We'll use the VillageMark test to see what Parhelia's performance is like under the conditions presented by this benchmark

Parhelia's performance in this test isn't too bad, despite it not being advertised with any bandwidth or overdraw reduction optimisations. VillageMark does use several simultaneous texture layers so the raw texturing performance of Parhelia will be of help, as will the raw bandwidth of the 256-bit memory bus.

Here we'll at "Humus"'s GL_EXT_reme benchmark, which has tests using various difference render orders.

From this we can see that the gains from Random ordering or Front-to-Back ordering are very minimal in comparison to Back-to-Front ordering, which is a good indication that there isn't any early pixel Z tests to retire an occluded pixel before texturing or Pixel Shading/Fragment processing is done on that pixel.

The next generation id title 'DoomIII' specifically operates by rendering the entire scene in a very uncomplicated fashion, which is to first purely lay down Z information for the frame prior to any of the per pixel operations taking place. The results of this is that boards that have early Z checking / rejection schemes won't need to do the per-pixel operations on occluded pixels, which have very intensive calculations, once the initial Z calculation pass is complete. Because the Z information for the entire frame will already be present, there will be a 100% certainly of whether the current pixels being rendered will actually be displayed. However, a board without early Z testing will not know whether or not a pixel is going to be occluded until it's ready to be sent to the frame buffer, so all of the intensive per pixel operations will be carried out on every pixel regardless of whether or not it will actually be displayed in the final frame.

Here we'll see how Parhelia performs under the PowerVR FableMark test, which makes extensive use of Stencil Buffers

Although the performance seems to be quite low at high resolution this is reasonably consistent with other DX8 class hardware. However, it does not appear that Parhelia features anything like single pass stencil operations.