Насколько плохо обновлять UniformBuffer во время его использования?

#vulkan

#vulkan

Вопрос:

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

  • Синхронизация (Забор …), чтобы убедиться, что вы не записываете в буфер во время его использования.
  • Запишите в другой буфер / смещение, обновите набор описаний и перезапишите CommandBuffer.

Но, допустим, я не синхронизирую, а просто помещаю некоторые свежие данные в тот же буфер в том же месте (смещение):

Насколько это было бы плохо?

Примечание: Этот вопрос предназначен только для лучшего понимания Vulkan, но определенно не для распространения плохих практик.

Комментарии:

1. Я не уверен, как это улучшает понимание Vulkan. Спецификация говорит вам не делать этого. Вы знаете, что этого делать нельзя. Итак … что бы вы ни узнали из этого, вы никогда не сможете использовать , если собираетесь правильно использовать Vulkan.

2. @NicolBolas Может быть, все это очевидно для вас, но не для меня. Я знал, что это плохая практика, но я не знал почему . Я не эксперт в рендеринге, и приобретать такие знания долго. Я попытался выполнить поиск в спецификации, но не нашел его. Поэтому я, хотя и прошу людей, которые действительно знают (здесь, в stack overflow), может быть хорошей идеей, лучше понять ( возможно ), как работает память. И более того, я подумал, что этот вопрос может быть задан некоторыми другими новичками в рендеринге. Но поскольку я теряю репутацию (и право комментировать везде, кстати), я подумываю об удалении этого вопроса.

3. » Я знал, что это плохая практика, я не знал почему». Но вы знаете, почему это плохая практика. Так сказано в стандарте. Вот и все «почему», которые вам нужны. Дело не в том, чтобы быть очевидным или неочевидным; если что-то говорит «не делай X», вам действительно не нужно исследовать глубже. И если вы хотите узнать больше о том, что происходит за кулисами, вы задаете неправильный вопрос. Вы спросили о том, что произойдет, если вы это сделаете; это ничего не говорит вам о том, почему это происходит, и это то, что вы действительно хотите знать.

4. Нет, я не знал почему. Я только что видел несколько случайных руководств, в которых говорилось «делай так», но я не нашел ссылку в стандарте. И когда я пытаюсь в своем приложении, оно просто работает нормально. Я понимаю, что для вас это глупый вопрос, возможно, плохо заданный, но я имею право на любопытство.

Ответ №1:

Это неопределенное поведение:

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

Оставляя в стороне любые «назальные демоны», связанные с неопределенным поведением, на практике, я думаю, есть большая вероятность, что в вашем рендеринге будут редкие сбои, когда вам не повезет настолько, что запись и чтение конфликтуют. Мне кажется маловероятным, что вы можете вызвать сбой, но вы никогда не могли быть уверены в этом на 100%.

Комментарии:

1. Осторожно; «неопределенные результаты» — это не то же самое, что «неопределенное поведение». Моя интерпретация приведенной выше цитаты такова: вы не знаете, какое значение будет записано, и какое значение будет прочитано (если что-либо также обращается к тому же асинхронно). Но это должна быть исправляемая ошибка (при условии отсутствия ошибок в драйвере).