The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Активность в разработке сервера X.org достигла минимума с 2003 года, opennews (??), 31-Дек-22, (0) [смотреть все]

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


27. "Активность в разработке сервера X.org достигла минимума с 20..."  –17 +/
Сообщение от Skullnetemail (ok), 31-Дек-22, 15:02 
Это нужно чтобы NVidia поднимала жопу и делала поддержку HDR в драйверах. А пока что у NVidia полгода занимает чтобы пофиксить небольшой баг с неработающей выгрузкой текстур, который появился в последней версии. Нах*й NVidia не сдался ваш линукс.
Ответить | Правка | Наверх | Cообщить модератору

30. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 31-Дек-22, 15:05 
А причём тут Nvidia?
Ну Intel и AMD бы показали класс с реализацией HDR для иксов, но у них тоже шиш.
Ответить | Правка | Наверх | Cообщить модератору

36. "Активность в разработке сервера X.org достигла минимума с 20..."  –17 +/
Сообщение от Skullnetemail (ok), 31-Дек-22, 15:15 
При том, что у неё доминирующее положение на рынке, а потом в mesa драйверах остальные подтянутся. Иначе получается ситуация как с Gallium nine, который был на фиг никому не нужен, потому что не работал на проприетарной NVidia, да и, честно говоря, не у всех нормально работал даже на AMD.
Ответить | Правка | Наверх | Cообщить модератору

41. "Активность в разработке сервера X.org достигла минимума с 20..."  +1 +/
Сообщение от iPony129412 (?), 31-Дек-22, 15:22 
Да как-то под линуксами у AMD, Nvidia, Intel — примерно равномерно по трети.

У Nvidia со встройками плохо, поэтому тут у Intel тоже сильные позиции. Встройка тоже HDR может — тут не нужна печка на 1000 ватт, чтобы HDR кино показать.

Ответить | Правка | Наверх | Cообщить модератору

43. "Активность в разработке сервера X.org достигла минимума с 20..."  +1 +/
Сообщение от iPony129412 (?), 31-Дек-22, 15:25 
Причём, что Intel, что AMD криво-косо но как-то всё-же имеют VAAPI для линуксов, и есть поддержка криво-косая в браузерах.

И Nvidia тут не причём. Красиво делай — красиво будет.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

83. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 17:50 
> Причём, что Intel, что AMD криво-косо но как-то всё-же имеют VAAPI для
> линуксов, и есть поддержка криво-косая в браузерах.

Что интересно они и VDPAU умеют :). Де факто почти все открытые дрова вывешивают и VDPAU и VAAPI, там, вроде, врапперы какие-то есть которые из одного другое могут сделать довольно халявно.

Ответить | Правка | Наверх | Cообщить модератору

90. "Активность в разработке сервера X.org достигла минимума с 20..."  –1 +/
Сообщение от iPony129412 (?), 31-Дек-22, 18:15 
Ни Chromium, ни Firefox не умеют в VDPAU.

Если тут там напишешь и подцепишь прослоек и переходников — это не меняет.
Это уже твоя самодеятельность за пределами браузера.

Ответить | Правка | Наверх | Cообщить модератору

104. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 18:58 
> Ни Chromium, ни Firefox не умеют в VDPAU.

Зато куча плееров умеет. А в хромиуме и файрфоксе битрейты не такие чтобы этим всем всерьез париться. Ну как, 50 Мбит тяжелым кодеком - проц уже напрягаться начинает. Но в интернете тебе столко грузить всех жаба удушит. Однако вон там, в качественно кодированом мувике...

> Если тут там напишешь и подцепишь прослоек и переходников — это не меняет.
> Это уже твоя самодеятельность за пределами браузера.

Да оно в браузере не настолько уж и критично как в жирных фильмах с тяжелыми кодеками с конским битрейтом.

Ответить | Правка | Наверх | Cообщить модератору

183. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 01-Янв-23, 08:10 
> Да оно в браузере не настолько уж и критично как в жирных фильмах с тяжелыми кодеками с конским битрейтом

Даже VP9 в 4К на ноутбуке — это не просто, естественно, чтобы это не выло, и батарея 🪫 не улетала. AV1 так вообще.

Ответить | Правка | Наверх | Cообщить модератору

199. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 01-Янв-23, 15:52 
> Даже VP9 в 4К на ноутбуке — это не просто,

Да там битрейт довольно скромный.

> естественно, чтобы это не выло, и батарея 🪫 не улетала.

А у тебя ноут, с большим и клевым 4К экраном, где ты сможешь это от 1080 отличить? Ну или в какой ситуации 4К на именно батарее имеет место?

> AV1 так вообще.

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

Ответить | Правка | Наверх | Cообщить модератору

200. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 01-Янв-23, 16:05 
> битрейт скромный

заладило на битрейт, оно не имеет связи к нагрузке на CPU.
одинаково качество видео в h.264 и AV1 будет иметь битрейт сильно ниже во втором случае, как и сильно выше нагрузку на CPU.

> А у тебя ноут, с большим и клевым 4К экраном, где ты сможешь это от 1080 отличить?

Не с огромным, но видно.
Так что разница есть, так что к чему эти "без всего можно и как-то будет работать"

Ответить | Правка | Наверх | Cообщить модератору

207. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 01-Янв-23, 18:48 
> заладило на битрейт, оно не имеет связи к нагрузке на CPU.

А я то думал что чем больше данных декодировать, и чем тяжелее кодек был, тем дольше процессор будет жевать эти данные тем алгоритмом. Попробуй-ка эту логику оспорь? От разрешения самого по себе зависит разве что loop filter и прочий постпроцессинг, в современном кодеке далеко не главное по потреблению CPU.

> одинаково качество видео в h.264 и AV1 будет иметь битрейт сильно ниже
> во втором случае, как и сильно выше нагрузку на CPU.

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

> Не с огромным, но видно.

Ну конечно 1080 -> 4K немного заметно будет.

> Так что разница есть, так что к чему эти "без всего можно и как-то будет работать"

Да я к тому что интернетный битрейт всяко подразумевает компромисс в качестве картинки и артефактах сжатия. Для идеальной передачи 4K картинки даже с AV1 надо все же побольше битрейта накинуть чем то что гугл в принципе готов с своих серверов условно-бесплатно тебе наливать. Им бандвиз денег стоит, это их топовая статья расходов, поэтому уж как есть. И это одна из причин по которым им нравятся эффективные кодеки. Шкурный интерес.

Ответить | Правка | Наверх | Cообщить модератору

135. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от barmaglot (??), 31-Дек-22, 20:49 
VAAPI obsolete ...
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

156. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Skullnetemail (ok), 31-Дек-22, 22:04 
Я жду когда сделают поддержку vp9 и h264 в Vulkan, тогда VA-API будет официально не нужен.
Ответить | Правка | Наверх | Cообщить модератору

166. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 23:05 
> Я жду когда сделают поддержку vp9 и h264 в Vulkan, тогда VA-API
> будет официально не нужен.

Уже толи комитнули, толи на грани.

Ответить | Правка | Наверх | Cообщить модератору

201. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 01-Янв-23, 16:08 
> Уже толи комитнули, толи на грани.

полгода ориентировочно грань эта, ещё и с адаптацией добавляй

Ответить | Правка | Наверх | Cообщить модератору

60. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 16:23 
> При том, что у неё доминирующее положение на рынке, а потом в
> mesa драйверах остальные подтянутся.

Вы что-то сильно перепутали в этой жизни, в линуксе нвидия уже давно тренды не задает и находится в догоняющих за командой делающей интерфейсы DRM/KMS/GBM. Реализуя вот это все как у них, но сами - и с большим отставанием.

Линуксным разработчикам пофиг на пользователей проприетари. Они не позволят пропретарщику диктовать системные интерфейсы. А в конкретно иксах проблема в том что вся их начинка не заточена ни на HDR, ни на FreeSync, ни на иные современные фичи. Кодить такие вещи для иксов требует мощные рефакторы по всей площади, а там такой жуткий код что трогать ЭТО никто не хочет. О чем и сабж.

> на проприетарной NVidia, да и, честно говоря, не у всех нормально работал даже на AMD.

Похоже на каие-то песни юзера нвидии с проприетарным драйвером. А знаете что? Вы вообще не часть Linux такие красивые. Сами там с своей нвидией в своей гадюшне и разбирайтесь. На вас все забили, уж извините но якорить разработку вам все же не дадут.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

32. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 31-Дек-22, 15:08 
Причём Nvidia хоть как-то пыталась и думала на тему HDR для иксов

https://www.phoronix.com/news/NVIDIA-HDR-Linux-Lacking

От AMD и Intel я такого не припомню даже.

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

38. "Активность в разработке сервера X.org достигла минимума с 20..."  –12 +/
Сообщение от Skullnetemail (ok), 31-Дек-22, 15:17 
Думала и передумала, NVidia линукс драйвера делаются по остаточному принципу. Учитывая низкую распространённость самого HDR и так себе поддержку даже в Windows. Делайте выводы.
Ответить | Правка | Наверх | Cообщить модератору

55. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 16:08 
> Думала и передумала, NVidia линукс драйвера делаются по остаточному принципу.

Не так. Линуксоиды нвидию достаточно сильно нагнули в благодарность за некооперативность и им было чем заняться поважнее HDR. Ну там кодингом DRM/KMS а потом и GBM, это довольно здоровые и фичастые штуки, без них до HDR дело просто не дойдет в принципе, а темпы впахивания вон той команды в ядре - ударные, нвидия едва поспевает с лагом в месяцы.

Нвидию видите ли HPC интересовал и все такое, и они там чего-то вылетать стали в последнее время. Тут они как-то сильно податливее стали, даже сорц драйвера вывалили. Однако на свое горе они так и не поняли некоторые вещи. Еще парочка гигабаксовых контрактов которые получит амд и нвидия таки либо поймет, либо начнет свой длинный и нелегкий путь к банкротству фирмы, как им там удобнее.

> Учитывая низкую распространённость самого HDR и так себе поддержку даже в Windows.
> Делайте выводы.

Мы уже сделали выводы: у нвидии сейчас вообще довольно много неудач. Технологически их жмет амд, HPCшники тоже на амд переходят, а вот эти с линуксом нормально интегрированы.

Ответить | Правка | Наверх | Cообщить модератору

221. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (221), 02-Янв-23, 15:39 
https://indico.freedesktop.org/event/2/contributions/56/atta...
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

222. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 02-Янв-23, 16:04 
> AMD 2022 Wayland HDR

имелось в виду про иксы в прошлом конечно.

Ответить | Правка | Наверх | Cообщить модератору

52. "Активность в разработке сервера X.org достигла минимума с 20..."  +1 +/
Сообщение от Аноним (-), 31-Дек-22, 16:02 
> Это нужно чтобы NVidia поднимала жопу и делала поддержку HDR в драйверах.

При чем тут нвидия? В линуксе есть DRM/KMS и GBM, это де факто новый низкоуровневый стандарт интерфейса к видеодровам. Нвидию в конечном итоге жизнь заставила вывешивать эти интерфейсы. Как впрочем и другие ос стали это делать. Почему-то.

> А пока что у NVidia полгода занимает чтобы пофиксить небольшой баг с неработающей
> выгрузкой текстур, который появился в последней версии.

У нвидии много других технических проблем. Им в ядре линукса показали средний палец еще и технически, повесив на KMS, DRM и GBM от таких как они GPL_ONLY. Им пришлось кодить аналоги самостоятельно. За теми темпами кодинга они не успевают, поэтому драйвер лагает на месяцы и радует юзерей глюками. Про GBM нвидия несколько лет ныла "давайте новый менеджер памяти сделаем, с учетом нас". Но всем остальным GBM был нормальненько, так что нвидия с этой инициативой осталась в гордом одиночестве.

> Нах*й NVidia не сдался ваш линукс.

Они там видите ли на несколько контрактов пролетели в гигабаксовых интервалах. Так даже им понятнее, когда топ500 начинает в верхних строчках занимать почему-то АМД. Тут нвидия и драйвер в опенсорс вываливает, добрая какая, и что там еще. Но им там видимо не сказали что в линукс не берут код "с лопаты".

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

57. "Активность в разработке сервера X.org достигла минимума с 20..."  –12 +/
Сообщение от Skullnetemail (ok), 31-Дек-22, 16:19 
> При чем тут нвидия? В линуксе есть DRM/KMS и GBM, это де факто новый низкоуровневый стандарт интерфейса к видеодровам. Нвидию в конечном итоге жизнь заставила вывешивать эти интерфейсы. Как впрочем и другие ос стали это делать. Почему-то.

Потому что именно видео драйвер отправляет метаданные и формат пикселей на монитор. В иксах то уже есть deep color (10bit). Нужно будет, сделаем и 12bit, и 16bit. Фреймбуфер это просто сырой набор пикселей, а функции для работы с определённым форматом сделать легко.

> У нвидии много других технических проблем. Им в ядре линукса показали средний палец еще и технически, повесив на KMS, DRM и GBM от таких как они GPL_ONLY. Им пришлось кодить аналоги самостоятельно. За теми темпами кодинга они не успевают, поэтому драйвер лагает на месяцы и радует юзерей глюками. Про GBM нвидия несколько лет ныла "давайте новый менеджер памяти сделаем, с учетом нас". Но всем остальным GBM был нормальненько, так что нвидия с этой инициативой осталась в гордом одиночестве.

NVidia всегда были мудаками при работе с Linux-сообществом, вместо того, чтобы реализовать GBM, они выкатили какой-то EGLStreams, потому что им нужно сохранить свой драйвер пропериетарным. AMD и Intel не имеет таких проблем, потому что они были дружелюбны к Linux-сообществу. В особенности Intel.

> Они там видите ли на несколько контрактов пролетели в гигабаксовых интервалах. Так даже им понятнее, когда топ500 начинает в верхних строчках занимать почему-то АМД. Тут нвидия и драйвер в опенсорс вываливает, добрая какая, и что там еще. Но им там видимо не сказали что в линукс не берут код "с лопаты".

NVidia пока что открыла только исходный код модулей ядра, который почти бесполезен, потому что основная вещь - это user-space часть драйвера и firmware. Пока что эти открытые модули ядра нормально не заводятся. У меня, например, работают только проприетарные версии модулей. И то, NVidia сделала это, только потому что её вынудили, украв исходники всего драйвера и выложив в свободный доступ (FOSS aka Forced Open Source Software).

Ответить | Правка | Наверх | Cообщить модератору

80. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 17:36 
> Потому что именно видео драйвер отправляет метаданные и формат пикселей на монитор

Это очень упрощенная картина мира. Воообще, поддерживаться должно всей инфраструктурой по всей площади, счастье наступит только тогда. И иксы в этом плане одна из наиболее мучительных штук во всем стеке. Поэтому с ними никто и не хочет связываться.

> В иксах то уже есть deep color (10bit). Нужно будет, сделаем
> и 12bit, и 16bit. Фреймбуфер это просто сырой набор пикселей, а
> функции для работы с определённым форматом сделать легко.

Иксы довольно хреновый фреймбуфер. Или точнее, большой кусок медленного и мешаюшегося кода на пути к нему. Ну а нвидия - на своей волне и не интегрирована в остальную инфраструктуру. Она не ориентир для разработчиков линукса, ее там терпеть не могут. Нвидию никто не учитывает, вон с EGL или заменой GBM - не прокатили инициативы. Девы решили что это проблемы нвидии и их кастомеров и дружно забили. Что хотите то и делайте. Эти экземпляры просто не клиенты линуксных девов. Unsupported configuration. С tainted kernel-ом - вы САМИ копаетесь. Нидиафаны могут хоть на ушах стоять но это не изменится, модель разработки KMS/DRM/GBM другая. А, теперь еще и подсистемы "акселераторов". KMSники всяко разнесли рисовалки и считалки, коллегам захотелось ту инфраструктуру и для совсем-не-рисовалок, типа акселераторов AI. На горизонте нвидии все больше туч. А фирма нокия показала как можно быстро перестать быть лидером рынка.

> NVidia всегда были мyдаками при работе с Linux-сообществом, вместо того, чтобы реализовать
> GBM, они выкатили какой-то EGLStreams, потому что им нужно сохранить свой
> драйвер пропериетарным.

Потом они начали осознавать что это никому не надо и стали новую тему двигать - а давайте сделаем новый менеджер памяти, вместо GBM, чтобы еще и нам удобно было?! Как несложно понять, остальные участники разработки адаптировали GBM под себя, им и так нормальненько. Так что и это тоже не прокатило.

> AMD и Intel не имеет таких проблем, потому что они были дружелюбны к Linux-сообществу.
> В особенности Intel.

Они сообща делают некий core. А кроме них сейчас есть много кого еще. Ну вон tinyDRM для мелочи был по сути ассимилирован и стал в общем то просто набором хелперов для всех кому что-то такое надо, а не чем-то совсем отдельным. Очень забавная подсистема где стыкуются интересы множества вендоров, железок и проч.

> NVidia пока что открыла только исходный код модулей ядра, который почти бесполезен,
> потому что основная вещь - это user-space часть драйвера и firmware.

Ну, как, там наверное можно посмотреть самые болезненные топики типа выполнения реклока. Фирмвары (подписаные) они вроде стали изредка релизить для нувы. Но в целом это все "too little and too late".

> Пока что эти открытые модули ядра нормально не заводятся.

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

> У меня, например, работают только проприетарные версии модулей. И то, NVidia сделала это,
> только потому что её вынудили, украв исходники всего драйвера и выложив
> в свободный доступ (FOSS aka Forced Open Source Software).

Ну а я вот покупаю по этому поводу амдшки. Дабы иметь возможность гонять свежие ядра, вплоть до -rc и плотно трекать статус майнлайна. Это мне надо по куче других причин, просто когда он такой еще и на лично моем десктопе, я как-то сильно заинтересованнее в его качестве оказываюсь, и это - специальное решение, подталкивающее меня заботиться о качестве этой щтуки на всех мыслимых уровнях. Иначе и меня подгорает - и я быстро и круто решаю эту проблему. Взамен я получаю годный кернел для моих затей, с минимумом сюрпризов.

Ответить | Правка | Наверх | Cообщить модератору

78. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Kuromi (ok), 31-Дек-22, 17:18 
Ну да, их последний драйвер конечно был шикарно протестирован - сломал vaapi враппер, сломал аппаратное ускорение в MPV, зато говорят от EGLStreams избавились (?)
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

81. "Активность в разработке сервера X.org достигла минимума с 20..."  +1 +/
Сообщение от Аноним (-), 31-Дек-22, 17:47 
> Ну да, их последний драйвер конечно был шикарно протестирован - сломал vaapi
> враппер, сломал аппаратное ускорение в MPV, зато говорят от EGLStreams избавились (?)

Ну а смысл EGLStreams таскать если кроме нвидии это никому не надо вышло? :)

Ответить | Правка | Наверх | Cообщить модератору

86. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Kuromi (ok), 31-Дек-22, 17:56 
>> Ну да, их последний драйвер конечно был шикарно протестирован - сломал vaapi
>> враппер, сломал аппаратное ускорение в MPV, зато говорят от EGLStreams избавились (?)
> Ну а смысл EGLStreams таскать если кроме нвидии это никому не надо
> вышло? :)

Все так, но как можно было так лихо "почистить кид", чтобы поломать аппаратное ускорение? Это намекает что тестируют там соотвественно. Причем сломали похоже серьезно, т.к. хотфикс по горячим следам не вышел.

Ответить | Правка | Наверх | Cообщить модератору

107. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (-), 31-Дек-22, 19:00 
У них много других проблем в данный момент. Начиная с того что амд их лихо выпер из HPC, и заканчивая тем что DRM/KMS а теперь и GBM дико глючные и следующие пару лет им будет чем заняться, соревнуясь с большой и эффективной тимой Linux Kernel в вон тех подсистемах. А за это время вон те еще отэволюционируют подсистему.. и .. ну вы там с вашей нвидией сами как нибудь разбирайтесь. Это ваши с ними отношения. К линуксу все это отношения не имеет.
Ответить | Правка | Наверх | Cообщить модератору

150. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Kuromi (ok), 31-Дек-22, 21:35 
> У них много других проблем в данный момент. Начиная с того что
> амд их лихо выпер из HPC, и заканчивая тем что DRM/KMS
> а теперь и GBM дико глючные и следующие пару лет им
> будет чем заняться, соревнуясь с большой и эффективной тимой Linux Kernel
> в вон тех подсистемах. А за это время вон те еще
> отэволюционируют подсистему.. и .. ну вы там с вашей нвидией сами
> как нибудь разбирайтесь. Это ваши с ними отношения. К линуксу все
> это отношения не имеет.

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

Ответить | Правка | Наверх | Cообщить модератору

154. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (154), 31-Дек-22, 22:00 
Ну да. Судя по дампу сорца модуля ядра до них даже что-то стало доползать. Но видимо too little and too late - это про них. Зажирак корпорации часто предшествует падению. Нокия подтвердит.
Ответить | Правка | Наверх | Cообщить модератору

89. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (89), 31-Дек-22, 18:13 
почему-то эксперты-системные программисты с opennet не торопятся делать HDR для открытых драйверов nouveau, amd, intel
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

136. "Активность в разработке сервера X.org достигла минимума с 20..."  –1 +/
Сообщение от Анонн (?), 31-Дек-22, 20:53 
К чему эти рассуждения если есть тикет на добавление HDR.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1037
Где разраб иксом черным по белому пишет что добавлять их не будет. И даже уточняет почему.
А не лепит отмазки что "это нвидия должна делать", "это интел должен делать".
Поэтому если HDR и будет, то только в xwayland.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

169. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от Аноним (169), 31-Дек-22, 23:33 
там сказано что добавлять их будут ПОСЛЕ добавления в драйвера и скорей всего после появления в вяленом.
Ответить | Правка | Наверх | Cообщить модератору

178. "Активность в разработке сервера X.org достигла минимума с 20..."  +/
Сообщение от iPony129412 (?), 01-Янв-23, 05:29 
Нет.

> There's been some discussion of a "deep color" protocol extension to enable X clients to send HDR content to the server, which would be a prerequisite. And then you'd have to actually wire that support into your display driver

Первым стоит вопрос про расширение в иксах. Это про предложенный и непринятый черновик от Nvidia.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру