LinuxForum.Fans
Тема

Релиз ядра Linux 3.7. Обзор новшеств

Автор: Lupo_Alberto 26 сообщений 4968 просмотров
#289957

Линус Торвальдс представил релиз ядра Linux 3.7. В новой версии представлена большая порция существенных изменений, связанных с архитектурой ARM: возможность формирования многоплатформенных ARM-сборок, поддержка архитектуры AArch64 (ARM64), адаптация Xen для работы на процессорах ARM Cortex A15. Из других улучшений можно отметить реализацию пространства имён для идентификаторов пользователей, возможность проверки цифровой подписи при загрузке модулей ядра, использование инструкций SMAP для защиты от эксплуатации уязвимостей в ядре, поддержку протоколов SMB2.1 и VXLAN, реализацию GRE и NAT для IPv6, поддержку режима TFO на стороне сервера.

В новую версию принято 10409 исправлений от более чем 1200 разработчиков, размер патча - 95 Мб (изменения затронули 15886 файлов, добавлено 1570793 строк кода, удалено 1246965 строк). В связи с изменением структуры размещения и переработкой иерархии дириекторий некоторых частей ядра, размер нынешнего патча более чем в два раза больше по сравнению с прошлыми выпусками. Около 33% всех представленных в 3.7 изменений связаны с драйверами устройств, примерно 23% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 6% связано с сетевым стеком, 3% - файловыми системами и 3% c внутренними подсистемами ядра.

Наиболее интересные новшества ядра 3.7:

  • Аппаратные архитектуры

    • Поддержка 64-разрядной архитектуры AArch64 (ARM64), реализованной в процессорах, поддерживающих набор команд ARMv8. 64-рязрядная архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON, такими как инструкции для ускорения работы алгоритмов шифрования AES и SHA-1/SHA-256. Реализация AArch64 для Linux поддерживает расширенную 39-разрядную адресацию памяти для ядра и пользовательского уровня и предоставляет режим совместимости, позволяющий выполнять 32-битные программы, собранные для архитектуры ARMv7 (ARM EABI). В настоящее время устройства на базе ARMv8 пока находятся на стадии тестирования прототипов, поступление в продажу первых ARMv8-систем ожидается в следующем году;
    • Унификация кода поддержки архитектуры ARM и обеспечение возможности формирования многоплатформенных ARM-сборок. Если ранее требовалось собирать отдельный вариант ядра для каждого типа SoC, то начиная с выпуска 3.7 появится возможность собрать одно ядро, которое будет содержать поддержку различных ARM-платформ. Унифицированная сборка ядра 3.7 сможет работать на платформах Calxeda Higbank (серверы HP Moonshot), Versatile Express (эталонная плата, поддерживается эмулятором QEMU), Marvell ARMADA (от мини-серверов до телеприставок), Altera SoC FPGA и Picohip picoXcell (мини-базовые станции для офисов). В будущих выпусках ядра число поддерживаемых платформ будет расширено. Указанное нововведение существенно упростит жизнь разработчикам дистрибутивов для ARM-систем, которым теперь не придётся формировать отдельный загрузочный образ для каждой ARM-платформы.
  • Виртуализация и безопасность

    • Поддержка механизмов виртуализации Xen для систем на базе процессоров ARM Cortex A15. Таким образом Xen стал первым гипервизором, поддерживаемым в Linux на платформе ARM. Представленный для интеграции в ядро код основан на использовании аппаратных расширений для обеспечения виртуализации, поддерживаемых архитектурой ARMv7. Особенностью реализации Xen для ARMv7 является отсутствие разделения в поддержке запуска гостевых систем в режиме паравиртуализации (PV) и аппаратной виртуализации (HVM). Вместо этого используется один комбинированный режим запуска гостевых систем, напоминающий запуск PV поверх HVM без необходимости эмуляции оборудования при помощи Qemu. Гостевые системы при этом всегда запускаются в режиме полной виртуализации, но для доступа к сетевым и блочным устройствам должны использовать специальные паравиртуальные драйверы (т.е. для гостевых окружений не требуется модификация ядра системы, но необходимо наличие нескольких драйверов).
    • Добавлена рабочая реализация пространств имён для идентификаторов пользователей (user namespaces). Указанная возможность позволяет сформировать в контейнерах собственные наборы идентификаторов групп и пользователей, а также связанные с ними привилегии (например, в каждом контейнере может быть свой root);
    • Поддержка набора инструкций SMAP (Supervisor Mode Access Prevention), реализованного в процессорах Intel на базе микроархитектуры Haswell. Задействование SMAP в ядре позволяет блокировать доступ к данным в пространстве пользователя из привилегированного кода, выполняемого в пространстве ядра (по аналогии с тем, как добавленная в ядре 3.0 поддержка SMEP не позволяет переходить из режима ядра к выполнению кода, находящегося в пользовательских областях). При обеспечении оборудованием поддержки инструкций SMAP, представленные средства защиты будут включаться автоматически, что существенно усложнит эксплуатацию уязвимостей в ядре, вызванных такими ошибками, как разыменование NULL-указателя;
    • Поддержка загрузки модулей ядра с проверкой их корректности по цифровой подписи. Указанная возможность разработана в рамках проекта по обеспечению поддержки загрузки верифицированного ядра Linux на системах с включенным режимом UEFI Secure Boot. При активации данной опции, ядро будет отвергать загрузку любых модулей для которых нет корректной цифровой подписи. Поддерживается и отладочный режим, при котором выполняется проверка, но она не влияет на загрузку модулей и информирует о проблемах через лог. При сборке ядра, при наличии открытого и публичного ключей процесс создания подписей для собираемых модулей выполняется автоматически, а проверочный ключ интегрируется в файл crypto/signature/key.h. Отмечается, что генерация цифровых подписей немного замедляет процесс сборки;
    • В соответствии с пожеланиями разработчиков systemd, расширенные атрибуты для управляющих групп (control groups) могут задаваться через создание иерархии директорий. При использовании неиерархических групп управления во вложенных элементах иерархических групп будет выдаваться ошибка. Кроме того, в cgroups добавлена поддержка xattr;
  • Дисковая подсистема, ввод/вывод и файловые системы

    • В файловую систему Btrfs добавлена поддержка "hole punching", технологии при которой часть файла можно пометить как более неиспользуемую. Это позволяет файловой системе и носителям (например, накопителям SSD) заранее освобождать неактуальные неиспользуемые блоки в середине файла. Для Btrfs также ускорена работа системного вызова fsync, что позволило повысить производительность записи для виртуальных машин, образы которых размещаются поверх Btrfs. Например, выполнение теста, в которой каждая операция записи завершалась вызовом fsync() ускорилось для SATA-диска с 82 до 140 Кб в сек., а для Fusion IO-накопителя с 431 до 2532 Кб/cек. Из других изменений отмечается исключение возможности одновременного использования опций монтирования compress и nodatacow и устрание ограничения на число жестких ссылок (hardlink) в одной директории;
    • В файловую систему Ext4 добавлена поддержка изменения размера на лету для 64-разнядных ФС (размером более 16 Тб) и ФС с meta_bg. Существенно ускорены операции удаления (unlink) файлов и их усечения (truncate). Добавлена опция монтирования max_dir_size_kb, которая позволяет задать максимальный лимит размера директории. Возобновлена поддержка опции "-o discard" при неактивном режиме журналирования;
    • В реализации файловой системы CIFS обеспечена поддержка протокола SMB2.1. Статус поддержки SMB2 на уровне ядра переведен из разряда "поломанный" в "экпериментальный";
    • Добавление модуля IMA (Integrity Measurement Architecture) для обеспечения хранения и проверки базы хэшей для проверки целостности файлов и связанных с ними метаданных. Данные для контроля целостности сохраняются как атрибуты xattr;
    • В реализацию программных RAID 0/1/10/5 (MD RAID) и файловой системы JFS добавлена поддержка команды TRIM (discard), которая позволит увеличить производительность при работе с SSD-накопителями и повысить их срок службы;
    • В подсистеме MD RAID добавлена поддержка пересборки массивов RAID10;
    • Перевод реализации NFS 4.1 в разряд стабильных (ранее поддержка NFS 4.1 была помечена как экспериментальная). В NFS [url=ttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=896526174ce2b6a773e187ebe5a047b68230e2c4] добавлена[/url] опция монтирования "migration", при которой возможна передача одинаковых для нескольких клиентов идентификаторов, допускающих реализацию схем для миграции состояний между клиентами;
  • Сетевая подсистема

    • Поддержка протокола туннелирования GRE (Generic Routing Encapsulation) для IPv6;
    • Поддержка трансляции адресов (NAT, MASQUERADE, NETMAP, REDIRECT, а также хелперы для протоколов FTP, IRC, SIP и amanda) для IPv6. IPv6 NAT позволяет осуществить подмену адресной информации в пакетах IPv6 в соответствии с заданными правилами трансляции, примерно так как это делается в классическом трансляторе адресов для IPv4. Для реализации поддержки IPv6 NAT, существующий в ядре код netfilter был переработан с целью разделения модуля NAT на два независимых компонента, один из которых включает в себя ядро подсистемы NAT, а второй реализует поддержку того или иного протокола третьего уровня;
    • Поддержка режима быстрого открытия TCP-соединений (TFO - TCP Fast Open) на стороне сервера. Режим TFO позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения, и давая возможность отправки данных на начальном этапе установки соединения. В ядре 3.6 поддержка TFO была ограничена возможностью управления только на стороне клиента в процессе создания соединения. Теперь TFO может быть активирован и по инициативе серверной стороны;
    • Поддержка протокола
      VXLAN для туннелирования виртуализированных сетей второго уровня поверх сетей третьего уровня. Указанный протокол позволяет обойти ограничение на 4096 VLAN-ов (в VXLAN используются 24-разрядные идентификаторы);
  • Память и системные сервисы

    • Началась интеграция результатов работы] по рефакторингу заголовочных файлов, конечной целью которой является разделение по разным иерархиям директорий заголовочных файлов для UAPI (Userspace API) и KAPI (Kernel API). Подобное разделение позволит более явно выделить необходимые для использования в пространстве пользователя заголовочные файлы, которые теперь перемещены в include/uapi и arch/$(ARCH)/include/uapi. Например, разработчики дистрибутивов получат возможность подготовить сокращённый пакет (включить только заголовки UAPI) для сборки пользовательских компонентов, завязанных на API ядра. В рамках проекта также проведена работа по упрощению сложившейся усложнённой и запутанной схемы внутренних зависимостей между заголовочными файлами, например, разработчики сталкивались с проблемами добавления inline-функций в заголовочный файл, так как нередко в таких функциях необходимо было использовать компоненты из других заголовочных файлов. В ядро 3.7 включены не все из предложенных патчей, многие изменения перенесены на следующий выпуск ядра;
    • Загрузчик прошивок теперь пытается загрузить файлы непосредственно из файловой системы, без задействования udev. Наличие прошивок пока проверяется в /lib/firmware, в будущем будут добавлены гибкие настройки выбора пути;
    • API для кэширования прошивок, позволяющий перед переходом в спящий режим поместить в память копии прошивок для активно используемых устройств, что позволит гарантировать наличие прошивок в памяти в момент пробуждения системы;
    • В системный вызов epoll_ctl() добавлена опция EPOLL_CTL_DISABLE, позволяющая отключить пулинг для указанного файлового дескриптора;
    • В утилиту perf добавлена команда trace ("perf trace PID") по выполняемым функциям напоминающая утилиту strace, но дополнительно позволяющая отображать события не связанные с системными вызовами;
    • Добавлена новая утилита "trace agent", использующая virtio для эффективного перемещения данных о трассировке из гостевой системы в окружение хоста;
    • Добавлена утилита acpidump для записи в текстовый файл дампа системных таблиц ACPI;
    • В файл конфигурации ядра добавлена опция CONFIG_COREDUMP, позволяющая исключить при сборке код для генерации core-дампов при крахе процессов и код для поддержки связанных с управления дампами sysctl-вызовов. Использование опции позволяет сократить размер ядра на несколько килобайт;
  • Оборудование

    • Полностью переписана базовая часть драйвера Nouveau, в которой теперь учтены дополнительные особенности чипсетов NVIDIA, которые не были известны в момент написания ранее доступной базовой части драйвера. Целью переработки было общее упрощение архитектуры и её адаптация к дальнейшему обеспечению поддержки дополнительных функций, таких как SLI (Scalable Link Interface). Кроме того, в состав драйвера добавлен код для обеспечения управления кулером, работающий на устройствах серии NV40 и NV50. Добавлена поддержка загрузки собственных прошивок для карт GeForce 600 с Kepler GPU (NVE0);
    • В драйвере i915 для видеокарт Intel улучшена работа кода для настройки устройств вывода, добавлен экспорт через Sysfs информации о частоте и режимах энергосбережения GPU, добавлена предварительная поддержка графических ядер для будущих моделей процессоров серии Haswell и ValleyView, которые ещё не выпущены на рынок;
    • В драйвере Radeon улучшен код для управления конфигурацией нескольких мониторов, расширена поддержка управления фоновой подсветкой на ноутбуках, сокращено потребление памяти за счёт поддержки двухуровневых таблиц страниц памяти (2-level VM pagetables);
    • Проведена реорганизация подсистемы Video4Linux 2, код драйверов теперь размещён по поддиректориям в зависимости от используемого типа шины. Переписан код для обеспечения работы DVB-устройств с интерфейсом USB;
    • В звуковую подсистему ALSA добавлен новый API (PCM channel-mapping API) для управления звуковыми каналами, позволяющий настроить привязку каналов или получить точные данные о том, какой канал привязан к какой позиции в пространстве (например, для surround 4.0 используются каналы - левый впереди, правый впереди, левый сзади, правый сзади);
    • Поддержка Raspberry Pi, а также SoC Broadcom BCM2835, Micrel KS8695; Freescale P5040DS, Freescale / iVeia P1022RDK и MIPS Technologies SEAD3;
    • Для приложений, работающих на системах на базе архитектуры s/390, добавлена возможность использования аппаратной транзакционной памяти System zEC12;
    • Поддержка игровых пультов Sony PS3 BD;
    • Поддержка сетевых контроллеров Silicom Bypass, Freescale XGMAC MDIO и Microchip MRF24J40;
    • Поддержка модемов ST-Ericsson STE и звуковых плат Wolfson Bells;
    • Поддержка USB-контроллеров: Broadcom BCM63xx, Marvell USB 3.0 PHY, ZTE USB-to-serial переходников и плат Cambridge Electronic Design 1401 USB;

Источник »
Главная ссылка к новости »

#289993
"Lupo Alberto" написал:
Nouveau
"Lupo Alberto" написал:
i915 для видеокарт Intel
"Lupo Alberto" написал:
Radeon

Что-то я совсем отстал от жизни. Драйвера для xorg в ядре?
Если нет, то совпадающие названия что-ли?
UPD, консольные видеодрайвера походу. Вылетело из головы совсем,- в menuconfig видел я их или нет.
Если кто надуху как ковырял .config - может напомните....

#290025

Ну да. Драйвера для Xorg в ядре. Нисколько не консольные. Хотя они и фреймбуфферные тоже.

#290036

Ну может в ubuntu 13.04 запилят там покатаю )))
второй абзац вообще хорош )))

#290094
"bobr" написал:
Нисколько не консольные. Хотя они и фреймбуферные тоже.

Под словом консоль- имел в виду именно фреймбуфер.

"bobr" написал:
Ну да. Драйвера для Xorg в ядре.

Просветите, давно ли они в ядре- драйвера для xorg.
Однозначно помню- собирал драйвера для xorg отдельно. (Или как вариант, ставились всегда в систему даже именно открытые драйвера для иксов именно помимо ядра,- не в пакете ядра, а как пакеты- зависимости иксов,- то есть нет в системе иксов- тогда нет и этих драйверов для него).

И всё-таки. Драйвера для фреймбуфера fbdev это всё-таки нечто более простое, чем иксовые драйвера.
К примеру груб увидали на экране,- уже работает фреймбуфер,- а будут ли там еще иксы- это вопрос.

так как фреймбуфер просто выполняет отрисовку кадров в область видеопамяти.
А драйвера для иксов призваны реализовывать более сложные вещи,- такие как поддержку опенGL, (каких-нибудь)D итд.
К примеру:
xf86-video-nouveau-1.0.4.tar.bz2
(вот http://ftp.osuosl.org/pub/blfs/svn/Xorg/ или вот
http://xorg.freedesktop.org/releases/individual/driver/ )

Если я в чем тут неправильно пишу,- прошу раскидать как надо.

#290136

У каждого драйвера видеокарты для иксов есть юзерспейсовая либа, которую подгружает икс-сервер, и есть ядерный модуль, который непосредственно обращается к железке.
Давно ли так? Сколько себя помню - всегда так было. А это по крайней мере, с версии 2.4.
И модули ядра, такие как radeon или nouveau являются не только драйверами для иксов, но и для фреймбуффера.
А OpenGL и прочие "более сложные вещи" реализованы отнюдь не в драйверах для иксов. Они реализованы в самой железке. А обращаться к железке может только ядро. Из юзерспейса обращаться к железу нельзя.

#290137
"bobr" написал:
не в драйверах для иксов. Они реализованы в самой железке

Но, поддержка в драйвере-то должна быть?

"bobr" написал:
Они реализованы в самой железке. А обращаться к железке может только ядро. Из юзерспейса обращаться к железу нельзя.

Правильно, устанавливая драйвер для иксов,- установим и еще модуль для ядра,- который и будет подгружаться.

"bobr" написал:
Давно ли так? Сколько себя помню - всегда так было. А это по крайней мере, с версии 2.4.

То есть 3D ускорение реализовано прям в ванильном ядре?- По вашему так выходит...

А на сомом-то деле для Этого 3D (как пример) нужет отдельный иксовый драйвер,- отдельно он от ядра идет,- причем даже в случае открытого интел.И этот драйвер отлдичается от фреймбуферного драйвера,-
то есть мое предположение оказывается верным- названия совпадают,- сами драйвера -нет.

#290138

.....Вот, нашел у себя на вскидку конфиг от ядра по-новее((3.1.0), которое, всмысле я сам ковырял):

text
#
# Graphics support
#
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD64=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_AGP_EFFICEON=m
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_TTM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_KMS is not set
CONFIG_DRM_I810=m
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_KMS is not set
.................

-понял я про что речь идет, это никак не искосвые драйвера, это и есть
фреймбуфер==консоль.
И названия( в целой части в смысле,- в общем то есть) совпадают с соотвествующими иксовыми.

#290139

Могу еще согласиться с такой концепцией:
что это части одного и того же драйвера,- одна часть в ядре,- другая по желанию- для иксов, если они предусмотрены в системе. Хотя,- это разные тарболы с кодом. То есть, если называть частями,- то в широком смысле.

ЗЫ
bobr,- я это не срача ради, а истины для. ;)

#290140
redux написал:

То есть 3D ускорение реализовано прям в ванильном ядре?- По вашему так выходит...

Прям да. Еще раз повторю: 3D реализовано в железе видеокарты. Иксовые драйвера - это только библиотеки для обращения к функциям ядерного модуля.

redux написал:
названия совпадают,- сами драйвера -нет.

Совпадают. Библиотеки для иксов и модули ядра - это два компонента одного драйвера. Одно без другого не работает.
Скажем, есть свободные дрова (nouveau) для нвидии и есть закрытые(nvidia). И, скажем, иксовый драйвер nouveau никак не сможет работать с модулем ядра nvidia и наоборот. Тоже самое можно сказать и о радеонах.

#290142
"bobr" написал:
Прям да. Еще раз повторю: 3D реализовано в железе видеокарты.

Ну, мы в смысле про код же говорим,- код заставляет работать железо, так вот где какой код.

Свою туманность я понял и для себя разъяснил,
я думал, что для фреймбуфера один какой-нибудь "fbdev-драйвер" в ядре,-
а оказалось - для каждой фирмы свой (заметьте фирмы, а не карты).
(И главное, ведь не обращал на это внимание, когда включал это дело мудулями в ядро.)

bobr, - спасибо подтолкнул в нужном направлении. :)

#290144
"bobr" написал:
redux пишет:

То есть 3D ускорение реализовано прям в ванильном ядре?- По вашему так выходит...

Прям да.

Вот тут только не согласен, идущий в составе ядра прям от линуса драйвер,- 3D и остальных вкусностей не несет,- оно заработает только под управлением иксового драйвера, -то есть только в нем и содержится. Во фреймбуферных же драйверах (хоть частями их называйте) - только и есть что простая прорисовка в видеопамять.(хотя, это если всё-таки упрощенно,- а если разбираться, то OpenGL можно реализовать без иксов, но на примере 3D- да )

#290201

Если я ничего не путаю, то код 3D как раз не в иксовых дровах, и для работы иксов 3D не нужно. То о чем вы говорите реализовано в библиотеке Mesa, которую используют свободные дрова. Либо в своих вендорских либах в случае проприетарных дров.

#290210
"bobr" написал:
код 3D как раз не в иксовых дровах, и для работы иксов 3D не нужно.

Как раз таки 3D используют приложения,- работающие как клиенты иксов, и больше никто. То есть 3D таки всегда работает через иксы (экзотику и всякие вайланды не берем сейчас в рассмотрение). Хотя если разбираться, кто первичнее в этой цепочке,- то конечно 3D дается мезой. Но реализовывается то оно на практике только иксами. Нету у нас 3D во фреймбуфере:

Ну вот, упомянутое вами Mesa, в лице mesa-utils: попробуйте перейти в истинную консоль и запустить хоть glxinfo, хоть glxgears,- не для фреймбуфера суть они,- ибо даже дисплея не обрящут.

С другой же стороны, при сборке xorg'a из сорцов,- драйвера его собираются именно обязательно,- никакой даже возможной замены для них в уже готовом на данной машине и запущенном ядре даже и не мыслимо.

С 15й стороны, при установке xorg'a в пакетном дистре,- свои драйвера он тянет лишь при собственной установке.
Не поставьте xserver-xorg-video-intel, который тянется за xorg'ом, а дайте ему всего лишь vesa-драйвер,- и какое у вас будет 3D в иксах (да хоть где)?-Никакого.
А ведь это не смотря на то, что Mesa ваша пашет при этом во всю в своих ядерных модулях. Вот и получается, что ксоргу нужны собственные 3D -дрова. И то, что они традиционно носят имена своих фирм,- так же как и соотвествующие DRM-драйвера в ядре,- породило эту тему.

#290213
"redux" написал:
Хотя если разбираться, кто первичнее в этой цепочке,- то конечно 3D дается мезой. Но реализовывается то оно на практике только иксами. Нету у нас 3D во фреймбуфере

Размышления над этой темой уже породили во мне сомнения.

Поставим вопрос максимально конкретно:
1.Имеем на машине систему без иксов.
2.Для упрощения задачи- карта интел,- (проприетарщину для чистоты экперимента не впутываем).

Вопрос: Можно ли как либо задействовать 3D ускорение (и ускорение чего) на такой машине-системе?

Ну, пусть ситуация типа такой, феерической: "пишем игру с 3D без иксов". Что-то мне кажется, для того, чтобы задействовать 3D-рендеринг, мы должны будем написать свой драйвер-надстройку для ядерного DRM-модуля.-То есть не хватит нам модуля DRM ядра, или как?




- И если о ней- о мезе. Она требуется то в системе только иксам,- ну тупо по blfs знаю,- больше сослаться не на что на вскидку.

{И рядом вопросик:

"bobr" написал:
в библиотеке Mesa, которую используют свободные дрова. Либо в своих вендорских либах в случае проприетарных дров.

- и вот здесь (о проприетрщине),- не свои ли модули ( .ko ) проприетарная установка пихает?- как самодостаточные,- чего им гордым-то через линусовские к железу обращаться,- они же тут уже не юзерспейс- они сами -- ядро(ну части его)}


Вот как-бы по-подробнее и по-яснее тут, а?

#290217

Собственно на основной вопрос отвестить помогла википедия:

"вики" написал:
Mesa ....на сегодняшний день является частью X.Org.

- то есть не будет никакого 3D без иксов. И драйвера у ксорга на это дело свои- отдельные,- насколько может быть отдельный код в отдельном тарболе на серверах проекта Xorg (а ни на kernel.org)

И чтобы попользовать 3D без иксов надо это дело в новый проект упаковывать....- ну то есть только гипотетически так можно- в принципе,- на на практике-шиш.

#290218

Я, конечно, в этом не очень разбираюсь, но то, что 3D сейчас используется в основном иксами и их клиентами-приложениями еще не значит, что на машине без иксов нельзя смотреть фильмы . И 3D здесь присутствует, хотя, наверное, в виде программного ускорения, то есть, весь обсчет графики делается CPU, а не GPU.

#290220
"yars" написал:
Я, конечно, в этом не очень разбираюсь, но то, что 3D сейчас используется в основном иксами и их клиентами-приложениями еще не значит, что на машине без иксов нельзя смотреть фильмы . И

Для воспроизведения фильма не нужно просчитывать мильоны треугольников в секунду,- это не 3D.
(к примеру кино можно смотреть на vesa-драйвере, а он, как известно 2D-драйвер).

"yars" написал:
не значит, что на машине без иксов нельзя смотреть фильмы .

- конечно не значит, mplayer прекрасно показывает кино в консоли на машине, где вообще нет иксов.- он кадры свои во фреймбуфер передает и все,- это не 3D.

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

"yars" написал:
Я, конечно, в этом не очень разбираюсь,

- если б я разбирался,- я бы тут ничего не спрашивал. ;)

#290222
text
lupo@gentoo-laptop ~ % uname -a
Linux gentoo-laptop 3.7.0-funtoo-r0a #1 PREEMPT Wed Dec 12 20:17:13 FET 2012 i686 Genuine Intel(R) CPU T1350 @ 1.86GHz GenuineIntel GNU/Linux
#290223

Lupo Alberto,- ядро собрали,- поздравляем. А мы тут около вашего ядра вопросы обсуждаем.- Присоединяйтесь :)

Войдите или зарегистрируйтесь, чтобы ответить.