Modifiable persisting variables
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?
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
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
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]
Quote:Original post by XmonYou 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.
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.
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 Xmonhmm, 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.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?
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement