Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт май 25, 2017 12:20 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 30 сообщений ]  На страницу Пред. 1 2
Автор Сообщение
 Заголовок сообщения: Re: Ядро - концепция работы
СообщениеДобавлено: Чт янв 28, 2010 9:08 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
[вопрос снят. Спасибо]


Последний раз редактировалось art_zh Чт янв 28, 2010 10:49 pm, всего редактировалось 1 раз.

Вернуться к началу
СообщениеДобавлено: Чт янв 28, 2010 10:42 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
andrew_programmer писал(а):
Я прекрасно помню, что diamond противник вынесения какой-либо графики из ядра.
А ещё есть сторонники идеи,"Нечего засорять ядро всяким гов**м". Попробуйте найти компромисное решение, удовлетворяющее и первым, и вторым....

Пожалуйста, пусть графика будет не в ядре, а в драйвере, пусть даже вместо кучи системных вызовов для обработки GUI и окон будет один системный вызов типа "вызвать функцию из GUI под номером ebx" (как вариант, два вызова - для GUI и для оконных функций), мне лично пофиг. Пока графическая подсистема а) не требует лишних переключений колец защиты, б) не требует лишних переключений контекста, в) способна исполняться более или менее параллельно при параллельных вызовах из разных приложений (по модулю, естественно, необходимых блокировок при работе с разделяемыми ресурсами), эффективность работы не изменится никак. Текущий код этим условиям удовлетворяет. X-сервер - нет. На данный момент я не убеждён, что улучшение графической подсистемы требует отказа от этих требований (что графическая подсистема требует улучшения - несомненно).
andrew_programmer писал(а):
1)Главное окно есть? Да. Дочерние окна есть? Нет.(...)Всплывающие окна есть? Нет. Окон, которые всегда на самом верху - нет. И на данный момент эмулировать их просто невозможно!

Очевидно, это означает, что текущий вариант оконной подсистемы не предоставляет некоторых нужных фич. Это не означает, что нужно писать X-сервер на Сях. Это означает, что нужно выяснить, какое API нужно, после чего взять и изменить текущую реализацию.
andrew_programmer писал(а):
2)Аппаратное ускорение возможно задействовать обращением к операционной системе через прерывания без помощи сторонних библиотек? Нет.
А если я захочу задействовать аппаратное ускорение 3D, что тогда делать? Mesa, между прочим, взаимодействует с X-server-ом для аппаратной отрисовки внутри окон.

Не понял. Почему аппаратное ускорение нельзя задействовать обращением к операционной системе через прерывания? Собственно, вроде вообще в любом взаимодействии программы с внешним миром должна как-то участвовать операционная система, а то несогласованные действия разных программ ни к чему хорошему не приведут. Ну а "прерывания" - всего лишь основной способ взаимодействия с ОСью. И каким образом аппаратное ускорение 3D противоречит требованиям а)-в), таким образом требуя выделение X-сервера?
andrew_programmer писал(а):
То и дело люди жалуются на артефакты "след окна" возникающие при пересечении иконок и окон обычных приложений.

Следовательно, нужно либо дать иконкам возможность быть окнами, всегда лежащими внизу оконного стека, либо сделать эти иконки частью большого окна под условным названием "рабочий стол", который опять же всё время должен лежать внизу оконного стека. Если "идеально правильным" вариантом считать первый, то текущая реализация костылём не является, а просто недоработана, с точки зрения второго, пожалуй, можно согласиться на костыльность, но сама по себе возможность первого варианта указывает на то, что несомненным костылём текущую реализацию счесть нельзя. По поводу недоработанности - согласен (и смотри выше).
andrew_programmer писал(а):
Отрисовка курсора: скрываем курсор, рисуем, отображаем. Это ужас.

Пожалуй, я согласен с классификацией этого как костыля. Но это костыль реализации, а не проектирования, и исправляется без глобальных переделок.
andrew_programmer писал(а):
Текст и числа отрисовывает операционная система.

В идеальном мире текст и числа отрисовывает каждая программа самостоятельно?
andrew_programmer писал(а):
Кнопки отрисовывает операционная система. А если я захочу 10000 кнопок то все их должна перебирать операционная система. Как тогда насчёт времени отклика и скорости работы OS?

В идеальном мире кнопки отрисовывает каждое приложение самостоятельно?
Если приложение хочет 10000 кнопок, в любом случае их кто-то должен перебирать.
andrew_programmer писал(а):
Сколько раз повторялись глюки с незакрытием окна, из-за пересечения областей кнопок и кнопки закрытия окна.

Чего? Если приложение не предпринимает специальных усилий, то кнопка закрытия окна не перекрывается с другими кнопками этого окна. Если она перекрывается с другими кнопками окон выше по оконному стеку, то, раз они выше, то и по логике они срабатывать должны.
andrew_programmer писал(а):
Вывод битмапа только 24 бита. Если с палитрой, то отдельная системная подфункция. Неужели по всякому поводу будем заводить подфункции системных функций?

Не по всякому, а только по нужным. Если окажется, что при проектировании забыли важную фичу, то да, придётся создавать новую функцию, а если будет лень переписывать ВСЁ на эту новую функцию, то старая останется для совместимости.
andrew_programmer писал(а):
Смотрим внимательно на код ядра. То здесь, то там вылезает кусок кода касающийся GUI.

Утверждается, что вся оконная подсистема локализована в следующих местах:
- папка gui/, где и положено быть всему GUI-коду (User Interface);
- папка video/, где и положено быть видеодрайверам;
- константы и определения, как им и положено, лежат в const.inc и proc32.inc;
- обработка системных вызовов в kernel.asm.
Это не так?
andrew_programmer писал(а):
Статический код графики и GUI приводит к путанице и бардаку в ядре усложняя понимание и, соответственно, модернизацию этого кода.

А если бы Велик изначально выбрал модель с X-сервером, то этот же самый код в составе сервера был бы вершиной красоты и изящества, ага?
andrew_programmer писал(а):
Если всё делать правильно, то программист будет просто наслаждаться удобством пользования библиотекой. Как это сейчас с InfinitySound. Не нужно париться с драйверами и их устройством - есть промежуточный абстрактный слой.

Так это подмена понятий. Сравниваются интерфейс библиотеки InfinitySound ("удобно пользоваться") и реализация графической подсистемы ("усложняя понимание и, соответственно, модернизацию"). Интерфейс-то и для взаимодействия с окнами прост и понятен, только бедный слишком.

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
СообщениеДобавлено: Чт янв 28, 2010 11:45 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Цитата:
Пожалуйста, пусть графика будет не в ядре, а в драйвере, пусть даже вместо кучи системных вызовов для обработки GUI и окон будет один системный вызов типа "вызвать функцию из GUI под номером ebx" (как вариант, два вызова - для GUI и для оконных функций), мне лично пофиг. Пока графическая подсистема а) не требует лишних переключений колец защиты, б) не требует лишних переключений контекста, в) способна исполняться более или менее параллельно при параллельных вызовах из разных приложений (по модулю, естественно, необходимых блокировок при работе с разделяемыми ресурсами), эффективность работы не изменится никак. Текущий код этим условиям удовлетворяет. X-сервер - нет.

Процетирую самого себя.
Цитата:
1)Графику в user mode отдельным процессом типа X-server в Linux.
2) Каждая программа будет использовать специальную библиотеку уровня ядра для работы с различными драйверами и с окнами. Типа как сейчас звук через Infinity.

diamond, ты выбрал вариант 2. Я ведь не зря спрашивал. Так как никто ничего не ответил, то я выбрал вариант 1, потому что проще писать, отлаживать, и с драйверами взаимодействовать(смотри далее).

Цитата:
Не понял. Почему аппаратное ускорение нельзя задействовать обращением к операционной системе через прерывания? Собственно, вроде вообще в любом взаимодействии программы с внешним миром должна как-то участвовать операционная система, а то несогласованные действия разных программ ни к чему хорошему не приведут. Ну а "прерывания" - всего лишь основной способ взаимодействия с ОСью. И каким образом аппаратное ускорение 3D противоречит требованиям а)-в), таким образом требуя выделение X-сервера?

Как-то Serge писал, что в новой версии Pixlib аппаратным будет только блиттер, а остальное будет рисоваться в user mode. То есть часть функциональности драйвера будет в user mode. Ещё было упоминание про библиотеку Mesa. Сомнительно, что такая махина будет работать в ядре(даже если опционально). Измениться ли ситуация - не знаю. Но чтобы взаимодействовать с драйвером в ядре, нужно либо знать особенности конкретного драйвера, либо драйвер должен иметь определённый интерфейс.
Надо обсуждать с Serge-ем.

Цитата:
В идеальном мире текст и числа отрисовывает каждая программа самостоятельно?

Цитата:
В идеальном мире кнопки отрисовывает каждое приложение самостоятельно?

В идеальном мире библиотека в user mode формирует команды к драйверу видео, а тот аппаратно отрисовывает. Если что-то аппаратно не поддерживается, то эмулирует програмно. Сейчас драйвер только VESA, а красиво встроить универсальную аппаратную отрисовку не получиться.
Цитата:
Если приложение хочет 10000 кнопок, в любом случае их кто-то должен перебирать.

Да, должен - библиотека GUI в user mode.
Цитата:
Чего? Если приложение не предпринимает специальных усилий, то кнопка закрытия окна не перекрывается с другими кнопками этого окна. Если она перекрывается с другими кнопками окон выше по оконному стеку, то, раз они выше, то и по логике они срабатывать должны.

Не помню всех обстоятельств, но иногда при перекрытии доски отладки и окна таки глюки возникают.
Цитата:
Утверждается, что вся оконная подсистема локализована в следующих местах:
- папка gui/, где и положено быть всему GUI-коду (User Interface);
- папка video/, где и положено быть видеодрайверам;
- константы и определения, как им и положено, лежат в const.inc и proc32.inc;
- обработка системных вызовов в kernel.asm.
Это не так?

Я знаю, что там локализовано. Я хорошо порылся в коде ядра. А вот если бы оно было локализовано в коде для 1 единственной DLL, а не во всём вышеперечисленном, то его было бы проще понимать,дорабатывать, совершенствовать. В kernel.asm помимо оконной подсистемы и графики ещё много чего есть. Код относящийся к различным драйверам поместить в отдельные папки и реализовать в виде DLL. Хотя некоторые драйверы уже в отдельных папках, но всё равно должен быть уровень абстракции, обеспечивающей максимальную модульность.

_________________
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!


Вернуться к началу
СообщениеДобавлено: Пт янв 29, 2010 1:51 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Ух, как жизнь забурлила !

diamond писал(а):
В идеальном мире текст и числа отрисовывает каждая программа самостоятельно?

Да. GPU от этого самоустранились. Тем более что 2D API стали намного сложнее. Координаты в вещественном формате, сглаживание, слои и многое другое. Теоретически примитивы можно рисовать и шейдерами но на данный момент очень сложно программировать железо напрямую. Может быть через 5-10 лет с появлением в GPU x86 и ARM ядер начнётся обратный процесс, но пока так.
В 3D ситуация похожа: драйвер в user-mode создаёт пакет команд в формате командного процессора gpu и передаёт драйверу. Драйвер ядра выполняет верификацию команд и патчит текстурные команды (у gpu своё адресное пространство и ещё текстуры могут быть вытеснены из видеопамяти и gart в системную память и своп). После обработки буфер передаётся на исполнение командному процессору.
То есть в ядре нет никакого специального 3D драйвера с вызовами "отрисовать массив вершин".

Общее направление - рисовать всё в битмапы в системной памяти а аппаратно выполнять только финальный рендеринг окон.


Последний раз редактировалось Serge Пт янв 29, 2010 4:53 am, всего редактировалось 3 раза.

Вернуться к началу
СообщениеДобавлено: Пт янв 29, 2010 2:30 am 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Serge

Ну так как насчёт драйверов в текущей KolibriOS? Драйвер ATI частично будет в user mode, а PCI и memory management в ядре?

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Вернуться к началу
СообщениеДобавлено: Пт янв 29, 2010 3:21 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
andrew_programmer

Специализированного для ATI кода в user-mode не будет. Из pixlib будут удалены обращения к драйверу для отрисовки 2D примитивов и улучшена поддержка битмапов.

Примерная схема работы такая:
1. Приложение
через pixlib создаёт битмап (create_pixmap) для своего окна. Отслеживает размеры окна и при необходимости меняет размер текстуры (resize_pixmap). Всю отрисовку выполняет самостоятельно. В pixlib есть несколько примитивов но лучше поискать для портирования более продвинутые библиотеки. Выводит окно на экран (draw_pixmap). При завершении удаляет битмап (delete_pixmap). Число битмапов ограничено только доступными ресурсами.
2. Драйвер
много фана с системной, локальной и gart памятью. Как замечательно что у нас нет свопа ! Ещё потребуется некоторая поддержка ( костыль ) от ядра потому что драйвер не умеет выполнять отсечение для перекрытых окон. То есть переднее окно будет выводиться аппаратно а фоновые через ядро.


Вернуться к началу
СообщениеДобавлено: Пт янв 29, 2010 1:58 pm 
Не в сети

Зарегистрирован: Вс фев 18, 2007 8:34 pm
Сообщения: 158
Цитата:
С целью?

1) иметь возможность использовать систему без системного GUI (текстовая консоль);
2) иметь возможность использовать альтернативный GUI;
3) получить более структурированную систему с лаконичным интерфейсом между ядром и графической подсистемой и т.д.

Цитата:
Вообще, задача операционной системы распределять системные ресурсы и разграничивать их между процессами. А не рисованием заниматься.
+1 :D

Цитата:
Драйверы в ядре, "полицейский" в user mode.
Как я уже сказал, я считаю, что более эффективным будет вариант, когда GUI-сервер (этим термином я называю не отдельный процесс, а библиотеку, предоставляющую GUI-сервис) работает в пространстве ядра. При таком подходе вообще нет необходимости передавать большие объемы графических данных через IPC. Другое дело, что и для обращения к GUI-серверу можно создать user-mode-прослойку, берущую на себя часть графических функций, чтобы опять в пространстве ядра не заниматься растеризацией контроллов и т.п.

Цитата:
...либо сделать эти иконки частью большого окна под условным названием "рабочий стол", который опять же всё время должен лежать внизу оконного стека.
Этот вариант наиболее логичный. Причем "рабочий стол" (вместе с иконками) естественно должен принадлежать оболочке. В случае, когда оболочка не запущена вообще, могут быть разные варианты. Либо совсем отключить вывод, либо выводить окошки на фоне, формируемом непосредственно GUI-сервером (я бы вообще предпочел черный фон).


Вернуться к началу
СообщениеДобавлено: Пт янв 29, 2010 5:18 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Цитата:
Примерная схема работы такая:
1. Приложение
через pixlib создаёт битмап (create_pixmap) для своего окна. Отслеживает размеры окна и при необходимости меняет размер текстуры (resize_pixmap). Всю отрисовку выполняет самостоятельно. В pixlib есть несколько примитивов но лучше поискать для портирования более продвинутые библиотеки. Выводит окно на экран (draw_pixmap). При завершении удаляет битмап (delete_pixmap). Число битмапов ограничено только доступными ресурсами.
2. Драйвер
много фана с системной, локальной и gart памятью. Как замечательно что у нас нет свопа ! Ещё потребуется некоторая поддержка ( костыль ) от ядра потому что драйвер не умеет выполнять отсечение для перекрытых окон. То есть переднее окно будет выводиться аппаратно а фоновые через ядро.


А драйвер ATI будет предоставлять сервисы типа START, service_proc, version? Если будет, то есть идея реализовать такую штуку. Оконная подсистема является отдельной dll работающей в ядре и предоставляет сервис называемый "WINDOWS". Она использует сервис "ATI" (можно назвать его как то по другому) для аппаратного переброса битмапов. Эти битмапы - окна, которыми управляет сервис "WINDOWS". Для рисования внутри окон используется вспомогательная библиотека libWindows, работающая в user mode, и отрисовывающая в битмап(окно). Если окно дочернее, то будет происходить просто отрисовка в родительское окно с указанием оконной подсистеме, что оно дочернее. Управлять оконным стеком и отсечением окон(битмапов) будет оконная подсистема, которая будет передавать отсечённые прямоугольники драйверу для аппаратного переброса на экран. Битмапы окон будут в user mode, а результирующие отсечённые окна уже в пространстве ядра в драйвере оконной подсистемы. Надо ещё будет решить, что делать с окнами зависших приложений.
Если пользователю не нужна оконная подсистема, то можно не грузить драйвер видео и не загружать оконную подсистему. Правда надо сделать драйвер консоли, чтобы можно было работать в консольном режиме.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Вернуться к началу
СообщениеДобавлено: Пт янв 29, 2010 5:57 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
andrew_programmer

Ну в перспективе я на это и расчитывал.

Кстати
Код:
struc SRV
{
 .srv_name          rb 16           ;ASCIIZ string
  .magic             dd ?     ;+0x10 ;'SRV '
  .size              dd ?     ;+0x14 ;size of structure SRV
  .fd                dd ?     ;+0x18 ;next SRV descriptor
  .bk                dd ?     ;+0x1C ;prev SRV descriptor
  .base              dd ?     ;+0x20 ;service base address
  .entry             dd ?     ;+0x24 ;service START function
  .srv_proc          dd ?     ;+0x28 ;user mode service handler
  .srv_proc_ex       dd ?     ;+0x2C ;kernel mode service handler
  .sizeof:}
srv_proc_ex появилась в транке но пока нигде не используется. Это защищённая точка входа для драйверов и сервисов ядра. И ещё одна структура ядра должна постепенно собрать все обращения ядра к драйверу
Код:
struc display_t
{
    .x              dd ?
    .y              dd ?
    .width          dd ?
    .height         dd ?
    .bpp            dd ?
    .vrefresh       dd ?
    .pitch          dd ?
    .lfb            dd ?

    .modes          dd ?
    .ddev           dd ?
    .connector      dd ?
    .crtc           dd ?

    .cr_list.next   dd ?
    .cr_list.prev   dd ?

    .cursor         dd ?

    .init_cursor    dd ?
    .select_cursor  dd ?
    .show_cursor    dd ?
    .move_cursor    dd ?
    .restore_cursor dd ?
    .disable_mouse  dd ?
}


Вернуться к началу
СообщениеДобавлено: Сб янв 30, 2010 11:26 am 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Цитата:
Это защищённая точка входа для драйверов и сервисов ядра.

То есть это тот же самый service_proc только для вызовов ядром OS для своих служебных целей?

Если в ближайшие сутки больше никто не выскажется против варианта реализации оконной подситемы описанного выше, то текущий вариант будет окончательным.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Вернуться к началу
СообщениеДобавлено: Сб янв 30, 2010 12:29 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Не тот же самый. Специальный обработчик для для вызовов из ядра и других драйверов. Предоставляет сервисы к которым нельзя давать доступ из user-mode потому что это обрушит систему.


Вернуться к началу
СообщениеДобавлено: Сб янв 30, 2010 3:39 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
А битмапы для всех окон не будут отжирать память со страшной скоростью?


Вернуться к началу
СообщениеДобавлено: Сб янв 30, 2010 4:56 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3925
Будут. Линукс их поэтому свопит. Можно освобождать страницы если окно свёрнуто или полность перекрыто.


Вернуться к началу
СообщениеДобавлено: Сб янв 30, 2010 5:44 pm 
А может как вариант для экономичности делить окна на сектора? Если сектор окна перекрыт полностью - уже неплохая экономия. Хотябы на 4 части.


Вернуться к началу
   
СообщениеДобавлено: Сб янв 30, 2010 6:28 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Цитата:
А может как вариант для экономичности делить окна на сектора? Если сектор окна перекрыт полностью - уже неплохая экономия. Хотябы на 4 части.

У меня идея более глобальна. Отрисовывать только не перекрытую часть окна. Хочется сделать алгоритм способный вычислять форму не перекрытой части(даже с дырками). Окна - это ведь прямоугольники. Тут окнам надо сопоставить Z координату глубины. Это потребует видео буфера, размером с экран, что ускорит рисование, но займёт 1.6-3.0Mb (зависит от разрешения экрана) оперативной памяти. В принципе, ради хорошей скорости - этого не жалко.

_________________
KolibriOS-перспективная ос!

Kolibri is best operation system in the world!


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 30 сообщений ]  На страницу Пред. 1 2

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB