GPU: Parallize track merger resolve kernel. - #3676
Conversation
5c3c2ab to
bd87a28
Compare
davidrohr
left a comment
There was a problem hiding this comment.
Code looks good, will check the output tomorrow.
There was a problem hiding this comment.
Can't we do 1 push and later on 1 pop?
There was a problem hiding this comment.
ah yeah, totally. Didn't pay attention to how push works. Removed the second push.
|
@fweig : This looks pretty good. Results are correct and it is pretty fast. Just one more comment. I would suggest to apply the below patch: The second parameter in the define defines the minimum number of blocks the GPU must be able to run for this kernel. This will set CUDA launch bounds to impose restriction to the register allocation, allowing the GPU to really run that many blocks. |
|
@fweig : I have seen some random crashes, and running it through valgrind I see some access to uninitialized memory: Could you have a look? |
|
The crashes seems to be caused by your |
|
Oh, sorry, I should have checked that. But it seems quite odd to my. My patch shouldn't actually change anything. What will happen is that the CPU code should just get the blockcount of 1 instead of 4 (which you had before). But how could that break the code? The change affects step 3, but I get the valgrind error already in the previous steps. I could only imagine that breaks step 3 in a way that corrupts memory, and then yields to subsequent problems in the previous steps. |
|
This is a weird one. I don't think your patch caused the bug. It just brought out what had been there before anyway, if it had any effect. The crashes appear randomly so maybe i was just (un)lucky when i rolled back the patch. |
|
@fweig : This might even be a gcc problem or something strange. |
|
I think it might be best to use builtin atomics instead of the OPENMP captures, which don't work well anyway. But it seems we would have to distinguish between gcc and clang: I'll have a look tomorrow. If you have nothing to do tonight, feel free to give it a try :| |
|
@fweig : So the problem is, you must not read the variable |
|
#3681 Should fix the problem with the atomics. Hopefully the builtins don't cause any trouble in the CI! |
|
CI ran already |
This PR replaces the serial resolve kernel with a parallel version, that runs in 2 steps:
I got about a ~40 times speedup over the serial version in my tests.