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
VkFFT error code handling #40
Comments
It may be different case by case, but I am thinking that generally we do not need to make working examples catch these exceptions nor make these messages more user friendly. Instead, I am thinking that the better approach is to treat them as run-time asserts and then debug the code so that these run-time asserts don't fail. In particular, if there is something that typically leads to one of these failures then we probably should check for those circumstances before asking VkFFT to handle it. For example, if VkFFT is complaining that a particular needed input is missing, we should probably be checking for that input in our code earlier and then do whatever ITK code typically should do when that kind of input is missing; and not call the failing VkFFT at all in this case. |
@Leengit For context, I typically see these failures (buffer copy, kernel copy, fence, etc) in the context of trying to run GPU FFT on very large images, in this case on a 1400x1400x1400 image. If we were to introduce a check it would need to involve asking the GPU if it has sufficient buffer size for everything the FFT requires (input buffer, output buffer, kernel, other?). Disadvantages of trying to implement an explicit GPU memory precheck:
Advantages of a GPU memory precheck:
|
Good, persuasive. Yes, in scenarios like "GPU availability may depend on other processes and could decrease after our check", it is sounding like letting VkFFT try is the way to go. We would try to parse VkFFT's error code in our ITK code and present it to the user in a manner typical of other ITK modules. Hopefully, VkFFT will rarely return a code that we haven't anticipated, but we should be prepared for that case anyway -- reporting what VkFFT has told us, and potentially contributing back to VkFFT to make those messages as clear as possible. In short, that's looking like your Proposal no. 2. |
Exceptions thrown by ITK VkFFT classes are disruptive to pipeline flow and difficult to read. For example, from Python benchmarking on BIL workshop2 node:
Proposals:
The text was updated successfully, but these errors were encountered: