Board.KolibriOS.org

[вопрос снят. Спасибо]

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

Очевидно, это означает, что текущий вариант оконной подсистемы не предоставляет некоторых нужных фич. Это не означает, что нужно писать X-сервер на Сях. Это означает, что нужно выяснить, какое API нужно, после чего взять и изменить текущую реализацию.

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

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

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

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

В идеальном мире кнопки отрисовывает каждое приложение самостоятельно?
Если приложение хочет 10000 кнопок, в любом случае их кто-то должен перебирать.

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

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

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

А если бы Велик изначально выбрал модель с X-сервером, то этот же самый код в составе сервера был бы вершиной красоты и изящества, ага?

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

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

Процетирую самого себя.

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


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



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

Да, должен - библиотека GUI в user mode.

Не помню всех обстоятельств, но иногда при перекрытии доски отладки и окна таки глюки возникают.

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

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

Ух, как жизнь забурлила !


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

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

Serge

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

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

Kolibri is best operation system in the world!

andrew_programmer

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

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

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

+1

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

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

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

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

Kolibri is best operation system in the world!

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 ?
}

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

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

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

Kolibri is best operation system in the world!

Не тот же самый. Специальный обработчик для для вызовов из ядра и других драйверов. Предоставляет сервисы к которым нельзя давать доступ из user-mode потому что это обрушит систему.

А битмапы для всех окон не будут отжирать память со страшной скоростью?

Будут. Линукс их поэтому свопит. Можно освобождать страницы если окно свёрнуто или полность перекрыто.

А может как вариант для экономичности делить окна на сектора? Если сектор окна перекрыт полностью - уже неплохая экономия. Хотябы на 4 части.

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

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

Kolibri is best operation system in the world!