Video Card Drivers

[Michael Clease]

Anyone that hasnt updated their video card drivers for a while I would recommend doing so.

I ran the TBGL_Benchmark and then downloaded the latest driver for my card and ran it again and was really suprised by the results..

BEFORE

Vertices tbgl_m15DrawModel tbgl_CallList Framerate [FPS]
48000 115 161
24000 230 320
12000 452 623
6000 887 1154
3000 1644 1915
1500 2571 3273
728 3871 4557
376 4615 4615
188 5806 3830

AFTER
Vertices tbgl_m15DrawModel tbgl_CallList Framerate [FPS]
48000 151 157
24000 303 311
12000 591 606
6000 1154 1150
3000 1925 1915
1500 3303 2880
728 4615 3830
376 3830 5806
188 3830 5806


Petr I dont know whats happening as the number reduces??

[ISAWHIM]

I want to do the benchmark... How do I do it? It says that is an unknown keyword?

Found it... LOL... I thought it was an internal function, not a code/program.

Michael, it looks like your card is using more, and faster internal RAM for the CallList, as opposed to the m15DrawModel. I assume, the M15 is in normal RAM, while the CallList is buffered/cached in your video-card RAM? (Possibly the M15 is also, but it may be clearing and refilling from the normal RAM cache.)

Wow, my card stinks... (It has no video RAM, only shared system RAM.)

I am curious, can you try my version... I want to see how fast yours tapers on a linear test.

Using the latest Version: 1.6.0.10 ThinBasic
ATI TECHNOLOGIES INC
ATI MOBILITY RADEON XPRESS 200
OpenGL 2.1.8086 RELEASE
Vertices tbgl_m15DrawModel tbgl_CallList
48000 43 61
24000 85 124
12000 168 253
6000 329 461
3000 562 562
1500 606 623
728 658 641
376 658 658
188 678 658

Using the latest Version: 1.7.0.0 ThinBasic
ATI TECHNOLOGIES INC
ATI MOBILITY RADEON XPRESS 200
OpenGL 2.1.8086 RELEASE
Vertices tbgl_m15DrawModel tbgl_CallList
48000 42 62
24000 85 123
12000 166 248
6000 316 461
3000 562 562
1500 606 623
728 658 639
376 677 641
188 678 658

I have created a modified version, it gave slight better results. (Noted changes in the file.)
This modified version uses a few more tests, and the test values are linear. I found the "Curved" tests to be a little misleading.

I also setup the tests so you can run a long-test by just changing the value of the "dim frames as long = 180". Any value higher than 180 should be fine. It will still draw only one full rotation per test. Higher numbers will result in smaller angle-moves per 360-deg rotation. Going lower may cause division by zero errors, and will result in less accurate results.

More important than the "Frame Rate" would be the "Time to complete X frames", or "Seconds per Vertice", or "Free time per 1/60th of a second". But FPS is important also.

Vertices tbgl_m15DrawModel tbgl_CallList
48000 41 60
44800 44 64
41600 47 69
38400 51 75
35200 55 82
32000 61 90
28800 68 99
25600 76 112
22400 86 127
19200 100 150
16000 119 180
12800 146 222
9600 192 288
6400 288 427
3200 523 606
10 677 679

Results are now equal on both 1.6 and 1.7 versions of ThinBASIC.

[Petr Schreiber]

Michael,

interesting how the display lists and models swapped speed for 188 vertices.
Which PC it was, I presume the one with GeForce 6?

I am thinking of writing new benchmark, with different models for different polycount, reflecting more the most common cases.

Jason, models are rendered via vertex arrays - you pass pointer to array to driver, and it renders it. Like immediate mode on steroids.
Display lists are passed to card once and then just referenced ... at least that is what they should do.


Petr

[ISAWHIM]

Your values are limited by the speed of how fast TB is sending and translating the "Calls" or "Code". At 3830 (Which is no coincidental number), that is the High-thread-speed of the call. At the fastest, your CPU sent the code at 5806. Possibly because the CPU was not doing less in those few micro-seconds. Which is the 100% thread speed. If you set TB to be "Critical Speed", you will should more of those times.

EG, between 1500 and 728, the card was thinking faster than the CPU.

Even on my card, I have similar results... The values jump but are always 641 to 671 (The priority speed.)

Must be why mine is so slow... It is passing it to {SYSTEM RAM (Normal)}, to {SYSTEM RAM (dedicated graphics)}, than being processed (Rendered).

Still, it is faster that way. Only one pass to the dedicated graphics ram, but limited by the slower bus-speed and read/write time-slices that the system is using. (Now I know why I get gains from using the "Enable Write Combining".)

LOL, I was playing with all my settings last night... The good news was, I didn't have any slow-downs using MAX settings and turning on all sorts of things in the benchmark.

The largest gain I had, was when the objects were no longer spinning off the screen. when the object was full.

I have a request though, for the object. instead of having it built like a fan, with blades that disappear, can you build it like a fan, but the layers disappear? (EG, as if they were stacked ****** not |||||| and spun around. **** would turn to *** then ** then *, but still a full screen size structure. You get false readings, as GL only draws the screen-changes. If only half the object is there, it only has to redraw half the size of the screen. When you get down to one box, it is only having to redraw an icon-size area, which is lightning fast.)

Possibly, a complete better setup for testing display and motion of this type, would be to have something solid spinning in the entire background. That will ensure that the whole screen is redrawn, without the acceleration of only drawing the mini-area of changes.

You also get false readings, since there is always 1/2 of the vertice structures culled. Since they are behind and not drawn. A triangle rope, wrapped in a spiral might better display the actual vertice-count set.

Obviously, my new drivers gave me huge gains.

Possibly, Mike's drivers have a new default setting, or have reset some other setting, or have "New code" to fix a problem that was present at those older "High-speed" values in the previous driver. Those "Fixes" usually come with a speed penalty where data is moved at a fast pace. (Thus, it would not be present until the lower levels, where less is drawn at lightning speeds. Limited by the access rates and checking/fixing codes.)

I didn't detect any memory leaks...

Also, moving the mouse, or background processes will interfere with those modes... virus scanners also. (It is using the same memory and buses that you are transferring data on.)

I also noticed that the "SetWindowText" causes a hiccup in the TBGL module. (That was causing my sand-box to jump all over. It seems that the "Set Title" function waits for a return value. EG, it doesn't keep running TB in the background, it actually sleeps until the return value is sent back. Which was part of the reason I setup a tiny DoEvents in the benchmark. That helped reduce the false-start of the loops as the title updated to show each new test.)

[ErosOlmi]

ATI TECHNOLOGIES INC.
ATI MOBILITY RADEON X1600 X86/SSE2
OpenGL 2.0.5696 WINXP RELEASE
Vertices tbgl_m15DrawModel tbgl_CallList
48000 192 320
24000 397 536
12000 590 887
6000 768 1212
3000 822 1538
1500 1277 1925
728 1925 2093
376 1915 2105
188 2293 2093


It is some time I'm not updating ATI drivers. I will do and see.

[Petr Schreiber]

Hi Eros,

thanks for the results, your Radeon is still in very good condition :)

Jason - you make good point about the size of object and pixels ratio.
The most differences will be visible on low end thought, high end has so huge fillrate performance is not an issue.

But I will keep it in mind. The rotation is here just to make it more interesting to watch :)

I will start new thread regarding new benchmark project.


Petr