Sign in to follow this  
Xmon

Modifiable persisting variables

Recommended Posts

In HLSL (compiled as shader version 3) is it possible to have a modifiable variable that persist longer than a single pass (e.g. add color value over a number of pixels)? If so how many of these can I have?

Share this post


Link to post
Share on other sites
No, you cant do this. The only valid output is to a render target (or multiple render targets if using MRT) or depth buffer. Writing to a parameter or constant isn't persistant (and you cant read it back either)..

You can use various tricks with down-sampling and blending to perform these sorts of operations - e.g. accumuate, average, min, max etc...

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by jollyjeffers
No, you cant do this. The only valid output is to a render target (or multiple render targets if using MRT) or depth buffer. Writing to a parameter or constant isn't persistant (and you cant read it back either)..

You can use various tricks with down-sampling and blending to perform these sorts of operations - e.g. accumuate, average, min, max etc...

hth
Jack


OK, thanks. The values I want to accumulate over a number of pixels fit into a 32bit map and a depth buffer (certain pixels has to be grouped). Is it a good idea to render to a low resolution target and copy it to system memory and let the cpu do the computation. I'm gonna process the data in sequence so maybe I can have a pointer that step thrue the bit-map in turn, to make reading effective. If the cpu stall the system I can divide these computations over a number of frames. Is this easely done or is there better and faster solutions.


Quote:
Original post by jollyjeffers
You can use various tricks with down-sampling and blending to perform these sorts of operations - e.g. accumuate, average, min, max etc...


Where do I find information on this, is there any usefull articles on the web or in some book?

[Edited by - Xmon on June 8, 2006 9:06:12 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Xmon
Is it a good idea to render to a low resolution target and copy it to system memory and let the cpu do the computation. I'm gonna process the data in sequence so maybe I can have a pointer that step thrue the bit-map in turn, to make reading effective. If the cpu stall the system I can divide these computations over a number of frames. Is this easely done or is there better and faster solutions.
You might be able to get it done easily via some heavily optimized CPU work, but in general any sort of locking and reading-back of data is slow.

Bare in mind that a GPU is specifically built for graphics processing - its a monster at such work, so making use of it where possible is worth the effort. Sometimes thinking in terms of the GPU rather than in terms of a CPU can help - they don't really work in quite the same way.

Quote:
Original post by Xmon
Quote:
Original post by jollyjeffers
You can use various tricks with down-sampling and blending to perform these sorts of operations - e.g. accumuate, average, min, max etc...


Where do I find information on this, is there any usefull articles on the web or in some book?
hmm, not sure if there are any articles... but its essentially a form of post-processing on the image. There are LOTS of articles online about that.

The "PostProcess" sample in the SDK shows you the basic mechanics of doing post-processing and in particular "kernel filtering" (taking multiple samples and writing an output). The "HDRLighting" and "HDRPipeline" samples both use down-sampling to obtain a maximum and/or average luminance value - you could take a look at those for an example.

hth
Jack

Share this post


Link to post
Share on other sites

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

Sign in to follow this