Здравствуйте, Sharov, Вы писали:
CC>>BIOS занимается начальным конфигурированием видеокарты, чтоб туда можно было что то рисовать пока нормальная ОС не стартанула. S>Дурацкий вопрос, но где про этот процесс можно детальнее почитать. Взаимодействие биос и карты на старте.
В классическом ДОС было всё просто — ROM видеокарты отображался в область выше 640Кб и при инициализации основной BIOS туда делал переход.
В x86 он отображался полностью железно — на схеме реально стоял компаратор, который отправлял запросы в ROM карты при совпадении. Все смещения, насколько я помню, были статические. Т.е. при замене видеокарты там появлялся новый код.
Здравствуйте, alpha21264, Вы писали:
A>И эта программа греет видимокарту так, что карта жужжит громче процессора?
По сравнению с видеокартой — процессор хилое слабое чмо. Какие-то сраные десятки гигафлопс (со стероидными AVX — сотни). Против полутора десятка ТЕРРАфлопс у видяхи.
A>Процессор (обычный, Интел) в каком-то виде (скорее всего 3Д) формирует сцену,
Нет, сцену тоже формирует видеокарта. Включая скелетную анимацию моделей. Процессор только начальные данные в видяху загружает, да игровую логику обрабатывает.
Здравствуйте, alpha21264, Вы писали:
A>Такие бессмысленные слова я тоже умею говорить. A>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
Подробнее — когда ты жил без этой прокладки ? Или ты до сих пор в IBM PC XT сидишь ? Там, кстати, тоже был драйвер, он зашит в BIOS. Ты не обязан им пользоваться, можешь всё руками делать, главное найди аргументы, что бы и другие разработчики делали тож самое.
Здравствуйте, const_volatile, Вы писали:
CC>>Поди не системщик, да? Всегда юзеры жили с какой то прокладкой. _>наоборот, олдскульный системщик. под досом не было никаких видеодрайверов и видеопамять тупо мапилась в общее адресное пространство.
И ради игрушек надо было обязаетльно поствить како нибудь VGA, SVGA, VESA драйвер, иначе игрушка ничего не могла выдать.
_>а до этого были времена, когда с видюхой можно было общаться командой out из приложения, минуя системное api. и было всего 3 типа видеокарт — CGA, EGA и VGA.
И даже тогда большинство софта работало не напрямую с железом, а через прерываение 10h BIOS или даже через 21h DOS. Даже если писали в видеопамять, маппингом управлял этот BIOS. Переключение режима мало в своём уме делал напрямую, получение адресов, смещений тоже делалось через BIOS.
Здравствуйте, alpha21264, Вы писали:
Z>>есть железка, которая работает по определенному протоколу. чтобы на экране нарисовать точку, нужно этому протоколу следовать. как это сделать — и есть задача драйвера.
A>Совсем-то откровенную фигню писать не надо. A>Чтобы на экране написовать точку нужно отправить байт в определённое место памяти. A>И Линукс и Винда именно это и делает, когда никакой драйвер ещё не установлен или не стартовал.
Да, могут писать в память средствами BIOS или по стандартным для VGA адресам.
Это и медленно, и разрешение детское.
A>Протокол можно соблюдать любой прграммой или библиотекой. Но ни то ни другое не есть драйвер.
Здравствуйте, alpha21264, Вы писали:
A>Совсем-то откровенную фигню писать не надо. A>Чтобы на экране написовать точку нужно отправить байт в определённое место памяти.
А ты уверен, что это ВСЕГДА так?
Здравствуйте, alpha21264, Вы писали:
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
От ОС не зависит...
Для разнообразия — поставь линукс сервер и попробуй какую-нибудь картинку нарисовать на экране
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
Работает
A>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>Не дайте дурой помереть!
Ну вот посмотри, есть разные производили видео-карт, каждый колбасит как умеет, у каждого свои заморочки, оптимизирующие графические вычисления, и как прикладному программисту с этим жить? Под каждую видео-карту отдельный софт писать? Во-о-о-от, надо что? Правильно стандартизовать интерфейс общения прикладного ПО с видео-картой, вот этим драйвер и занимается. Это переводчик, за который отвечает производитель видео-карты.
Здравствуйте, Dym On, Вы писали:
A>>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>>Не дайте дурой помереть! DO>Ну вот посмотри, есть разные производили видео-карт, каждый колбасит как умеет, у каждого свои заморочки, оптимизирующие графические вычисления, и как прикладному программисту с этим жить? Под каждую видео-карту отдельный софт писать? Во-о-о-от, надо что? Правильно стандартизовать интерфейс общения прикладного ПО с видео-картой, вот этим драйвер и занимается. Это переводчик, за который отвечает производитель видео-карты.
Вот сколько не писал прикладного ПО — с драйвером взаимодействовать не приходилось, только с OS.
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот сколько не писал прикладного ПО — с драйвером взаимодействовать не приходилось, только с OS.
Собствено драйвера и нужны ОС чтобы реализовать некоторый API с которым уже все остальные работают.
Здравствуйте, 0x7be, Вы писали:
A>>Совсем-то откровенную фигню писать не надо. A>>Чтобы на экране написовать точку нужно отправить байт в определённое место памяти. 0>А ты уверен, что это ВСЕГДА так?
"Всегда" бывают разные. Бывают, например, аналоговые телевизоры. Но мы же не про это говорим?
A>"Всегда" бывают разные. Бывают, например, аналоговые телевизоры. Но мы же не про это говорим?
Отрисовка пикселя путем записи байта в память возможна только в случае отображения видеопамяти на адресное пространство процессора. Это широко применяемая схема, но не единственная. Например, есть устройства отображения, подключаемые к последовательным шинам — SPI, I2C, USB. Их видеопамять не отображается на адресное пространство, а отрисовка происходит путем посылки команд.
Здравствуйте, IID, Вы писали:
IID>Нет, сцену тоже формирует видеокарта. Включая скелетную анимацию моделей. Процессор только начальные данные в видяху загружает, да игровую логику обрабатывает.
нельзя сравнивать не сравнимое. процессор универсален и в нем 2-4-8+ ядер. видеокарта узко специализированная и в ней сотни и тысячи ядер. есть алгоритмы, которые можно распараллелить и их хорошо обрабатывать на видеокарте. а если программы, которые на видеокартах запускать нет никакого смысла, потому что производительность их будет никакой.
Здравствуйте, 0x7be, Вы писали:
A>>"Всегда" бывают разные. Бывают, например, аналоговые телевизоры. Но мы же не про это говорим? 0>Отрисовка пикселя путем записи байта в память возможна только в случае отображения видеопамяти на адресное пространство процессора. Это широко применяемая схема, но не единственная. Например, есть устройства отображения, подключаемые к последовательным шинам — SPI, I2C, USB. Их видеопамять не отображается на адресное пространство, а отрисовка происходит путем посылки команд.
Ну, О Кей, уговорил. В таком случае наверное протоколу нужно следовать. Драйвер-то тут зачем?
Библиотека (да и программа) протоколу следует не хуже, но при этом нет странных прибабахов свойственных драйверам.
PS.
Кстати, всё равно не понял. Ну есть последовательная шина. Что мешает писать по адресу?
Почему вообще программа должна что-то знать про шины?
Ты когда-нибудь заморачивался на темы различной работы с памятью DDR, DDR2 и DDR3?
Они (шины, протоколы) в достаточной степени разные. Но программа про это ничего не знает.
И не должна.
MD>А вот некоторые видяхи поумнее умели аж 135 колонок рисовать. Для этого наша прога должна уметь понимать поддерживается ли этот режим, и если да, то знать как в него перейти.
Не должна понимать (в историчеком плане). И все проги самостоятельно не понимали поддерживается этот режим или нет, но некоторые могли в него переходить согласно пожеланию юзера.
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот сколько не писал прикладного ПО — с драйвером взаимодействовать не приходилось, только с OS.
Между юзермодской аппликухой и драйвером есть ещё пару слоёв.
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот сколько не писал прикладного ПО — с драйвером взаимодействовать не приходилось, только с OS.
Ну так никто не мешает начать: https://github.com/tmpvar/kmstools — напрямую к драйверу, минуя все остальные прослойки. Нужна только библиотека Mesa для трансляции OpenGL в поток команд конкретного драйвера.
A>PS. A>Кстати, всё равно не понял. Ну есть последовательная шина. Что мешает писать по адресу? A>Почему вообще программа должна что-то знать про шины? A>Ты когда-нибудь заморачивался на темы различной работы с памятью DDR, DDR2 и DDR3? A>Они (шины, протоколы) в достаточной степени разные. Но программа про это ничего не знает. A>И не должна.
Давай на примере разберем. Представь простую систему, где есть проц, озу, "обычный" видеоадаптер VGA, контроллер I2C и подключенный через I2C монитор. Система построена вокруг простой шины типa ISA: линии адреса, линии данных, управляющие сигналы. весь ввод-вывод — memory mapped.
Обычный цикл записи в адресное пространство:
1. Процессор выставляет на линии адреса желаемый адрес, на линии данных — данные, управляющие сигналы обозначают цикл записи.
2. Все устройства на шине "видят адрес", и у каждого отрабатывает логика дешифрации адреса. Если обращаются к устройству — оно реагирует, если нет — просто игнорирует этот цикл шины.
3. Выбранное устройство принимает байт из шины данных, обрабатывает его согласно свой логике, выставляет сигнал готовности.
4. Процессор принимает сигнал готовности и завершает цикл.
Помещение байта в VGA выглядит просто: схема дешифрации адреса видеоадаптера вычленяет циклы записи в соответствующее "окно" в адресном пространстве и в эти моменты подключает к шине ОЗУ видеоадаптера. Данные сразу попадают в ОЗУ из которой RAMDAC формирует видеосигнал, и мы видим пиксель.
Что же с I2C? контроллер I2C не отображает никакой памяти в адресное пространство процессора. Он ничего не знает том, что к нему подключено, он просто работает передастом потока байт по определенному транспортному протоколу. В адресное пространство процессора он отображает небольшое количество регистров через которые процессор ему отдаёт команду "послать вот такой пакет устройству с вот таким адресом". Как именно этот поток байт будет распознан устройством — это уже детали прикладного протокола, который "знает" само устройство и программа. Причем в тут даже может быть ДВА драйвера задействовано — драйвер контроллера I2C и драйвер самого монитора.
Как-то так.
A>Ну, О Кей, уговорил. В таком случае наверное протоколу нужно следовать. Драйвер-то тут зачем? A>Библиотека (да и программа) протоколу следует не хуже, но при этом нет странных прибабахов свойственных драйверам.
А так и было когда-то. Когда разного оборудования было мало, то все программы несли в себе весь необходимый код. Помнишь старые игры под MS-DOS, где вначале надо было выбрать, какой у тебя видеоадаптер и звуковая карта? Но когда оборудования стало много, то этот подход перестал работать — пришлось разделять код приложения и драйвера.
Дальше, если мы говорим про однозадачную систему, работающую без использования механизмов защиты то драйвер вполне может быть выполнен в виде динамической библиотеки, которая линкуется с приложением, предоставляя ему свой интерфейс. Но как только появляются системы, где есть ядро, работающее в привилегированном режиме, эта схема тоже перестаёт работать. Код приложения не имеет доступа к вводу-выводу (как к memory-mapped IO, так и к спец. командам ввода/вывода). Поэтому драйвер уже не может быть просто кодом, загруженным в приложение, он должен быть загружен в контекст ядра (говорим про системы с монолитным ядром, так проще). Вот тут и появляются все эти тонкости конкретной ОС — как именно драйвер встраивается в ядро, как именно приложение может с ним общаться и т.п. Если система многозадачная, то драйвер так же решает и задачу разделения доступа разных задач к одному устройству.
