A new OpenGL BenchMark ?

Yes, but if only such extensions are used, the benchmark won't run on hardware supporting ARB only extensions

 

Left scores are with the Benchmark.jpg, right scores with Stereo.jpg:

1280*1024*32:

Code:

Current:----------536 fps------------------550 fps
--------------------------------------------------------
Detail PS:--------328 fps------------------372 fps
Emboss PS:--------383 fps------------------394 fps
Art Drawing 1 PS:-184 fps------------------218 fps
Art Drawing 2 PS:-235 fps------------------273 fps
Gray Scale PS:----468 fps------------------509 fps
Negate Scale PS:--466 fps------------------507 fps
--------------------------------------------------------
Average PS:-------344 fps------------------379 fps

--------------------------------------------------------
PS2.0 Low P:------108 fps------------------128 fps
PS2.0 HighP:------107 fps------------------128 fps

Radeon 9700PRO
XP 2200@12*166
512MB DDR
WinXP PRO/SP1
DX9.0a
Cat 3.10

 

The program has some benchmarks for pixel shader 1 and
others for pixelshader 2 , if you use the ARB then you'll be using
the pixelshader 2 path , therefore the benchmark will be testing
pixelshader 2 by then instead of pixelshader 1 , Unlike Direct 3D
,in OpenGl if you want to use pixelshader 1 then you have to use
vendor specific , there in no way that you can use pixelshader 1
in a generic way and run for future hardware like the ARB case.

and ofcourse i don't see your post as a bad thing , on the contrary
it is always the constructive and objective respectible posts (like
yours) that provides me an excellent way to enhance my software ,
and i really thank you for that , if you have any further questions or
comments please don't hesitate and completely feel free to post them.

 

IIRC, the ARB extensions do not have support for fp16 - minimum is fp24. That might be the explanation for the same score on high and low (i.e. both are going to fp32)

 

That could be possible. I don't know for sure.

I could have been wrong on my original assessment.

I'm quite sure FP16 has been forced on Direct3D apps that request the precision. (only for the NV30 derivatives)

OpenGL is a different ballpark as there is ONLY a min spec (no pp here) of FP24. Remember that PP is exclusive to DX9. This has no application whatsoever to OpenGL.

Then this benchmark would just prove (assuming FP16 was not forced on the OpenGL driver) that FP32 is NOT viable on extensive usage (which has been mentioned time and time again).

The question becomes, are there PP (or PP-like) hints in OpenGL? (or rather NVidia's extensions, if any - I don't think there are any vendor extensions in OpenGL 2.0 though)

If there aren't any PP-like hints in OpenGL, then there is no reason to have two modes (high and low precision) in the application (as it cannot be done).

On a different note, I don't think NVidia has completed their GLSL support (aka OpenGL 2.0). If you're using any of those extensions on an NVidia card, I don't believe it will work.

 

Thanks for coming by and answering questions Ahmed Bahaa, it's very curteous and very much appreciated.

A little bit-o-insite from a little bit-o-a-thicky, it might be a good idea to either put out a limited time-unlimited benchmark that is non-configurable and has a preset benchmark suite set-up with nothing more than a big red "BENCHMARK" button in the middle of it or else just add a big red "BENCHMARK" button to your existing program.

For people to give this benchmark widespread adoption you'll need to set a basic standard for comparison. I'd suggest 1024x768 full-screen as I think that's still the most standard, but like I said I'm a bit of a thicky.

It's a nice little program, but it's definately aimed more at the power user than anything else. It would be complimented nicely by a gumby version that would just run a standardized bench for comparison sake.

 

The minimum ARB fp precision is 1 part in 10^5 or roughly 17 bits
and because no vga card today has 17 bits of precission the logic
will say that the implementation must consider the nearest bigger
value of the fp precission wich will be 24 bits in the case of ATI
and 32 in the case of Nvidia , but i have received reports saying
that some drivers slightly twist the minimun to be 16 bits rather than 24
or 32 , one developper informed me that he wrote some data to the
float buffer and read them back , and the result was always 16 bits
of pricission , that's why i assumed it will be 16 bits in the first place

but having a closer look at the results posted here , i think you are right
the pixelshader 2.0 results for GeforceFX are relatively low compared
to the Radeon , so i guess it is using 32 bits of precision in all the
tests , i have posted a mail for Nvidia regarding the subject and waiting
for response , right now only a developper with a GeforceFX who write to
a float buffer and read the results back can verify this.

 

I doubt that the specs ask for a 17 bit representation in memory, because normally everything is multiple of a byte (8 bits). However, the mantissa of a floating point does not store the most significant bit because it is always 1. So, in essence, FP16 is a 17 bits.

 

No, it refers to the mantissa.
FP24 mantissa is 16 bit + 1 implicit bit = 17 bit.

 

Come to think of it, there is a hint I think for 'fastest', which allows the driver to select lower precision if available. If I recall correctly, that applies to all operations though. The ARB certainly made a strange choice as far as precision is concerned. The DirectX approach of a per operation hint is much better I think. (Most operations are fine with fp16 in my experience, and you can selectively choose fp24/fp32 for those, like dependent texture computations, that need the higher precision.)

In any case, the question becomes - is the benchmark using the hint?

 

I think you mean :

FP24 = 16 bit mantissa + 1 implicit bit (which doesn't count because
it is not stored) + 8 exponent bits

i mean the matissa is a part of the whole FP
not the other way around right ?
or may be i miss understood what you mean , please correct me if so.

i agree that 17 bit is the same as 16 bit , i didn't know that the
most significant bit is not stored , thanks for the information.

Yes it uses the hints fragment program option , but the question i am
asking now is : if i use specific vendor functions
(i.e NV_Fragment_program ) will there be any difference ?

i am asking this because nvidia stated in their documentation that
you can control the precision of the instructions if you use
NV_Fragment_program and there are different levels of control
over the precision by using this function , so what do you think ?

 

I'd say try it out. See what results you can get. You'd have to get FX users to try it out though (since you don't have one, if I'm not mistaken).

 

<is still hanging around....with FX in hand....>

 

You got me exactly right. But I don't see what I said wrong.
The mantissa in FP24 == "FP24 mantissa" == 16 bits + 1 implicit bit == 17 bit

So this means that FP24 (s16e7) is just right for the OpenGL standard (that wants 1 in 10^5 precision in the mantissa).

One thing though: FP24 in R300 is s16e7== 1 sign bit + 16(+1) mantissa bits + 7 exponent bits.

[edit]
Just realized where you misunderstood me.
"No, it refers to the mantissa" was wrt the 1 to 10^5 precision.
[/edit]

But FP16 is s10e5, or in other words 1 sign bit + 10(+1) mantissa bits + 5 exponent bits. The 11 mantissa bits are not enough for OpenGL. (Except if partial precision is hinted.)

 

digitalwanderer , the idea you are proposing here is quite interesting.

when i first made this benchmark , i thought it would be nice if it will
be adjustable and configurable so by this way users can select different
image each time they run the benchmark , and can select different
settings and study their effect , for example they can select 1600x1200
image and apply bilinear and linear_mipmap_linear filtering modes
and watch the performance drop by about 35% when using
linear_mipmap_linear filtering due to memory bandwidth bottleneck
which is quite interesting , so i prefered the idea of being adjustable.

but after your post , i felt that i was thinking stupidly , i don't need
to prefer anything over anything , i can just add a new , automatic
benchmark which fixes everything and adds some sort of stadarization
to the already existing benchmark , by this way i can keep the best of two
ways , the variancs and the stadarization.

Excellent idea digitalwanderer , thanks very much
i think i'll do that , any more contibutions
, ideas , proposals like this one ?

 

Ahmed Bahaa you have done a nice job with your software, and welcome to Beyond3D

 

Thank you my friend , i consider your post as a great honour

 

BAH! Apparently it didn't show up... I *did* type something in there!

oh well nvm anyhow...