   Extremely Simple Pixel Shader
  Hi there,Firstly I'm in the process of doing some massive R&D, so I might be completely wrong with my assumptions here.  But here goes...Hardware accellerated programmable pixel shaders, presuming they aren't something I've just dreamt up or misunderstood, here is what I would like to do.I would like to create a bitmap of lets say 10x10 pixels. So quite small.  I would like to set the RGB values of each pixel to just all 0's for now (R=0,G=0,B=0), something simple. So I've got a black square.In my pixel shader code I would like to simply add 1 to each RGB value of eachy pixel of a texture being passed through it.So my texture would then have (R=1,G=1,B=1) for each pixel after just 1 pass.I would then like to render the output to a backbuffer, and then save the result to disk as a bitmap.So far, my assumptions have lead me to....Bitmap ->  Texture -> Pixel Shader -> Render-To-Backbuffer-Copy-To-Texture -> Save to disk.With all this said, does anyone have a tiny example of doing this (presuming it's possible) or could something provide me with more information of doing so.  Please bare in mind that I would like to do this in DirectX, C++ or .NET, no OpenGL.I've been googling for christ knows how long and even searched your forum but not had any luck so far other than samples which draw some crappy image to the screen, which I could mod, but as I'm a noob to this I'm trying to cut down the complexity of what I'm trying to learn here.btw, I'm a pro software engineer, just a noob with gaming/direct3d etc.Many thanks for your time in advance!Nick.   
  I'm not sure you can write back to a texture directly from the pixel shader like that (or rather, I'm pretty sure you can't, since there's no 1-to-1 mapping between texels and fragments, but I've been wrong once today already), but what will work for sure is if you just render a quad over the whole screen, textured with your bitmap, with a texture as a render target. Then in your pixel shader, you can modify the fragment's color to your hearts content (based on the original texture's color). This may or may not be good enough for what you're trying to do. I'm not familiar with how this works with DirectX commands but here's some code that should help you get started.   ;  Make a 2D orthographic view, and make the backbuffer the same dimensions as the original image. Then you will have a perfect texel-to-pixel mapping. Disable all texture filtering.   ;  A fragment shader (pixel) works on pixels that are mapped to a certain piece of geometry, so you're gonna have to work with a quad as mentioned earlier. If all you want to do is set every pixel to the same color, then go, no problem there. However, if you're planning on doing stuff like "every n-th pixel will be green, every m-th row will be white", then (probably) no, because the order in which fragments are processed is arbitrary.;Quote:Original post by toriA fragment shader (pixel) works on pixels that are mapped to a certain piece of geometry, so you're gonna have to work with a quad as mentioned earlier. If all you want to do is set every pixel to the same color, then go, no problem there. However, if you're planning on doing stuff like "every n-th pixel will be green, every m-th row will be white", then (probably) no, because the order in which fragments are processed is arbitrary.you can still compute that kind of stuff (every n-th pixel) because you have access to the texture coordinates when the fragment runs. those texture coordinates can be used to deduce which row and column the pixel is in, assuming we are rendering to a quad of course.   ;  Wow you guys are quick!Quote:Original post by lightbringerI'm not sure you can write back to a texture directly from the pixel shader like that (or rather, I'm pretty sure you can't, since there's no 1-to-1 mapping between texels and fragments, but I've been wrong once today already), but what will work for sure is if you just render a quad over the whole screen, textured with your bitmap, with a texture as a render target. Then in your pixel shader, you can modify the fragment's color to your hearts content (based on the original texture's color). This may or may not be good enough for what you're trying to do. I'm not familiar with how this works with DirectX commands but here's some code that should help you get started.Hey that still sounds like it would achieve what I am attempting to achieve so that's great.  At least it sounds like it would do what I would like to do, basically I would like to manipulate what is essentially an array on the GPU that I can then render to disk.  With full hardware accelleration.  So basically 2D image effects are exactly what I'm trying to do.  Thanks for your tips.Quote:Original post by WilyCoderMake a 2D orthographic view, and make the backbuffer the same dimensions as the original image. Then you will have a perfect texel-to-pixel mapping. Disable all texture filtering.Wow this sounds even simpler, will I retain hardware accellerated manipulation of the image pixels?Quote:Original post by toriA fragment shader (pixel) works on pixels that are mapped to a certain piece of geometry, so you're gonna have to work with a quad as mentioned earlier. If all you want to do is set every pixel to the same color, then go, no problem there. However, if you're planning on doing stuff like "every n-th pixel will be green, every m-th row will be white", then (probably) no, because the order in which fragments are processed is arbitrary.hmm, well I guess that isn't the way I would like to do it then.  I would like to enumerate through each pixel of the image in question on in the pixel shader code and perform basic arithmatic on it.  from top left to bottom right, random ordering just won't work.Surely this concept isn't impossible though right?  Articles I have read have suggested that non-graphical related processing can performed on the GPU by doing this?   ;Quote:Original post by WilyCoderyou can still compute that kind of stuff (every n-th pixel) because you have access to the texture coordinates when the fragment runs. those texture coordinates can be used to deduce which row and column the pixel is in, assuming we are rendering to a quad of course.hmm... well I'm going to have a deeper look into rendering to Quads and the like as I mentioned earlier I'm not clued up on Direct3D.  I'm presuming that this isn't exactly how I would expect it to be as it's all in 3D space? and the final output wouldn't necessarily be pixel for pixel mapping?  I read that Adobe were utilising the shaders in CS4 for performing effects on their images so I presume that they must have control over each pixel of the image in one foul swoop otherwise the effects would be pretty limited.;  Oh yeah, that texture coordinate method is a neat idea :) but you may get some minor noise coming from floating point inaccuracy (e.g. a pixel more here, a pixel less there, tiny bit different on different hardware). But of course if you're working with relatively small bitmaps (1000s of pixels in each dimension) you can still consider floats reliable. And on bigger maps you probably won't give a damn about a stray pixel anyway.   ;  Reading and writing precisely the pixels you want isn't too difficult, especially under DX10 where you no longer need the half pixel offset.However, you can't process the pixels in any particular order without killing performance - this is because the hardware runs the shaders for many pixels simultaneously to get it to go at a decent speed. It's like running multiple CPU threads, without any synchronization - sharing data between those threads won't work correctly unless it's read only.You can do some combining of results though as you can read from multiple source pixels when you write one out. For example, you could output a half sized texture where each result pixel was combined from 4 source pixels. This lets you do many image processing effects like blurs. Reading from too many source pixels does get slow though, and there are limits.You can also do multiple passes, for example most blur effects are done in two passes - one horizontal and one vertical for speed.If you can't rework your algorithm to work well within those limits then you're probably better off using the CPU.   ;Quote:Original post by toriOh yeah, that texture coordinate method is a neat idea :) but you may get some minor noise coming from floating point inaccuracy (e.g. a pixel more here, a pixel less there, tiny bit different on different hardware). But of course if you're working with relatively small bitmaps (1000s of pixels in each dimension) you can still consider floats reliable. And on bigger maps you probably won't give a damn about a stray pixel anyway.You should take a look at some GPGPU stuff. Solving problems with GPGPU methods requires exact access to the correct pixel by way of texture coordinates.Quick example would be doing the physics of a particle system on the GPU. Each pixel of a texture stores the x, y, and z of the particle. Another texture of identical size contains the x, y, and z of the velocity. And a 3rd texture does the same for the acceleration. To do this kind of calculation on the GPU you need EXACT access to the correct data. So getting the correct pixel absolutely can be done if you setup the textures correctly and always use quads.If you need any more verification that this can be done correctly, look at how they do it in GPGPU. We've been doing this kind of thing for a few years now, its not brand new, it works :)Also, remember you are not going to work with textures larger than 8192×8192 on consumer cards.   