@Philipp Oeser (lichtwerk) I think this can be avoided by clipping the viewport to the render region like Cycles does. You can see this in the viewport when it draws too, Eevee doesn't clip to the render region like Cycles will if one is set. I looked at the code and it appears Eevee uses very similar code to setting up for the viewport while rendering, which is probably where this slipped in.

CC @Jeroen Bakker (jbakker)

the solution or i should say workaround for this is... make 19200x10800 resolution of image and keyframe camera shift settings -1 -1, -1 1 , 1 1 ,1 -1
and just render this as 4 frame animation

Check https://docs.blender.org/manual/en/latest/render/eevee/limitations.html

In practice, using too much GPU memory can make the GPU driver crash, freeze, or kill the application. So be careful of what you ask.

IMO we could clarify this specific case better in the manual. The actual development is a feature request cq removal of a limitation, not a bug.

@Maciej Jutrzenka (Kramon) Unfortunately, it's not that simple. Try it yourself, if you shift the camera without changing the focal length, you just render more of the view, not a higher resolution version of the current camera view. I am working on an actual work around though, if i can figure out the math to generalize it, if they decide not to fix this.

@Jeroen Bakker (jbakker) Seems like a bug to me to use 10x the memory actually required to render a section of the view. Sure, it requires more math to setup the camera properly but what it's doing now is just brute forcing it and wasting a ton of GPU memory.

@Ted Milker (TedMilker)
ah yes forgot about that i long time ago did the math but don't have it now cose now i just use VM when i render huge stuff.... But it wasn't that complex

@Ted Milker (TedMilker),

If you have the math that will work with all the screen space effects that EEVEE provides, is complete and production ready, we are interested. Until then I am not convinced this could be classified as a bug.

@Jeroen Bakker (jbakker) You don't need any math to fix screen space effects, just math to clip the camera to the region. Screen space effect artifacts from region renders can be dealt with by adjusting the overscan option, assuming that's properly integrated into the fix.

How would you solve SSR with overscan?

The same way Blender solves it now when you change the camera's focal length and aspect ratio? Nothing is changing with the render path here, you're changing the camera being rendered to a camera that makes up the render region's aspect ratio with an adjusted focal length to match the original camera.

Thanks for the speedy decision at least. I'll pursue my work around using multiple cameras for now, maybe a useful tiling addon will even come out of it.

one way to murder this bug would be to use RTX / radeon rays instead of SSR.

it's a bit like shooting a fly with a shotgun, but it also kills many other flies.