Closed zeratax closed 4 years ago
Das ganze würde ein bisschen Umstrukturierung bedingen.
Das Problem ist, dass man für cuMemAllocHost
einen bereits initialisierten Context benötigt, der wiederum deviceabhängig ist. D.h. man muss bereits vor Erstellung der KernelArgs das Device ausgewählt haben...
(Ich habs fürs JNI auf Branch #49 implementiert)
ist das eig nicht auch der fall für normalen cumemalloc? das mit context regt mich etwas auf, hasse so implizite argumente, weiß garnicht wie man dann einfach zwischen contexten wechselt für e.g. multidevice...
Ich glaube für cumemalloc braucht man auch den Kontext. In der jetzigen JNI-Implementierung wird für jedes in Java übergebenes Argument einfach mit (normalem) malloc
Speicher allokiert, in welchen die Java-Argumente reinkopiert werden, und der dann später aufs Device hochgeladen wird.
Das Problem mit cuMemAllocHost
ist halt, dass es Kontextabhängig und damit scheinbar auch deviceabhängig ist.
Eine Möglichkeit wäre eine init-Methode, die den Kontext initialisiert und am Anfang von jedem Programm aufgerufen werden muss, was aber auch ziemlich unschön wäre.
https://github.com/mgopshtein/cudacpp/blob/master/examples/invoke-rtc.cpp#L17 so wie hier nen context erstellen mit device ist vielleicht sinnvoll?
vielleicht #46 im hinterkopf behalten
https://github.com/mgopshtein/cudacpp/blob/master/examples/invoke-rtc.cpp#L17 so wie hier nen context erstellen mit device ist vielleicht sinnvoll?
vielleicht #46 im hinterkopf behalten
implementiert mit #124
https://devblogs.nvidia.com/how-optimize-data-transfers-cuda-cc/ https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__MEM.html#group__CUDA__MEM_1gdd8311286d2c2691605362c689bc64e0