Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от opennews (ok), 02-Дек-24, 23:19
После почти трёх лет работы консорциум Khronos, занимающийся разработкой графических стандартов, опубликовал спецификацию Vulkan 1.4, определяющую API для доступа к графическим и вычислительным возможностям GPU. Новая спецификация вобрала в себя накопившиеся  расширения, которые ранее позиционировались как опциональные, а также предоставила ряд новых возможностей и повысила минимальные требования к оборудованию. Инструментарий Vulkan SDK планируют опубликовать в январе 2025 года... Подробнее: https://www.opennet.me/opennews/art.shtml?num=62331
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

3. Скрыто модератором	–19 +/–
Сообщение от Аноним (3), 02-Дек-24, 23:31
Сколько лет пилят и всё никак не допилят. Даже из флагов хрома убрали возможность работать через вулкан 😁
Ответить | Правка | Наверх | Cообщить модератору

	6. Скрыто модератором	–4 +/–
	Сообщение от Аноним (6), 03-Дек-24, 00:12
	Прямо как вяленого. Очередной оупенсорцный долгострой.
	Ответить | Правка | Наверх | Cообщить модератору

	20. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 03-Дек-24, 01:07
	Лол что? Версия 1.3 была в 22 году. А сам стандарт с 2016го. Плюс ты учти инертность отрасли.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	100. Скрыто модератором	+1 +/–
	Сообщение от Аноним (100), 03-Дек-24, 15:27
	Не убрали, это браг, что пропал флаг. Можешь включить через "--enable-features=EnableVulkan"
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

10. "Опубликован графический стандарт Vulkan 1.4"	+2 +/–
Сообщение от Аноним (-), 03-Дек-24, 00:24
Вроде бы много улучшений, но хотелось бы увидеть больше внимания к упрощению разработки под Vulkan. API все еще довольно сложный."
Ответить | Правка | Наверх | Cообщить модератору

	44. "Опубликован графический стандарт Vulkan 1.4"	+13 +/–
	Сообщение от Аноним (44), 03-Дек-24, 05:43
	Ого технически простым быть не может, можно накостылить абстракции и опять получить opengl.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Опубликован графический стандарт Vulkan 1.4"	–15 +/–
	Сообщение от laindono (ok), 03-Дек-24, 05:50
	Есть WebGPU, который простой и быстрый одновременно. Точно проще и быстрее OpenGL.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (181), 08-Дек-24, 08:24
	> Есть WebGPU, который простой и быстрый одновременно. Точно проще и быстрее OpenGL. Судя по тому что я видел в программах которые это пытались юзать - у вэбобизянок получился весьма характерный кривой уродец. Который уж точно не low overhead, тормозит что апокалиптец даже на мощном проце и GPU, и напрягается отрендерить даже любительское двигло на конфиге которая с вулканом AAA игры тянет на ура. Или как продолбать 90% возможностей железки - вникуда.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от laindono (ok), 08-Дек-24, 10:43
	Я лично тестил. Как минимум нативная версия WebGPU от Mozilla, которая wgpu, прям ощутимо быстрее OpenGL. То, что оно медленнее Vulkan, это очевидно и без тестов, но я обратного и не утверждал. Что там по итогу в вебе получается, меня вообще честно говоря не интересует.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от Аноним (82), 03-Дек-24, 11:12
	Дрова в юзерспейс вынесли, о какой простоте может идти речь?
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	142. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (142), 04-Дек-24, 12:17
	Не будет никакого упрощения. Будет только усложнение до бесконечности. OpenGL в своё время тоже с каждой версией становился всё сложнее. Добавлялись новые шейдеры, инстансинг, юниформовые буфера (про раскладку std140 я вообще молчу). Теперь Vulkan продолжает тоже самое. Чтобы хоть немного упростить, надо всю концепцию рендеринга менять ещё на аппаратном уровне.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	144. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от Аноним (144), 04-Дек-24, 14:44
	OpenGL-у приходилось еще кучу легаси аж с дошейдерных времен с собой тащить, для совместимости. А Vulkan - это OpenGL, каким бы он был написан с нуля сегрдня.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (142), 04-Дек-24, 22:52
	И что? Стало легче приложения разрабатывать? Ну производителям видеокарт может быть конечно и легче поддерживать vulkan вместо opengl. А пройдёт 10-20 лет, дак и у вулкана свой легаси ещё появится.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Опубликован графический стандарт Vulkan 1.4"	+2 +/–
	Сообщение от Аноним (144), 05-Дек-24, 00:16
	Какой ужас, gpu за это время всего-то в 20 тысяч раз сложнее стали, совсем уже ничего не могут эти ваши кроносы. OpenGL теперь легаси, смирись.
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (142), 05-Дек-24, 10:19
	OpenGL ещё 10 лет минимум проживёт. Вулкан сейчас не готов его полностью заменить. Вон, WebGPU до сих пор в экспериментальной стадии и из коробки не робит. Да и на андроиде где апи на джаве под вулкан? Только через NDK, судя по официальной доке.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (158), 05-Дек-24, 05:04
	> И что? Стало легче приложения разрабатывать? Ага. Теперь автыри движков могут сделать что хотели - вместо героической борьбы с дурацким апи делавшим не то что надо движку, дико тормозя при этом. > Ну производителям видеокарт может быть конечно и легче поддерживать vulkan вместо opengl. Намного легче. Как и прикручивать это к движкам. > А пройдёт 10-20 лет, дак и у вулкана свой легаси ещё появится. Тем не менее он в целом наного более простая в реализации штука. И намного более резвый, оверхеда сильно меньше. Что на потоках в гигазы в секунду - аргумент. А совсем без движка гамезы мало кто нынче делает.
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

	166. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (142), 05-Дек-24, 10:32
	Да вам сколько не дай перформанса, всегда будет мало. Да и помимо гамезов есть разные задачи, с которыми современные игровые двиги могут быть мало эффективны.
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (144), 05-Дек-24, 19:59
	> Да вам сколько не дай перформанса, всегда будет мало. У уважаемого анонима, как я понимаю, есть работающая альтернатива прогрессу? > Да и помимо гамезов есть разные задачи, с которыми современные игровые двиги могут быть мало эффективны. Да, есть. И что?
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 08-Дек-24, 08:31
	>> Да и помимо гамезов есть разные задачи, с которыми современные игровые >> двиги могут быть мало эффективны. > Да, есть. И что? Однако вон там Lynne из FFMpeg прикололась - и таки - запилила кучу фильтров процессинга ffmpeg работающих на GPU, через вулкановское апи. Раз уж там еще и считать можно и апи довольно простое. Пример вообще совсем не игрового движка - которому вулкан тоже зашел.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 08-Дек-24, 08:28
	> Да вам сколько не дай перформанса, всегда будет мало. Тем не менее в OpenGL очень дорогие draw calls, немеряный state с кривым доступом и проч. Поэтому вместо того чтобы сделать то что собирались как удобнее было - начинается порнография с воркэраундом всего этого, если полтора FPS в мощной конфиге не хочется. > Да и помимо гамезов есть разные задачи, с которыми современные игровые двиги > могут быть мало эффективны. Как ни странно - в вулкане есть еще API для compute и video. Так что умеющие в него - бонусом смогут еще и... 1) Немного посчитать. Или не очень немного. 2) Интерфейснуться к хардварным декодерам видяхи. А по моему и энкодерам уже.
	Ответить | Правка | К родителю #166 | Наверх | Cообщить модератору

16. "Опубликован графический стандарт Vulkan 1.4"	–10 +/–
Сообщение от Аноним (6), 03-Дек-24, 00:45
Вулкан не взлетел. Помню в году эдак 2015 пророчили что он одним махом заменит opengl. Воз ныне там 🤷‍♂️
Ответить | Правка | Наверх | Cообщить модератору

	17. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (17), 03-Дек-24, 00:53
	Вулкан никуда и не взлетает, он в лучшем случае конкурент. Впрочем, даже тотальное хейтерство в сторону ДХ и ОГЛ не помогло.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Опубликован графический стандарт Vulkan 1.4"	+10 +/–
	Сообщение от Аноним (-), 03-Дек-24, 01:03
	> Вулкан не взлетел. Угу, и во всех современных видяхах поддержка, и куча движков (unreal, unity, даже всякие бомж варианты типа годота). Точно не взлетел! Сейчас даже проще opengl эмулировать через вулкан, чем костылять нативку. > Помню в году эдак 2015 пророчили что он одним махом заменит opengl. Воз ныне там 🤷‍♂️ Не знаю кто там пророчил если его только в 2014 начали разрабатывать, а выпустили в 16 году. Ты думаешь все сразу побежали переписывать движки и игры на новый АПИ? И тем не менее куча новых игр типа Baldur's Gate 3, RDR2, Star Citizen и тд уже поддерживают.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	22. "Опубликован графический стандарт Vulkan 1.4"	–20 +/–
	Сообщение от Аноним (17), 03-Дек-24, 01:12
	> И тем не менее куча новых игр типа О которых никто не слышал. Пришлось гуглить что это за казуалки.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Опубликован графический стандарт Vulkan 1.4"	+9 +/–
	Сообщение от Аноним (75), 03-Дек-24, 10:30
	Ну да, не широкораспространённые Tux Racer и Xonotic.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от Аноним (104), 03-Дек-24, 16:20
	Nexuiz, urban terror, supertuxkart и tremulous.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 16:35
	> Nexuiz, urban terror, supertuxkart и tremulous. Погоди-ка! urban terror это только открытый движок, сама игра проприетарь, хоть и бесплатная. Хотя название для попенсорс проэкта было бы отличное) Nexuiz мертво, да и еценка 6/10 на стиме как бы намекает на качество. И заодно учит что неблягодарные потербялди отвернутся от разработчика если он попросит денег. supertuxkart - жалкое подобие мариокартов, тк со своими идеями у попенсорсников туговато, приходится копировать успешных первопроходцев. Tremulous - жуткий баланс и "генитальные решения" - тоже мертв.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 04-Дек-24, 20:24
	> Хотя название для попенсорс проэкта было бы отличное) > Nexuiz мертво, да и еценка 6/10 на стиме как бы намекает на качество. Софт делаемый комьюнити живет пока это кому-то надо. Ну оно и воскресло как Xonotic. Живой такой, веселый, headshot кому-нибудь в нем навесить - милое дело. Да и у...ть от толпы раздолбаев уперев их флаг - весьма адреналинисто и кайфово. > И заодно учит что неблягодарные потербялди отвернутся от разработчика если он попросит > денег. Если разработчик сто лет не разрабатывает - и удумывает кинуть комьюнити, сдав их как стеклотару совершенно левой фирме, с совершенно посторонними технологиями - его и правда могут не понять. Да и отфоркать нахрен, и проект, и название. Так появился Xonotic.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (75), 03-Дек-24, 17:54
	Тоже «отличные» примеры.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	111. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Анонимусс (-), 03-Дек-24, 18:19
	>  Тоже «отличные» примеры. Наоборот! Именно отличные. Отлично показывают эээ... "вкусы" представителей местной аудитории. Удивительно что Heroes of Wesnoth не вспомнили.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (118), 03-Дек-24, 20:32
	Lincity one love.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (158), 05-Дек-24, 05:05
	>> И тем не менее куча новых игр типа > О которых никто не слышал. Пришлось гуглить что это за казуалки. Может ты и про DOTA не слышал? А то она тоже вулкан умеет, чертову кучу лет...
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	47. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от leap42 (ok), 03-Дек-24, 06:50
	> Воз ныне там 🤷‍♂️ Эм, точно? Я вот из гнома пишу, у него сейчас новый рендеринг: vulkan по умолчанию, ngl на подстраховке. Иногда Ведьмака в lutris запускаю, и там vulkan.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	56. "Опубликован графический стандарт Vulkan 1.4"	+3 +/–
	Сообщение от Андрей (??), 03-Дек-24, 07:25
	И при этом сейчас vulkan на линуксе почти везде(стимдековский протон не просто так летает), вплоть до того, что ogl через него то ли обещали обернуть, то ли обернули, что и не удивительно, т.к. суть вулкана именно в том, чтобы быть сделать гибкую низкоуровневую прослойку. Единственное, что не совсем ясно так это то, что вулкану обещали низкоуровневость вплоть до возможности любые вычисления на ускорителях через него обернуть, в т.ч. OCL, SYCL, но в каком это сейчас состоянии не понятно.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	57. "Опубликован графический стандарт Vulkan 1.4"	–12 +/–
	Сообщение от пох. (?), 03-Дек-24, 07:43
	прям так везде что о нем только и говорят но никто не видел. Прекращай пороть чушь.. .
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от nume (ok), 03-Дек-24, 15:27
	> говорят но никто не видел Настолько никто не видел что gtk4 и gnome сейчас через вулкан вместо opengl, plasma уже разрабатывает замену opengl на вулкан. Cosmic через вулкан. Все игры на linux кроме 15-20 летних через вулкан в первую очередь. Почти всё графические по использует вулкан (или в процессе обновления). wine windows directx через вулкан. opengl тоже эмулируется через вулкан сейчас чаще чем нативно. Конечно никто не видел))
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Хо (?), 03-Дек-24, 18:41
	У большинства местных на коре дуба не работает!
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от Аноним (75), 03-Дек-24, 09:24
	Заменить он должен был разве что Direct3D, OpenGL и так умер.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

18. "Опубликован графический стандарт Vulkan 1.4"	+6 +/–
Сообщение от Аноним (18), 03-Дек-24, 00:56
Давно уже почти все используют в качестве рендера вулкан. Даже ретро через dxvk. И это хорошо. Опенсурс хотя бы здесь смог отвязаться от корпов в лице дх. Благодаря конечно мантлу от амд, и вальвы с протоном. Для себя как обычный пользователь, ощутил больше свободы. Узнать бы какие еще прорывы ждут в опенсорсе в будущем.
Ответить | Правка | Наверх | Cообщить модератору

	24. "Опубликован графический стандарт Vulkan 1.4"	–3 +/–
	Сообщение от Аноним (17), 03-Дек-24, 01:14
	> Давно уже почти все используют в качестве рендера вулкан. Примеры будут? А то что-то как был DX11 и c OpenGL так и остаются. Даже Metal сугубо маковский занимает больше рынка, чем кроссплатформенный вулкан)
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Опубликован графический стандарт Vulkan 1.4"	+2 +/–
	Сообщение от Аноним (33), 03-Дек-24, 03:17
	Что подразумевается под "больше рынка"? Больше игрушек написано? Больше железяк поддерживает?
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (46), 03-Дек-24, 06:39
	Рынок - это товарно-денежные отношения. Коллеге неплохо бы подкрепить свой тезис цифрами.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Опубликован графический стандарт Vulkan 1.4"	–3 +/–
	Сообщение от robot228 (?), 03-Дек-24, 07:49
	OpenGL это сложная архитектура и очень косячная ВЕЗДЕ. Надеюсь как и многие миллионы - Vulcan заменит его в скором времени.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	64. "Опубликован графический стандарт Vulkan 1.4"	–2 +/–
	Сообщение от robot229 (?), 03-Дек-24, 07:54
	Смешно, учитывая насколько вулкан сложнее из-за низкоуровнивости.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (142), 05-Дек-24, 10:41
	Это называется легаси, а не косячная.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	54. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (6), 03-Дек-24, 07:19
	> Давно уже почти все используют в качестве рендера вулкан. Насколько "давно" и кто это "все" по вашему?
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

21. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
Сообщение от Аноним (21), 03-Дек-24, 01:11
На самом деле нет особой разницы в api, влиять будет то как конкретный проект оптимизируют. https://www.youtube.com/watch?v=NbpZCSf4_Yk
Ответить | Правка | Наверх | Cообщить модератору

27. "Опубликован графический стандарт Vulkan 1.4"	–2 +/–
Сообщение от Zenitur (ok), 03-Дек-24, 02:28
Может не в тему, но всё равно спрошу. Установил на нетбук Win98IF, DirectDraw-игрушки работают нормально, а Direct3D хотят дрова. Есть открытые драйверы для винды на ATi Radeon 6250?
Ответить | Правка | Наверх | Cообщить модератору

	29. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Хрю (?), 03-Дек-24, 02:36
	Что такое IF в контексте Win98IF?
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от Zenitur (ok), 03-Дек-24, 03:27
	Неофициальная сборка. Как расшифровывается - не знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от _kp (ok), 05-Дек-24, 15:23
	Так читайте особенности сборки (внизу красным шрифтом): При установке драйверов.. безнадёжно зависает, портит файловую систему, конфликтует с установщиком, установка не работает, установка прерывается, начинает тормозить, старые игры вылетают... Ну и дизайн обгажен. Оно Вам точно надо?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 05-Дек-24, 17:25
	Нормально работает. Баги встречаются, но данные не бьются. У меня не бились, во всяком случае. Сборка включает в себя все обновления, которые выпускались вплоть до окончания поддержки в 2005 году. Также в сборку включён патч от Рудольфа Лоева, позволяющий увидеть 2 Гб ОЗУ. Также я не занимался поиском и установкой дров на контроллер жёсткого диска и на видеокарту. Наверное там UniVBE и UniATA.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Опубликован графический стандарт Vulkan 1.4"	+6 +/–
	Сообщение от Аноним (38), 03-Дек-24, 03:40
	Васянская сборка 98SE, IF - Игорь Федоренко.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	143. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (143), 04-Дек-24, 14:40
	*Игорянская сборка
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (48), 03-Дек-24, 07:03
	Нет и не будет.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	96. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 03-Дек-24, 15:12
	Я так и думал, но всё же решил спросить. Например я нашёл проект стороннего энтузиаста, который портировал актуальную Месу на Win98. Правда, она только софтварная. Автор позиционирует проект для виртуальных машин.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (75), 03-Дек-24, 10:28
	Жениться б вам, барин… Много ли тех Direct3D-игрушек, которые не заработают на условной семёрке?
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	92. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (92), 03-Дек-24, 13:53
	По пробуй WineD3D  - DirectX 1-11 to OpenGL wrapper Использовать DirectX через OpenGL
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	97. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Zenitur (ok), 03-Дек-24, 15:13
	OpenGL на данной машинке тоже нет. Последние дрова для ATi для Windows 98 выпускались я даже не знаю для какого поколения. Наверное 9700/9800 и X800/X1000.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (106), 03-Дек-24, 16:30
	не, для ати X1xxx серии уже не было дров под Win9X. а для X800 дрова умеют только DX9b, не 9c. у невидии дрова были и для GT6xxx серии, с поддержкой DX9c. для просто работы в SVGA режимах можно использовать VBEMP (есть в сборке).
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 03-Дек-24, 18:30
	> не, для ати X1xxx серии уже не было дров под Win9X. > а для X800 дрова умеют только DX9b, не 9c. > у невидии дрова были и для GT6xxx серии, с поддержкой DX9c. > для просто работы в SVGA режимах можно использовать VBEMP (есть в сборке). Не знаю что в сборке, однако Герои 3 работают, а Морровинд - нет. Эх, а ведь нетбук - офигенная альтернатива стационарному Атлону для игры в старые игри... Впрочем, проблема решается при помощи Windows XP. Или ReactOS :)
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (92), 04-Дек-24, 08:47
	Если скорость игры (fps) не самый важный параметр (например: пошаговые игры ) Можно попробовать sowfware mesa driver OpenGL - его в принципе пофиг вообще на видюху - все будет делаить проц...
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 04-Дек-24, 20:27
	> Не знаю что в сборке, однако Герои 3 работают, а Морровинд - > нет. Эх, а ведь нетбук - офигенная альтернатива стационарному Атлону для > игры в старые игри... Впрочем, проблема решается при помощи Windows XP. > Или ReactOS :) Что, зеня, старость пришла - на извращения потянуло?! :)
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	151. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 04-Дек-24, 20:48
	Герои 3 всю жизнь играю. А из Морровинда даже ник взял.
	Ответить | Правка | Наверх | Cообщить модератору

	160. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (158), 05-Дек-24, 05:06
	> Герои 3 всю жизнь играю. А из Морровинда даже ник взял. В геруев можно и в VCMI поиграть, без таких ужасных извращений.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 05-Дек-24, 07:38
	> извращений. Разве поставить винду ради игры в героев - это извращение? > VCMI Тогда уж HotA.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от _kp (ok), 05-Дек-24, 15:41
	Морровинд работает на Windows98 c вменяемой дискретной видеокартой. У меня на коллекционном ноутбуке c PII 400 стоит он. Но играть на этом так себе. :( Но Морровинд нужен строго без графических расширений, которые сейчас встроены в любую сборку, и без тяжелых модов. Лучше найти образ оригинального CD. И поставить нормальный Windows, а не васянскую сборку. > Эх, а ведь нетбук - старый нетбук - это отсутствие видеокарты. А запуск игр на муляже видеокарты отдельная тема. На 4ПДА почитайте, что получите на W98, и смело забейте. Полноценных драйверов для W98 для нетбуков нет! А установите Win7 или Windows XP, так старые игры без пинков и запустятся. На минималках.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	175. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 05-Дек-24, 17:05
	Я играю на современном компе. Wine прекрасно тянет игру. А также у меня есть ретро-компьютер Athlon XP в связке с видеокартой 7600GT. Решил заменить его на нетбук. По производительности - то же самое, а по гаьбаритам и шуму - гораздо лучше. Я без проблем установлю XP, там дрова есть. Просто надеялся, вдруг кто-то подскажет дрова для Win98. Вдруг и правда есть?
	Ответить | Правка | Наверх | Cообщить модератору

37. "Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от Аноним (37), 03-Дек-24, 03:40
Одного меня начинает серьёзно раздражать эта зависимость всего и вся от LLVM?
Ответить | Правка | Наверх | Cообщить модератору

	55. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (6), 03-Дек-24, 07:20
	А тебя не раздражает зависимость всего и вся от ядра, которое в свою очередь зависит от одного человека, который не вечен?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от User (??), 03-Дек-24, 11:21
	Ээээ... В каком месте оно от него зависит?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (75), 03-Дек-24, 09:25
	Да.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	76. "Опубликован графический стандарт Vulkan 1.4"	+5 +/–
	Сообщение от Анониссимус (?), 03-Дек-24, 10:48
	А анонам всё не нравится. Если много проектов -- зоопарк, если один проект -- зависимость всего и вся...
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	94. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (94), 03-Дек-24, 14:01
	Не только тебя. Гента, ллвм не установлен.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	102. "Опубликован графический стандарт Vulkan 1.4"	–2 +/–
	Сообщение от Аноним (-), 03-Дек-24, 16:12
	Да, тебя одного. LLVM это возможность уйти от копирастического ЕЕЕ в GCC (гнутые расширения). Поэтому чем больше фирм будут использовать его - тем лучше.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	103. "Опубликован графический стандарт Vulkan 1.4"	+3 +/–
	Сообщение от Аноним (-), 03-Дек-24, 16:12
	>  Одного меня начинает серьёзно раздражать эта зависимость всего и вся от LLVM? Т.е. когда все прибито к гцц, это норм. А когда к ллвм, то это раздражает. Нормальные такие двойные стандарты...
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	168. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (168), 05-Дек-24, 12:57
	> Т.е. когда все прибито к гцц, это норм. Как собрать GCC? mkdir build2 ../configure --enable-languages=c,c++ --prefix=/home/username/gcc-version Единственное отклонение от нормы - то, что нельзя вызвать configure прям из папки с исходниками. Как собрать LLVM? А хрен его знает! Начать с того, что архивов с исходниками 6 штук. Это уже вводит в заблуждение. Пытался распарсить SPEC-файл, чтобы вычленить простую и понятную команду - не смог. Одно только это делает LLVM хуже, чем GCC: когда пытаются усложнить то, что в усложнении не нуждается. Версия 6 - последняя, которая собралась и на 64-битной, и на 32-битной системе (сборка нужна для работы Mesa в multilib). Начиная же с 7 версии - на stage2 в упор не видит libffi. Который разумеется есть: и 32-битный, и 64-битный... Запрещаешь сборку с libffi - теперь libncurses не видит. А запрещаешь его - ещё что-то не видит. В итоге пользуюсь готовыми сборками с apt.llvm.net. Разве такой подход нормален? Всё равно что сказать "сидите и не p-diddy - умные дяди за вас всё собрали, кушайте что дают и не пытайтесь собирать сами". Офигенная характеристика для _компилятора_, не находите? Ну и время сборки, конечно - моё почтение. Дольше только Хром собирается.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (-), 05-Дек-24, 15:07
	> Как собрать GCC? Тут скорее вопрос "зачем?")) > Как собрать LLVM? > А хрен его знает! Начать с того, что архивов с исходниками 6 штук. Это уже вводит в заблуждение. Ты уверен что ты все делал "так"? Тут есть вполне понятная инструкция https://llvm.org/docs/GettingStarted.html#getting-the-source... > Одно только это делает LLVM хуже, чем GCC: когда пытаются усложнить то, что в усложнении не нуждается. В таком случае линукс не нужен - есть "неусложненная винда для проф.домохозяек" > Версия 6 - последняя, которая собралась и на 64-битной, и на 32-битной системе... Но зачем? Если ты уже собираешь - то скорее всего под платформу. У тебя же не меняется система туда-сюда. Значит можно сделать сборку для 32 и для 64 отдельно. > В итоге пользуюсь готовыми сборками с apt.llvm.net. Разве такой подход нормален? Всё равно что сказать "сидите и не p-diddy - умные дяди за вас всё собрали, кушайте что дают и не пытайтесь собирать сами". Именно так сделали разработчики GCC, которые позволяют скачать с кучи зеркал tar.gz https://gcc.gnu.org/mirrors.html > Офигенная характеристика для _компилятора_, не находите? Судя по сайту гцц - практика принятая в индустрии) > Ну и время сборки, конечно - моё почтение. Дольше только Хром собирается. И как часто тебе приходится собирать? Ну не каждую неделю как гентушники) Я например делал это всего пару раз и то больше для самообразования. А претензии что "умные дяди за вас всё собрали" - если ты не доверяешь собранным и подписанным сборкам с указанными fingerprintʼми, то сорцам точно так же можно не верить. Может там прямо в код напихали бекдоров. Но я очень сомневаюсь, что ты пересматриваешь каждый коммит для gcc.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 05-Дек-24, 15:34
	> Тут есть вполне понятная инструкция За ссылку спасибо. Буду пробовать. > И как часто тебе приходится собирать? Каждый раз, когда выходит новая версия LLVM (или когда новая Mesa просит обновить LLVM). Потому как в бэкпортах его не было, а про apt.llvm.net я узнал пост-фактум, когда уже собрал, и уже не надо. Кстати, спасибо человеку с Опеннета, который дал мне эту ссылку 3-5 лет назад. > Но зачем? В то время я использовал Debian 7 (актуальным дебианом на тот момент был 9, однако мне не хотелось переустанавливать уже настроенную и обжитую систему). Там был компилятор GCC 4.7, а в бэкпортах были доступны 4.8 и 4.9. Так вот: C++-проги, собранные таким образом, зависели от /usr/lib/gcc-4.9-backport/lib64/libstdc++.so.6. Проблема была решена накладыванием патча gcc4.9-libstdc++-compat.patch из RHEL. P.S. Ещё в то время был забавный баг. Не собирались MesaOpenCL и Beignet (тоже OpenCL). Оказалось - binutils 2.26-2.31 имели баг в связке с LLVM, который позже исправили в новых версиях binutils. Я потом долго ломал голову: почему раньше меса собиралась, а теперь нет. А это я binutils обновил.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от ano (??), 06-Дек-24, 13:51
	используй дженту, люк!
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	184. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 08-Дек-24, 08:35
	> Одного меня начинает серьёзно раздражать эта зависимость всего и вся от LLVM? Сама по себе спека вулкана ни от чего не зависит - это просто спека. На чем там те или иные имплементеры его решили сделать - да это вообще их дело. Если это реверанс в сторону SPIRV то - таки - он _не_ совпадает с LLVM IR напрямую и без уровня трансляции ессно не того. Он просто "по мотивам", но не более того.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

40. "Опубликован графический стандарт Vulkan 1.4"	–7 +/–
Сообщение от Аноним (104), 03-Дек-24, 04:16
>Открытые драйверы для GPU AMD (radv), Apple M1/M2 (honeykrisp), Intel (anv), NVIDIA (nvk) и Qualcomm (tu), развиваемые проектом Mesa, уже прошли все тесты совместимости с Vulkan 1.4 из набора CTS (Khronos Conformance Test Suite) и включены в список сертифицированных драйверов. Что-то здесь не то. Radv это не драйвер, а юзерспейс библиотека. А драйвер называется amdvlk.
Ответить | Правка | Наверх | Cообщить модератору

	41. "Опубликован графический стандарт Vulkan 1.4"	+7 +/–
	Сообщение от Zenitur (ok), 03-Дек-24, 05:28
	amdvlk развивает AMD, а radv развивает Mesa.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Опубликован графический стандарт Vulkan 1.4"	+2 +/–
	Сообщение от Аноним (42), 03-Дек-24, 05:36
	Для radv в составе mesa есть vulkan-radeon. А amdvlk это открытая реализация от amd. Есть еще и закрытая — vulkan-amdgpu-pro. И, насколько я помню, amd рекомендует использовать именно вариант из mesa.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

43. "Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от нитгитлистер (?), 03-Дек-24, 05:41
что-то так не понятно это версия для всех ОС или только для линя?
Ответить | Правка | Наверх | Cообщить модератору

	49. "Опубликован графический стандарт Vulkan 1.4"	+3 +/–
	Сообщение от Аноним (48), 03-Дек-24, 07:05
	Это — стандарт, по которому делаются дрова, которые каждые под свою ОС.
	Ответить | Правка | Наверх | Cообщить модератору

50. "Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от Аноним (50), 03-Дек-24, 07:08
Ух когда то писал тысячу строк кода на голом Vulkan лишь для того чтобы рисовать треугольник. Все эти инициализации устройств, свопчейнов, пейплайнов итд это боль!
Ответить | Правка | Наверх | Cообщить модератору

	58. "Опубликован графический стандарт Vulkan 1.4"	–8 +/–
	Сообщение от пох. (?), 03-Дек-24, 07:45
	потому и не взлетел. слишком сложОн, и в общем то рыночек помешал.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Опубликован графический стандарт Vulkan 1.4"	+4 +/–
	Сообщение от robot228 (?), 03-Дек-24, 07:47
	пруфы что не взлетел
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Опубликован графический стандарт Vulkan 1.4"	–4 +/–
	Сообщение от robot229 (?), 03-Дек-24, 07:52
	Логичнее было бы вам предоставить пруф что наоборот взлетел. А то похоже разделит судьбу дх12.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Опубликован графический стандарт Vulkan 1.4"	+2 +/–
	Сообщение от Аноним (71), 03-Дек-24, 09:38
	> Логичнее было бы вам предоставить пруф что наоборот взлетел. Не логичнее, потому что бремя доказательства лежит на утверждающем.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (125), 03-Дек-24, 21:13
	> Логичнее было бы вам предоставить пруф что наоборот взлетел. Поддерживается практически всеми современными 3D движками, какие еще пруфы надо?! > А то похоже разделит судьбу дх12. DX12 виноват в основном тем что 1) Появился позже вулкана. 2) По смыслу кривой ripoff оного. 3) Win-only, что делает использование этого апи невыгодным для девов. 4) Виндовые дрова умеют вулкан. Ну девы и програмят - на вулкане. Сразу двигуны для игр.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	77. "Опубликован графический стандарт Vulkan 1.4"	+2 +/–
	Сообщение от Анониссимус (?), 03-Дек-24, 10:52
	Так у тебя никто и не забирал твой WebGPU. Vulcan -- это прослойка для тех, кто пишет сами webgpu, opengl, движки для игорь и прочее. Но пользоваться вулканом разработчику конечного приложения -- не имеет смысла. Вы же не пишите на асме, а используете хотя бы сишку?
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	95. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от мяя (?), 03-Дек-24, 14:31
	WebGPU лютый мусор который зауринила-саботрировала apple из-за конфликта с khoronos и помогали ей в этом растер из мозиллы (ныне там не работающий).
	Ответить | Правка | Наверх | Cообщить модератору

59. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
Сообщение от robot228 (?), 03-Дек-24, 07:46
Есть 3д движки для рендеринга архитектуры на этом API?
Ответить | Правка | Наверх | Cообщить модератору

	63. "Опубликован графический стандарт Vulkan 1.4"	–5 +/–
	Сообщение от robot229 (?), 03-Дек-24, 07:52
	Нет. Даже из хрома поддержку экспериментальную выпилили.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от AleksK (ok), 03-Дек-24, 08:19
	Ты совсем того? Gnome работает через вулкан. Большая часть игр на линуксе работает через вулкан напрямую или через трансляцию в него dx.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (100), 03-Дек-24, 15:26
	Не выпили https://www.reddit.com/r/chrome/comments/1gqi64j/vulkan_not_.../ Просто фраг случайно скрыли, потом вернут
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	72. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (71), 03-Дек-24, 09:40
	> Есть 3д движки для рендеринга архитектуры на этом API? Абсолютно любой современный: Unreal, Unity, Godot...
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	87. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (87), 03-Дек-24, 12:06
	"Рендеринг архитектуры" ?
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	105. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (104), 03-Дек-24, 16:27
	Rhino 8 на direct3d.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	124. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (125), 03-Дек-24, 21:10
	> Есть 3д движки для рендеринга архитектуры на этом API? Почти все минимально живые 3D двигла - обзавелись этим. Зачем именно рендерингу именно архитектуры это надо хз, вы там что - в реалтайме с высоким FPS бегать чтоли среди нарисованных домов хотите?
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

65. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
Сообщение от Анонимчик (?), 03-Дек-24, 08:05
> API Vulkan примечателен кардинальным упрощением драйверов, выносом генерации команд GPU на сторону приложения ... Для обеспечения высокой производительности и предсказуемости, Vulkan предоставляет приложениям средства для прямого управления операциями GPU ... А не таится ли здесь корень нынешних и будущих проблем, когда любое самое примитивное глючное приложение сможет "положить" всю систему. Последенее время я такое наблюдаю все чаще и чаще.
Ответить | Правка | Наверх | Cообщить модератору

	78. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анониссимус (?), 03-Дек-24, 10:54
	Странно. Уже сейчас любое приложение генерирует команды, и даже не для gpu, а аш для cpu. И ничего, вроде не вешается вся система...
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анонимчик (?), 03-Дек-24, 11:11
	Я возможно отстал от жизни. В современных GPU уже аппаратно реализованы изоляция памяти процессов, сосбственные контексты выполнения процессов, переключение между процессами и т.п.?
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 11:54
	А ты погляди, как организовано разделение современных GPU в системах виртуализации - возможно, поймёшь.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анонимчик (?), 03-Дек-24, 13:12
	А, если ты такой знаток, то что, тебе так трудно вместо того, чтобы потратить 1 мин на 1 предложение ни о чем, потратить 5 мин на 5 предложений, в которых в общих чертах пояснить, как оно сейчас устроено. Я не пишу 3д софт и/или драйверы. Мне всего лишь интересно понять, почему у меня время от времени Файерфокс спонтанно зависает и вешает ГУИ. Притом, что я еще помню времена, когда у меня X-ы (целиком, а не отдельное приложение) подвисали два - три раза за год.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (108), 03-Дек-24, 17:28
	Именно поэтому на несовременных GPU настоящего vulkanа не будет никогда. Сейчас на них любое приложение видит видеопамять другого. Вот прямо берёт и видит.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	123. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (125), 03-Дек-24, 21:08
	> Именно поэтому на несовременных GPU настоящего vulkanа не будет никогда. Некий прототип есть даже на RadeonHD 6xxx (VLIW которые). Это недостаточно доисторические видяхи? > Сейчас на них любое приложение видит видеопамять другого. Вот прямо берёт и видит. Вулкан нигде не требует иного. Но вон там шейдер от амд в новом кернеле - таки - может и чистить VRAM при переключении контекста. Только это весьма дорогая операция.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анонимчик (?), 04-Дек-24, 08:56
	То есть получается, что рассказы об изолированности содержимого окон разных приложений в Wayland на аппаратном уровне оказалось просто брехнёй? Но даже, если области видео памяти могут изолироваться друг от друга с помощью MMU, все равно остается доступ приложений к командам GPU. Не значит ли это, что ошибки в одном приложении могут угробить всё ГУИ целиком. Неужели мы возвращаемся к Win95, когда одно зависшее окно подвешивало все остальные?
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 04-Дек-24, 20:41
	> То есть получается, что рассказы об изолированности содержимого окон разных приложений > в Wayland на аппаратном уровне оказалось просто брехнёй? У вйэланда как такового есть некий контроль кто и что может - он композитор и сводит картинки, а программа сама по себе - так изначально видит только саму себя. То что там где-то сбоку при очень сильном желании какие-то останки может быть можно выковырять из VRAM которую явно никто не затирал - и то - вот - амд шейдер накорябали для этого - как бы некая разница VS ситуация когда каждая первая прога может через штатные апи хряпнуть весь экран, узурпировать весь ввод и вообще вытворять черт знает что. Вплоть до того что в плеере перестают работать шорткаты "потому что в браудере открыто меню". Офигенная причина профачить "типа глобальные" шорткаты, чего уж. Но перефразируя одного типа, это типа-глобальные, типа-шорткаты, на манер деревянного типа-меча, типа-Дюрандаль. > Но даже, если области видео памяти могут изолироваться друг от друга с > помощью MMU, все равно остается доступ приложений к командам GPU. У современных GPU тоже есть - MMU. С их собственной стороны. Однако занулять VRAM при ее освобождении - довольно ресурсоемкое занятие. Этим и для системной памяти занимаются весьма условно и местами, если вы вдруг не в курсе. По тем же причинам. Так что атаки такого класса порой возможны даже и на обычную системную память, с энными оговорками. > Не значит ли это, что ошибки в одном приложении могут угробить всё > ГУИ целиком. Это врядли. Чего оно такого сделает чтобы ВСЕ программы сдохли? В случае Xorg основная проблема была в том что при любом отклонении от идеала - сыпется гранд централ сервер запросов, и по цепочке - все что за ним весело. И поэтому какой-нибудь GPU Recovery может изумительно рестартануть GPU, реинициализировать его с ноля, и так то все причастные перерисовались бы - но в парадигме Xorg процесс Xorg часто дохнет от такого, и все что за ним осыпается как горох. И вот толку с такого GPU Recovey тогда? А с вон тем - ну они перерисуют себя постепенно, куда они денутся? А никаких гранд-центральных процессов работы с GPU как раз и нет толком. > Неужели мы возвращаемся к Win95, когда одно зависшее окно > подвешивало все остальные? Нет конечно, это Xorg так работал, а вон там - чему вообще виснуть в агрегации N картинок в 1? Тупая как дрова операция, в отличие от навороченых кишков Xorg которые толи колом встать могут - заякорив ВСЕХ кто делал запрсоы туда, толи просто процесс грохается при отклонении от идеала типа GPU Recovery. И вот вроде и отрекаверились - но вся сессия в трубу, и вот радости с такого рекавери?! Иксовые проги - улетают вслед за иксами. А вон там у них причин нет так улетать.
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анонимчик (?), 04-Дек-24, 22:34
	Хм, речь не о том, где больше вероятность глюкануть в следствии наличия багов, или сложности реализации Х-сервера, или композитора вяленого. Х-сервер в своей изначальной концепции до того, как во все поля понеслись аппаратное 3д и всякие DRI, изолировал оконные приложения от непосредственного доступа к оборудованию графической подсистемы. А с вялендом, насколько я понимаю, ситуация иная. Композитор управляет окнами. Но, насколько я понимаю, любое оконное приложение для отрисовки своего окна может задействовать, например, через тот же вулкан напрямую аппаратуру ГПУ. Я не представляю, как устроены современные ГПУ. Не представляю, как несколько задач одновременно с помощью одного ГПУ могут рисовать что-то свое в своих окнах. Пусть даже задачи выполняются псевдо параллельно. Как они между собой делят общий ресурс ГПУ? Ну не реализован же в самом деле в современных ГПУ многозадачность, как в ЦПУ с полным переключением контекста процессов? Мой вопрос то в том, может ли оконное приложение вследствии наличия ошибок в коде ввести весь ГУИ в некорректное состояние? Например, испортить какие-то параметры для других окон, и в них будет рисоваться какой-то мусор? Или повредить вообще информацию об окнах, так что композитор вообще потеряет понятие, где и что находится?
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 05-Дек-24, 05:41
	> изначальной концепции до того, как во все поля понеслись аппаратное 3д > и всякие DRI, изолировал оконные приложения Он так "изолировал" что любая программа могла - делать в системе что угодно, тыря весь контент экрана, нажатия клавиш и проч. А при активном рендере неудачной программы - с арбитражем ресурсов швах. Может успасть весь X-сервер, утянув всю сессию. Может начать так рендерить что вообще ничего отрисовываться не будет. Изоляция программ от фокусов друг друга - так и прет! > от непосредственного доступа к оборудованию графической подсистемы. Ну как бы совсем непосредственно программе в юзермоде никто и не даст железку програмить. > А с вялендом, насколько я понимаю, ситуация иная. Композитор управляет окнами. Но, > насколько я понимаю, любое оконное приложение для отрисовки своего окна может > задействовать, например, через тот же вулкан напрямую аппаратуру ГПУ. Оно получает свой регион-фреймбуфер и может через вон те апи запускать шейдеры для рендера чего-то с ускорением (или просто счета). Но это как таковое ничего нового vs то что было. Кроме того что это куда менее ректально. У Xorg по дефолту - огромные битмапы прямо in band протокола, и надо все эти гигазы парсить. Какая там секурити у парсеров и остальных кишков - вообще отдельный вопрос, и это все как правило под рутом. А вулны 1988 года не являются чем-то невиданным. Как я понимаю - откровенный максимум - шейдером можно при сильном желании попытаться выковырять кусок неиницилизарованной VRAM, где могут быть чьи-то еще остстки. > Я не представляю, как устроены современные ГПУ. Не представляю, как несколько > задач одновременно с помощью одного ГПУ могут рисовать что-то свое в своих окнах. Ну вот так и могут. В GPU сабмитят потоки команд (шейдеры). Результатом является энная картинка. Эта картинка может быть либо в VRAM фреймбуфера и сразу в провод лететь (фулскрин), а может и не в провод, а всякий композитинг делаться, когда композитор объединяет картинки N программ до того как это годно к выводу на экран. > Пусть даже задачи выполняются псевдо параллельно. Как они между собой делят > общий ресурс ГПУ? Ну вот так. GPU тоже шедулится, и шедулинг его ресурсов это тоже отдельный вопрос. Скажем можно интенсивными вычислениями прям на "системном" gpu основательно втормозить графику. Но так изначально - эта вулканская прога вообще не знает почему ее шейдеры дольше выполнялись. Там драйвер и GPU уже сами решают что в какой очередности самбитить, как и кому выгружать результаты и проч. Т.е. ни 1 прога не получает полный контроль над всей железкой и не может например DMA в энный адрес запросить. Как я понимаю - максимум что оно может попытаться это стырить что-то из неинициализированнго куска VRAM которое ей дали, ибо затирать его нолями все же по скорости накладно. > Ну не реализован же в самом деле в современных ГПУ многозадачность, как в ЦПУ Там даже свой MMU есть, у всех современных. Но это чуть иначе: в GPU пуляют джоб с запросом, он его считает, возвращает результат. По каким критериям это все система и ее дрова шедулят, для каких программ - их дело. > с полным переключением контекста процессов? Там очередизация запросов программ к железке. Если есть 5 желающих считать, их запросы будут поочередно пулять туда, возвращать результаты счета и проч. И да, так какой-нибудь opencl крякер паролей может нехило втормозить графоний, заняв все compute engine своим добром - так что вон тем шейдерам тех программ вычислялки достаются на минималках и редко. > Мой вопрос то в том, может ли оконное приложение вследствии наличия > ошибок в коде ввести весь ГУИ в некорректное состояние? Сие достаточно проблематично. Оно сможет попытатсять подгрузить GPU интенсивным счетом, затормозив рендер остальных - но что-то сверх того... как вы представляете себе слом грубо говоря (персонального) фреймбуфера? В него можно рендерить что угодно. Wayland сам по себе - управляющий обвес согласования параметров всего этого. Он это surface называет. Де факто такой персональный фреймбуфер на стероидах. Ну и вон там возможность у вон тех апей - сабмитить еще и шейдеры, и что-то ситать/рисовать ими. > Например, испортить какие-то параметры для других окон, Это вообще на системном проце реализацией вэйланда трекается. > и в них будет рисоваться какой-то мусор? Или повредить вообще информацию об окнах, > так что композитор вообще потеряет понятие, где и что находится? Это все вообще не в GPU. Взаимодействие с вэйландом - через его протокол апи, и штатно там ессно такого не предусмотрено. А что и кто собирается ломать в фреймбуферобразной абстракции зщ. В основном ему самому же от этого плохо и станет прежде всего. И жрат на рендер он CPU будет - от своего лица, а не считая кучу наворотов в X'овом сервере. Скажем если навороченый рендер векторного фонта на скорость ("стена текста") в Xorg нормально сделать с хорошим качеством, эта потуга поставит колом остальных caller'ов. Но вон там это займет проц от лица этой задачи - она будет грузить проц, но остальные смогут рендерить, и пострадает в основном - сама прога, она будет неспешно рефрешиться в своем "фреймбуфере" но это ее проблемы. Остальному до этого какое дело, шедулер проца им же кванты отдает.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анонимчик (?), 05-Дек-24, 09:57
	Ну ладно, коли уж пошла такая пьянка, то может объяснишь, как это все работает? Давно уже хотелось с этим вопросом разобраться. Итак с Х все понятно.Клиент отправляет команды нарисовать несколько примитивов. Даже, если в этот промежуток времени задача переключится, то Х сервер, имея все графические контексты, все это отрисует с перерывами, или без - неважно. Главное, что для клиента все будет отрисовано в нужном порядке. Теперь варианат OGL приложение, имеющее доступ к ГПУ. Приложение строит 3д сцену: определяет координаты вершин в пространстве для 3д объектов, определяет текстуры, шейдеры и пр. Затем запускает отрисовку. Так? Рисуется один кадр. Теперь ситуация, когда сцена до конца не определена, а задача прервана планировщиком. Другая задача начинает строить свою сцену и портит сцену первого приложения. Первое приложение в свою очередь продолжает достраивать свою сцену и ... Или на уровне драйвера OGL каждое построение одной сцены реализуется атомарно? То есть драйвер сохраняет в своих софтверных буферах все параметры сцены и хранит их до момента, когда будет подана команда отрисовки. И только тогда все скопом отправляет в ГПУ. Так что ли получается? Если это так, то хорошо бы еще понять, почему именно файерфокс время от времени вешает весь ГУИ.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 05-Дек-24, 15:13
	> Даже, если в этот промежуток времени задача переключится, то Х сервер, имея все графические контексты, все это отрисует с перерывами, или без - неважно. > Главное, что для клиента все будет отрисовано в нужном порядке. Хм.. разве оно не работает "асинхронно"? Ну типа если у тебя есть вкладка браузера и в ней крутится флеш, то оно обрабатываются по отдельности и не синхронизируются. А потом пользователь делает скрол - и в видео появляются артефакты.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анонимчик (?), 05-Дек-24, 16:59
	> Хм.. разве оно не работает "асинхронно"? > Ну типа если у тебя есть вкладка браузера и в ней крутится флеш, то оно обрабатываются по отдельности и не синхронизируются. > А потом пользователь делает скрол - и в видео появляются артефакты. Ну с Х то все понятно. Ну сдвинется окно в которое выводится выдео. Может один кадр попортися, а может даже нет. Тут в общем-то, что в Х, что не в Х особой разницы не вижу. В окно мапится область памяти, выводи туда что хочешь напрямую. Вот если в процессе рендеринга видеокадров задействуются аппаратные механизмы ГПУ, вот это мне интересно было бы узнать как реализуется.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 08-Дек-24, 10:43
	> общем-то, что в Х, что не в Х особой разницы не > вижу. В окно мапится область памяти, выводи туда что хочешь напрямую. Вообще-то в иксах это как раз "not taken for granted" - так что извольте получить здоровенный такой ререндер окна перекрытого в уголочке вон той фигней при случае. Фигли, делали под топовые компы, с аж 4 мегами оперативы, ну ее и экономили - пипеткой. А теперь - нате вам ререндеры всяких офисов, браузеров и кадов "от и до" на каждый пшик. > Вот если в процессе рендеринга видеокадров задействуются аппаратные механизмы ГПУ, вот > это мне интересно было бы узнать как реализуется. Так и реализуется - в GPU отправляют данные на счет и шейдеры, получают результат куда-то. При том это и off screen буфер может быть, для композитинга какого, или вообще - при фулскрине - сразу в тот фреймбуфер который на экран гнали. В таком случае всякие Xorg и прочие композиторы при правильном раскладе - просто отваливают с дороги совсем. В оконном режиме фокус, разумеется, не катит. И там вместо этого композитор будет буфера агрегировать. Вот только Xorg изначально "фреймбуферами" особо и не оперирует как раз. И хотело оно так изначально - вообще совсем другое делать. А то что рендер все стали делать в либах тулкитов и использовать иксы как кривую и тормозную плевалку битпапа - это и есть ужасная перверсия.
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 08-Дек-24, 10:19
	> Ну ладно, коли уж пошла такая пьянка, то может объяснишь, как это > все работает? Давно уже хотелось с этим вопросом разобраться. > Итак с Х все понятно.Клиент отправляет команды нарисовать несколько примитивов. Даже, если > в этот промежуток времени задача переключится, то Х сервер, имея все > графические контексты, все это отрисует с перерывами, или без - неважно. Вообще-то с иксами как раз большой вопрос что там реально происходит. И особенно что изначально было. На заре времен иксы узурпировали железку с 1 стороны. С другой - OpenGL, очевидно, совсем не Xorg. Как и сабж. DDX как я понимаю тогда и был "драйвером GPU" в том смысле что все ускорение и специфика - жили там. Но это как раз вызывало море проблем с тем как делать OpenGL и проч. В какой-то момент тот пер-ректум достал, слои расщепили. Есть DRM/KMS/GBM в ядре. Есть клиенты к нему в юзермоде. Они транслируют свои апи понятия вон того. В GPU накидывают запросы на счет и проч. Драйвер выполняет, конфигурит железку, возвращает результаты, или что там хотели, etc. В тот момент Xorg перестал быть центром вселенной и арбитром запросов, его демотнули до "одного из клиентов подсистемы". Теперь DDX относительно скромный shim для интерфейса в воооон то. На практике как окзалось "generic KMS" работает даже лучше чем потуги "ускорения" DDX. > Главное, что для клиента все будет отрисовано в нужном порядке. Поддержание логической корректности "своей" абстракции апи - задача реализации апи поверх вон того. Для этого оно ессно ведет некий трек состояния и проч (state tracker) что там у него где. KMS (Kernel modesetting) - управление видеорежимами, DRM (Direct Rendering Manager) - рендеринг и счет, GBM (Generic Buffer Management) - управление буферами вокруг этого, в частности - VRAM. Это комбо может прожевать весь ассортимент графического железа и "считалок". И на самом нижнем уровне ВСЕ ВООБЩЕ - транслируется в это. Запросы в GPU. > Теперь варианат OGL приложение, имеющее доступ к ГПУ. Оно не имеет доступа к GPU. Ему апи вывешено, через него оно даст свои данные, которые, может даже в VRAM вгрузят, и шейдеры - которые надо выполнить на GPU. И куда-то деть результат. > Приложение строит 3д сцену: определяет координаты вершин в пространстве для > 3д объектов, определяет текстуры, шейдеры и пр. Затем запускает отрисовку. Так? Для GPU на нижнем уровне все и вся - запросы, содержащие данные на счет + код шейдеров. И потом результат счета "куда-то". GPU не знает кто и почему хотел вон то считать. State tracking например GL - где-то в недрах реализации GL живет, оно транслириует свои абстракции в такие запросы. Навороченный state и stateful природа GL - одна из причин дико тормозныз Draw Calls в нем. Этот апи не делан под те парадигмы. Оно пыталось быть расширением идей fixed function HW. А железо стало - ну, вот, считалками, в которые можно запрос пульнуть посчитать. "Туда" - может быть и "VRAM", вплоть до фреймбуфера долбилки на экран, тогда результат счета шейдера может и сразу на экран лететь (фулскрин рендер 3D гамезы работает так, оптимальный сценарий). Отсюда следует и что оконный режим с композитингом менее эффективен. > Рисуется один кадр. Теперь ситуация, когда сцена до конца не определена, а > задача прервана планировщиком. Другая задача начинает строить свою сцену Это проблемы с одной стороны реализации API, с другой - драйверов GPU. Для нижнего уровня это лишь запросы на счет, от сих до сих, тех данных, с этими шейдерами. Туда код+данные, назад результат (или вообше его сразу в буфер экрана, если ситуация позволяла). > и портит сцену первого приложения. Что значит "портит сцену" в парадигме, где в GPU - кидался запрос на счет и забирался результат? State tracking апи жил уровнем выше - и, конечно, эта апликуха - не имела доступа в RAM соседа с состоянием его state tracker'а. А от нижнего уровня требудется только простой низкоуровневый арбитраж ресурсов GPU, типа аллокации буферов, шедулинга операций счета и проч. Т.е. как раз то что логично спихать на кернел было. Если на все хотелки всех желающих VRAM не хватило - в случае MESA с GBM есть перегрузка текстур в/из системный RAM, на манер "свопа" по мере реальной надобности. Это, конечно, роняет скорость в разы. Ибо одно дело если данные под боком, другое если это в PCIe или что там надо затолкать. Но так можно и солидный кус системной RAM под текстуры сожрать. Для APU есть оптимизация когда GPU сам в системный RAM ходит, пропуская копирование CPU <-> GPU. > Первое приложение в свою очередь продолжает достраивать свою сцену и ... ...и вся эта абстракция жила в основном в state tracker'е GL. А GPU оперировал несколько иными терминами. Вида дали данные, дали шейдер, хотят результат. Ну там, вот, кадр гамезе посчитать, из тех текстур + шейдеров в VRAM, или где там. А после этого - кадр в буфер гамесы, и можно посчитать что-то другое, кому-то еще. > Или на уровне драйвера OGL каждое построение одной сцены реализуется атомарно? Это уже дело реализации API, как оно внутрях транслирует запросы прог в "своих" абстракциях - в те запросы к GPU, чтобы корректность абстракции при этом держать. Как я понимаю, да, может и весь фрейм считаться, но то что это единственный возможный вариант - ниоткуда не следует. И как я понимаю - для GL в целом отлилось в навороченный (и медленный / оверхедистый) state tracker, а реализация драйвера (по сути либ делающих ту трансляцию парадигм) канительна. На закате до них дошло в GL 4.6 что современное железо хотело бы иного, и они сделали расширение "direct state access". Но по сравнению с Vulkan это даже не полумеры. Вулкан намного ближе к тому что такое те GPU что вещи типа типа DRM/KMS/GBM на самом деле делали. > То есть драйвер сохраняет в своих софтверных буферах все параметры сцены и > хранит их до момента, когда будет подана команда отрисовки. Для GL как я понимаю оно держит нехилый state своего апи в именно реализации GL, для каддой проги. По мере надобности ессно в GPU улетают запросы на вгруз нужных данных (если оно еще не в VRAM) и счет воооон той сцены. И дальше оно на экран, или куда там еще - композитору например, для сведения N картинок. > И только тогда все скопом отправляет в ГПУ. Так что ли получается? Как я понимаю - для рендера кадра в полном экране через GL может быть примерно так. Если прог несколько - их запросы разруливают очередизуют, композитор сводит буфера с результатами в то что пригодно к выводу на экран. Ничему не противоречит висение текстур в VRAM и для сразу N штук, если VRAM хватало. А если не хватает - подкачака по мере надобности посчитать. GBM чем-то вокруг этого и занимается. Если GPU считает для первой проги - значит, вторая подождет выполнения своего запроса. Конечно с потерей FPS, ибо претендентов на ресурс стало более 1, и если считали запрос первой - значит не считали запрос второй, позже посичтают. Ну а композитор - сводит все воедино. Wayland - узаконивает такую схему и сразу оттуда и танцует. И все сильно проще и шустрее. Там сразу у каждой проги свой "фреймбуфер". И можно с ним оперировать. В Xorg это сбоку на скотч примотано. Изначально Xorg на это не были расчитаны. И поэтому оно очень хреново и криво, через кучу прослоек хотевших совсем иного. > Если это так, то хорошо бы еще понять, почему именно файерфокс время > от времени вешает весь ГУИ. Я так понимаю что он в основном такой - потому что делает весьма дофига в том же треде в котором морда крутится, и если та активность ловит клин, то и рендер морды заодно. А в Xorg c их манерой хотеть ререндер ВСЕГО ОКНА по поводу и без это может отлиться и в "лысое" или "порушеное" окно, пока оно не толкнет ВЕСЬ рендер, ибо кэшированой битмапы не было - и пока вся здоровенная штука не перерендерит навороченное окно от и до - упс, please wait. Даже если там ничего не менялось - этого уголка окна нигде не было чтобы его показать. На системах с 4 мега RAM это имело смысл. Сейчас это вызывает дикий клин навороченных прог на ровном месте, вызывая ререндер навороченых окон на каждый пшик. А для вяленда и ко оно так то в конечном итоге i++ буфер кадра. Там этот уголок окна - был. И не обязательно дергать ререндер этой штуки заново. Но кроме этого есть более 9000 иных причин поймать клин в энном треде. От paging до блокирубщих сисколов или просто натужного делания чего-то побочного в стиле "и пусть весь мир подождет".
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	147. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (147), 04-Дек-24, 18:56
	Я знаю об этой поделке. Правда я не осилил её собрать. Её бы поверх последней месы перебазировать, а не отставать на тысячи коммитов. А собирать для старой месы - зачем? И она ведь - ненастоящий вулкан. С кучей "если", которые сломают любые вулкан приложения, кроме тех, которые под неё адаптированы. То есть это получится "кооперативный вулкан", как кооперативная многозадачность. Но кто из разрабов будет писать под такую? Кто пишет под вулкан - это же просто намеренное решение дропнуть старьё. Они его не затем приняли, чтобы потом впихивать костыли  Вон, стороннюю реализацию Unreal Engine 1 написали чисто под вулкан, которого в годы оригинала и в проекте не было. Зачем, ведь никто не сможет убедительно обосновать, что там прям 100% железобетонно вулкан нужен. Просто разраб - хозяин-барин, на чём хочет - на том и пишет, движется вперёд, зачем учить старьё, если можно учить новьё, а воскрешение старых игрушек - это просто образовательный проект.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	162. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 05-Дек-24, 05:53
	> Я знаю об этой поделке. Правда я не осилил её собрать. Её > бы поверх последней месы перебазировать, а не отставать на тысячи коммитов. > А собирать для старой месы - зачем? Не очень понял - кто и о какой поделке что знает. Это очень неконкретно. Radv и прочие nvk и tu давно часть актуальных версий MESA и пересобираются как ее часть. Значит это наверное о чем-то еще. Только хрен его знает - чем. > И она ведь - ненастоящий вулкан. Странно, Khronos Group считает иначе - https://www.opennet.me/opennews/art.shtml?num=62197 и это для весьма немолодых GCN. Остальные были conformant еще раньше. > С кучей "если", Драйвер или проходит conformance test suite вулкана, или нет. Да, у них это есть. > которые сломают любые вулкан приложения, кроме тех, которые под неё адаптированы. Кто там что сломает, если на RADV народ спокойно играет в AAA игры? Не понимаю. > То есть это получится "кооперативный вулкан", Вулкан бывает - только тот который Khronos Goroup апрувнула. Все остальное - левак. > будет писать под такую? Кто пишет под вулкан - это же > просто намеренное решение дропнуть старьё. Пишут - под спеки вулкана. Какая там реализация, и MESA это или кто там еще - дева вообще волновать не должно. Для этого спеки и conformance test suite и существуют. > можно учить новьё, а воскрешение старых игрушек - это просто образовательный проект. Хорощее описание почему нове движки врядли будут с GL возиться - и сразу будут вулкан юзать...
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (180), 06-Дек-24, 23:04
	> Не очень понял - кто и о какой поделке что знает. Это очень неконкретно. Вот конкретно об этой (вас цитирую): > Некий прототип есть даже на RadeonHD 6xxx (VLIW которые). Это недостаточно доисторические видяхи? ------ >Драйвер или проходит conformance test suite вулкана, или нет. Да, у них это есть. У кого, у Terakanа?! > Пишут - под спеки вулкана. Какая там реализация, и MESA это или кто там еще - дева вообще волновать не должно. Для этого спеки и conformance test suite и существуют. Вот и будут писать под спеки вулкана. А на карты без MMU - срать.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (125), 03-Дек-24, 21:07
	> Я возможно отстал от жизни. В современных GPU уже аппаратно реализованы изоляция > памяти процессов, сосбственные контексты выполнения процессов, переключение между > процессами и т.п.? Там есть свой GPU-side paging и GPU-side MMU как правило. Однако жто не вся часьт балета. ...или к вопросу о блобе (с исходниками на экзотичном асме) от амд который в libre kernel выпилили. Ака опциональный VRAM Cleaner - который запускается на GPU для очистки VRAM при переключении контекста ядром. В силу ресурсоемкости этой операции сие, ессно, весьма опционально, для хардкорщиков по части секурити.
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

68. "Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от Аноним (68), 03-Дек-24, 08:42
Ждём поддержки в видеокартах Nvidia RTX 50 серии. Может с помощью этой версии Vulkan зелёные наконец смогут обеспечить честные 8к в играх с норм фпс)))
Ответить | Правка | Наверх | Cообщить модератору

	116. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
	Сообщение от Neon (??), 03-Дек-24, 18:50
	А так ли нужны, вообще то, честные 8к в играх  ? Не всякий пользователь разглядит все эти пиксели)))
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анониссимус (?), 04-Дек-24, 00:24
	> А так ли нужны, вообще то, честные 8к в играх  ? > Не всякий пользователь разглядит все эти пиксели))) Может в каких-нибудь VR-очках нужно. На мониторе 4к уже избыточно, по-моему.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (138), 04-Дек-24, 07:20
	Нет, не достаточно. Но есть вроде есть сторонники теории, кому и даже 24FPS достаточно.
	Ответить | Правка | Наверх | Cообщить модератору

88. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
Сообщение от Аноним (88), 03-Дек-24, 12:15
Да блин. Тока тока 1.3 реализовали для более или менее всех видушек, что позволит запускать в вайне проги под D3D11, который поддерживался на них в винде с самого начала, а они теперь 1.4 придумали и все сразу побегут его требовать, так что опять привет для запуска древней игры под D3D10/11 будут требовать какую-нибудь 10050090RGTXXXXXXXXXXX.
Ответить | Правка | Наверх | Cообщить модератору

	178. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (178), 05-Дек-24, 22:40
	Как бы в README к dxvk и vkd3d написано прямым текстом, что они жертвуют обратной совместимостью со старым железом ради более высокой производительности. Тем не менее, никто не мешает взять старые версии DXVK или VKD3D, запихнуть их в префикс, и играть в старые игры на картошке. Половина раздела лялих-игр завёрнутых в вайн на рутрекере примерно так и живёт.
	Ответить | Правка | Наверх | Cообщить модератору

91. "Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от Аноним (91), 03-Дек-24, 13:16
> выносом генерации команд GPU на сторону приложения > переносимое промежуточное представление SPIR-V то есть каждое приложение которому шэйдеры надо генерировать в рантайме будет с собой теперь ещё и компилятор таскать?
Ответить | Правка | Наверх | Cообщить модератору

	93. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 14:00
	> то есть каждое приложение которому шэйдеры надо генерировать в рантайме будет с собой теперь ещё и компилятор таскать? Ну так сгенерируй из заранее, в чем проблема? Зато их можно писать на разных языках и использовать везде где нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (91), 03-Дек-24, 15:49
	> в чем проблема? в том что "шэйдеры надо генерировать в рантайме", или генерировать такую кучу всевозможных комбинаций, что проще тогда таскать компилятор с собой.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Анониссимус (?), 04-Дек-24, 00:28
	>> выносом генерации команд GPU на сторону приложения >> переносимое промежуточное представление SPIR-V > то есть каждое приложение которому шэйдеры надо генерировать в рантайме будет с > собой теперь ещё и компилятор таскать? Этот компилятор будет весить меньше, чем одна текстурка современного тайтла.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

112. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
Сообщение от Аноним (-), 03-Дек-24, 18:24
>Продукты с поддержкой Vulkan 1.4 готовятся выпустить компании AMD, Arm, Imagination, Intel, NVIDIA, Qualcomm и Samsung. Открытые драйверы для GPU AMD (radv), Apple M1/M2 (honeykrisp), Intel (anv), NVIDIA (nvk) и Qualcomm (tu), развиваемые проектом Mesa, уже прошли все тесты совместимости с Vulkan 1.4 из набора CTS (Khronos Conformance Test Suite) и включены в список сертифицированных драйверов. Из всех реализаций стандарта Vulkan, для Свободного сообщества важны GPU AMD (radv) и Mesa. Все остальные это проприетарные реализации. Не забвайте этого, и не ставьте в один ряд разработки сообщества с разработками копирастов.
Ответить | Правка | Наверх | Cообщить модератору

	114. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 18:33
	> Из всех реализаций стандарта Vulkan, для Свободного сообщества важны GPU AMD (radv) и Mesa. И поэтому работают хуже других? > Все остальные это проприетарные реализации. Тем не менее это реализации. Для всех людей, а не только для гну-комми.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 21:02
	> И поэтому работают хуже других? Вообще-то RADV из Mesa - дал мастеркласс AmdVlk который сначала был проприетарный... а к моменту когда его открыли - RADV его уже делал во всех номинациях, ну он уже никому особо и не нужен.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анононировавший (?), 03-Дек-24, 21:23
	И понятнее все равно не стало ) Есть amdgpu - это ядрёный код который работает с железом. Есть MESA - в состав него входят важные API (vulkan собственно), которые разрабатываются и вливаются драйвера "от вендоров" (vulkan_radeon.so и вот это вот все). На мой взгляд - где то пошли не туда. $ vulkaninfo --summary WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Received return code -3 from call to vkCreateInstance in ICD /usr/lib/x86_64-linux-gnu/libvulkan_dzn.so. Skipping this driver. WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Received return code -3 from call to vkCreateInstance in ICD /usr/lib/x86_64-linux-gnu/libvulkan_virtio.so. Skipping this driver libvulkan_dzn - это пля dozen микрософтовский для WSL.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анононировавший (?), 03-Дек-24, 21:31
	Я хочу чтобы у ВИН людей в WSL было все хорошо, но я не хочу чтобы эта поганая контора лезла в мои драйвера )
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Zenitur (ok), 04-Дек-24, 18:14
	> И понятнее все равно не стало ) > Есть amdgpu - это ядрёный код который работает с железом. Мне кажется, что ты перептал amdgpu с amdvlk. Первый действительно в ядре. Второй - в юзерспейсе, является взаимозаменяемым с RADV.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	152. "Опубликован графический стандарт Vulkan 1.4"	+1 +/–
	Сообщение от Аноним (-), 04-Дек-24, 21:12
	> И понятнее все равно не стало ) > Есть amdgpu - это ядрёный код который работает с железом. > Есть MESA - в состав него входят важные API (vulkan собственно), которые > разрабатываются и вливаются драйвера "от вендоров" (vulkan_radeon.so и вот это вот все). Технологически это как-то так: - Самый нижний уровень это модуль DRM/KMS и проч для энного GPU. Собссно низкоуровневое управление железкой и ее памятью, в кернеле. Для новых AMD это модуль amdgpu, для старых, типа HD5xxx/6xxx и т.п. - radeon. - LibDRM вывешивает те интерфейсы ядра в более удобном программам виде, ибо фигачить сисколами и прочими ioctl от и до - апликушникам не очень сподручно. - Поверх этого MESA - или кто там еще - реализует те апи которые они хотели. Вулкан, GL, whatever. Технически все вон те - клиенты подсистемы DRM/KMS в ядре. В этом смысле Radv - это реализация API Vulkan для AMD GPU (подразумевает модуль amdgpu). AmdVlk - аналогично, в общем то. Просто другой набор юзермодовых либ, которые тоже реализуют это апи - и тоже интерфейсятся в DRM/KMS (тоже подразумевая amdgpu). В силу того что Radv шустрее и открытый - amdvlk мало кто вообще пользуется на практике, амд протормозили. А nvk - примерно то же самое но - для нвидвий - поверх модуля nouveau. Собссно их основная грабля - не качество реализации а неумение в реклок. С переходом на использование GSP их попустит - ибо при этом видяха сама себя будет реклокать фирмварой GSP под нагрузку. > На мой взгляд - где то пошли не туда. Т.е. вы даже не понимаете как это работает - но мнение имеете? А это мнение в таком виде точно имеет какую-то ценность? > $ vulkaninfo --summary > WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Received return code -3 from > call to vkCreateInstance in ICD /usr/lib/x86_64-linux-gnu/libvulkan_dzn.so. Skipping > this driver. > WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Received return code -3 from > call to vkCreateInstance in ICD /usr/lib/x86_64-linux-gnu/libvulkan_virtio.so. Skipping > this driver > libvulkan_dzn - это пля dozen микрософтовский для WSL. Да и хрен с ним. Хоть я и не понимаю зачем оно вон там у вас. Это в винде? Или у вас майнтайнеры странные люди? А virtio - это вообще виртуальный драйвер. Актуален в основном в VM. И как по мне все пошло в куда более правильную сторону чем было изначально. Изначально - был процесс Xorg, лазивший из юзермода в видяху сам. Все остальное в этой схеме делалось через ж@пу и по мере начала хотения иных апи типа GL всерьез это стало проблемой. Как впрочем и желание нормально играть видео, например. Вы же понимаете что точные тайминги из юзермода - это вообще весьма такое себе? А беэ этого совсем забыть про тиринг и статтеринг не получится. Что усугублено кучей тяжелых операций рендера в кишках Xorg которые могут все колом ставить, вплоть до того что misbehaving программа может настолько заякорить ВСЕ графические операции что юзер просто не дождется рендера таскменеджера исползовавшего Xorg.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	119. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Анононировавший (?), 03-Дек-24, 20:59
	> Из всех реализаций стандарта Vulkan, для Свободного сообщества важны GPU AMD (radv) и Mesa А разве MESA не равно RADV ? До сих пор разбираюсь ) С невидией проще было, apt install nvidia-drivers-5* и страдай по возможности )
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	120. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (-), 03-Дек-24, 21:00
	> Из всех реализаций стандарта Vulkan, для Свободного сообщества важны GPU AMD (radv) > и Mesa. А ничего что radv - часть MESA? :) > Все остальные это проприетарные реализации. ...как и большая часть перечисленных :). Да, anv или tu - это тоже куски MESA. И nvk кстати тоже, насколько я помню, поверх нувы пашет. И?!
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	131. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (131), 03-Дек-24, 22:33
	KDE тру, арч не тру (извините). Я могу вкорячить в пакет троянчик (чисто для тебя, ни у кого не высветится). и запузырить в AUR
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (131), 03-Дек-24, 22:41
	Да, такое можно тоже сделать с дебиан или убунту репами... НО сильно сложнее )
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Аноним (153), 04-Дек-24, 21:18
	> KDE тру, арч не тру (извините). Да какая мне разница кому и что вы там трете? :) > Я могу вкорячить в пакет троянчик (чисто для тебя, ни у кого > не высветится). и запузырить в AUR Ну как бы если арчевское сообщество такое позволит - это их факап. При чем тут сабж, я и околотопичные дела? К vulkan самому по себе это отношения не имеет.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

136. "Опубликован графический стандарт Vulkan 1.4"	+/–
Сообщение от Аноним (136), 04-Дек-24, 00:30
Когда я попробовал мод на майнкрафт который меняет api на vulkan я ощутил такую плавность игры,правда он только на относительно новые версии но кто играет советую попробовать.
Ответить | Правка | Наверх | Cообщить модератору

137. "Опубликован графический стандарт Vulkan 1.4"	–1 +/–
Сообщение от Аноним (137), 04-Дек-24, 05:59
чё-то какую игру не вспомню с этим вулканом, так какие-то проблемы: то borderless fullscreen не работает (уходит в эксклюзивный режим из-за чего альт-таб адски неудобно использовать), то HDR работает только в эксклюзивном режиме (AC Odyssey). Пока они это не исправят - directx будет незаменим.
Ответить | Правка | Наверх | Cообщить модератору

	157. "Опубликован графический стандарт Vulkan 1.4"	+/–
	Сообщение от Beta Version (ok), 05-Дек-24, 03:09
	Кто "они"? Это проблемы конкретных игр и их разработчиков, а не API.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема