Wine 6.23

Уж это-то не должно вызывать трудностей. Собирайте deferred state и пуште только во время дравколов.

Да, такое он тоже упоминал:

The "no calls at all" option is likely to be the choice for d3d.
d3d already uses a worker thread to do actual GL/vulkan calls.
Producer and consumer communicate via a lockless ring buffer. We
don't need to leave guest space to write to the ring buffer, and
the host side can read from it just fine without entering guest
space. That's less likely to be an option for GL and Vulkan
because adding our own async render thread for those APIs would
be a huge amount of work.

То есть, по крайней мере для д3д они так сделают со временем, и оверхед уйдёт. Для других АПИ, типа, «слишком трудно». :) Но другие под виндой-то и не особо кто использует, так что, видимо, со временем, от основного оверхеда уйдут. Суть была лишь в том, что уход от мультилиба не ограничивается конверсией в ПЕ32, а потребует переписывания здоровенных кусков, и по тому, рановато пока строить роадмапы.

vulkan под вендой вполне используют. opengl тоже, не в играх обычно правда

d3d там работает с нормальной скоростью только через dxvk, то есть, vulkan

ну или через nine(mesa)

Сейчас игровые движки так и делают внутри себя, когда предоставляют подобные апи Этим же занимается OpenGL под макосью.

А почему это не может делать, например, сама меса?

Вообще, кому-то давно пора сделать glvk в PE, желательно ещё и с разделением потоков на сборку и исполнение коммандбуферов. Уделает винду по перформансу, обещаю.

Где-то писали, что чел, который у них хотел это сделать, погиб. Придётся вам его заменить.

потому, что mesa находится за пределами wine, а обсуждаемый оверхед - в пределах wine?

Не, это понятно. В вайне никак. Но вы про движки говорили, т.е. почему меса это не может делать, чтобы другим было хорошо, а движкам - не приходилось делать это?

Во-первых, в месе уже есть для этого Zink уровнем ниже https://www.collabora.com/assets/images/blog/zink/zink-architecture.png

во-вторых это никак вайну не поможет потому что меса находится по другую сторону мультилиба

в-третьих да, меня раньше тоже интересовал этот вопрос. Емнип кто-то с кружочков, кажется, zeus, выкатывал враппер для dx9 который именно это и делал.

чел, который у них хотел это сделать, погиб. Придётся вам его заменить.

Звучит рискованно :-)

Емнип кто-то с кружочков, кажется, zeus, выкатывал враппер для dx9 который именно это и делал.

Несколько странно, если это такой халявный прирост - почему «кто-то выкладывал враппер»… Полагаю, какие-то подводные камни тут зарыты.

Звучит рискованно :-)

Да вообще мультилиб из вайна рискованно выпиливать. Кен Томасес, который силанг пропатчил в кодевиверс, тоже сразу умер.

майкрософт балуется полонием и новичком

типа, «слишком трудно»

Могу вкратце объяснить за OpenGL:

• это не один апи. <2 , 2+, 3.2+ и 4.4+ (bindless в коре) отличаются достаточно весомо

• режимы совместимости, когда вроде 3.2, но и 2- тоже можно

• экстеншоны позволяют просто брать фичи из других версий и мешать как попало

• неписаные правила, специальные сочетания функций, не всегда описанных в апи. Классический пример, buffer orphaning:

To orphan, just use the buffer re-specification technique (glBufferData(NULL), glMapBufferRange(GL_MAP_INVALIDATE_BUFFER_BIT), or glInvalidateBufferData). You then get a fresh block of storage underneath the buffer handle to scribble on that no other GL commands can be referring to, so no synchronize is needed.

• GLSL это катастрофа. В своём движке я внаглую модифицирую код обходя наиболее популярные проблемы

• Возможности, скрытые за простым PBO это штота. Начиная с R2VB и заканчивая хтоническим ужасом в духе Кармаковских обратных корней

• поддержка многопоточности через шареные контексты.

Это только что сходу в голову приходит. Будь я молодой и глупый, я бы взялся, так как очень в теме, но теперь я матёрый и знаю, что это проект на долгие годы и мне никакой мотивации не хватит тащить эту лямку.

Но есть и плюс: всевозможные реализации OpenGL настолько всрато работали, что каждому вменяемому приложению приходилось писать фолбеки для худших случаев. Поэтому насколько бы хреново не реализовывала бы прослойка, большинство приложений каким-то чудом эти косяки обойдёт. Главное в GL_VENDOR соврать, что ты штеуд и тогда приложение уже не будет ни на что надеяться и чего-то ждать (особенно 4 и 6 пункты)

Да, но вопрос был не о проблемах ОпенГЛ в общем и целом. Вопрос был, почему меса не может батчить пользовательские запросы сама, и если какие нашлёпки и есть, то они непонятно где и кем писаны, и непонятно, какой прирост дают. Если ответить на этот вопрос, то, скорее всего, станет понятно и то, почему для вайна это непосильная задача. Тк корни проблемы будут, скорее всего, едины. Впрочем, я вполне допускаю, что чёткого ответа тут и нет. Что всё складывается из тысяч всяких мелких проблемок. Но просто я не вижу очевидной связи между проблемами батчинга, и теми проблемами, что вы описали.

Это было описание причин, по которым сложно написать glvk за вменяемые сроки. Что касается оптимизаций самого OpenGL, то реализация под макос, например, собирает deferred state и применяет только актуальное на момент дравкола состояние (при этом ругаясь на redundant calls). Самая быстрая реализация с разделением тредов увеличит инпут лаг, так как рендер-тред будет всегда на один кадр отставать by design. У нвидии емнип вообще профили с разным поведением под каждое популярное приложение. К последнему можно стремиться хотя бы для наиболее распространённых и запущенных случаях, но, имхо, уже не очень актуально. Месу не ковырял, так как проблемы оптимизации под Линукс обычно волнуют людей разве что в качестве хобби. Платить на работе за такое никто не станет.

реализация с разделением тредов увеличит инпут лаг

С другой стороны, дизайн OpenGL это разрешает, и на той же макоси вызовы OpenGL неоправданно тяжёлые. Наверное, основная причина в том, что приложения от вменяемых разработчиков уже имеют отдельный рендер-тред, а значит, профита реализовывать это на стороне OpenGL нет. Вот если бы с самого начала так было, это другое дело.

что приложения от вменяемых разработчиков уже имеют отдельный рендер-тред,

Но мне всё ещё непонятно, откуда вообще этот самый прирост. Да, приложение начнёт «работать» быстро. Но тормозить будет рендер трид, и с чего бы ФПСу повыситься?

(при этом ругаясь на redundant calls)

Видимо, только вот в этом и вся оптимизация?

Это две разные оптимизации. Сокращение вызовов апи за счёт кэширования стейта нередко есть в самих приложениях (хотя я часто встречал игры где не, в том числе под dx). При трансляции в вулкан очевидно, понадобится ещё и кэшировать созданные пайплайны.

Но тормозить будет рендер трид

Вынос вызовов в рендер-тред же помогает ускорить cpu-bound приложения, которые не успевают в одном потоке за условные 16мс обработать и графику, и игровую логику. Вызовы апи не бесплатны, и в сумме жрут драгоценные миллисекунды. Так как игры, использующие OpenGL зачастую ещё и однопоточные, это может заметно помочь.

Это может помочь даже в случае, когда видеокарта является узким местом, например, если между первыми вызовами будет достаточно времени на какую-то внутреннюю логику приложения и видеокарта будет скучать, в то время как рендер-тред мог бы кормить её командами максимально интенсивно.

Также это в какой-то мере сгладит implicit synchronization, т.к. ожидания гпу внутри рендер-треда не затронут основной тред.

Чем больше пишу, тем больше понимаю, что это всё митигация криворукости писателей приложений и нормально написанным программам будет только мешать.

майкрософт балуется полонием и новичком

Слишком чёрно…

Ага, примерно понял, спасибо. А для вайна, соответственно, нужна именно первая оптимизация - сокращение кол-ва вызовов. И как раз это-то они и вряд ли потянут. А просто перетаскивание всех вызовов, как есть, в другой трид - им особо ничего и не даст, кроме тормозов. Всё верно?

Верно. И если в старых приложениях используется glBegin, то там сокращение вызовов будет идти на сотни: вместо вызова на каждый атрибут каждой вершины можно сократить до одного вызова передающего сразу массив. Конкретно этот кейс обернуть нетрудно, он же будет давать худший перформанс если не оборачивать. Но это прям древнее зло, так уже лет 20 никто не пишет (я надеюсь)

им особо ничего и не даст, кроме тормозов

В зависимости от приложения, может дать как прирост, так и лишние тормоза (если отдельный рендер тред уже есть на стороне приложения)

И как раз это-то они и вряд ли потянут.

Они не потянут трансляцию в Вулкан, что позволило бы прям совсем сократить т.к. он позволяет прям целое состояние закэшировать и потом переиспользовать. А просто сократить вызовы которые бессмысленно меняют состояние между дравколами (в жопоруких приложениях, коих большинство) потребует куда меньше усилий.

dxvk-то как раз PE бинарь

dxvk-то как раз PE бинарь

+1.

К тому же чел ведь писал вот это:

The "no calls at all" option is likely to be the choice for d3d.
d3d already uses a worker thread to do actual GL/vulkan calls.

Так что, видимо, д3д в вулкан они как раз и потянут, а остальное (остальное - это ГЛ в вулкан, что ли?) - видимо, нет…

Это было описание причин, по которым сложно написать glvk за вменяемые сроки.

А, собственно, анонимус про ГЛ в вулкан и говорил… Тогда всё сходится. :)

Зачем они это развивают? Для кого?

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

Лул. Пробовал запустить такую игрушку, как ворлд оф тэнкс блиц недавно на невидии 9500 джифорс, вроде: 5-6 версий протона показали кукиш. Правда, показали по-разному, какие-то даже пытались, но не шмогли.

А так да, на линупсе с пердолингом можно что-то запустить в вайне, винрар какой-нибудь, не более. Зы. человеку пришлось семерочку максимальную накатить, ну там ясень пень всё заработало, чай не линупс.

Толсто.

https://www.protondb.com/app/444200

У меня он тоже не работает несмотря на отзывы в protondb.

Хотя, конечно, про один винрар смешно читать. Так-то 80-90% игр работают.

невидии 9500 джифорс

Без вулкана сходу идёшь на венду.

С параметрами shader_backend=arb и strict_shader_math=1, на NVIDIA с проприетарным драйвером нормально работает wined3d.

Это дерьмо имеет дикий оверхед и абсолютно бесполезно по сравнению с dvxk. Ещё, последний раз, когда я его пробовал, оно вовсе не запускало то, что dxvk запускал.

Да на самом деле, они что-то сильно поломали ближе к началу этого года, в протоне. Сначала на brwrap ругаться начал, потом ещё на что-то, потом на фритайп. Потом они выкатили некий proton-experimental, которого раньше не было, и понадобился он, видимо, как раз чтобы экстренно латать баги в стиле «а у меня всё отвалилось». И, скажем, у меня где-то только осенью начало всё «оживать» в proton-experimental.

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

Значит, нужно было ставить предыдущий стабильный релиз, или как там у них.

Значит, нужно было ставить предыдущий стабильный релиз, или как там у них.

Ну стабильных там нет в принципе - это всё доступно если поставить галку «участвую в бета-тестировании», или типа того (по памяти пишу). А так - да, откат на какую-то прошлогоднюю версию решал проблемы, но блин, так глубоко не каждый станет откатываться.

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

Это не продуктивно для него. Юзер уже согласился на бета-тестирование, а значит, его стоит всегда держать на последней версии (теперь это протон-экспериментал), чтобы собирать баг-репорты на гитхабе. Иначе кто будет чего репортить? И для кого тогда вообще стараться и выпускать новые версии? Может, когда-нибудь они и сделают ЛТСные ветки, но сейчас, пока у них может всё развалиться на годик вперёд, мы можем только в тестировании поучаствовать и порепортить баги. Впрочем, мои репорты им никогда особенно не помогали, тк всегда оказывалось, что этот баг уже зарепорчен раз этак тысячу. Мне оставалось на него только подписаться и мониторить апдейты…

У меня он тоже не работает несмотря на отзывы в protondb.

Хотя, конечно, про один винрар смешно читать. Так-то 80-90% игр работают. конечно, работают. но как обычно именно тебе бывают нужны оставшиеся 10% игр, и тогда мало радости от работающих игр, когда ты идешь со своим нахваливаемым другим линупсом в поросячью задницу. с другой стороны, можно же поорать на нищебродов с древним железом, однако там где винда просто работает, линупс зачастую не дает того же даже после кровавых мозолей от напильника 😭😂😄