- User Since
- Apr 1 2014, 1:52 PM (276 w, 2 d)
Jun 14 2019
Jun 12 2019
Jun 11 2019
Jun 10 2019
Apr 16 2019
response to Alexey's comment
LGTM, just made one minor suggestion
Apr 12 2019
see note above; apologies if it is already done and hiding somewhere I did not see
Apr 8 2019
See suggested changes, should be pretty straightforward to do, let me know if you need help
Apr 3 2019
Sep 4 2018
make sense, thanks
Aug 27 2018
Yes, we should have done this right away. I did a rewrite of the functionality that uses header files already included; it was posted in D50522 and the changes were approved and pushed to svn.
- Merge branch 'unpatched-master' into unpatched-master-target-offload-envvar
- while (0) edit
Aug 26 2018
- added do while(1) for macros
Aug 24 2018
- put fatal message for default tgt test
Alexey was not happy about adding an include, and we already used the define approach for the debug messages. So we reuse the same functionality that we already used for debug.
Agreed that Johnas suggested it, and given the problem with the include, Alexey urged me to change the code to what we have here.
I reworked the solution to avoid varargs, and proposed a more robust solution in D51226
Aug 23 2018
Aug 16 2018
Thanks to all for your valuable comments, much appreciated, really contributed to the quality of the patch
Aug 15 2018
updated comments status
fixed clang-format and moved fatal message function
Aug 14 2018
responded to comments
implemented suggest changes
responded to comments.
Addressed all remaining issues
Aug 13 2018
Good arguments, I see why the consistency of why linking the number of devices returned and OMP_TARGET_OFFLOAD environment is good.
Implemented the requested changes
Default policy is now selected when registering the libraries, and will default to mandatory/disabled depending of whether there are one or more devices/none.
Aug 10 2018
Added a mutex around changing DEFAULT to MANDATORY or DISABLED
Added proper action when discovering failure (which is immediate abort of function being performed)
Failure to locate data during an update is now tolerated (a warning could be issued)
Did you consider this example?
I disagree. As it is currently written, omp_get_num_devices() can also grow over time, so you can also have it return zero, only to increase later to a larger number. What does that do to DEFAULT?
I believe the current policy is ok; if any device fails for any reason on first use, it becomes disabled. Anyone that want to rely on devices being there should use the MANDATORY policy.
I am happy to add a lock around the change of DEFAULT to MANDATORY or DISABLED.
Aug 9 2018
Aug 3 2018
Aug 2 2018
First, there missing sync for the _tgt_target_data_begin_depend, tgt_target_data_begin_depend_nowait, tgt_target_data_update_depend, tgt_target_data_update_depend_nowait,
Look at the end versions of the call for a possible implementation.
Second, it would be better IMO to use kmpc_omp_wait_deps instead of the broader task wait.
Nov 22 2017
Changes are correct, a memory barrier is needed between allocating/reseting values to zero and publishing the pointer. That way, another thread see the published pointer only once all of the zeroing is complete.