После трёх месяцев разработки доступен (https://lists.freedesktop.org/archives/mesa-announce/2016-Ju...) релиз свободной реализации OpenGL API - Mesa 12.0 (http://mesa3d.org/), примечательный реализацией OpenGL 4.2 и 4.3 в драйверах RadeonSI, Nouveau (nvc0) и Intel (i965) для видеокарт AMD на основе архитектуры GCN (HD 7700-7900, HD 8000, Rx 240-290, Rx 300), NVIDIA на базе GPU Fermi, Kepler и Maxwell (GeForce 400/500/600/700) и GPU Intel Gen8+ (Broadwell). Кроме того, в драйверах RadeonSI и Nouveau (nvc0) обеспечена поддержка OpenGL ES 3.1. Первый выпуск ветки Mesa 12.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 12.0.1.
Кроме поддержки OpenGL 4.3 и OpenGL ES 3.1 в новом выпуске можно отметить следующие (http://cgit.freedesktop.org/mesa/mesa/log/) изменения (http://cgit.freedesktop.org/mesa/mesa/tree/docs/relnotes/11....):
- Включение в поставку драйвера для графического API Vulkan (https://www.opennet.ru/opennews/art.shtml?num=43887). Драйвер пока поддерживает только оборудование Intel, начиная с платформ Ivy Bridge;
- Поддержка предложенной компанией NVIDIA GLX-библиотеки GLVND (OpenGL Vendor-Neutral Driver), предлагающей новую инфраструктуру GLX- и OpenGL-драйверов. Библиотека GLVND (libglvnd) представляет собой программный диспетчер, осуществляющий перенаправление команд от 3D-приложения к той или иной реализации OpenGL, давая возможность сосуществовать драйверам Mesa и NVIDIA;
- В состав включён разработанный компанией Intel высокопроизводительный программный растеризатор SWR (http://openswr.org/), предоставляющий средства для программной отрисовки OpenGL силами центрального процессора, без привлечения GPU (может рассматриваться как программный GPU, который поддерживает OpenGL 3.3). По сравнению с ранее предлагаемым в Mesa однопоточным растеризатором llvmpipe при отрисовке сцен со сложной геометриейSWR обеспечивает существенный прирост производительности, например, при расчёте сцены из 2.9 млн треугольников SWR обгоняет llvmpipe по производительности в 29 раз, а на сцене из 106.2 млн треугольников - в 51 раз. Подобной производительности удалось добиться за счёт эффективного распараллеливания операций на многоядерных процессорах (операции отрисовки разбиваются на части для параллельной обработки вершин), применения JIT-компиляции шейдеров и задействования специализированных векторных наборов инструкций, таких как SSE (Streaming SIMD Extensions), AVX и AVX2 (Advanced Vector Extensions).- Для VDPAU, OMX и VAAPI включена поддержка DRI3;
- Для сборки Gallium-драйверов radeon (r300, r600 и radeonsi) теперь требуется ядро Linux 3.2+ и LLVM 3.6+;
- Поддержка новых расширений OpenGL, определённых в стандартах OpenGL 4.x:
- GL_ARB_ES3_1_compatibility в драйверах nvc0, radeonsi- GL_ARB_compute_shader в nvc0, radeonsi, softpipe
- GL_ARB_cull_distance в i965/gen6+, nv50, nvc0, llvmpipe, softpipe
- GL_ARB_framebuffer_no_attachments в nvc0, r600, radeonsi, softpipe
- GL_ARB_internalformat_query2 во всех драйверах
- GL_ARB_query_buffer_object в i965/hsw+
- GL_ARB_robust_buffer_access_behavior в i965, nvc0, radeonsi
- GL_ARB_shader_atomic_counters в radeonsi, softpipe
- GL_ARB_shader_atomic_counter_ops в nvc0, radeonsi, softpipe
- GL_ARB_shader_image_load_store в nvc0, radeonsi, softpipe
- GL_ARB_shader_image_size в nvc0, radeonsi, softpipe
- GL_ARB_shader_storage_buffer_objects в radeonsi, softpipe
- GL_ATI_fragment_shader во всех Gallium-драйверах
- GL_EXT_base_instance во всех драйверах с поддержкой GL_ARB_base_instance
- GL_EXT_clip_cull_distance во всех драйверах с поддержкой GL_ARB_cull_distance
- GL_KHR_robustness в i965
- GL_OES_copy_image в i965 (Baytrail и Gen8+)
- GL_OES_draw_buffers_indexed и GL_EXT_draw_buffers_indexed во всех драйверах с поддержкой GL_ARB_draw_buffers_blend
- GL_OES_gpu_shader5 и GL_EXT_gpu_shader5 во всех драйверах с поддержкой GL_ARB_gpu_shader5
- GL_OES_sample_shading в i965, nvc0, r600, radeonsi
- GL_OES_sample_variables в i965, nvc0, r600, radeonsi
- GL_OES_shader_image_atomic во всех драйверах с поддержкой GL_ARB_shader_image_load_store
- GL_OES_shader_io_blocks в i965, nvc0, radeonsi
- GL_OES_shader_multisample_interpolation в i965, nvc0, r600, radeonsi
- GL_OES_texture_border_clamp и GL_EXT_texture_border_clamp во всех драйверах с поддержкой GL_ARB_texture_border_clamp
- GL_OES_texture_buffer и GL_EXT_texture_buffer в i965, nvc0, radeonsi
- EGL_KHR_reusable_sync во всех драйверах
- GL_ARB_stencil_texture8 and GL_OES_stencil_texture8 в i965/gen8+
URL: https://lists.freedesktop.org/archives/mesa-announce/2016-Ju...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44757
Хороший релиз, ждем во всех дистрибутивах страны
Отлично! :-)
не смог распарсить кашу в первом абзаце
Поясните идиоту отличия OpenGL и Vulkan
OpenGL проверяет шейдеры на CPU и пропускает все валидации через софт
Vulkan использует прямой доступ с низким уровнем для вывода и прямого доступа к памяти.
не так. OpenGL компилит шейдеры на лету, Vulkan хранит в байт-коде. по идее, должно нехило подтянуть производительность и помочь тем, кто не осиливает glsl, например, разрабам Unreal Engine)) жаль только поддержу Vulkan они не торопятся для десктопов пилить.
Vulkan переводит в байтод, я в курсах через LLVM у них там свой нестабильный тулкит.
Vulkan ничего никуда не переводит. Это API. Байткод производят компиляторы шейдеров.
Не на лету. В нормальных движках (не Unreal Engine) шейдеры компилируются заранее. Но да, на это все равно уходит время. HLSL и SPIR-V в этом плане значительно лучше.
Vulkan более низкоуровневый и с ним удобнее использовать многопоточность.
Ну грубо говоря, OpenGL и тот же DirectX (до 12-ой версии) работали и с видеокартами, и с CPU. Притом, реализация такова, что этот самый CPU - "узкое горлышко". Vulkan и DirectX 12 имеют общее - они оба имеют в себе стандартизацию по использованию всех ядер CPU и более расширенное использование ресурсов современных видеокарт. Главное что вы заметите при переносе со старых до новых стандартов - куча объектов на экране будет прорисовываться быстрее за счёт увеличения числа Draw Call (являющееся тем самым "узким горлышком"). Это число увеличивается на порядки, и потому не должно лагать даже при очень масштабных сценах для рендера. Ну тут есть свои моменты, конечно же, включая сырость драйверов и стандартов, тем не менее подвижки позитивные и в скором времени ощутим реальную мощь. Ах да, игры на Vulkan API будет проще портировать на разные платформы, в отличие от DX12, жёстко привязанного к Windows 10 и XBox консоли.
Сначала секунда 3D-анимации стоила офигеть сколько денег. Потом появилась SGI, и 3D-анимация стала стоить дёшево. Домашние пользователи не могли приобрести 3D-ускоритель, но большие компании - смогли. Мы увидели Историю игрушек и Парк юрского периода.На компьютерах Iris могли быть установлены любые приложения - софт не зашивался. Поэтому был нужен API разработчика. Им стал IrisGL. Набор софта для Iris мог стоить больше, чем сам Iris.
Прошло время. В IrisGL появилось много Deprecated, но его было нельзя убрать: старые программы отвалятся. Потом у SGI появилось много конкурентов, в связи с чем она открыла IrisGL под названием OpenGL. Странный шаг борьбы с конкуренцией, на мой взгляд. В OpenGL была произведена чистка от Deprecated.
Прошло 15 лет. OpenGL стал использоваться для игр, а не только для фильмов. Из-за диверсии Microsoft, OpenGL пережил тяжелейший кризис.
Прошло 10 лет. На Mac OS X и Linux пришла Valve. OpenGL стал остро востребован! Выяснилось, что за 25 лет накопилось много Deprecated. Однако перезапуск API не происходил потому, что в кино OpenGL был и так отшлифован до идеального состояния, а для игр он был не нужен. Как только он стал нужен для игр, появился Vulkan. В Vulkan была произведена чистка от Deprecated.
> В Vulkan была произведена чистка от Deprecated.Это не чистка opengl, вообще практически с нуля все сделано. (не считая mantle).
нет поддержки Fermi, пошли они в #### со своим вулканом, точка.
К слову, для поддержки OpenGL 4.3 в radeonsi еще нужен LLVM-3.9, который будет выпущен только в августе (ну или llvm из svn). Иначе полноценно поддерживается только OpenGL 4.1 (не хватает поддержки compute шейдеров и еще пары связанные расширений).
Традиционная ложка дегтя. Потом как допилят OGL целиком, ждать на LLVM-3.10/4 угу.
Можно не ждать, просто скачать, собрать и использовать. На то как бы и опенсорс...
Судя по https://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt в следующем релизе будет полная поддержка всех версий спецификации OpenGL. начнется полировка кода и реализация Vulkan, так что можно сказать - догнали и теперь разработка будет идти в ногу с закрытыми драйверами.
Останется догнать по скорости. :-)
хаки неприемлемы
а кто-то предлагал?
а по-другому никак
Ничего, для нормальной работы с нормальной скоростью всегда остаётся Nvidia.
Расскажи нам про нормальную скорость с nouveau. Это сайт OPENнет, не забывай, блобы и их любители тут мало кого интересуют.
> Ничего, для нормальной работы с нормальной скоростью всегда остаётся Nvidia.На самом деле это отчасти заслуга самих hardware-вендоров (nvidia и amd), т. к. это они постоянно прогибаются и встраивают хаки в проприетарные дрова вместо того, чтобы перевести стрелки и натравить геймеров на криворуких игроделов. :( Ссылка в тему:
http://www.dsogaming.com/news/ex-nvidia-driver-developer-on-.../Ну а разработчики открытых дров гарантированно не будут встраивать хаки и подменять шейдеры для отдельных игорь.
Ну, как бы бизнес всё решает. Как ты заставишь каких-то левых разработчиков исправить свой движок? В лучшем случае бывает договор между разработчиками игры и вендорами, тогда ты видишь что-то типа "The way it's meant to be played" в заставке. А если никакого договора нет, то можешь разве что в твиттере написать, что они облажались. Но это тоже плохо для бизнеса.Вендорам проще и дешевле самим сделать хак.
На самом деле во многих играх, выпущенных под линукс, фиксят баги, выявленные при использовании открытых дров. Потому что:
- разработчики открытых дров говорят, что это баг в игре, и не собираются с этим ничего делать, после чего юзера достают разработчиков в багзиллах или на форумах steam/gog, и т. д.;
- порты обычно делаются сторонними не очень крупными компаниями. И некоторые из них (Feral Ineractive) даже начали официально поддерживать открытый драйвер radeonsi в своих новых портах. Более того, они даже сами тестируют (!) свои порты на нем.Так что в принципе перевод стрелок на игроделов в какой-то степени работает, но требует времени. Nvidia с AMD сложно идти по этому пути при релизе очередной AAA-игры, когда нужно оперативно что-то делать, иначе на всех сайтах будут писать, что вот у другого вендора с производительностью все хорошо.
Ну так об этом я и говорил, либо вендор по-быстрому что-то фиксит, либо получает маркетинговые проблемы.А то, что feral начинает что-то там фиксить - это хорошо, но они тоже мало что могут сделать.
Расскажи, с чем именно у тебя "по-другому никак"?
> Судя по https://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt в следующем релизе
> будет полная поддержка всех версий спецификации OpenGL. начнется полировка кода и
> реализация Vulkan, так что можно сказать - догнали и теперь разработка
> будет идти в ногу с закрытыми драйверами.будет прикольно если они таки решат запилить вулкан на фермях ;)
Твоя ферми уже по производительности на затычку только тянет. Иди уже устройся на работу и обновись хоть на амд, хоть на новую нвидию.
Осталось подтянуть производительность нуво, а то оно так и работает на минимальных частотах без реклокинга.
Да щас Нвидия спеки, драва откроет и всё будет
Да скорее дрова AMD начнут собираться без бубна на последних ядрах.
Они уже в ядре, с добрым утром!
> Они уже в ядре, с добрым утром!Ох, прошу прощения, забыл указать, что речь об AMDGPU-Pro и старом проприетарном драйвере. К сожалению, с открытым драйвером на R9 380 только OpenGL 3.3, так что пришлось ставить AMDGPU-Pro для поддержки OpenGL 4.5. Что характерно, все deb-пакеты установились, кроме модуля ядра, который не смог собраться через dkms из-за несовместимости с ядром Linux 4.6. С ядром 4.4 собрался, но давал лишь чёрный экран. Тем не менее, на Linux 4.5 OpenGL 4.5 заработал и со встроенным модулем amdgpu, а вместе с ним заработал в wine "Wolfenstein: The New Order". Так что, в принципе, невелика потеря.
> Они уже в ядре, с добрым утром!Ох, прошу прощения, забыл указать, что речь об AMDGPU-Pro и старом проприетарном драйвере. К сожалению, с открытым драйвером на R9 380 только OpenGL 3.3, так что пришлось ставить AMDGPU-Pro для поддержки OpenGL 4.5. Что характерно, все deb-пакеты установились, кроме пакета с модулем ядра (amdgpu-pro-dkms), который не смог собраться через из-за несовместимости с ядром Linux 4.6. С ядром 4.4 собрался, но давал лишь чёрный экран. Тем не менее, на Linux 4.6 OpenGL 4.5 заработал и со встроенным модулем amdgpu, а вместе с ним заработал в wine "Wolfenstein: The New Order". Так что, в принципе, невелика потеря.
> Да скорее дрова AMD начнут собираться без бубна на последних ядрах.до-до, святое затронули: саму зеленую «зависть»? как же фанатику не написать про АМД, чтобы утолить горечь сожаления о попранном кумире?
В зеркало посмотри. Дрова AMD в ядре, а ты почему-то желчью брызжешь во все стороны... Почему? Ответь себе сам.
>Да скорее дрова AMD начнут собираться без бубна на последних ядрах.они уже никогда не начнут собираться. Теперь и проприетарный и свободный драйвер использует один и тот же модуль ядра radeon. Являющийся частью ядра.
> они уже никогда не начнут собираться.Точнее, собираются сразу вместе с ядром.
И не radeon, a amdgpu.
> Да щас Нвидия спеки, драва откроет и всё будетдержи карман шире.
держи карман пистолетом
> Осталось подтянуть производительность нуво, а то оно так и работает на минимальных
> частотах без реклокинга.вот если бы это пофиксили я бы уже их драйвер юзал вместо блоба
А чего себя так мучить? Юзай карты с нормальными открытыми дровами.
>В состав включён разработанный компанией Intel высокопроизводительный программный растеризатор SWR, предоставляющий средства для программной отрисовки OpenGL силами центрального процессораЗачем?
Кто знает, как этим пользоваться?
> Зачем?Надо.
> Кто знает, как этим пользоваться?
Я знаю.
>> Зачем?
> Надо.Только затем, что графика у интела слабенькая. Вот и приходится как-то выкручиваться за счет CPU.
На машинах без видеокарт для рендеринга чего-то несложного; для VM.
я сегодня обновился, в т.ч. и меса обновилась - стим запускаться перестал. Пошаманил немного - слетели настройки стима. Не обратил внимания, запустил доту, поиграл как обычно. А вот сейчас на фоне этой новости посмотрел, а там у меня и запуск через optirun слетел. Играл на интеловской видюхе и, блин, разницы не заметил.
рач? Тоже самое ибо
Он, родимый.
Чёрт, как-то двусмысленно получилось...
> я сегодня обновился, в т.ч. и меса обновилась - стим запускаться перестал.
> Пошаманил немного - слетели настройки стима. Не обратил внимания, запустил доту,
> поиграл как обычно. А вот сейчас на фоне этой новости посмотрел,
> а там у меня и запуск через optirun слетел. Играл на
> интеловской видюхе и, блин, разницы не заметил.а что конкретно слетело? libglvnd который они нвшный туда притащили? вообще печально, что они его притащили из бинарного блоба в месу ;)...значит будет тоже самое при попытках юзать старый стим и новую месу как и при попытках заюзать новый блоб + стим и поиграться в доту2. у меня в этом случае только нативный openGL в линухе пахал, но через стим, нет.
Да не, libglvnd уже давно установлен и проблем никаких не было.
У меня просто совпало обновление системы с обновлением самого стима. Там пришлось удалять некоторые стимовские либы, чтобы с новыми системными всё заработало (типа libc).
Кажется, это скорее проблема дистра, чем mesa
i915 опять в пролёте :(
Ну кое-что и для него есть:
https://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/...
https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/drive...
Есть смысл устанавливать для ATI RS600M?
Изменения есть, но в основном это заглушки + несколько багфиксов.
https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/drive...
> Есть смысл устанавливать для ATI RS600M?Проще его выкинуть, чем поддерживать