[Q-e-developers] QE-GPU and QE trunk, one step toward convergency

Paolo Giannozzi paolo.giannozzi at uniud.it
Sat Apr 20 21:32:52 CEST 2013


Hi Filippo

I admit that I never looked into the GPU stuff, and I never verify 
the potential effects on it of my changes: I rely on you for this task!

I think that the solution you propose is a reasonable one.
Asymptotically, if the CUDA version is going to stay, it has to 
be more tightly integrated with the rest of the distribution. 
There are many #ifdef's , notably  __MPI and __PARA that can 
be removed, in case you feel guilty of aggravated #ifdeffing.

I do not know what Layla thinks, but I am quite confident that she 
has a more urgent task these days!

Paolo

> due to on-going internal restructuring it is very difficult for me to
> keep constantly aligned the plugin to the latest version of the trunk.
> Despite I tried to put in place a set of naive scripts (not perfect
> scripts, just something semi-automatic to help me figure out which
> changes in the trunk may impact on the GPU code), I have to manually
> look very often to the code and fix dependencies. Until now, my
> philosophy was to completely let the trunk completely ignore the
> existence of the QE-GPU plugin. However it is not practical from a
> development point of view, not anymore. 
> 
> 
> What I would like to do, is to let the code in the trunk (so the main
> code) call eventually GPU routines if the plugin is used. This can be
> easily achieved by isolate piece of code with a preprocessor macro
> (__CUDA). 
> 
> 
> Here an example of the changes I have in mind applied to
> "PW/scr/addusdens.f90"):
> 
> 
> !----------------------------------------------------------------------
> SUBROUTINE addusdens(rho)
>   !----------------------------------------------------------------------
>   !
>   USE realus,               ONLY : addusdens_r
>   USE control_flags,        ONLY : tqr
>   USE noncollin_module,     ONLY : nspin_mag
>   USE fft_base,             ONLY : dfftp
>   USE kinds,                ONLY : DP
>   !
>   IMPLICIT NONE
>   !
>   !
>   REAL(kind=dp), intent(inout) :: rho(dfftp%nnr,nspin_mag)
>   !
>   IF ( tqr ) THEN
>      CALL addusdens_r(rho,.true.)
>   ELSE
> #if defined(__CUDA)
>      CALL addusdens_g_gpu(rho)
> #else
>      CALL addusdens_g(rho)
> #endif
>   END IF
>   !
>   RETURN
>   !
> END SUBROUTINE addusdens
> 
> 
> 
> 
> The routine "addusdens_r_gpu" will be in a separate file called for
> example "addusdens_gpu.f90" under the GPU directory. This file will be
> compiled iff the proper Makefile.gpu (generated by
> "GPU/install/configure") is used. From a generic non-GPU user
> perspective, any piece of code or routine encapsulated by __CUDA will
> be ignored. Simple but very effective.
> 
> 
> I understand that introducing in several parts of the trunk the macro
> __CUDA may look a dirty move but this will save a lot of my time and
> it will simplify my job. Plus it might stimulate new people to develop
> code for QE-GPU.
> 
> 
> Paolo, Layla… any opinion?
> 
> 
> If I can do that, I expect to commit all the changes by mid of this
> week.
> 
> 
> Cheers,
> Filippo
> 
> 
> --
> Mr. Filippo SPIGA, M.Sc.
> http://filippospiga.me ~ skype: filippo.spiga
> 
> «Nobody will drive us out of Cantor's paradise.» ~ David Hilbert
> 
> 
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers





More information about the developers mailing list