allow libm_intrinsics fallback #985
Conversation
There was a problem hiding this comment.
I feel like it would be less effort to not have entries in the libm_intrinsics map for any function we don't want to hook at all.
Looking a bit closer at it, several LibmCustomIntrinsics are implemented by expanding them to GLSL ops, so I think the reason the remaining ones panic is that they were meant to be implemented the same way.
Do you have a specific subset in mind that you need?
| } | ||
| */ | ||
| _ => return None | ||
| }) |
There was a problem hiding this comment.
Commenting this stuff out doesn't seem the best. I think I understand what's going on, but maybe each of these should be evaluated to see if there is a GLSL fallback and removed from the LimCustomIntrinsic type entirely, if not.
It would be nice if the only software operations kept would be the ones that are relatively cheap (and mostly just operate on the binary representation).
|
i need erf* functions and it doesn't seem to be on GLOps(i'm not sure) |
allow using libm software implementation as fallback