Mario
Пока не появятся желающие сделать дрова на Интел. Sandy Bridge и Fusion съедают все интеграшки, лоу-энд и часть мидла. Доля NV сильно ужмётся.
yogev_ezra
Быстро, пока не запустишь плеер, или не начнёшь делать снимки экрана. Для видео 720х384 25 кадров поток 26 Мб/с. При псп на запись в 140 Мб это 0.19 сек только на отрисовку, что очень уныло.
Оптимизация ядерной графики
art_zh
А как насчёт 16 битного режима. Для старых компьютеров - самое то.
А как насчёт 16 битного режима. Для старых компьютеров - самое то.
Last edited by Maxis on Sat Nov 20, 2010 4:58 pm, edited 1 time in total.
Да, если честно, я почти не знаю компьютеров, которые поддерживают 24 бита. Все либо 16, либо 32.
fplay пока не могу проверить - нет звука.
fplay пока не могу проверить - нет звука.
Мне кажется, что эти 130-150 Мб/с это скорость PCI интерфейса и на новых компьютерах с PCI-E и AGP скорость должна поболее быть.Serge wrote:... Не уверен, что оптимизация кода даст заметный выигрыш в быстродействии для дискретной графики.Там скорость прямой записи в видеопамять всего 130-150 Мб/с. Как на интеграшках не знаю, надо проверять.
Насколько я понял, Колибри пока не поддерживает PCI-express & AGPMaxis wrote:Мне кажется, что эти 130-150 Мб/с это скорость PCI интерфейса и на новых компьютерах с PCI-E и AGP скорость должна поболее быть.
yogev_ezra
AGP точно не поддерживает. Насчёт PCI-E не уверен, что для этой шины требуется какой-либо специальный драйвер.
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, но в официальном ядре она по умолчанию отключена.
Полноценная поддержка 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 в текстовом режиме,
+
возможность запустить (изменить) графический режим позже
A.
Я вижу два пути развития KolibriOS (в.т.ч. в контектсе графической подсистемы):
1) монолитная архитектура (ядра) с модулями с автоматической подгрузкой (в.т.ч. графических) драйверов (путь GNU Linux);
2) -> гибридная -> микроядерная архитектура (с выносом GUI, а возможно, и драйверов из ядра) с автоматическим запуском нужного ring3 драйвера, ring3 сервера.
В первом случае пока система уменьшается на дискету, беспокоится нечего (разве что подумать о возможности компилировать только нужное).
Во втором случае, когда произойдёт реальный сдвиг в этом направлении, тогда и лучше можно будет понять, что конкретно надо менять в.т.ч. и в графической подсистеме. (Следует также заметить, что размер ядра KolibriOS примерно равен размеру микроядра Minix3, так что на пути к микроядерной архитектуре именно размер ядра KolibriOS как раз не проблема, нужны ring3 драйверы и серверы, но прежде всего система привилегий и полномочий, а также более развитые механизмы межпроцессного взаиможействия).
Б.
Пока не так уж и много как графических режимов, так и специальных драйверов (с поддержкой аппаратного ускорения). Когда их будет действительно много (по крайней мере существенно больше чем сейчас), тогда будеть лучше понять, как и что оптимизировать
В.
Я запускал KolibriOS на 3-х аппаратных платформах и 2-х виртуальных машинах: набор возможных рабочих режимов в каждом случае был несколько разным. Боюсь, что любое из предлагаемых измененй приведёт к тому, что на одной из 5-ти платформ KolibriOS не будет запускаться (или будет запускаться с издержками на пересчёт графики в виртуальной машине).
В связи с этим (на мой взгляд), прежде чем делать такие изменения, нужно что-то вроде:
возможность запустить KolibriOS в текстовом режиме,
+
возможность запустить (изменить) графический режим позже
Maxis
1000 Мб/с это с акселерацией или без ? В Haiku были свои дрова.
1000 Мб/с это с акселерацией или без ? В Haiku были свои дрова.
VESA режим. По-умолчанию 2D акселерация в Haiku отключена - нужно в исходниках её включить и скомпилировать систему заново. Я этого не делал.
Maxis
Очень интересно. Непонятнор откуда такой прирост. Биос должна настроить шину на максимальную скорость. А драйвер агп без акселерации ни к чему. А что за тест ? Надо посмотреть исходники. Их svn у меня есть.
Очень интересно. Непонятнор откуда такой прирост. Биос должна настроить шину на максимальную скорость. А драйвер агп без акселерации ни к чему. А что за тест ? Надо посмотреть исходники. Их svn у меня есть.
Названия теста я уже не помню. Брал с haikuware. Тест простенький: рисуется окошко фиксированых размеров через системный API. Тестировал следующим образом: удалял драйвер - 133Мб/с; с драйвером - около тысячи.
FireWall
A - я рассматривал только вариант 1) - см. первый пост сабжа. О микроядерной архитектуре говорено много, а сделано не густо.
Б .
Полноценные видеодрайверы есть только для радеонов. Для NV их не будет никогда, аминь. Для intel-графики - только если кто-то проплатит их разработку (кстати, этот вариант весьма вероятен). Из универсальных вариантов стаются только VESA-режимы, но и те не дают друг другу полноценно функционировать.
Я помню золотые слова diamond`a: "Колибри - это не только очень быстрая, но еще и очень маленькая ОС". Этот подход (плюс универсализация кода для всех мыслимых платформ) иногда даёт совершенно обратный результат: код в итоге получается медленным и рыхлым. А разные "оптимизирующие" трюки (иногда за гранью "высшего пилотажа") еще и делают его крайне ненадежным. VESA2 + window.inc - один из самых показательных примеров (есть и другие). Такие узлы надо не расплетать - рубить.
В - только разумеется рубить не по живому. Потренируемся "на кошечках", в боковой ветке, а потом сравним результаты.
Но в любом случае имхо назрел вопрос раздельной компиляции ядра для разных платформ. Так можно снять из ядра 30-40 килобайт ненужного кода и дублирующих проверок. И только так можно обеспечить эффективную работу системы на все более непохожих друг на друга платформах.
Наилучшим вариантом здесь мне видится аналог линуксовского config.h
A - я рассматривал только вариант 1) - см. первый пост сабжа. О микроядерной архитектуре говорено много, а сделано не густо.
Б .
Полноценные видеодрайверы есть только для радеонов. Для NV их не будет никогда, аминь. Для intel-графики - только если кто-то проплатит их разработку (кстати, этот вариант весьма вероятен). Из универсальных вариантов стаются только VESA-режимы, но и те не дают друг другу полноценно функционировать.
Я помню золотые слова diamond`a: "Колибри - это не только очень быстрая, но еще и очень маленькая ОС". Этот подход (плюс универсализация кода для всех мыслимых платформ) иногда даёт совершенно обратный результат: код в итоге получается медленным и рыхлым. А разные "оптимизирующие" трюки (иногда за гранью "высшего пилотажа") еще и делают его крайне ненадежным. VESA2 + window.inc - один из самых показательных примеров (есть и другие). Такие узлы надо не расплетать - рубить.
В - только разумеется рубить не по живому. Потренируемся "на кошечках", в боковой ветке, а потом сравним результаты.
Но в любом случае имхо назрел вопрос раздельной компиляции ядра для разных платформ. Так можно снять из ядра 30-40 килобайт ненужного кода и дублирующих проверок. И только так можно обеспечить эффективную работу системы на все более непохожих друг на друга платформах.
Наилучшим вариантом здесь мне видится аналог линуксовского config.h
Who is online
Users browsing this forum: Bing [Bot] and 1 guest