Remove the call to set device flags.

[WeiqunZhang]

Summary

This is no longer needed and may result in failure due to that the device
has already been set and initialized in another code.

Additional background

Exa-Wind has a code that uses both Kokkos and AMReX. It seems that
the call to cudaSetDeviceFlags fails because of that.

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• are described in the proposed changes to the AMReX documentation, if appropriate

[kngott]

I feel like this should be done more robustly, especially since other libraries could do something similar but fail to include our required flags. This could make an error that we can't track down very easily.

We should check to see if this returns "cudaErrorSetOnActiveProcess", and if so call "cudaGetDeviceFlags" to make sure "cudaDeviceMapHost" is on. If not, throw an error stating that we require it or throw a warning and use "cudaDeviceReset" to do the setup ourselves with their flags plus ours.

@maxpkatz: That sound right? (Also, do we still need this flag / is this flag still doing the same thing since this setup was built?)

[maximumcats]

I suggest we just remove the call to this API. On any platform that users realistically have access to today (>= CUDA 4, >= Fermi architecture), pinned memory is automatically part of a unified address space and automatically supported through the runtime API. I suspect this was added by someone reading the docs and thinking it would be needed just to be safe, but I don't think it's needed.

[WeiqunZhang]

OK. That would be the easiest!