Почему не может преобразовать TCHAR* для обугливания*

Заполняемость может немного ввести в заблуждение, и 100% заполняемость не должна быть вашей основной целью. Если вы можете получить полностью объединенный доступ к глобальной памяти, то на высоком GPU 50% заполняемости будет достаточно, чтобы скрыть задержку к глобальной памяти (для плавающих, даже ниже для двойных). Ознакомьтесь с презентацией Advanced CUDA C от GTC в прошлом году для получения дополнительной информации по этой теме.

В вашем случае вы должны измерить производительность как с, так и без установки maxrregcount 16. Задержка локальной памяти должна быть скрыта в результате наличия достаточного количества потоков, при условии, что вы не имеете произвольного доступа к локальным массивам (что приведет к некоалесцированному доступу).

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

Вероятно, потому, что TCHAR определен как символ в одном из ваших проектов, но не в VS2010, где он, вероятно, wchar_t.

Если проект определяет UNICODE/_UNICODE, что совпадает с определением в параметрах настройки проекта построения в Юникоде, TCHAR будут wchar_t.

Вам, в основном, нужно решить, использовать Юникод или нет, и если да, вам нужно изменить регулярные вызовы strncpy и др. на широкоугольные эквиваленты или использовать t-варианты, которые изменяются так же, как и TCHAR. Просмотрите справку по strncpy или другим функциям, чтобы увидеть, как называются широкие или t-варианты.

Можно также просмотреть MSDN для таких вызовов, как strcpy , где можно увидеть, что широкострочная версия называется wcscpy, а t - _tcscpy. Я бы рекомендовал вам придерживаться t-версий, если вы собираетесь использовать код в различных проектах, которые либо используют Юникод, либо нет, или принять осознанное решение, какой из них вы собираетесь использовать, а затем придерживаться этого. Что лучше зависит от вашего сценария, я бы сказал, и может ссылаться на некоторые «религиозные» мнения...

Является ли ваш проект проектом Юникод? Если это так, я полагаю, что TCHAR будет эквивалентен wchar _ t , а не char , что делает попытки преобразования недействительными. Смотрите здесь для получения дополнительной информации.

Возможно, потому что TCHAR определен как char в одном из ваших проектов, но не в проекте VS2010, где он, вероятно, wchar_t.

Если ваш проект определяет UNICODE/_UNICODE, что то же самое, что указать в настройках проекта, что это сборка Unicode, то TCHAR будут wchar_t.

По сути, вам нужно решить, использовать Unicode или нет, и если да, то вам нужно изменить обычные вызовы strncpy и др. на широкосимвольные эквиваленты или использовать t-варианты, которые изменяются так же, как и TCHAR. Посмотрите в справке к strncpy или другим функциям, чтобы узнать, как называются широкие или t-варианты.

Вы также можете посмотреть в MSDN такие вызовы, как strcpy, где вы увидите, что широкозарядный вариант называется wcscpy, а t-вариант - _tcscpy. Я бы рекомендовал вам придерживаться t-версии, если вы собираетесь использовать код в различных проектах, которые либо используют UNICODE, либо нет, или принять взвешенное решение, какую из них вы собираетесь использовать, а затем придерживаться ее. Что лучше, зависит от вашего сценария, я бы сказал, и может вызвать некоторые "религиозные" мнения...