Представлен (http://lists.freedesktop.org/archives/mesa-dev/2013-February... релиз свободной реализации OpenGL API - Mesa 9.1. Новая версия примечательна прежде всего реализацией поддержки OpenGL 3.1 для видеокарт Radeon и OpenGL ES 3.0 для некоторых карт Intel. В настоящий момент ветка Mesa 9.1 имеет экспериментальный статус, после проведения окончательной стабилизации кода, будет выпущен стабильный релиз 9.1.1.
Основные улучшения (http://www.mesa3d.org/relnotes-9.1.html) в Mesa 9.1:
- Продолжение обеспечения поддержки OpenGL 3.1 API. В дополнение к драйверу i965 (Intel Sandy Bridge и Ivy Bridge), поддержка OpenGL 3.1 теперь реализована и для карт AMD серий Radeon HD2000-HD6000 (драйвер R600g). Частично поддержка элементов OpenGL 3.1 присутствует в драйверах Softpipe, Nouveau NVC0 (карты NVIDIA с GPU Fermi, такие как GeForce 400/500) и NV50 (карты GeForce 8), но пока реализована не полностью;- Поддержка OpenGL ES 3.0 для графических подсистем процессоров Intel семейства Ivy Bridge и Sandy Bridge (GPU HD Graphics 2000, 2500, 3000 и 4000). Примечательно, что организация Khronos Group официально сертифицировала свободный OpenGL стек MESA в сочетании с DRM-модулем ядра Linux 3.6 на предмет полной совместимости с OpenGL ES 3.0. Спецификация OpenGL ES 3.0 была выпущена (http://www.opennet.me/opennews/art.shtml?num=34500) в августе 2012 года и отличается такими особенностями, как поддержкой алгоритмов сжатия текстур ETC2 и EAC, улучшения в конвейере рендеринга, обновление языка шейдеров, расширенный набор обязательных текстур и полная поддержка текстур с плавающей запятой, 3D текстур, текстур глубины, текстур вершин, NPOT текстур, R/RG текстур, неизменных текстур, текстур 2D массивов и т.д.
- Для GPU серии Radeon X1000 обеспечена поддержка мультимэмплового сглаживания (MSAA, multisample anti-aliasing (http://en.wikipedia.org/wiki/Multisample_anti-aliasing));
- Добавлена поддержка новых расширений OpenGL:
- GL_ANGLE_texture_compression_dxt3- GL_ANGLE_texture_compression_dxt5
- GL_ARB_ES3_compatibility
- GL_ARB_internalformat_query
- GL_ARB_map_buffer_alignment
- GL_ARB_shading_language_packing
- GL_ARB_texture_buffer_object_rgb32
- GL_ARB_texture_cube_map_array
- GL_EXT_color_buffer_float
- GL_OES_depth_texture_cube_map
- Удалена поддержка систем, оставшихся без сопровождающих или находящихся в неработоспособном виде:
- VAAPI state tracker;
- Некорректная аппаратная реализация GL_NV_vertex_program из состава драйвера i965;
- swrast для GL_NV_vertex_program;- swrast для GL_NV_fragment_program;
- Прекращена поддержка OpenVMS;
- Использование makedepend для оценки сборочных зависимостей.
URL: http://lists.freedesktop.org/archives/mesa-dev/2013-February...
Новость: http://www.opennet.me/opennews/art.shtml?num=36207
У меня практический вопрос: у меня есть своя система на базе Yocto (OpenEmbedded, не важно). Что мне надо чтобы получить работающие опенсорсные драйвера и OpenGL и прочее? Собрать последнее ядро с последними драйверами + Mesa последней версии?Какие нужны компоненты чтобы тупо получить графический стек последнего поколения распоследней версии?
Я с трудом представляю, у меня в голове каша из иксов ядра и mesa. Понимаю что как минимум ядро и mesa должны быть последней версии. А X сервер? Могу ли я получить Qt/OpenGL вывод без X-сервера на основе Mesa?
drm (direct rendering manager) еще надо.
Так это же все равно дополнение иксов.
Мне принципиально не нужны иксы, и GUI на базе Qt с новой абстракцией, которой не так сильно иксы уперлись.
> GUI на базе Qt с новой абстракцией,А эта новая абстракция через что рисует?
> Так это же все равно дополнение иксов.Вас обманули, это иксы - дополнение к нему :)
Для начала стоит понять что иксы и opengl - по сути два разных мира, довольно мало пересекающихся между собой. Общего у них только то что они для отрисовки в конце концов юзают одни и те же низкоуровневые подсистемы ядра + у иксов есть расширение GLX, позволяющее GL программам оперировать окнами в иксовом окружении. В остальном это два разных мира, почти не пересекающиеся между собой.По большому счету из "драйверов GPU" можно выделить 3 куска.
1) Самая низкоуровневая часть - в ядре. Инициализация и совсем базовые вещи типа управления памятью, фактическое уталкивание команд в GPU, управление частотами/вольтаэами и прочая - делается ядром и его модулем драйвера соотв. GPU. Стало быть чем свежее кернел, тем лучше. Тем не менее, groundbreaking changes встречаются не так уж и часто.
1.1) Упомянутые сервисы ядра вывешиваются юзермоду через характерные либы - libkms, libdrm, ... - ими то и пользуются остальные (иксы, меса) для доступа к низкоуровневым услугам ядра по отрисовке, установке режимов и прочая.
2) Для ускорения графики в иксах есть иксовые драйвера ("DDX-drivers"). Если они есть - иксы выводят графику с ускорением. Если нету - значит без.
3) OpenGL в случае открытого стека рисует через MESA. А она в свою очередь при наличии либы для конкретной видеокарты - будет ускорять операции через оную. В конечном итоге все опять же будет отправлено подсистемам кернела.Это очень примерная картинка. Вот тут: http://habrahabr.ru/post/148954/ описано получше.
Во, оно. Стоять бояться. Наконец-то вы меня нашли... то есть, я - вас.Вот есть у меня два дистрибутива, в кажом и mesa и открытые драйвера, один сверхкомпактный, другой арч. Одна и та же видео, визуально похожие драйвера. Грузятся модули на dri и прочее, kms отрабатывает, всё по чинарю. В логах иксов практически одно и то же, никакого криминала, различные ati и radeon-модули грузятся.
Но. При этом один в месе грузит ati_dri, а второй активно требудет swrast и только swrast.
Внимание, вопрос: ОТКУДА ОНО ЗНАЕТ? Кто именно ему говорит, когда ati_dri, а когда swrast, и как его итить отучить от swrast и приучить к ati_dri?
Нашел где спрашивать, спроси на irc.freenode.net #radeon и #dri-devel, там похоже одни и те же сидят, без разницы.
Если KMS работает, значит модуль ядра radeon загружен. Дальше грузится видео драйвер (xf86-video-radeon). Видело драйвер пытается определить доступное 2d и 3d ускорение. Для 3d нужна libdrm собранная с поддержкой radeon (--enable-radeon), mesa (--with-gallium-drivers=r600,swrast). Если все так, то нужно смотреть лог x.org
> Если KMS работает, значит модуль ядра radeon загружен. Дальше грузится видео драйвер
> (xf86-video-radeon). Видело драйвер пытается определить доступное 2d и 3d ускорение. Для
> 3d нужна libdrm собранная с поддержкой radeon (--enable-radeon), mesa (--with-gallium-drivers=r600,swrast).
> Если все так, то нужно смотреть лог x.orgСпасибо! Чётко и по делу!
Еще бывает что нужный firmware для видеокарты отсутуствует в /lib/firmware/radeon
> Еще бывает что нужный firmware для видеокарты отсутуствует в /lib/firmware/radeonПри этом в dmesg ругань должна быть. При успешной загрузке микрокода в радеон будет нечто типа:
[ ...] [drm] Loading <наименование_GPU> Microcode
В Ubuntu 13.04 будет?
Поясните, Mesa - софтверный растеризатор, выполняет пайп на ЦПУ. Тогда причем здесь указанные видеокарты?
Mesa - это открытая реализация OpenGL, пока не сертифицмрованная, но вроде собираются. А на ЦПУ графику рисует llvmpipe, один из драйверов месы.
> Mesa - это открытая реализация OpenGL, пока не сертифицмрованная,Интель таки прошел сертификацию на соответствие OpenGL ES 3 с их открытым драйвером.
>софтверный растеризаторНет, в месе также лежат куски драйверов для всяких нуво и радеонов. Видеодрайвера размазаны по трём компонентам: ядро, Mesa и драйвера Xorg.
> Видеодрайвера размазаны по трём компонентам: ядро, Mesa и драйвера Xorg.Ну и наверное уже в этот список можно Wayland добавить.
> Ну и наверное уже в этот список можно Wayland добавить.Можно, только он где-то сбоку получается. Ну то-есть он юзает существующие подсистемы, но сам по себе - вроде бы не драйвер :)
Там нет драйверов
> Поясните, Mesa - софтверный растеризатор,Кто вам это сказал? Меса умеет использовать GPU для акселерации 3D операций. Софтварный используется только если у вас GPU нету.
Он просто пишет из прошлого и не в курсе, что Mesa ассимилировала Gallium.
Она и без галлиума аппаратно ускоряла 3D. Просто раньше драйверы были как сейчас Intel, вещь в себе. Gallium это просто более современный способ как написать эти самые драйверы.
> Она и без галлиума аппаратно ускоряла 3D. Просто раньше драйверы были как
> сейчас Intel, вещь в себе. Gallium это просто более современный способНо также есть мнение что и менее эффективный в плане скорости. Собственно интел потому и кладет на него. У них и так GPU тормозные, так что еще и в дровах тупить они не могут себе позволить.
>> Она и без галлиума аппаратно ускоряла 3D. Просто раньше драйверы были как
>> сейчас Intel, вещь в себе. Gallium это просто более современный способ
> Но также есть мнение что и менее эффективный в плане скорости. Собственно
> интел потому и кладет на него. У них и так GPU
> тормозные, так что еще и в дровах тупить они не могут
> себе позволить.Насколько я помню, когда создавался gallium, то на некоторых железках был 2-3х кратный прирост скорости по сравнению с тем, что было.
Интел кладет на него только потому, что разработчики не хотят переписывать свой код. Скорость здесь ни при чем.
> Интел кладет на него только потому, что разработчики не хотят переписывать свой
> код. Скорость здесь ни при чем.Тем не менее, по нагрузке на CPU интеловский драйвер лучше. А вот gallium до проца довольно прожорлив. Так что критика со стороны интеловских разработчиков не то чтобы совсем уж на пустом месте. Таки да, попытки трейса и профайлинга показали что 3D апликухи довольно много времени проводят в характерных IOCTL радеоновского драйвера. И проц оно жрет довольно убедительно. Ну а интел с своими дохлыми GPU не может позволить себе лишний оверхед.
АМДшные разработчики вообще те еще головотяпы в плане оверхеда и порой принимают какие-то странные и сомнительные по оптимальности решения. См. например тред от Вадима Гирлина (надеюсь правильно написал - Vadim Girlin) относительно LLVM (http://lists.freedesktop.org/archives/mesa-dev/2013-February.... А вот интель всерьез нацелился на выжимку максимального результата из того что есть, судя по всему. Вон они даже с валвой взаимодействуют. На полном серьезе рассчитывая гонять TF2 на открытом драйвере, без скидок. АМДшники в этом плане менее привлекательны, т.к. свой горбатый блоб допиливают вместо того чтобы довести до ума открытый драйвер, как это делает тот же интел. Ну и в результате походу решения принимаются "как проще девелопать" а не "как лучше результат для пользователей".
> поддержка OpenGL 3.1 и GLSL 1.40 теперь реализована и для карт AMD серий Radeon HD2000-HD6000 (драйвер R600g)Дык софт же все равно? У меня под HD5xxx только softpipe/llvmpipe и собирается.
> Дык софт же все равно? У меня под HD5xxx только softpipe/llvmpipe и собирается.Ээээ? http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drive... - очень интересный такой софт.
Чойта вдруг? Вполне хардварно. glxinfo должен говорить что-то типа: OpenGL 3.1 on R600 - то это полностью хардварно ускоренный OpenGL.
Я и говорю, что оно все софтверно. А теже шейдеры для r600g ускоряются только экспериментальным llvm рекомпилятором.
P.S. Я курил сайт Mesa и ./configure --help
Ну, это как бы технически не возможно, чтобы шойдеры были софварные, а OpenGL не совтварный.
Тащем-то компилятор шейдеров там и без llvm есть, и компилирует вполне gpu-инструкции.
> Тащем-то компилятор шейдеров там и без llvm есть, и компилирует вполне gpu-инструкции.Ну да. Глючит гражданина по черному. LLVM амдшникам интересен т.к. к немy OpenCL проще привинтить. Но код для VLIW он пока-что генерит отвратительнейше.
> Я и говорю, что оно все софтверно. А теже шейдеры для r600g
> ускоряются только экспериментальным llvm рекомпилятором.
> P.S. Я курил сайт Mesa и ./configure --helpДля разных видеокарт по разному. У кого то llvm, у кого то самописные решения.
> Для разных видеокарт по разному. У кого то llvm, у кого то самописные решения.С LLVM пока не все гладко. В Galluim драйвере R600g он себя пока показал, скажем так, не очень. Сливая по производительности при больших затратах на то чтобы вообще допинать его до рабочего состояния. Недавно разработчик Vadim Girlin недвусмысленно высказался про то что он думает про соотношение затрат сил к результату. В смысле, самопальный кодогенератор генерит для шейдеров R600 более хороший код с меньшими усилиями. Этот гражданин заоптимизил его так что он на Unigine Heaven benchmark втопил на еще 30% резвее. А вот допинать до таких же высот LLVM никто пока не смог. Как я понял, LLVM в курсе того что такое VLIW чуть менее чем никак. По поводу чего имеет большие проблемы с группировкой удачной инструкций в блоки. В результате требуется кастомный оптимизационный проход и смысл LLVM в результате становится не очевиден: работы нифига не меньше, кишки - сложнее, etc. Там в мэйллисте на этот счет любопытные дебаты.
> Я и говорю, что оно все софтверно.Вас глючит - большинство операций таки спихано в конечном итоге на GPU.
> А теже шейдеры для r600g ускоряются только экспериментальным llvm рекомпилятором.
И еще раз вас глючит, там есть и свой местечковый кодогенератор. LLVM генерит более паршивый код нынче, кстати. Потому как вообще не в курсах кто такие VLIW-ы и все это потребовало адовых костылей для LLVM. По мнению некоторых разработчиков (см. другое сообщение), местечковый кодогенератор проще допинывается при более хороших результатах.
Меса становится всё круче. Фичи третьего OpenGL это прежде всего упор на фрагментные шейдеры, что позволяет существенно улучшить реализм трёхмерных сцен.
> Меса становится всё круче. Фичи третьего OpenGLОни, кстати, почти добили третий. По большому счету им осталось геометрические шейдеры для 3.2 дожать (при том, сырая реализация уже есть, хоть и сырая) и GLSL 1.5. И вроде как все.
автор, посмотри внимательно в ссылке на вики упоминание о nv50
в этом тексте его нет и это название нигде не фигурировало на официальных бумагах
> автор, посмотри внимательно в ссылке на вики упоминание о nv50
> в этом тексте его нет и это название нигде не фигурировало на
> официальных бумагахЭто лишь ваши домыслы, именно NV50 оно и звалось изначально:
http://nouveau.freedesktop.org/wiki/CodeNames#NV50
https://bitbucket.org/thweber/linux_devkit8000/src/ae168d973...
оно изначально так называлось ДО выхода, такая же ситуация с gt200, который был изначально обозван g100
давайте везде g100 писать тогда?
> оно изначально так называлось ДО выхода, такая же ситуация с gt200, который был изначально обозван g100
> давайте везде g100 писать тогда?_Драйвер_ назывался и называется NV50. Вам даже ссылки на код указали, а вы всё на своём. Ну не переименуют разработчики nouveau драйвер, как бы вам этого не хотелось.
В новости все написано абсолютно верно, так как речь там про драйвер: "...в драйверах Softpipe, Nouveau NVC0 .... и NV50 (GPU GeForce 8)...".
претензии снимаются, но в новости совершенно неочевидно что под nv50 понимается именно драйвер нуво, к тому-же приведена ссылка на вики, указывающая на g80 и переправленная с nv50 :\
> Это лишь ваши домыслы, именно NV50 оно и звалось изначально:
> http://nouveau.freedesktop.org/wiki/CodeNames#NV50
> https://bitbucket.org/thweber/linux_devkit8000/src/ae168d973...да, ссылки на вторичные источники вообще не показательны
от самой нвидии или на снимках ГПУ НЕ фигурирует это название, так что с выдумками это точно не ко мне
>> Это лишь ваши домыслы, именно NV50 оно и звалось изначально:
>> http://nouveau.freedesktop.org/wiki/CodeNames#NV50
>> https://bitbucket.org/thweber/linux_devkit8000/src/ae168d973...
> да, ссылки на вторичные источники вообще не показательныВ данном случае это первичные источники, а nvidia как раз вторичный, так как в разработке свободного драйвера Nouveau NV50 участия не принимает.
Желающим пощупать на livecd:
http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkima...
http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkima...Собрано на сегодняшнем сизифе с добавлением вот этого репозитория:
http://ftp.altlinux.org/pub/people/shrek/Xorg/У меня под этим самым e17 наблюдается некоторая регрессия с отрисовкой окон при их появлении (насколько понимаю, но могу ошибаться -- это когда окошко уже мапится): http://lists.altlinux.org/pipermail/devel/2013-February/1968...
> У меня под этим самым e17 наблюдается некоторая регрессия с отрисовкой оконЧестно говоря не понимаю при чем тут e17 и почему тесты месы надо начинать с какой-то хардкорной экзотики.
>> У меня под этим самым e17 наблюдается некоторая регрессия с отрисовкой окон
> Честно говоря не понимаю при чем тут e17Композитный менеджер.
> и почему тесты месы надо начинать с какой-то хардкорной экзотики.
Так заметил вскоре после service dm restart... ну и не вижу тут никакой особой экзотики.