Войти
ПрограммированиеФорумГрафика

Framebuffer на встроенном GPU (AMD, Intel, ARM)

#0
14:13, 10 июля 2019

Давеча смотрел ролик 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?"


#1
(Правка: 14:45) 14:43, 10 июля 2019

Deamon
> Похоже у N64 framebuffer существовал в памяти, к которой CPU имел
> непосредственный доступ

https://gamedev.ru/flame/forum/?id=231027&page=3#m31 (там вся тема про подобное, в начале оглавление по системам):

Интересно, что в Nintendo 64 центральную роль в системе играет видеочип - причём сам он по себе является многокомпонентной величиной.
Для того чтобы сделать унифицированную RAM и не разделять банки графической и основной ОЗУ в итоге было сделано так, что ЦП обращался к RAM через видеочип.
И вообще все пути-дорожки сходились именно на видеочипе - как общение с периферией, так и общение хоть с памятью хоть с картриджем как видео, как геймпада, как и звука - всё шло через видеочип.
Он получается становился каким то южным мостом в одном флаконе и точкой, где встречались все компоненты системы.
#2
16:27, 10 июля 2019

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

Ты точно гуглил?

#3
17:38, 10 июля 2019

=A=L=X=
Интересно... Т.е. у N64 все сходилось в видеочипе... Спасибо, дает большее понимание что там происходило и почему. Обязательно прочитаю все тему, чтобы сложить 2+2. Как говорится I will need to wrap my head around that
nonamezerox
Ну это все равно немного не то. Чтобы из PBO прочитать данные нужно все равно делать вызов glReadPixels и все равно происходит копирование из Framebuffer'а в PBO. Т.е. прямого доступа к памяти опять таки нет.

И не смотря на N64, где возможно его и не было изначально - странно что прямого доступа нет в OpenGL.

Что он может быть в Vulkan - я подозревал, но не проверял.

#4
17:54, 10 июля 2019

Объединённое ОЗУ для ЦП и ГПУ - решение прежде всего медленное.
Поэтому, как мне кажется, его не стараются закреплять в API, чтобы не способствовать пенальти по скорости там где эта скорость реально блещет.
В конце концов консоли тоже чаще всего используют концепцию отдельного VRAM к которому ЦП имеет очень ограниченный и неудобный доступ.
Поэтому смысла лазить во фреймбуфер даже если шины и схемы соединения это позволяют на ПК - нет. Ну т.е. драйвер конечно лазит, но пользовательскому коду там делать нечего.
Лучшим случаем сейчас считается вариант когда нарисовав первичную какую то картинку внутри ГПУ мы даём ГПУ команду взять её снова в качестве текстуры, допустим, и не передавая к ЦПУ дальше с ней работать как хочется - этот вариант предпочтительнее.

#5
15:47, 11 июля 2019

Deamon
> Быстрый гуглеж не показал наличие каких-то специальных расширений, которые
> позволяли бы прямой доступ к framebuffer'у с GPU.
Для IntelHD вот:
https://www.khronos.org/registry/OpenGL/extensions/INTEL/INTEL_map_texture.txt

#6
16:46, 11 июля 2019


Deamon
> И не смотря на N64, где возможно его и не было изначально - странно что прямого
> доступа нет в OpenGL.

Ты для начала попробуй понять, НАФИГА тебе нужен этот доступ к фрейм-буферу.

Потом осознай, что на TBDR GPU (т.е. на всех мобилках и хандхелдах начиная с PS Vita) фреймбуффера в-принципе нет и и желание "прочитать пиксель" приведёт к невдолбических затратам памяти и времени.

#7
12:39, 12 июля 2019

Apfel1994
О, сенкс. Один из вендеров таки решил побыть не таким как все.

Ghost Dragon
>Ты для начала попробуй понять, НАФИГА тебе нужен этот доступ к фрейм-буферу.
Академ. интерес :).

#8
14:00, 12 июля 2019

Шаринг памяти для intel OpenCL
https://software.intel.com/en-us/articles/getting-the-most-from-o… ssor-graphics

ПрограммированиеФорумГрафика