   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...hthJack   ;Quote:Original post by jollyjeffersNo, 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...hthJackOK, 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 jollyjeffersYou 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 XmonIs 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 XmonQuote:Original post by jollyjeffersYou 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.hthJack