Мне вот интересно. Предположим я решил тупо с нуля написать свою ОС.
При этом хочу на максимальном количестве совместимого СОВРЕМЕННОГО оборудования тупо при загрузке выставить максимально возможное разрешение, максимальную глубину цвета, и тупо нарисовать красивый Hello world рассматривая видеоадаптер (наверное даже несколько видеоадаптеров, ибо сейчас есть и интегрированное видел), и оперировать со всем тупо записывая в экранную область памяти.
Какой стандарт наиболее актуальный? Неужто блин VESA BIOS Extensions? В котором даже Full HD ни фига нет и который заточен под 4 на 3 размер экрана?
У меня такое впечатление что сейчас блин нормального стандарта то и нет! Либо жуткое легаси 30 летней давности, либо пиши драйвер под какую ОС реализующий API OpenGL DirectX или Vulkan.
Здравствуйте, Великий Реверс, Вы писали:
ВР>если бы был видео стандарт ВР>не было бы зоопарка видео драйверов со своими апи ВР>а так в целом UEFI некоторые улучшенные видео доступы дают
Ну вот как минимум какой то стандарт явно есть. Только вот не остался ли он до сих пор как SVGA с расчетом на 4 на 3 дисплеи и максимальным разрешением 1280 × 1024 с 24 битами на пиксель? И насколько я понимаю, UEFI то этим стандартом и пользуется чтоб была базовая графика и поддержка мыши и клавиатуры.
И соответственно что, до сих пор нет стандарта, который поддерживает допустим FullHD? Ибо UEFI такое разрешение не поддерживает ни черта, при этом какое то более менее приемлемый видеорежим там есть.
Здравствуйте, elmal, Вы писали:
E>Какой стандарт наиболее актуальный? Неужто блин VESA BIOS Extensions? В котором даже Full HD ни фига нет и который заточен под 4 на 3 размер экрана?
Всё это зависит от карточки. VESA декларирует некоторый минимальный набор режимов. Дальше на ходу ты можешь проитерировать полный набор и подобрать лучший.
Но тебе ещё надо убедиться, что дисплей адекватно вытянет этот режим. Будешь писать запросчик свойств дисплея?
E>У меня такое впечатление что сейчас блин нормального стандарта то и нет! Либо жуткое легаси 30 летней давности, либо пиши драйвер под какую ОС реализующий API OpenGL DirectX или Vulkan.
Ну вот framebuffer подсистема в Linux решает главную задачу — обеспечить ясность общения до момента, когда включатся собственно "тяжёлые" драйвера.
Здравствуйте, netch80, Вы писали:
N>Всё это зависит от карточки. VESA декларирует некоторый минимальный набор режимов. Дальше на ходу ты можешь проитерировать полный набор и подобрать лучший.
То есть до сих пор VESA? Это вроде как поддерживают вообще все карточки.
N>Но тебе ещё надо убедиться, что дисплей адекватно вытянет этот режим. Будешь писать запросчик свойств дисплея?
Ну на деле этот код пишется ровно один раз и уже давно должен бы быть написан по идее. Но вообще, современные дисплеи вроде относительно адекватно вытягивают любой режим. Full HD хорошо показывают практически все дисплеи, за исключением разве что часов.
раньше биосы давали прерывания и через них был VESA
сейчас акцент сместился с биоса назвав их легаси биос
в сторону UEFI
по сути UEFI это тот же доступ ко всем VESA режимам
только с другой стороны
все их комплектует производитель
поскольку нельзя обеспечить доступ к линейному буферу видео памяти
без знания спецификации видео карты
то список доступных разрешений ограничен
хотя помниться там както все хитро последние годы было
когда сам биос на материнке мог получить доступ к биосу(точке доступа) на видухе
и уже сама видуха давала эти все функции VESA или UEFI GOP
но все равно
сами видухи не особо заботились что бы передать как можно больше разрешений для базового использования
поскольку это нафиг не нужно
для 3d итд не используется линейный видео буффер
что там есть за списки режимов сейчас я хз
вот на одном форуме попалось
Здравствуйте, Великий Реверс, Вы писали:
ВР>но все равно ВР>сами видухи не особо заботились что бы передать как можно больше разрешений для базового использования ВР>поскольку это нафиг не нужно ВР>для 3d итд не используется линейный видео буффер
Это то понятно, 3d для базового использования то нафик не нужно, а вот линейный видеобуффер бы не помешал.
ВР>[0] 3840x2160 BPP 32 MEM_MODES 1
Очень любопытно, что это единственный 16 на 9 режим в списке.
Меня несколько печалит, что сейчас я вообще ни хрена не врубаюсь как это все работает на низком уровне. Современные ОС конечно ни фига не дают контроля над оборудованием уже десятилетиями. Но вот например если я поставлю FreeDOS — контроль по идее над оборудованием будет. И очень интересно как мне на ассемблере переключиться в графический режим допустим даже 4k и попробовать что нидь нарисовать путем тупо посылки байтиков в линейную видеопамять.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Великий Реверс, Вы писали:
ВР>>но все равно ВР>>сами видухи не особо заботились что бы передать как можно больше разрешений для базового использования ВР>>поскольку это нафиг не нужно ВР>>для 3d итд не используется линейный видео буффер E>Это то понятно, 3d для базового использования то нафик не нужно, а вот линейный видеобуффер бы не помешал.
производители исходят из того что большие разрешения с линейной памятью тоже нафиг не нужны
никто под уровня ос это писать не будет
потому что для ос мало линейной памяти
даже базовая графика будет тормозить
в коде reactos можете поколупаться
хз что там сейчас в дровами фрембуфера для видео
или в дровах DDK/WDK от MS
там может базовые дрова для фрейм буфера есть
ВР>>[0] 3840x2160 BPP 32 MEM_MODES 1 E>Очень любопытно, что это единственный 16 на 9 режим в списке.
E>Меня несколько печалит, что сейчас я вообще ни хрена не врубаюсь как это все работает на низком уровне. Современные ОС конечно ни фига не дают контроля над оборудованием уже десятилетиями. Но вот например если я поставлю FreeDOS — контроль по идее над оборудованием будет. И очень интересно как мне на ассемблере переключиться в графический режим допустим даже 4k и попробовать что нидь нарисовать путем тупо посылки байтиков в линейную видеопамять.
ну так примеров дофига и больше
или через прерывания int если это легаси биос
или через UEFI GOP(если биос UEFI) примеры сегодня находил на хабре, но не стал постить уже сюда
Здравствуйте, elmal, Вы писали:
N>>Всё это зависит от карточки. VESA декларирует некоторый минимальный набор режимов. Дальше на ходу ты можешь проитерировать полный набор и подобрать лучший. E>То есть до сих пор VESA? Это вроде как поддерживают вообще все карточки.
Ты путаешь стандартный набор режимов VESA и интерфейс установки режимов.
В интерфейсе есть возможность проитерировать поддерживаемое и выставить наиболее подходящий. https://wiki.osdev.org/VESA_Video_Modes
INT 0x10, AX=0x4F00
Get Controller Info. This is the one that returns the array of all supported video modes.
INT 0x10, AX=0x4F01, CX=mode, ES:DI=256 byte buffer
Get Mode Info. Call this for each member of the mode array to find out the details of that mode. The 256 byte buffer will be filled by the mode info block.
N>>Но тебе ещё надо убедиться, что дисплей адекватно вытянет этот режим. Будешь писать запросчик свойств дисплея? E>Ну на деле этот код пишется ровно один раз и уже давно должен бы быть написан по идее.
Я тоже так думаю. Искать, однако, облом.
E> Но вообще, современные дисплеи вроде относительно адекватно вытягивают любой режим. Full HD хорошо показывают практически все дисплеи, за исключением разве что часов.
У меня до сих пор есть живой лаптоп с 1366x768. На нём точно будет "мыло", если пытаться показать 1920x1080. Если вообще разрешит включить.
Здравствуйте, elmal, Вы писали:
E>Мне вот интересно. Предположим я решил тупо с нуля написать свою ОС.
E>При этом хочу на максимальном количестве совместимого СОВРЕМЕННОГО оборудования тупо при загрузке выставить максимально возможное разрешение, максимальную глубину цвета, и тупо нарисовать красивый Hello world рассматривая видеоадаптер (наверное даже несколько видеоадаптеров, ибо сейчас есть и интегрированное видел), и оперировать со всем тупо записывая в экранную область памяти.
Тупо не получится, тупо можно только по com порту или по сети
Для современного железа придётся иметь набор драйверов и пользоваться ими. Лень писать самому есть linux.
И да под некоторое железо дров просто нет. Особенно в этом вопросе выделеяется intel Он с чистой совестью выпускает продукт без дров и потом end of life, а дров нет и описания нет, зато железо есть.
E>Какой стандарт наиболее актуальный?
display port
Если софтовый то BIOS,VESA,UEFI
все трое ущербы чуть более чем полность, но uefi подволяет добавлят дрова самому, но смысла опять же нет. Всё выполнено по остаточному принципу (что бы хоть что-то показывало).
Так что грузишь линукс и через /dev/fb0 фигачишь или запускаешь xserver и через него.
Здравствуйте, kov_serg, Вы писали:
_>Так что грузишь линукс и через /dev/fb0 фигачишь или запускаешь xserver и через него.
Так это один фиг через драйвер работает, при отсутствии драйверов через тот же VESA. Это тупо абстракция над драйвером, при отсутствии нормального драйвера будет драйвер для VESA режимов.
Насколько я понимаю, /dev/fb0 держат иксы, соответственно фиг я туда что запишу напрямую — правильно? А вот смогу ли прочитать оттуда — это уже интереснее, но скорее всего тоже не смогу.
Но вообще, я сейчас немного по поводу VESA погуглил, и в теории там вроде есть возможность вообще любое разрешение поддерживать, хоть 32к, вроде как набор режимов не фиксированный.
Хотя вот здесь режимы перечисляются, максимум 1600x1200. С тех пор изменилось что? Статья 2010 года всеж.
Я уж молчу что сейчас линухи все на wayland практически перешли, и там до фига все могло поменяться.
А я это все к чему. Меня блин ужасает когда драйвер видеокарты занимает блин гигабайт! И я конечно понимаю, что если воспроизводить видео или анимацию только средствами процессора, то будут лютейшие тормоза на современных разрешениях. Однако меня очень печалит, что при отсутствии драйвера до того, как я его поставлю, работать крайне некомфортно, либо консоль, либо писец какое мыло и крайне низкое разрешение.
Называется не те драйвера поставил — и сиди один на один с текстовой консолью, и гуглить с текстовой консоли это та еще радость. И для таких случаев можно же было в 2025-м году сделать какой режим, позволяющий хоть с тормозами при прокрутке, но отобразить браузер. Сидеть в 1024 на 768 в то время, когда все сверстано под совсем другое разрешение и под другую конфигурацию экрана — такое себе, хоть и лучше чем тупо текстом в консоли.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, kov_serg, Вы писали:
_>>Так что грузишь линукс и через /dev/fb0 фигачишь или запускаешь xserver и через него. E>Так это один фиг через драйвер работает, при отсутствии драйверов через тот же VESA. Это тупо абстракция над драйвером, при отсутствии нормального драйвера будет драйвер для VESA режимов.
E>Насколько я понимаю, /dev/fb0 держат иксы, соответственно фиг я туда что запишу напрямую — правильно? А вот смогу ли прочитать оттуда — это уже интереснее, но скорее всего тоже не смогу.
E>Но вообще, я сейчас немного по поводу VESA погуглил, и в теории там вроде есть возможность вообще любое разрешение поддерживать, хоть 32к, вроде как набор режимов не фиксированный.
E>Хотя вот здесь режимы перечисляются, максимум 1600x1200. С тех пор изменилось что? Статья 2010 года всеж.
E>Я уж молчу что сейчас линухи все на wayland практически перешли, и там до фига все могло поменяться.
E>А я это все к чему. Меня блин ужасает когда драйвер видеокарты занимает блин гигабайт! И я конечно понимаю, что если воспроизводить видео или анимацию только средствами процессора, то будут лютейшие тормоза на современных разрешениях. Однако меня очень печалит, что при отсутствии драйвера до того, как я его поставлю, работать крайне некомфортно, либо консоль, либо писец какое мыло и крайне низкое разрешение.
E>Называется не те драйвера поставил — и сиди один на один с текстовой консолью, и гуглить с текстовой консоли это та еще радость. И для таких случаев можно же было в 2025-м году сделать какой режим, позволяющий хоть с тормозами при прокрутке, но отобразить браузер. Сидеть в 1024 на 768 в то время, когда все сверстано под совсем другое разрешение и под другую конфигурацию экрана — такое себе, хоть и лучше чем тупо текстом в консоли.
Нет вы сами можете написать драйвер fb и алга
Я к тому что если хочется на всё запускаться или хотябы на многом, по придётся таскать минимальный набор дров для этого множеста.
Без этого никак. Особенно если у вас не x86
Вот пример линуха который должен был пускаться на всём https://slitaz.org/en/ и работать из ram (аля zx-spectrum)
но 3 4 5 могут пускаться на разном подмножестве множесте железа. приходится троих таскать на флешке.
Здравствуйте, kov_serg, Вы писали:
_>Нет вы сами можете написать драйвер fb и алга _>Я к тому что если хочется на всё запускаться или хотябы на многом, по придётся таскать минимальный набор дров для этого множеста. _>Без этого никак. Особенно если у вас не x86
Ну вот минимальный набор дров — это вроде бы VESA, но чтоб с поддержкой современных разрешений. Всякие совсем уж старые драйвера вроде S3Trio64 не актуальны совершенно, а почти гигабайт на NVIDIA карточку для драйвера — это капец какой избыток, тем более как минимум есть еще AMD и Intel карточки, в том числе в процессоре.
Но вообще, кажется какой у нас последний видеостандарт я вроде разобрался http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf
Там в пропозалах вроде как планы как минимум такое для аудио добавить, что можно только приветствовать и лет через 10 наверно добавят.
Здравствуйте, elmal, Вы писали:
E>Ну вот минимальный набор дров — это вроде бы VESA, но чтоб с поддержкой современных разрешений. Всякие совсем уж старые драйвера вроде S3Trio64 не актуальны совершенно, а почти гигабайт на NVIDIA карточку для драйвера — это капец какой избыток, тем более как минимум есть еще AMD и Intel карточки, в том числе в процессоре.
По поводу S3Trio вы неправы многие железяки поддерживают старый интерфейс.
E>Но вообще, кажется какой у нас последний видеостандарт я вроде разобрался E>http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf E>Там в пропозалах вроде как планы как минимум такое для аудио добавить, что можно только приветствовать и лет через 10 наверно добавят.
Все эти расширения должны быть в прошивке видео карты. А там обычно не заморачиваются только базовые вичи vbe2 или вообще только uefi с самыми простыми разрешениями. Ускорение только в маках остальным нафиг не надо ибо сложно и не прибыльно. Никто бесплатно заморачиваться не хочет. А если учесть что еще uefi бывает и с ошибками которые никто не исправляет то вообще прикольно.
Так что выбор использовать линух и его драйвера, если их нет дописывать самому (если достаните описание на железо) линуксойды много чего нареверсили что бы получить хоть какие-то дрова. Грех не использовать накопленный человеческий опыт.
Более того если у вас своя железяка то всякие bios, uefi это overkill достаточно реализовать интерфейс sdl и уже можно ехать.
Здравствуйте, kov_serg, Вы писали:
_>По поводу S3Trio вы неправы многие железяки поддерживают старый интерфейс.
Ну, хватает того, что у меня таких железяк нет
E>>Но вообще, кажется какой у нас последний видеостандарт я вроде разобрался E>>http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf E>>Там в пропозалах вроде как планы как минимум такое для аудио добавить, что можно только приветствовать и лет через 10 наверно добавят. _>Все эти расширения должны быть в прошивке видео карты. А там обычно не заморачиваются только базовые вичи vbe2 или вообще только uefi с самыми простыми разрешениями.
Ээээ, можно поконкретнее с терминологией? VBE2 — это вроде VESA BIOS EXTENSION. Насколько я тут разобрался — тупо 10 прерывание, при инициализации видеокарта как то сама устанавливает вектор 10-го прерывания таким образом, чтобы непосредственно его обрабатывать. Как это делается в деталях как то пока не представляю, на такой уровень обычно мало кто лезет, а мне вот в отпуске интересно стало .
EFI вроде как ко всем этим VESA никакого отношения не имеет вообще. И там вроде никаких int 10h теперь, а появилось вместо этого сначала EFI UGA, а сейчас самое современное что есть — это UEFI GOP. Последнее это вроде как самое современное, что есть. То, что появилось в EFI — оно сразу работает в защищенном режиме и соответственно никаких костылей с сегментами и 1Mb памяти хватит всем уже не актуально.
Все, что пошло с EFI и выше — оно уже по умолчанию новее VBE3, соответственно фичи поактуальнее должны быть.
Тоже очень интересно как это связано с биосом видеокарты, и что конкретно происходит когда дергаешь функцию определенной в хедере, как там все в код видеокарты попадает тож не очень понятно.
_>Ускорение только в маках остальным нафиг не надо ибо сложно и не прибыльно. Никто бесплатно заморачиваться не хочет. А если учесть что еще uefi бывает и с ошибками которые никто не исправляет то вообще прикольно.
Так ускорение там нафиг не сдалось, даже если будет 1 кадр секунду рендериться, это вполне приемлемо.
_>Так что выбор использовать линух и его драйвера, если их нет дописывать самому (если достаните описание на железо) линуксойды много чего нареверсили что бы получить хоть какие-то дрова. Грех не использовать накопленный человеческий опыт.
Ээээ, а ежли я хочу на реальном железе поиграться со всякими QNX? А то и всякие KolibriOS. Там никакие линуксовые драйвера не пойдут вроде. А базового графического комфорта всеж хочется.
Здравствуйте, elmal, Вы писали:
E>>>Там в пропозалах вроде как планы как минимум такое для аудио добавить, что можно только приветствовать и лет через 10 наверно добавят. _>>Все эти расширения должны быть в прошивке видео карты. А там обычно не заморачиваются только базовые вичи vbe2 или вообще только uefi с самыми простыми разрешениями. E>Ээээ, можно поконкретнее с терминологией? VBE2 — это вроде VESA BIOS EXTENSION. Насколько я тут разобрался — тупо 10 прерывание, при инициализации видеокарта как то сама устанавливает вектор 10-го прерывания таким образом, чтобы непосредственно его обрабатывать. Как это делается в деталях как то пока не представляю, на такой уровень обычно мало кто лезет, а мне вот в отпуске интересно стало .
Там ничего сложного небыло. Но если хочется что бы было всеядно то и это должно быть. Более того были железки где vbe это отсутствовало и добавлялось после загрузки сторонним исполняемым univbe.
E>EFI вроде как ко всем этим VESA никакого отношения не имеет вообще. И там вроде никаких int 10h теперь, а появилось вместо этого сначала EFI UGA, а сейчас самое современное что есть — это UEFI GOP. Последнее это вроде как самое современное, что есть. То, что появилось в EFI — оно сразу работает в защищенном режиме и соответственно никаких костылей с сегментами и 1Mb памяти хватит всем уже не актуально.
Защищенны не защищенный это дело десятое. Дело в том что эти фичи реализованы по остаточному принципы.
E>Все, что пошло с EFI и выше — оно уже по умолчанию новее VBE3, соответственно фичи поактуальнее должны быть.
E>Тоже очень интересно как это связано с биосом видеокарты, и что конкретно происходит когда дергаешь функцию определенной в хедере, как там все в код видеокарты попадает тож не очень понятно.
Там всё очень просто или по портам меняются регисты или по адресам памяти. Просто заполняеши линию данными и оно пошло что-то делать. Есть еще управление по медленной шине типа i2c.
_>>Ускорение только в маках остальным нафиг не надо ибо сложно и не прибыльно. Никто бесплатно заморачиваться не хочет. А если учесть что еще uefi бывает и с ошибками которые никто не исправляет то вообще прикольно. E>Так ускорение там нафиг не сдалось, даже если будет 1 кадр секунду рендериться, это вполне приемлемо.
Незнаю запускаещь какой-нибудь сервер за 10кбаксов, заходишь в биос и оно перерисовывает текстовый экран медленнее чем 286. Это просто огонь.
E>Ээээ, а ежли я хочу на реальном железе поиграться со всякими QNX? А то и всякие KolibriOS. Там никакие линуксовые драйвера не пойдут вроде. А базового графического комфорта всеж хочется.
С фигали. Там обычно полноценный ubuntu с питоном А всякие микро контроллеры аля arduino на mege спокойно lvgl рисуют или через либы lcd экранов по spi и тому же i2c.
Причем на ардуине это делается в пару кликов и оно работает и потом просто допиливаешь под себя.
Здравствуйте, kov_serg, Вы писали:
_>Там всё очень просто или по портам меняются регисты или по адресам памяти. Просто заполняеши линию данными и оно пошло что-то делать. Есть еще управление по медленной шине типа i2c.
Ну, мне не очень понятен хотя бы порядок инициализации после включения питания. Вот включается питание, проц стартует. На видеокарту когда подается питание и когда она стартует? И как данные из BIOS видеокарты попадают на шину адреса и данных процессора как минимум, и тем более так попадает, чтоб попадало в нужный момент чтоб в нужную область памяти записалось по сигналу с видеокарты определенные значения. Что представляет собой шина PCI Express электрически и программно тоже пока представление не очень имею, к своему стыду не очень у меня есть понятие даже как ISA шина работала .
_>Незнаю запускаещь какой-нибудь сервер за 10кбаксов, заходишь в биос и оно перерисовывает текстовый экран медленнее чем 286. Это просто огонь.
Ну, оно не так часто надо в биос то заходить.
_>С фигали. Там обычно полноценный ubuntu с питоном А всякие микро контроллеры аля arduino на mege спокойно lvgl рисуют или через либы lcd экранов по spi и тому же i2c.
Где полноценный ubuntu с питоном? В QNX и KolibriOS? Чет у меня другая информация, там линуксами даже не пахнет, по крайней мере в kolibriOS точно. LGVL это вроде как совсем другой стандарт, даже близко не соприкасающийся с VESA и всякими реальными мониторами и мейнстримными видеокартами и всяким HDMI и DP. То есть в микроконтроллерах видеостандарт есть, достаточно актуальный и современный, заточенный под требуемые задачи, естественно что там не RTX 5090 видеокарту подрубают а что попроще. Для ПК с этим сильно все печальнее.
Здравствуйте, elmal, Вы писали:
_>>Там всё очень просто или по портам меняются регисты или по адресам памяти. Просто заполняеши линию данными и оно пошло что-то делать. Есть еще управление по медленной шине типа i2c. E>Ну, мне не очень понятен хотя бы порядок инициализации после включения питания. Вот включается питание, проц стартует. На видеокарту когда подается питание и когда она стартует? И как данные из BIOS видеокарты попадают на шину адреса и данных процессора как минимум, и тем более так попадает, чтоб попадало в нужный момент чтоб в нужную область памяти записалось по сигналу с видеокарты определенные значения. Что представляет собой шина PCI Express электрически и программно тоже пока представление не очень имею, к своему стыду не очень у меня есть понятие даже как ISA шина работала .
Таки посмотрите там есть медленная шина smbus (типа i2c) +jtag (можно отлаживать, прошивать и даже диагностировать пины // при условии что есть описание BSDL микросхем которые подключены) и lane-ы 1,2 ... 16 каждая lane это по две диф пары in/out + еще к ним диф пара тактирования по ним как по сетевухе гоняются пакеты. Если не заморачиваться с транспортом то они позволяют читать и писать память и порты
То что раньше делалось напрямую в ISA. Так что после втыкания вы можете прочитать или записать конфигурацию, память, порты и другие запросы.
E>Где полноценный ubuntu с питоном? В QNX и KolibriOS? Чет у меня другая информация, там линуксами даже не пахнет, по крайней мере в kolibriOS точно. LGVL это вроде как совсем другой стандарт, даже близко не соприкасающийся с VESA и всякими реальными мониторами и мейнстримными видеокартами и всяким HDMI и DP. То есть в микроконтроллерах видеостандарт есть, достаточно актуальный и современный, заточенный под требуемые задачи, естественно что там не RTX 5090 видеокарту подрубают а что попроще. Для ПК с этим сильно все печальнее.
Вот например микроконтроллер за 12$ с 1Tops. LVGL это не стандарт, а просто библиотека для отрисовки, одна и многих. Теже малинки, банабыпи, репки и куча микрокомпьютеров на arm, mips и riscv
Я и не говорил про монстров, для микроконтроллнров достаточно VGA и LVDS или даже I2C для маленьких экранов. Для 16К вам и оборудование надо будет соответствующее способное выдавать картинку в DP. HDMI у многих SOC есть встроенный. И обычно там нигде нет задачи пускаться на широком зоопарке железа, просто используют уже готовые решения и не компостируют мозг.
Здравствуйте, kov_serg, Вы писали:
_>Там всё очень просто или по портам меняются регисты или по адресам памяти. Просто заполняеши линию данными и оно пошло что-то делать. Есть еще управление по медленной шине типа i2c.
сложнее там всё, есть много буферов инструкций есть, которые написаны на собсвтенном, очень странном ассемблере. Со странной архитектурой. Да у GPU даже есть своя страничная адресация памяти, с переключением таблиц страниц для разных GPU задач, наподобие как это делает Linux kernel для приложений.
Вот, почитайте про эксплуатацию недавнего бага в GPU. Довольно простой баг для того, чтобы его триггернуть. Очень мощный при этом. И всё равно, какие сложности, и как всё чудовищно устроено.
