art_zh
А как насчёт 16 битного режима. Для старых компьютеров - самое то.

Да, если честно, я почти не знаю компьютеров, которые поддерживают 24 бита. Все либо 16, либо 32.
fplay пока не могу проверить - нет звука.

Serge wrote:... Не уверен, что оптимизация кода даст заметный выигрыш в быстродействии для дискретной графики.Там скорость прямой записи в видеопамять всего 130-150 Мб/с. Как на интеграшках не знаю, надо проверять.

Мне кажется, что эти 130-150 Мб/с это скорость PCI интерфейса и на новых компьютерах с PCI-E и AGP скорость должна поболее быть.

Maxis wrote:Мне кажется, что эти 130-150 Мб/с это скорость PCI интерфейса и на новых компьютерах с PCI-E и AGP скорость должна поболее быть.

Насколько я понял, Колибри пока не поддерживает PCI-express & AGP

yogev_ezra
AGP точно не поддерживает. Насчёт PCI-E не уверен, что для этой шины требуется какой-либо специальный драйвер.

140 Мб запись 4.5 Мб чтение по моим замерам на AGP 8x. Эта скорость слабо зависит от шины если читать и писать вручную.

Я в Haiku тестировал с драйвером AGP и без в VESA режиме. Без него бенчмарк показывал где-то 133Мб/c, с ним около тысячи на AGP 8x.

yogev_ezra
Полноценная поддержка AGP - только для радеонов, в мегадрайвере ATIKMS.DLL
PCI-express настраивается BIOSом и распознается системой как обычная PCI, хотя данные по ней передаются на максимальной PCIe-скорости, которую способен обеспечить канал и чипсет.
Еще есть поддержка расширенного пространства PCIe, но в официальном ядре она по умолчанию отключена.

Я тоже проголосовал за п.1 (но из "идеологических" соображений)

A.
Я вижу два пути развития KolibriOS (в.т.ч. в контектсе графической подсистемы):
1) монолитная архитектура (ядра) с модулями с автоматической подгрузкой (в.т.ч. графических) драйверов (путь GNU Linux);
2) -> гибридная -> микроядерная архитектура (с выносом GUI, а возможно, и драйверов из ядра) с автоматическим запуском нужного ring3 драйвера, ring3 сервера.

В первом случае пока система уменьшается на дискету, беспокоится нечего (разве что подумать о возможности компилировать только нужное).

Во втором случае, когда произойдёт реальный сдвиг в этом направлении, тогда и лучше можно будет понять, что конкретно надо менять в.т.ч. и в графической подсистеме. (Следует также заметить, что размер ядра KolibriOS примерно равен размеру микроядра Minix3, так что на пути к микроядерной архитектуре именно размер ядра KolibriOS как раз не проблема, нужны ring3 драйверы и серверы, но прежде всего система привилегий и полномочий, а также более развитые механизмы межпроцессного взаиможействия).

Б.

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

В.

Я запускал KolibriOS на 3-х аппаратных платформах и 2-х виртуальных машинах: набор возможных рабочих режимов в каждом случае был несколько разным. Боюсь, что любое из предлагаемых измененй приведёт к тому, что на одной из 5-ти платформ KolibriOS не будет запускаться (или будет запускаться с издержками на пересчёт графики в виртуальной машине).

В связи с этим (на мой взгляд), прежде чем делать такие изменения, нужно что-то вроде:

возможность запустить KolibriOS в текстовом режиме,
+
возможность запустить (изменить) графический режим позже

Maxis

1000 Мб/с это с акселерацией или без ? В Haiku были свои дрова.

VESA режим. По-умолчанию 2D акселерация в Haiku отключена - нужно в исходниках её включить и скомпилировать систему заново. Я этого не делал.

Maxis

Очень интересно. Непонятнор откуда такой прирост. Биос должна настроить шину на максимальную скорость. А драйвер агп без акселерации ни к чему. А что за тест ? Надо посмотреть исходники. Их svn у меня есть.

Названия теста я уже не помню. Брал с haikuware. Тест простенький: рисуется окошко фиксированых размеров через системный API. Тестировал следующим образом: удалял драйвер - 133Мб/с; с драйвером - около тысячи.

FireWall
A - я рассматривал только вариант 1) - см. первый пост сабжа. О микроядерной архитектуре говорено много, а сделано не густо.
Б .
Полноценные видеодрайверы есть только для радеонов. Для NV их не будет никогда, аминь. Для intel-графики - только если кто-то проплатит их разработку (кстати, этот вариант весьма вероятен). Из универсальных вариантов стаются только VESA-режимы, но и те не дают друг другу полноценно функционировать.
Я помню золотые слова diamond`a: "Колибри - это не только очень быстрая, но еще и очень маленькая ОС". Этот подход (плюс универсализация кода для всех мыслимых платформ) иногда даёт совершенно обратный результат: код в итоге получается медленным и рыхлым. А разные "оптимизирующие" трюки (иногда за гранью "высшего пилотажа") еще и делают его крайне ненадежным. VESA2 + window.inc - один из самых показательных примеров (есть и другие). Такие узлы надо не расплетать - рубить.
В - только разумеется рубить не по живому. Потренируемся "на кошечках", в боковой ветке, а потом сравним результаты.
Но в любом случае имхо назрел вопрос раздельной компиляции ядра для разных платформ. Так можно снять из ядра 30-40 килобайт ненужного кода и дублирующих проверок. И только так можно обеспечить эффективную работу системы на все более непохожих друг на друга платформах.

Наилучшим вариантом здесь мне видится аналог линуксовского config.h