Недавно я начал расширять проект, зависящий от повышения, для использования CUDA для его самого внутреннего цикла. Я подумал, что стоит почитать здесь о каком-то странном поведении, которое я видел. Простое включение некоторых заголовков ускорителей вызовет мой первый вызов cuda для генерации большого количества ядер.Чрезмерное ядро запускается при создании контекста
Если компилировать и отлаживать следующий код:. simplestCase.cu
#include <boost/thread.hpp>
int main(int argc, char **argv){
int *myInt;
cudaMalloc(&myInt, sizeof(int));
return 0;
}
Я получаю следующие строки отладки сообщений при выполнении cudaMalloc (такое же поведение, если я бегу ядро я определил кажется, все, что триггеры создание контекста вызовет это).
[Launch of CUDA Kernel 0 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 1 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 2 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 3 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 4 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 5 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 6 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 7 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
[Launch of CUDA Kernel 8 (memset32_post<<<(1,1,1),(64,1,1)>>>) on Device 0]
До сих пор я определил два заголовки, которые вызывают проблемы: повышение/thread.hpp повышение/mpi.hpp
Вот немного информации, которая может оказаться полезной в репликации проблемы:
- IDE: Nsight Eclipse, издание
- ОС: Ubuntu 12.04 x64
- GPU: GeForce GTX 580 (я считаю, мой GeForce GT 520 используется моей ОС)
- подталкивание Lib: 1,52
- кота/Proc/водитель/NVIDIA/версия:
- NVRM вер Сьон: Модуль NVIDIA UNIX ядро x86_64 310,32 пн 14 января 14:41:13 PST 2013
- версия GCC: GCC версии 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
настройки проекта :
- Свойства-> Build-> CUDA-> DeviceLinkerMode = Раздельная компиляция
- Свойства-> Build-> CUDA-> GenerateGPUCode = 2,0
- Свойства-> Build-> Настройки-> ToolSet tings-> NVCCLinker-> Библиотеки = boost_system
- свойства-> Name = simplest_case_example
Я думаю, что это все.
Edit:
Благодарим вас за мое внимание на то, что я не задал вопрос. Я знал, что забыл что-то критическое. Мой вопрос таков:
Мне кажется странным, что очень специфический относится к их генерации вызовов периферийного ядра, в частности, поскольку я не использую их, и я не вижу, как они могут повлиять на мое взаимодействие с CUDA , Должен ли cuda запускать это много дополнительных ядер для кода, который я даже не использую? Я вижу более 100 ядер, запущенных в проекте, над которым я сейчас работаю, когда в моем проекте есть единственный код CUDA, который у меня есть, - это один cudaMalloc в точке входа программы.
Edit2:
происходит Также на Tesla K20 (Kepler архитектуры карты, в то время как я думаю, что GTX 580 является Fermi).
Edit3:
Обновленный драйвер CUDA до версии 319.23. Никаких изменений в поведении, о котором я говорил выше, но это устранило проблемы отладчика, которые у меня были в более крупных программах.
Вы не задали вопрос. Хотя вы можете подумать, что вопрос должен быть очевиден, по-прежнему хорошая практика сделать это очевидным. Я думаю, что вы наблюдаете, что время выполнения CUDA может по своему усмотрению вызвать множество неочевидных операций для выполнения определенных задач, таких как запуск «лишних» ядер «под капотом». Я предполагаю, что вы спрашиваете, почему включение конкретного заголовка boost приводит к тому, что среда выполнения выполняет эти конкретные вызовы ядра? Вы использовали слово «проблема» в своем описании, но я не уверен, что здесь есть настоящая «проблема». –
Я не могу воспроизвести это на любой платформе, к которой у меня есть доступ ... – talonmies
Интересно. Мне удалось воспроизвести это на компьютере сотрудника. Я не знаю никаких подробностей, которые я пропустил. Хотя я считаю, что наши компьютеры состоят из одного и того же оборудования, я считаю, что в этом случае графическая карта должна быть единственным возможным нарушителем. – longbowrocks