Опубликован (https://lists.freedesktop.org/archives/mesa-dev/2019-March/2...) релиз свободной реализации API OpenGL и Vulkan - Mesa 19.0.0 (http://mesa3d.org/). Первый выпуск ветки Mesa 19.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 19.0.1. В Mesa 19.0 предоставляется (https://mesamatrix.net/) полная поддержка OpenGL 4.5 для драйверов i965, radeonsi и nvc0, поддержка Vulkan 1.1 для карт Intel и AMD, а также частичная поддержка стандарта OpenGL 4.6 (https://www.opennet.dev/opennews/art.shtml?num=46952).
Наиболее заметные (https://cgit.freedesktop.org/mesa/mesa/log) изменения (http://cgit.freedesktop.org/mesa/mesa/tree/docs/relnotes/19....):
- Объявлена устаревшей сборочная система на основе autotools. По умолчанию для сборки теперь применяется Meson (https://www.opennet.dev/opennews/art.shtml?num=50288). Для продолжения сборки с autotools при запуске autogen.sh следует указать опцию "--enable-autotools". В следующем выпуске 19.1 планируется полностью удалить поддержку autotools;- В драйвер ANV (Vulkan-драйвер для GPU Intel) добавлено (https://cgit.freedesktop.org/mesa/mesa/commit/?id=ac0f8a6ea0...) расширение Vulkan Transform Feedback (https://www.khronos.org/registry/vulkan/specs/1.1-extensions...), которое предоставляет техническую возможность для проектов DXVK (https://www.opennet.dev/opennews/art.shtml?num=47943) и VKD3D (https://www.opennet.dev/opennews/art.shtml?num=48648) (реализации Direct3D 11 и 12 поверх API Vulkan) использовать Direct3D Stream Output, отвечающий за отображение многих поверхностей в играх. Ранее данное расширение было реализовано только в драйвере RADV;
- В драйвер ANV добавлены расширения VK_EXT_scalar_block_layout, VK_EXT_pci_bus_info, VK_ANDROID_external_memory_android_hardware_buffer, VK_KHR_depth_stencil_resolve, VK_KHR_draw_indirect_count и VK_EXT_conditional_rendering;
- В драйвер RADV (Vulkan-драйвер для карт AMD) добавлены расширения VK_EXT_memory_budget, VK_EXT_scalar_block_layout и VK_EXT_pci_bus_info;- В RadeonSI (OpenGL-драйвер для карт AMD) включена (https://cgit.freedesktop.org/mesa/mesa/commit/?id=e260493f2a...) поддержка
технологии VESA Adaptive-Sync (FreeSync), позволяющей адаптивно менять частоту обновления монитора для обеспечения плавного вывода и отсутствия разрывов;
- Добавлены новые расширения OpenGL:
- GL_AMD_texture_texture4 (https://www.khronos.org/registry/OpenGL/extensions/AMD/AMD_t...) ля всех драйверов с поддержкой GL 4.0;
- GL_EXT_shader_implicit_conversions (https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_s...) для всех драйверов
- GL_EXT_texture_compression_bptc (https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_t...) для всех драйверов с поддержкой GL 4.0;
- GL_EXT_texture_compression_rgtc (https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_t...) для всех драйверов с поддержкой GL 3.0;
- GL_EXT_render_snorm (https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_r...) для всех драйверов на базе gallium;
- GL_EXT_texture_view (https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_t...) для драйверов с поддержкой Texture Views;
- GL_OES_texture_view (https://www.khronos.org/registry/OpenGL/extensions/OES/OES_t...) для драйверов с поддержкой Texture Views;
- GL_NV_shader_atomic_float (https://www.khronos.org/registry/OpenGL/extensions/NV/NV_sha...) для nvc0 (Fermi/Kepler).- В драйвере Freedreno улучшена поддержка GPU Qualcomm Adreno A2xx;
- Для GLSL реализованы (https://cgit.freedesktop.org/mesa/mesa/commit/?id=b63a1f8e40...) функции для поддержки 64-разрядных типов FP64 и INT64;
- В драйвер i965 добавлена (https://cgit.freedesktop.org/mesa/mesa/commit/?id=406f603b34...) программная реализация (на основе шейдеров) 64-разрядных расширений GLSL GL_ARB_gpu_shader_fp64, GL_ARB_gpu_shader_int64 и GL_ARB_vertex_attrib_64bit, а также расширения GL_ARB_shader_ballot;
- Добавлено расширение EGL_MESA_query_driver (https://cgit.freedesktop.org/mesa/mesa/commit/?id=381d0e753a...), упрощающее получение параметров драйверов в Wayland.URL: https://lists.freedesktop.org/archives/mesa-dev/2019-March/2...
Новость: https://www.opennet.dev/opennews/art.shtml?num=50316
Уже который раз добавляют FreeSync? Я сбился со щёта.
А по настоящему заработает то когда, например в KDE?
Не который раз, а куда. Его отдельно надо добавлять в ядро, отдельно для разных видеокарт, отдельно в месу.
Зачем тебе freesync в DE?
1) повысить отклик на действия
2) использовать 75 ФПС.
Когда пропишешь в конфиг иксов, тогда и заработает. кэп.
Ставить надо?
Минусы ). Это вопрос был, продвинутые умственно :) Начитаются источников и давай митинговать )
Если это был вопрос, то ответ и впрямь отрицательный.PS: не минусовал. :)
Хм уже использую на radeon RX-570 8G c kernel 5.0.0.Игра stalker-нс2016
на wine-4.1.При работе с Gallium-Nine (dx9) ощутимо быстрее чем Opengl.
Выражается в инпутлаге (задержка ввода тактильно очень заметна) при работе с мышкой в Opengl.Переключаю wine на Gallium-Nine и "ватность"
мышки пропадает.На жк мониторах может и не заметно но на плазме в игровом режиме даже очень ощутимо.Ну и по тестам переключая wine туда сюда выяснилось что Nine все же не очень стабильно чем Opengl. Да fps почти одинковый.
P.S
OpenGL или софтверный рендеринг работает. ... Кто не знает gallium-nine - это реализация D3D9 в mesa, используя его можно избежать трасляции d3d>opengl>tgsi>видеокарта а просто выполнять d3d>tgsi>видеокарта
>Переключаю wine на Gallium-Nine и "ватность"мышки пропадает.
Хорошо освидомил.
Году в 2008, когда я запускал Сталкер 1.5 в Wine 1.1.16, тоже была "ватность" мышки. Ничё не меняется )
ну так никто в игре мышку от директхаков не отвязывал, вот оно и лагает при трансляции..
Кстати скоро обещают трансляцию wine d3d9 в Vulkan в Mesa посмотрим чем будет лучше Nine.Да и как я понял при работе Nine Mesa не кэширует откомпилированные шейдеры как например в OpenGl.При прохождении в игре повторно одних и тех же мест OpenGl плавнее вроде как.Не уверен.
> скоро обещают трансляцию wine d3d9 в Vulkan в Mesaкто обещает? прямо щас вроде все эти проекты d3d9 в Vulkan подзаглохли, но есть варианты d3d9 в d3d12 и d3d12 в Vulkan, которые вроде как пока не супер в первой части цепочки
Новые ачивки подъехали
Nouveau, походу, всё. Очень печально, с ноутбуками на Optimus неудобно использовать проприетарный драйвер, а bumblebee больше не развивается. И ладно бы завести последний костылями, так ведь vulkan'а не будет.
По-идее, Optimus должен работать на 100%. Но что-то не слышно историй успехаДавай краткий пересказ событий. Сначала был Bumblebee. Позволяет одновременно пользоваться и Intel GPU, и NVIDIA GPU, и ещё обесточивать NVIDIA во время неиспользования при помощи bbswitch. Есть NVIDIA PRIME, появился в драйвере 319.xx и требует для своей работы Linux 3.9 (в драйвере 364.xx подняли до 3.13), X-Server 1.13 и Xrandr 1.4 (или новее). Настраивается при помощи создания специального xorg.conf и изменения конфига LightDM (или другого DM, если вы его используете). Подробнее в Arch Wiki и Gentoo Wiki, а в Ubuntu сделали "из коробки".
Решение от NVIDIA не подразумевает использование Intel GPU, а следовательно всегда недолгое время работы от батареи. Также всегда тиринг. Но в X-Server 1.19 тиринг исправили. Только нужно вручную приписывать параметры, чтобы тиринга больше не было (PRIME Syncronization). Причём даже не надо включать композитный менеджер - тиринга всё равно не будет.
А в X-Server 1.20 должна была заработать переключаемая графика. Системная библиотека libGL заменялась на диспетчер, перенаправляющий вызовы либо в релазизацию OpenGL от Mesa, либо в NVIDIA. То есть, настоящий Optimus, без обходных путей. Интересно, можно ли обесточить NVIDIA? Но я не слышал, чтобы хоть кто-нибудь это использовал
На ноуте с i5 и Nvidia MX150 у меня отлично работал optirun. Вся система загружается и работает через Intel GPU, но конкретное приложение можно запустить через optirun. Можно и Иксы по идее через оптиран пускать.
> А в X-Server 1.20 должна была заработать переключаемая графика. Системная библиотека libGL заменялась на диспетчер, перенаправляющий вызовы либо в релазизацию OpenGL от Mesa, либо в NVIDIA. То есть, настоящий Optimus, без обходных путей.Есть Xorg 1.20.4 и переключаемая графика (glvnd). И как добиться переключения? Ноут с Intel UHD 630 + Geforce 1050 Ti, при использовании проприетарного драйвера все время активна только нвидия (хотя встроенный экран ноута подключен к интелу). Никакого bumblebee, современный PRIME. Решения из Arch Wiki (https://wiki.archlinux.org/index.php/PRIME) не работают - DRI_PRIME ничего не меняет, попытка сделать интел основной картой через xrandr --setprovideroffloadsink выдает ошибку - т.е. оба провайдера там видны, но порядок допустим только "нвидия, потом интел", и не поменять ни порядок, ни активировать интел форсированно для приложения.
А nouveau на этом конфиге работает настолько отвратительно, что даже описывать не хочется.
Ноут с точно такой же конфигурацией. Просто поставил проприентарный драйвер и bumblebee, даже ничего не настраивал, и все работает. Иксы крутятся на интеловской карте, через optirun пускается то, чему надо производительность повыше. Gentoo, если что.
> Ноут с точно такой же конфигурацией. Просто поставил проприентарный драйвер и bumblebee,
> даже ничего не настраивал, и все работает. Иксы крутятся на интеловской
> карте, через optirun пускается то, чему надо производительность повыше. Gentoo, если
> что.Я не ставил bumblebee т.к. на каждом углу пишут, что это прошлый век, с ним не работает vulkan, он тормоз (https://github.com/Witko/nvidia-xrun/issues/4#issuecomment-1...) и тд и тп и в 2019 году давно надо использовать PRIME вместо него... Оно заработало из коробки. Но переключение на Intel назад - не выходит (
В Ubuntu можно, но только с перезапуском "иксов". https://i.stack.imgur.com/NixuN.png В остальных дистрах можно удалить или переименовать xorg.conf, тогда X-Server запустится на Intel GPU. Не знаю, сделает ли это работу от батареи дольше
>Никакого bumblebee, современный PRIMEPRIME угешнее шмелятины, такие дела.
чем же им autotools не угодили? они же заводятся на любом калькуляторе и работают на всех системах
Вы их точно не только запускали (кстати, неспешное дело) но и писать правила пытались?
https://media.ccc.de/v/44-making_your_gnome_app_compile_24x_...
Воу. Там где-то на 1:10 схема работы autotools. Эта схема -- неоценимая штука. Может быть если бы она у меня была бы десять лет назад, то я бы знал сейчас, как заточить свой проект под autotools. Я тогда пытался разобраться, читая мануал к autotools, но так и не понял. Схема проясняет, почему я не понял.
Ты пробовал заводить autotools на калькуляторе? Я пробовал использовать их на малинке, я собирал базовую систему gentoo и наблюдал. У меня сложилось впечатление, что больше половины времени сборки отожрали autotools. Интересно было бы замерять.
Есть основания полагать что с meson'ом будет ещё веселее. Как минимум --- изрядно потопчемся по новым граблям, пока их не распознаем.
> Есть основания полагать что с meson'ом будет ещё веселее. Как минимум ---
> изрядно потопчемся по новым граблям, пока их не распознаем.Возможно. Но раз за разом наступать на старые грабли из-за страха наступить на новые -- это не вариант нисколько.
Старые грабли уже все (кому это было интересно) знают, как обходить. А на новых ещё подорваться придётся. А поскольку там питон, а питон местами полный абзац врубает, то я от meson'а ничего хорошего не жду.
> Старые грабли уже все (кому это было интересно) знают, как обходить. А
> на новых ещё подорваться придётся.Во, отличный пример олдфажеского подхода: я научился обходить старые грабли, а дальше хоть трава не расти, я не позволю вам убирать эти грабли и привносить новые, потому что старую собаку новым трюкам научить невозможно. И именно поэтому, созданием новых граблей приходится заниматься зелёным юнцам: у юнцов ещё молоко на губах не обсохло, но олдфаги уже ни на что не способны, кроме как кряхтеть о том, что тот кто не может обойти грабли, известные только этим олдфагом, должен свалить из профессии вон.
Мне старые грабли autotools были интересны, но недостаточно, чтобы понять как этим пользоваться. Я перечитал мануалы несколько раз, посмотрел на GNU Hello World, плюнул и сделал всё вручную. И я не знаю, как обойти старую граблю autotools иначе, кроме как не использовать их. И я очень рад тому, что сегодня есть cmake, meson, и прочие, которые позволяют новым поколениям разработчиков не тратить своё время на изучение граблей autotools: они реально не стоят того.
И да, я не собираюсь сваливать вон из профессии, я лучше подожду, когда свалят олдфаги. А они свалят, таблетку бессмертия пока ещё не придумали.
> А поскольку там питон, а питон
> местами полный абзац врубает, то я от meson'а ничего хорошего не
> жду.Ок.
Кто-то может четко объяснить, зачем нужна прослойка в виде mesa, когда драйвера и так opengl предоставляют
Проприетарные тащат свои "libgl.so". А это "libgl.so" для швaбодных драйверов.
Как тут еще на пальцах и для самых маленьких получше объяснить..
Швaбодный libgl.so который дергaет проприетарные драйвера
> Швaбодный libgl.so который дергaет проприетарные драйверавы заблуждаетесь, меса работает с открытыми дровами (но вообще сейчас есть возможность перенаправлять запрос в любой libgl.so по выбору)
Ты про драйвера в ядре? Но как ты будешь дёргать эти драйвера? Я чесслово не знаю как это делается, через ioctl'ы? Может ли быть у разных драйверов разный ABI?mesa же предоставляет тебе няшный C'шный ABI.
opengl стандартизирован (вот это поворот)
> opengl стандартизирован (вот это поворот)Да неужели? ABI там тоже стандартизован? Как ядерный драйвер сможет обеспечить тебе C'шный ABI?
https://blogs.igalia.com/itoral/2014/08/08/diving-into-mesa/
> релиз свободной реализации API OpenGL и Vulkan
> ANV (Vulkan-драйвер для GPU Intel)
> RadeonSI (OpenGL-драйвер для карт AMD)
> драйвер RADV (Vulkan-драйвер для карт AMD)Еще раз:
> свободной реализации API OpenGL и VulkanВ каком месте непонятно?