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

"Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
Сообщение от opennews (??), 01-Фев-24, 22:46
Опубликован релиз свободной реализации API OpenGL и Vulkan - Mesa 24.0.0. Первый выпуск ветки Mesa 24.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 24.0.1... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60537
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+3 +/–
Сообщение от Аноним (1), 01-Фев-24, 22:46
Есть какие-нибудь книги статьи которые объясняют как графический стек работает в линуксе? Что-то кажется неохваченная тема вообще.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–15 +/–
	Сообщение от Аноним (3), 01-Фев-24, 23:01
	https://www.google.com/search?q=graphics+stack+linux
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+42 +/–
	Сообщение от Аноним (4), 02-Фев-24, 00:06
	С точки зрения программиста надо просто смотреть код. С точки зрения пользователя просто запомнить что открытый графический драйвер состоит из трех компонентов: DRM (Direct Render Manager) в ядре, mesa (новость про нее) и libdrm в userspace, через последний mesa "общается" с DRM. DRM это то что непосредственно взаимодействует в видеокартой, а mesa содержит реализации графических API с помощью которых данные подготавливаются и отправляются на видеокарту (например там компилируются шейдеры под конкретный графический чип используя ACO либо LLVM в качестве компилятора).   Пользователю эта инфа нужна чтоб понимать что нужно обновлять для того или иного эффекта, например если нужно новые фичи разгона или решение проблем с переключаемыми режимами (частота и разрешение экрана) то это к DRM, а если нужны решить проблемы с артефактами в игрушке или низким fps то это mesa.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	5. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+4 +/–
	Сообщение от Аноним (5), 02-Фев-24, 01:04
	Продолжай, очень интересно! А где тут находятся x11 в libdrm (userspace)?
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
	Сообщение от Аноним (4), 02-Фев-24, 01:31
	Догадываюсь что раз X11 непосредственно использует libdrm то только для управления подключенными дисплеями. Само же окружение рабочего стола рисуется на OpenGL, через mesa, ответственный за это компонент mesa называется Glamor.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+10 +/–
	Сообщение от Zenitur (ok), 02-Фев-24, 02:20
	Сначала было 2D-ускорение XAA. Оно использовалось X11 для того, чтобы ускорять такие действия, как перетаскивание окна из стороны в сторону. Для ресайза окна. Обычно эти действия вычислялись программно на CPU, но если доступен XAA, то всё становилось быстрее. По сути, XAA это налог DirectDraw, а Xv это аналог DirectShow. В конце 00-х, XAA заменили на EXA. Все вендоры видеокарт успешно провели миграцию со старого на новый API, и старый API даже удалили из X11. Потом Intel сделала UXA и SNA. Но другие вендоры не стали реализовывать эти API у себя. Потом появился Glamor - аппаратное 2D, работающее поверх аппаратного 3D. Дело в том, что вендорыы начали убирать из графических чипов - вычислительные модули для 2D-графики. Чтоб не занимали место, так как аппаратное 2D уже никому не нужно. Использует ли X11 библиотеку libdrm? Нет. Для управления дисплеями используется xrandr. Окружение рабочего стола не рисуется через OpenGL - хотя в теории можно включить композитинг, но всё работает и без него.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Аноним (16), 02-Фев-24, 08:40
	> Использует ли X11 библиотеку libdrm? Нет. Как не использует? Очень даже использует, как же иначе получать информацию о дисплеях, разрешениях и прочем.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
	Сообщение от Zenitur (ok), 02-Фев-24, 13:47
	Насколько я знаю, драйвер NVIDIA не использует libdrm вообще. Может, лицензия не позволяет к нему обращаться. Не знаю. Поэтому я и предположил, что определение разрешений экрана происходит как-то иначе, а libdrm используется только для 3d-ускорения, и ни для чего больше. Ниже мне написали, что" strings amdgpu_drv.so" показывает, что libdrm таки используется ими. А раз DDX-драйвер обращается к этой библиотеке - значит, libdrm используется не только для 3D. Я ошибался, когда предположил, что libdrm - только для 3D, а не для разрешений экрана.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 15:56
	> Насколько я знаю, драйвер NVIDIA не использует libdrm вообще. $  ldd /usr/lib/xorg/modules/drivers/nvidia_drv.so     linux-vdso.so.1 (0x00007ffc591f0000)     libm.so.6 => /usr/lib/libm.so.6 (0x000073d7bcd15000)     libc.so.6 => /usr/lib/libc.so.6 (0x000073d7bcb37000)     libdl.so.2 => /usr/lib/libdl.so.2 (0x000073d7bd940000)     /usr/lib64/ld-linux-x86-64.so.2 (0x000073d7bd97e000) > Поэтому я и предположил, что определение разрешений экрана происходит как-то иначе https://download.nvidia.com/XFree86/Linux-x86_64/390.157/REA...
	Ответить | Правка | Наверх | Cообщить модератору

	58. Скрыто модератором	+1 +/–
	Сообщение от Аноним (56), 02-Фев-24, 16:19
	Хотя: $  strings /usr/lib/xorg/modules/drivers/nvidia_drv.so |grep libdrm Couldn't open libdrm.so.2 libdrm.so.2 was loaded, but required symbol %s was not found $  strings /usr/lib/xorg/modules/drivers/nvidia_drv.so |grep '^drm' drmClose drmFreeVersion drmGetCap drmGetVersion drmIoctl drmOpen drmPrimeHandleToFD Видимо, загрузка библиотеки динамическая.
	Ответить | Правка | Наверх | Cообщить модератору

	69. Скрыто модератором	+/–
	Сообщение от Zenitur (ok), 02-Фев-24, 20:36
	А вот это уже интересно. Я совсем забыл, что, начиная с драйвера 361 и 364, появилась поддержка glvnd. GLvnd это программа-диспетчер, которая позволяет работать с дваумя библиотеками OpenGL одновременно. Ради этого NVIDIA даже удалила все расхождения со стандартом OpenGL (она целенаправленно нарушала стандарт, так как это делало разработку значительно проще). Может, начиная с драйвера 364, NVIDIA стала реально общаться с системной библиотекой libdrm? Так как KMS в её драйвере тоже начиная с 364 версии... А реализовать KMS как-то иначе, кроме как общаясь с libdrm, невозможно...
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
	Сообщение от Аноним (24), 02-Фев-24, 10:53
	> Glamor - аппаратное 2D, работающее поверх аппаратного 3D. Расскажи как именно 2D рисуется через 3D? Gloamor регистры на видеокарте вызывает? Как текстуру того или иного окна отсылает в видеопамять?   Для этого есть графические api типа OpenGL, GL ES и Vulkan, а иначе тебе придется делать отдельный DDX драйвер под каждый графический чип и дублировать работу mesa специально для 2D.   В поиске введи `Glamor OpenGL`, найдешь соответсвующие новости, или вот патчь https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests... > Использует ли X11 библиотеку libdrm? Нет. Использует через DDX драйверы такие как `xserver-xorg-video-amdgpu`, `xserver-xorg-video-intel`, ...   Можешь посмотреть выполнив `ldd /usr/lib/xorg/modules/drivers/amdgpu_drv.so` или `ldd /usr/lib/xorg/modules/drivers/intel_drv.so`, там будут зависимости на `libdrm.so`
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	25. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от Аноним (24), 02-Фев-24, 11:03
	И xrandr это просто CLI утилита над иксовым DDX драйвером. P.S. Специально для грамар наци: `s%/патчь/патч/g`
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от Moomintroll (ok), 02-Фев-24, 11:41
	> xrandr это просто CLI утилита Точно? https://www.x.org/archive/X11R7.7/doc/man/man3/Xrandr.3.xhtml
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (24), 02-Фев-24, 12:08
	Изначальное утверждение на которое был написан ответ: > Для управления дисплеями используется xrandr. А по твоей же ссылке на доку написано > Xrandr is a simple library designed to interface the X Resize and Rotate Extension. Это фронтэенд над функциями X11. Есть CLI утилита xrandr, а есть библиотека libXrandr.so чтоб можно было слинковаться и вызвать нужные функции из своей программы. Что это меняет? libXrandr и xrandr являются фрондером над RandR, а про него написано следующее.   > RandR as implemented and integrated into the X server Я добавлю что он как раз и использует DDX драйвер, и например, если ты поменяешь разрешение то цепочка вызовов будет такой: [libxrandr или xrandr] -> [x11:RandR] -> [x11:DDX (intel, amdgpu, nvidia,...)] -> [libDRM] -> [Kernel-DRM (intel, amdgpu, nvidia,...)]
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 12:21
	> [x11:DDX (intel, amdgpu, nvidia,...)] x11:DDX (modesetting)
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от vitalif (ok), 02-Фев-24, 16:50
	>Расскажи как именно 2D рисуется через 3D? Именно так, через opengl, через шейдеры
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	83. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от kravich (ok), 04-Фев-24, 09:35
	Да Зенитарка, ты временами странный, но в Linux-археологии тебе равных нет, спасибо
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	92. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Zenitur (ok), 05-Фев-24, 13:19
	> Да Зенитарка, ты временами странный, но в Linux-археологии тебе равных нет, спасибо Пожалуйста. Согласен, у меня такое есть. Бывает - напишу комментарий, а через несколько часов (когда в голове складывается более полная картина), я возвращаюсь и редактирую. Тогда людям нравится. По этой причине, у меня на ЛОРе под некоторыми комментариями "отредактировано 10 раз". А лучше не отправлять комментарий сразу, а дать ему настояться. Прочитать несколько раз перед отправкой... Бывает, что я нахожу свой же комментарий, отправленный несколько лет назад - и понимаю, что я имел в виду не то, что в нём написано... Жаль, что их уже не отредактируешь. По поводу Linux-археологии - что-то застал, а что-то узнавал уже пост-фактум. Причём в 2005 я думал "ну вот, это уже новодельные линуксы - с UTF-8 и GTK2 с Clearlooks - а вот в 1999-2001 было тру, а сейчас уже поздно вкатываться в это..." P.S. А ещё я жалею, что не видел Mac OS X Tiger в годы актуальности. Следующий релиз Snow Leopard вроде как был последним нормалаьным. А потом началась плоскота.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Аноним (24), 02-Фев-24, 11:42
	> Само же окружение рабочего стола рисуется на OpenGL, через mesa, ответственный за это компонент mesa называется Glamor. Есть одно ошибочное утверждение, разумеется Glamor это часть xorg, входящая в DDX драйвер. Glamor рисует все через OpenGL или OpenGL ES (у одноплатников и телефонов обычно только такой драйвер), ну и разумеется glamor'у пофиг будет ли OpenGL реализован открытым драйвером mesa или проприетарным драйвером nvidia/qualcomm/broadcom/etc, главное чтоб нужные функции были.   А если драйверов нет и 3D не работает, то mesa будет использовать программную реализацию OpenGL которая называется llvmpipe, на выходе вы получите очень тормазнутный UI как и 3D. Такое можете увидеть если у вас нет драйвера, или например видеокарта выпущена значительно позже дистрибутива, или в виртуалке если она не прокинула свой OGL драйвер-адаптер переадресующий вызовы в вашей видокарте на хост машине.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	14. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от Аноним (14), 02-Фев-24, 08:18
	> С точки зрения программиста надо просто смотреть код. Вы какой-то плохой погромист - без понимания ундерлаинг технологий код не помощник.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	27. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 02-Фев-24, 11:40
	Если так нравятся английские словесы, то black box reverse engineering - это когда изучают код клиента чёрного ящика, что бы понять, что там за ундерлаинг технологии внутри.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (35), 02-Фев-24, 13:14
	> С точки зрения пользователя просто запомнить что Что обезьяньи упражнения хороши для обезьян.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	8. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+13 +/–
	Сообщение от Zenitur (ok), 02-Фев-24, 01:38
	Знаю только самое начало. Драйвер делится на две части: 1. Cам драйвер. 2. Файл библиотеки OpenGL. Сам драйвер делится на два файла: 1. Ядерную часть (в kernelspace) /lib/modules/2.6.32/kernel/drivers/video/nvidia.ko 2. Юзерспейсную часть. /usr/lib/xorg/modules/drivers/nvidia_drv.so Интересный факт. Во времена видеокарт без 3D-ускорения, была только юзерспейсная часть. Это называется DDX-драйвер. Файл библиотеки OpenGL тоже делится на две части: 1. server glx. /usr/lib/xorg/modules/extensions/libglx.so 2. client glx. /usr/lib/libGL.so.1 Если 3D-ускорение не работает - значит, какого-то из этих файлов нет. Проверяй вывод команды glxinfo, чтобы "Server GLX string" и "Client GLX string" были от "NVIDIA Corporation". Если нет - чини. Также проверяй файл "/var/log/Xorg.0.log". Интересный факт. Графический сервер X11 (X-server) общается с библиотекой OpenGL не напрямую. Между ними есть посредник в виде библиотеки GLX. Цепочка выглядит так: X11-GLX-OpenGL. Теперь история. OpenGL был создан компанией Silicon Graphics, которая создавала мощные рендер-фермы для компьютерной графики в кино. Рендер-ферма делилась на два компонента: сервер и клиент. Сервер представлял из себя мощный компьютер без монитора. Клиент представлял из себя обычный комп, с монитором, клавиатурой и мышкой. Назывался "рабочая станция". Ещё нужно было покупать кучу софта. Софт мог быть по стоимости, как сам комп. Собственно, авторам софта и нужно было как-то общаться с видеокарточкой. На каком-то языке. Так и появился API OpenGL. А ещё есть такая штука, как графический сервер X11. Он появился в 1987 году. Для справки, Linux появился в 1992-м. Во времена Pentium Pro (ноябрь 1995 года) стало понятно, что архитектура x86 теперь способна потягаться с MIPS и SPARC. В том числе и для 3D-графики. В то время набирала популярность операционная система Linux. Там использовался графический сервер XFree86. Логично, что 86, это архитектура x86, а Free, значит свободный. Значит, на серьёзных UNIX-машинах использовался какой-то другой сервер. В конце 1996 года вышла видеокарта 3dfx Voodoo - первый 3D-ускоритель для домашних компьютеров, получивший популярность. В начале 1997 года вышла видеокарточка nVidia Riva 128. Под неё были драйверы для Windows 95, Windows NT, Linux, FreeBSD и Solaris. Интересный факт: были драйверы даже для Windows 3.1 - правда, без поддержки 3D. Что интересно, первые драйверы NVIDIA были с открытым исходным кодом (что нетипично для этой компании). Для того, чтобы запустить драйверы, нужно было серьёзно пропатчить "иксы". Поиграть можно было в игру Quake II - первую коммерческую игру, которая была выпущена для Linux. Компания Tungsten Graphics придумала, как можно запустить 3D-ускорение под XFree86, не имея необходимости накладывать патчи. Именно они предложили, что отныне драйвер разделён на ядерный и юзерспейсный (раньше был только юзерспейсный). Для написания ядерной части драйвера, в ядре находится модуль DRI, с которым предстоит взаимодействовать вендору видеокарты в процессе написания своего драйвера. Однако компания NVIDIA раскритиковала DRI и сделала своё. Модуль nvidia.ko по сути даёт вожделенный Direct Rendering, но без использования DRI в ядре и libdrm в юзерспейсе. Считалось, что получить вожделенный DRI в XFree86 нельзя, что надо создать новый графический сервер. Однако для иксов появилось расширение DRI (одноимённое с модулем ядра), и DRI стало можно юзать в XFree86. Вот как выглядела одна из секций файла /etc/X11/XF86Config: Section "Module"     Load    "glx"     Load    "dri" EndSection А ещё она могла выглядеть вот так: Section "Module"     Load    "GLcore"     Load    "bitmap"     Load    "dbe"     Load    "ddc"     Load    "dri"     Load    "extmod"     Load    "freetype"     Load    "glx"     Load    "int10"     Load    "record"     Load    "speedo"     Load    "type1"     Load    "vbe" EndSection Как хорошо, что сейчас не нужно иметь большой развесистый конфиг. В декабре 2000 года вышел дистрибутив Red Hat 7.2. Компания NVIDIA начала формировать rpm-пакеты для него и для SUSE. А также run-инсталлятор для остальных систем. Создатели тех или иных дистрибутивов Linux могли перепаковать run-инсталлятор, чтобы получить например пакет deb. И да, драйвер теперь проприетарный. Считалось, что в Red Hat проблемные иксы, которые надо патчить. А в SUSE иксы самые лучшие. Доходило даже до того, что самым беспроблемным способом настроить иксы в Red Hat - установить пакеты из SUSE. Впрочем, спустя пару лет иксы "причесали". А потом произошёл форк XFree86 под именем Xorg. В 2005 году прекращена разработка XGL - того самого нового сервера, который начали создавать в тот момент, когда считалось, что из-под "иксов" нельзя поюзать DRI. Однако при помощи XGL можно было пощупать композитинг - а это было любопытно. Поэтому поддержку XGL осуществляли до 2008 года (до тех пор, пока последний из драйверов, который не поддерживал AIGLX, не реализовал его поддержку). В 2008 году появился libxcb. Дело в том, что libX11 был тем ещё мучением для разработчиков программ (куда хуже WinAPI), и поэтому все использовали тулкиты - вместо того, чтобы напрямую общаться с libX11. В libxcb был потенциал. В 2008 году появился DRI2 - новая версия ядерного модуля. Драйверы radeon, intel и nouveau были переписаны под новый модуль (какое-то время - до 2023 года - в ядре распространялись драйверы DRI1 и DRI2. А вот в Месе поддержку DRI1 бросили ещё в 2012 году - в релизе 8.0). В 2008 году появился KMS - новая модель драйверов. Теперь драйвер реализовывался целиком в kernelspace, а в DDX-драйвере почти ничего не осталось. У KMS был ряд достоинств и почти не было недостатков. Ну и в ноябре 2008 года появился Wayland - новый графический сервер, который использует EGL вместо GLX, а также использует KMS в обязательном порядке. Также в обязательном порядке включен композитинг, а также в обязательном порядке - использование тулкитов. Wayland является более легковесным, чем X11. P.S. Ну что, не сильно длинно получилось?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	23. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+3 +/–
	Сообщение от Ананий (?), 02-Фев-24, 09:56
	>Wayland является более легковесным, чем X11 Глупый вопрос можно? Чому этот легковесный так долго пилят и все никак недопилят? Вечно какие-то проблемы, которых у нелегковесных X11 почему-то нет. Были ли какие-либо нароботки Mir использованны в wayland? Ну и когда уже X11-капец? ЗЫ я не потролить и не поразжигать срачи, просто интересно какие перспективы и когда все устаканится по вашему мнению?
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+4 +/–
	Сообщение от Stellarwind (?), 02-Фев-24, 11:19
	Проблема вейланда в том, что пытались сделать легковесный выкинув ненужное, а потом оказалось что без ненужного ничего не работает у пользователя. Причем они дружно сопротивляются попыткам вернуть ненужное, т.к. это либо к ним не относится, либо не безопасно. Еще и принцип вейленд это протокол, каждый ДЕ сам за себя тоже помог. Тиринг ужасно - всем нужен vsync обязательно, все остальные идиоты. То что игруны не хотят vsync, а хотят больше фпс очень долго убеждать пришлось. Глобальные хоткеи, скриншоты, скринкасты, расстановка окон по экрану - нельзя, потому что безопасность. В итоге это людям все равно это нужно и начали изобретать велосипеды как заставить это работать мимо вейланда - сначала каждый свой как может, потом когда им сказали что не будут писать приложения под десяток DE, начали обратно унифицировать в порталах/pipewire и т.д. До того чтобы дать приложухам восстанавливать окна вот почти договорились спустя 15 лет. Срать им что пользователь не хочет каждый раз окошки gimp расставлять.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от n00by (ok), 02-Фев-24, 11:45
	> Тиринг ужасно - всем нужен vsync обязательно, все остальные идиоты. То что > игруны не хотят vsync, а хотят больше фпс очень долго убеждать > пришлось. Что-то не заметно, что игруны убедили Хидэтака Миядзаки отказаться от фиксированных 60 кадров в секунду. Продажники "красных" и "зелёных", понятное дело, с радостью готовы идти на встречу требовательному покупателю и поддержать версию, что неотображаемые монитором кадры улучшают, простите за такое слово, гейминг.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Beta Version (ok), 02-Фев-24, 12:37
	> Продажники "красных" и "зелёных", понятное дело, с радостью готовы идти на встречу требовательному покупателю и поддержать версию, что неотображаемые монитором кадры улучшают, простите за такое слово, гейминг. А вы из тех, кто до сих пор в это не верит?
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
	Сообщение от Аноним (56), 02-Фев-24, 13:20
	Во всех новых играх первым делом иду в настройки и включаю VSync, чтобы уменьшить энергопотребление == нагрев видеокарты. Мне не нужно постоянно перестраивать сцену на GPU со скоростью 300 кадров в секунду, когда монитор показывает максимум 60, а физический игровой движок фиксирован на 30. Мнение Невидии по этому поводу, с её расплавленными картами, меня не интересует. А понты киберкотлетов - это понты киберкотлетов.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от n00by (ok), 02-Фев-24, 13:39
	> А понты киберкотлетов - это понты киберкотлетов. Может они в каких-то играх и обоснованы. Другое дело, что если отключение VSync что-то действительно даёт игроку, это значит, что с просчётом физики какие-то проблемы в движке и лишние кадры их компенсируют. Вот например тщательно продуманная физика и игрок с прямыми руками и превосходной реакцией: Elden Ring - Lvl1 Wretch VS Malenia Blade of Miquella [Solo, No Damage, Parry Kill] https://youtu.be/_tOfAdBvQRQ И против него миллионы, кто списывает свои ошибки на нехватку воображаемых FPS.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 13:59
	>> А понты киберкотлетов - это понты киберкотлетов. > Может они в каких-то играх и обоснованы. В локальной сети, на чемпионате - может и обоснованы. Но мы-то играем в Интернете с лагом 5-350 мс. Побеждает тот, кто хорошо знает карту (кратчайшие маршруты между бонусами) и натренирован стрелять на упреждение ("попой чует" куда побежит враг, через сколько мс окажется в перекрестии). Плюс, мышка с высоким DPI совсем не помешает. > отключение VSync что-то действительно даёт игроку, это значит, что Vsync реализован программным таймером в одном цикле с физикой, а не параллельно, аппартно. От такой синхронизации, действительно, мало толку. Но такое сегодня встречается очень редко, в студенческих движках.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 02-Фев-24, 14:08
	Под VSync я понимаю сигнал с видеокарты, к которому привязывается вывод очередного кадра движком. Если к нему же привязать и физику (а больше и не к чему - другой таймер неизбежно "поплывёт"), то могут быть нюансы. Например, в сложной сцене возник пропуск кадра. Если физика это не учтёт, то вся динамика игры сдвинется на 1/60 сек. И чувство игрока тем самым местом начнёт его подводить. В такой ситуации без VSync лаг физики окажется меньше, для игрока не столь заметен. Но тут надо не убирать ограничение кадров, а физику корректировать.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 14:42
	Физический движок (обычно) не привязан к выводу. Он работает на CPU, (обычно) имеет фиксированное время просчета кадра (исчисляемое от системного времени) и обязан успевать просчитать всё за это время. Если он всё-таки не успевает, то мы наблюдаем "торможение", но его "кадры" (тики / итерации главного цикла) никогда не пропускаются. Какие-то отдельные, независимые от моментального игрового состояния функции могут обсчитываться параллельной очередью. Например, ИИ может отложенно оперировать устаревшими данными сцены, полученными в предыдущие кадры, для построения маршрутов многочисленных ИИ-агентов. Впрочем, параллельная очередь может также сбрасываться по фиксированному времени, если не успевает всё обсчитать за это время. Обработка ввода (клавиатура/мышь) и вывода (дисплей), при этом, происходит параллельно. И синхронизируется с физикой/главным циклом "как придётся", "как ляжет", "как сквантуется". > Если физика это не учтёт, то вся динамика игры сдвинется на 1/60 сек. Движение в движке - результат интерполяции. С фиксированным кадром мы получаем только замедление динамики (игрок это чувствует, как и сетевую задержку, и подстраивается). В движках с плавающим кадром, когда deltaTime большое, он наблюдает "рывки", к которым не приспособишься.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 02-Фев-24, 16:45
	Вот это "фиксированное время" для расчёта кадра не с потолка ведь берётся. Считать 100 кадров в секунду при 60 Гц у монитора вряд ли имеет смысла больше, чем выводить кадры впустую. Т.е., грубо говоря, определяется частота монитора, и делится на коэффициент 1 или 2. Таким образом физический движек получается привязан к частоте вывода, но не жестко. Где привязан жестко - там возникают проблемы, "решаемые" отказом от VSync. В тех случаях наверняка и опрос ввода происходит в том же цикле, поскольку так проще.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 18:40
	> Вот это "фиксированное время" для расчёта кадра не с потолка ведь берётся. Берётся достаточно большим, чтобы обсчитать больше, но достаточно малым, чтобы чаще обновлять сцену (например, интерполированное положение движущегося объекта), чтобы игрок не замечал дискретного шага времени. Обычно это 30 Гц. Связь с частотой монитора косвенная: оба пытаются подстроиться под "частоту обновления" человеческого глаза (24-25 Гц). Такая же как с видеороликами с частотой 25-30 Гц для экономии места с почти незаметным глазу падением качества в движении. Физическая подсистема (особенно, если это специализированная, модульная библиотека) выполняется в отдельном потоке (thread) от обработки вывода и ввода. Она, когда нужно, снимает состояние ввода на момент и/или обрабатывает очередь накопленных событий. Графическая подсистема обновляется на основе состояния сцены, также на момент, также в одностороннем порядке. Когда игрок увидит готовый кадр, тот уже может сильно отличаться от реального (времени) состояния мира. (Поэтому видеовывод требует большей частоты обновления.) Связь между подсистемами косвенная, на уровне планировщика потоков ОС. Из-за этого многие данные в подсистемах дублируются. Например, при обсчете столкновений используется не настоящая геометрия, а заранее подготовленные на её основе геометрические коллайдеры. Не только для скорости, но из-за разницы времени выполнения и архитектур (CPU/GPU). Если вызывать подсистемы последовательно в одном цикле, то добиться фиксированной частоты затруднительно. То время на себя перетянет физика, то графика. То динамичная сцена замирает в ожидании окончания построения видеокадра (в теневом буфере - при двойной буферизации), то картинка замирает в ожидании пересчета всего мира. Тогда подсистемы нужно делать с плавающим кадром, с интерполяцией по переменной величине времени между кадрами (deltaTime) для каждой подсистемы соответственно. Но у плавающего кадра свои проблемы. А в век многоядерных всего-и-вся это как-то совсем нерационально.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 03-Фев-24, 11:56
	Благодарю за подробное описание. > чтобы игрок не замечал дискретного шага времени. > Обычно это 30 Гц. Связь с частотой монитора косвенная: > оба пытаются подстроиться под "частоту обновления" человеческого глаза (24-25Гц). Вот в первом предложении цитаты - ключевой момент. Ставится целью удовлетворить пользователя, вписать происходящее в виртуальном мире игры в особенности восприятия игрока. Далее программисты эту задачу решают. Кто-то справляется, согласовав модель с картинкой и ожиданиями пользователя. У других ТП начинает имитировать деятельность: подкрутите то, потом это. > Связь между подсистемами косвенная, на уровне планировщика потоков ОС. А с этим на "дефолтной" игровой платформе свои нюансы. Квант по умолчанию 15 мс, а способ изменить такое недоразумение Микрософт документировала лишь лет через 10 после начала массового использования. Без вызова timeBeginPeriod(1) случалась дилемма: Sleep(1) приводит к пропуску кадра, а без него загрузка 100%. > Если вызывать подсистемы последовательно в одном цикле, то добиться фиксированной частоты > затруднительно. То время на себя перетянет физика, то графика. То динамичная > сцена замирает в ожидании окончания построения видеокадра (в теневом буфере - > при двойной буферизации), то картинка замирает в ожидании пересчета всего мира. > Тогда подсистемы нужно делать с плавающим кадром, с интерполяцией по переменной > величине времени между кадрами (deltaTime) для каждой подсистемы соответственно. Но у > плавающего кадра свои проблемы. А в век многоядерных всего-и-вся это как-то > совсем нерационально. Так первые шутеры возникли задолго до многоядерности. Там разносить по потокам было чревато потерями на лишние переключения контекста. Для дублирования данных было мало памяти. Ждать синхроимпульс в DX7 - 100% загрузка процессора, насколько помню. Тогда отключение VSync, наверное, действительно имело смысл, а с тех пор обросло легендами и мифами.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	46. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Beta Version (ok), 02-Фев-24, 14:13
	> Во всех новых играх первым делом иду в настройки и включаю VSync, > чтобы уменьшить энергопотребление == нагрев видеокарты. Мне не нужно постоянно перестраивать > сцену на GPU со скоростью 300 кадров в секунду, когда монитор > показывает максимум 60, а физический игровой движок фиксирован на 30. > Мнение Невидии по этому поводу, с её расплавленными картами, меня не интересует. > А понты киберкотлетов - это понты киберкотлетов. Я тоже играю с локом на 60 фпс почти во все сингловые игры. Но в КС2 с 60 фпс просто не могу - управление недостаточно отзывчивое. А на 75 фпс уже норм для сильвера. А кто метит в голд или мастер, те в основном на 120 фпс играют. И кстати Vsync добавляет инпутлаг. Когда игра даёт такую возможность, следует отключать Vsync и включать внутриигровой лимит кадров. Или пользоваться сторонними программами вроде Mangohud.
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	48. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 02-Фев-24, 14:28
	То есть тут надо бы опрашивать устройства ввода дважды за кадр, но это придётся написать код, который бы рассчитывал время, плюс как-то обеспечить его устойчивость в ОС без гарантий реального времени. Куда как проще тупо рендерить лишний кадр, который никто не увидит - поток исполнения ведь чем-то занят, значит планировщик отдаст ему такты.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–3 +/–
	Сообщение от n00by (ok), 02-Фев-24, 13:22
	>> Продажники "красных" и "зелёных", понятное дело, с радостью готовы идти на встречу требовательному покупателю и поддержать версию, что неотображаемые монитором кадры улучшают, простите за такое слово, гейминг. > А вы из тех, кто до сих пор в это не верит? Я из тех, кто понимает принципиальное отличие веры от знания. Известно, что если кадр монитором не выводится, значит его не видно. Так же эксперименты подтверждают эффект плацебо среди верующих в силу имитации лекарства.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	42. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Beta Version (ok), 02-Фев-24, 13:43
	> Я из тех, кто понимает принципиальное отличие веры от знания. Известно, что > если кадр монитором не выводится, значит его не видно. Так же > эксперименты подтверждают эффект плацебо среди верующих в силу имитации лекарства. Так вы из тех, кто просто не разбирается в том, о чём судит и говорит. Вам нужно две вещи: 1) Узнать, что такое инпутлаг, оно же "задержка ввода управления" или "отзывчивость управления", и как на него влияет системный фпс (и что вообще такое системный фпс); 2) Узнать, что такое время кадра, как оно зависит от фпс, почему оно разное при 60фпс/60Hz и 120фпс/60Hz и как это влияет на то, что видит игрок на мониторе. Если что, мне не лень вам в общих чертах всё объяснить. Только попросите. Хотя куда проще оставить ссылку вот на этот ролик - https://www.youtube.com/watch?v=WGB93qQA10o&t=227s (смотреть с таймкода)
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 02-Фев-24, 14:22
	Мне не надо смотреть какие-то ролики. Я делал т.н. "мультипликатор" на экране Спектрума. Сразу объясню, что это требует манипуляций с отображаемой экранной памятью в строго определённое время хода луча. Поэтому советую Вам усвоить, что если "инпут лаг" зависит от FPS - значит опрос устройств ввода происходит когда попало, а не когда следовало бы. Но делать правильно - это за свои деньги. А купить видеокарту помощнее - это за деньги пользователя.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Beta Version (ok), 02-Фев-24, 15:04
	> Мне не надо смотреть какие-то ролики. Конечно вам не надо ничего смотреть. Вы же "понимаете принципиальное отличие веры от знания". Верьте дальше.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от n00by (ok), 02-Фев-24, 16:47
	>> Мне не надо смотреть какие-то ролики. > Конечно вам не надо ничего смотреть. Вы же "понимаете принципиальное отличие веры > от знания". Верьте дальше. Ну почему же ничего, я посмотрел на вот это: "Автор канала  - видеоблоггер, игровой обозреватель, стример." Всё это вполне укладывается в мою версию о подогреве кретинизации населения производителями железа. Если здесь ещё возможно встретить человека, кто слышал про "модель-вид-контроллер", а не только умеет из "игруны не хотят" плавно перейти к какой-то одной игре и _инпут_ лагу, то там вообще ловить нечего.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Beta Version (ok), 02-Фев-24, 16:57
	> Ну почему же ничего, я посмотрел на вот это: "Автор канала   > - видеоблоггер, игровой обозреватель, стример." Всё это вполне укладывается в мою > версию о подогреве кретинизации населения производителями железа. Чел озвучивает то, что и так знают те, кто знает инфу из обоих пунктов, озвученных мною пару комментов выше. Если вы не согласны с его словами - оспорьте их. Сливаясь со словами "он блогер, не моей высоты полёта птица" вы себя дураком выставляете и этот спор становится бессмысленным точно так же, как бессмысленнен спор с плоскоземельщиком.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 02-Фев-24, 17:25
	>> Ну почему же ничего, я посмотрел на вот это: "Автор канала >> - видеоблоггер, игровой обозреватель, стример." Всё это вполне укладывается в мою >> версию о подогреве кретинизации населения производителями железа. > Чел озвучивает то, что и так знают те, кто знает инфу из > обоих пунктов, озвученных мною пару комментов выше. Иначе говоря, существует некая группа лиц, друг на друга ссылающихся в доказательство своей правоты? В тех пунктах я не увидел ничего для себя нового, как в техническом плане, так и в "риторике". Обычное дело, свалить проблемы контроллера на отображать, ведь про MVC в среде тех экспертов никто не слышал. > Если вы не согласны > с его словами - оспорьте их. Не надо так спешить. Был вкинут тезис "вы из тех, кто просто не разбирается в том, о чём судит и говорит". Вот его и доказывайте. Напомню, что с п.2 вышло полное фиаско.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Beta Version (ok), 02-Фев-24, 17:47
	> Иначе говоря, существует некая группа лиц, друг на друга ссылающихся в доказательство > своей правоты? Нет. Чел в видео озвучил то же самое, что написал бы я. А проверяются его слова банальным увеличением фпс выше частоты монитора. Прямо сейчас запускаете КС2 и играете с 60 фпс, а потом выставляете 120 фпс и сравниваете. > В тех пунктах я не увидел ничего для себя нового, как в > техническом плане, так и в "риторике". Обычное дело, свалить проблемы контроллера > на отображать, ведь про MVC в среде тех экспертов никто не > слышал. Я не знаю вы мне сейчас какие-то обидки озвучиваете или это просто старческое брюзжание. В тех пунктах описано то, из-за чего увеличение фпс выше частоты монитора имеет положительное влияние на геймплей. Что вы мне сейчас конкретно пытаетесь доказать? Что и чел из видео, и я - оба врём и на самом деле фпс не влияет на инпутлаг и скорость вывода кадра на экран? > Не надо так спешить. Был вкинут тезис "вы из тех, кто просто > не разбирается в том, о чём судит и говорит". Вот его > и доказывайте. Напомню, что с п.2 вышло полное фиаско. Давайте без этих увиливаний. Фпс выше частоты монитора сказывается положительно на инпутлаге и скорости вывода кадра или нет? Сначала разберёмся с этим вопросом, а там уже будет ясно, что вы знаете, а во что верите.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	77. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 03-Фев-24, 12:25
	>> Иначе говоря, существует некая группа лиц, друг на друга ссылающихся в доказательство >> своей правоты? > Нет. Чел в видео озвучил то же самое, что написал бы я. > А проверяются его слова банальным увеличением фпс выше частоты монитора. Прямо > сейчас запускаете КС2 и играете с 60 фпс, а потом выставляете > 120 фпс и сравниваете. Нет. Раз уж мысли сходятся с тем экспертом по видеоблоггингу на Бесяточке, то прямо сейчас идёте в MSDN и ищете волшебные буквы: ISR, DPC и IRQL PASSIVE_LEVEL - на нём исполняется IRP CompletionRoutine. Поскольку GetDeviceState в DirectInput неблокирующий, придётся ознакомиться с нюансами работы планировщика, узнать длительность кванта. Тогда можно будет прикинуть самый настоящий инпут лаг в миллисекундах. Ну и может быть даже понять, что этот термин не имеет вообще отношения к выводу. Если с первого раза понять не удалось, то можно упростить, вот тут попытка уменьшить ипут лаг в Wine: https://github.com/ValveSoftware/wine/issues/60#issuecomment... Никаких Vsync в коде и близко нет. >> В тех пунктах я не увидел ничего для себя нового, как в >> техническом плане, так и в "риторике". Обычное дело, свалить проблемы контроллера >> на отображать, ведь про MVC в среде тех экспертов никто не >> слышал. > Я не знаю вы мне сейчас какие-то обидки озвучиваете или это просто > старческое брюзжание. В тех пунктах описано то, из-за чего увеличение фпс > выше частоты монитора имеет положительное влияние на геймплей. Что вы мне > сейчас конкретно пытаетесь доказать? Что и чел из видео, и я > - оба врём и на самом деле фпс не влияет на > инпутлаг и скорость вывода кадра на экран? Пока я вижу, что слова "модель-вид-контроллер" (MVC) упорно игнорируются, значит нет представления, что это вообще такое. Советую почитать сообщение #50 и дальше, где Аноним постарался и достаточно понятно расписал это применительно к играм. >> Не надо так спешить. Был вкинут тезис "вы из тех, кто просто >> не разбирается в том, о чём судит и говорит". Вот его >> и доказывайте. Напомню, что с п.2 вышло полное фиаско. > Давайте без этих увиливаний. Фпс выше частоты монитора сказывается положительно на инпутлаге > и скорости вывода кадра или нет? Сначала разберёмся с этим вопросом, > а там уже будет ясно, что вы знаете, а во что > верите. Сначала надо разобраться с вопросом "что такое индукция в логике". С тем, что "инпут" означает "ввод" и априори не имеет отношения к выводу, мы уже разобрались в первом абзаце. Если же он в какой-то игре имеет - значит, что конкретный движок написан абы как. Для обобщения на всё остальные необходимо, что бы везде было так же. А с этим сложности - в #39 я привёл пример, где отключение VSync ничего не даёт.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	82. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Beta Version (ok), 03-Фев-24, 13:37
	Заканчивай своё трёп и ответь на простой вопрос: фпс выше частоты монитора сказывается положительно на инпутлаге и скорости вывода кадра или нет?
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	85. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	–1 +/–
	Сообщение от n00by (ok), 04-Фев-24, 11:41
	> Заканчивай своё трёп А ты успокойся, прекрати так волноваться по поводу слова "гейминг". > и ответь на простой вопрос: фпс выше частоты монитора > сказывается положительно на инпутлаге и скорости вывода кадра или нет? Перечитай внимательно моё предыдущее сообщение, там есть однозначный ответ на твой вопрос. Вообще, я не удивлён, называющие себя "геймеры" упорно путают ввод и вывод. Гипотеза Сепира — Уорфа объясняет, почему.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	93. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (93), 05-Фев-24, 14:19
	Там нет ответа, там показное непонимание из-за недоопределённости input lag как термина - понимаешь, что имеется в виду, но считаешь, что неприятному собеседнику лучше в этом не признаваться. Input lag. Задержка ввода. Ввода куда? Ввода кадра в монитор? Так термин тоже нередко используется. Но тут - ввода пользователя. Задержка между вводом и чем? Чем угодно, в термине не написано, между чем, между выводом на монитор - тоже можно, что и имеется в виду. Если назвать это end-to-end latency, то неоднозначности будет меньше. Экспериментально эту величину замеряют (и убеждаются в пользе fps, превышающего refresh rate) скоростной камерой с модифицированной мышкой[1]. Зачем пытаться произвести впечатление кишками оффтоподрайверов, если обсуждается другой и более высокоуровневый вопрос (влияние fps на end-to-end latency при fps >= refresh rate)? Зачем обсуждать абстрактную физику с полетом кирпичей, если к теме относится только вещь более конкретная - ввод пользователя? Если предположить, что ввод обсчитывается 30 раз в секунду в отдельном от рендеринга потоке, то это будет надругательством над владельцами хороших мониторов и безрецептурным рвотным средством для владельцев VR, но даже в этом случае end-to-end latency в среднем уменьшится. Но вот Valve пишет[1] про свои онлайн-игры, там они в одном потоке: frame loop looks something like the following: ... 2. Sample user input (mouse, keyboard, joystick) ... 7. Render Scene > если отключение VSync что-то действительно даёт игроку Оно не может не давать, проблема задержек классического VSync породила столько других методов борьбы с тирингом, что их устанешь перечислять и неминуемо запутаешься в buzzword'ах. [1] https://youtu.be/4GnKsqDAmgY?feature=shared&t=183 [2] https://developer.valvesoftware.com/wiki/Latency_Compensatin...
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	94. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (93), 05-Фев-24, 14:29
	* "End-to-end _system_ latency" у Nvidia и в некоторых других статьях ** выводом, гхм, на поверхность монитора *** Valve пишет[2]
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	95. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 05-Фев-24, 17:32
	> Там нет ответа, там показное непонимание из-за недоопределённости input lag как термина > - понимаешь, что имеется в виду, но считаешь, что неприятному собеседнику > лучше в этом не признаваться. Напомню, что собеседник уже _отказался_ доказывать свой тезис "вы из тех, кто просто не разбирается в том, о чём судит и говорит". Теперь есть два варианта: 1. Посторонний не читал ветку целиком, упускает контекст и зачем-то решил прилепить сбоку своё особо ценное мнение. 2. Тот же самый собеседник пишет под Анонимом. В любом случае, не вижу особого смысла это комментировать, но попробую. > Input lag. Задержка ввода. Ввода куда? Ввода кадра в монитор? Так термин > тоже нередко используется. Речь о системе в целом, значит ввод - это данные с устройств ввода (клавиатура, мышь, игровой контроллер). > Зачем пытаться произвести впечатление кишками оффтоподрайверов, если обсуждается другой > и более высокоуровневый вопрос (влияние fps на end-to-end latency при fps > >= refresh rate)? Затем, что мне была дана ссылка на какого-то блоггера, а он использует как раз эту ОС. > Зачем обсуждать абстрактную физику с полетом кирпичей, если к теме относится только > вещь более конкретная - ввод пользователя? А зачем заниматься вот такой демагогией? Я и утверждал, что инпут лаг - это про ввод пользователя, а не про негативный опыт геймера в КС2. > Если предположить, что ввод обсчитывается > 30 раз в секунду в отдельном от рендеринга потоке, то это > будет надругательством над владельцами хороших мониторов и безрецептурным рвотным средством > для владельцев VR, но даже в этом случае end-to-end latency в > среднем уменьшится. Не надо предполагать, надо почитать, что я писал выше. А именно, что для избавления от инпутлага надо опрашивать ввод когда следует, и уж точно не с частотой 30 Гц. > Но вот Valve пишет[1] про свои онлайн-игры, там они в одном потоке: > frame loop looks something like the following: > ... > 2. Sample user input (mouse, keyboard, joystick) > ... > 7. Render Scene Ну да, как я и предполагал - сделали криво (потому что давно; тогда один поток был нормой), а не как описано в тех сообщения про физику. Потому и у самого свидетеля инпутлага он проявляется в одной игре, а в остальных он включает VSync. >> если отключение VSync что-то действительно даёт игроку > Оно не может не давать, проблема задержек классического VSync породила столько других > методов борьбы с тирингом, что их устанешь перечислять и неминуемо запутаешься > в buzzword'ах. Может не давать, ссылка на видео была выше.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	96. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (93), 05-Фев-24, 19:48
	Так вы же не разбираетесь, замеры обсуждаемой величины по первой ссылке вот проигнорировали, опыт игрока в Elden Ring используете как аргумент в пользу... того, что можно хорошо играть с VSync? Если бы с этим кто-то спорил. От своего "Если к нему же привязать и физику (а больше и не к чему - другой таймер неизбежно "поплывёт")" перешли к противоположному "Советую почитать сообщение #50 и дальше, где Аноним постарался", не сбавляя паров. Приписали оппоненту "он проявляется в одной игре", хотя он довольно ясно сказал, что это онлайн-игра, в ней задержки важнее. Похоже, писали странности без "показного непонимания". Уже понятно, как объясните результаты измерений (на канале таких много) - игру (игры) "сделали криво". Вы из тех, кто любит нефальсифицируемые гипотезы? Мы, наверное, все втроём сойдёмся в том, что погоня за минимальными задержками вне киберспорта не особо важна. Но вопрос в признании явления (положительного влияния повышения fps на end-to-end system latency при fps >= refresh rate).
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	98. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 06-Фев-24, 08:09
	> Так вы же не разбираетесь, замеры обсуждаемой величины по первой ссылке вот > проигнорировали Мы уже разобрались, что инпут лаг - это задержка сигнала ввода, а не разница между нажатием на кнопку и изменением картинки на экране. Допустимо использовать термин "инпутлаг" применительно к последнему: кто понимает смысл "инпутлага", то закроет глаза на подобное натяжение совы на глобус. Однако, последующие заявления "не разбираетесь" воспримет как проекцию. > опыт игрока в Elden Ring используете как аргумент в пользу... > того, что можно хорошо играть с VSync? Как пример игрового движка, где опрос управления реализован грамотно, потому ему не мешает синхронизация картинки. > Если бы с этим кто-то спорил. Так и я не спорю с тем, что отключение VSync помогает в каких-то частных случаях. Это и ежу понятно, что можно написать так, что VSync будет влиять. Вот только не надо перекладывать с больной головы на здоровую. Это проблема конкретных реализаций (ключевой момент - устаревших движков), а не Wayland. И это вообще обычное дело, что с legacy возникают проблемы, для их решения костылируют особую поддержку частных случаев.
	Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

	99. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Электрон (?), 07-Фев-24, 09:44
	Прежде чем вменять собеседнику непонятую импликацию и следующую по ней демагогию о задержке вывода, может следовало хотя бы одно предложение уделить этому и сказать, что автор строго разграничивает в своих понятиях задержку ввода и вывода.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	100. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 07-Фев-24, 13:21
	Такой подход давал ли хоть раз результат в случае _веры_ (см. #33)? С точки зрения члена секты отрицание догмы посторонним является очередным доказательством величия их гуру. Поэтому я сначала прощупал, верно ли предположение, а в #77 на паре примеров указал, что такое инпут лаг. На этом набор шаблонов верующего закончился. Я извлёк для себя хоть какую-то пользу - следующий оппонент потрудился и вывалил в #93 подтверждение моего предположения, что в КС2 всё крутится в одном цикле. В чём-то их убеждать - это мартышкин труд. Вот из такого волшебным образом делают выводы, что Wayland хуже X.org: https://github.com/ValveSoftware/csgo-osx-linux/issues?q=is&... 1. [CS2] Frustratingly inconsistent mouse and keyboard actions #3403 https://github.com/ValveSoftware/csgo-osx-linux/issues/3403 X Server Vendor: The X.Org Foundation Monitor Refresh Rate: 164 Hz Mouse will inconsistently fast double click while lining up a flash or smoke. 2. Insane input lag, stutters and artifacts on low settings #3302 https://github.com/ValveSoftware/csgo-osx-linux/issues/3302 X Server Vendor: The X.Org Foundation Monitor Refresh Rate: 164 Hz ... My fps is almost constant, and the biggest frame drop is from 200 to 150 (but still have to be good), anyway it's awful laggy and choppy.. 3. Mouse low sensitivity #3301 https://github.com/ValveSoftware/csgo-osx-linux/issues/3301 X Server Vendor: The X.Org Foundation Monitor Refresh Rate: 143 Hz ... I also noticed that when moving the mouse to the left, it seems heavier than moving to the right
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	34. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (-), 02-Фев-24, 13:07
	> скриншоты, скринкасты Уже давно есть, не надо тут. > Срать им что пользователь не хочет каждый раз окошки gimp расставлять. Да, именно так. Вообще странно, когда когда в вебе кто-то что-то фингерпринтит - сразу набигают белки истерички "за нами слидят!!111" А когда так же самое есть у любой десктопной аппы - не, ну это норм, диды как-то с этим жили, ну и нам так же жить.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	38. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
	Сообщение от Аноним (56), 02-Фев-24, 13:29
	> когда в вебе кто-то что-то фингерпринтит > А когда так же самое есть у любой десктопной аппы В вебе приложение поставляется во время исполнения и имеет закрытый/обфусцированный код. Что и куда оно передавало/передаёт/будет передавать - неизвестно. Локальное приложение собирается из исходников с полностью контроллируемым процессом обновления и хранит настройки (например, позицию и размер окна) локально и никуда не передает. Если тебе "всё едино", значит, ты не понимаешь, что такое модель безопасности, значит, и безопасность тебе не нужна, ты просто очередная жертва маркетинга, купившаяся на "безопасность".
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (-), 02-Фев-24, 14:44
	> Локальное приложение собирается из исходников с полностью контроллируемым процессом обновления Серьезно? Это в каком-то линуксовом манямирке весь софт с открытым кодом. А в реальном мире тебе нужно устанавливать проприетарный софт и совсем не хочется, чтобы он шарился где попало. > и никуда не передает думаешь ты)) А про дыры в приложениях - и открытых и закрытых - можно даже не вспоминать.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 15:23
	> Это в каком-то линуксовом манямирке весь софт с открытым кодом. Ну не весь - 98,5%. > проприетарный софт и совсем не хочется, чтобы он шарился где попало Оставшиеся 1,5% можно запустить в отдельном user namespace без сети и быть уверенным: что происходит в клубе, остаётся в клубе. А веб-приложение без связи с backend-ом теряет свою полезность. >> и никуда не передает > думаешь ты)) Знаю. > А про дыры в приложениях А про модель безопасности, ты так ничего и не понял?
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (-), 02-Фев-24, 15:46
	> Ну не весь - 98,5%. > Оставшиеся 1,5% можно запустить в отдельном user namespace без сети и быть уверенным: что происходит в клубе, остаётся в клубе. Что правда? У тебя октрыты все дрова начиная от загрузчика, до прошивок на всех-всех устройствах, включая сетевую карту, gsm модем и тд? Ты собираешль компилятор начиная с ввода хекс кодов с бумажки? Да у нас тут просто мегакакер! > А про модель безопасности, ты так ничего и не понял? Ну так просвети меня, о гуру! Расскажи, что мне применить, чтобы получить правильную "модель безопасности". В соседних новостях про "очередная уязвимость в su" народ как-то не уверен.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 16:06
	> У тебя октрыты все дрова начиная от загрузчика, до прошивок на всех-всех устройствах, включая сетевую карту, gsm модем и тд? Я специально всё открытое не подбирал, исходил из бюджета, что вполне соответствует уровню секретности обрабатываемой мной информации. И пока никому ещё не удалось проэксплуатировать загрузчик и прошивки, чтобы подсунуть мне таргетированную рекламу. Чего не скажешь о вездесущей телеметрии в вебе. > Ты собираешль компилятор начиная с ввода хекс кодов с бумажки? А ты нет? См. https://en.wikipedia.org/wiki/Bootstrapping_(compilers) > Да у нас тут просто мегакакер! И это ты? > Расскажи, что мне применить, чтобы получить правильную "модель безопасности". Для начала, перестать валить всё в кучу и доводить до абсурда.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Аноним (-), 02-Фев-24, 17:09
	> И пока никому ещё не удалось проэксплуатировать загрузчик и прошивки, чтобы подсунуть мне таргетированную рекламу. Ты ж понимаешь, насколько это глупо звучит? Те кто смогут  проэксплуатировать загрузчик или прошивки не будут тебе ничего подсовывать.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 18:53
	> Ты ж понимаешь, насколько это глупо звучит? Ты же понимаешь, что это была ирония над твоим подходом к безопасности - "сгорел сарай, гори и хата".
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 13:41
	Существует какой-то список литературы (на русском или английском языке) по исторической стороне графического вопроса?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	49. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Zenitur (ok), 02-Фев-24, 14:32
	> Существует какой-то список литературы (на русском или английском языке) по исторической > стороне графического вопроса? Можно начать с Википедии: https://ru.wikipedia.org/wiki/Mesa_3D Насчёт книг - не знаю. Знаю, что есть Red book, Green book и так далее, являющиенся настольными книгами для разработчика под OpenGL. Я слышал о них в выпуске "16 бит тому назад" про OpenGL. Эти книги, они скорее про программирование, чем про "понять, как это работает". 700 страниц текста убористым шрифтом про каждый вызов OpenGL... Как-то так.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (56), 02-Фев-24, 15:13
	Не, мне именно (более детальная) история развития графического стека в Linux и его userspace интересна. А GL - только в части его интеграции в экосистему: GLX/EGL.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от n00by (ok), 03-Фев-24, 12:39
	Историей интересуетесь с целью прикинуть будущее? Я её знаю плохо, но в двух словах: каждый хотел перетянуть общее одеяло на себя. Сейчас настоящее таково, что RedHat уже выкинула X.Org. Остаётся Steam OS, но в Wine 9.0 работает Wayland, значит в Proton 9.0 будет так же. В 10.0 вероятно выкинут X. Хотелки остальных на судьбу X.Org не влияют. С OGL ситуация схожа: Khronos Group определяет Vulkan как перспективное API. Из существующих драйверов поддержку OGL вряд ли удалят в ближайшее время, но новые наверняка будут появляться с поддержкой только Vulkan. В Mesa уже есть прослойка для трансляции OGL в Vulkan https://docs.mesa3d.org/drivers/zink.html
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (5), 03-Фев-24, 01:58
	Спасибо! Очень интересно, познавательно и просто описано!
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	80. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Zenitur (ok), 03-Фев-24, 13:30
	> Спасибо! Очень интересно, познавательно и просто описано! Пожалуйста! Если вам интересно, добавлю ещё немного. Моим первым линуксом был KNOPPIX в 2004 году. У меня был вполне стандартный комп для того времени: Athlon XP и GeForce 4. Удивило, что можно загрузить систему, не устанавливая её на комп. А это - вполне себе альтернатива системной дискете Windows 98... Вот только NTFS не поддерживался на запись, а значит, можно попытаться восстановить систему только на разделе FAT32. Там я увидел браузер Mozilla 5.0, плеер XMMS, KDE 3.2, гимп, опенофис... Одна из игр, которая была в комплекте, по необъяснимой причине тормозила. Игра Chromium B.S.U. обладала простенькой графикой (2D-битэмап), примерно на уровне другой игры, которая находилась на том же диске - Enigma. Однако Enigma нормально работала. Затем я попробовал Mandrake 10.0. Раздражали шрифты с засечками на рабочем столе, а так - всё то же самое. KDE, XMMS для аудио, mplayer для видео... Познакомился с классной программой k3b - для записи дисков. В какой-то момент я нашёл в местной локальной сети - Linux-версию одной игры. Это игра с простенькой графикой и открытым кодом. Мне было интересно запустить на своей системе - что-то стороннее. И я никак не мог пройти один уровень - там в туннеле FPS падал до 5-10. Наал искать в интернете решение проблемы - пишут "надо установить драйвер NVIDIA". И начался квест по установке драйвера... Скачал run-файл. И что с ним дальше делать? Мышкой нажимаю - ничего не происходит... В интернете пишут: открыть командную строку и написать "sh имя_файла". Набираю - установка запускается и пишет "я вижу, у вас загружен графический сервер. Выключите его, прежде чем продолжать установку". Мне страшно! В консоли под линуксом я ещё не работал! Под досом - да... Набираю "init 3". Набираю "sh имя_файла". Установка завершена. Набираю "init 5". Хм, вроде ничего не изменилось... Однако игра стала выдавать 100-150 FPS вместо 20-25. И игра Chromium B.S.U. внезапно тоже забегала бодренько! Так вот почему она тормозила... Она использовала OpenGL, который всё это время был программным. А Enigma и Frozen Bubble не использовали. Оказалось, что драйвер NVIDIA не предустанавливается в дистрибутив Linux. Причина: законодательство США. Однако существует такая штука, как национальные дистрибутивы Linux. Alt Linux и ASP Linux в России, Kurumin в Бразилии. Там драйверы с несвободной лицензией и закрытым кодом могут быть предустановлены. Mandrake по-идее тоже национальный дистрибутив (Франция), но он претендовал на популярность, а потому не включал в себя драйвер NVIDIA в стандартной поставке (однако была версия PowerPack с платными прогпраммами - там, возможно, драйвер был доступен сразу же при установке). Мне стало интересно: как же работало 3D до этого? Оказалось, что оно работало через Mesa. Mesa - библиотека OpenGL, которая выполняет отрисовку на процессоре. Оказалось, что на сайте OpenGL нет готовых сборок библиотеки. Там лежат только спецификации, а также заголовочные файлы. Писать код библиотеки приходится производителям операционных систем. А драйвер NVIDIA стирает библиотеку libGL.so.1, которая предустановлена в систему (пакет Mesa), и устанавливает свою. Интересно получается: разработчики Mesa сделали библиотеку "под снос", которую пользователит удаляют сразу, как устанавливают систему. После Mandrake я попробовал SUSE. Меня там удивил более крутой центр управления - YAST вместо DrakX. Ещё там был аудиоплеер Amarok, который был красивее, чем XMMS. Однако mp3 почему-то не игралось! Оказывается, на установочный CD нельзя класть не только закрытый код, но и патентованный код... Интересно, почему тогда в Mandrake mp3 играли? В общем, в SUSE нужно было подключить репозиторий Packman, а затем открыть YAST, выбрать репозиторий Packman и нажать "перевести системные пакеты на версии из этого репозитория". Несколько пакетов (libavcodec, libxine) заменялись на них же, пересобранных с "--enable-libmad". mp3 заработали. А вот драйвер NVIDIA, который я скачал для мандрейка почему-то не ставился. Интернет говорит, что, когда выпускается новая версия ядра Linux - надо скачивать новую версию драйвера, в которой добавили поддержку нового ядра. В Мандрейке было ядро 2.6.4, в сусе - 2.6.16. Прошлый драйвер попросту не знал о существовании ядра 2.6.16, поэтому пришлось скачать заново... Снова интересное нововведение: программа установки драйвера заверишла установку словами "Вам нужно сгенерировать конфигурационный файл /etc/X11/xorg.conf - если вы хотите, я могу сделать это прямо сейчас. Однако вы всегда можете это сделать командой nvidia-xconfig. В случае, если у вас SUSE Linux, выполните "SaX2 -m 0=nvidia". Интересно, почему SUSE требует особенного отношения? Выполнил - открылась программа по настройке видеокарт, мышек, клавиатур и тачскринов. Я выбрал просто "применить изменения". В сусе я впервые попробовал Wine. В системе была версия 0.9.11, в то время ходила шутка, что, когда Wine достигнет версии 1.0 - наступит [censored]. Я посмотрел, какая версия Wine является последней. 0.9.30. Что ж, [censored] откладывается. Скачал, установил, и правда больше софта заработало... На диске от журнала Linux Format мне попался диск с Kororaa 0.2. Вот треды о нём: https://www.linux.org.ru/news/linux-general/1302351 https://www.linux.org.ru/news/linux-general/1340074 https://www.linux.org.ru/news/opensource/1659888 Загружаю. Вижу логотип NVIDIA, значит, проприетарные драйверы - мало того, что предустановлены, так ещё и автоматически настроились! Загружается рабочий стол GNOME. Непривычно - в Mandrake и SUSE я загружал GNOME только на "посмотреть". А в остальное время пользовался KDE. В журнале пишут "потаскайте окно из стороны в сторону - оно будет желеобразным". Попробовал - действительно. "Нажмите Alt и покрутите скролл мыши - окно станет полупрозрачным". Попробовал - и правда. "Нажмите Winkey и покрутите скролл мыши - включится экранная лупа". Включилась. "Сворачивайте и разворачивайте окно - оно будет плавно сворачиваться и разворачиваться. Откройте и закройте меню - оно будет плавно появляться и исчезать". Ну и в качестве небольшого бонуса - возможность включить дождь по Shift-F9, и порисовать водой Winkey+левая кнопка мыши. Первая мысль "а как же в фотошопе под Wine увеличивать и уменьшать изображение? В гимпе-то это делается по Ctrl, а в фотошопе по Alt". Второй вопрос: как это запустить в SUSE? Я нажал "включить XGL" - мне ответило "ваша видеокарта не поддерживается". Оказывается, нужно было установить драйвер из rpm-пакетов, а не из run-инсталлятора. Я об этом не знал. Причём не только я: https://www.linux.org.ru/search.jsp?q=xgl+suse&range=ALL&int... Скачивать драйвер я не стал - трафик не резиновый... Отредактировав конфигурационный файл, отключив проверку на совместимый драйвер, я запустил-таки XGL. Затем обновление с 10.1 на 10.2. Новое ядро 2.6.18, поддержка записи на NTFS... Однако драйвер madwifi, который прекрасно собирался под 2.6.16, отказался собираться под 2.6.18. На страничке драйвера на sourceforce выложили обнову. Потом был скандал с когда Novell и Microsoft заключили соглашения. Они касались разработки Mono (это .NET для Linux, Майкрософт помог его улучшить), OpenOffice (Майкрософт помог улучшить поддержку макросов VBA в документах Microsoft Office), Майкрософт также решил использовать SUSE на своих серверах и рабочих местах. Казалось бы, всё же хорошо, разве нет? Однако пользователей пугало сближение этих компаний. Дело в том, что Novell обладал патентами на UNIX, и если случится так, что Microsoft ими завдалеет... Будет жопа. К счастью, всё обошлось. SCO проиграла суд, а Novell успешно защитилась. Следующим дистром выбрал Ubuntu. Версия 6.06 имела лавинообразную популярность, когда о системе, о которой раньше никто не слышал, стали говорить. Я установил версию 7.04. В журнале писали, что эта версия "разочаровывала малым количеством инноваций!". А это - на секундочку - Upstart, Jockey... Интересно, что же было в версии 6.10, что автор статьи на её фоне сказал, что этого мало... Убунта - гном. Пришлось привыкать. Можно было поставить Kubuntu - но опять-таки, трафик не резиновый. Кстати про трафик: в этот раз установочным носителем был CD, а не DVD, поэтому предустановленных прог было мало. Я ограничился драйверами NVIDIA и madwifi, а также кодеками mp3, которые предложил мне Jockey. Что же насчёт 3D-эффектов рабочего стола - я с удивлением узнал, что они, оказывается, называются не XGL, а Compiz! Вот это поворот! В общем, сейчас всё объясню. Как следует из названия, XGL это X11 поверх OpenGL. Раньше OpenGL можно было запускать _внутри_ X11, например в окне. Теперь сам сервер X11 работает поверх OpenGL. XGL делился на два компонента: Xegl и Xglx. Первый использовал EGL и позволял сделать иксы легковесными, но так и не был закончен. Сейчас вместо него - Wayland. Второй использовал GLX и являлся временным решением: рядом с XGL стартовал классический сервер X-Server. А 3D-эффекты, это Compiz, а не XGL. Но так как информации было мало, все называли эти 3D-эффекты - XGL. В какой-то момент, разработчики прекратили разработку XGL. Причина вот: https://www.linux.org.ru/news/opensource/1035637 Разработчик из команды Fedora Team по имени Kristian Høgsberg (который потом создаст Wayland и уйдёт работать в Intel) предложил решение, как можно запустить 3D-эффекты в обычном, не патченном X-Server. Решение называется AIGLX (Accelerated Indirect GLX). https://en.wikipedia.org/wiki/AIGLX Однако существовала серьёзная проблема: AIGLX требовал для своей работы libdrm. А проприетарные драйверы с этой библиотекой не общались. Как разработчики выходили из ситуации? NVIDIA выпустила драйвер 9625-beta с поддержкой расширения GL_EXT_texture_from_pixmap. Фактически, NVIDIA сделала свой собственный AIGLX, но без необходимости использовать libdrm (NVIDIA не использовала её по каким-то своим причинам). Причём AIGLX требовал Xorg 7.1, а NVIDIA работала даже на Xorg 6.9, фактически сделав подарок владельцам старых систем, таких как RHEL 4. AMD продолжала использовать XGL дальше. Ради AMD, подержку XGL дотянули до Xorg 7.3. Когда же вышел драйвер Catalyst 8.8 с поддержкой AIGLX - XGL тут же выбросили из кода Xorg. Следующая версия Xorg 7.4 была уже без него. Ну а дальше - банкротство Sun и покупка её компанией Oracle. Появление файловой системы ext4. Появление офисного пакета LibreOffice (Oracle не была заинтересована в дальнейшей разработке OpenOffice, поэтому сообщество форкнуло Go-OO - тот самый форк OpenOffice от Novell с улучшенным VBA). Появление аппаратного ускорения в Mesa (внезапно - я всегда считал, что это чисто софтварная библиотека). Об этом расскажу подробнее. Когда я в начале текста сказал, что Mesa это чисто софтварная библиотека - я соврал. Она поддерживала аппаратное 3D, причём всё это время. Просто наиболее популярные графические карты - NVIDIA и ATi - ей не поддерживались, поэтому я не знал. Когда я только начинал осваивать Linux, интеграшек от Intel ещё не было (или я про них просто не слышал). А их драйверы использовали именно Mesa (а не свою библиотеку, как NVIDIA), которая давала им не программную, а аппаратную отрисовку. Всё начало меняться, когда AMD купила компанию ATi. Если раньше публиковались спецификации лишь для устаревших карт - после того, как AMD возглавила компанию, спецификации стали доступны и для новых видеокарт тоже. На рубеже 2008-2009 годов появилась новость: R600 обзавёлся аппаратным ускорением на открытом драйвере! Для того, чтобы проверить, нужно собрать ядро из GIT, libdrm из GIT, Mesa из GIT и драйвер radeon из GIT. Я всё это сделал. Это было здорово: проприетарного драйвера нет, а 3D-ускорение есть. Впрочем, в тот момент поддержка была ещё ранняя, работало не всё, но разработка продолжалась. У меня была проблема: после каждого обновления ядра, иксы не стартовали. Оказывается, нужно было пересобрать модуль ядра под новое ядро. Это не касалось открытых драйверов - только проприетарных. Однако как я это сделаю, если передо мной - чёрный экран? Ответ: переключиться на витруальный терминал нажатием клавиш Ctrl-Alt-F1, отредактировать /etc/X11/xorg.conf, заменив драйвер NVIDIA на nv или vesa. Первый поддерживает только 2D, а второй не поддерживает даже этого, но при этом является универсальным драйвером, выпущенным под любую видеокарту PCI, AGP или PCI-E. А в Ubuntu 8.10 появился удобный "Безопасный режим", когда драйвер vesa включался автоматически, если что-то пошло не так. А ещё на убунтофоруме очень не любили, когда кто-то устанавливал драйвер из run-инсталлятора. "Вы же нарушаете пакетную систему!". На форуме пубилковалась команда, которая повторно устанавливает месу (apt-get с перечислением пакетов). После чего, предлагалось устанавливать драйвер NVIDIA или AMD из пакетов. Через некоторое время я узнал, что, при установке из run-файла, драйверы NVIDIA и AMD делают бэкап файлов, которые они затирают. Запуск инсталлятора с ключом --uninstall возвращает всё как было. Искать специальную команду для удаления драйвера NVIDIA (если вы устанавливали его при помощи инсталлятора) стало не нужно. Ну а дальше началась гибридная графика, Bumblebee. Аппаратное ускорение VDPAU, VA-API. Компьютинг на GPU: CUDA и OpenCL. Флеш плеер с поддержкой VDPAU и CrystalHD 98% сайтов с онлайн-видео использовали именно флеш), когда энтузиаст из Уфы написал враппер, позволяющий использовать аппаратное ускорение на Intel и ATi. Написали PulseAudio, дропнули HAL, дропнули GNOME2 и KDE3, форкнули их под именами MATE и TDE. Форкнули OpenAL под названием OpenAL Soft, в котором появилась поддержка EAX на аудиокартах без поддержки оного. В том числе и под Linux. Wine 1.0, Firefox 3.0, Google Chrome, электрон, дропнули нативный скайп. Steam, Wine Staging, CSMT. Прекращение разработки Cedega. Vulkan, DXVK, Proton, Steam Deck. Андроид, Chromebook, суд Microsoft с вендорами смартфонов из-за FAT. exfat-fuse, exfat-nofuse, драйвер Paragon NTFS в ядре. Дропнули Madwifi в пользу ath5k, на основе которого создан ath9k - лучший драйвер Wi-Fi под Linux. LXC, Docker, KVM, Systemd... Впрочем, это уже совсем другая история.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (5), 04-Фев-24, 10:05
	Нужна так называемая майндмэп что бы было пррще понять историко-стэковую связь ))) столько разработок, столько версий... Так получается, что вэйланд это, от части, забытая старая XGL? Нужно было настроить на стареньком ноуте графику, и с bumblebee, получился еще тот квест, железо устаревшее, но еще могет (интел + nvidia). В манах дебиана рекомендуется ставить все это совместно с primus примус автоматом тянет primus-vk, он завязан на vulkan, vulkan на старом железе не поддерживется, ничего не стартует, для запуска просто через шмеля требуется сторонняя библиотека, которой нет в репах, в общем нормально работает только встройка ))). Вариант просто включить дискретку и выводить изображение с помощью настройки иксов (дискретка -> встройка -> экран) наблюдаются подлаги, а фпс очень низок в отличие от запуска на виндопсе.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Zenitur (ok), 04-Фев-24, 13:44
	> Нужна так называемая майндмэп что бы было пррще понять историко-стэковую связь ))) Можно просто спросить на ЛОРе. Там многие застали и многие помнят. Bumblebee был актуален в 2013 году, и многие пользовались им в Ubuntu или Mint. > Так получается, что вэйланд это, от части, забытая старая XGL? Получается что да. Я делал поиск на ЛОРе, упоминание XGL впервые встречается в 1999 году (если сделать поиск и отсортировать от старых к новым). Скорее всего, причина прекращения разработки в том, что трудно сохранить совместимость с тяжёлыми (как их принято называть) иксами, когда у тебя - легковесный сервер. Другая версия: возможно, не была готова библиотека EGL, которая должна была прийти на смену библиотеке GLX. Если эта версия верна, то тут одно из двух: либо те два человека, которые делали XGL, ждали, когда будет готова EGL, и не дождались. Либо они сами же её и делали, однако им не хватило денег и сил. Вообще, меня удивляет одна штука, появившаяся ещё в начале "нулевых" - Quartz Compositor от Apple. Я так понимаю, они нашли в списках рассылки freedesktop.org - идеи XGL и EGL, и просто их доделали. Дали денег, наняли специалистов... С другой стороны - разве Apple не презрительно воротила нос от линуксоидов? Не знаю, майкрософт - однозначно да, а вот Apple использовала FreeBSD в качестве ядра для Mac OS X, KHTML в качестве основы для WebKit, а сервер печати CUPS вообще ей и разрабатывается. И кроме того, когда я впервые попробовал Raspberry Pi, там была папка /opt/vc/lib с файлами libGLESv2.so и libEGL.so. Портированные, как я понял, с Андроида (GPU VideoCore IV, используемый в Raspberry Pi, это чип с мобилок, разработанный Broadcom). Получается, что EGL появился на Андроиде раньше, чем в Месе (там эта библиотека появилась в версии 7.8 в 2010 году, а мобилки на андроиде появились в 2007-2008). А значит, и на iOS используется та же связка GLES2 + EGL... Столько вопросов, и так мало ответов... Получается, что XGL + EGL вдохновили Apple создать Quartz Compositor, а он, в свою очередь, вдохновил Microsoft создать Aero, а Novell - Compiz. Потом успех iPhone привёл к появлению Android, а композитные серверы на мобилках (SurfaceFlinger на Android) вдохновили Red Hat создать Wayland... Даже по времени сходится: Wayland появился в ноябре 2008, когда андроид существовал полгода-год. > Нужно было настроить на стареньком ноуте графику, и с bumblebee, получился еще тот квест, железо устаревшее, но еще могет (интел + nvidia). Нужно на ЛОРе спросить. Там многие пользуются Bumblebee до сих пор, несмотря на то, что уже есть PRIME Offloading. У меня на ноуте - именно последний вариант, для него требуются довольно новые иксы (1.20.7 из PPA с патчами или 1.21). Однако NVIDIA не "засыпает" при неиспользовании: она это делает автоматически только на новых GPU типа Turing или Ambere - а у меня Kepler. Приходится вручную по инструкции с ЛОРа запускать скрипт bbswitch: https://www.linux.org.ru/articles/desktop/17315787
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (5), 04-Фев-24, 20:10
	>>И кроме того, когда я впервые попробовал Raspberry Pi... Хм... конспирология? )))
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Zenitur (ok), 04-Фев-24, 23:57
	Скорее домыслы. Когда я увидел, что на Raspberry Pi есть OpenGL_ES и EGL, а на десктопном линуксе их нет - я понял, что их портировали с андроида (имена файлов без SOVER на это намекали). Как так получилось, что на десктопе EGL так и не доделали, а на мобилках он уже давно есть? Вот я и решил, что линуксоидам не хватило денег и человеко-часов работы, чтобы это доделать, а Apple и Google соответствующими деньгами располагали.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Zenitur (ok), 10-Фев-24, 12:43
	Раз уж я поднял тему графического стека (а людям понравилось) - напишу ещё один комментарий. И хотя новость уже ушла с Главной и коммент всё равно никто не прочитает - мне нужно сослаться на это сообщение из комментания к новости про Palemoon. Во времена, когда актуальными версиями OpenGL были 1.5 и 2.1.2, NVIDIA не соблюдала слишком строго спецификацию OpenGL. Причём кому-то это нравилось: люди говорили, что благодаря расхождениям со стандартами, писать код под NVIDIA проще, чем под конкурентов. "Если бы это зависело от нас, мы бы выпускали свой софт только под NVIDIA". Пример высказывания от разработчика Natural Selection 2: https://www.linux.org.ru/forum/talks/10487097 А кто-то напротив, ругал NVIDIA (примеры таких высказываний есть по той же ссылке). "Мы писали код, проверяя его на NVIDIA - а AMD он не заработал! Мы подумали, что Catalyst глючит - но оказалось, что он отработал, как надо! Это NVIDIA работает неправильно, но мы-то считали такое поведение правильным!". В то время NVIDIA доминировала на Linux, и AMD-шники (порой справедливо) считали, что в некоторых случаях их драйвер обвиняют в глюках не потому, что глюки реально были, а потому что софтину во время разработки затачивали под NVIDIA! Кто-то даже презрительно называл их библиотеку - NVIDIAGL (привет, Quasar!), подразумевая, что из-за неточного следования стандартам это уже не OpenGL, а какая-то другая библиотека. В драйвере 180.xx, выпущенном в 2009 году, NVIDIA реализовала поддержку OpenGL 3.0. Начиная с третьей версии, соответствие спецификациям стало строгим. Предполагалось, что юзеры рано или поздно уйдут от использования OpenGL 1.x и 2.x. Таким образом, проблема решится сама собой. В драйвере 364.xx, выпущенном в 2016 году), NVIDIA реализовала поддержку KMS и GLVND. Благодаря GLVND, иксы теперь стали работать не с одной, а с двумя библиотеками OpenGL - что сделало возможной переключаемую (гибридную) графику. Вот только ради реализации подобной фичи, этой компании пришлось удалить все несоответствия стандартам в своей библиотеке OpenGL... Если запустить установку с ключом --help, нам покажут опции, как установить glvnd-версию драйвера (которая строго соответствует спецификации OpenGL), а как nonglvnd (которую раньше неофициально называли NVIDIA GL). В Debian сделали два пакета libgl1-nvidia-glx-glvnd и libgl1-nvidia-glx-nonglvnd на выбор. Для чего нужен выбор? Для того, что какой-нибудь коммерческий софт (Maya или Nuke) наверняка знал об особенностях NVIDIA OpenGL, и вставлял свои "костыли" в случае использования этого драйвера... А если применить такие костыли с glvnd-версией OpenGL jn NVIDIA, софт мог просто упасть... В качестве примера такого софта я могу привести Compiz 0.8.8: у меня GTK2-программы под ним начали закрашиваться белым и не всегда перерисовывать окно. Надеюсь, что в актуальных версиях Compiz проблема поправлена... Также я подозреваю, что самая первая версия игры Metro: Last Light (которая была выпущена для Linux ещё до переиздания Redux) перестала запускаться (хоть я и не проверял, но мне так кажется). Дело в том, что автор порта тестил её на NVIDIA GT 640M, и включение __GL_THREADING_OPTIMIZATIONS=1 (оптимизации, появившиеся уже после релиза порта) приводило к неработоспособности игры. Значит, и glvnd данный порт может воспринять так же, раз уж он такой хрупкий и нежный. Начиная с драйвера 440.xx, nonglvnd-версии библиотеки больше нет. Всем, у кого софт порушился в процессе переазда на glvnd, давали 5 лет, чтобы это устранить. Также из драйвера были удалены файлы gl.h, glx.h и т.д., это заголовочные файлы, которые в "десятые" и "нулевые" годы позволяли собирать софт с nonglvnd-библиотекой.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	88. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (-), 04-Фев-24, 13:46
	> Так получается, что вэйланд это, от части, забытая старая XGL? Неа, Wayland это изменение парадигм относительно Xorg. В xorg все и вся - включая bulk data - пихается в протокол дисплейного сервера, и тот от и до парсит, объединяет и выдает на экран. По задумке в Xorg были сложные операции, типа рендера фонтов или контролов. Но контролы страшны как смерть, рендер фонтов тоже, а активное рисование чего-то типа такого через центральный сервер - ставит колом всю графику в системе. Поэтому современные тулкиты типа GTK и Qt рендерят все сами в контексте программы а иксам отдают - готовый битмап. И проблема иксов в том что как плевалка битмапов они переусложненные, тормозные и кривые, а 90% кода - unused, но место занимает и майнтенанс нагружает. В wayland через протокол делается аллокация буферов-поверхностей и параметров этого. После получения региона, апликуха работает с этим грубо говоря напрямую. Основной поток данных не врапается в протокол - и не предмет парсинга парсером. Это просто пишется в аллоцированый surface как запись в регион памяти. Это вообще не дисплейный сервер как таковой. Согласование регионов для рендера. Surface в принципе может быть и хардварным. У современных контроллеров дисплея - более одного "surface". И есть более специализированые, например, хардварный оверлей для быстрого вывода видео. Архитектура как у вэйланда лучше маппится на такие хардварные реалии. Xorg такими концепциями не оперирует, да и с таймингами операций у него вечно проблемы. > Нужно было настроить на стареньком ноуте графику, и с bumblebee, получился еще > тот квест, железо устаревшее, но еще могет (интел + nvidia). Нвидия стоит здорово особняком. Им в ядре показали чисто технический фак, за некооперативность, и они сами реимплементят подсистему DRM/KMS. Со всеми вытекающими оттуда багами и глюками. Это то что нвидия получила за стояние особняком. Поэтому с ними можно хлебнуть горя а разработчики линуха нвидию терпеть не могут. Сейчас вроде бы нвидия частично пересмотрела подходы - но они нормально в рабочие процессы не интегрированы и в этом очень невыгодно отстают от амд, интел и даже мелких GPU типа mali каких. GLX - вообще так, экстеншн Xorg для согласования параметров окна для non-xorg программ, типа какой-нибудь игры работающей через OpenGL и т.п.. В этом случае основной поток данных в GPU после Mesa идет через libdrm какой, это отдельный клиент подсистемы DRM/KMS, а иксы вообще не у дел - кроме вот начального согласования параметров окна, да может еще чего по мелочи. Поэтому и работает быстро - xorg сам по себе знатный тормоз.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	90. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (5), 04-Фев-24, 20:11
	>>Нвидия стоит здорово особняком. А как с nouveau дела обстоят? Там совсем караул, или для старых карт норм поддержка стала?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Дрататуй (?), 06-Фев-24, 04:18
	Насколько мне известно, могу ошибаться, xFree86 использовался и в больших Униксах. Хорошо бы создать какую-нить энциклопедию по всяким линуксам, в качестве главного архивариуса даже знаю кого назначить. ☺ Это всё равно проще, чем каждый раз набирать один и тот же текст. И да, редактировать неточности можно будет в отличие от многочисленных площадок.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	101. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Zenitur (ok), 10-Фев-24, 11:42
	> Насколько мне известно, могу ошибаться, xFree86 использовался и в больших Униксах. Угу, я почитал описание, паишут что изначально назывался X386 (1991), потом XFree86, и стал стандартом де-факто для всех, включая промышленные Unix-машины. > Хорошо бы создать какую-нить энциклопедию по всяким линуксам, в качестве главного архивариуса > даже знаю кого назначить. ☺ Парфёнова? :-) > Это всё равно проще, чем каждый раз набирать один и тот же > текст. И да, редактировать неточности можно будет в отличие от многочисленных > площадок. Это да. Комменты заретяются с годами. Нужно LOR Wiki возобновить.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от n00by (ok), 10-Фев-24, 14:23
	> В 2008 году появился libxcb. Дело в том, что libX11 был тем > ещё мучением для разработчиков программ (куда хуже WinAPI), и поэтому все > использовали тулкиты - вместо того, чтобы напрямую общаться с libX11. В > libxcb был потенциал. Тогда я и поправлю, раз уж новость ушла с Главной. Xlib и XCB - это, грубо говоря, как блокирующие сокеты и асинхронные. XCB ещё сложнее в использовании, но позволяет исключить некоторые задержки на ожидание ответа сервера. Xlib сейчас реализована как обёртка над XCB.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	104. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Zenitur (ok), 12-Фев-24, 13:07
	> Xlib и XCB - это, грубо говоря, как блокирующие сокеты и асинхронные. > XCB ещё сложнее в использовании, но позволяет исключить некоторые задержки на > ожидание ответа сервера. Xlib сейчас реализована как обёртка над XCB. Буду знать. Оказывается, сложность осталась той же, а XCB, это попытка решить проблему иксов с задержками.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Аноним (10), 02-Фев-24, 02:11
	> Есть какие-нибудь книги статьи попадаются https://bootlin.com/doc/training/graphics/graphics-slides.pdf
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	72. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
	Сообщение от Аноним (72), 02-Фев-24, 23:45
	https://www.baeldung.com/linux/gui
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	73. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
	Сообщение от Аноним (72), 02-Фев-24, 23:46
	Очень хорошо всё расписано
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
	Сообщение от Аноним (-), 04-Фев-24, 13:31
	> Есть какие-нибудь книги статьи которые объясняют как графический стек работает в линуксе? > Что-то кажется неохваченная тема вообще. На саммом концептуальном уровне: Нижний уровень: kernel. Он управляет аллокацией памяти, видеорежимами, вгрузки шейдеров (если есть вычислялки) и чего там еще кернелу уместно делать. Это базовые примитивы для работы с GPU. Это называется KMS (kernel modesetting) и DRM (Direct Rendering Manager). Еще GBM рядом - менеджмент памяти GPU. К этому добру интерфейсится libdrm - вывешивающий более юзермодовым вещам (клиентам DRM/KMS) это добро. Над этим - клиенты DRM/KMS. Wayland, Xorg, OpenGL, Vulkan - это клиенты к вон тому апи, поверх libdrm как правило. Есть ряд иных программ которые могут что-то эдакое без Xorg/Wayland. Например GLMark2 умеет рисовать 3D "в консоли" - будучи клиентом KMS и апи GL без задействования xorg или wayland. Или некоторые видеоплееры - тоже умеют через KMS/DRM рисовать. Без вон тех. Для KMS/DRM есть отображалки и есть считалки. Типовая видеокарта - это и то и другое. Но есть видеокарты без видеовыхода, тогда от них только compute вывешен. Или есть безмозглые контроллеры дисплея - умеющие только долбить RAM на экран. Или произвольная комбинация вот этого всего, что более-менее покрывает все существующие варианты хардвара, даже эмбедовку и прочиа странные штуки.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

9. Скрыто модератором	+4 +/–
Сообщение от Аноним (9), 02-Фев-24, 01:53
Вот смотришь так на этот внушительнейший список изменений и что вообще в принципе mase умеют, и понимаешь что это титаричпский труд. Но когда найдут какую-нить багу с переполнением, то набИгут растаманы и начнут орать, что сишники опять в память не смогли, пора переписать на сами знаете чем. При этом сам критик писать ничего не будет и не умеет, но авторов, к-е сделали этот ченджлист в новости, конечно же, обгадит
Ответить | Правка | Наверх | Cообщить модератору

	13. Скрыто модератором	+/–
	Сообщение от AleksK (ok), 02-Фев-24, 06:24
	Хорошо приплёл. Большинство комментариев про переписать на раст и пишут растохейтеры, чтобы поразжигать. Я вот вообще не особо понимаю эти языковые холивары.
	Ответить | Правка | Наверх | Cообщить модератору

	17. Скрыто модератором	+/–
	Сообщение от Аноним (17), 02-Фев-24, 08:50
	молодой, неопытный
	Ответить | Правка | Наверх | Cообщить модератору

	41. Скрыто модератором	+1 +/–
	Сообщение от Fyjy (-), 02-Фев-24, 13:42
	Вот смотришь на домик в деревне, выкопанный колодец и туалет под вишенками, что деды руками копали, и понимаешь какой это был титаничекий труд! Но когда туда, на подгнивших досках всего один раз(!) провалишься, набигут снежинки и начнут орать, что опять криво построили и надо переделать. Вообще перестали уважать труд прошлых поколений, хотят водопровод и канализацию(( Им видите ли, попа на морозе к сидушке примерзает! Не понимают они счастья, смотреть на поднимающийся пар, после хорошо сделанного дела. При этом сам критик строить ничего не будет и не умеет, возьмет и наймет строителей или даже строительную компанию, такие только критиковать горазды.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

15. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+1 +/–
Сообщение от Аноним (15), 02-Фев-24, 08:20
https://archive.fosdem.org/2023/schedule/event/graphics_a_fr.../ вот отличная презентация от Daniel Stone как работает графика в Linux
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+/–
Сообщение от Аноним (66), 02-Фев-24, 18:15
Пытался во фряхе накатить месу, но в пакетах только меса-девел, которая начинает искать девел-версии дров, которых нет (кмод, встройка интел атом). Как воевать?
Ответить | Правка | Наверх | Cообщить модератору

70. "Релиз Mesa 24.0, свободной реализации OpenGL и Vulkan "	+2 +/–
Сообщение от Аноним (70), 02-Фев-24, 21:06
ясно, понятно. на Raspberry Pi 4 как всегда нормальный драйвер vulkan так и не шмогли. с такими особенностями, уролог тогда тоже этим разрабам не поможет.
Ответить | Правка | Наверх | Cообщить модератору

	71. Скрыто модератором	+/–
	Сообщение от Аноним (71), 02-Фев-24, 21:47
	Там же нет DXVK ввиду отсутствия винды на ARM. Значит, и запускать там особо нечего...
	Ответить | Правка | Наверх | Cообщить модератору

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

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