Fixed assignment with idx after changing device by willyborn · Pull Request #3420 · arrayfire/arrayfire · GitHub
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Footer
You can’t perform that action at this time.
After changing device, the assignment with index generates an exception (Invalid Memory Object when calling clSetkernelArg)
Description
Code to reproduce:
#include <arrayfire.h>
int main(int, char**) {
// Initialize the kernel array just once
af::info();
}
Output:
ArrayFire v3.9.0 (OpenCL, 64-bit Windows, build b184388)
[0] AMD: Spectre, 6571 MB -- OpenCL 2.0 AMD-APP (3224.5) -- Device driver 3224.5 -- FP64 Support: True
-1- NVIDIA: NVIDIA GeForce GTX 750 Ti, 2047 MB -- OpenCL 3.0 CUDA -- Device driver 531.61 -- FP64 Support: True
OpenCL Error (-38): Invalid Memory Object when calling clSetKernelArg
Cause:
For Assignments on arrays with indexes, empty indexes are internally generated.
For each empty index, an empty device buffer is used as parameter to the assign kernel.
Since the empty device buffer remains unchanged, the resulting buffer of the 1st time is cached.
The cached device buffer is however dependent on the context, explaining why it failed after setdevice(1) (=changed context).
Changes to Users
1 bug less.
Checklist