Блог

Я хотел бы сфотографировать, что происходит с моим экраном, но скриншот этого не передает, но лучшее описание — снег.

Один из моих проектов имеет привычку к случайному сбою на новой итерации, и я всегда предполагал, что это ошибка «Вы используете слишком много памяти, дурак!», Поэтому был рад перезапустить, разобраться с этим и попытаться устранить проблему.

Затем я начал фактически отслеживать назначенную глобальную память; Она оставалась свободной примерно на 70% на протяжении всего выполнения, пока внезапно не умерла на новом malloc.

Чтобы усугубить ситуацию, эти медитации Гуру начали регулярно появляться в моем dmesg; все (что я заметил) с одним и тем же адресом.

 NVRM: Xid (0000:01:00): 13, 0008 00000000 000050c0 00000368 00000000 00000080 
  

Есть какие-нибудь слова от мудрых о том, что, черт возьми, происходит? Я все еще продолжаю расследование проблем с регистром и общей памятью, но хотел бы задать этот вопрос для любых идей, которые есть у кого-либо еще.

Если ни одно из ваших выделений памяти CUDA не завершается сбоем, то ваша проблема не в том, что у вас закончилась память (если бы это было так, это могло быть из-за фрагментации, не обязательно из-за потребления 100% ).

Если вы получаете эффект рождественского дерева, то у вас, вероятно, есть ядро, которое выполняет запись за пределами выделенной памяти. Проверьте индексы пикселей / ячеек массива, к которым вы обращаетесь, и вычисление смещения памяти для их положения в выходных буферах.

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

Пожалуйста, завершите все вызовы CUDA Runtime API с помощью cudaSafeCall() и добавьте cudaCheckError() после всех вызовов ядра. Эти служебные функции представлены в cutil.h . Это должно помочь вам обнаружить любые ошибки CUDA в тот момент, когда они действительно происходят, и их сообщение об ошибке должно помочь вашему расследованию.