Comments 10
Хм… Всё же не очевидно. А как они собираются указатели поддерживать на всяческих DSP, GPU и прочих устройствах, у которых нет аппаратной защиты? Генерировать Managed код?
Насколько я понял, Renderscript как бы сам определяет — есть ли в системе вычислители с такими возможностями, и тогда запускает соответствующий код на них. Если же нет, то и не запускает, а выбирает CPU (to fall back upon).
Или Вам интересно как они определяют, на каком вычислителе какие есть возможности?
Или Вам интересно как они определяют, на каком вычислителе какие есть возможности?
Определение не представляется проблемой. Мне интересны сценарии работы. Хм… Которые пока всё равно не понятны. Сложно же определить, какие features нужны коду, а какие нет. Вот там в примере функция же описана через указатели. При чём, совершенно явно. И код, который получиться в LLVM виде, будет оперировать этими указателями. И в итоге, система посмотрит на GPU, имеющиеся в системе, и не станет на них запускать код, потому что он 'опасный'.
Или же тут ставка сделана на такую архитектуру, когда у GPU собственная память, не пересекающаяся с основной? Хм… Надо поизучать встраиваемые решения. Но такое ощущение, что подобное распределение — непозволительная роскошь для SoC.
Хотя. ARM уже предложила архитектуру Mali, в которой у GPU есть MMU, который может обеспечить безопасность работы с указателями. Может, и другие производители к такому же решению подтянутся.
Но, IMHO, Google тут как-то странно проектирует. Оно, конечно, будет универсально, но не будет ли так, что оно в большинстве случаев будет откатываться на использование CPU? И как нужно писать, чтобы всё же попасть на GPU для обработки? Вот код в примере — идеален для выполнение на GPU, но как принять решение, что это можно безопасно сделать?
Проанализировать код, сделать вывод о том, что указатели свободно не меняются, и пометить, как безопасное? Что же… Это вполне возможно… А Вы не в курсе, где можно за развитием Renderscript следить? А то, я прочесал обе статьи, вроде, ничего такого не нашёл.
Или же тут ставка сделана на такую архитектуру, когда у GPU собственная память, не пересекающаяся с основной? Хм… Надо поизучать встраиваемые решения. Но такое ощущение, что подобное распределение — непозволительная роскошь для SoC.
Хотя. ARM уже предложила архитектуру Mali, в которой у GPU есть MMU, который может обеспечить безопасность работы с указателями. Может, и другие производители к такому же решению подтянутся.
Но, IMHO, Google тут как-то странно проектирует. Оно, конечно, будет универсально, но не будет ли так, что оно в большинстве случаев будет откатываться на использование CPU? И как нужно писать, чтобы всё же попасть на GPU для обработки? Вот код в примере — идеален для выполнение на GPU, но как принять решение, что это можно безопасно сделать?
Проанализировать код, сделать вывод о том, что указатели свободно не меняются, и пометить, как безопасное? Что же… Это вполне возможно… А Вы не в курсе, где можно за развитием Renderscript следить? А то, я прочесал обе статьи, вроде, ничего такого не нашёл.
Вся информацию, которую я смог вытащить — из блога разработчиков и developer.android.com.
Я все равно не понял, чем им Java для Dalvik не угодил все-таки?
Прочитал половину статьи и не нашел определения Renderscript. Хотя, если «Renderscript — новая фича» считается определением, тогда извиняюсь.
Спасибо за перевод, очень интересно.
Sign up to leave a comment.
Renderscript часть вторая