• entries
    422
  • comments
    1540
  • views
    488537

The plot thickens...

Sign in to follow this  
jollyjeffers

112 views

Just a quick entry before lunch... I'm kind of hoping that if I write this stuff down it might, just maybe, make some sense.

So I put in a load of debugging trace statements into my program. All the resources are being created in the desired format (16bit FP) at the correct resolution.

Next step, I used PIX (most amazing debugging tool ever. Fact.) and stepped through my program and examined every resource after each step. The bright pass results were 0/black, which when fed into the lens effects generates black, which when added to the final image adds nothing - thus no bloom effects.

FACT 1: Bright pass isn't generating results, so no lens effects appear.

After experimenting a bit further I find that if I set the "bright pass threshold" to a value less than 1.0 then I get some content in my bright pass output. If I set it to 0.99 then I get the bright parts as expected, set it to 1.0 and they disappear.

FACT 2: No pixels in the source image have values > 1.0

Now this one really confuses me. I pass in values to my lighting equations that are most definitely > 1.0; which means it must be being clamped on the GPU. The bottom line appears to be that switching from an ATI Radeon 9800 to an Nvidia GeForce 6600 (somewhere) saturates/clamps the values to a [0.0, 1.0] range.

Everyone should know that when the IHV's disagree your only friend is the reference rasterizer.

FACT 3: The reference rasterizer gives me a completely white image, different to both ATI and Nvidia hardware

So, I can only guess that somewhere during development on my ATI machine I've made an assumption or used a feature that only ATI handles "correctly". That is, the ATI drivers are letting me do something that the RefRast says is wrong but I think is correct. Nvidia hardware is just somewhere in the middle - not quite as accurate as the RefRast, and not quite as wrong as the ATI.

One final gripe - PIX doesn't do a good job of debugging HDRI formats. Or rather, it could do a much better job. I'm getting lots of black images and lots of white images - it'd be nice to be able to arbitrarily scale them so I can tell if it's really black or just extremely small values - and for the white areas find out if they are actually 1.0 or are actually > 1.0 and can't be displayed.

So, after I grab something to eat:

  1. Run the reference rasterizer through PIX and see if I can find out where it goes wrong.

  2. Check that the reference rasterizer also disagrees with ATI on my other machine (it should do, but this is just a sanity check!)

  3. Scream, shout and stamp my feet until it works [flaming]



Also found out that due to permissions on this lab machine, I have to set up VC++'s directories each time I log back in. So before I can do any work after lunch I'll have to reconfigure it again. Yay!
Sign in to follow this  


6 Comments


Recommended Comments

All vs_2_0 or fixed function (for screen-aligned quads) for geometry, and ps_2_0 everywhere else.

I'll double-check it in a bit, but I was pretty sure that only the SM1 models had clamped/restricted registers?

Jack

Share this comment


Link to comment
This is indeed strange behavior... I wish I had more to offer.

I'll just say...
Quote:
I have to set up VC++'s directories each time I log back in.
Shoot the network admin. [evil]

Share this comment


Link to comment
Quote:
COLOR[n] Diffuse or specular color. For shaders prior to vs_3_0 and ps_3_0, this data ranges between 0 and 1, inclusive. Starting with ps_3_0, there is no restriction on the data range.


If you're using the COLOR semantic that could be the problem.

Share this comment


Link to comment
Thanks for the info james, but unfortunately I'm not using that semantic [headshake]

All HDRI-related data is passed in via float shader constants or just computed internally in the shader and then written to a FP render target. It's a pretty simple setup (or, so I thought!)..

I'm getting a bit closer I think - I have a RenderScene() function - PIX is showing it doesn't actually do anything when running under the RefRast - but it has several 100 calls when running with hardware... Which is an interesting clue [oh]

Cheers,
Jack

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now