Придумал тему.

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

Обоснование.

Для большого числа систем низкая скорость обмена с видеопамятью является ключевым фактором, ограничивающим быстродействие системы. Например для моего i5-2400+H67 отрисовка 30 кадров в секунду с разрешением 1280*1024*32bpp приводит к 100% загрузке процессора. При этом скорость обмена с видеопамятью составляет всего 150Мb в секунду. 100% загрузка в этом случае означает лишь то, что процессор подавляющую часть времени проводит в ожидании завершения операции обмена с видеопамятью.Его можно сравнить с автомобилем, стоящим в пробке с выключенным мотором.

Перенос графических операций на другое физическое ядро:
1. Освободит основной процессор для выполнения полезной работы.
(То есть он будет спать на hlt 99% времени, как ему и положено )
2. Снизит нагрузку на L1 и L2 кеш.
Все графические операции в ядре выполняются с проверкой принадлежности пикселя при помощи байтовой карты окон. Это приводит к тому, что при выполнении графических операций полезные данные из L1 и L2 вытесняются данными оконной карты. При этом низкая скорость видеопамяти существенно снижает пользу от кеширования оконной карты. Физические ядра современных процессоров имеют индивидуальные L1/L2 кеши. Таким образом выполнение графических операций другим ядром значительно снизит нагрузку на кеш-память основного ядра. (И мы сможем убить кеш битмапами )

PROFIT реализатора идеи.
Практические навыки определения числа физических ядер в MP системе, инициализации AP и принципов работы LAPIC.
Глубокое понимание механизмов синхронизации доступа к данным, необходимости синхронизации TLB, а также блокировки и взаимной блокировки ядер.
Бесценный опыт трассировки и отладки многопоточного кода в SMP версии Bochs.

P.S. Я убрал смайлики.

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

Для студентов изучающих SMP самое то. Это на порядок проще чем реализация полноценной SMP системы, но все подводные камни MP присутствуют и испытываются на собственной шкуре.
Race conditions, deadlock, TLB inconsistency ( всех этих слов на русском нет ©Наше всё). Если хочешь по настоящему научиться, Колибри самый подходящий вариант. Ядро достаточно простое, своего SMP нет, а все необходимые условия для запуска AP есть. Эмуляция виртуального GPU задача не самая сложная. Можно посмотреть на VMware или придумать свой API. Реально получить опыт, который не даст ни один учебный курс и штудирование всего Open source SMP кода.

Serge
Задачка что надо: сложная, интересная, оригинальная, полезная.
И еще - покажет преимущества Колибри как идеальной среды для low-level экспериментов.

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

в самую точку

Из хобби ос перемещаемся в сегмент обучения студентов. Жаль только в ту пору прекрасную жить не придется ни мне ни тебе в России так и будут плодить дельфи-программистов.

art_zh
Кеш: Такая уж наша боярская доля.

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

Mario
Надо смотреть. Всё относилось только к физическим ядрам. L1 там как правило индивидуальный. Всякие гипертрейдинги и бульдозерные модули не в счёт. Хотя и с них должен быть профит.
Единственный непонятный момент это контроллер памяти. Как он обрабатывает такие медленные запросы и не встанет ли на них. Чего я не не понимаю, так это почему у меня такая низкая скорость записи. Ведь это физически та же двухканальная DDR3 что и системная память. Откуда такие тормоза ?

Прошёл год... Встречайте Google Summer of Code 2013. В этот раз вы как хотите, а заявку я подам

Поддерживаю, заявка на SummerCode нужна. Однако нужна страница, например как у QEMU http://wiki.qemu.org/Google_Summer_of_Code_2012 или у других проектов участвующих в GSoC

XVilka wrote:Поддерживаю, заявка на SummerCode нужна. Однако нужна страница, например как у QEMU http://wiki.qemu.org/Google_Summer_of_Code_2012 или у других проектов участвующих в GSoC

Так вот зачем ты мне вчера вечером админа на Вики предлагал Ну давай теперь админа, что уж.

Клёвая идея!

Время поджимает. Надо заполнять эту страницу http://wiki.kolibrios.org/wiki/Google_S ... _Code_2013 содержанием, и создать отдельную страницу для собственно идей/возможных проектов. См., например, как это сделано у coreboot http://www.coreboot.org/GSoC и http://www.coreboot.org/Project_Ideas

Прошу обратить внимание на таблицу внизу - со списком координаторов и менторов. Также, прежде чем подаваться в менторы, необходимо осознать меру ответственности и быть способным уделять время своим студентам каждую неделю

продвинутый браузер - пара менторов найдется

подсистема шрифтов и обработки клавиатуры - ментор найдется

файловые системы - пара менторов найдется

офисные программы (порт или даже доработка таблицы и какого-то из имеющихся редакторов) - ?

драйвер FireWire или другой шины. Как вариант доделать менеджер устройств Serge - пара менторов найдется

сетевые протоколы или протоколы мессенджеров или драйверы сетевых карт - ментор найдется

компилятор, интерпретатор какого-то популярного языка (JAVA, Perl?) - ? На худой конец помощь Джонухаунду в порте его IDE.

драйверы принтеров - ?

драйверы сканеров - ?

поддержка адресации больших жестких дисков - ментор найдется

драйверы видеокард с хардварным ускорением - ментор найдется

Что не нравится - выкидывайте (даже у очень известных проектов редко больше 5-6 студентов) и ищите/заманивайте студентов вконтакте, фейсбуке...