Обсуждение графической подсистемы

Kernel-side graphics support
  • andrew_programmer wrote:Я прекрасно помню, что diamond противник вынесения какой-либо графики из ядра.
    А ещё есть сторонники идеи,"Нечего засорять ядро всяким гов**м". Попробуйте найти компромисное решение, удовлетворяющее и первым, и вторым....
    Пожалуйста, пусть графика будет не в ядре, а в драйвере, пусть даже вместо кучи системных вызовов для обработки GUI и окон будет один системный вызов типа "вызвать функцию из GUI под номером ebx" (как вариант, два вызова - для GUI и для оконных функций), мне лично пофиг. Пока графическая подсистема а) не требует лишних переключений колец защиты, б) не требует лишних переключений контекста, в) способна исполняться более или менее параллельно при параллельных вызовах из разных приложений (по модулю, естественно, необходимых блокировок при работе с разделяемыми ресурсами), эффективность работы не изменится никак. Текущий код этим условиям удовлетворяет. X-сервер - нет. На данный момент я не убеждён, что улучшение графической подсистемы требует отказа от этих требований (что графическая подсистема требует улучшения - несомненно).
    andrew_programmer wrote:1)Главное окно есть? Да. Дочерние окна есть? Нет.(...)Всплывающие окна есть? Нет. Окон, которые всегда на самом верху - нет. И на данный момент эмулировать их просто невозможно!
    Очевидно, это означает, что текущий вариант оконной подсистемы не предоставляет некоторых нужных фич. Это не означает, что нужно писать X-сервер на Сях. Это означает, что нужно выяснить, какое API нужно, после чего взять и изменить текущую реализацию.
    andrew_programmer wrote:2)Аппаратное ускорение возможно задействовать обращением к операционной системе через прерывания без помощи сторонних библиотек? Нет.
    А если я захочу задействовать аппаратное ускорение 3D, что тогда делать? Mesa, между прочим, взаимодействует с X-server-ом для аппаратной отрисовки внутри окон.
    Не понял. Почему аппаратное ускорение нельзя задействовать обращением к операционной системе через прерывания? Собственно, вроде вообще в любом взаимодействии программы с внешним миром должна как-то участвовать операционная система, а то несогласованные действия разных программ ни к чему хорошему не приведут. Ну а "прерывания" - всего лишь основной способ взаимодействия с ОСью. И каким образом аппаратное ускорение 3D противоречит требованиям а)-в), таким образом требуя выделение X-сервера?
    andrew_programmer wrote:То и дело люди жалуются на артефакты "след окна" возникающие при пересечении иконок и окон обычных приложений.
    Следовательно, нужно либо дать иконкам возможность быть окнами, всегда лежащими внизу оконного стека, либо сделать эти иконки частью большого окна под условным названием "рабочий стол", который опять же всё время должен лежать внизу оконного стека. Если "идеально правильным" вариантом считать первый, то текущая реализация костылём не является, а просто недоработана, с точки зрения второго, пожалуй, можно согласиться на костыльность, но сама по себе возможность первого варианта указывает на то, что несомненным костылём текущую реализацию счесть нельзя. По поводу недоработанности - согласен (и смотри выше).
    andrew_programmer wrote:Отрисовка курсора: скрываем курсор, рисуем, отображаем. Это ужас.
    Пожалуй, я согласен с классификацией этого как костыля. Но это костыль реализации, а не проектирования, и исправляется без глобальных переделок.
    andrew_programmer wrote:Текст и числа отрисовывает операционная система.
    В идеальном мире текст и числа отрисовывает каждая программа самостоятельно?
    andrew_programmer wrote:Кнопки отрисовывает операционная система. А если я захочу 10000 кнопок то все их должна перебирать операционная система. Как тогда насчёт времени отклика и скорости работы OS?
    В идеальном мире кнопки отрисовывает каждое приложение самостоятельно?
    Если приложение хочет 10000 кнопок, в любом случае их кто-то должен перебирать.
    andrew_programmer wrote:Сколько раз повторялись глюки с незакрытием окна, из-за пересечения областей кнопок и кнопки закрытия окна.
    Чего? Если приложение не предпринимает специальных усилий, то кнопка закрытия окна не перекрывается с другими кнопками этого окна. Если она перекрывается с другими кнопками окон выше по оконному стеку, то, раз они выше, то и по логике они срабатывать должны.
    andrew_programmer wrote:Вывод битмапа только 24 бита. Если с палитрой, то отдельная системная подфункция. Неужели по всякому поводу будем заводить подфункции системных функций?
    Не по всякому, а только по нужным. Если окажется, что при проектировании забыли важную фичу, то да, придётся создавать новую функцию, а если будет лень переписывать ВСЁ на эту новую функцию, то старая останется для совместимости.
    andrew_programmer wrote:Смотрим внимательно на код ядра. То здесь, то там вылезает кусок кода касающийся GUI.
    Утверждается, что вся оконная подсистема локализована в следующих местах:
    - папка gui/, где и положено быть всему GUI-коду (User Interface);
    - папка video/, где и положено быть видеодрайверам;
    - константы и определения, как им и положено, лежат в const.inc и proc32.inc;
    - обработка системных вызовов в kernel.asm.
    Это не так?
    andrew_programmer wrote:Статический код графики и GUI приводит к путанице и бардаку в ядре усложняя понимание и, соответственно, модернизацию этого кода.
    А если бы Велик изначально выбрал модель с X-сервером, то этот же самый код в составе сервера был бы вершиной красоты и изящества, ага?
    andrew_programmer wrote:Если всё делать правильно, то программист будет просто наслаждаться удобством пользования библиотекой. Как это сейчас с InfinitySound. Не нужно париться с драйверами и их устройством - есть промежуточный абстрактный слой.
    Так это подмена понятий. Сравниваются интерфейс библиотеки InfinitySound ("удобно пользоваться") и реализация графической подсистемы ("усложняя понимание и, соответственно, модернизацию"). Интерфейс-то и для взаимодействия с окнами прост и понятен, только бедный слишком.
    Ушёл к умным, знающим и культурным людям.
  • Пожалуйста, пусть графика будет не в ядре, а в драйвере, пусть даже вместо кучи системных вызовов для обработки 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!
  • Ух, как жизнь забурлила !
    diamond wrote:В идеальном мире текст и числа отрисовывает каждая программа самостоятельно?
    Да. GPU от этого самоустранились. Тем более что 2D API стали намного сложнее. Координаты в вещественном формате, сглаживание, слои и многое другое. Теоретически примитивы можно рисовать и шейдерами но на данный момент очень сложно программировать железо напрямую. Может быть через 5-10 лет с появлением в GPU x86 и ARM ядер начнётся обратный процесс, но пока так.
    В 3D ситуация похожа: драйвер в user-mode создаёт пакет команд в формате командного процессора gpu и передаёт драйверу. Драйвер ядра выполняет верификацию команд и патчит текстурные команды (у gpu своё адресное пространство и ещё текстуры могут быть вытеснены из видеопамяти и gart в системную память и своп). После обработки буфер передаётся на исполнение командному процессору.
    То есть в ядре нет никакого специального 3D драйвера с вызовами "отрисовать массив вершин".

    Общее направление - рисовать всё в битмапы в системной памяти а аппаратно выполнять только финальный рендеринг окон.
    Last edited by Serge on Fri Jan 29, 2010 4:53 am, edited 3 times in total.
  • 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 :D
    Драйверы в ядре, "полицейский" в user mode.
    Как я уже сказал, я считаю, что более эффективным будет вариант, когда GUI-сервер (этим термином я называю не отдельный процесс, а библиотеку, предоставляющую GUI-сервис) работает в пространстве ядра. При таком подходе вообще нет необходимости передавать большие объемы графических данных через IPC. Другое дело, что и для обращения к GUI-серверу можно создать user-mode-прослойку, берущую на себя часть графических функций, чтобы опять в пространстве ядра не заниматься растеризацией контроллов и т.п.
    ...либо сделать эти иконки частью большого окна под условным названием "рабочий стол", который опять же всё время должен лежать внизу оконного стека.
    Этот вариант наиболее логичный. Причем "рабочий стол" (вместе с иконками) естественно должен принадлежать оболочке. В случае, когда оболочка не запущена вообще, могут быть разные варианты. Либо совсем отключить вывод, либо выводить окошки на фоне, формируемом непосредственно GUI-сервером (я бы вообще предпочел черный фон).
  • Примерная схема работы такая:
    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!
  • andrew_programmer

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

    Кстати

    Code: Select all

    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 появилась в транке но пока нигде не используется. Это защищённая точка входа для драйверов и сервисов ядра. И ещё одна структура ядра должна постепенно собрать все обращения ядра к драйверу

    Code: Select all

    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 части.
  • А может как вариант для экономичности делить окна на сектора? Если сектор окна перекрыт полностью - уже неплохая экономия. Хотябы на 4 части.
    У меня идея более глобальна. Отрисовывать только не перекрытую часть окна. Хочется сделать алгоритм способный вычислять форму не перекрытой части(даже с дырками). Окна - это ведь прямоугольники. Тут окнам надо сопоставить Z координату глубины. Это потребует видео буфера, размером с экран, что ускорит рисование, но займёт 1.6-3.0Mb (зависит от разрешения экрана) оперативной памяти. В принципе, ради хорошей скорости - этого не жалко.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Who is online

    Users browsing this forum: No registered users and 3 guests