That was the first thing I tried when I had the Problem, but the Update had no impact. I searched for new drivers today, but they are up to date. The manual also was not helpfull for me, but the error dosen't seem to be a comon problem and as you sad very Hardware configuration dependent.

Did some tests:
@Nominous (Nominous)
@Philipp Oeser (lichtwerk)

@Nominous (Nominous) Just tested, it seems OSL node gives better results. Thanks!

@Sebastian Schneider (Redphoenix) @Marko Tatalovic (Fuxna) The OSL node took me about a minute to bake on an i5-3570k (4.4 GHz, 4 threads total) using the settings I listed above in that blend file. The most important thing is to set the render sample to 1 in the render properties tab. Setting it higher slows the bake down drastically, but it's unneeded. I still think unlocking the bevel samples in the default bevel shader would be a good experiment and I think the OSL node is a good workaround for now.

The cause of problems so dependent on the setup is very difficult to investigate.
Have you tried upgrading GPU drivers?
See https://docs.blender.org/manual/en/dev/troubleshooting/gpu/index.html

thats strange, its even the same architecture(Polaris).
I've tested a lot today and it dosen't happen with Tile sizes of 64 and lower, extremly low sample count or volume without simulation data. Also Raw cache worked, but not VDB or Uni cache. RAM and VRAM are both utilized lower than 50%. (combining CPU and GPU or disabeling Noise had no impact).

15 - 30 min for baking bevel is not a right solution. Question is why are normal of the non beveled edges affected in the first place. Can't they be masked and mixed with original normals? All we got on this ticket are distractions, and no response from devs at all. Is it a bug, do we don't understand how to use it, is it a known limitation bla bla bla...

@Nominous (Nominous) Maybe, but for me computation time was insane.

The duplicate by Max (Raytraced) that was merged to this report forgot to mention that he experimented with increasing the bevel shader samples past 16 (512+) by using a custom OSL node, which seems to solve wireframe artifacts in the normal map bake: https://polycount.com/discussion/comment/2701351/#Comment_2701351 Maybe that would be a good path toward solving this problem?

I could reproduce it reliably, now I have not checked again, but from code I still see that there is no changes to mitigate this in at least kernel_filter_nlm_update_output method.

I rendered 100 frames but was unable to reproduce the bug on a Radeon (TM) RX 480 Graphics ATI Technologies Inc. 4.5.13586 Core Profile Context 19.50.01.05 26.20.15001.5006

Color Ramps are converted to a texture and then sampled from a 256 px wide image. There is an optimisation in Eevee when there are only two stops which explains why it breaks after adding another stop. See the following thread from twitter: https://twitter.com/BartekMoniewski/status/1229063557330984960

Is it still an issue ? Can it be reliably redone ?

Tried with 2.79, problem still persists. After that, I tried the driver given by the manufacturer which is AMD Raven Ridge 25.20.15030.4 and nope, still doesn't work.

Can you test with rendering blender from the command line. I could not reproduce with a 1050ti and a 2070.

mDt Real 0.0012029988
mDtMin Real 0.0260417499
assertMsg((mDt > (mDtMin / 2.)), "Invalid dt encountered! Shouldnt happen...");

crashed while baking:

aborting: Invalid dt encountered! Shouldnt happen...
Error raised in /Users/ankitkumar/blender-build/blender/extern/mantaflow/preprocessed/fluidsolver.cpp:243

you missed the blend file

Sure thing. Thanks.

We still don't know if the problem is with an NVidia driver or if it's in blender. Let's wait and see what the Cycles team will say.

thanks, considering it as solved then :)

In T57109#879045, @Bastien Montagne (mont29) wrote:

More than a week of inactivity, closing for now (we can always re-open should requested info be provided).

We are using gcc7 for official builds to comply with LTS distros and OpenVFX platform. Does not mean we do not support more recent compilers (most devs actually use gcc 8 or 9 already I think).

Issue is that the gpu_shader_image_color_frag is being used. And the file browser sets the color parameter of that shader to render the icons.
The draw manager should reset the color parameter to fix this issue.