Blender 2.80 EEVEE unable to render some materials on OSX due to the OpenGL implementation #63935

New Issue

Talha Saruhan · 2019-04-27T12:49:24+02:00

Talha Saruhan commented

2019-04-27 12:49:24 +02:00

System Information
Operating system: Darwin-17.7.0-x86_64-i386-64bit 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 Ti OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-10.33.0 387.10.10.10.40.105

Blender Version
Broken: version: 2.80 (sub 58), branch: blender2.7, commit date: 2019-04-21 20:30, hash: 797539e76c
Worked: (optional)

Short description of error
When I add more than 2 normal maps to a material (multiple principled BSDFs mixed together), it breaks the material and yields a flat pink/purple color that pops up when there are missing textures. I'm attaching a video below that demonstrates the bug. Also, even if I add a mix shader with factor set to 1, this whole material at the top node and a simple diffuse at the bottom, it still gives the same results. So, it breaks the material completely.

blender-eevee-bug-recording.mov

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

**System Information** Operating system: Darwin-17.7.0-x86_64-i386-64bit 64 Bits Graphics card: NVIDIA GeForce GTX 1080 Ti OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-10.33.0 387.10.10.10.40.105 **Blender Version** Broken: version: 2.80 (sub 58), branch: blender2.7, commit date: 2019-04-21 20:30, hash: `797539e76c` Worked: (optional) **Short description of error** When I add more than 2 normal maps to a material (multiple principled BSDFs mixed together), it breaks the material and yields a flat pink/purple color that pops up when there are missing textures. I'm attaching a video below that demonstrates the bug. Also, even if I add a mix shader with factor set to 1, this whole material at the top node and a simple diffuse at the bottom, it still gives the same results. So, it breaks the material completely. [blender-eevee-bug-recording.mov](https://archive.blender.org/developer/F6984560/blender-eevee-bug-recording.mov) **Exact steps for others to reproduce the error** [Please describe the exact steps needed to reproduce the issue] [Based on the default startup or an attached .blend file (as simple as possible)]

Talha Saruhan commented

2019-04-27 12:49:24 +02:00

Added subscriber: @talhasaruhan

Marco commented

2019-04-28 15:40:14 +02:00

Added subscriber: @nacioss

Marco commented

2019-04-28 15:40:14 +02:00

Please send us the blend file to reproduce the issue.

Philipp Oeser commented

2019-04-29 09:59:02 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-04-29 09:59:02 +02:00

Not sure I can reproduce (file below seem to work for me)

#63935.blend

If this still turns out to be a bug it might be related to #63464 [see comment about tangents in D4672].

But as it seems to work in above file, we still need a .blend for this report that shows the error.... also above video doesnt seem to play....

Not sure I can reproduce (file below seem to work for me) [#63935.blend](https://archive.blender.org/developer/F6991038/T63935.blend) If this still turns out to be a bug it might be related to #63464 [see comment about tangents in [D4672](https://archive.blender.org/developer/D4672)]. But as it seems to work in above file, we still need a .blend for this report that shows the error.... also above video doesnt seem to play....

Talha Saruhan commented

2019-04-29 10:32:43 +02:00

Here's the .blend file. The issue may not have anything to do with normal maps. I think the problem rather has something to do with the number of textures or the texture memory required. Please note that the actual textures are not packed into the blender file because it would take forever to upload it with the textures. Also, one more thing, when I used procedural textures instead of image textures, the bug didn't seem to occur.#63935.blend

Here's the .blend file. The issue may not have anything to do with normal maps. I think the problem rather has something to do with the number of textures or the texture memory required. Please note that the actual textures are not packed into the blender file because it would take forever to upload it with the textures. Also, one more thing, when I used procedural textures instead of image textures, the bug didn't seem to occur.[#63935.blend](https://archive.blender.org/developer/F6991153/T63935.blend)

Philipp Oeser commented

2019-04-29 11:04:11 +02:00

Cant do much without the (highres) textures, but seems to work (with 1K textures):

T63935_1k_packed.blend

Please verify if above file works, then try to increase resolution to see when it breaks (if this is a memory problem)
Also: does running with --debug-gpu show something interesting regarding memory (in your case of failure)?

Cant do much without the (highres) textures, but seems to work (with 1K textures): [T63935_1k_packed.blend](https://archive.blender.org/developer/F6991221/T63935_1k_packed.blend) Please verify if above file works, then try to increase resolution to see when it breaks (if this is a memory problem) Also: does running with `--debug-gpu` show something interesting regarding memory (in your case of failure)?

Talha Saruhan commented

2019-04-30 15:11:32 +02:00

The file you attached doesn't work on my machine. I'm going to try the --debug-gpu argument and post the news.

Talha Saruhan commented

2019-04-30 16:17:45 +02:00

Ok, here are the results:

GPUShader: linking error:
ERROR: Implementation limit of 16 active fragment shader samplers (e.g., maximum number of supported image units) exceeded, fragment shader uses 20 samplers

I'm attaching the full debug info file (/Applications/blender-2.80/blender.app/Contents/MacOS/blender --debug-gpu &> ~/Desktop/blender-gpu-debug.txt), so you can take a look at it as well.blender-gpu-debug.txt.

Now, as far as I understand this either has something to do with the supported OGL version (4.1) or Nvidia's driver implementation for OSX. But can Blender do anything to work around these issues? After all, many people use Macs for content creation.

Ok, here are the results: *** GPUShader: linking error: ERROR: Implementation limit of 16 active fragment shader samplers (e.g., maximum number of supported image units) exceeded, fragment shader uses 20 samplers *** I'm attaching the full debug info file (/Applications/blender-2.80/blender.app/Contents/MacOS/blender --debug-gpu &> ~/Desktop/blender-gpu-debug.txt), so you can take a look at it as well.[blender-gpu-debug.txt](https://archive.blender.org/developer/F6995283/blender-gpu-debug.txt). Now, as far as I understand this either has something to do with the supported OGL version (4.1) or Nvidia's driver implementation for OSX. But can Blender do anything to work around these issues? After all, many people use Macs for content creation.

Clément Foucault was assigned by Philipp Oeser

2019-04-30 16:26:22 +02:00

Philipp Oeser commented

2019-04-30 16:26:22 +02:00

Added subscriber: @fclem

Philipp Oeser commented

2019-04-30 16:26:22 +02:00

Thx for getting back, this is probably in good hands with @fclem?

Talha Saruhan commented

2019-04-30 16:33:55 +02:00

Yep, it's not about the version itself as the specification doesn't include a max limit. In fact 16 is the minimum that specification allows, funny eh?

It's caused by the poor OpenGL drivers :(

glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, &i);
>> 16

Now, the question now is, can we do anything about that? Sure, it might not be optimal from a performance point of view, but it should be fine for most applications as games usually feature more complex and dynamic scenes than we work on in Blender and they can render in real time.

Yep, it's not about the version itself as the specification doesn't include a max limit. In fact 16 is the minimum that specification allows, funny eh? It's caused by the poor OpenGL drivers :( ``` glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, &i); >> 16 ``` Now, the question now is, can we do anything about that? Sure, it might not be optimal from a performance point of view, but it should be fine for most applications as games usually feature more complex and dynamic scenes than we work on in Blender and they can render in real time.

Talha Saruhan changed title from ~~Blender 2.80 EEVEE More than 2 Normal Maps Cause Purple Material~~ to Blender 2.80 EEVEE unable to render some materials on OSX due to the OpenGL implementation

2019-04-30 16:42:20 +02:00

Talha Saruhan commented

2019-05-01 10:56:47 +02:00

Following up, maybe we can branch off and have EEVEE render such materials by doing multiple passes? I may be able to work on this but I'm a rusty in OpenGL and I don't have much knowledge of the Blender's code base.

Also, this issue might seem very minor and not worth to fix, but my GTX 1080 Ti has 32 texture units available for fragment shaders, as does the newest Nvidia cards such as RTX 2080 Ti. Meaning that, even if someone was on a well supported platform, they still couldn't work with very complex materials. As EEVEE is gaining popularity, more and more people are using it to preview scenes even if the final shot will be rendered on Cycles. And we can reasonably expect professional artists to hit or exceed 32 limit.

So, I believe working around this by doing multiple passes could benefit:

people like me, on damn OSX
professional with very complex materials exceeding hardware capabilities
people with older hardware that have fewer texture image units.

Following up, maybe we can branch off and have EEVEE render such materials by doing multiple passes? I may be able to work on this but I'm a rusty in OpenGL and I don't have much knowledge of the Blender's code base. Also, this issue might seem very minor and not worth to fix, but my GTX 1080 Ti has 32 texture units available for fragment shaders, as does the newest Nvidia cards such as RTX 2080 Ti. Meaning that, even if someone was on a well supported platform, they still couldn't work with very complex materials. As EEVEE is gaining popularity, more and more people are using it to preview scenes even if the final shot will be rendered on Cycles. And we can reasonably expect professional artists to hit or exceed 32 limit. So, I believe working around this by doing multiple passes could benefit: * people like me, on damn OSX * professional with very complex materials exceeding hardware capabilities * people with older hardware that have fewer texture image units.

Clément Foucault commented

2019-05-02 17:05:54 +02:00

Changed status from 'Open' to: 'Archived'

Clément Foucault closed this issue

2019-05-02 17:05:54 +02:00

Clément Foucault commented

2019-05-02 17:05:54 +02:00

For higher texture count we aim at using bindless textures extension on newer hardware. This should fix your second use case.

I think supporting multiple passes for separate texture is really not doable since all the texture may be needed for surface evaluation. If you mean rendering different bsdfs separately it might work but the cost of implementing such non trivial system is really high and the system bound to become obsolete.
Another idea would be to put texture into texture array if they have the same size. But again this is not trivial and have huge technical implications.

I see no point into putting effort into fixing this right now.

For higher texture count we aim at using bindless textures extension on newer hardware. This should fix your second use case. I think supporting multiple passes for separate texture is really not doable since all the texture may be needed for surface evaluation. If you mean rendering different bsdfs separately it might work but the cost of implementing such non trivial system is really high and the system bound to become obsolete. Another idea would be to put texture into texture array if they have the same size. But again this is not trivial and have huge technical implications. I see no point into putting effort into fixing this right now.

Talha Saruhan commented

2019-05-02 17:23:53 +02:00

I was talking about rendering groups of bsdfs, have them write to (an) intermediate buffer(s) then combining them later on with a final pass. But you're right, it'd take too much time to just develop let alone maintaining.

Btw, bindless textures seem really cool. Asking out of curiosity, do you have a road map ahead of you on that or just the hint of it?

I was talking about rendering groups of bsdfs, have them write to (an) intermediate buffer(s) then combining them later on with a final pass. But you're right, it'd take too much time to just develop let alone maintaining. Btw, bindless textures seem really cool. Asking out of curiosity, do you have a road map ahead of you on that or just the hint of it?

Clément Foucault commented

2019-05-02 17:28:20 +02:00

No official roadmap for this at the moment.

blender-admin commented

2022-09-06 07:55:21 +02:00

This issue was referenced by c0640ddff9

This issue was referenced by c0640ddff93664bb6bf7ea3b57146ed3ca462340

blender-admin commented

2022-09-06 07:55:21 +02:00

This issue was referenced by 32d19f7317

This issue was referenced by 32d19f7317e9f2d726230a67ba9fed623fee337e

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

Blender 2.80 EEVEE unable to render some materials on OSX due to the OpenGL implementation #63935