As it turns out, this ProgPoW tree builds the ProgPoW OpenCL kernels using ProgPoW epoch derived back from the coarse Ethash DAG epochs. As a result, kernels are only built correctly, and the ProgPoW computation is only correct, very rarely - only when the block number is at or just after an Ethash DAG epoch. So it is correct e.g. for block 30000 and 60000, but not for 10000, 29000, 31000, nor 7000000 or 10000000. (The last two of these are block numbers I've been using for benchmarks before, thinking the computation is hopefully correct. This news partially invalidates those benchmark results on AMD cards, and CUDA vs. OpenCL comparisons on NVIDIA cards.)
The host-side code for CUDA doesn't have the same problem. I didn't check all the history, but my guess is that when ProgPoW periods lower than Ethash DAG's were introduced, only the CUDA code was updated to reflect that. OpenCL was either forgotten or left for later, without this having been documented.
I'll probably send a PR fixing this in a few days, but I thought I'd bring this up in here first in case there are any comments.
As it turns out, this ProgPoW tree builds the ProgPoW OpenCL kernels using ProgPoW epoch derived back from the coarse Ethash DAG epochs. As a result, kernels are only built correctly, and the ProgPoW computation is only correct, very rarely - only when the block number is at or just after an Ethash DAG epoch. So it is correct e.g. for block 30000 and 60000, but not for 10000, 29000, 31000, nor 7000000 or 10000000. (The last two of these are block numbers I've been using for benchmarks before, thinking the computation is hopefully correct. This news partially invalidates those benchmark results on AMD cards, and CUDA vs. OpenCL comparisons on NVIDIA cards.)
The host-side code for CUDA doesn't have the same problem. I didn't check all the history, but my guess is that when ProgPoW periods lower than Ethash DAG's were introduced, only the CUDA code was updated to reflect that. OpenCL was either forgotten or left for later, without this having been documented.
I'll probably send a PR fixing this in a few days, but I thought I'd bring this up in here first in case there are any comments.