R300 3DMARK2001 PROJECT COMPARE

[OpenGL guy]

My bet is that each sprite quad is composed of two tris, thus halving throughput.

Bzzt! Next answer?

 

[Sabastian]

"What Are Point Sprites?
Support for point sprites in Microsoft® Direct3D® for Microsoft DirectX® 8.0 enables the high-performance rendering of points (particle systems). Point sprites are generalizations of generic points that enable arbitrary shapes to be rendered as defined by textures.

Point sprites are not supported in the fixed-function geometry pipeline. To use point sprites, programmable vertex processing must be used."

http://msdn.microsoft.com/archive/d.../dx8_vb/directx_vb/graphics_advanced_78ab.asp

 

[Geeforcer]

Bzzt! Next answer?

Fill-rate limitation ?

 

[Doomtrooper]

My bet is that each sprite quad is composed of two tris, thus halving throughput.

Bzzt! Next answer?

Whats the prize for the right answer ?

 

[OpenGL guy]

Bzzt! Next answer?

Fill-rate limitation ?

Nope

Next?

P.S. It helps if you sit down and actually look at the data instead of just stabbing in the dark.

 

[OpenGL guy]

Whats the prize for the right answer ?

Forget about it: You're not getting my R300!

 

[Doomtrooper]

Boooooo ....Can't blame a man for trying..

 

[Kristof]

My bet is that each sprite quad is composed of two tris, thus halving throughput.

Bzzt! Next answer?

Can we have multiple guesses ?

- Point Sprite scene has no (backface) culling, while High Polygon Test does have backfaces culled ?

- Or boring option : CPU limit ?

YAWN 6:30 am is too early to think about this

K~

 

[Geeforcer]

P.S. It helps if you sit down and actually look at the data instead of just stabbing in the dark.

I did , although I apparently was looking at the wrong data.

Undeleted question: do the large discrepancies between single and multi-texture filtrate results on R9000 and R9700 stem primarily from the way the tests are setup?

 

[Kristof]

Undeleted question: do the large discrepancies between single and multi-texture filtrate results on R9000 and R9700 stem primarily from the way the tests are setup?

Single texturing means that you write to the framebuffer a factor 8 more than the multitexture scene. Can't remember how many layers the test does but say it draws 16 layers, in single texture you write 16 times to the framebuffer, in multitexture you write twice to the framebuffer and handle the 8 layers using multitexture on the chip. I would say this has an impact on external memory bus. Since the texture hits OK on an average cache its mainly the framebuffer write/read bandwidth that is going to hurt, hence single layer much more expensive than multitexture. Well at least on immediate mode designs.

K~

 

[Geeforcer]

This does make sense. This is from MadOnion:

Single-Texturing: There are 64 surfaces with one texture each. This means that the graphics hardware fill each of these objects separately, no matter how many texture layers that card is capable of drawing in a single pass.
Multi-Texturing: We draw 64 texture layers as fast as possible. This means that we take advantage of the fact that modern cards are usually capable of drawing multiple texture layers on a single object as fast as it would draw one single layer. 64 texture layers are distributed so that each surface in use has as many texture layers as that particular card can draw in a single pass. For example, if your card can draw 8 texture layers in a single pass, then there will be 8 objects with 8 texture layers each. If your card is capable of doing 6 texture layers in a pass, there will be 10 objects with 6 layers and an 11th layer with the remaining 4 layers.

So the greater the number of textures the hardware can draw in a single pass, the greater will the discrepancy between singe and multi-texture result be.

 

[Kristof]

So the greater the number of textures the hardware can draw in a single pass, the greater will the discrepancy between singe and multi-texture result be.

Only if the added framebuffer bandwidth is an issue, ideally there should be no performance difference. But yes, if you see a delta its most likely due to the scene nature and the resulting difference in dataflow.

K~

 

[DemoCoder]

But seriously, you aren't taking the datasets into consideration. For example, how large are the triangles in the hi-poly 1 light test vs. the size of the point sprites in the point sprite test?
As soon as you analyze the data, let us know.

I'd estimate that the point sprite test pixels are between 1-4 pixels given the size of the jaggies and "holes" that pop sometimes. Are you saying that the point sprites are eating more fillrate than the triangles? I highly doubt it. 40 million point sprites * (let's be conservative and say 10 pixels each) yields 400megapixels/sec.

Moreover, the vertex shader test is doing diffuse and specular light right? The point sprites have a much shorter transformation and lighting spec.

What investigation have you done that leads you to believe there's a possible driver issue here? Maybe Geeforcer is on to something with his data.

Well, I said it's an either/or situation. It's possibly a CPU limitation or some other problem due to the way 3Dmark is coded. If you know what the problem really is, why not just spit it out?

40M particles/sec on a next gen card like the R300 seems pretty bad.

 

[Geeforcer]

I'd estimate that the point sprite test pixels are between 1-4 pixels given the size of the jaggies and "holes" that pop sometimes. Are you saying that the point sprites are eating more fillrate than the triangles? I highly doubt it. 40 million point sprites * (let's be conservative and say 10 pixels each) yields 400megapixels/sec.

Actually, I just saw that a minute ago:

Point sprites are a kind of particles which have more limitations than custom particle systems, but are drawn very fast if there is hardware support for them. There are about 500000 particles simultaneously on-screen in this test and they are used for rendering a 3D model. Particles are usually used in games for effects like fire, smoke and explosions. We are using such a large number of particles that we have to use particles the size of a single pixel. If we didn't, the test would become heavily fill rate limited.

 

[DemoCoder]

Perhaps there is some kind of setup/state change overhead with drawing point sprites that you don't get when drawing triangles?

 

[nggalai]

I'd like to see what kind of score it gets without the OCed P4.

Then again, 3.0GHz P4s are supposedly coming out before the end of the year...

Serge

. . . and some info on the VGA would come in handy, too--Ken is known to overclock anything.

i.e. take these results with a grain of salt.

Edit: re-checked the link, and Ken added a description. Hence, forget you've ever read this posting.

ta,
-Sascha.rb

 

[Kristof]

I'd estimate that the point sprite test pixels are between 1-4 pixels given the size of the jaggies and "holes" that pop sometimes. Are you saying that the point sprites are eating more fillrate than the triangles? I highly doubt it. 40 million point sprites * (let's be conservative and say 10 pixels each) yields 400megapixels/sec.

Well he already said its not fillrate. ALthough one has to take into account that writing very small triangles using a very wide bus (256bits x 2) can results in extremely poor efficiency.

How many possibilities are there ?

Options I have left are : Culling (High Poly has culling, point sprites are not culled since they are always front facing), Tri Setup (assuming 2 tris setup per Point Sprite Quad), Bandwidth (small tri over big bus) and CPU.

K-

 

[Reverend]

But seriously, you aren't taking the datasets into consideration. For example, how large are the triangles in the hi-poly 1 light test vs. the size of the point sprites in the point sprite test?

The high poly count test has 1047088 polygons in the scene, with the most dense meshes in the dragons (about 100K each). This means that at least on the dragons, the polygons can be about the size of a pixel, and some are sub-pixel size, depending on the resolution. The other objects in the scene have larger polygons and the skybox and the ground have naturally the largest ones.

The point sprite test, of course, has no polygons or lights, it's all point sprites, a kind of particles. The size of the point sprites is adjusted with the resolution so that the horse is intact. Too small points would leave holes between the points.

 

[eSa]

Maybe I'm mistaken here, but are those "One light / 8 lights polycount" tests that good ? That is, 78 MTris/sec with one light is bit low, isn't it ?
Maybe this is a driver issue and it's going to get better ?

 

[Neeyik]

The point sprite test, of course, has no polygons

That's not entirely true as DX8 handles point sprites by rasterising a quad that has each vertex with the same colour (with the option of the texture coordinates being the same too). It's not a poly in the normal sense of things but it's still got vertices.