- it it's possible the combination of functions are triggering a bug in the driver though (is there such a thing as colour overflow? - I'm think of each component of colour being operated on?)
I suspect something like that is what's happening. If even software rendering gets it, the code is very likely to be algorithmcally sound.
I had the impressions drivers don't
actually execute the code as written but run agressive optimization at shader compile time - and that sometimes does weird things.
I've spent once three days chasing an issue where I could render two channels, both individually fine and as expected, with no dependence on view axis. Yet when I summed them (and clamped the result to [0:1] to be sure to always get a valid color - I saw a dependence on view axis and the result did not look like the sum at all. Mathematically this is impossible - the video driver managed just fine.
Sometimes you can manage to not trigger these issues by re-writing the code in a slightly different way. Sometimes not.
I have no good advice how to isolate this further to give meaningful feedback to driver developers. The practical solution seems easy enough - don't use the agriculture effect while the driver exhibits the problem.
it may be advisable to remove this feature and then reduce the problems when using different video cards
smoothstep is a perfectly fine GLSL function - which is why it runs with basically any other video driver and even in the same form in another shader on the Intel driver you're using. There's no line in the code that's not there for a reason and can simply be removed without side effects, and I strongly suggest that you don't consider 'random deletion of lines' a valid strategy to create rendering code in the future.
We have quality settings for this very reason - if your setup can't handle something, you can dial quality a notch down.