Environment: i5-3230M When running the attached code against the latest git dev code of beignet, and also the latest release (llvm 3.5 for both), the code does not run all of the kernels in their entirety. On my machine, the end of output is a whole bunch of zeros indicating that some kernels did not run. When running with a smaller POINTS macro (in test.cpp) (on the order of 500 * 64), all of the data is collected correctly. So the problem is that with a very large number of kernels, the program stops working correctly. I would expect that all of the kernels would run correctly, or at least that an "out of resources" error would be thrown, if that is indeed what is happening. This is just speculation. Thanks, Matt
Created attachment 114886 [details] test code to reproduce problem Sorry, I thought I'd attached this yesterday.
The bug has been confirmed, and we are working on it. Thanks for reporting it.
The root cause is the drm_intel_gem_bo_context_exec() failed to bind the command buffer when there is a very large array. Beignet forget to check the return status. This bug has been fixed in current master branch. Please verify. Thanks.
What behaviour am I supposed to be seeing now? I did a git pull, and ensured that my ICD was picking up the newly built code, but I can't see any difference in behaviour for the test code.
(In reply to bugReporter92 from comment #4) > What behaviour am I supposed to be seeing now? I did a git pull, and ensured > that my ICD was picking up the newly built code, but I can't see any > difference in behaviour for the test code. I thought this is a duplicate bug as debian bug at : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781875 "beignet: silently does nothing on large arrays". After I double checked your test case, it may not be the same. You may run into one known GPU hang issue. Please refer the README.md's known issue section, there is one item to describe how to check whether a GPU hang occur and how to disable GPU hang to try your kernel again.
You're right. I didn't check before whether the GPU was hanging. Hopefully there will be a more graceful solution for handling larger kernels later on. After turning off the hang check, the kernel works as expected. Does the driver code get some warning when the GPU hangs? It might be nice to throw an "out of resources" message to the callback in this case as well, as I didn't even suspect that the GPU was hanging.
(In reply to bugReporter92 from comment #6) > You're right. I didn't check before whether the GPU was hanging. Hopefully > there will be a more graceful solution for handling larger kernels later on. > > After turning off the hang check, the kernel works as expected. > > Does the driver code get some warning when the GPU hangs? It might be nice > to throw an "out of resources" message to the callback in this case as well, > as I didn't even suspect that the GPU was hanging. GPU hang is an asynchronous error event occured in KMD. From user space, there is no elegant way to catch this error efficiently. To check the dmesge for each kernel running is obviously not a good idea. Right? So we have to just put this in the known issues currently. If you get any better idea, please feel to share with us here or send it to the mail list. Thanks for your feedback.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.