Здравствуйте, alpha21264, Вы писали:
A>А теперь, когда вы уже обратили внимание на провокационный заголовок, A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
Эти драйверы (реального режима) жили и продолжают до сих пор жить в BIOS практически всех видеокарт (по крайней мере, предназначенных для IBM-, PowerPC- или MIPS Alpha- совместимых компов).
Если графика встроена в процессор, то соотв. часть кода видео-BIOS находится на материнке.
Именно ж поэтому не нужны никакие винды или линуха для доступа к базовой VESA-функциональности IBM- или PowerPC- совместимых компов.
A>И как оно сейчас.
Как сейчас с VESA уже рассказал.
Помимо этого появилось еще несколько абстракций, но уже заточенных под разные сценарии:
— сценарии удалённого графического адаптера;
— сценарии локального графического адаптера для защищённого режима процессоров.
Например, OpenGL, если взглянуть на него внимательней, писался исключительно под защищёный режим.
Все его абстракции и принципы работы с ними пляшут от маппинга IO на память в защищённом режиме и от необходимости абстрагирования от конкретного физического расположения графических объектов — те могут находится как в основной памяти компа, так и в памяти видеокартейки. Впервые по-настоящему неплохо подобную абстракцию реализовала подсистема Windows GDI. В появившемся значительно позже OpenGL хорошо видно, что приличную часть идей они тупо утянули у GDI. ))
A>Потому что то, что есть сейчас мне напоминает один старинный анекдот. A>Однажды собрались астрономы и стали рассуждать об птолемеевых эпициклах. A>Король испанский Альфонс II пошутил, что он бы посоветовал богу сотворить вселенную попроще.
Дык, абстракция — это и есть основной способ борьбы со сложностью.
Да, абстракции не дешевые, определённое penalty есть всегда... но это плата за возможность независимо развивать железо и софт, не прибивая одно к другому гвоздями.
Здравствуйте, alpha21264, Вы писали:
A>Экран 640 x 480 заполнял процессор intel-286 12 MHz!
Заполнить статический экран это не проблема. Проблема сделать программным образом хотя бы плавный скроллинг. Во времена Windows 3.1, если что, при перетаскивании окна перетаскивалась только контуры окна. Нажимаешь мышку, передвигаешь контур, отпускаешь мышку — только тогда шла перерисовка. Ибо если перетаскивать окно целиком — были бы тормоза. И тормозило тогда все весьма прилично, если что, можно было во многих случаях невооруженным глазом наблюдать как строится картинка. Соответственно чтоб эти тормоза убрать, и появилось 2Д ускорение.
A>Напомню, что он в среднем тратил 5 тактов на выполнение одной команды. A>Сейчас мы имеем процессоры в 3 MHz, 4 ядра и 4 команды за такт. A>Это более, чем в тысячу раз быстрее. A>Вы говорите про какие-то тормоза из-за высоких разрешений.
Во первых, разрешение 640 x 480 в древние VGA времена были при 16 цветах. Соответственно экранная область была порядка 150 килобайт. И для динамической картинки это тогда было довольно много, хотелось сильно ускорить. Сейчас НИЗКОЕ разрешение — это 1920*1080. При миллионах цветов, на пиксель идет 4 байта. Соответственно экранная область 8 мегабайт. Так вот, все анимации и т.д. требуются при хотя бы 60 кадрах в секунду, соответственно в секунду проц должен перелопатить 8*60 = 640 мегабайт. Нет, проц то с этим конечно справится и программными средствами. Вот только ценой загрузки процессора. 4 ядра и 4 такта за такт — это, кстати, пиковая производительность. Когда все инструкции загружены в кеш, нет промахов при предсказании переходов и т.д. В реальности меньше, при этом страдают другие приложения. Ты двигаешь окошко, а в этот момент у тебя начинает приостанавливаться компиляция, начинает пропадать звук в скайпе и т.д. Такое понравится? А если проц десятилетней давности, то ему уже будет напряжно. А процессору обычно есть чем заняться кроме рендеринга картинки.
Ну и если мы переходим к такой вещи, как 3Д, то уже при современных разрешениях у проца ни малейших шансов отрендерить сцену с приемлемой скоростью. Ибо над каждой точкой экрана нужно провести до фига вычислений.
А теперь, когда вы уже обратили внимание на провокационный заголовок,
расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался.
Не дайте дурой помереть!
Здравствуйте, CreatorCray, Вы писали:
CC>А, так ты потроллить сюда пришёл.
Конечно. Хотя все может быть. Автор темы намекал когда-то, что начинал карьеру на аналитической машине Бэббиджа, которую собрал по чертежам. Откуда на ней драйверы?
Здравствуйте, const_volatile, Вы писали:
A>>>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу. CC>>Поди не системщик, да? Всегда юзеры жили с какой то прокладкой. _>наоборот, олдскульный системщик. под досом не было никаких видеодрайверов и видеопамять тупо мапилась в общее адресное пространство.
Было, ещё как было. Драйвера видеокарты были частью BIOS ROM и были доступны через прерывание 10h, которое указывало прямо в ROM видеокарты. Потому переключение в старый добрый 13h было очень простым (mov ax, 13h; int 10h).
В то время от драйверов особо много не требовалось, потому и казалось, что их "не было". Но вот если хотелось что-то особенное, типа режима с возможностью использования back buffer'а, то уже требовалось программирование регистров видеокарты.
А когда появилась SVGA, то всё стало на порядок хуже. Стандарта нормального не было, и каждый творил что хотел. В результате появились драйвера типа https://en.wikipedia.org/wiki/UniVBE
Здравствуйте, Lazy Bear, Вы писали:
LB>Здравствуйте, alpha21264, Вы писали:
A>>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах. A>>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>>Не дайте дурой помереть!
LB>Это прокладка между вашим прикладным уровнем и неизвестной ему железкой
Такие бессмысленные слова я тоже умею говорить.
Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, Lazy Bear, Вы писали:
A>Такие бессмысленные слова я тоже умею говорить. A>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
А она и не тебе нужна, а операционке.
Говоришь ты в своей программе операционке — нарисуй-ка мне 3D треугольник, да побыстрее, с помощью видюхи.
А операционка такая глядь, а там Радеон, чо за херня, вчера НВидия стояла. Говорит операционка видюхе «слыш, хозяину треугольник на экране нужон», а видюха такая в ответ «cfhbchbdhb hufchuhnvbv hc dfaryh. Dhubdgud”. Не поняли они друг друга. Чтоб понимали — переводчик нужен. Вот это и есть драйвер.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, alpha21264, Вы писали:
A>>Я подозреваю, что авторы Автокада не просто так поступили таким образом, A>>на первый взгляд более трудоёмким. Наверное использовать драйверы было ещё труднее. E>Во первых, в те времена драйверов не было. И разработчики чтоб выполнить простейшие операции вроде нарисовать линию и вывести Hello World корячились и реализовывали весь функционал этого рисования, зачастую бразенхеймом. Во вторых, видеокарты тогда были достаточно примитивные, и не умели даже рисовать векторные шрифты. Потому писали напрямую в видеопамять в графическом режиме. В третьих, в те времена все работало под Dos. Программа была запущена одна, и эта одна программа обращалась напрямую с устройствами ввода вывода. В четвертых, в те времена более менее стандартами были CGA, EGA, VGA, Hercules. Потом появилась Vesa и SVGA. По современным стандартам те видеокарты были примитивные до неприличия. Даже на SVGA поддерживались крайне низкие разрешения вроде 1024*768. Но даже на этих разрешениях тормозило все неимоверно. Если через VESA все делать на современной видеокарте, охрененно заметны тормоза даже на современных процессорах.
640 x 480 = 307 200 пикселей (ничего не тормозило)
800 x 600 = 480 000
1024 x 762 = 786 432
1920 x 1080 = 2 073 600 пикселей.
Итого, что мы видим?
Нынешний размер экрана в 6.75 раз больше того, что был в прошлом веке.
Всего в семь раз! А процессоры с тех пор во сколько раз ускорились?
Экран 640 x 480 заполнял процессор intel-286 12 MHz!
Напомню, что он в среднем тратил 5 тактов на выполнение одной команды.
Сейчас мы имеем процессоры в 3 MHz, 4 ядра и 4 команды за такт.
Это более, чем в тысячу раз быстрее.
Вы говорите про какие-то тормоза из-за высоких разрешений.
Вы о чём вообще?
Остальное скипнул, потому что оно не имеет смысла не разобравшись с этим.
Здравствуйте, eskimo82, Вы писали:
MD>>Повторю ещё раз: стандарта — не было. Вот совсем. E>Вот вранье. Стандарт был и есть, в том числе и для 132 символов в строке.
Хорошо, давайте читать вот прямо с самого начала:
InstallCheck:
For Ahead adapters, the signature "AHEAD" at C000h:0025h.
For Paradise adapters, the signature "VGA=" at C000h:007Dh.
For Oak Tech OTI-037/057/067/077 chipsets, the signature "OAK VGA" at C000h:0008h.
For ATI adapters, the signature "761295520" at C000h:0031h; the byte at C000h:0043h indicates the chipset revision:
Или милая табличка с комментариями:
Notes:
[2] for ATI EGA Wonder, mode 08h is only valid if SMS.COM is loaded resident.
SMS maps mode 08h to mode 27h if the byte at location 0040:0063 is 0B4h,
otherwise to mode 23h, thus selecting the appropriate (monochrome or
color) 132x25 character mode.
for ATI VGA Wonder, mode 08h is the same, and only valid if VCONFIG loaded
resident
[3] early XGA boards support 132-column text but do not have this BIOS mode
Итого, вместо одного способа "узнать есть ли поддержка 132*25, и включить при возможности" мы начинаем колбасить простыню проверок в прикладном коде. Ничего не напоминает? Подскажу: если IE, если Chrome, если FireFox…
Это, батенька, никакой не Стандарт. Это — макароны в стиле JavaScript.
Здравствуйте, eskimo82, Вы писали:
MD>>Хорошо, давайте читать вот прямо с самого начала: E>В данном случае, этот документ следует читать не с начала:
E>Values for video mode: E>text/ text pixel pixel colors disply scrn system E>grph resol box resolution pages addr E>00h = T 40x25 8x8 320x200 16gray 8 B800 CGA,PCjr,Tandy E>01h = T 40x25 8x8 320x200 16 8 B800 CGA,PCjr,Tandy E>02h = T 80x25 8x8 640x200 16gray 4 B800 CGA,PCjr,Tandy E>03h = T 80x25 8x8 640x200 16 4 B800 CGA,PCjr,Tandy E>04h = G 40x25 8x8 320x200 4 . B800 CGA,PCjr,EGA,MCGA,VGA E>05h = G 40x25 8x8 320x200 4gray . B800 CGA,PCjr,EGA E>06h = G 80x25 8x8 640x200 2 . B800 CGA,PCjr,EGA,MCGA,VGA E>07h = T 80x25 9x14 720x350 mono var B000 MDA,Hercules,EGA E>08h = T 132x25 8x8 1056x200 16 . B800 ATI EGA/VGA Wonder [2] E>09h = G 40x25 8x8 320x200 16 . . PCjr, Tandy 1000
С начала или нет, а вот художественной резкой по квотингу заниматься не надо, да.
Потому что на самом деле там сильно больше строчек, и написано, например, такое:
03h = T 80x25 8x8 640x200 16 4 B800 CGA,PCjr,Tandy
= T 80x25 8x14 640x350 16/64 8 B800 EGA
= T 80x25 8x16 640x400 16 8 B800 MCGA
= T 80x25 9x16 720x400 16 8 B800 VGA
= T 80x43 8x8 640x350 16 4 B800 EGA,VGA [17]
= T 80x50 8x8 640x400 16 4 B800 VGA [17]
<...>
08h = T 132x25 8x8 1056x200 16 . B800 ATI EGA/VGA Wonder [2]
= T 132x25 8x8 1056x200 mono . B000 ATI EGA/VGA Wonder [2]
= G 20x25 8x8 160x200 16 . . PCjr, Tandy 1000
= G 80x25 8x16 640x400 color . . Tandy 2000
= G 90x43 8x8 720x348 mono . B000 Hercules + MSHERC.COM
= G 90x45 8x8 720x360 mono . B000 Hercules + HERKULES [11]
= G 90x29 8x12 720x348 mono . . Hercules + HERCBIOS [15]
То есть уже в самой первой порции режимов надо было знать, что за карточка, и что за драйвер(!), чтобы узнать, какой режим стоит за конкретным номером.
И, кстати, источника, аналогичного RBIL, в первой половине 80х не было, от слова "совсем". Крохи данных набирались личным обменом и/или из журналов типа Byte, кои процентов на 80 состояли из рекламы разноцветного светящегося дерьма за бешеные деньги.
Это всё не называется "стандарт". Это называется "бардак".
E>Прекрасно видно что интерфейс для переключения видеорежимов стандартизован.
Прекрасно видно, что ничего подобного.
MD>>Или милая табличка с комментариями: E>К переключениюб видеорежимом эта табличка не имеет никакого отношения.
И к чему же она имеет отношение?
>> for ATI EGA Wonder, mode 08h is only valid if SMS.COM is loaded resident.
То есть режим 08h может быть включён только при дополнительных условиях, которые надо проверить вендороспецифичным образом. И ты продолжаешь утверждать, что "к переключению <...> не имеет отношения"?
Это какой-то альтернативный метод использования даже не русского языка, а вообще любого человеческого.
MD>>Итого, вместо одного способа "узнать есть ли поддержка 132*25, и включить при возможности" мы начинаем колбасить простыню проверок в прикладном коде. Ничего не напоминает? Подскажу: если IE, если Chrome, если FireFox… E>Еще раз:
И все проги самостоятельно не понимали поддерживается этот режим или нет, но некоторые могли в него переходить согласно пожеланию юзера.
Ну да, теперь драйвером работает ещё и юзер — он должен знать, какой номер ему задать, чтобы получить конкретный результат.
E>И вариант без VESA на любой карточке: E> mode = atoi(argv[1]);
Вот именно. "На этой машине жмите foo.exe 8". Хотел было спросить "а самому не смешно", но смысла нет...
Здравствуйте, alpha21264, Вы писали:
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
Что делает? Достаточно много:
1) Предоставляет унифицированный интерфейс к настройкам мониторов, включая такие вещи, как цветовое пространство.
2) Занимается 3D-ускорением. В частности, это включает полноценный компилятор шейдеров из высокоуровневого языка в машинный код видеокарты.
3) Занимается менеджментом памяти, включая миграцию из видеопамяти в системную (и наоборот).
Здравствуйте, alpha21264, Вы писали:
A>Совсем-то откровенную фигню писать не надо.
Так не пиши
A>Чтобы на экране написовать точку нужно отправить байт в определённое место памяти.
Видеокарту можно сконфигурировать таким образом, но в общем случае это очень сильно не так.
A>И Линукс и Винда именно это и делает, когда никакой драйвер ещё не установлен или не стартовал.
BIOS занимается начальным конфигурированием видеокарты, чтоб туда можно было что то рисовать пока нормальная ОС не стартанула.
Здравствуйте, alpha21264, Вы писали:
A>Но тогда совсем непонятно, зачем нужен драйвер.
Драйвер как раз заменяет физическое устройство виртуальным, которое обещает уметь все нужные функции, а там он сам разберётся что железке говорить чтоб она сделала что попросили.
A>Библиотека отличается от драйвера тем, что она не привязана к операционной системе и к версии операционной системы.
Она всё равно привязана к очень конкретному протоколу общения с железкой.
Драйвер это всё прячет внутрь.
A>К тому же библиотека не может уронить операционку в синий экран.
Дык юзермодный драйвер тоже не может.
Здравствуйте, alpha21264, Вы писали:
A>Такие бессмысленные слова я тоже умею говорить. A>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
ты не можешь жить без видеодрайвера, иначе на твоем мониторе ты ничего не увидишь.
есть железка, которая работает по определенному протоколу. чтобы на экране нарисовать точку, нужно этому протоколу следовать. как это сделать — и есть задача драйвера.
Здравствуйте, alpha21264, Вы писали:
A>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
Поди не системщик, да? Всегда юзеры жили с какой то прокладкой.
Я вот времена когда приходилось под каждую видюху свой код писать и её глюки отслеживать и поддерживать вспоминаю с содроганием.
Здравствуйте, const_volatile, Вы писали:
_>наоборот, олдскульный системщик. под досом не было никаких видеодрайверов и видеопамять тупо мапилась в общее адресное пространство.
Это для текстового режима. Для графики надо было мудохаться как проклятому. Хреначить магические константы в магические регистры, которые далеко не везде работали одинаково.
CC>>Я вот времена когда приходилось под каждую видюху свой код писать и её глюки отслеживать и поддерживать вспоминаю с содроганием. _>а до этого были времена, когда с видюхой можно было общаться командой out из приложения, минуя системное api. и было всего 3 типа видеокарт — CGA, EGA и VGA.
Их было несколько больше, а ещё не все вендоры правильно реализовывали даже свои спецификации.
Здравствуйте, zverjuga, Вы писали:
A>>Такие бессмысленные слова я тоже умею говорить. A>>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
Z>ты не можешь жить без видеодрайвера, иначе на твоем мониторе ты ничего не увидишь. Z>есть железка, которая работает по определенному протоколу. чтобы на экране нарисовать точку, нужно этому протоколу следовать. как это сделать — и есть задача драйвера.
Совсем-то откровенную фигню писать не надо.
Чтобы на экране написовать точку нужно отправить байт в определённое место памяти.
И Линукс и Винда именно это и делает, когда никакой драйвер ещё не установлен или не стартовал.
Пингвин, которого рисует Линукс при старте, пишется непосредственно в память процессором.
Потом (когда и ОС и Драйвер стартовали) общение идёт через драйвер.
В Линуксе в любой ммент можно нажать Ctrl+Alt+F1 и вот ты снова без драйвера.
Протокол можно соблюдать любой прграммой или библиотекой. Но ни то ни другое не есть драйвер.
Здравствуйте, eskimo82, Вы писали:
CC>>С указанием что на чём не работает, если можно. E>Например на этом или этом. E>С полным списком можно ознакомится здесь.
Где там хоть одна игра, про которую ты заявил?
?>Никогда не встречал игр, работающих только на Nvidia? Или не работающих на Radeon?
MD>Или милая табличка с комментариями:
К переключениюб видеорежимом эта табличка не имеет никакого отношения.
MD>Итого, вместо одного способа "узнать есть ли поддержка 132*25, и включить при возможности" мы начинаем колбасить простыню проверок в прикладном коде. Ничего не напоминает? Подскажу: если IE, если Chrome, если FireFox…
Еще раз:
И все проги самостоятельно не понимали поддерживается этот режим или нет, но некоторые могли в него переходить согласно пожеланию юзера.
MD>Это, батенька, никакой не Стандарт. Это — макароны в стиле JavaScript.
Это у тебя в голове макароны.
MD>А теперь давайте посмотрим на действительный Стандарт на примере VESA MD>http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf MD>И вот что получается в итоге на любой (любой, Карл!!111) SVGA-карточке: MD>
MD>void main(int argc, char *argv[])
MD>{
MD> int x,y;
MD> if (argc != 3)
MD> availableModes();
MD> x = atoi(argv[1]);
MD> y = atoi(argv[2]);
MD> initGraphics(x, y);
MD> drawMoire();
MD> getch();
MD>}
MD>
MD>хорошо, добавим комментариев:
наивные коментарии, да еще и на русском не принимаются.
MD>Повторю требование — Стандарт это унификация и краткость (а не "описание болезни", как мы имеем в случае с JS-макаронами)
Учи матчасть.
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, так и к спец. командам ввода/вывода). Поэтому драйвер уже не может быть просто кодом, загруженным в приложение, он должен быть загружен в контекст ядра (говорим про системы с монолитным ядром, так проще). Вот тут и появляются все эти тонкости конкретной ОС — как именно драйвер встраивается в ядро, как именно приложение может с ним общаться и т.п. Если система многозадачная, то драйвер так же решает и задачу разделения доступа разных задач к одному устройству.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, CreatorCray, Вы писали:
CC>>BIOS занимается начальным конфигурированием видеокарты, чтоб туда можно было что то рисовать пока нормальная ОС не стартанула.
S>Дурацкий вопрос, но где про этот процесс можно детальнее почитать. Взаимодействие биос и карты на старте.
скорее нигде
У карты есть свой BIOS. И его запускает BIOS компьютера.
Здравствуйте, Sharov, Вы писали:
CC>>BIOS занимается начальным конфигурированием видеокарты, чтоб туда можно было что то рисовать пока нормальная ОС не стартанула. S>Дурацкий вопрос, но где про этот процесс можно детальнее почитать. Взаимодействие биос и карты на старте.
В классическом ДОС было всё просто — ROM видеокарты отображался в область выше 640Кб и при инициализации основной BIOS туда делал переход.
В x86 он отображался полностью железно — на схеме реально стоял компаратор, который отправлял запросы в ROM карты при совпадении. Все смещения, насколько я помню, были статические. Т.е. при замене видеокарты там появлялся новый код.
alpha21264:
A>А теперь, когда вы уже обратили внимание на провокационный заголовок, A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах. A>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>Не дайте дурой помереть! A>
В досовские времена было ограниченное число стандартов видеокарт.
Видеодрайвера тогда входили в BIOS, (если не вру, int 10h) но работали медленно.
Хочешь быстро красить пиксели пачками, учи видеорежимы, адреса видеопамяти, порты и пр.
Потом пошли ОСи с оконными интерфейсами и зоопарк SVGA-режимов.
Каджый пиксель не нарисуешь по int 10h, вот появились драйвера на уровне ОС.
Потом видеокарты научились рисовать линии, рамки, иконки, простые графические примитивы.
Каждая видюха рисует примитивы своим способом. и в биос все не засунешь, для каждой оси нужен свой драйвер.
Потом видюхи научились 3d. Потом GPGPU. Кодирование и декодирование видео. Нейросети и пр. и пр.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Здравствуйте, Stanislav V. Zudin, Вы писали:
A>>Я подозреваю, что авторы Автокада не просто так поступили таким образом, A>>на первый взгляд более трудоёмким. Наверное использовать драйверы было ещё труднее.
SVZ>Думаю, в те былинные времена драйверов просто не было. SVZ>Акад тупо заюзал самый общий АПИ, который поддерживался большинством плоттеров, ибо поддерживать все возможные модели — проще удавиться. SVZ>А по уму Акад должен был давать команды "нарисовать линию", "нарисовать дугу", а драйвер бы превращал эти команды либо в "много-много маленьких чёрточек", либо напрямую отправлял в железку.
Мы немного ушли от первоначальной темы — видеодрайверов.
Чтбы Автокад мог так делать, нужно чтобы был какой-то стандарт
на эти функции "нарисовать линию", "нарисовать дугу".
Чтобы все плоттеры выполняли эти команды и не сходили с ума.
Но тогда совсем непонятно, зачем нужен драйвер.
Чтобы превратить высокоуровневую команду в массив низкоуровневых,
нужен не драйвер, а библиотека. Собственно Автокад так и поступил.
Библиотека отличается от драйвера тем, что она не привязана
к операционной системе и к версии операционной системы.
Драйвер, который отлично работал в Виндовс 7 может отказаться
работать в Виндовс 8. И что тогда делать? Лапу сосать?
А с библиотекой гораздо проще — тут гарантируется совместимость
аж с прошлым веком. К тому же библиотека не может уронить
операционку в синий экран.
Здравствуйте, alpha21264, Вы писали:
A>Ой да ладно. В Линуксе Framebuffer почти так и работает. A>Вируальные адреса, правда могут не соответствовать физическим, A>но тем не менее пишешь как в массив пиксель за пикселем. A>В Виндах, наверное тоже так можно.
Так очень медленно. У меня, например, на компутере средней руки видимая область экрана — это примерно 19 МБ (два монитора 1980x1200). Если обновлять их 25 раз в секунду, то придется гнать по шине почти полгига в секунду. Это и сейчас дофига, а не так давно шина столько просто не умела. Это при том, что эти полгига надо еще откуда-то взять, что изрядно загрузит процессор.
Поэтому индустрия пришла к тому, что видеокарта стала универсальным вычислителем, который эти данные и вычисляет, исполняя загруженные в него программы. Только к сожалению, машинный код этого вычислителя нефига не стандартизован, да и способ загрузки этих программ и взаимодействия с ними тоже.
Так что пиксель за пикселем в реальной жизни никто не пишет.
Здравствуйте, alpha21264, Вы писали:
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах. A>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>Не дайте дурой помереть!
Это прокладка между вашим прикладным уровнем и неизвестной ему железкой
Здравствуйте, CreatorCray, Вы писали:
A>>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу. CC>Поди не системщик, да? Всегда юзеры жили с какой то прокладкой.
наоборот, олдскульный системщик. под досом не было никаких видеодрайверов и видеопамять тупо мапилась в общее адресное пространство.
CC>Я вот времена когда приходилось под каждую видюху свой код писать и её глюки отслеживать и поддерживать вспоминаю с содроганием.
а до этого были времена, когда с видюхой можно было общаться командой out из приложения, минуя системное api. и было всего 3 типа видеокарт — CGA, EGA и VGA.
Здравствуйте, T4r4sB, Вы писали:
TB>Во времена ДОСа, когда надо было писать байты в $A000:0000? Боюсь, там тоже без драйвера не обошлося.
Это таки было напрямую. Можно конечно считать, что драйвер был (и кстати есть, запись туда никто не отменял, если карта vga-совместима) сразу внутри платы.
Здравствуйте, Cyberax, Вы писали:
A>>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах. C>Что делает? Достаточно много: C>1) Предоставляет унифицированный интерфейс к настройкам мониторов, включая такие вещи, как цветовое пространство. C>2) Занимается 3D-ускорением. В частности, это включает полноценный компилятор шейдеров из высокоуровневого языка в машинный код видеокарты. C>3) Занимается менеджментом памяти, включая миграцию из видеопамяти в системную (и наоборот).
Во, здорово!
Похоже, что ты в этом разбираешься.
По крайней мере, ты единственный, кто сказал вумное слово "шейдер".
Что такое шейдер?
Я так понимаю, что 3Д видимокарта нужна чтобы формировать изображение в играх.
Процессор (обычный, Интел) в каком-то виде (скорее всего 3Д) формирует сцену,
а карта из этой сцены формирует картинку. То есть получается,
что видимокарта — это такой странный процессор, заточенный ровно под одну задачу.
Так что получается?
В видеодрайвере содержится специальная программа,
которая исполняется не на процессоре, а на видимокарте?
И эта программа греет видимокарту так, что карта жужжит громче процессора?
Здравствуйте, alpha21264, Вы писали:
A>Эээ... A>То есть что получается — есть секретный протокол видеокарты, и открытые протоколы OpenGL и DirectX? A>А зачем так сделано? Зачем нужен секретный протокол?
Производителей видеокарт дофига. Зачастую, когда выходит новая видюха, она поддерживает что то такое, что не поддерживают другие. Например 16к разрешение. При 128 битах на пиксель. У видюхи может быть разное назначение. Одни хайэндовые, оптимизированные по самое небалуйся. Другие дешевые, которые экономят на всем, на чем только можно, там и для шрифтов нет ускорения, и для всяких рисований кривых. Соответственно в дешевых видеокартах те операции, которая она не поддерживает на железном уровне, делаются на уровне драйвера. Это медленнее, соответственно в игрушках тянуть не будет. Но просто для просмотра инета и верстки текста пойдет. А для хайэндовских там оптимизируют протокол так, чтобы нужные задачи выполнялись как можно быстрее. И над этим думает производитель, ему не нужно черти как договариваться с остальными. Он делает оптимизации на уровне железа и затачивает под все это драйвера — и видюхой можно пользоваться и можно пользоваться новыми фичами.
A>Чем жужжит видеокарта? Я понимаю, что пропеллерами, но что она там делает своими кристаллами?
Современная видеокарта — это устройство, которое оптимизировано под задачи компьютерной графики. Там свои процессоры, своя память и т.д. По существу там процессоры общего назначения, на видеокарте можно выполнить практически любой алгоритм. Но средний классический обычный алгоритм будет медленнее в силу архитектуры, ибо средние алгоритмы заточены под CPU. А на своих задачах, когда предполагается бешенный параллелизм, когда все сводится к тому, что нужно над каждой точкой экрана одновременно вычислить какую то формулу — видеокарты на много порядков эффективнее процессоров общего назначения. Уже давно видеокарты называются не видеокартами, а GPU, на них обсчитывается не только 3d сцена, но там обраюатывается вся физика для миллионов частиц, определяются столкновения, осуществляется кодирование и декодирование видео. Там гораздо больше ядер, чем на CPU. И процессоры видеокарты сейчас гораздо сложнее, чем центральный процессор, там гораздо больше транзисторов. При работе эти процессоры греются также, как и центральный процессор, соответственно ее нужно охлаждать. Плюс видеопамять нужно охлаждать. Соответственно одна современная видюха много мощнее в определенного вида операциях, чем можно выжать из любого процессора. И топовые видеокарты соответственно и стоят черти как. Ибо на одной видюхе можно в параллель считать то, ради чего ранее требовался кластер из тысяч машин.
Соответственно кроме API для графики вроде OpenGL и DirectX, Vulkan и т.д, сейчас уже появились проприетарные стандарты, вроде CUDA, для произвольных вычислениях на видеокартах. Заточенные под одного производителя — NVidia. Есть более общие стандарты, вроде OpenMP, которые работают в том числе и на AMD видеокартах. Соответственно драйвера скрывают внутреннюю реализацию, делают компиляцию высокоуровневого кода на Си подобном языке в операции конкретной видеокарты, чем скрывают различия между различными видюхами.
Здравствуйте, Lazy Bear, Вы писали:
A>>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
LB>Мсье стебется, что ли? LB>Нужно не тебе, а ОС. Я тебе даже больше скажу: раньше жили прекрасно и без всяких операционных систем. Так зачем они нужны?
Видите ли сэр...
Когда задаётся вопрос "зачем" ответ должен начинаться со слова "затем" или "чтобы".
Ваш ответ был бы уместен, если бы я спрашивал, "Нужна ли мне эта прокладка?".
Даже формально Ваш ответ неверен.
Здравствуйте, alexsmirnoff, Вы писали:
A>А при отладке выяснил, что Автокад вообще ничем из этого не пользуется A>Выбрать перо, передвинуть в координаты, перо вверх/вниз — и всё. A>Все окружности и дуги Автокад рисовал из много-много маленьких чёрточек. A>Вот такое огорчение.
Вот!
Я подозреваю, что авторы Автокада не просто так поступили таким образом,
на первый взгляд более трудоёмким. Наверное использовать драйверы было ещё труднее.
Здравствуйте, alpha21264, Вы писали:
A>Вообще, я думаю, что причиной появления зоопарка драйверов является не защищённый режим.
Нет, причина в том, что vesa — это последний стандарт, которому еще более-менее следуют все pc-совместимые (то есть почти все) видеоплаты сейчас. При этом vesa не стандартизировало даже 2D-ускорение, не говоря про 3D.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Далее графика. Зоопарк начался с Геркулеса.
Ух эти ссуки попили крови в своё время. Была эта карточка у полутора юзеров а гемору с ней было просто атас.
Здравствуйте, alpha21264, Вы писали:
A>Во, здорово! A>Похоже, что ты в этом разбираешься. A>По крайней мере, ты единственный, кто сказал вумное слово "шейдер".
Здравствуйте, eskimo82, Вы писали:
V>>Эти драйверы (реального режима) жили и продолжают до сих пор жить в BIOS практически всех видеокарт (по крайней мере, предназначенных для IBM-, PowerPC- или MIPS Alpha- совместимых компов). E>"VBE Protected mode interface"
Брысь, школота. ))
Это уже версия 2.0, ближе к середине 90-х.
Но так-то до сих пор:
Most newer cards implement the more capable VBE 3.0 standard. Older versions of VBE provide only a real mode interface
Драйвер это граница (интерфейс) между функционалом разработчика железяки и операционкой.
Можно было бы конечно сдвинуть границу скажем на протокол взаимодействия с железякой по шинам, но это сильно ограничило бы возможности как железякоделателей, так и софтоделателей, т.к. однажды выкованное в железе менять очень сложно. Потому граница софтовая — софт менять просто.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, alpha21264, Вы писали:
A>Я подозреваю, что авторы Автокада не просто так поступили таким образом, A>на первый взгляд более трудоёмким. Наверное использовать драйверы было ещё труднее.
Во первых, в те времена драйверов не было. И разработчики чтоб выполнить простейшие операции вроде нарисовать линию и вывести Hello World корячились и реализовывали весь функционал этого рисования, зачастую бразенхеймом. Во вторых, видеокарты тогда были достаточно примитивные, и не умели даже рисовать векторные шрифты. Потому писали напрямую в видеопамять в графическом режиме. В третьих, в те времена все работало под Dos. Программа была запущена одна, и эта одна программа обращалась напрямую с устройствами ввода вывода. В четвертых, в те времена более менее стандартами были CGA, EGA, VGA, Hercules. Потом появилась Vesa и SVGA. По современным стандартам те видеокарты были примитивные до неприличия. Даже на SVGA поддерживались крайне низкие разрешения вроде 1024*768. Но даже на этих разрешениях тормозило все неимоверно. Если через VESA все делать на современной видеокарте, охрененно заметны тормоза даже на современных процессорах. Ибо фиг вам, а не аппаратный скроллинг окон. Фиг вам, а не аппаратный рендеринг шрифтов. В те времена (это уже 90-е), чтоб не тормозило все, в видеокарты добавляли 2D ускорители, в результате уже в винде все более менее шустро работало и уже лагов при скроллинге текста не было заметно. Но эти тормоза убрались как раз появилось благодаря драйверам. Ибо производителей видеокарт было до черта. Потребность чтоб не тормозил пользовательский интерфейс в виндах (а также в OS/2, линуксах) была. И производители для этого добавляли в свои видеокарты функционал, ускоряющие востребованные операции. Независимо друг от друга. И чтоб это работало, уже стали необходимы драйвера, которые стали прослойкой между GDI и железом. GDI являлось частью ОС, потому чтоб ОС могла ускорять GDI операции, нужно чтоб библиотеки прослойки между этим API и железом удовлетворяли определенным стандартам, про которые знает ОС. И таким образом появились интерфейсы драйверов, которым каждый производитель оборудования если удовлетворял, то ОС автоматом получала требуемый функционал от оборудование и ускорение, если позволяло железо. ОС менялись, и вместе с ними менялся формат драйверов. Ибо крайне сложно предугадать какие возможности потребуются в будущем, соответственно при проектировании этих интерфейсов многие потребности в ранних стандартах не учли. Плюс не забываем, что в те времена мощности железа были слабенькие по сравнению с текущими временами, и приходилось экономить каждый байт и зачастую каждый такт. Соответственно если делать в то время все суперуниверсально — это бы дико тормозило. Вспоминаем про однобайтовые кодировки, просто юникод казался огромным расточительством и т.д. Далее появилась потребность в шустрой 3D графике, потом появилась потребность в выполнении произвольных программ над каждым пикселем и над каждой вершиной, хотелки вырастали и вырастали. И также вырастают и будут вырастать.
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
Работает
A>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>Не дайте дурой помереть!
Ну вот посмотри, есть разные производили видео-карт, каждый колбасит как умеет, у каждого свои заморочки, оптимизирующие графические вычисления, и как прикладному программисту с этим жить? Под каждую видео-карту отдельный софт писать? Во-о-о-от, надо что? Правильно стандартизовать интерфейс общения прикладного ПО с видео-картой, вот этим драйвер и занимается. Это переводчик, за который отвечает производитель видео-карты.
Здравствуйте, B0FEE664, Вы писали:
BFE>Вот сколько не писал прикладного ПО — с драйвером взаимодействовать не приходилось, только с OS.
Собствено драйвера и нужны ОС чтобы реализовать некоторый API с которым уже все остальные работают.
A>Нынешний размер экрана в 6.75 раз больше того, что был в прошлом веке.
нынешние видеокарты решают другие задачи. совсем другие, вообще.
поэтому сложность, несовместимость, драйвера.
а заполнить или, там, скопировать экран — это уже на сдачу. если бы они только этим и занимались бы — разговор имел бы смысл
Здравствуйте, alpha21264, Вы писали:
A>Все говорят "если нет стандарта, значит драйвер". A>Похоже, что это превратилось в какую-то религиозную догму. A>Мантру, про которую никто не задумывается.
Не-а, чистая практика.
A>Во-первых непонятна сама логика. A>Ведь драйвер (по вашей логике) — эта некая реализация единого интерфейса. То есть стандарт. A>Тогда почему стандарт не сделан на уровне самого железа. Это же легче!
Потому что никто не пустит тебя к железу. Кто ты такой, чтобы тебя туда пускать? Юзерская программа? Вот говори, что тебе нарисовать, и тебе помогут. Когда положено.
К какому железу тебя пускать? Чтобы настроить отображение видеопамяти, надо, например, на всех PCI мостах по дороге от адаптера к корневому PCI мосту настроить окна-апертуры, и самой карточке выставить нужный адресный диапазон. Кто ты такой, чтобы иметь право этим управлять? Тебе не доверяют. А вдруг ты кусок видеопамяти на чужую память замапишь и станешь через него чужие данные читать?
А вдруг придёт какая-то системная тулза, которой нужен экран, и захочет окно своё отобразить? Ты ей будешь мешать? Нет, извини, тебе на это время доступ просто закрывают (может, невидимо), отображают что нужно, а потом снова твою картинку поднимают наверх.
A>Во-вторых ты говоришь про что? Про текстовый режим? A>Что там вообще стандартизировать-то? A>Это-ж два числа — размер по вертикали и по горизонтали — два регистра. A>Ну были в VGA эти два регистра. Пиши туда да и всё. Не надо аппаратный интерфейс менять.
А если мониторов несколько, а тебе дали только один? Куда писать будем?
A>Да, кстати, 43 и 50 строки в VGA я себе делал. Ничего сложного.
Кто бы сомневался. А теперь повтори то же самое, например, на DEC Alpha.
Там даже карточки почти такие же. Только вот никаких портов 3C0-3DF тебе не дадут, там вообще портов нет.
Зато OpenGL и все наследники — работают без проблем.
Здравствуйте, alpha21264, Вы писали:
A>Ведь драйвер (по вашей логике) — эта некая реализация единого интерфейса. То есть стандарт.
стандартов для видеокарт не существует. каждый производитель делает железку так, как считает для себя нужным. другим туда доступ закрыт.
A>Тогда почему стандарт не сделан на уровне самого железа. Это же легче!
нет, это гораздо сложнее. операционных систем больше одной. и если бы это было стандартом, то под каждую версию железки пришлось бы выпускать свою версию операционки. а если железка устарела? а если наоборот, появилась прорывная технология? здесь концепт драйверов выглядит намного более правильным. проще поменять драйвер, чем операционку.
Здравствуйте, Michael7, Вы писали:
M>Это таки было напрямую. Можно конечно считать, что драйвер был (и кстати есть, запись туда никто не отменял, если карта vga-совместима) сразу внутри платы.
Если запускали старые игры, там во многих случаях перед запуском предлагалось выбрать установленное оборудование из поддерживаемого. То есть драйвера были просто вшиты в программу (мышь, видео, звук).
Здравствуйте, alpha21264, Вы писали:
A>Тогда почему стандарт не сделан на уровне самого железа. Это же легче!
1) Потому что железо зачастую работает не благодаря, а вопреки. И сделать добавить костылей в драйвер проще, чем исправлять железку.
2) У многих железок архитектура принципиально разная, и, причём, патентованная
3) Новые фичи — как обеспечивать к ним доступ? Допустим есть сетевая карта, на которую добавили TCP Offload. Если убрать драйвер, то воспользоваться этой фичей смогут только приложения, скомпилированные с новой версией библиотеки. При наличии же прослойки она доступна для всех приложений.
4) Кооперативный доступ: говорить о прямом доступе к железу можно было только в однозадачной среде.
A>Это-ж два числа — размер по вертикали и по горизонтали — два регистра.
Э... а указатель на шрифт для знакогенератора?
A>Да, кстати, 43 и 50 строки в VGA я себе делал. Ничего сложного.
Зато как только вы переходите в графический режим, сразу начинаются приключения: от нестандартной карты видеопамяти (CGA, EGA) до проблем, возникающих при превышении видеопамятью размера сегмента (Hello VESA).
Здравствуйте, Pzz, Вы писали:
V>>Впервые по-настоящему неплохо подобную абстракцию реализовала подсистема Windows GDI. В появившемся значительно позже OpenGL хорошо видно, что приличную часть идей они тупо утянули у GDI. )) Pzz>Вот и пришло оно, новое поколение, не знающее истории собственной индустрии.
С ума сошёл? ))
Pzz>OpenGL идет от компьютеров Silicon Graphics, и появился в 1992 году.
Практически в сегодняшнем виде GDI появилось на 5 лет раньше.
Pzz>OpenGL — это такой способ писать програмки на универсальном языке, которые могут исполняться процессором видеокарты.
У-у-у, пошли городские легенды. ))
OpenGL с первой же версии вышел как набор обычных структур и ф-ий, описанных на С.
Pzz>Windows GDI же — это встроенный в систему набор графических примитивов (типа "нарисуй линию" и т.п.). Совершенно разные подходы.
Нет в GDI такого, не вводи в заблуждение.
Есть возможность последовательного вызова "черепашки" (MoveTo'Ex, LineTo), либо подать массив координат.
В OpenGL в точности аналогично — можно рисовать кривую через последовательность команд по одной на каждую вершину, либо можно за один раз подать набор вершин для ломанной.
======================
Основная задача при программировании на АПИ подобного рода — это управление ресурсами.
До GDI об управлении ресурсами речи не шло.
Там было, действительно, примерно так: "нарисуй мне линию".
В GDI стало по-другому — появились ресурсы, их можно было создавать, многократно повторно использовать в операциях, кидать на "канвас" и они влияли на результат вызываемых затем ф-ий драйвера (при движении "черепашки", например) и т.д.
Сам "канвас" тоже стал ресурсом и одновременно абстракцией.
Так вот, в OpenGL поступили в точности аналогично GDI — "канвас" сделали абстракцией, и точно так же на него можно было накидать ресурсов (в терминах этих АПИ — "выбрать объект"), которые влияли на происходящее.
Ресурс — это ж не только битмпы.
Хотя, модель DIB, опять же, впервые более-менее развилась именно в АПИ виндов.
Собсно, именно через Винды битмапы стали битмапами в современном понимании.
Тут OpenGL тоже в хвосте всегда плелась.
Здравствуйте, netch80, Вы писали:
A>>А теперь, когда вы уже обратили внимание на провокационный заголовок, A>>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
N>Показывает 25-й кадр.
А остальные 24 кадра кто показывает?
ЗЫ.
Кстати, чё-то плохо он 25 кадр показывает. Я его вижу.
Здравствуйте, alpha21264, Вы писали:
LB>>Это прокладка между вашим прикладным уровнем и неизвестной ему железкой
A>Такие бессмысленные слова я тоже умею говорить.
A>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
Мсье стебется, что ли?
Нужно не тебе, а ОС. Я тебе даже больше скажу: раньше жили прекрасно и без всяких операционных систем. Так зачем они нужны?
Здравствуйте, alpha21264, Вы писали:
A>А теперь, когда вы уже обратили внимание на провокационный заголовок, A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
Реализует вызовы стандартного API (например OpenGL, DirectX) используя проприетарный протокол, специфичный для видеокарты.
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах. A>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>Не дайте дурой помереть! A>
это будет очень грубая аналогия, зато наглядная
видеокарта в твоем компе — это еще один комп(до чего дошел прогресс)
и у разных производителей эти компы разные. ну как будто у тебя pc, а внутри его видеокарта-pc. а может видеокарта-мак. а может вообще видеокарта бэкашка(для тех, у кого денег мало). хуже того, в погоне за скоростью один и тот же производитель новые видеокарты делает несовместимыми со старыми. драйвер от тебя все эти несовместимости прячет — ты для разных видеокард код не пишешь. тебе для твоих задач, наверное, оно не надо — тебе бы хватило vga. но специально под тебя никто видюху-делать не будет, у всех уже стоит сложная видюха-комп, так что придется тебе с этим фактом жить.
p.s. если стало интересно, описание архитектур этих компов вполне можно скачать
Здравствуйте, alpha21264, Вы писали:
LB>>Это прокладка между вашим прикладным уровнем и неизвестной ему железкой
A>Такие бессмысленные слова я тоже умею говорить. A>Зачем мне эта прокладка? Я прекрасно жил без неё и сейчас время от времени без неё живу.
Ну вот возьмём времена MS-DOS. Работу в текстовом режиме 80*25 умели все видеокарты — это дефолт со времён MDA. А вот некоторые видяхи поумнее умели аж 135 колонок рисовать. Для этого наша прога должна уметь понимать поддерживается ли этот режим, и если да, то знать как в него перейти. И строк чтоб не 25 а побольше, сказали юзера. Ну ладно, сказали производители... В итоге имеем в каждой независимой софтине эдакую экспертную систему, которая знает на каких видяхах как работать с текстом (что характерно, регулярно нужны апдейты, иначе новейшая видяха с крутейшим монитором будет юзаться в самом кислом режиме, без раскрытия всего потенциала). Вот если бы ОС умела сама нам сказать список поддерживаемый текстовых режимов и абстрагировала переключение в них...
Далее графика. Зоопарк начался с Геркулеса. Нет-нет, не того древнего качка-бодибилдера (хотя нет, бодибилдером был Апполон, Геркулес был скорее стронгмэн). Hercules — это был видеоадаптер такой, весь из себя нестандартный. Ну а далее покатилось: CGA, EGA, VGA, зоопарк SVGA-режимов. Если бы VESA-консорциум вовремя не опомнился, введя стандарт на API видеоадаптера, всем было бы очень весело... ОС вздохнула и решила что в этот раз не отвертеться. И приказала "ВСЕМ РИСОВАТЬ ДРАЙВЕРА!"
Здравствуйте, GarryIV, Вы писали:
A>>Кстати, чё-то плохо он 25 кадр показывает. Я его вижу. GIV>А 26ой?
А 26-го нет.
Эффект поймался на старо-советском фильме "Трактористы".
После того как председатель колхоза говорит
"Трактор, это танк, а танк — это УУУУУ!"
Появляется ОДИН КАДР на котором изображён танк Т-28.
Дальше показывают различные трюки танки БТ-5 и БТ-7.
Так вот, этот танк Т-28 отлично виден.
Здравствуйте, vsb, Вы писали:
A>>А теперь, когда вы уже обратили внимание на провокационный заголовок, A>>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
vsb>Реализует вызовы стандартного API (например OpenGL, DirectX) используя проприетарный протокол, специфичный для видеокарты.
Эээ...
То есть что получается — есть секретный протокол видеокарты, и открытые протоколы OpenGL и DirectX?
А зачем так сделано? Зачем нужен секретный протокол?
Чем жужжит видеокарта? Я понимаю, что пропеллерами, но что она там делает своими кристаллами?
A>Совсем-то откровенную фигню писать не надо. A>Чтобы на экране написовать точку нужно отправить байт в определённое место памяти.
если она доступна
вот правда, она всегда доступна?
а если доступна, скорость доступа хорошая? или раз в 100 медленнее, чем у проца на видюхе?
A>И Линукс и Винда именно это и делает, когда никакой драйвер ещё не установлен или не стартовал. A>Пингвин, которого рисует Линукс при старте, пишется непосредственно в память процессором.
а потом меняет режим и я опять задаю те же вопросы
Немного оффтоп, но навеяло воспоминаний.
В стародавние времена пришлось писать драйвер для перьевого плоттера под досовский Автокад.
Я, как путный Вася, изучил документацию, все плоттерные плюшки — он и штриховку умел, не говоря о примитивах типа окружностей — всё воплотил, реализовал.
А при отладке выяснил, что Автокад вообще ничем из этого не пользуется
Выбрать перо, передвинуть в координаты, перо вверх/вниз — и всё.
Все окружности и дуги Автокад рисовал из много-много маленьких чёрточек.
Вот такое огорчение.
Здравствуйте, alpha21264, Вы писали:
A>И Линукс и Винда именно это и делает, когда никакой драйвер ещё не установлен или не стартовал.
про линух не знаю, а в винде стоит драйвер по умолчанию. и не уверен я, что тебе в защищенном режиме разрешать писать в память, которая не мапится в твое адресное пространство, то есть в видеопамять.
Здравствуйте, alpha21264, Вы писали:
A>>>А теперь, когда вы уже обратили внимание на провокационный заголовок, A>>>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
vsb>>Реализует вызовы стандартного API (например OpenGL, DirectX) используя проприетарный протокол, специфичный для видеокарты.
A>Эээ... A>То есть что получается — есть секретный протокол видеокарты, и открытые протоколы OpenGL и DirectX?
Да.
A>А зачем так сделано? Зачем нужен секретный протокол?
Ну видимо так получилось. К тому же это удобно. У Apple Metal. В Linux X Server, Wayland. В Windows DirectX, возможно ещё какой-то протокол, через который GDI рисует, точно не знаю. У всех есть OpenGL. Реализовывать всё это внутри видеокарты сложно и не нужно, проще вынести отдельным компонентом в виде драйвера ОС. Есть стандартные открытые протоколы вроде VGA, но они распространения не получили, видимо на то были причины. Если убедишь всех производителей ОС перейти под Vulkan, например, возможно лет через 20 после этого он станет нативным протоколом для большинства видеокарт и отдельный драйвер для ОС станет не нужен.
A>Чем жужжит видеокарта? Я понимаю, что пропеллерами, но что она там делает своими кристаллами?
Не знаю, у меня ничем не жужжит. Может какие-то неисправные электронные компоненты? Говорят, дроссели могут издавать звуки.
Здравствуйте, vdimas, Вы писали:
_>>наоборот, олдскульный системщик. под досом не было никаких видеодрайверов и видеопамять тупо мапилась в общее адресное пространство.
V>А потом появилась SVGA/VESA и всё резко изменилось.
Вот хотелось бы узнать, что изменилось и почему. И как оно сейчас.
Потому что то, что есть сейчас мне напоминает один старинный анекдот.
Однажды собрались астрономы и стали рассуждать об птолемеевых эпициклах.
Король испанский Альфонс II пошутил, что он бы посоветовал богу сотворить вселенную попроще.
Здравствуйте, alpha21264, Вы писали:
V>>А потом появилась SVGA/VESA и всё резко изменилось.
A>Вот хотелось бы узнать, что изменилось и почему. И как оно сейчас.
изменилось то, что в процессорах появился защищенный режим и никто тебе не разрешит писать в видеопамять напрямую.
Здравствуйте, zverjuga, Вы писали:
V>>>А потом появилась SVGA/VESA и всё резко изменилось.
A>>Вот хотелось бы узнать, что изменилось и почему. И как оно сейчас.
Z>изменилось то, что в процессорах появился защищенный режим и никто тебе не разрешит писать в видеопамять напрямую.
Ой да ладно. В Линуксе Framebuffer почти так и работает.
Вируальные адреса, правда могут не соответствовать физическим,
но тем не менее пишешь как в массив пиксель за пикселем.
В Виндах, наверное тоже так можно.
Вообще, я думаю, что причиной появления зоопарка драйверов является не защищённый режим.
Здравствуйте, vsb, Вы писали:
vsb>Есть стандартные открытые протоколы вроде VGA, но они распространения не получили, видимо на то были причины. Если убедишь всех производителей ОС перейти под Vulkan, например, возможно лет через 20 после этого он станет нативным протоколом для большинства видеокарт и отдельный драйвер для ОС станет не нужен.
VGA поддерживается биосом, и это очень хорошо.
То есть любая ОС на любой видеокарте необходимый минимум (текст или 800*600) покажет.
Если это сервер — за глаза достаточно.
Интересно, почему нет аналогичной поддержки сети.
Здравствуйте, alpha21264, Вы писали:
A>>А при отладке выяснил, что Автокад вообще ничем из этого не пользуется A>>Выбрать перо, передвинуть в координаты, перо вверх/вниз — и всё. A>>Все окружности и дуги Автокад рисовал из много-много маленьких чёрточек.
A>Я подозреваю, что авторы Автокада не просто так поступили таким образом, A>на первый взгляд более трудоёмким. Наверное использовать драйверы было ещё труднее.
Думаю, в те былинные времена драйверов просто не было.
Акад тупо заюзал самый общий АПИ, который поддерживался большинством плоттеров, ибо поддерживать все возможные модели — проще удавиться.
А по уму Акад должен был давать команды "нарисовать линию", "нарисовать дугу", а драйвер бы превращал эти команды либо в "много-много маленьких чёрточек", либо напрямую отправлял в железку.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, alpha21264, Вы писали:
A>Мы немного ушли от первоначальной темы — видеодрайверов.
Не, просто разбираем более близкий нам аналог.
A>Чтбы Автокад мог так делать, нужно чтобы был какой-то стандарт A>на эти функции "нарисовать линию", "нарисовать дугу". A>Чтобы все плоттеры выполняли эти команды и не сходили с ума.
Вот этого стандарта и не существует (не существовало). А есть железки, и у каждой свой интерфейс.
Драйвер приводит все железки к общему знаменателю.
A>Но тогда совсем непонятно, зачем нужен драйвер. A>Чтобы превратить высокоуровневую команду в массив низкоуровневых, A>нужен не драйвер, а библиотека. Собственно Автокад так и поступил.
Да как ни назови — библиотека или драйвер, это всё один и тот же элемент абстракции (Адаптер).
Плюс драйвер, в отличие от библиотеки, может являться синглетоном.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, alpha21264, Вы писали:
A>>Эээ... A>>То есть что получается — есть секретный протокол видеокарты, и открытые протоколы OpenGL и DirectX? A>>А зачем так сделано? Зачем нужен секретный протокол? E>Производителей видеокарт дофига.
Было когда-то. Было что даже дорабатывали фирменные чипсеты и свои драйвера выпускали.
Сейчас осталось не дофига, а фактически три-четыре производителя: Nvidia, AMD (встроенные и отдельные) и Intel для встроенных. В принципе еще Matrox есть для совсем странных людей Все.
Здравствуйте, alpha21264, Вы писали:
A>Что такое шейдер?
Просто специальная программа, которая исполняется на GPU.
A>Так что получается? A>В видеодрайвере содержится специальная программа, A>которая исполняется не на процессоре, а на видимокарте?
Именно так.
A>И эта программа греет видимокарту так, что карта жужжит громче процессора?
Ага.
V>Эти драйверы (реального режима) жили и продолжают до сих пор жить в BIOS практически всех видеокарт (по крайней мере, предназначенных для IBM-, PowerPC- или MIPS Alpha- совместимых компов).
"VBE Protected mode interface"
V>Помимо этого появилось еще несколько абстракций, но уже заточенных под разные сценарии: V>- сценарии удалённого графического адаптера; V>- сценарии локального графического адаптера для защищённого режима процессоров.
V>Например, OpenGL, если взглянуть на него внимательней, писался исключительно под защищёный режим.
V>Впервые по-настоящему неплохо подобную абстракцию реализовала подсистема Windows GDI. В появившемся значительно позже OpenGL хорошо видно, что приличную часть идей они тупо утянули у GDI. ))
CC>Это для текстового режима. Для графики надо было мудохаться как проклятому. Хреначить магические константы в магические регистры, которые далеко не везде работали одинаково.
Не то чтобы мудохаться, но переключать мапинг цветовых плоскостей на память было нужно. Ну и цвет задавался битами в определенных плоскостях — не так как теперича одной чиселкой для RGB.
Здравствуйте, alpha21264, Вы писали:
A>То есть что получается — есть секретный протокол видеокарты, и открытые протоколы OpenGL и DirectX?
Примерно как есть машинный код, свой у каждой архитектуры и есть python
Здравствуйте, Stanislav V. Zudin, Вы писали: SVZ>Думаю, в те былинные времена драйверов просто не было.
Совершенно верно. В былинные времена операционная система на себя не брала ничего, кроме абстракций ввода-вывода на диск.
Каждая приличная программа тащила с собой умение печатать на принтерах из списка, и рисовать на плоттерах из списка. SVZ>Акад тупо заюзал самый общий АПИ, который поддерживался большинством плоттеров, ибо поддерживать все возможные модели — проще удавиться.
Скорее всего, они тупо использовали HP-GL. SVZ>А по уму Акад должен был давать команды "нарисовать линию", "нарисовать дугу", а драйвер бы превращал эти команды либо в "много-много маленьких чёрточек", либо напрямую отправлял в железку.
Вот именно так работает современная ОС. Вы рисуете на Device Context; драйвер принтера превращает это в пикселы, драйвер плоттера — в команды LineTo/MoveTo, а драйвер видео превращает это в последовательность команд по управлению видеоадаптером.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, CreatorCray, Вы писали:
CC>BIOS занимается начальным конфигурированием видеокарты, чтоб туда можно было что то рисовать пока нормальная ОС не стартанула.
Дурацкий вопрос, но где про этот процесс можно детальнее почитать. Взаимодействие биос и карты на старте.
Здравствуйте, 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>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах.
От ОС не зависит...
Для разнообразия — поставь линукс сервер и попробуй какую-нибудь картинку нарисовать на экране
Здравствуйте, Dym On, Вы писали:
A>>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>>Не дайте дурой помереть! DO>Ну вот посмотри, есть разные производили видео-карт, каждый колбасит как умеет, у каждого свои заморочки, оптимизирующие графические вычисления, и как прикладному программисту с этим жить? Под каждую видео-карту отдельный софт писать? Во-о-о-от, надо что? Правильно стандартизовать интерфейс общения прикладного ПО с видео-картой, вот этим драйвер и занимается. Это переводчик, за который отвечает производитель видео-карты.
Вот сколько не писал прикладного ПО — с драйвером взаимодействовать не приходилось, только с OS.
Здравствуйте, 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 в поток команд конкретного драйвера.
CC>Я вот времена когда приходилось под каждую видюху свой код писать и её глюки отслеживать и поддерживать вспоминаю с содроганием.
Как будто сейчас что-то поменялось.
Никогда не встречал игр, работающих только на Nvidia? Или не работающих на Radeon? Их полно.
Здравствуйте, eskimo82, Вы писали:
MD>>А вот некоторые видяхи поумнее умели аж 135 колонок рисовать. Для этого наша прога должна уметь понимать поддерживается ли этот режим, и если да, то знать как в него перейти. E>но некоторые могли в него переходить согласно пожеланию юзера.
Правильно, но как это сделать? На одной видяхе для этого надо записать значение 123 в порт 456, на другой видяхе — дёрнуть int78 с параметром 90
в регистре Ah, и так далее, и тому подобное. Повторю ещё раз: стандарта — не было. Вот совсем.
Здравствуйте, Mr.Delphist, Вы писали:
MD>>>А вот некоторые видяхи поумнее умели аж 135 колонок рисовать. Для этого наша прога должна уметь понимать поддерживается ли этот режим, и если да, то знать как в него перейти. E>>но некоторые могли в него переходить согласно пожеланию юзера.
MD>Правильно, но как это сделать? На одной видяхе для этого надо записать значение 123 в порт 456, на другой видяхе — дёрнуть int78 с параметром 90 MD> в регистре Ah, и так далее, и тому подобное. Повторю ещё раз: стандарта — не было. Вот совсем.
Все говорят "если нет стандарта, значит драйвер".
Похоже, что это превратилось в какую-то религиозную догму.
Мантру, про которую никто не задумывается.
Во-первых непонятна сама логика.
Ведь драйвер (по вашей логике) — эта некая реализация единого интерфейса. То есть стандарт.
Тогда почему стандарт не сделан на уровне самого железа. Это же легче!
Во-вторых ты говоришь про что? Про текстовый режим?
Что там вообще стандартизировать-то?
Это-ж два числа — размер по вертикали и по горизонтали — два регистра.
Ну были в VGA эти два регистра. Пиши туда да и всё. Не надо аппаратный интерфейс менять.
Да, кстати, 43 и 50 строки в VGA я себе делал. Ничего сложного.
CC>Раз уж ты влез отвечать на заданный вопрос — будь любезен отвечать на заданный вопрос. CC>
С указанием что на чём не работает, если можно.
Я ответил тебе на заданый вопрос. То что ты не в состоянии прочитать ответ или принять его — это твои и только твои проблемы.
CC>Голоса в твоей голове меня не интересуют.
Если ты слышиш "голоса в моей голове", то тебе следует сходить на прием к психиатору.
CC>Так где тот самый список игр?
Довольствуйся для начала списком исключительных и частенько несовместимых особенностей.
Когда его изучиш вернемся к играм.
хорошо, добавим комментариев:
E>И вариант без VESA на любой карточке: E>
E>void main(int argc, char *argv[])
E>{
E> int mode;
E> if (argc != 1)
E> printUsage(); // в SVGA-версии тут было availableModes() - т.е. получение списка всех (всех, Карл!!111) доступных видеорежимов для любой SVGA-карточки, хоть современного GeForce
E> else {
E> mode = atoi(argv[1]);
E> bios_setup_mode(mode); // в каждом видео-биосе нестандартные режимы включаются по-разному; поэтому что должно быть в этой функции? какой длины будет этот код? смотрим стр.79 из VESA-стандарта для сравнения
E> drawMoire(); // мэппинг видеопамяти в знакоместа на экране - как? ведь единого стандарта ещё не было; опять же, сравниваем с VESA-стандартом и рыдаем или хихикаем, по желанию
E> getch();
E> }
E>}
E>
Повторю требование — Стандарт это унификация и краткость (а не "описание болезни", как мы имеем в случае с JS-макаронами)
Здравствуйте, CreatorCray, Вы писали:
CC>>>Где там хоть одна игра, про которую ты заявил? E>>Во первых, я про игры не заявлял. CC>Наглое гонево!
CC>Re[4]: Драйверы — зло и лишний элемент!
Здравствуйте, netch80, Вы писали:
N>Ты действительно считаешь, что eskimo82 и ? — один человек?
Раз уж он взялся отвечать — пусть будет так любезен отвечать на заданный вопрос, а не голосам в своей голове.
CC>Раз уж он взялся отвечать — пусть будет так любезен отвечать на заданный вопрос, а не голосам в своей голове.
Я тебе ответил на заданый вопрос. Чем ты так недоволен ? Нежданный ответ нарушающий вселенную голосов у тебя голове ?
Здравствуйте, eskimo82, Вы писали:
CC>>Ты уже составил список игр? E>А ты уже изучил расширения NV ?
Я их изучал лет 15 назад, когда работал в gamedev.
Итак, где же те игры, которые ну никак не идут на одной из карточек?
Здравствуйте, eskimo82, Вы писали:
CC>>Раз уж он взялся отвечать — пусть будет так любезен отвечать на заданный вопрос, а не голосам в своей голове. E>Я тебе ответил на заданый вопрос.
Вопрос был про список игр, работающих только на одной из карт.
Не про список extensions а про конечный продукт — игры.
CC>>>Ты уже составил список игр? E>>А ты уже изучил расширения NV ? CC>Я их изучал лет 15 назад, когда работал в gamedev.
Те, про которые я указал, 15 лет назад не было, они 2-3 летней давности от силы.
CC>Итак, где же те игры, которые ну никак не идут на одной из карточек?
Как только изучишь расширения.
E>>Я тебе ответил на заданый вопрос. CC>Вопрос был про список игр, работающих только на одной из карт. CC>Не про список extensions а про конечный продукт — игры.
В вопросе был вопрос
Здравствуйте, const_volatile, Вы писали:
_>а до этого были времена, когда с видюхой можно было общаться командой out из приложения, минуя системное api. и было всего 3 типа видеокарт — CGA, EGA и VGA.
Так это и была реализация функций драйвера внутри приложения.
Здравствуйте, Cyberax, Вы писали:
C>В x86 он отображался полностью железно — на схеме реально стоял компаратор, который отправлял запросы в ROM карты при совпадении. Все смещения, насколько я помню, были статические. Т.е. при замене видеокарты там появлялся новый код.
Следует еще вспомнить, что этот код умел так мало, и работал так медленно, что в реальной жизни никто его и не использовал.
Здравствуйте, alpha21264, Вы писали:
A>расскажите о том, что делает видео-драйвер в "нормальной операционной системе" в Виндах. A>Всю жисть писал программы прикладного уровня, а теперь вот заинтересовался. A>Не дайте дурой помереть!
Видеокарт разных больно много развелось. Неохота, чтобы каждая программа, которой надо порисовать на экране, была вынуждена знать особенности всех видеокарт. Это с одной стороны. А с другой, хочется, чтобы производители видеокарт при появлении нового железа могли приделать что-то к операционной системе так, чтобы все программы научились пользоваться этим новым железом, без необходимости со стороны авторов программ предпринимать какие-то усилия.
Здравствуйте, vdimas, Вы писали:
V>Впервые по-настоящему неплохо подобную абстракцию реализовала подсистема Windows GDI. В появившемся значительно позже OpenGL хорошо видно, что приличную часть идей они тупо утянули у GDI. ))
Вот и пришло оно, новое поколение, не знающее истории собственной индустрии.
OpenGL идет от компьютеров Silicon Graphics, и появился в 1992 году. OpenGL — это такой способ писать програмки на универсальном языке, которые могут исполняться процессором видеокарты. Windows GDI же — это встроенный в систему набор графических примитивов (типа "нарисуй линию" и т.п.). Совершенно разные подходы.
Здравствуйте, alpha21264, Вы писали:
A>Ведь драйвер (по вашей логике) — эта некая реализация единого интерфейса. То есть стандарт. A>Тогда почему стандарт не сделан на уровне самого железа. Это же легче!
А почему компилятор не сделан на уровне самого железа? Казалось бы, пусть в процессоре будет регистр, куда можно писать C++ в utf-8, а он пусть уж сам разбирается, как этот код исполнять...
К сожалению, сложновато пока сделать приемлимый аппаратный интерфейс видеокарты, позволяющих делать то, что делают современные видеокарты — разгружать центральный процессор от задач, связанных с графикой.
Здравствуйте, alpha21264, Вы писали:
A>Так что получается? A>В видеодрайвере содержится специальная программа, A>которая исполняется не на процессоре, а на видимокарте? A>И эта программа греет видимокарту так, что карта жужжит громче процессора?
Здравствуйте, Pzz, Вы писали:
Pzz>Так очень медленно. У меня, например, на компутере средней руки видимая область экрана — это примерно 19 МБ (два монитора 1980x1200). Если обновлять их 25 раз в секунду, то придется гнать по шине почти полгига в секунду.
Если разнести по разным видюхам, то разнесешь по разным шинам.
Pzz>Это и сейчас дофига, а не так давно шина столько просто не умела.
Верно, поэтому изначально PCI-картейки забирали для себя 4, 8 или даже 16 шин.
Pzz>Это при том, что эти полгига надо еще откуда-то взять, что изрядно загрузит процессор.
При программном декодировании видео так и есть.
Правда, FULL HD чуть другой — 1920x1080, т.е. заметно меньше, чем ты назвал.
Но так-то да, слабые процы не справляются.
Pzz>Поэтому индустрия пришла к тому, что видеокарта стала универсальным вычислителем, который эти данные и вычисляет, исполняя загруженные в него программы.
Если бы не было такого бардака с графическими стандартами, которые есть сейчас и на фоне этого не было бы такой плачевной ситуации с драйверами под видеокарты в тех же линухах, о фрейм-буфере никто бы не говорил.
Но имеем что имеем. ))
Pzz>Так что пиксель за пикселем в реальной жизни никто не пишет.
Еще как пишут.
Собсно, любой мессенджер при показе видео формирует его программно и гонит кадры на видюху.
Здравствуйте, alpha21264, Вы писали:
A>По крайней мере, ты единственный, кто сказал вумное слово "шейдер".
Шейдер совершенно не обязателен для 3D.
A>Что такое шейдер?
Это юзверский код, исполняемый на картейке.
Например, пиксельный шейдер (он же фрагментный шейдер) вычисляет цвет всего одной точки (фрагмента), но картейка запускает шейдеры в параллель (сколько может).
Причём, рисование даже линий/кривых при таком подходе становится нетривиальной задачей. ))
Необходимо выяснить, принадлежит ли данный пиксель кривой: http://glslsandbox.com/e#49567.0
Аргументы шейдера по ссылке:
gl_FragCoord — координаты пикселя;
gl_FragColor — результирующий цвет пикселя;
resolution — разрешение сцены;
time — текущее время.
С т.з. шейдера его "аргументы" — это статические переменные.
Первые две переменные уникальные для экземпляра шейдера, следующие два общие для всех шейдеров и являются "прикладными" — они введены OpenGL SL JS-кодом страницы.
(ага, кол-во аббревиатур зашкаливает) https://developer.mozilla.org/en-US/docs/Games/Techniques/3D_on_the_web/GLSL_Shaders
A>что видимокарта — это такой странный процессор, заточенный ровно под одну задачу.
Да, примерно так.
Это такой специальный процессор, в котором один указатель команд и еще куча блоков, управляющих вычислениями, делится м/у кучей АЛУ.
Получается эдакая иерархия вычислительных блоков.
Т.е. один вычислительный блок самого нижнего уровня выполняет ровно ту же программу, что и другие вычислители в этом же блоке.
Они все работают синхронно, но обрабатывают разные данные.
Таких групп вычислителей тем больше (и кол-во АЛУ в каждом блоке), чем "мощнее" картейка.
Пример пиксельного шейдера — самый демонстрационный для таких вещей.
К тому же, в пиксельные шейдеры можно загнать собственный 3D-движок: https://www.shadertoy.com/view/4ttSWf
))
