-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] ECAL Reco on GPU v2 #366
[WIP] ECAL Reco on GPU v2 #366
Conversation
char const* msg = cudaGetErrorString(result); | ||
printf("\n%s, line %d:\ncudaCheckFromDevice(%s);\n%s: %s\n", | ||
file, line, cmd, error, msg); | ||
assert(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to note that we have experienced an assert()
in kernel code (or in a function called by a kernel) leading to a device-side synchronization between CUDA streams, see #186 and #183. On the other hand I see I had noted in #183 (comment) that in case the condition can be checked at compile time the assert
would not lead to syncrhonization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx a lot Mattti! I did not know about this at all! just to note, i added this to provide at least some check on launching kernels from device side. Feel free to recommend a better check in here... this was copied from what you guys have in cudaCheck...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really have better ideas. But check with the profiler whether the kernels get run in parallel or not , the effect should be rather visible (see discussion and profile timelines in #183).
PR description:
Next iteration of ecal multifit. This is Work in Progress. The idea is
PR validation:
using the ecal validation exe