Время, затраченное на выделение битмапа

Я уже некоторое время экспериментировал с Renderscript. Я написал небольшие тестовые ядра для гистограммы, фильтрации и т. Д. На изображениях из локального хранилища, чтобы проверить их функциональность. Если я получаю трассировку для этой последовательности операций - при размере изображения 8MP - на сегодняшний день наибольшее время занимает звонок Allocation.createFromBitmap. Для этого вызова я вижу примерно 22 мс против ~ 1 мс для запуска моего ядра.Время, затраченное на выделение битмапа

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

Спасибо,

Акшай

источник

2014-02-13 Akshay Panday

1ms кажется быстрым для ядра 8mp. Если вы добавите финиш сразу после вызова ядра и перед вашим временным кодом, изменится ли время? –

О, ничего себе. Это изменило все. Теперь мое общее время увеличилось на секунду или около того. В traceview RenderScript.finish занимает 1292 мс, хотя время для моих ядер как таковое не изменилось. Итак, если бы мне пришлось написать последовательность последовательных операций, Gray Scale -> Threshold -> Gaussian Downsample, то между этими ядрами мне нужно явно называть финиш между ними? И тогда имеет смысл написать две несвязанные операции в последовательности, чтобы асинхронное поведение не имело значения? –

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

Основным решением этой проблемы является "USAGE_SHARED". Какую версию API вы тестируете?

Новая (API 18+) реализация RS создаст распределения с этим флагом по умолчанию. Вы все равно должны будете называть copyTo/From, но они могут (должны) превращаться в NOP. Драйверы HW по-прежнему улучшают поддержку этого флага использования и в некоторых случаях возвращаются к фактической копии. Со временем вы должны увидеть, что накладные расходы на копии исчезают на более новых устройствах.

источник

2014-02-13 22:42:47

Я использую 19 по большей части, 18 при тестировании с GS4. Итак, в идеальном случае не должно быть накладных расходов, поскольку память распределяется между java и native? –

Да, похоже, что драйвер на этом устройстве все еще делает копии за кулисами. Вы можете заставить его обратиться к нашему справочному драйверу с помощью «adb shell setprop debug.rs.default-CPU-driver 1» и посмотреть, не пропадут ли служебные данные. –

Попробуй это. Но, как вы сказали выше, возможно, время копирования (для copyTo) поглощает ожидание завершения ядра, и именно это я вижу здесь. –

Время, затраченное на выделение битмапа

ответ

Смежные вопросы