Eevee allocates entire render framebuffer texture for region renders #71692

New Issue

Ted Milker · 2019-11-19T22:12:33+01:00

Ted Milker commented

2019-11-19 22:12:33 +01:00

System Information
Operating system: Windows 10 64bit
Graphics card: EVGA GeForce GTX 1080 Ti SC Black Edition

Blender Version
Broken: v 2.80 (release)

Description
I need to render high DPI images for print and display materials. Eevee renders would fail(Blender will stop responding, never finishes render) when I tried resolutions at and exceeding 19200x10800. So I thought to work around this by partitioning my render into 4 quadrants with render region, rendering them separately and then combining them into one large image. However, these smaller images fail as well. According to --debug-gpu, even choosing a very small region of a 19200x10800 render will still attempt to allocate the entire 19200x10800.

If this allocation issue is corrected, I can use partition rendering to produce images that exceed the 16384x16384 texture size limitation on modern graphics cards.

If you'd like a real world example of the need for this: We've had a 20 foot by 10 foot pop-up display produced in the past that required a 150dpi image. This image would be 36000x18000.

eevee_issue.blend

Exact steps for others to reproduce the error
Open attached blend (maybe with --debug-gpu if you want to see allocation for yourself)

Hit F12 or choose Render->Render Image

This may also be related to #70305 (Eevee out of GPU memory on large render)

**System Information** Operating system: Windows 10 64bit Graphics card: EVGA GeForce GTX 1080 Ti SC Black Edition **Blender Version** Broken: v 2.80 (release) **Description** I need to render high DPI images for print and display materials. Eevee renders would fail(Blender will stop responding, never finishes render) when I tried resolutions at and exceeding 19200x10800. So I thought to work around this by partitioning my render into 4 quadrants with render region, rendering them separately and then combining them into one large image. However, these smaller images fail as well. According to --debug-gpu, even choosing a very small region of a 19200x10800 render will still attempt to allocate the entire 19200x10800. If this allocation issue is corrected, I can use partition rendering to produce images that exceed the 16384x16384 texture size limitation on modern graphics cards. If you'd like a real world example of the need for this: We've had a 20 foot by 10 foot pop-up display produced in the past that required a 150dpi image. This image would be 36000x18000. ![eevee_01.png](https://archive.blender.org/developer/F8145023/eevee_01.png) ![eevee_02.png](https://archive.blender.org/developer/F8145026/eevee_02.png) [eevee_issue.blend](https://archive.blender.org/developer/F8145022/eevee_issue.blend) **Exact steps for others to reproduce the error** Open attached blend (maybe with --debug-gpu if you want to see allocation for yourself) Hit F12 or choose Render->Render Image This may also be related to #70305 (Eevee out of GPU memory on large render)

Ted Milker commented

2019-11-19 22:12:33 +01:00

Added subscriber: @Teds

blender-admin commented

2019-11-19 22:12:33 +01:00

#70305 was marked as duplicate of this issue

Philipp Oeser commented

2019-11-21 14:06:33 +01:00

Added subscribers: @fclem, @lichtwerk

Philipp Oeser commented

2019-11-21 14:06:33 +01:00

@fclem: will confirm for now [not sure this can be avoided?]

Philipp Oeser commented

2019-11-21 14:07:46 +01:00

Added subscribers: @sorinv, @rboxman, @KlariceVulpes, @nokipaike

Philipp Oeser commented

2019-11-21 14:08:49 +01:00

Sorry, swallowed some information in #70305 (Eevee out of GPU memory on large render) by merging.

Ted Milker commented

2019-11-21 14:15:27 +01:00

@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.

Philipp Oeser commented

2019-11-21 14:39:57 +01:00

Added subscriber: @Jeroen-Bakker

Philipp Oeser commented

2019-11-21 14:39:57 +01:00

CC @Jeroen-Bakker

Maciej Jutrzenka commented

2019-11-21 14:55:50 +01:00

Added subscriber: @MaciejJutrzenka

Maciej Jutrzenka commented

2019-11-21 14:55:50 +01:00

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

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

Jeroen Bakker commented

2019-11-21 15:03:01 +01:00

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.

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.

Ted Milker commented

2019-11-21 15:23:04 +01:00

@MaciejJutrzenka 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 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.

@MaciejJutrzenka 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 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.

Maciej Jutrzenka commented

2019-11-21 15:34:10 +01:00

@Teds
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

@Teds 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

Jeroen Bakker commented

2019-11-21 15:40:28 +01:00

@Teds,

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.

@Teds, 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.

Ted Milker commented

2019-11-21 15:44:40 +01:00

@Jeroen-Bakker 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.

Jeroen Bakker commented

2019-11-21 15:47:26 +01:00

How would you solve SSR with overscan?

Ted Milker commented

2019-11-21 15:51:35 +01:00

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.

Jeroen Bakker commented

2019-11-21 15:57:39 +01:00

Removed subscriber: @Jeroen-Bakker

Clément Foucault commented

2019-11-21 16:09:43 +01:00

Changed status from 'Open' to: 'Archived'

Clément Foucault closed this issue

2019-11-21 16:09:43 +01:00

Clément Foucault self-assigned this 2019-11-21 16:09:43 +01:00

Clément Foucault commented

2019-11-21 16:09:43 +01:00

Added subscriber: @Jeroen-Bakker

Clément Foucault commented

2019-11-21 16:09:43 +01:00

Like @Jeroen-Bakker said, the screenspace effects will have problems with this ways of rendering. And even if you use overscan it won't match a fullscreen render and will always have discontinuity between tiles (unless you increase overscans to a ridiculous high value but this defeats the purpose and basically increase the overall vram usage).

What I'm planning to do to fix this limitation is to divide the render in a checkerboard pattern. This will lower the actual vram requirement for really high resolutions but it will make all screenspace effects blurry instead of having discontinuities (also I need to check if they actually do converge correctly in this case and not create blobs/blocky artifacts).

The pattern could also be scanlines but i'm not sure what is best (maybe a future option?).

Anyway, I consider this a limitation for the time being. I created a TODO task for this #71733.

Like @Jeroen-Bakker said, the screenspace effects will have problems with this ways of rendering. And even if you use overscan it won't match a fullscreen render and will always have discontinuity between tiles (unless you increase overscans to a ridiculous high value but this defeats the purpose and basically increase the overall vram usage). What I'm planning to do to fix this limitation is to divide the render in a checkerboard pattern. This will lower the actual vram requirement for really high resolutions but it will make all screenspace effects blurry instead of having discontinuities (also I need to check if they actually do converge correctly in this case and not create blobs/blocky artifacts). The pattern could also be scanlines but i'm not sure what is best (maybe a future option?). Anyway, I consider this a limitation for the time being. I created a TODO task for this #71733.

Ted Milker commented

2019-11-21 16:12:57 +01:00

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.

Jacob Merrill commented

2019-11-21 18:26:20 +01:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2019-11-21 18:26:20 +01:00

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.

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.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Eevee allocates entire render framebuffer texture for region renders #71692