Прямой ByteBuffer и безопасность потока

Question

Я изучаю OpenGL ES, и я вижу много примеров, которые выделяют прямой ByteBuffer, а затем переносят его в FloatBuffer и записывают в него данные вершин в Renderer#onDrawFrame(...).

Почему этот поточно-безопасный? (Или это?) Является ли это характеристикой прямого ByteBuffer или что-то сделанное вызывающим абонентом onDrawFrame(...), что гарантирует, что записи в буфер будут видны в шейдерных программах?

Редактировать: Мое понимание JMM заключается в том, что именно это происходит, поскольку Java предоставляет некоторую сложность современного оборудования. Я предполагаю, что те же проблемы видимости памяти, которые существуют между потоками Java, также существуют между потоком Java и не-Java-программой, обращающейся к одной и той же памяти. Я также предполагаю, что шейдеры запускаются на графическом процессоре, а не в потоке рендеринга Java.

Если все вышесказанное верно, то там должен быть барьер памяти, чтобы гарантировать, что записи в потоке рендеринга видны шейдеру. Мой вопрос сводится к: где этот барьер памяти? Является ли это ответственностью за его создание?

Answer 1

В идеале, все выделения и заселения происходят в потоке рендеринга, поэтому нет проблемы безопасности потока. В этом отношении нет ничего особенного в прямых ByteBuffers. Если приложение пишет из одного потока и читает от другого без синхронизации, возможно, существует условие гонки.

Если водитель GLES решает использовать несколько потоков, он отвечает за выдачу соответствующих барьеров памяти.

cf. Android SMP Primer

Редактировать (в соответствии редактировать в вопросе): ответственность приложения является, чтобы получить доступ к контексту EGL из одного потока в то время (который я звоню в «рендерер нить»). Если вы отправляете данные в GLES из буфера с расчетом данных, у вас будет плохое время. Пока поток рендеринга имеет согласованное представление, все, что вы делаете с GLES в этом потоке, будет работать должным образом.

Если реализация GLES выполняется для выполнения шейдеров на другом потоке процессора или в графическом процессоре, то ответственность за проблемы согласованности с памятью лежит на драйвере GLES.