bisected and it was fixed by rB96abe5ebbc55: DRW: Fix issue with batch reusing freed VBO indices.

• Fix static warning

Hello guys. Same problem here and I think you can narrow it to UBUNTU.
It does not happen on Ubuntu 20.04. No problem on Arch and Fedora.
But it happens from Ubuntu (and PopOs) 20.10, and I just tried now on 21.04 same bug (it also happens on Wayland or Xorg).

@Cambell Barton Hi. Can you reopen? It looks like 2.93 fixed, but shading for caps is still slightly different.
And it is totally wrong for other versions (3.0 i.e.)

Don't know which commit did it, but this bug is resolved on my end. 8dc95f61f3dff4e5686c2a278bd44db714065b20
macOS 10.14, Intel HD 6000

Another user has confirmed this bug here: T78710#1158178.

Don't have any M1 to test in the triaging team, but confirming due to two reports.

bisecting says the crash caused by rB22574f741c4e4d142c7068316296d24bbfc2a12c

I can reproduce the crash for version 3.0.0, hash: rB0061150e4c9.
Steps would be little different to reproduce the crash because once collection is excluded, it is not possible to pick any object from that collection

I have FHD on my GTX 1070 and in Solid 223 fps.
So about four times the fps at a quarter of the resolution, is about right.

Thanks for the hint, I edited my comment. I disabled vsync and then used a script to count how long it took to animate across the 250 frames and calculated fps from that. The numbers above should be pretty accurate now. (yeah, even at 4k the default cube scene maxes out at ~70fps for me on both versions so the 60fps numbers there seem right for solid view)

Hi Clément and Jesse,

In T88170#1159717, @Clément Foucault (fclem) wrote:

This is due to a difference between Cycles and EEVEE.

EEVEE applies ensure_valid_reflection on glossy normal input where Cycles only applies it on normal mapped & bump node output.

Here is an example of the same behavior in cycles.

Unfortunately, we need to use ensure_valid_reflection to avoid nasty artifacts on glossy BSDF even without bump/normal mapping (see T81070 & T78501).

We keep the same behavior when SSR is off to keep consistency.

Note that EEVEE won't distort the normals for diffuse.

Sadly I can repro here:
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070 with Max-Q Design/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 466.27
High-DPI display (4k so there's lots of pixels to shade)

macOS 10.14, Intel HD 6000, rB8dc95f61f3dff4e5686c2a278bd44db714065b20

In T86194#1126796, @Germano Cavalcante (mano-wii) wrote:

In this case, it may be related to the problem reported in T78845: Some hair particles are rendered the wrong material in EEVEE

The last one also seems to have much greater weight for changes in normals across a continuous surface than for changes in depth, with sharper darkening of crevasses and brightening of ridges, and much higher contrast in general.

rB267a9e14f5a7 may have introduce a bit more overhead but not that much (would expect max 5% change). This seems to affect all modes.

Those sound very interesting. I wish you plenty of luck as you make advancements to Eevee along with trying Apple's Metal API! Hopefully, there will be an announcement for this! In he meantime, I'll experiment with some workarounds myself.

Can confirm the difference, seems like Cycles is basing this on window coordinates whereas Eevee does this on area coordinates (this is just a quick shot in the dark).

With that said, you mentioned that there's a 16 texture limit. Is that for all standard computers, or is it just a MacOS limitation?

Most have a limit of 24 or 32 textures. This is without using bindless textures which we currently do not use for EEVEE (long term TODO).

That's certainly frustrating... While I would like to change operating systems, I just acquired this computer and I'm not interested in swapping them so soon. On top of that, I have no idea what would carry over should I switch. Perhaps this is something I'll investigate once I'm in the market for another computer again?

Think this is mostly about the noise for the last case (increasing the distance seems like the way to go -- I would even argue that increasing the factor should not be necessary?)

Well it is a "software" limitation as it is the OpenGL driver that is well bellow standard on MacOS. Only 16 textures can be used in the shader and EEVEE uses ~8 of them for internal purpose. So for the time being it is an expected limitation unfortunately.

@Germano Cavalcante (mano-wii) for mee all looks fine too!

Transforming verts.