Fixing bug. RESOLVED:556370c6406e6b943b88affbe7728a5036b1ba22, this was catchable by using debugging flags, but seems to otherwise cause no issues. Investigating I found that it only clips the below ground level, so that must not have been affecting other levels. This is technically BIT_CHANGING since it resolves an issue. (details)
Making num_draw_points in fill_holes a constant. We were already using this value as a constant everywhere, but passing a constant by argument list makes it difficult/impossible for a compiler to optimize using that constant, unless it does inlining. Now, rather than passing the constant num_hf_draw_points (or sometimes a hardcoded 2) we just use num_hf_draw_points directly from constants_clubb. This massively improves the performance of a loop in fill holes when using nvhpc+omp, which was the motivation for this, but should also improve the performance on CPUs. Everything is BFB. (details)
Making compatible with latest clubb changes. (details)
Fixing bug. RESOLVED:556370c6406e6b943b88affbe7728a5036b1ba22, this was catchable by using debugging flags, but seems to otherwise cause no issues. Investigating I found that it only clips the below ground level, so that must not have been affecting other levels. This is technically BIT_CHANGING since it resolves an issue.
Making num_draw_points in fill_holes a constant. We were already using this value as a constant everywhere, but passing a constant by argument list makes it difficult/impossible for a compiler to optimize using that constant, unless it does inlining. Now, rather than passing the constant num_hf_draw_points (or sometimes a hardcoded 2) we just use num_hf_draw_points directly from constants_clubb. This massively improves the performance of a loop in fill holes when using nvhpc+omp, which was the motivation for this, but should also improve the performance on CPUs. Everything is BFB.