forum.lissyara.su

хм
помниться линуксоиды всегда орали и орут что нафиг делать графике в ядре
вот вообщем искал инашел такую штуку

http://www.microxwin.com/architecture.html

код модуля ядреного закрыт
размер всей minixorg почти метр
интересно у кого линукс есть и ему нечем заняться - тестоните)
неужто быстро работает?

Что то в этом мне напомнило давно виденый доклад от OpenBSD тим, о перспективах Хов, натыкался на него тут, там вроде еше что то про тачскрины есть, пока не читал.

paradox писал(а): неужто быстро работает?

а почему оно быстрее должно, из-за того что архитектура ядра как-то по другому сишные модули использует?

если firefox встроить в ядро может быстрее будет?

а почему оно быстрее должно, из-за того что архитектура ядра как-то по другому сишные модули использует?

потому что ты незнаешь что такое контекст)
и что делает процессор для того что бы твоя операционка работала
вот если бы это знали еще и те кто изобретал xorg....

Graphics data is copied directly from user space to frame buffer by kernel module.

эм, а driver pixmaps по ихнему для чего существует?

Complete user space anti-aliased fonts based on fontconfig and Xft.

хех, это если учитивать что от "этих ваших" векторных шрифтов и идут основные тормоза.

У мя тупой вопрос: сколько попугаев у gtkperf они этим выиграли?

paradox писал(а):потому что ты незнаешь что такое контекст)

а при чём тут контекст? да и потом, контекст чего?

просто тупо заменили одну библиотеку другой, встроили нечто похожее на директдроу с поддержкой апи иксов в ядро и опа... вместо сокета появился девайс в /dev/

интресней другое - в теории эта штука может все форточки рисовать на OpenGL. Правда, я там не нашёл упоминаний про драйвер видяхи. А это отнюдь не маловажная часть такой системы.

и, вообще, не очень понятно что они сделали с драйверами DDX/DRM/DRI. Объединили и пихнули в ядро?

эм, а driver pixmaps по ихнему для чего существует?

они упрощали по другому видать

У мя тупой вопрос: сколько попугаев у gtkperf они этим выиграли?

это для embeded девайсов

а при чём тут контекст? да и потом, контекст чего?

user-space
kernel-space

xorg
разнесен в два разных пространства(контекст CPU) при переключении с двух ring0 <-> ring3 очень тяжолая операция

просто тупо заменили одну библиотеку другой, встроили нечто похожее на директдроу с поддержкой апи иксов в ядро и опа... вместо сокета появился девайс в /dev/

ну уже чуть лучше
чем сокеты

интресней другое - в теории эта штука может все форточки рисовать на OpenGL. Правда, я там не нашёл упоминаний про драйвер видяхи. А это отнюдь не маловажная часть такой системы.

vesa

и, вообще, не очень понятно что они сделали с драйверами DDX/DRM/DRI. Объединили и пихнули в ядро?

они их вообще не брали
все на vesa framebuffer

paradox писал(а):vesa

почему-то так и подумал

paradox писал(а):ну уже чуть лучше
чем сокеты

конечно лучше, тут даже и спорить не о чём. Просто весь гуй уже давным давно пора переводить в опенгл, иначе это переливание из пустого в порожнее.

Просто щас получается, что пока они не завяжутся на дровах с аппаратной поддержкой ускорения, смысла слезать с иксов нет. Да и то, что мудль ядра закрыт совем не радует.

конечно лучше, тут даже и спорить не о чём. Просто весь гуй уже давным давно пора переводить в опенгл, иначе это переливание из пустого в порожнее.

ну это все абстракция
в винде в итоге к этому все и вышло
посто они OpenGL для самой винды не давали
токо как ексклюзив для игр
но в висте уже сделали
и получили еффекты в плоть до тех что есть в бериле

Просто щас получается, что пока они не завяжутся на дровах с аппаратной поддержкой ускорения, смысла слезать с иксов нет. Да и то, что мудль ядра закрыт совем не радует.

всего лиш абстракция
если бы правильно реализовали
то дальше меняй дрова vesa или хардварный для какойто карты
и получай либо ускорение либо обычный фреймбуффер

на иксах и в программах бывают глюки, если иксы будут в ядре, то оно висеть будет часто как на винде?

paradox писал(а):и получили еффекты в плоть до тех что есть в бериле

не в эффектах дело, а в нагрузке. В XP все окна прорисовывает проц, как и высчитывает их наложение, пересечения и прочая. OpenGL справится с тем же в сотни раз быстрее и без какой-либо нагрузки на цп. Если учесть, что каждая закорючка, которая имеет hwnd, является полноценным окном, то видяха очень сильно может помочь разгрузить проц.

paradox писал(а):то дальше меняй дрова vesa или хардварный для какойто карты

хотелось бы надеяться. Ты под фрёй не колупал сие чудо?

ProFTP писал(а):на иксах и в программах бывают глюки, если иксы будут в ядре, то оно висеть будет часто как на винде?

-))) не боись, не будет.

хотелось бы надеяться. Ты под фрёй не колупал сие чудо?

наскоко я помню xorg так и работает
а эти
http://www.microxwin.com/architecture.html
просто усекли до vesa
тоесть vesa они фактически туда вкомпилили

ну и вообще если чтото кто то реализовывает
то потом сменить с фрейм буффера на чтото хардварное нет проблем
лишбы дрова опен соурс были для той видюхи что надо

на иксах и в программах бывают глюки, если иксы будут в ядре, то оно висеть будет часто как на винде?

смотря какие
но на ядро это никак не скажеться

иксы у меня на машинах в районе пентум 3-4 жрут мало жрут процессор и память максимум 20%CPU и 20М и это когда на приделе

paradox писал(а): и что делает процессор для того что бы твоя операционка работала

почему апач до сих пор не в ядре?

>ProFTP
ты все как то неправильно истолковал

что делать апатчу в ядре? если все что нужно должно работать в апаче хватает в пользовательском уровне

всечто нужно апатчу для ядра это send(socket) recv(socket)


а для графики нужно постоянно и быстро передавать потоки данных между простратвом ядра и пользовательским уровнем
user<-> kernel

вот винда собала статистические данные и перенесла в ядро ту часть кода
которая заставляла бегать туда сюда между user<->kernel что бы максимально разгрузить этот обмен

а для твоего любимого апача когда то в ядаре бсд были два модуля
для ускорения работы HTTP контента
но помоему их удалили наскоко я помню(не следил)

для линукса был вроде khttpd

paradox писал(а):а для твоего любимого апача когда то в ядаре бсд были два модуля
для ускорения работы HTTP контента
но помоему их удалили наскоко я помню(не следил)

accept() фильтры не куда не делись.
accf_http(9)
accf_data(9)
accf_dns(9)

нене там что то другое было насчет HTTP
хотя может делоло тоже но называлось по другому
точно помню что до freebsd 4.4 оно еще было
два параметра для ядра каких то

Есть порт directfb.

который работает поверх sdl, кои работаеют поверх иксов. Нет, конечно, sdl умеет vgl и svgalib, но обе привязаны к i386, как и фреймбуферный эмулятор термина с поддержкой графики jfbterm.

На amd64 directfb дальше иксов не уйдет, скорее наоборот, прибавит тормозов из-за лишних слоев абстракции.

ну будет надеяться что когда тореализуют fb и для amd64
тогда можно будет например уже разрабатывать ядреные отладчики потипу syser для винды

кстате, а как swap работает? он используетр распределенную память/хранилище?

может swap в СУБД поставить как-то?