compute-runtime
compute-runtime copied to clipboard
Don't use "abortUnrecoverable" from Windows Device Driver Code
I am using OpenCL on Windows with D3D11 texture sharing and the following crash has driven me nuts:
Abort was called at 362 line in file:
D:\qb\workspace\21461\source\vpg-compute-neo\shared\source\os_interface\windows\wddm\wddm.cpp
That wasn't really helpful at all. Probably, most people won't even know that the source file for this is located in this "Linux-Repository".
So, I found the source file, but I didn't know which version I need to look for, in order to get a match with the line number. I tried to guess based on the graphics driver date and found the right line:
https://github.com/intel/compute-runtime/blob/3aff89199d028e2d3e444bbdbdca8138618794fa/shared/source/os_interface/windows/wddm/wddm.cpp#L365-L379
But that didn't help much. I still didn't know what the problem was, because you are totally ignoring the error code that is returned. Instead you are executing that stupid UNRECOVERABLE_IF
macro.
Could you please - at least in the Windows code - return the actual error codes in the way as it's documented in the DDK? What you are doing here is not the right way (I can only speak for Windows).
That would be great! Thanks
PS: It was an out-of-memory error and it would have saved me 5h when the correct error code would have been propagated.
• We acknowledge the feedback regarding INRECOVERABLE_IF needing a better explanation – we will follow up with a section in README
• In this specific case, we have found a way to avoid the abort() altogether by using a different combination of flags for trim operation and a regular failure when the trim is unsuccessful.
Let’s keep the issue open until two of the follow-up actions above are complete.
Hi Piotr,
Thanks a lot for responding.
My actual point is that applications that are making use of those features don't know where to find the source code - even more on Windows - for which there is no way to compile and debug the code. Hence, a documentation in the source code doesn't help much. That's why the driver should return an appropriate Windows error code instead of crashing silently.
It's great that you found an alternative way for this specific situation. What I wanted to point out though, is that there are many other cases that I've seen, which are having the same issue.
Kind regards, sw
We updated documentation descirbing our usage of UNRECOVERABLE_IF