Paths

Table of Contentst

Differential D9524

Fix T82042: Crash when rendering huge images
ClosedPublic
Actions

Authored by Jeroen Bakker (jbakker) on Nov 10 2020, 5:06 PM.

Details

Reviewers

Clément Foucault (fclem)

Maniphest Tasks

T82042: Crash when rendering huge images on CPU 2.92.0 alpha

Commits

rB2e1498ff1619: Fix T82042: Crash when rendering huge images

Summary

Issue is related to the definition of the GL_MAX_TEXTURE_SIZE.

OpenGL does not clearly defined GL_MAX_TEXTURE_SIZE exactly means. Both on AMD and NVIDIA we
have issues with huge textures that they don't get created even if they are smaller. (See D9530: Added test case to research support of texture sizes for research).
This patch will try to create the texture in a smaller size when the texture creation failed.

Future

In my opinion we should create a solution that doesn't need downscaling. For this specific case ARB_sparse_texture might help to create cleaner code, but you still have to commit the whole image. Other option is to optimize the scaling current implementation isn't optimized for performance.

Diff Detail

Repository: rB Blender

Event Timeline

Jeroen Bakker (jbakker) requested review of this revision.Nov 10 2020, 5:06 PM

Jeroen Bakker (jbakker) created this revision.

Harbormaster completed remote builds in B11210: Diff 30942.Nov 10 2020, 5:08 PM

Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Nov 10 2020, 5:09 PM

Jeroen Bakker (jbakker) added a reviewer: Clément Foucault (fclem).

Jeroen Bakker (jbakker) added projects: EEVEE & Viewport, BF Blender (2.91).

save -> safe?

@Brecht Van Lommel (brecht) yes will change it.

I also want to perform more test to find out where current the limitations are. We might want to adapt the patch to these findings.

Jeroen Bakker (jbakker) added a parent revision: D9530: Added test case to research support of texture sizes.Nov 11 2020, 2:24 PM

A better workaround would be to just test if texture creation worked. In case it did not, divide it's size by 2 and try again. Since the size is clamped to max gl size (16K) then its half always fit the 8K requirement. See P1767. However, this does not fix T82591 at all.

You can always improve and add more cases for 8k limit and buffer limit but that's maybe too much driver dependent to be useful.

In the future, we might want to avoid requesting the fullsize image.

After some experiments I sticked to your solution as the code didn't became to complex.
My alternative was to do this in 3 steps (100%, 75% and 50% of the max texture size).

In my opinion we should create a solution that doesn't need downscaling (eg sparse textures, https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_sparse_texture.txt). I would assume that users would would want to render huge resolutions have modern GPUs. For GPUs not supporting this ARB we could still do the scaling.

Next to that we could also optimize the current pipeline so that even when the ARB isn't supported the GPU texture is updated by tiles. During rendering the area that changes is small. I could look into this for 2.92.

Harbormaster completed remote builds in B11278: Diff 31116.Nov 16 2020, 9:56 AM

Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Nov 16 2020, 10:01 AM

Jeroen Bakker (jbakker) removed a parent revision: D9530: Added test case to research support of texture sizes.Nov 16 2020, 10:13 AM

Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Nov 16 2020, 12:20 PM

Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Nov 16 2020, 12:24 PM

Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Nov 16 2020, 1:10 PM

Clément Foucault (fclem) accepted this revision.Nov 17 2020, 2:37 AM

This revision is now accepted and ready to land.Nov 17 2020, 2:37 AM

Closed by commit rB2e1498ff1619: Fix T82042: Crash when rendering huge images (authored by Jeroen Bakker (jbakker)). · Explain WhyNov 17 2020, 9:39 AM

This revision was automatically updated to reflect the committed changes.

Jeroen Bakker (jbakker) added a commit: rB2e1498ff1619: Fix T82042: Crash when rendering huge images.

Just a suggestion: The automatic scaling solution certainly seems like a friendly behaviour but from a UX perspective, the user isn't informed when this is happening. Would there be some possible way to notify the user when an image is too large? Perhaps just one of those on screen notification popups?
Something like:

"Warning: texture_64k.png has been downscaled to the maximum size supported by your GPU: 8,192px x 8,192px."

I'm just thinking about the possibility of a situation where a user is expecting a very high resolution image. Say for example, a user loading a monster sized texture for a photogrammetry scan of an area produced by other software. They load the texture they need, and perhaps is left scratching their head when it appears much lower resolution in the render result. It could result in some amount of confused head scratching trying to figure out what's happening. You wouldn't want the user to think in that situation that the issue is a bug in Blender (and creating a bug report here), so it might be helpful to notify them that it's just Blender getting around the limitations of their GPU.

Revision Contents
Changeset List

Path

Size

source/

blender/

imbuf/

intern/

util_gpu.c

12 lines

Diff 31143

View Options

source/blender/imbuf/intern/util_gpu.c

Fix T82042: Crash when rendering huge imagesClosedPublicActions