Сформирован (https://github.com/doitsujin/dxvk/releases/tag/v1.3) выпуск прослойки DXVK 1.3 (https://github.com/doitsujin/dxvk/), предоставляющей реализацию DXGI (DirectX Graphics Infrastructure), Direct3D 10 и Direct3D 11, работающую через трансляцию вызовов в API Vulkan. Для использования DXVK требуется (https://github.com/doitsujin/dxvk/wiki/Driver-support) наличие драйверов с поддержкой API Vulkan (https://www.opennet.me/opennews/art.shtml?num=48227), таких как
AMD RADV 18.3, NVIDIA 415.22, Intel ANV 19.0 и AMDVLK (https://www.opennet.me/opennews/art.shtml?num=47816).
DXVK может применяться для запуска 3D-приложений и игр в Linux при помощи Wine, выступая в качестве более высокопроизводительной альтернативы встроенной в Wine реализации Direct3D 11, работающей поверх OpenGL. В некоторых играх (https://www.reddit.com/r/wine_gaming/comments/9cvfux/benchma.../) производительность связки Wine+DXVK отличается (https://github.com/doitsujin/dxvk/issues/67) от запуска в Windows всего на 10-20%, в то время как при использовании реализации Direct3D 11 на базе OpenGL производительность снижается более существенно.Добавленные улучшения:
- Реализована оптимизация с использованием инструкции "discard" в шейдерах, основанная на Vulkan-расширении VK_EXT_shader_demote_to_helper_invocation и способная повысить производительность в некоторых играх. Для использования оптимизации требуется обновить компонент winevulkan и драйверы (Intel до Mesa 19.2-git и NVIDIA до проприетарного драйвера 418.52.14-beta, драйверы AMD пока не поддерживают расширение VK_EXT_shader_demote_to_helper_invocation);- Обеспечена асинхронная обработка вывода результата рендеринга на экран (стадия presentation (https://vulkan-tutorial.com/Drawing_a_triangle/Drawing/Rende...)). Для уменьшения задержек в основном потоке рендеринга, обработка вывода теперь выполняется в потоке передачи команд (command submission thread). Выигрыш в производительности от асинхронной обработки особенно заметен при выводе с высокой частотой кадров и при ресурсоёмкой передаче команд. Из игр в которых наблюдается прирост производительности отмечается Quake Champions при запуске на системах с GPU AMD;
- Появилась возможность начальной загрузки ресурсов с использованием движков копирования (copy engine), предоставляемых устройством с поддержкой Vulkan (пока поддерживается только драйверами AMDVLK и NVIDIA). Новая возможность позволяет немного улучшить согласованность времени кадра в играх, загружающих большое число текстур во время игры;
- Улучшено ведение лога ошибок, возникающих в условиях нехватки памяти;
- Улучшена совместимость с MSVC (Microsoft Visual C++);
- Убраны повторяющиеся цикличные проверки во время вывода, что может значительно снизить нагрузку на CPU в сценариях с ограниченными GPU;- Устранена проблема с двойным маппингом субресурсов изображений, проявлявшаяся в игре Final Fantasy XIV;
- Устранён крах из-за некорректного поведения метода RSGetViewport, проявлявшийся в игре Scrap Mechanic.URL: https://vk.com/multi_linux_community?w=wall-114916478_356323
Новость: https://www.opennet.me/opennews/art.shtml?num=51084
Почему-то я вижу сообщение об ошибке, когда пытаюсь прислать Вам ссылку на вот эту новость: https://vk.com/multi_linux_community?w=wall-114916478_356164Проект "GNOME" отреагировал на новость о начале разработки с нуля "Ubuntu Snap Store" для замены им текущего в Ubuntu магазина приложений "GNOME Software" отключением в будущих выпусках "GNOME Software" дополнения, обеспечивающего в нём поддержку Snap-пакетов.
Хотя в настоящее время Ubuntu использует "GNOME Software" в качестве своего "центра программного обеспечения" (или "магазина приложений") с интеграцией Snap, как я писал недавно (https://vk.com/multi_linux_community?w=wall-114916478_356159), Canonical начали писать собственный Snap Store. Учитывая это и то, что они не планируют использовать "GNOME Software" в Ubuntu 20.04 LTS и, разработчики GNOME планируют отключить подключаемый модуль Snap для "GNOME Software".
Разрабатываемый Canonical Snap Store, очевидно, будет сосредоточен только на Snap и не будет поддерживать Flatpak. Из-за вероятности того, что плагин GNOME Software Snap быстро пострадает от "гниения" и создаст бремя обслуживания для разработчиков GNOME практически без получения какой-либо выгоды взамен после удаления GNOME Software из Ubuntu, и так как Snap в основном, чаще всего, используется только в Ubuntu, то вполне разумно, что разработчики GNOME по крайней мере отключат этот плагин, обеспечивающий работу Snap.
Ричард Хьюз (Richard Hughes) из Red Hat сказал:
"Существующий плагин Snap не очень хорошо протестирован, и я не хочу нести ответственность за его поломки. В настоящий момент включение плагина поддержки Snap приводит к ухудшению общего впечатления пользователей "GNOME Software", поскольку все поисковые запросы также маршрутизируются через snapd вместо того, чтобы обрабатываться в одном и том же процессе. Конструкция snapd также означает, что пакеты просто обновляются "за спиной" "GNOME Software", и поэтому очень сложно сделать что-либо полезное в пользовательском интерфейсе или заставить работать такие вещи, как измерение данных, корректно. И, кроме того, даже после уже нескольких лет после обещаний, всё ещё нет поддержки песочницы, а это означает, что в Fedora запуск Snap-пакетов не более безопасен, чем "wget -O - URL | bash", что опять же сильно отличается от Flatpak."Более подробная информация в этом списке почтовой рассылки Ричарда Хьюза из Red Hat: https://lists.fedoraproject.org/archives/list/devel@lis.../
Какой текст ошибки был выведен? Ошибка в форме добавления новостей может быть показана в трёх случаях: когда не заполнен заголовок, когда прошло больше 3 часов с момента показа капчи и когда страница пришла без Referer (т.е. например, сохранена локально или на другом сайте, после чего заполнена и отправлена).
По поводу новости, я пока наблюдаю за ситуацией. То сообщение от Richard Hughes уже устарело и всё изменилось - https://gitlab.gnome.org/GNOME/gnome-software/merge_requests...
Кроме удаления из Fedora также был предложен коммит для полного выпиливания кода поддержки snap из GNOME Software, под предлогом того, что Ubuntu планирует прекратить использование gnome-software в пользу разрабатываемого нового интерфейса.Затем пришёл разработчик из Canonical и сильно удивился. Оказалось, что в Canоnical никаких решений относительно разрабатываемого нового интерфейса к snapd (https://github.com/ubuntu/snap-store ) ещё не принято и проект находится на очень раннем этапе развития, пока это лишь эксперимент. В текущем виде продолжают использоваться и будут поставляться как раньше два продукта: родной gnome-software под именем "Ubuntu Software" и
snap-store (https://snapcraft.io/snap-store название с новым проектом совпадает, позможно поэтому и путаница) - вариант GNOME Software, работающий только с плагином snap. Компания Canonical заинтересована в поддержке snap в GNOME Software для различных дистрибутивов, не ограничиваясь Ubuntu.
Упоминаемая разработчиками GNOME статья в Phoronix, на основе информации из которой они посчитали, что Ubuntu для snap переходит на новый интерфейс, отмечена как не являющаяся официальным заявлением планов Canonical и не содержащая никакой информации от Canonical/Ubuntu.Сейчас разработчики всё обсудили и Richard Hughes пересмотрел своё решение:
"Okay, closing this MR for my own sanity, I hope that's okay with everyone. We can revisit the plugin removal in a few months if required."
В Canonical вообще странные вещи с Gnome делают. Взяли и вхреначили неудаляемый без целого метапакета Ubuntu Dock, хотя это просто преднастроенное гноморасширение Dash to Dock, которое любой нуб может с полпинка завести, потом с какого-то дуба запихали в дефолт гномокалькулятор, долбаный калькулятор, Карл - в snap'е!
> неудаляемый без целого метапакетаКажется, ты недопонял концепцию метапакетов.
Да концепцию я допонял, понятно, что оно не убьет полсистемы на самом деле при удалении, но при обновлении проблемы же могут вылезти, не? Наркомания какая-то.
> при обновлении проблемы же могут вылезти, не?Не могут. Обновляются пакеты, которые есть в системе + новые зависимости, если такие возникают. Метапакеты существуют лишь для удобства установки.
> Почему-то я вижу сообщение об ошибке, когда пытаюсь прислать Вам ссылку на вот эту новостьПотому, что нечего пихать сюда ссылки на ФСБ-шные помойки.
Когда можно будет автогад через DXVK запустить?
А разве сейчас нельзя? Пишите все Ваши пожелания и проблемы, связанные с DXVK, сюда: https://github.com/doitsujin/dxvk/issues
Автокад уже давно скатился. Рекомендую перейти на другие КАДы, например BricsCAD, CADWorx или Siemens NX
А для Direct3D 12 такое будут делать? Там, по идее, даже проще должно быть...
vkd3d
> А для Direct3D 12 такое будут делать? Там, по идее, даже проще
> должно быть...Direct3D 12 уже давно реализован в Wine, но для работы обязательно требует поддержку Vulkan, установленные Vulkan-драйверы, установленный пакет vkd3d и переключенный в режим Windows 10 префикс Wine.
> асинхронная обработка вывода результата рендеринга на экранНикогда это не любил. Да, когда асинхронно, то не проседает FPS. Но когда играешь в Серьёзного Сэма 3, и включается кат-сцена, где огромный мутант весь такой злой и угрожающий... дорисосывается в процессе, то становитсяне страшно, а смешно. Ещё и тени в первые пол-секунды рваные, а потом чёткие
Мне кажется асинхронный рендеринг и асинхронная загрузка текстур - это разные вещи
Да суть одна и та же. Когда не было асинхронного рендеринга, движки приходилось писать хорошо. А теперь можно расслабиться: пусть на экран будет выводиться не до конца готовая картинка (особенно на старом "железе"), зато не лагает, дааа
Ну так отключай фичу и играй с лагами.
Поздно - разработчики движков уже расслабились, и махнули рукой на оптимизацию
> Да суть одна и та же.Это не вы случаем разработчик электрона?
> Wine+DXVK отличается от запуска в Windows всего на 10-20%где по ссылке разница в 10% по сравнению с виндой?
>где по ссылке разница в 10% по сравнению с виндой?Куда интереснее, как эту разницу замеряли. Файловая система, de/wm, включён или отключён композит и многое другое. Тут в линуксе-то разница в 20 — 25% fps будет ни о чём, а уж в сравнении с другой системой так и тем более.
Да там данные эпично устарели.
Теперь же уже быстрее винды, правда?
Смотря в чём. В старых opengl играх вино было быстрее ещё 10 лет назад.
Герои 3 снова запускаются? А что с трассировкой лучей в "новой" Кваке?
Через HoMM3 HD+ всегда запускались.
> Теперь же уже быстрее винды, правда?Где-то быстрее, где-то медленнее. В GuildWars2 гораздо быстрее, но там d9vk используется, в Ведьмаке процентов на 15 медленнее. В SuperPosition быстрее чем OGL версия, но медленнее чем DX. Самое главное чтобы кеш на SSD был, а не жестком.
>> NVIDIA до проприетарного драйвера 418.52.14-betaтак вроде стабильный драйвер сейчас 430.26
> так вроде стабильный драйвер сейчас 430.26Нет, 430.34.
У меня 430.26 в Арче стоит.
> У меня 430.26 в Арче стоит.Ну так это к вам и арчу вопросы, а не ко мне... Текущий стабильный драйвер это .34, зайдите на сайт нвидии и убедитесь.
>>> NVIDIA до проприетарного драйвера 418.52.14-beta
> так вроде стабильный драйвер сейчас 430.26Nvidia Vulkan Beta драйверы нумеруются иначе, без оглядки на нумерацию стабильных выпусков.
>Из игр в которых наблюдается прирост производительности отмечается Quake Champions при запуске на системах с GPU AMD;Странно, у меня наоборот, наблюдается снижение производительности. Если откатиться до 1.2, то все ОК.
>>Из игр в которых наблюдается прирост производительности отмечается Quake Champions при запуске на системах с GPU AMD;
> Странно, у меня наоборот, наблюдается снижение производительности. Если откатиться до
> 1.2, то все ОК.Необходимо соблюдать заявленные требования к видеодрайверам. А если они соблюдены, но FPS всё равно ниже нормы, то тогда пишите баг репорт сюда: https://github.com/doitsujin/dxvk/issues
>отличается от запуска в Windows всего на 10-20%Здесь слово "всего" меня всегда умиляет. А если речь идёт о том, есть ли заветные 30 фпс или их нет? Тогда эти 10% решают вопрос, можно ли в это играть из под Линукс или нет. Не говоря уже о 20% ;)
Это всё пустое, уже год сижу на лайвсиди с блобом, перезагружаю пк раз в месяц в новую версию лайвсиди. Не работает или работает хуже примерно 1 игра из 1000 (с dxvk, без него у того же юнити проблемы вроде фризов и в нативных версиях).
>уже год сижу
>Не работает или работает хуже примерно 1 игра из 1000Однако, вы феноменальный игрун достойный книги рекордов и иссследования! Я вот только одну Mass Effect Andromeda проходил в течении полугода :(
Да обычное дело. Обычно я не прохожу их целиком: куплю, наиграюсь, покупаю следующую. Если очень нравится, могу потратить часов 10, больше уже боль и страдания - очень редко игры делают так, чтобы они были интересны до конца (некоторые легко держат все 50 часов). Но обычно остаётся приятное впечатление. И если мне скучно я просто отложу до лучших времён. Игры должны развлекать в конце концов, когда в игре на 10 часов контента на 2 часа это тоже не дело.
> есть ли заветные 30 фпс или их нет? Тогда эти 10% решают вопрос3 fps решают? :)