(My most sincere apologies if i am wrong in my guess below, the intention is of course only to clarify)
I think you may have misunderstood how a shader works? My guess is that you think in the wrong direction.
You do NOT "re-position" a pixel, into a different location on the target (may it be a surface or the monitor) while you process it. You (kind of) do NOT process in a forward direction in a shader. You can NOT "place a pixel" just anywhere you like.
Instead, the system (hardware + driver + 3Dware) determines which pixels are visible and thus need to be painted. You can indeed affect this in advance, as a whole, eg. by painting only a part of the screen. But once the draw command is executed, the system concludes which pixels are involved and need to be painted, and this is non-negotiable and automatic.
Instead, your job is to provide content for that (and the other) pixels. The system kind of asks you (= the shader, your code) to "give something". This is where the re-positioning happens, as you can of course "give" anything you like. You can fetch it from anywhere, calculate it with code, or say clip() in which case you "give" nothing and the target pixel is left unpainted.
Example: You have a 8192x8192 px map that you what to paint onto a full 1920x1080 screen, with a 1:1px scale, by using a shader. Apparently, only part of the huge map fits the screen.
You do NOT first focus on a/any pixel, say for example (100,100), in the big 8192x8192 map and decide that you "throw it" into pixel (500,500) on screen. And you can not then focus on pixel (101,101) and decide that you "throw it" into say pixel (211,972) on screen.
Instead, the system will walk through all screen (target) pixels in parallel (in an order that you do not know in advance and will never know). All pixels are independent and unaware of each other - each pixel thinks it is the only pixel in the world but all pixels will be taken care of. The system WILL invoke your shader for each pixel.
At some point, the system will process screen pixel (500,500) - this is guaranteed and happens without your own active effort. Your job is now to provide content for this pixel. So in the shader, you say "yes, lets grab pixel (100,100) from the big source map this time". Equally well you could say "yes, lets grab pixel (99,100) from the big source map this time". And next frame (98, 100), then (97,100) etc., in fact that way producing a scrolling output for the user who views the result.
In the end, you will achieve exactly what you are considering with your question. You just need to think from the final result backwards into the source pixel - and not think from the source pixel forwards into the final result pixel.