This is a blatant and ugly hack catalyzed by NVIDIA's foolish decision to
break all legacy CUDA code that exploits warp synchronous behavior so as to
placate some internal C++ fetishists obsessed with letting CUDA code
spinlock. Yeah, not exaggerating.
It's best just to look away until the lid is dropped back down on this
unholy ark of the covenant decision. It didn't go well for those who opened
the ark, and it didn't go well here.
But on the bright side, beginning with SM 8.0, we know we can't trust the
behavior of warps so we can code accordingly.
That said, uninitialized variables up the wazoo in AMBER 20 are a much
bigger issue IMO. WTFF?
On Thu, Jul 30, 2020 at 6:29 PM David A Case <david.case.rutgers.edu> wrote:
> I asked this question on gitlab a week ago, but everyone is pretty busy.
> I'm hoping someone in the wider audience here might know the answer:
>
> The proposed MR ("support_ampere") to create an update for the released
> version does this:
>
> - set(SM70FLAGS -gencode arch=compute_70,code=sm_70)
> + set(SM70FLAGS -gencode arch=compute_60,code=sm_70)
>
> SM70 covers TitanV and V100. The proposed change is in master but I'd
> like to understand what is going on, and what the implications might
> be. Our users are compiling now with arch=compute_70, and they would
> be changing to arch=compute_60. What does this change do? Should we
> expect people to have issues with the current code (that just haven't been
> reported yet)? Or with the proposed change?
>
> ...thx...dac
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Aug 03 2020 - 13:00:02 PDT
