Галоидные внешние методы
Я использую компиляцию AOT для использования кода Halide без библиотек Halide.
Я вижу в HalideRuntime.h (имеется в источниках), что у меня есть много доступных методов extern в моих .o файлах.
halide_dev_malloc а также halide_dev_free очень интересны. Я уже пользуюсь halide_copy_to_dev без проблем, но я вижу, что моя память была выделена.
Если я хочу сделать простой memcpy между хостом и устройством и использовать вместо него halide_dev_malloc, возможно ли это?
Сгруппировал ли HalideRuntime.h все доступные внешние функции или в объектных файлах много других?
сойка
Решение
HalideRuntime.h предназначен для документирования всех процедур, которые могут вызываться или заменяться клиентами. В среде выполнения есть много других символов, но их следует считать внутренними. Недавно мы переместили эти другие подпрограммы в их собственное пространство имен, чтобы указать, что они являются внутренними.
Среда выполнения для серверных бэкэндов все еще находится в стадии разработки, и будет улучшенный дизайн, предназначенный для обеспечения большей гибкости и обеспечения возможности выполнения кода большего объема при одновременной общей работе с несколькими бэкэндами. В настоящее время halide_dev_malloc будет выделять дескриптор устройства для любого бэкэнда устройства, выбранного через Target во время компиляции Halide. Однако этот дескриптор специфичен для бэкэнда, и поэтому для того, чтобы что-то с ним сделать, вы должны знать, какой бэкэнд используется и как этот бэкэнд взаимодействовал с API устройства. Например. чтобы использовать дескриптор с memcpy, вам нужно знать, что серверная часть устройства поддерживает некую унифицированную архитектуру памяти («унифицированное виртуальное адресное пространство» в терминологии CUDA), и память устройства была выделена с помощью правильных вызовов API для создания памяти буфер, к которому можно получить доступ как с устройства, так и с процессора с одним и тем же указателем и т. д. В зависимости от того, какой бэкэнд вы используете и на какой платформе вы работаете, это может сработать или не сработать в настоящее время. (Унифицированный дизайн памяти по большей части довольно недавний. Мы не приложили много усилий для их поддержки.)
Для CUDA / PTX halide_dev_malloc вызывает cuMemAlloc, и я думаю, что он может быть в Унифицированном виртуальном адресном пространстве на многих системах по умолчанию, но я не уверен.
Другие решения
Да, вы можете использовать halide_dev_malloc и копировать вещи самостоятельно. Увидеть https://github.com/halide/Halide/blob/master/src/runtime/cuda.cpp строка 466 для того, что фактически делает halide_copy_to_dev.
Сначала он делает halide_dev_malloc, а затем использует cuMemcpyHtoD от cuda. Там есть куча дополнительной логики, если буфер не плотный в памяти, но большую часть времени он превращается в один cuMemcpyHtoD.
Я считаю, что HalideRuntime.h содержит все полезные функции extern. Есть несколько других внутренних, таких как halide_create_cuda_context, которые могут быть интересны. Чтобы увидеть их все, поищите функции, помеченные как WEAK, которые начинаются с имени halide_ в этой папке: https://github.com/halide/Halide/tree/master/src/runtime
Или вы можете запустить nm в сгенерированном галогенидом объектном файле и увидеть все символы, которые начинаются с halide_.