Jeff Lait

Gaalvk
Since I fixed everything, I haven't encountered this error again. I'll try to reproduce it again; I need to come up with some kind of test, because it didn't cause any errors right away, only after some time.

Okay, thank you for keeping an eye out for this. It is possible that an accidental out of bounds had put things in a bad state that only showed up later.... But I'm not discounting this as the cause either.

Gaalvk
And a message to the developers: it would be nice to solve this problem at compile time - not to skip lines like (int2) (0.0), where a floating point number is in the argument of the int2 function, because most likely this is a typo and will cause problems later.

That is very worrying!

That should be legal, AFAIK, as 0.0 can coerce to 0...

Checking the opencl reference spec https://registry.khronos.org/OpenCL/specs/opencl-2.0-openclc.pdf [registry.khronos.org] page 13:

I believe from page 19 that the widening refers to scalar -> vector conversion, not float -> double. So it would seem this is entirely valid OpenCL code by the spec; but that doesn't stop a particular compiler from dying on it :<

Unfortunately, there is nothing we can do directly about this as the actual compilation is done by the driver.

Can you please submit a bug with a .hip file with this, along with your About Houdini so we can test against a similar OpenCL Driver?

Note that out of bound memory reads & writes can cause delayed errors that show up on other nodes. Those are usually the source of the "need to restart houdini".

It is sad when a play suddenly turns into a tragedy....

But it is important to hear this stuff, so thank you very much for both pushing Copernicus and reporting where things broke down.

If you can, please do submit the offending .hip so we can better understand how things failed. Because while I've seen this, I can only hope that our planned solutions to those pain points will work... I don't want to find out we fixed the wrong problem.

Please include a link to this thread as well.