Comments 10
Хм… Всё же не очевидно. А как они собираются указатели поддерживать на всяческих DSP, GPU и прочих устройствах, у которых нет аппаратной защиты? Генерировать Managed код?
0
Насколько я понял, Renderscript как бы сам определяет — есть ли в системе вычислители с такими возможностями, и тогда запускает соответствующий код на них. Если же нет, то и не запускает, а выбирает CPU (to fall back upon).
Или Вам интересно как они определяют, на каком вычислителе какие есть возможности?
Или Вам интересно как они определяют, на каком вычислителе какие есть возможности?
0
Определение не представляется проблемой. Мне интересны сценарии работы. Хм… Которые пока всё равно не понятны. Сложно же определить, какие 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 следить? А то, я прочесал обе статьи, вроде, ничего такого не нашёл.
0
Вся информацию, которую я смог вытащить — из блога разработчиков и developer.android.com.
0
Я все равно не понял, чем им Java для Dalvik не угодил все-таки?
0
Прочитал половину статьи и не нашел определения Renderscript. Хотя, если «Renderscript — новая фича» считается определением, тогда извиняюсь.
0
Спасибо за перевод, очень интересно.
0
Sign up to leave a comment.
Renderscript часть вторая