JtpRangeIdsTest failed due to incorrect expectations.
freemo opened this issue · 9 comments
The following test fails and demonstrates the issue:
https://github.com/Syncleus/aparapi/blob/master/src/test/java/com/aparapi/runtime/JtpRangeIdsTest.java
I do not know here this test came from. Looks like it is testing the 2D java Range class to ensure that it creates the appropriate dims. But would have to study closer.
@grfrost yea im a bit confused myself. Was hoping you might know off hand. No worries, thanks.
@freemo The JtpRangeIdsTest is absolutely flawed. I spent some time with this, thinking this was a solvable problem, but it isn't. The test is rigged. For instance consider globalIdX=3, and globalIdY=1, according to the test this would give globalThreadId=1x12+3=15, now if we look into the test table entry test[15] it says that globalIdX should have been 7 and that globalIdY should have been 1, but according to this, that would given test table entry 1x12+7=19... 😆
So this test is a no go.
@freemo Please ignore my previous comments before the updating to this version. So this test is completely a no go, it only made me loose time to assess bugs in the test itself, while trying to follow what the Aparapi implementation does, and it looks like it does, more or less, mimics OpenCL behaviour of executing a group at a time. Aparapi executes one thread per local id for the entire workgroup size and then each thread iterates over the whole number of groups.
@CoreRasurae So your saying the behavior is normal and the test itself is flawed and should be removed?
@freemo Yes, this test is flawed. However it can be fixed to make some useful validation. It would just test the 2D range, there would be the need for tests for 1D, and 3D ranges.
@freemo removal of the test is an option too. As a test it is useless as it is.
@CoreRasurae What are you thought on just adapting the test so the values in the matrix allow it to pass? Since its not a bug that would ensure behavior remains predictable anf garuntees regression.