Проблема timeout при счете на GPU

[electric_retard]

bin
Никто кроме вас резет устройства сделать не может. Как и стереть то, что вы там разместили.

[bin]

electric_retard
1) Если я правильно понял, то моя программа может застолбить себе память на устройстве вызовом cudaMalloc и циклически обращаться к устройству. Пока эта программа не освободит память на устройстве по cudaFree, никакие посторонние процессы эту память отобрать и изменить не смогут даже вызовом cudaDeviceReset. Т.е. например, если я запущу на исполнение две копии этой программы одновременно, то вторая может вклинить свои вызовы устройства среди вызовов устройства первой, закончиться раньше и вызвать cudaDeviceReset, но и тогда данные в памяти устройства, принадлежащие первой копии, не пострадают. Правильно?

2) Попробовал перекинуть дисплей на встроенное GPU. И ничего не получилось: тот же самый timeout, если в контрольной панели установлен 2ой монитор, а если галочку снимаю, то cuda перестает его видеть, при этом в девайс менеджере устройство указано и работает нормально. Как тут быть?

[electric_retard]

bin
1) Наверное да, проще почитать инструкцию.
2) Ничего не понял. Какой еще второй монитор? Выключаете комп перетыкаете монитор, в биосе указываете, что в приоритете встроенная графика.
Кстати задача поиска минимума в массиве наверняка должна быть решена в каких-нибудь библиотеках для для CUDA, например CUDPP.

[bin]

electric_retard в сообщении #925941 писал(а):

Наверное да, проще почитать инструкцию.

Осторожный ответ. Наверняка, если бы все инструкции всегда отвечали реальности, то подобных тем, как эта, не возникало бы

[electric_retard]

bin
Подозреваю, что они возникают от слабого понимания. Инструкция к функции это не ребус, там все однозначно. Ну и предположение о том, что один процесс рулит памятью другого это конечно тоже перл.

[bin]

electric_retard в сообщении #926227 писал(а):

Подозреваю, что они возникают от слабого понимания. Инструкция к функции это не ребус, там все однозначно.

Я занимаюсь CUDA всего 2 недели на фоне других работ. Вряд ли за 2 недели может возникнуть продвинутое понимание Тем более, что и Вы ответили осторожно Однако, перечтите мой первый пост в этой теме, там наглядный пример того, как однозначные инструкции MSDN работают не всегда.

electric_retard в сообщении #926227 писал(а):

Ну и предположение о том, что один процесс рулит памятью другого это конечно тоже перл.

Примеров можно привести сколько угодно Например, из игровой индустрии:

Цитата:

ArtMoney — компьютерная программа с закрытым исходным кодом, позволяющая редактировать численные параметры в компьютерных играх, для получения бесконечных денег, жизней, патронов и т. п. […] Работа программы осуществляется двумя основными способами: Поиск в памяти процесса игры. Пользователь должен выбрать в специальном окне (аналогичном окну «Диспетчера задач» Windows) запущенный процесс игры. (Википедия)

В нашем же случае речь даже не об ОЗУ компа, а о внешнем устройстве. Если я возьму такое внешнее устройство как TV-рекордер, то могу короткой программой установить на нем таймер записи, после чего, когда программа освободит устройство со сделанными там установками, могу другой программой сбросить эти установки. Это обычная практика и ничего удивительного в этом нет.

[lsoft]

прошу прощения немного за оффтопик, но я тоже сталкивался в описанной проблемой, что ядро останавливается аварийно по таймауту из-за TDR. У меня была задачи сложности $N^3$.
У меня был ноутбук с NVidia видеокартой. Мне помогло только полное отключение TDR выбором TdrLevelOff и перезагрузка. Это было весной. Возможно, Вам стоит снова вернуться к этой теме и поиграться значениями.

Но в любом случае, запускать ядро надолго (на много много секунд) - плохой стиль. Согласен, что надо бить на маленькие порции. Я в итоге так и поступил.

[bin]

lsoft в сообщении #942951 писал(а):

У меня был ноутбук с NVidia видеокартой. Мне помогло только полное отключение TDR выбором TdrLevelOff и перезагрузка. Это было весной. Возможно, Вам стоит снова вернуться к этой теме и поиграться значениями.

Какая у Вас ОС? У меня XP SP3 и сейчас не могу найти MSDN для этой ОС. В этом, похоже, дело: новые ОС используют другие значения (ключи). Уже и с NVidia support переписку имел, но ничего отличного от сказаннного здесь они присоветовать не смогли.

lsoft в сообщении #942951 писал(а):

Но в любом случае, запускать ядро надолго (на много много секунд) - плохой стиль.

Не понял! Я же сказал здесь выше:

bin в сообщении #925096 писал(а):

Хотел бы поставить задачу на всю ночь с выключенным монитором.

И это плохой стиль? Включать обновление экрана каждые несколько секунд, когда он физически выключен на ночь? Если мой подход верен, то реально ценные результаты можно будет получить только на суперкомпах - и там "запускать ядро надолго (на много много секунд) - плохой стиль"?

[electric_retard]

bin
Какой смысл писать в NVIDIA, если TDR — это мулька майкрософта? Ищите ошибку у себя, судя по интернету TDR должен отключаться и в XP.

(Оффтоп)

По поводу бить или не бить на части —

[lsoft]

bin
Спорить насчет стиля не будем, это на то и стиль, что каждый решает для себя. Ведь главное, чтобы результаты были, правда? :) Решать Вам.

Но замечу в скобках (не для дискуссии), что разбитие кернела на много вызовов, каждый из которых работает секунду-другую не должен сильно замедлять просчет. Замедляет просчет прогон данных между хостом и GPU по шине, вот его надо избегать. Ну это Вам уже сказали.

По поводу ОС - у меня Windows 7, тут да. Что там на XP мне неведомо.


В любом случае, я просто высказал свое мнение, принять его во внимание или нет - дело Ваше.

Желаю удачи!

[bin]

electric_retard в сообщении #943477 писал(а):

Какой смысл писать в NVIDIA, если TDR — это мулька майкрософта? Ищите ошибку у себя

Самый прямой смысл. NVIDIA поддерживает свои устройства в том числе и под Wind XP и делает софт для этого. Не случайно, что они пытались ответить, а не отфутболить меня в МС, где, подозреваю, спрашивать про XP уже бесполезно - принципиально не ответят по существу. Что касается ошибок, то в моей программе их нет. Т.к. получаю верные результаты. Версию "по частям" тоже сделал. Тестовую задачу эта версия считала час. Время приемлемое, результат верный. Т.о. дело не в ошибке, а в отсутствии информации по ОС.

lsoft в сообщении #943479 писал(а):

Спорить насчет стиля не будем, это на то и стиль, что каждый решает для себя. Ведь главное, чтобы результаты были, правда?

Понятие стиля программирования - традиционная тема для обсуждения, нпр., в литературе. Почему бы и здесь не обменяться мнениями? Тем более, что в моем случае это очень немаловажный момент. Главное, действительно, чтобы результаты были. Так вот, моим основновным результатом будет публикация алгоритма, возможно, и программной реализации. Вопросы стиля в такой публикации важны.

lsoft в сообщении #943479 писал(а):

Но замечу в скобках (не для дискуссии), что разбитие кернела на много вызовов, каждый из которых работает секунду-другую не должен сильно замедлять просчет.

Нет, реально не замедляет (см. выше). Но реализация становится сложнее и для суперкомпа, как уже говорил, такой подход кажется странным.

lsoft в сообщении #943479 писал(а):

Желаю удачи!

Спасибо!

[lsoft]

bin
Не знаю, к какой области науки будет принадлежать Ваша будущая статья, но, уверяю Вас, в научных статьях реализации алгоритмов обычно совершенно не годны к промышленной эксплуатации :) реализация должна подчеркивать научную новизну статьи. поэтому, я бы не волновался по поводу стиля :)

Ну и насколько я понимаю, тема, заявленная в заголовке, исчерпана достижением полной и безоговорочной победой.
Поздравляю! :)

[bin]

lsoft в сообщении #943669 писал(а):

Не знаю, к какой области науки будет принадлежать Ваша будущая статья

Мат. химия. В двух словах: одной из задач этой области является поиск веществ с заранее заданными свойствами. Нпр., поиск новых лекарственных препаратов. Это очень востребованная человечеством индустрия. В настоящее время стоимость разработки нового лекарства в среднем оценивается в 10 миллионов долларов США. На такие деньги при необходимости много машиннного времени можно купить

lsoft в сообщении #943669 писал(а):

реализации алгоритмов обычно совершенно не годны к промышленной эксплуатации

Не всегда. Нпр., еще в прошлом веке у меня была публикация в J. of Math. Chem. по оптимизации вычисления индекса Хосойи (полное число паросочетаний ребер молекулярного графа $+1$). С тех пор ко мне с вопросами по этой статье несколько раз обращались сотрудники фармацевтических компаний. Из чего вижу, что высказанные мной идеи реализации показались им полезными. Конечно же, речь шла о достаточно общих деталях, а не о фрагментах кода.

lsoft в сообщении #943669 писал(а):

Ну и насколько я понимаю, тема, заявленная в заголовке, исчерпана достижением полной и безоговорочной победой.
Поздравляю!

Спасибо за поздравление. Но, на мой взгляд, праздновать победу еще рано. Мне нужно показать, каких результатов можно достичь даже на скромной аппаратуре. Это будет основанием попробовать мой подход на более высоких вычислительных мощностях, а потом, в случае успеха, и на более высоких. Чем меньше будет проблем переноса, чем проще будет исходная реализация, тем охотнее заинтересовавшиеся специалисты пойдут на такие испытания.

Я вспомнил об индексе Хосойи потому, что в данном случае похожая ситуация: теория давно разработана в классических работах и теоретическая ценность сомнений не вызывает. Вся беда в трудной вычислимости. И в том, и в этом случае я нашел, как радикально сократить перебор. Но в подобных ситуациях для достаточного обоснования практической применимости теоретических оценок обычно оказывается недостаточно, нужны экспериментальные данные по времени расчета модельных систем.