MunkyMark

[xtknight]

Originally posted by: munky
I got the same results when I had no graphics driver installed on the gf2 mx. When it says "GDI Generic" for renderer, it means that OpenGL is emulated in software on the system. What I think is causing the crash is that even though there's a cpu math mode, the app still uses OpenGL to draw the result buffer, and with limited/incomplete OGL support it causes an error. When it says "shader version not > 1", it means SM2 or higher shaders are not supported in HW, and the app will only run using the cpu mode. I may just have to code a pure software rendering mode that uses no OpenGL at all.

Hmm...shouldn't the reference renderer support SM3? On second thought I'm not sure how since installing NVIDIA drivers just installs their ICD (and to my knowledge that exclusively reacts with the graphics card). Without installing those, you're stuck with MS's opengl32.dll and I don't know the last time they updated that. But I do have an ICD installed (VMware I think) and that doesn't support everything (doesn't support shaders). It's still an experimental 3D support driver so I wouldn't worry about it (just find somehow to exit it without error).

*edit: BTW, does the idle version of the app crash also?

Nope, it just sits...idle at the black screen.

 

[Munky]

It's not exactly a reference renderer, it's just Microsoft's outdated software emulation of OpenGL. The fact that it's only version 1.1 also tells that it's an old, bare minimum implementation, as most graphics hardware made within the last 7 years or so will support at least version 1.3, with a semi-modern driver. My gf2 mx reports version 1.5 since I updated the drivers, and now at least it can run the app in CPU mode without crashing.

 

[Don66]

E6600@3.2GHz x1900xt
SM3=37.30
SM2=24.80
FBO=20.80
CPU=3.10

 

[Munky]

Beta 4 is now available to download, and this version has some big changes. The most important change is I added a second dependency chain to the cpu math loop. Basically it allows the cpu to calculate 2 pixels per loop, and each pixel is processed independently of the other. This not only allows the cpu more opportunities to reorder instructions, but it gives the cpu 2x as many instructions to work with, thereby putting all the decoders and appropriate execution units to work. Also, the Conroe is now able to put it's 4-issue architecture to good use, and it shows substantial gains over the K8 cpus, as well as having much improved clock scaling. I'm not sure how the P4's will fare in this case, someone try it...

Here's my results for the cpu scores:

old version -
2.4 ghz X2: 2.89 fps
2.4 ghz C2D: 2.88
3.2 ghz C2D: 3.33

new version -
2.4 ghz X2: 5.44
2.4 ghz C2D: 6.5
3.2 ghz C2D: 8.66

 

[Munky]

Originally posted by: Don66
E6600@3.2GHz x1900xt
SM3=37.30
SM2=24.80
FBO=20.80
CPU=3.10

Is this with Crossfire? Your video card scores are much higher than typical for a single x1900xt. Or maybe it's just OC'd really high...

 

[Don66]

Originally posted by: munky

Originally posted by: Don66
E6600@3.2GHz x1900xt
SM3=37.30
SM2=24.80
FBO=20.80
CPU=3.10

Is this with Crossfire? Your video card scores are much higher than typical for a single x1900xt. Or maybe it's just OC'd really high...

No Crossfire, and no overclock. I'm just using Omega drivers.

 

[Don66]

reran it and got a total different score..
SM3=17.10
SM2=10.50
FBO=10.40
CPU=8.50

Is the test supposed to be ran in debug mode which gives a higher score?
Or in mandelbrot mode which gives a lower score?

Debug mode:With your newest test
SM3=33.45
SM2=24.00
FBO=20.90
CPU=9.56

 

[Munky]

Originally posted by: Don66
reran it and got a total different score..
SM3=17.10
SM2=10.50
FBO=10.40
CPU=8.50

My x1900xt gets about 25, 14, 10, using catalyst 6.2. I dont know what's up with the Omega drivers.... but your cpu score is higher due to the new & improved version.

 

[Munky]

No, debug was just for testing purposes. The real test is supposed to run in fullscreen mode, using the mandelbrot.exe app.