Page 8 of 17
Re: Оптимизация ядерной графики
Posted: Wed May 18, 2011 8:52 am
by Serge
Из памяти видеокарты в буфер приложения ?
Да.
Полилайны будут. И эллипсы тоже. Только без закраски!!
Закраска эллипсов нужна. Без неё плохо.
Re: Оптимизация ядерной графики
Posted: Wed May 18, 2011 5:58 pm
by art_zh
Serge
Дык это же не от системы зависит, а от устройства?
Как читать MMIO в винде - я к стыду своему так и не въехал в WDM, а напрямую нельзя.
В линуксе тоже нельзя напрямую, для этого надо вешать самодельный драйвер kernel unit, который из Ring0 сможет вызвать ioremap и отобразить адрес на юзерспейс.
Проще всего у нас (даже неинтересно рассказывать) - достаточно компильнуть ядро, поставив bdf-адрес видеокарты в переменную mmio_pci_addr (33-я строчка в /bus/pci/pci32.inc).
После этого можно будет прочитать видеопамять с помощью mcall 62,12 как в pcidev (кусок после Try_MMIO: сейчас он сканирует все BARы, но его легко можно переделать под конкретный BAR фреймбуфера).
Поменяй код в дампе - возьми блок пошире и засеки время прочтения.
Но сдается мне что ты все-таки что-то другое хотел спросить, ?
Про DMA/burst-режимы чтения видеобуфера я ничего сказать не могу. Реализовать режим захвата шины схемотехнически очень легко. Тут разработчики железа отрываются кто как хочет: у каждого устройства - своя регистровая модель DMA, стандарта нет. Но ты это тоже лучше меня знаешь. Тогда о чем вопрос?
Re: Оптимизация ядерной графики
Posted: Thu May 19, 2011 4:27 pm
by Serge
Нет, я копирование экрана штатными средствами GDI.
Re: Оптимизация ядерной графики
Posted: Thu May 19, 2011 5:19 pm
by art_zh
A-a.
Ну тут у нас ничего кроме тормознутых fn 35 и 36 нет.
А что, кому-то нужен быстрый getbitmap?
А на какой номер новые примитивы (для начала - эллипс и полигон, потом может и сплайны / безье кто добавит) лучше повесить?
Мне видятся два варианта:
1) sysfn 74 (73-й номер уже окончательно забит?)
2) использовать древний номер 19
Re: Оптимизация ядерной графики
Posted: Fri May 20, 2011 8:22 am
by Gluk
почему в голосовании нет варианта "заменить графический на текстовый режим"?)
Re: Оптимизация ядерной графики
Posted: Fri May 20, 2011 9:54 am
by art_zh
Gluk
потому что зачем.
Re: Оптимизация ядерной графики
Posted: Fri May 20, 2011 10:01 am
by maximYCH
Почему нет варианта вырезать всю графику из ядра полностью?
Выделить в библиотеки и драйверы в смысле
Re: Оптимизация ядерной графики
Posted: Fri May 20, 2011 10:01 am
by yogev_ezra
Gluk wrote:почему в голосовании нет варианта "заменить графический на текстовый режим"?)
Если перефразировать CleverMouse: "У нас уже есть одна операционная система, выглядящая как DOS, - это DOS"
Re: Оптимизация ядерной графики
Posted: Sat May 21, 2011 4:16 pm
by Gluk
yogev_ezra, то есть Колибри отличается от остальных ОС только своим интерфейсом?
Если портировать гр. инт. Колибри под линукс, такой линукс станет Колибри?
Re: Оптимизация ядерной графики
Posted: Sat May 21, 2011 4:31 pm
by Mario
И понесся флуд и оффтоп и возрыдали сирые форума сего...
Re: Оптимизация ядерной графики
Posted: Sat May 21, 2011 5:13 pm
by Gluk
Mario, в моем сообщении трижды упоминается Колибри, и дважды графика (см. заголовок темы), для двух строчек это достаточно много
Re: Оптимизация ядерной графики
Posted: Sat May 21, 2011 7:48 pm
by Mario
Твой первый пост отклоняется от темы в провоцирующее русло "Давайте отрежем Сусанину ногу...", а тема насчет оптимизации GUI, а не замены его на что-то. Колибри исторически сложилась (в наследии от Menuet) как ОС с GUI. Вопрос об отделении GUI от ядра уже обсуждался в других темах форума.
Я думаю не имеет смысла опять все в одну кучу сваливать. В конечном счете если бы кто-то действительно хотел сделать Колибри с текстовым режимом вместо GUI, то он бы это сделал или нет?
Re: Оптимизация ядерной графики
Posted: Mon May 23, 2011 8:38 am
by VaStaNi
art_zh wrote:А на какой номер новые примитивы
не только примитивы, но и саму GUIшку "вынес" бы в виде отдельного апи, например, типа int 0x50
(вот в биосе int 0x10 существует целевым назначением и это хорошо ведь).
Зачем все на 40 все лепить?
Куда их экономить то, вектора эти, не вижу прока.
А вот тематическо-функциональное разделение мне кажется уместным, особенно в свете новых технологий, редакций, принципиально нового движка и т.д...
Дабы не было крика про поддержку "старого" GUI, вещи касательно 40вых дел можно ведь и не трогать, оставив на "пока", вполне возможно атрофируются сами со временем..., как проигравшая технология GUI.
Re: Оптимизация ядерной графики
Posted: Mon May 23, 2011 2:58 pm
by CleverMouse
VaStaNi, быстрые системные вызовы sysenter и syscall имеют только одну точку входа.
Кроме того, вы, похоже, не прочли или не осознали пост, на который отвечаете, - в посте речь шла о создании нескольких новых примитивов, а отнюдь не о переносе или замене существующих.
Re: Оптимизация ядерной графики
Posted: Mon May 23, 2011 4:12 pm
by art_zh
VaStaNi
Столь радикальные изменения подразумевают смену соглашения о порядке передачи параметров в ядро ?
Если нет - тогда зачем менять шило на мыло? int40 - это пусть забавный, но все-таки не самый идиотский вариант.
Если да - тогда надо глубоко продумать альтернативный механизм, иначе можно что-то еще смешнее накостылять.
Ради эллипса конечно не стоит огород городить, а вот для парсера очередей GUI-запросов - вполне.
CleverMouse
fastcall и syscall оказались малоэффективной заменой для int40, их можно безболезненно убрать из макроопределения
mcall. А потом - и из ядра. Полгода
ругани - и всё забудется...
Для syscall заметное (до трех раз!) ускорение входа в Ring0 достигается только если не переключать стек задачи, и не использовать ecx для передачи параметров. А еще лучше - передавать все параметры в стеке.
Но это, в сущности, и определяет некий новый API-механизм, к которому можно будет приклеить и соответствующий fastcall, и int50.