One problem is Blender is BIG software, some times I not certain about where in Blender or what context is using a message. Screen image or video would help but no way exist for link that with .po files.
"Screen" and "Frame" synonyms are currently most important problems in italian translation.
Did some more deeper research. The commit mentioned above has nothing to do with this issue. In fact, i don't see issue here at all. At least there is no change in behavior since Blender version 2.75. All older versions did not have any logging around materials. All the versions starting from 2.75 are reporting 7 shaders synchronized to the shader manager.
Here the log.
@Sergey Sharybin (sergey) think raising hard limit is fine yes.
The issue is coming from hardcoded MAX_SOCKET set to 64. I've tried to remove such a static limit, but it's not so trivial within the current nodes design, especially for the texture nodes. I think it is safe to bump this constant to 512. This will only be ~16K extra stack memory usage per thread during evaluation which is really small for the modern systems.
Had a look here. So far managed to reproduce on Windows, didn't see this error on Linux. Most likely it's because of different timeout policies on different platforms (those timeouts are dictated by driver and OS and out of our control). The issue is very similar to the one described in out manual . It is not solvable in general case for as long as the card is not dedicated for compute (aka, has monitor attached to it).
Committed a work around for now. We are planning to abandon MSVC2013, so not really motivated spending days nailing down the issue.
I'm having similar issues to it being very slow, I'm running an i7-4810mq CPU with an NVidia 860m. As other users have mentioned - everything else works perfectly well, including 3dsmax, composite, digital fusion etc.
I can reproduce the issue with 2.78b, but not with 2.78c and master.
Please try updating to 2.78c and checking if it also fixes the issue for you.
I also have struggled with this kind of artifacts and found a simple trick how to avoid them. Basically you can calculate a dot product between normal and incoming vector and attenuate the normal map where it could cause problems viz https://blenderartists.org/forum/showthread.php?382497-Black-material-artifacts-on-flat-angle-surface-areas
This is the same problem as in T49921 - the normal mapping changes the surface normal, so the reflected ray would go inside the actual geometry, which isn't really possible.
The problem here is that you have Clamp enabled, which means that the Node is actually doing something (or rather, would do something if your textures were HDR).
However, there's no real reason to keep the full MixRGB node in the SVM code if only a clamp is needed, so I'll add a separate clamp-only SVM code.
Tue, Mar 21
Glad to hear that is working with the latest build. :)
Feel free to reopen this task if the same error shows up again in a different build in the future.
Confirmed, work with the latest build. Thanks.