Interesting RTHDRIBL results @ Hexus

I was just scanning through the shader mark results, and it's just plain odd the way both cards stack up.

I haven't really looked at the shaders in detail, but based on how I'd write them I just can't see what the pattern is in terms of performance. Has anyone here looked in detail at the shders in shader mark?

 

as it is quite old, i think it was indeed written by hand.. but i'm unsure.. by hand, or with a very first release HLSL compiler..

 

From what I've read, the NV3x was VLIW. The NV4x is not. The instructions carry less information about direct hardware scheduling than on the NV3x, with some of that taken care of by the hardware.

I suspect that the improvement in the NV4x's performance was due both to nVidia producing the compiler along with the architecture, and due to the hardware taking over parts of the low-level scheduling that would be challenging without knowledge of runtime data.

Obviously there are other higher-level things that the compiler must take care of (for example, I suspect that better register allocation in future drivers will help the NV4x's performance).

Wow, yeah, that's pretty bad. I suppose this is one reason higher-level languages should really be used.

 

Might be interesting, but I think we'll see things change significantly with later drivers anyway, so I'm not sure it will really make a huge difference.

 

I was trying to establish if it's a difference in texture performance vs ALU op throughput. It's just out of interest on my part.

Since I'm one of the few people who has a reason to care about SM3.0 ATI's part is useless to me anyway.

One thing that did occur to me with RTHDRIBL (or whatever) is that it uses a 16 bit target fo the HDR image and then textures from it. Since ATI doesn't support fp texture filtering, it's possible that the code soesn't set it to point sampling explicitly and that NV40 is filtering the fp texture.

Of course it could be any number of other issues aswell.

 

ERP, wow, I thought of the exact same thing, but had no way to verify it! And RTHDRIBL uses a hell of a lot of texture ops per shader too.

 

Hmm, if there's difference on the filtering, we should be able to find some visual differences.

 

Not necessarilly, it's probably already doing a blur filter in the shader, which would pretty much amke it impossible to tell if the individual samples were bilinear, or point sampled.

I have no idea how you would tell without the soursce code. Probably the easiest is to email the author and ask.

 

Right, but we can extract the shader code by 3danalyzer, all we need to do is to go through the code looking for filtering.

Asking the author may not be a bad idea also, saves us some time at least.

And judging from the screen shot, it seems to me that there's already a blur filter applied on the background.
http://img.hexus.net/v2/graphics_cards/ati/r420/images/rthdribl_big.png

Do you think nVIDIA should provide a control button to disable the FP filtering when necessary? If the programmer implement the filtering in the shader, it's pointless and harmful to do repeated work.

 

This makes me curious on one thing, I remember in past some game developers ( Half Life 2 ) detecting NV3x and using 1.x shaders instead of 2.0 shaders. If other applications do this and running on 6800, then this application will not be taking full advantage of the new chip.

Just something that came to mind when reading this thread.

 

Huh? FP filtering will only be used when requested. If the program requested filtering while assuming that it wouldn't be done because it's a FP target, well, then that's just sloppy.

 

You're suggesting that this demo (RTHDRIBL) is doing it?

The reason developers default to a lower shader is to get past a hardware's limitations, rather than hide its strengths. Do you really think Core and Crytek (and their TWIMTBP titles) are sabotaging nvidia's performance by forcing more 1.1 shaders instead of 2.0 on them?

 

Well, I used 3DAnalyze to log every DX9 call. Judging by the results, it does appear that RTHDRIBL is asking for D3DTEXF_ANISOTROPIC on float textures, but it's hard to track because of the voluminous data. There appears to be a call to CreateCubeTexture for D3DFMT_A16R16G16B16F, followed by a SetTexture for sampler stage 0, followed by a SetSamplerState to D3DTEXF_ANISOTROPIC on that sampler, but I'm not totally sure because I was jumping around alot in a textfile with thousands of lines trying to track back hex addresses.

 

The 7 posts just mysteriously dissapeared eh? Well I suppose it is for the best.

 

I'm learning more towards shader problems myself, but there is heavy use of FP cube maps going on.

 

Any updates to RTHDRIBL performance? Has anyone contacted the author?

 

I know NVIDIA are having a look at it themselves, they asked me this morning how I did the testing for RTHDRIBL.

Rys

 

Bump (before it falls off the front page and I forget) to remind ppl to post if either nV or the "dribble" author responds.

 

I've asked NVIDIA what optimisation for RTHDRIBL's case they're performing, since it's a somewhat unique problem. I'll post when they reply.

Rys

 

Let us know