- =A=L=X=
- Постоялец
Давеча смотрел ролик https://youtu.be/5fWQ6JCNrH4?t=232
На 3:52 раскрывается тема с эмуляцией Framebuffer'а. Похоже у N64 framebuffer существовал в памяти, к которой CPU имел непосредственный доступ, и разрабы под эту приставку прибегали к изврату, когда часть рисуется средствами GPU, а часть обрабатывается CPU.
После непродолжительного гугления, были даже найдены упоминания, что некоторые товарищи даже портировали эмулятор на CUDA\OpenCL только для того, чтобы иметь прямой доступ к Framebuffer'у
И тут у меня появляется вопрос, в современном мире железа есть как минимум 3 товарища, которые по идее должны обладать таким же прямым доступом к GPU: APU от ARM, Core i7 от Intel и SoC'и с ARM'ом и Mali/Ardeno. Быстрый гуглеж не показал наличие каких-то специальных расширений, которые позволяли бы прямой доступ к framebuffer'у с GPU.
Отсюда вопрос, в чем подвох? Почему такая функциональность отсутствует?
Пока писал пост вспомнил про многопоточность, когда GPU отстает от CPU на кадр и более. Но "Is it a case for embedded GPUs too?"
Deamon
> Похоже у N64 framebuffer существовал в памяти, к которой CPU имел
> непосредственный доступ
https://gamedev.ru/flame/forum/?id=231027&page=3#m31 (там вся тема про подобное, в начале оглавление по системам):
Интересно, что в Nintendo 64 центральную роль в системе играет видеочип - причём сам он по себе является многокомпонентной величиной.
Для того чтобы сделать унифицированную RAM и не разделять банки графической и основной ОЗУ в итоге было сделано так, что ЦП обращался к RAM через видеочип.
И вообще все пути-дорожки сходились именно на видеочипе - как общение с периферией, так и общение хоть с памятью хоть с картриджем как видео, как геймпада, как и звука - всё шло через видеочип.
Он получается становился каким то южным мостом в одном флаконе и точкой, где встречались все компоненты системы.
Deamon
> Быстрый гуглеж не показал наличие каких-то специальных расширений, которые
> позволяли бы прямой доступ к framebuffer'у с GPU.
Эммм, https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glMapBuffer.xml
https://docs.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d11… cecontext-map
Про вулкан и DX12 уже молчу.
https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/… apMemory.html
Ты точно гуглил?
=A=L=X=
Интересно... Т.е. у N64 все сходилось в видеочипе... Спасибо, дает большее понимание что там происходило и почему. Обязательно прочитаю все тему, чтобы сложить 2+2. Как говорится I will need to wrap my head around that
nonamezerox
Ну это все равно немного не то. Чтобы из PBO прочитать данные нужно все равно делать вызов glReadPixels и все равно происходит копирование из Framebuffer'а в PBO. Т.е. прямого доступа к памяти опять таки нет.
И не смотря на N64, где возможно его и не было изначально - странно что прямого доступа нет в OpenGL.
Что он может быть в Vulkan - я подозревал, но не проверял.
Объединённое ОЗУ для ЦП и ГПУ - решение прежде всего медленное.
Поэтому, как мне кажется, его не стараются закреплять в API, чтобы не способствовать пенальти по скорости там где эта скорость реально блещет.
В конце концов консоли тоже чаще всего используют концепцию отдельного VRAM к которому ЦП имеет очень ограниченный и неудобный доступ.
Поэтому смысла лазить во фреймбуфер даже если шины и схемы соединения это позволяют на ПК - нет. Ну т.е. драйвер конечно лазит, но пользовательскому коду там делать нечего.
Лучшим случаем сейчас считается вариант когда нарисовав первичную какую то картинку внутри ГПУ мы даём ГПУ команду взять её снова в качестве текстуры, допустим, и не передавая к ЦПУ дальше с ней работать как хочется - этот вариант предпочтительнее.
Deamon
> Быстрый гуглеж не показал наличие каких-то специальных расширений, которые
> позволяли бы прямой доступ к framebuffer'у с GPU.
Для IntelHD вот:
https://www.khronos.org/registry/OpenGL/extensions/INTEL/INTEL_map_texture.txt
Deamon
> И не смотря на N64, где возможно его и не было изначально - странно что прямого
> доступа нет в OpenGL.
Ты для начала попробуй понять, НАФИГА тебе нужен этот доступ к фрейм-буферу.
Потом осознай, что на TBDR GPU (т.е. на всех мобилках и хандхелдах начиная с PS Vita) фреймбуффера в-принципе нет и и желание "прочитать пиксель" приведёт к невдолбических затратам памяти и времени.
Apfel1994
О, сенкс. Один из вендеров таки решил побыть не таким как все.
Ghost Dragon
>Ты для начала попробуй понять, НАФИГА тебе нужен этот доступ к фрейм-буферу.
Академ. интерес :).
Шаринг памяти для intel OpenCL
https://software.intel.com/en-us/articles/getting-the-most-from-o… ssor-graphics
Тема в архиве.