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

"Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании"	+/–
Сообщение от opennews (??), 23-Фев-24, 23:29
При  обсуждении ошибки, связанной с относительно высоким по сравнению с Windows потреблением электроэнергии на APU AMD с поддержкой аппаратного декодирования видео, инженер из AMD, Алекс Дойкер (Alex Deucher, основной разработчик драйвера amdgpu), признал, что отображение видео в Linux в принципе неэффективно... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60656
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Инженер из AMD признал, что графический стек Linux нуждается..."	+20 +/–
Сообщение от Аноним (1), 23-Фев-24, 23:29
Wayland придёт, порядок наведёт?
Ответить | Правка | Наверх | Cообщить модератору

	2. "Инженер из AMD признал, что графический стек Linux нуждается..."	+7 +/–
	Сообщение от dannyD (?), 23-Фев-24, 23:34
	это был сарказм (?)
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Инженер из AMD признал, что графический стек Linux нуждается..."	+9 +/–
	Сообщение от Аноним (4), 23-Фев-24, 23:38
	Да хоть бы кто-нибудь пришёл, займёшься?
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Инженер из AMD признал, что графический стек Linux нуждается..."	+3 +/–
	Сообщение от dannyD (?), 24-Фев-24, 10:09
	тебе надо - сам займись. меня и Х и консоль устраивает.
	Ответить | Правка | Наверх | Cообщить модератору

	208. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 24-Фев-24, 21:54
	> тебе надо - сам займись. > меня и Х и консоль устраивает. Во, збс, у нас тут майнтайнер на иксы походу нашелся, когда тима эйрли его в утиль окончательно спишет. Или предлагай услуги по майнтенансу, тебя там очень ждут.
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:08
	>> тебе надо - сам займись. >> меня и Х и консоль устраивает. Во, отлично, у нас тут видимо майнтайнер на иксы нашелся, когда тима эйрли их в утиль окончательно спишет. Иди предлагай услуги по майнтенансу, они тебя очень ждут.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	273. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от dannyD (?), 25-Фев-24, 21:11
	>>Иди предлагай вот и иди .!..
	Ответить | Правка | Наверх | Cообщить модератору

	284. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (-), 26-Фев-24, 05:19
	>>>Иди предлагай > вот и иди .!.. Так это не мне надо, чудак. Мне все равно что с иксами случится. Я не буду скучать по этой свалке костылей и коду с testimonials вида "80 000 строк боли!" от фиксера, уж прости.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Инженер из AMD признал, что графический стек Linux нуждается..."	+22 +/–
	Сообщение от Аноним (50), 24-Фев-24, 01:53
	Ой, чейт все больше ощущение что вяленд почи такая же хрень как и иксы. В добавок еще и сыроватая.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	140. "Инженер из AMD признал, что графический стек Linux нуждается..."	+6 +/–
	Сообщение от Аноним (140), 24-Фев-24, 09:55
	Иксы решали сугубо свои задачи и в юникс-мире в целом всех устраивали. Но поскольку линукс — не юникс и даже не полноценный posix, а всего лишь нагромождение костылей без чёткого направления решаемых задач, то и иксы там живут как костыль в море. Вяленд делают именно с расчётом на линукс, игнорируя всех остальных, но его ещё делать и делать, он сам архитектурно плох и всё равно будет существовать в условиях мутирующих костылей.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Инженер из AMD признал, что графический стек Linux нуждается..."	–3 +/–
	Сообщение от Аноним (-), 24-Фев-24, 21:52
	> Иксы решали сугубо свои задачи и в юникс-мире в целом всех устраивали. Только этот юникс мир перестал всех устраивать - и бесславно сдох. А так все хорошо, прекрасная маркиза. > Но поскольку линукс — не юникс Вообще-то как минимум 1 из линухов был вот именно сертифицирован как юникс. Что иронично по многим параметрам, но так можно было. > и даже не полноценный posix, И сейчас нам эксперты покажут позикс полноценнее? :) > а всего лишь нагромождение костылей без чёткого направления решаемых задач, > то и иксы там живут как костыль в море. Иксы не вписываются в современную графическую архитектуру. By design. На самом фундаментальном уровне. > Вяленд делают именно с расчётом на линукс, игнорируя всех остальных, А они самоустранились из процесса и - вот - пиндят что их все устраивает. Ну раз все устраивает - пусть и сидят со своими костяшками, например? > но его ещё делать и делать, он сам архитектурно плох и всё равно будет > существовать в условиях мутирующих костылей. Архитектурно он маппится на современный хардвар на порядок лучше иксов. Одно это уже ломовое улучшение. А иксы это та кобыла, которая умерла. Все хорошо, прекрасная маркиза. Правда свои типа-юниксы вы тоже - профакали.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от iZEN (ok), 25-Фев-24, 12:27
	> Архитектурно он маппится на современный хардвар на порядок лучше иксов. Одно это > уже ломовое улучшение. А иксы это та кобыла, которая умерла. Все > хорошо, прекрасная маркиза. Правда свои типа-юниксы вы тоже - профакали. User294, хватит шифроваться под Анонима.
	Ответить | Правка | Наверх | Cообщить модератору

	270. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 25-Фев-24, 20:22
	> User294, хватит шифроваться под Анонима. Вау, Изен! Живой, собственной персоной. Ну, раз ты пришел, то можешь похвастаться что ты там не профакал. Вот лично ты как поспособствовал улучшению графики в своей системе, и почему это было круто. Если будешь убедителен, я и признать неправоту насчет профака систем могу :) Знаешь чем мы отличаемся? Я пришел к вон тем. И мы сообща гасили баги импактившие меня. Это было кайфово и круто, а бонусом я вообще смог посмотреть что за тима, что может, какие там у них challenges, куда двигаются, почему - так. Поэтому я доверю определять мое будущее - им. А не вон тем топилам за иксы рассказывающим что там мне якобы не нужно, что суть хамство.
	Ответить | Правка | Наверх | Cообщить модератору

	304. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от гыгы (?), 26-Фев-24, 16:12
	ты там забыл отчитаться о разгромной победе btrfs везде и еще кучу разного бреда про одноплатники давно не пишешь, заболел или немного (но не достаточно пока еще) поумнел?
	Ответить | Правка | Наверх | Cообщить модератору

	318. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 19:41
	> ты там забыл отчитаться о разгромной победе btrfs везде Это к графону в линухе не относится. Но так то, когда вы в проде FB обслуживаете миллиарды, а WD приходит, нанимает тушек, комитит вам поддержку своих накопителей, и все такое - очевидно, авторы ФС все правильно сделали и надо продолжать в том же духе. > и еще кучу разного бреда про одноплатники давно не пишешь, заболел или > немного (но не достаточно пока еще) поумнел? С таким бы ником да про интеллект то рассуждать... :)
	Ответить | Правка | Наверх | Cообщить модератору

	317. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от iZEN (ok), 26-Фев-24, 19:24
	> Ну, раз ты пришел, то можешь похвастаться что ты там не профакал. Я забил на графику от AMD — я не смог завести интеграшку AMD760 на последних версиях драйверов серии xf86-video-ati. Это для меня оказалось поистине непосильной задачей. Intel и AMD наконец-то добились своей цели: пользователи бессильны перед их выкрутасами с DRI/KMS ради поддержки Wayland. А что там у тебя с победой Btrfs? Оно ещё живо?
	Ответить | Правка | К родителю #270 | Наверх | Cообщить модератору

	330. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 05:56
	>> Ну, раз ты пришел, то можешь похвастаться что ты там не профакал. > Я забил на графику от AMD — я не смог завести интеграшку > AMD760 на последних версиях драйверов серии xf86-video-ati. Это для меня оказалось > поистине непосильной задачей. Intel и AMD наконец-то добились своей цели: пользователи > бессильны перед их выкрутасами с DRI/KMS ради поддержки Wayland. Да это какие-то ваши локальные BSDпроблемы, я какой-то винтажный радеон HD, типа 1300 чтоли в линухе без проблем завел. Возможно, не стоило самоустраняться из процесса и горлопанить что вас все и так устраивает? И мне казалось что ща drm/kms в бсде наоборот лучше стал. Это ложное ощущение? А еще 99% что ты не хотел "xf86-video-ati", чудак. Ты хотел generic KMS на стороне иксов как DDX, имхо. Как большая часть дистров линя. DDX это такой кусок крапа что там "акселерация" не стоит боли. Чаще получается тормозизация и глюкизация, ибо архитектура современных GPU vs иксы это как гамно из пуль, но бонусом еще багов немеряно. Ты видимо не понимаешь структуру этого стека и изменение парадигм, откуда твои проблемы и лезут. Не, иксы более не центр вселенной. И все что выводило графику быстро для начала не рисует ее через иксы и DDX, да и тот DDX не особо хуже атевого. > А что там у тебя с победой Btrfs? Оно ещё живо? У меня целый небольшой флот одноплатников на этом. Около пары сотен юнитов суммарно. Работает, куле. Но по сравнению с FB где оно обслуживает миллиард юзерей это фигня.
	Ответить | Правка | Наверх | Cообщить модератору

	357. Скрыто модератором	+/–
	Сообщение от iZEN (ok), 12-Мрт-24, 21:14
	>> А что там у тебя с победой Btrfs? Оно ещё живо? > У меня целый небольшой флот одноплатников на этом. Около пары сотен юнитов > суммарно. Работает, куле. Но по сравнению с FB где оно обслуживает > миллиард юзерей это фигня. На вот почитай для разнообразия: https://overclockers.ru/blog/Hard-Workshop/show/143538/poche...
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Xo (?), 24-Фев-24, 10:49
	Пятой точкой чуешь? А если верхний мозг включить?
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	164. "Инженер из AMD признал, что графический стек Linux нуждается..."	+3 +/–
	Сообщение от Аноним (164), 24-Фев-24, 12:48
	Да ну, ты хочешь сказать что графический сервер, который пилят уже 15 лет и который без примочек умеет лишь в простые геометрические фигуры - ХРЕНЬ?
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	187. "Инженер из AMD признал, что графический стек Linux нуждается..."	+3 +/–
	Сообщение от некая_ычанька (?), 24-Фев-24, 15:43
	>сыроватая Сыровяленая.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	329. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (329), 27-Фев-24, 04:59
	Все гораздо хуже. Вялый еще большая хрень. NIH-синдром, вагон не совместимых с друг другом реализаций, отсутствие понимания что должно получиться в конце и, как следствие, костылинг всего и вся. Лучший вариант — закопать вяленого, учесть шишки от граблей и запилить вменяемый X12. Десяток лет писания оного старые добрые иксы вполне себе протянут.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	52. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (-), 24-Фев-24, 02:07
	> Wayland придёт, порядок наведёт? Забавно, но ты прав. Иксы, в силу своей убогости, не могут так как вейланд: "It's generally not possible to use multiple planes in X, so this would be wayland only."
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

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

	201. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Chel (?), 24-Фев-24, 20:45
	Это вообще-то набор протоколов
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Илья (??), 24-Фев-24, 21:43
	А в каких дистрибутивах сейчас вейленд не по-умолчанию?
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	209. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (209), 24-Фев-24, 21:57
	Fedora
	Ответить | Правка | Наверх | Cообщить модератору

	347. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Dima (??), 28-Фев-24, 11:16
	В Федоре вайланд давно по умолчанию.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (125), 24-Фев-24, 08:19
	> Wayland не могут работать Забавно, но нет.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	78. "Инженер из AMD признал, что графический стек Linux нуждается..."	+14 +/–
	Сообщение от Аноним (-), 24-Фев-24, 03:40
	> Wayland придёт, порядок наведёт? Он может. Потому что архитектурно он сделан так как работает железо. Он менеджер буферов-surface'ов по сути. Это именно то что надо чтобы воооооон то получить. Surface flinger и проч - под видео выделяет отдельный хардварный surface, который сразу в YUV - и эта штука сейчас есть и в мобильных GPU, и в десктопных. На wayland это не особо сложно приделать, это логично маппится на его архитектуру согласования буферов. Просто приделать какое-то расширение когда прога может согласовать не абы что и через композитор а хардварный surface под видео, и все завертится. Более того - железо умеет обычно слеплять несколько поверхносстей до того как в провод выстрелить и проч. Так что видео может быть как бы оверлеем, или над ним можно отрисовать оверлей, но при том для плеера это весьма тупая долбежка в хардварный surface, не жрущая проц. ...ну а Xorg - он вообще такими концепциями не оперирует и страшно далек от этого всего. Там динозавры на переходе удивленно смотрят на мамонта - что это за инноватор в шкуру вырядился?!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	133. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (133), 24-Фев-24, 09:33
	> ...ну а Xorg - он вообще такими концепциями не оперирует и страшно далек от этого всего. Там динозавры на переходе удивленно смотрят на мамонта - что это за инноватор в шкуру вырядился?! Извини, но это чушь. В Иксах черт знает с каких времен есть расширение XVideo с поддержкой аппаратных YUV сурфейсов. То, что оно работает не со всеми дровами - это вопрос к производителям самих дров (и к автору новости, который написал, что в Иксах это якобы невозможно). https://people.freedesktop.org/~mslusarz/nouveau-wiki-dump/X... > XVideo is an X server extension introduced by XFree86 4.x. This extension provides access to hardware accelerated color space conversion and scaling
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Инженер из AMD признал, что графический стек Linux нуждается..."	+3 +/–
	Сообщение от Аноним (-), 24-Фев-24, 10:47
	> Извини, но это чушь. В Иксах черт знает с каких времен есть расширение XVideo с поддержкой аппаратных YUV сурфейсов. Ну-ну, а разве иксы могут в несколько planes, ну и чтобы часть из них были YUV, а часть RGB? Расскажи нам и вон тому чуваку из АМД, может мы все просто не в курсе!
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (-), 24-Фев-24, 22:33
	> Ну-ну, а разве иксы могут в несколько planes, ну и чтобы часть > из них были YUV, а часть RGB? > Расскажи нам и вон тому чуваку из АМД, может мы все просто не в курсе! А это как раз тот самый инноватор который в волосатую шкуру на переходе вырядился, пытаясь доказать дино что они устарели :)
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (238), 25-Фев-24, 02:37
	> Ну-ну, а разве иксы могут в несколько planes, ну и чтобы часть из них были YUV, а часть RGB? Не совсем понял, а как оно сейчас работает? Ну если у тебя медиаплеер делает окошко с opengl и собирается шейдерами (или вообще на CPU) конвертить yuv->rgb, то причем тут XVideo? Если плеер выводит через XVideo, то оно и выводится через хардверный конвертер нужного yuv-цветового пространства в RGB. Это и есть аппаратное ускорение XVideo. Несколько окон плееров можно открыть и в каждом окне выводится своё видео - хочешь в yuy2, хочешь в yv12, в чем хочешь выводит. Скриншотится чёрный (синий) экран, видео идёт в обход экранного буфера X11. В окне просто "дырка" цветом XVColorKey. У меня так видео с 2000-го года выводятся, да я понимаю про chroma-артефакты на субтитрах и OSD (если плеер рендерит субтитры прямо в видео). Но это не обязательно, kaffeine (из kde3), например, рендерил в основном окне, просто рисуя что надо поверх окна... цветом отличным от colorkey. На интеле есть Adaptor #0: "Intel(R) Video Sprite" и Adaptor #1: "Intel(R) Textured Video" Вот адаптер 1 именно по описанному мной алгоритму работает. И работал так с середины 90-х. Всегда считалось, что это самый оптимальный вывод видео (но видео не будет видно на скриншоте).
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	271. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 25-Фев-24, 20:35
	> Не совсем понял, а как оно сейчас работает? Ну если у тебя > медиаплеер делает окошко с opengl и собирается шейдерами (или вообще на > CPU) конвертить yuv->rgb, то причем тут XVideo? Ну так АМДшники и написали для бакланов - такие маневры видите ли апскейлят частоты GPU и он жрать начинает. Есть какие-то проблемы с чтением новости? При том это бессмысленное и беспощадное действо сушествует по причине "абстракция такая". Хотя железо могло бы проглотить вон то и без этого всего - если сделать вон то, вон так. Только на архитектуру иксов эта хотелка не маппится - никак. Ну вот не созданы они для таких вещей. А в вяленде нет ничего, что по крупному бы встало на пути реализации этого. Такая разница. > Если плеер выводит через XVideo, то оно и выводится через хардверный конвертер > нужного yuv-цветового пространства в RGB. Это и есть аппаратное ускорение XVideo. Ага, теперь расскажите как туда выхлоп ХАРДВАРНОГО ДЕКОДЕРА ВИДЯХИ загнать в эффективном виде?! Если вы декодировали на CPU у вас, конечно, нет этой проблемы ибо когда проц молотил со всемй дури - про экономию питания речь не шла один фиг. Но если видео распаковал хардварный декодер, а сервисный обвес операции начинает жрать больше энергии чем сама операция, это начинает несколько напрягать, вызывая нездоровые лулзы. > Несколько окон плееров можно открыть и в каждом окне выводится своё видео > - хочешь в yuy2, хочешь в yv12, в чем хочешь выводит. Как это стыкуется с хардварным декодером в эффективном виде? Вон тот пайплайн, именно в том виде сделать - можно? Нет, через забор с заподвыподвертом закинуть фрейм на кривой козе - не интересно, весь пойнт будет пролюблен. > Вот адаптер 1 именно по описанному мной алгоритму работает. И работал так > с середины 90-х. Всегда считалось, что это самый оптимальный вывод видео > (но видео не будет видно на скриншоте). Это в ваших серединах девяностых и считалось. С тех пор придумали ряд идей сильно получше. Типа хардварного surface'а в железе, в который к тому же хардварный декодер сам в лучшем случае и будет рисовать. А железо потом слепит эн surface'ов перед посылкой в провод. Нечто типа простого хардварного варианта композитинга.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Anonymous1 (?), 24-Фев-24, 12:54
	> есть расширение XVideo с поддержкой аппаратных YUV сурфейсов. И что же, зачем нужны все остальные расширения для вывода видео? Почему бы не оставить одно распрекрасное расширение, чтобы всем было хорошо? Может, потому что не всё так прекрасно, как ты пишешь?
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	189. "Инженер из AMD признал, что графический стек Linux нуждается..."	+6 +/–
	Сообщение от Аноним (189), 24-Фев-24, 16:06
	А в вяленде что, не вокруг расширений базового протокола всё крутится?
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 23:24
	> А в вяленде что, не вокруг расширений базового протокола всё крутится? А как вы вон то предлагаете обыграть то? Вбить прям в core вяленда жесткий requirement к фичам хардвара - уметь все вон то, со всеми наворотами? Тогда тоже порядком народа резко взвоет, особенно учитывая что воон то, в воооон теми constraints надо было - не всем. Дизайн софта - это всегда некий набор компромиссов.
	Ответить | Правка | Наверх | Cообщить модератору

	210. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Аноним (-), 24-Фев-24, 22:05
	> Извини, но это чушь. В Иксах черт знает с каких времен есть > расширение XVideo с поддержкой аппаратных YUV сурфейсов. А еще этот кусок невменяемой блевотины, ушибленной на весь мозг - никому не нужен уже лет как десять. Потому что работает так, что проще через GL или Vulkan рисовать. Хоть плеер и не трехмерная программа, зато иксы - вместе со всей их горбатой бловотой за бортом и проблем сразу в 20 раз меньше и перфоманс в разы лучше. Почему-то. Хоть гнать кадры видео как текстуры и несколько изврат. Зато - цуко работает и цуко лучше. Но вы можете использовать это угробище - если оно для вас работает. > То, что оно работает не со всеми дровами - это вопрос к производителям самих дров Вопрос скорее в том как это угробище вообще работало. За что и выпало из фавора. > (и к автору новости, который написал, что в Иксах это якобы невозможно). Вы настолько некомпетентны что не в состоянии понять что именно вам писали амдшники насчет графического пайплайна. > https://people.freedesktop.org/~mslusarz/nouveau-wiki-dump/X... Последнее обновление этой паги в 2013 году (всего 11 лет прошло!) - вместе с высокоинновационными family нвидий (последний писк какого именно года, не уточните?) как бы намекает. В 2013 все еще только начиналось. И там вон то еще даже чуть трепыхалось. Сейчас этот кусок крапа просто мертв. Забудьте про это. Букмарки надо иногда апдейтить. Ваша кобыла давно умерла. И плееры уже на нее почти забили. Такой видео-тормозятор и видео-глюкатор никому не надо, сорян. Это жутчайшее легаси на данный момент, если оно еще вообще работает.
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	194. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от AlexYeCu (ok), 24-Фев-24, 18:03
	>Просто приделать какое-то расширение Забавно, но вот за такой подход к решению проблем фанаты Вяленого обычно ругают Иксы.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	213. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:16
	> Забавно, но вот за такой подход к решению проблем фанаты Вяленого обычно ругают Иксы. В вот этом конкретном случае иксы скорее просто внутренними абстракциями не вышли. Там на гвозди прибиты совсем другие идеи о том что такое графическая подсистема и как это работает. Те допущения - жутко клещатся с вон той идеей, сделать такой shortcut средствами хардвара. И не, натянуть такую сову на этот глобус - нереал. И никто не будет дедушку так по костяшкам перебирать, в надежде что он снова сможет олимпийцем быть, если вдруг это ВЫ случайно не удумаете сами ЭТО попробовать. А вот вэйланд архитектурно вон тому - совсем нигде и никак не мешает и замимплементить в 50 раз проще будет.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от жорик (?), 24-Фев-24, 16:00
	меня все устраивает.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	294. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от User (??), 26-Фев-24, 08:33
	Да хрен знает. Не очень понятно, кому и насколько оно вообще надо. У тех, кому НАДО - оно есть и работает, шо у ведроидов, шо у всяких вебос уже свои слои костылей. А проблемы юзеров линуксодесктопа нннууэээ... вот.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Инженер из AMD признал, что графический стек Linux нуждается..."	–20 +/–
Сообщение от Аноним (3), 23-Фев-24, 23:37
Ну так етить, а чья это проблема, что железо какое-то в линуксах не поддерживается? Линуксокодеров или производителей железа, которые свои железки не поддерживают в линуксе? Или линуксокодеры должны для любой железки самостоятельно в одно рыло писать при каждой возможности все плюшки, а рыло там у производителей железа не треснет?! Для винды поди сами написывали. А для линуксов не было нужды, вот и нет, потому что производители железа навстречу не шли, вот и не вкладывались в "десктопное" направление, потому что его особо серьёзно и не рассмтривали. Особенно в каком-то крутом графическом стеке.
Ответить | Правка | Наверх | Cообщить модератору

	8. "Инженер из AMD признал, что графический стек Linux нуждается..."	+31 +/–
	Сообщение от НяшМяш (ok), 23-Фев-24, 23:53
	Онаним новость не прочитал и сделал неверные выводы. Никогда такого не было и вот ещё один.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Инженер из AMD признал, что графический стек Linux нуждается..."	–5 +/–
	Сообщение от ваноним (?), 24-Фев-24, 05:46
	> Никогда такого не было и вот ещё один. Да раньше надо было "правильное" железо купить или на линуксе нихрена не заведется. А тебе еще и плюсы наставили :)
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (-), 24-Фев-24, 00:56
	> Линуксокодеров или производителей железа, которые свои железки не поддерживают в линуксе? Мда... ну допустим всё производители железа ринуться писать поддержку для линукса. Как это изменит нынешний порядок операций в ядре?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	38. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (38), 24-Фев-24, 01:12
	Всмысле как? Изменят нынешний порядок в ядре. Как по-твоему Интел коммитил KMS в ядро?
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 01:53
	> Как по-твоему Интел коммитил KMS в ядро? Я не прашивал как. Я срашивал "какого?" то, что "ни X.org, ни Wayland не могут работать с YUV-потоками напрямую" должны исправлять амдщники. Это не их задача.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (129), 24-Фев-24, 08:41
	Не «не могут», а «не реализовано». Только в Wayland это делается естественным образом, а в Xorg через ж
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от анонимоус (?), 24-Фев-24, 09:44
	> Это не их задача. Он жалуется что их железо не работает как надо. Чтоб их железо заработало, кто-то за них должен решить задачу?
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	147. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 10:52
	> их железо не работает как надо Не правда. Их железо прекрасно работает в нормально написанных системах. Напр. в винде и андроиде "Windows and android handle most of this in their compositors.". Все потому что "MS and Android put a lot of work into their compositor and media APIs to enable these use cases out of the box." А на корявых системах, где всё написано через Ж еще для логики работы терминального доступа... там оно не работает, удивительно, не так ли? Поэтому чтобы их железо заработало, нужно менять не драйвера или железо, а граф. подсистему линукса.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от 128557 (?), 24-Фев-24, 13:43
	Это надо делать только для железа от AMD? И как тогда уживается железо от Intel и Nvidia, логичный Вы наш?
	Ответить | Правка | Наверх | Cообщить модератору

	185. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (185), 24-Фев-24, 15:02
	Вполне возможно, что железо от Intel и Nvidia имеют теже проблемы, что и AMD, только молчат об этом, потому что их никто не спрашивал
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (257), 25-Фев-24, 14:31
	А я вот вообще не вижу проблемы: почему линуксоиды на голом энтузиазме просто не напишут правильные реализации и запушат патчи в апстрим — опенсорс же.
	Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

	195. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от AlexYeCu (ok), 24-Фев-24, 18:06
	>Не правда. Их железо прекрасно работает в нормально написанных системах. Напр. в винде и андроиде Бггг. Видел я, как оно в Винде работает. Как в Андроиде не видел — это что-то из серии «x86 Андроид в виртуалке»?
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	230. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (230), 25-Фев-24, 00:08
	В новых Exynos видео ядро от amd.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от iPony129412 (?), 24-Фев-24, 04:19
	> Для винды поди сами написывали Там Microsoft написал. А под Линукс... Ну в теории могли бы всё на себя взвалить (как любят говорить тут фанатики — «а где патч?»). Но это круто конечно, да и на какие шиши такую сложную задачу делать ради мизерной аудитории, где разработка по принципу лебедь-рак-щука.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	139. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от анонимоус (?), 24-Фев-24, 09:48
	>  ради мизерной аудитории Так аудитория мизерная потому, что их железо плохо работает
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (189), 24-Фев-24, 16:10
	А железо плохо работает, потому что дров нет. А дров нет, потому что не пишут. И если посмотреть на этот круговорот импотенции, то можно увидеть, что писать дрова под линукс — занятие ну просто малоприятное. Поэтому дрова под линуксом в массе своей рожают крупные железные конторы, а вот под всякими бздями люди умудряются писать обычные кодеры. Уже это должно намекнуть, что проблемы носят архитектурный характер. Вспомните, сколько амуде пришлось затащить в ядро, чтобы иметь возможность более-мене стабильно делать свои дрова. Не от хорошей жизни.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (193), 24-Фев-24, 17:34
	> А железо плохо работает, потому что дров нет. А дров нет, потому > что не пишут. > И если посмотреть на этот круговорот импотенции, то можно увидеть, что писать > дрова под линукс — занятие ну просто малоприятное. Поэтому дрова под > линуксом в массе своей рожают крупные железные конторы, а вот под > всякими бздями люди умудряются писать обычные кодеры. Уже это должно намекнуть, > что проблемы носят архитектурный характер. > Вспомните, сколько амуде пришлось затащить в ядро, чтобы иметь возможность более-мене стабильно > делать свои дрова. Не от хорошей жизни. В Линуксе надо постоянно бежать за ломкой API в ядре - в Windows ты нежно и спокойно работаешь с одним и тем же API лет 10 подряд, а то и больше. WDDM практически не менялся с Windows Vista, которой скоро 20 лет. Понятное, что Линукс разрабы не успевают и всё это выливается в тонне ошибок и регрессий.
	Ответить | Правка | Наверх | Cообщить модератору

	288. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от mos87 (ok), 26-Фев-24, 07:12
	>в Windows ты нежно и спокойно работаешь с одним и тем же API лет 10 бггг
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Инженер из AMD признал, что графический стек Linux нуждается..."	+7 +/–
	Сообщение от Аноним (230), 25-Фев-24, 00:09
	Видеокарты от AMD самые беспроблемные под Linux.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	112. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Слава Линуксу (?), 24-Фев-24, 06:51
	Линукс-общество сами выбрали такой путь - мы все сами. Вот пусть и расхлёбывают. А майки это многомиллиардная компания, они денег дадут на это и все будет готово. Решает рыночек. Проснись, а то насмотрелся на Ютубе видосиков про свободное сообщество нетакусиков...
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	118. "Инженер из AMD признал, что графический стек Linux нуждается..."	–5 +/–
	Сообщение от Аноним (118), 24-Фев-24, 07:40
	Тут причина в кривых АМДешных дровах в 5 млн строк.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от iPony129412 (?), 24-Фев-24, 07:54
	Как-будто хадача декодирования видео в линуксах работает отлично на AND и Nvidia. Дело было не в бобине.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (152), 24-Фев-24, 11:30
	Причина проста. No money, no honey.
	Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

6. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
Сообщение от ы (?), 23-Фев-24, 23:49
Может это тонкий намёк Valve? :)
Ответить | Правка | Наверх | Cообщить модератору

	18. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (18), 24-Фев-24, 00:35
	А валв тут при чем?
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Инженер из AMD признал, что графический стек Linux нуждается..."	+10 +/–
	Сообщение от ыыы (?), 24-Фев-24, 02:50
	Ооо, давно заметил такую тенденцию. У них в опенсоре никто никому не должен. Но как только появляются реальные рабочие руки, делающие дело, то на них сразу хотят повесить все свое хотелки.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от soarin (ok), 24-Фев-24, 06:04
	У них много денег. Их Steam Dеck работает на AMD. Им бы хорошо, чтобы на нём можно было эффективно смотреть видяшки. И значит – отдувайтесь за всех 🙂 Ещё бы и Flatpak занялись бы – "отняли" бы у RedHat.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	181. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (181), 24-Фев-24, 14:10
	>Ещё бы и Flatpak занялись бы – "отняли" бы у RedHat. Чтобы что?
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (229), 25-Фев-24, 00:06
	Чтобы занялись.
	Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором	–3 +/–
Сообщение от AKTEON (?), 23-Фев-24, 23:50
Мелочная  бездуховность  индустрии "     Сжатый видеопоток     VCN     Сырые YUV данные     Контроллер дисплея, который будет преобразовывать палитру, масштабировать и отображать. " Благолепный академизм "     Сжатый видеопоток     VCN (модуль аппаратного декодирования видео для GPU AMD)     Сырые YUV данные     Конвертация палитры, масштабирование на модуле GFX (по сути 3D акселератор в GPU, что заставляет его повышать частоты работы ядра и VRAM)     RGB данные     Вывод на дисплей. "
Ответить | Правка | Наверх | Cообщить модератору

	20. Скрыто модератором	+3 +/–
	Сообщение от Аноним (18), 24-Фев-24, 00:36
	Что сказать то хотел?
	Ответить | Правка | Наверх | Cообщить модератору

	39. Скрыто модератором	+/–
	Сообщение от Аноним (38), 24-Фев-24, 01:14
	Это правка к новости или что?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

9. Скрыто модератором	–4 +/–
Сообщение от Аноним (9), 23-Фев-24, 23:54
Ставьте оболочкой windows 11. Все в нем работает. Чего мудрить?
Ответить | Правка | Наверх | Cообщить модератору

	11. Скрыто модератором	–3 +/–
	Сообщение от Аноним (118), 24-Фев-24, 00:01
	В лиунсе тоже работает, и надежность с безопасностью выше. Просто в графическом режиме видео карты немного больше потребляют. Ну так не гамай.
	Ответить | Правка | Наверх | Cообщить модератору

	29. Скрыто модератором	–7 +/–
	Сообщение от Аноним (-), 24-Фев-24, 00:57
	> и надежность с безопасностью выше Как говорил Бендер Родригес:   Ахаха! Погоди, ты это серьезно?   Тогда я буду смеяться еще громче! Читая каждые почти каждую неделю про очередную дыряшку в ядре с повышением привилегий, про вечные уязвимости su/sudo/suid и прочих костылей, про дырки в хорг'е живущие по 30 лет... Что-то меня терзают смутные сомнения.
	Ответить | Правка | Наверх | Cообщить модератору

	42. Скрыто модератором	+2 +/–
	Сообщение от Аноним (42), 24-Фев-24, 01:22
	Смех без причины, Билли, признак передёргивания. Всё познаётся в сравнении: 1. https://blog.qualys.com/vulnerabilities-threat-research/2023... 2. https://www.cvedetails.com/top-50-vendors.php Так что да. Дыряшка та еще. ^_^
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	+7 +/–
	Сообщение от Аноним (118), 24-Фев-24, 01:30
	Ты читаешь про исправления, в том числе и мелких багов и багов, которые существуют чисто теоретически. И все равно исправляют. И находят это благодаря открытости исходников и благодаря тому что Линукс это серверная система №1 и внимание к ее надежности колоссально. Винда же закрыта и МС не заинтересован в афишировании дыр, и поиск их и успешность удаления вызывает сомнения, тем более -  кодят индусы.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	126. Скрыто модератором	+/–
	Сообщение от Аноним (125), 24-Фев-24, 08:23
	Фермы на чем? Вот и ответ на вопрос эффективности. А выше - офтопик тролли (как проплаченные, так и инициативники), да и "новость" тоже.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	66. Скрыто модератором	+/–
	Сообщение от Аноним (64), 24-Фев-24, 02:54
	> Ставьте оболочкой windows 11. Все в нем работает. Чего мудрить? Да просто не нужно. Потому и не сделано. Очевидно ж. Ненужно=не_сделано.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

10. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (10), 23-Фев-24, 23:55
А что мешает взять из андройда реализацию ?
Ответить | Правка | Наверх | Cообщить модератору

	22. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (18), 24-Фев-24, 00:38
	Это невозможно, там надо будет переписать 99%. Неужели не ясно?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (176), 24-Фев-24, 13:47
	Ну так сядьте и за пару недель перепишите, но нет - они буду ходить и годами ныть.
	Ответить | Правка | Наверх | Cообщить модератору

	356. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от sena (ok), 01-Мрт-24, 13:08
	Где "там"?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	30. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от ПомидорИзДолины (?), 24-Фев-24, 00:58
	Насколько я понял проблема - на уровне протоколов XOrg и Wayland. Графический стек из андроида в линуксовый десктоп принести можно, но ни одно настольно приложение поверх него работать не сможет. Плюс в андроиде графический стек построен прибит гвоздями к другим кускам рантайма (Activity и вот это вот все).
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	355. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от sena (ok), 01-Мрт-24, 13:07
	То есть тулкиты надо допилить? Qt под Андроид вроде бы уже есть? А то что старые приложения не будут работать это нормально. И иксовые приложения в вейланде без спец. поддержки со стороны вейланда не будут работать.
	Ответить | Правка | Наверх | Cообщить модератору

	358. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от ПомидорИзДолины (?), 25-Мрт-24, 23:59
	> То есть тулкиты надо допилить? Qt под Андроид вроде бы уже есть? Да, можно подпилить тулкиты и пересобрать вообще все. Другая проблема, что во время пересборки окажется, что приложения помимо фреймвоков дергают APIшки операционки напрямую. Все такие кейсы придется перепимывать. Вой будет стоять такой, что перекроет системду, вяленого и раст вместе взятых. > А то что старые приложения не будут работать это нормально. И > иксовые приложения в вейланде без спец. поддержки со стороны вейланда не > будут работать. Сегодня иксовые приложения в вяленом работают. Обеспечить их поддержку поверх андроидного стека можно, но нужны хорошие инвестиции.
	Ответить | Правка | Наверх | Cообщить модератору

	359. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (42), 26-Мрт-24, 02:30
	> Другая проблема, что во > время пересборки окажется, что приложения помимо фреймвоков дергают APIшки операционки > напрямую. сисколы ядра линукса или бсди дергают? гуи приложения? > Все такие кейсы придется перепимывать. кейсы ^_^ > Вой будет стоять такой, что перекроет системду, вяленого и раст вместе взятых. не угрожай нам! >_< > Сегодня иксовые приложения в вяленом работают. Обеспечить их поддержку поверх андроидного > стека можно, но нужны хорошие инвестиции. иксы пашут на андроиде. о чем ты вообще? что здесь происходит? O_o Юзер, ты обдолбался?
	Ответить | Правка | Наверх | Cообщить модератору

	360. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от sena (ok), 27-Мрт-24, 12:32
	> Сегодня иксовые приложения в вяленом работают. Обеспечить их поддержку поверх андроидного > стека можно, но нужны хорошие инвестиции. X-Server под Андроид уже есть. Может допилить его надо... https://play.google.com/store/apps/details?id=x.org.server&h...
	Ответить | Правка | К родителю #358 | Наверх | Cообщить модератору

	215. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:20
	> А что мешает взять из андройда реализацию ? То что у surface flinger'а как-то маловато фич для вот именно десктопа. Он совсем уж на минималочках, ну, можешь посмотреть какая оконная система в андроиде. Если это таковым вообще можно назвать. А что, хочешь себе ТАКОЕ на десктоп? Если да - ну так андроид и накати?! Он для x86 бывает. Получишь желаемое!
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	354. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от sena (ok), 01-Мрт-24, 13:03
	А каких фич там не хватает? Окошки можно дописать при необходимости. При чём тут окошки? Рчь идёт не о переносе Андроида, а только его граф. подсистемы, если она действительно хорошо работает.
	Ответить | Правка | Наверх | Cообщить модератору

13. "Инженер из AMD признал, что графический стек Linux нуждается..."	–4 +/–
Сообщение от Аноним (13), 24-Фев-24, 00:15
Брехня, у меня вот UHD770 так же коряво работает с AV1 что на линуксе, что на шинде. На шинде графияеский адаптер тоже грузится, а не как с VP9 например. Иными словами полноценного декодера там по сути нет, зато для инета менее напряжно. Эти они от лгбт фанатиков понабрались всякой дури. Амдэбои могут проверить как с AV1 в обоих случаях?
Ответить | Правка | Наверх | Cообщить модератору

	21. "Инженер из AMD признал, что графический стек Linux нуждается..."	+15 +/–
	Сообщение от Аноним (21), 24-Фев-24, 00:38
	Да у тебя, судя по всему, и клавиатура коряво буквы нажимает.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (151), 24-Фев-24, 11:27
	вот именно, он жмёт в надежде получить иероглиф, а получается кириллица
	Ответить | Правка | Наверх | Cообщить модератору

	249. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (13), 25-Фев-24, 11:36
	Да ты прорицатель, я и правда на русском могу в японский. Там и правда только английские символы заменяются,а русский язык пробивает их насквозь.
	Ответить | Правка | Наверх | Cообщить модератору

	250. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (13), 25-Фев-24, 11:37
	Ага, это андроидские загоны когда он ошибки выдает вместо нажатий.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	94. "Инженер из AMD признал, что графический стек Linux нуждается..."	+5 +/–
	Сообщение от Аноним (94), 24-Фев-24, 04:52
	https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

14. "Инженер из AMD признал, что графический стек Linux нуждается..."	+5 +/–
Сообщение от omnonom (?), 24-Фев-24, 00:23
> Более эффективно это может быть решено в Wayland композиторах, А может быть и не решено > но пока реализации нет. Ну то есть - безосновательная спекуляция.
Ответить | Правка | Наверх | Cообщить модератору

	24. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (-), 24-Фев-24, 00:51
	> А может быть и не решено Не-не, то что может быть - факт. Осталось только найти кто запилит реализацию. А вот в иксах оно даже в теории не получится - это все иксы переписать придется (и разумеется, сохранить обратную совместимость при этом не получится.)
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Инженер из AMD признал, что графический стек Linux нуждается..."	–4 +/–
	Сообщение от Анании.orig (?), 24-Фев-24, 03:49
	> А вот в иксах оно даже в теории не получится - это все иксы переписать придется Бредовые утверждение
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
	Сообщение от Аноним (-), 24-Фев-24, 10:54
	> Бредовые утверждение "It's generally not possible to use multiple planes in X, so this would be wayland only." Угу, расскажи это инженеру АМД))
	Ответить | Правка | Наверх | Cообщить модератору

	234. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (230), 25-Фев-24, 00:23
	Архитектура wayland позволяет использовать одновременно разный формат поверхностей, а у X нет. Поэтому реализовать гораздо проще в wayland,а иксы придется переписывать что бы подобное заработало.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

17. Скрыто модератором	–1 +/–
Сообщение от Аноним (17), 24-Фев-24, 00:33
Не всем нужен графический стек, можно и в консоли сидеть.
Ответить | Правка | Наверх | Cообщить модератору

	32. Скрыто модератором	+1 +/–
	Сообщение от ПомидорИзДолины (?), 24-Фев-24, 01:01
	Вот она, вся сила современного линуксоида: сидеть в консоли, программно декодировать видео, но ни в коем случае его не смотерть. Не поняли в чем профит? А это некоммерческая организация!
	Ответить | Правка | Наверх | Cообщить модератору

19. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
Сообщение от Аноним (21), 24-Фев-24, 00:35
Правда! Я гляжу на свой  ATI Radeon Mobility M6 и плачу дважды: первый раз, когда вижу как он работает и второй раз, когда читаю комменты на опеннете.
Ответить | Правка | Наверх | Cообщить модератору

	27. "Инженер из AMD признал, что графический стек Linux нуждается..."	+6 +/–
	Сообщение от хрю (?), 24-Фев-24, 00:54
	>>ATI Radeon Mobility M6 хммм это ж карта 20 летней давности. Тебе надо радоваться - то что она до сих пор работает уже чудо. Не?
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от kusb (?), 24-Фев-24, 20:04
	У меня есть компьютер с ati R 600 и она даже мощная и может работать, я надеюсь. Не включал несколько лет.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 25-Фев-24, 20:58
	Если бы с такими характеристиками и не максиму TDP 240 W, https://www.techpowerup.com/gpu-specs/ati-r600.g431 а не больше 65W это для меня ещё за бесплатно может и сошло бы в игры не играю, но нет ещё и размер видеокарты большой и с TDP 240 W и с такими характеристиками не оправдано иметь такую видеокарту впустую лишний нагрев и размер. С такими характеристиками есть старше модели видеокарт с меньше размером и TDP, намного ниже TDP раза в 3-6.
	Ответить | Правка | Наверх | Cообщить модератору

	274. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 25-Фев-24, 21:33
	Есть и такое, один из примеров ATI Radeon HD 2900 XTX https://www.techpowerup.com/gpu-specs/radeon-hd-2900-xtx.c2140 GRAPHICS PROCESSOR R600 CORES 320 TMUS 16 ROPS 16 MEMORY SIZE 512 MB MEMORY TYPE GDDR3BUS WIDTH 512 bit Когда я писал TPD в 3-6 раз меньше я имел ввиду видеокарты с Memory Bus 64, 128 bit. Но, поскольку в игры я не играю у меня видеокарта с ширина памяти 64бит. Я брал с 64 бит шиной чтобы максимально уменьшить нагрев - меньше чипов памяти. GPU Clock 743 MHz Memory Clock 828 MHz 1656 Mbps effective Memory Memory Size 512 MB Memory Type GDDR3 Memory Bus 512 bit Bandwidth 106.0 GB/s Render Config Shading Units 320 TMUs 16 ROPs 16 Compute Units 4 L2 Cache 256 KB Theoretical Performance Pixel Rate 11.89 GPixel/s Texture Rate 11.89 GTexel/s FP32 (float) 475.5 GFLOPS Board Design Slot Width Dual-slot Length 315 mm 12.4 inches TDP 240 W Suggested PSU 550 W Outputs 2x DVI 1x S-Video Power Connectors 2x 6-pin Board Number 109-B00131-00 Graphics Features DirectX 10.0 (10_0) OpenGL 3.3 (full) 4.0 (partial) OpenCL N/A Vulkan N/A Shader Model 4.0
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	291. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 07:54
	> GRAPHICS PROCESSOR > R600 CORES 320 TMUS 16 ROPS 16 MEMORY SIZE 512 MB MEMORY > TYPE GDDR3BUS WIDTH 512 bit По состоянию на сейчас - бессмысленная и беспощадная байда. Жрет много, считает чуть, архитектура винтажна настолько что допустим GPGPU бэк для него никто даже не пытался делать в силу бессмысленности. > Когда я писал TPD в 3-6 раз меньше я имел ввиду видеокарты > с Memory Bus 64, 128 bit. А, вы хотите вот именно затычку для слота в вообще совсем понимани - кусок текстолита? Ну тогда воткните S3 Virge, с 64 бит шиной разницы будет немного. Дискретку есть смысл ставить как раз ради отдельной быстрой VRAM на жирной шине. А если это мусор с тормозной 64 бит шиной и каким нибудь DDR3 - тогда можно было интеграт юзать и не выделываться, еще вопрос что лучше. > с 64 бит шиной чтобы максимально уменьшить нагрев - меньше чипов памяти. Можно было интеграт брать с такими "требованиями". > Theoretical Performance АнтикЪ. Не умеет в современные стандарты, таким и помрет. Этот видео-тормозитель далек от вон той проблематики. И вообще - у него VCN блока нет. Вот хоть там как.
	Ответить | Правка | Наверх | Cообщить модератору

	320. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 20:23
	Я прекрасно понимаю что себе я покупаю и для чего. Не всем нужны игры и просмотр видео с 4K или 8K. Для чего и берут мощные видеокарты кто понимает что покупает и для чего покупает. А раз мне это не надо то в пустую платить за ненужную производительность я не хочу. Но да же если бы мне подарили видеокарту уровня GeForce GTX четырёхтысячной серии я бы её продал или выкинул если бы не захотел заморaчиватся с продажей. Такая огромная печка мне ненужна в компьютере, нет практичного для меня смыла, только минус от использования такой видеокарты лишний нагрев, больше шума и лишнее в пустую потребление электричества. Я сторонник практичного использования. Нужны были бы игры у меня была бы другая видеокарта. Интегрированное видео в процессор может быть будет и это вариант когда я посчитаю, что мне пора уже менять процессор - весь компьютер, а может и не весь не знаю нет острой необходимости делать по другому. Но не факт, что будет.
	Ответить | Правка | Наверх | Cообщить модератору

	321. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 20:35
	Не GeForce GTX, GeForce RTX перепутал букву. В игры не играю. Развитие видеокарт специально не отслеживаю, пока покупать менять видеокарту мне не понадобится.
	Ответить | Правка | Наверх | Cообщить модератору

	322. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 20:47
	Деньги не лишние. Но игры дело не полезное я в этом участвовать не хочу. По этому может быть и выкинул. Так как почти на 100% есть уверенность, что такую видеокарту GeForce RTX будут в том числе и для игр использовать.
	Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

	331. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 06:21
	> Я прекрасно понимаю что себе я покупаю и для чего. Не всем > нужны игры и просмотр видео с 4K или 8K. Ну тогда и вон та хрень вам ни к чему, и чего мы тогда тут обсуждаем? > мне подарили видеокарту уровня GeForce GTX четырёхтысячной серии я бы её > продал или выкинул если бы не захотел заморaчиватся с продажей. Ну так можно юзать какойнить интеграт и не париться. > Такая огромная печка мне ненужна в компьютере, нет практичного для меня смыла, На нее можно дофига вычислений спихнуть так то. Это уже давно generic вычислитель с видеовыходом так то.
	Ответить | Правка | К родителю #320 | Наверх | Cообщить модератору

	337. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 19:03
	Суть моих слов та, что была написана выше перечитайте. Только из-за большой скорости памяти если у видеокарты скорость шины 256бит, 512бит, этой серии видеокарты могут быть лучше для игр при равном по производительности видео процессоре. А если не для игр использовать такие видеокарты, такие видеокарты не оправдывают себя по сравнению с видеокартами новее меньшего размера и с меньшим потреблением электричества. А дальше на что менять или менять каждый решает сам.
	Ответить | Правка | Наверх | Cообщить модератору

	338. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 20:58
	Чего считать будем? Криптавлюту считать или пароли подбирать? Ушлые счетоводы видеокарты для этого не одну штуку используют, сотнями покупают видеокарты обедняют в кластер, тысячу или больше тысячи видеокарт в кластере используют.
	Ответить | Правка | К родителю #331 | Наверх | Cообщить модератору

	340. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 21:28
	Для чего вычисления будем использовать (Чего считать будем?) ? Так точнее смысл написанного.
	Ответить | Правка | Наверх | Cообщить модератору

	341. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 28-Фев-24, 00:07
	> Чего считать будем? Криптавлюту считать или пароли подбирать? А также всякие фильтры в FFMPEG, фоточки в darktable, ускорение в каком-нибудь CADе... ну да, кому это нужно? Явно не хомячкам с опеннета. > Ушлые счетоводы видеокарты > для этого не одну штуку используют, сотнями покупают видеокарты обедняют в > кластер, тысячу или больше тысячи видеокарт в кластере используют. Чтобы разговаривать о вкусе устриц надо их хотя-бы раз попробовать.
	Ответить | Правка | К родителю #338 | Наверх | Cообщить модератору

	343. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 28-Фев-24, 02:54
	Кому надо тот использует кому не надо нет. Я знаю, что что-то можно, но это всё ещё в массе людей не много. Как были основным предназначением мощных видеокарт обслуживать игры так и осталось и вся эта мощность для игр на первом месте и проектируются, чтобы вся это мощь могла обрабатывать очередную игру.
	Ответить | Правка | Наверх | Cообщить модератору

	344. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 28-Фев-24, 03:25
	> Кому надо тот использует кому не надо нет. Я знаю, что что-то > можно, но это всё ещё в массе людей не много. Как > были основным предназначением мощных видеокарт обслуживать игры так и осталось и > вся эта мощность для игр на первом месте и проектируются, чтобы > вся это мощь могла обрабатывать очередную игру. Осталось все это нвидии и амд обяъснить, а то что-то их а AI-акселерацию потянуло... странные игры какие-то - у половины видях аж видеовыхода нет.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 28-Фев-24, 19:00
	https://www.nvidia.com/ru-ru/data-center/tesla-v100/ У NVIDIA есть направление видеокарт для вычислений TESLA называется. Не пиши ерунду, а посчитай если тебе это надо, сколько компьютеров и ноутбуков с видеокартой NVIDIA куплено, а сколько видеокарт TESLA в наличии в использовании у людей или аналоги если есть у AMD. О AMD видеокартах меньше знаю не пользуюсь на данный момент видеокартами AMD по этому почти нечего из современного у AMD не знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	349. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 28-Фев-24, 19:27
	Я о видеокартах TESLA знаю не один год лет 7 или 10. В каком году появилась первая TESLA не знаю пишут 2007 год. Были модели видеокарт Quadro. "NVIDIA Quadro теперь называется NVIDIA RTX. Уже более 20 лет NVIDIA Quadro является самым надежным в мире брендом для профессиональных визуальных вычислений" Знать надо. "NVIDIA Tesla V100 с тензорными ядрами – самый технически продвинутый в мире GPU для дата-центров, предназначенный для ускорения искусственного интеллекта, HPC, наука о данных и графики. Созданный на основе архитектуры NVIDIA Volta, он доступен в конфигурации с 16 или 32ГБ памяти и обеспечивает производительность на уровне 100 CPU. Это дает ученым, исследователям и инженерам возможность справляться с задачами, решение которых ранее было невозможно"
	Ответить | Правка | Наверх | Cообщить модератору

	350. Скрыто модератором	+/–
	Сообщение от Аноним (-), 28-Фев-24, 19:41
	"Знать надо" - если надо об этом знать не всем эта информация нужна.
	Ответить | Правка | К родителю #349 | Наверх | Cообщить модератору

	353. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 29-Фев-24, 19:45
	Удалено пробую ещё раз. Посмотрел характеристики Tesla V100 и V100S и GeForce RTX 4090. Тесла это не самое быстрое. Может какие-то специфичные программы и задачи есть для Теслы которые только на ней можно делать. Характеристики разные. Подробную информацию сами ищите кому интересно. Ват меньше 250 Тесла и 450 GeForce RTX 4090 оно и должно быть меньше если Cores меньше. Эту теслу не эту имеют виду я не знаю. NVIDIA Tesla V100S PCIe 32 GB Graphics Processor     GV100 Cores     5120 TMUs     320 ROPs     128 Memory Size     32 GB Memory Type     HBM2 Bus Width     4096 bit Memory Size     32 GB Memory Type     HBM2 Memory Bus     4096 bit Bandwidth     1,134 GB/s ------------------------------------------------------------------- NVIDIA GeForce RTX 4090 Graphics Processor     AD102 Cores     16384 TMUs     512 ROPs     176 Memory Size     24 GB Memory Type     GDDR6X Bus Width     384 bit Memory Size     24 GB Memory Type     GDDR6X Memory Bus     384 bit Bandwidth     1,008 GB/s ---------------------------------------------------------------------- Relative Performance: Tesla V100S PCIe 32 GB 100% GeForce RTX 3070 Ti 101% Radeon RX 7700 XT 102% Radeon RX 6800 104% GeForce RTX 4070 115% Radeon RX 6800 XT 118% GeForce RTX 3080 123% Radeon RX 7800 XT 124% Radeon RX 6900 XT 128% GeForce RTX 4070 SUPER 134% Radeon RX 7900 GRE 136% GeForce RTX 3080 Ti 138% Radeon RX 6950 XT 138% GeForce RTX 3090 140% GeForce RTX 4070 Ti 144% GeForce RTX 4070 Ti SUPER 157% Radeon RX 7900 XT 161% GeForce RTX 3090 Ti 163% GeForce RTX 4080 183% GeForce RTX 4080 SUPER 185% Radeon RX 7900 XTX 187% GeForce RTX 4090 229%
	Ответить | Правка | К родителю #349 | Наверх | Cообщить модератору

	325. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 21:19
	Не посмотрел, сразу что это S3 Virge. Подумал это что-то современное от AMD. А это видеокарта из 90 годов 1995г. "Ну тогда воткните S3 Virge, с 64 бит шиной разницы будет немного" Дорогой ты мой ребёнок иди ты лесом не нах, а лесом с своим выпендрёжом глупым сравнением. Я написал по хорошему без злобы.
	Ответить | Правка | К родителю #291 | Наверх | Cообщить модератору

	326. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 21:48
	S3 ViRGE Specifications: 64-bit 2D/3D graphics S3d Engine with integrated 135 MHz (325 and MX), 170 MHz (DX/GX/GX2) or 220 MHz (VX) RAMDAC and clock synthesizer     S3 Streams Processor for accelerated video         On-the-fly stretching and blending of primary RGB stream and RGB or YUV (video) secondary stream         Each stream can have a different color depth         Hardware-assisted video playback with horizontal interpolation         Support for Indeo, Cinepak, and software and hardware-accelerated MPEG-1 video     S3 Scenic Highway for direct interface to live video and MPEG-1 peripherals     2D GUI acceleration. (BitBLT, line draw, polygon fill)     3D texture mapping         Perspective correction, flat and Gouraud shading. ViRGE/DX and later feature 'parallel processing' perspective correction for better performance         Bilinear and trilinear texture filtering, MIP Mapping, alpha blending, and video texture mapping. Trilinear filtering is full-speed on ViRGE/DX and later, termed 'SmartFilter' technology.         Depth cueing and fogging, Z-buffering     1600×1200 with 16 colors (VX), 1280×1024 with 256 colors at 75 Hz refresh, 1024×768 with 64K colors at 75 Hz refresh, 800×600 16.7M colors at 75 Hz refresh (these are the non-interlaced modes; higher color depths are supported with interlaced video)[3]     64-bit DRAM or VRAM (VX) memory interface, 2, 4, and 8 (VX) MiB video memory, Single-cycle EDO operation     Glueless PCI 2.1 bus interface and VESA VL-Bus (325) interface     PCI bus mastering for display list processing and video capture support     Drivers for major operating systems and APIs: Windows 95, Windows 3.1x, Windows NT, IBM OS/2 2.1 and 3.0 (Warp), ADI 4.2, Direct3D, BRender, RenderWare and OpenGL     Full hardware and BIOS support for VESA Display Power Management Signaling (DPMS) monitor power savings modes     DDC monitor communications     325 uses 208-pin PQFP package. VX uses 288-pin BGA package     ViRGE 325 pin compatible with S3 Trio64V+ Нет с этим не корректное сравнение. Не так и мало, но нет. Это если этот чип перенести на плату с PCE-I и добавить памяти до 128МБ вместо 4МБ. Я даже не знаю, а есть в этот чип смысл больше памяти добавлять не пользовался такой видеокартой в наше время с нынишними операционными сситемами.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 21:56
	PCI-E не для скорости, а для совместимости, чтобы было во что вствлять. Так как S3 ViRGE сделана для PCI.
	Ответить | Правка | Наверх | Cообщить модератору

	342. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 28-Фев-24, 00:39
	> PCI-E не для скорости, а для совместимости, чтобы было во что вствлять. > Так как S3 ViRGE сделана для PCI. Вообще-то в PCI, обычный, 32-битный, видеокарты упирались только в путь. Поэтому и появился AGP. А потом и PCIe, когда кривой переросток-костыль всех утомил.
	Ответить | Правка | Наверх | Cообщить модератору

	328. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 22:05
	Вариант с AGP был. Но сути это не меняет.
	Ответить | Правка | К родителю #326 | Наверх | Cообщить модератору

25. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
Сообщение от Аноним (-), 24-Фев-24, 00:53
> Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании На 20й год индеец Зоркий Глаз увидел что нет четвертой стены... Да все и так знают что он нуждается в улучшении! Тоже мне, Капитан Очевидность.
Ответить | Правка | Наверх | Cообщить модератору

33. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от хрю (?), 24-Фев-24, 01:01
Как я понял весь сыр был из-за потери 6.5 ват энергии при просмотре [s]порну[/s] ... фильмов? Ну да это самая важная проблема в линукс ...
Ответить | Правка | Наверх | Cообщить модератору

	40. "Инженер из AMD признал, что графический стек Linux нуждается..."	+5 +/–
	Сообщение от Аноним (-), 24-Фев-24, 01:14
	Не, весь сыр бор в том что под оффтопиком оно кушало 8.5 ватт, в под Fedorой - 13W. Т.е если тебе не повезло, то твой ноут проживет на 50% меньше времени без розетки. А это уже серьезно, брать ноут с батарейкой на 12 часов, чтобы его хватало на 8... Проще уже с виндой взять. ps я бы предположил, что все дело в лицензии и маленкие столлманы в̶о̶р̶у̶ю̶т̶ ̶е̶м̶а̶к̶с̶ы̶ экспроприируют ватты во благо коммун партии и мировой революции, но раз инджинер АМД уверен в том, что в линуксе граф стек просто овно... наверное он может быть прав.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Аноним (42), 24-Фев-24, 01:26
	>но раз инджинер АМД уверен в том, что в линуксе граф стек просто овно... а почему конкурент из интела не овно он не знает... >наверное он может быть прав. не сомневайся, сомнение преступно.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (230), 25-Фев-24, 00:29
	А почему вы решили что Интел чем-то отличается, не удивлюсь что в интелах под Линукс просто нет мониторинга потребления втдеочипа, что бы пользователи даже не задумывались о проблеме.
	Ответить | Правка | Наверх | Cообщить модератору

	302. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от an onim (?), 26-Фев-24, 14:27
	А если есть - удивитесь? xorg  в простое Intel Icelake (Gen11) @ /dev/dri/card0 -   12/  12 MHz;  99% RC6;  0.02/ 2.4 W xorg 4k60fps youtube Intel Icelake (Gen11) @ /dev/dri/card0 -  960/ 958 MHz;  48% RC6;  2.23/13.33 W
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Аноним (125), 24-Фев-24, 08:27
	> А это уже серьезно, брать ноут с батарейкой на 12 часов, чтобы его хватало на 8... Проще уже с виндой взять. Каждый устанавливает свои критерии. С таким Вам действительно проще ... взять.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	144. "Инженер из AMD признал, что графический стек Linux нуждается..."	–3 +/–
	Сообщение от хрю (?), 24-Фев-24, 10:26
	> Т.е если тебе не повезло, то твой ноут проживет на 50% меньше > времени без розетки. > А это уже серьезно, брать ноут с батарейкой на 12 часов, чтобы > его хватало на 8... Вы на ноуте при работе от акума часто фильмы смотрите? Максимум в самолёте или в сапсане, вам 8 часов не хватит ? Ну и вот, дальше сами додумаете. Есть гораздо более важные проблемы в линуксячей графике, чем раздутие 6.5 ватт.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	153. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (-), 24-Фев-24, 11:35
	> вам 8 часов не хватит? Это если у тебя изначально батареи было на 12 часов. А если на 8? Или на 6? Другой ноут покупать? Вот едешь ты в междугородном автобусе, пишешь код тихонько, компилишь, доку читаешь. И решил параллельно сериальчик посмотреть. А оно тебе взяло и сожрало всю батарею. Печалька, не так ли? > Есть гораздо более важные проблемы в линуксячей графике, чем раздутие 6.5 ватт. И это повод не говорить об этой проблеме?
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Аноним (118), 24-Фев-24, 11:40
	Не покупай АМД и все!
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
	Сообщение от Аноним (-), 24-Фев-24, 11:57
	> Не покупай АМД и все! Ну да, вас послушай и будет "АМД не покупай - оно много жрет" "невидию не покупай - там дрова проприетарные, а открытые глюченые" "интел не покупай - там intelME" Так проще выкинуть глючный лиинупс, чем отказываться от AMD. Потому что в нормальных системах все работает.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (118), 24-Фев-24, 12:39
	В АМД свое МЕ, забыл как оно там. Так что нельзя покупать. И глючная винда идет лесом.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (230), 25-Фев-24, 00:30
	Ты думаешь у Intel и Nvidia свой волшебный графический стек в Linux? Там та же проблема.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	178. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от 128557 (?), 24-Фев-24, 13:57
	Очередной Евгений Вахтангович, постоянно разъезжающий в междугороднем автобусе, пишущий код тихонько, компилящий, доку читающий, и решающий параллельно сериальчик посмотреть. Ржу, не могу от таких скоморохов. Чего из пальца не насасаны другие высокие материи? Внезапно решающий спеть оперу, станцевать балет и отправиться в космос ближний, и всё не покидая рейс дальний?
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	212. "Инженер из AMD признал, что графический стек Linux нуждается..."	–3 +/–
	Сообщение от Аноним (-), 24-Фев-24, 22:14
	Ну надо же что-то отвечать на тупейшие вопросы типа "Вы на ноуте при работе от акума часто фильмы смотрите?" - да часто, люблю взять ноут на балкон, сидеть в кресле и смотреть фильмец. "Есть гораздо более важные проблемы в линуксячей графике, чем раздутие 6.5 ватт" - не 6.5 ватт, а 1,5 раза. Гораздо большие проблемы это сборище некрофилов и копролитофилов - иначе бы хорг уже закопали и можно было бы сделать нормальную графику. ps на твои пуки про оперу и дальний космос отвечать не буду, тк они превысили мою терпимость у человеческому идиотизму
	Ответить | Правка | Наверх | Cообщить модератору

	232. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (229), 25-Фев-24, 00:11
	>пишешь код тихонько, доку читаешь >И решил параллельно сериальчик посмотреть Ну и как удаётся это совмещать?
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	267. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (267), 25-Фев-24, 19:00
	Как удаётся мы можем видеть по новостям о CVE и жалобам на плозую документацию.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Kuromi (ok), 27-Фев-24, 21:22
	Так это всегда так было. Хочешь чтобы ноут работал долго - ставь винду, еще 10 лет тому назд говорили, под Линуксом батарея всегда жралась в полтора-два раза быстрее. Можно было конечно подкрутить частоту процессора, но не сильно помогало когда, например, блютус выключался в ОС но продолжал жрать энергию.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

34. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
Сообщение от Аноним (42), 24-Фев-24, 01:08
>> I still don't understand why Intel fairs so much better and I feel like there's some very large inefficiency on the AMD side. > I'm not familiar with Intel hardware, but I suspect they ... Подздравляю обладателей красных видеокарт. ^_^ И да, виноват линукс, и иксы, конечно же.
Ответить | Правка | Наверх | Cообщить модератору

	37. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от name (??), 24-Фев-24, 01:12
	Иксы отбросили графический стек линукса на десятилетия назад.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (42), 24-Фев-24, 01:24
	Разумеется, для AMD. Патамушта лапки.
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от name (??), 24-Фев-24, 01:41
	АМД тут каким боком? Дрова они хорошие запилили.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (42), 24-Фев-24, 01:51
	> АМД тут каким боком? Дрова они хорошие запилили. Память 3 секунды? :-D Ну отмотай вверх, перечитай. Не лишним кстати будет напомнить: https://www.phoronix.com/news/AMD-5-Million-Lines Еще раз мои поздравления красным.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Инженер из AMD признал, что графический стек Linux нуждается..."	+3 +/–
	Сообщение от name (??), 24-Фев-24, 02:24
	Последний пост прочитай, у интела другая тема. Амуде нужно, чтобы композитор умел yuv хавать. Прямой рендеринг уже есть, хоть и багнутый.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (42), 24-Фев-24, 02:38
	Я тебе последний пост и цитировал. :-D >Амуде нужно, чтобы композитор умел yuv хавать. AMDу композитор танцевать мешает. Почему Intel не жрёт (конкурент, ёмаё) - он не знает. Но чукча не читатель, чукча писатель. Он уже нашел фатальный недостаток вейланда и иксов.)) Хорошо хоть в ядре им позволяют испражняться тоннами овнокода. Держим кулачки чтоб сломали иксы. Про вейланд молчу, он и так не работает. >Прямой рендеринг уже есть, хоть и багнутый. Как и драйвер AMD.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от name (??), 24-Фев-24, 02:43
	Зачем им делать свои костыли, когда это должен api предоставлять? Про вейланд вообще бред какой-то и про дрова, почему у меня тогда работает?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Аноним (42), 24-Фев-24, 03:04
	>Зачем им делать свои костыли, когда это должен api предоставлять? Согласен. Тем более, что свои костыли у АМД получились плохими. Пусть сделают хоть кто-нибудь нормально за них. Только не опционально, прошу, есть тут разрабы вейланда? Сделайте принудительный вывод. Нам нужно порадовать пользователей/разработчиков графики и мультимедия. Все 3%. Ну, и обязательно депрекейт всех [s]radeon[/s] amdgpu драйверов, с аккселератором, слава богу он уже не нужен. ^_^ Слухай, а может попросить амдэшникам разрабов интел поделиться костылями? Ну, как поделиться, написать за AMD. >Про вейланд вообще бред какой-то и про дрова, почему у меня тогда работает? Ты серьёзно под новостью где у амд всё плохо пишешь что нет, всё хорошо? Всё хорошо, но дальше так жить нельзя? :-D
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от name (??), 24-Фев-24, 03:20
	Очень полезные комментарии набрасываешь, продолжай. Какой же амд плохой, одни дураки там работают.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (42), 24-Фев-24, 03:30
	> Очень полезные комментарии набрасываешь, продолжай. Набросил тот, кто написал новость. И мы оба знаем почему. > Какой же амд плохой, одни дураки там работают. Зачем выдумываешь соломенное чучело? Я такого не говорил. А если ты думаешь что копроративный сектор автоматически рожает хороший код - то советую заглянуть в соседнюю новость про NetworkManager. Я там набросил ссылки на код красношляпых. Поверь, ты они так пишут, что ты в пьяном угаре такое не напишешь. Ну ладно, напишешь, но для себя любимого ты так софт писать не будешь. Да что там поверь - проверь.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от name (??), 24-Фев-24, 03:34
	И почему же? Код, может, и не лучшего качества, но свободный, и во многих кейсах он работает хорошо.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (42), 24-Фев-24, 03:58
	> И почему же? Срача ради, очевидно же. > Код, может, и не лучшего качества, но свободный, и во многих кейсах он работает хорошо. Код плохого качества не может работать хорошо. Это противоестественно.)) Впрочем, кому и кобыла невеста. Что до свободы - это его единственное преимущество, но из за вендорлока и это преимущество коту под хвост. Это абсолютно unmaintainable, как и системд кусок копролита. Который сдохнет сразу как закончатся на него деньги. ;-)
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от name (??), 24-Фев-24, 04:06
	Слишком много претензий к лучшей линуксовой графике, не находишь?
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	85. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
	Сообщение от Аноним (42), 24-Фев-24, 04:09
	> Слишком много претензий к лучшей линуксовой графике, не находишь? Причем от тех, кто сделал худший драйвер. Закономерно, не находишь?
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	88. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от name (??), 24-Фев-24, 04:12
	Но они не делали драйвер для нвидии, ты что-то путаешь.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	95. "Инженер из AMD признал, что графический стек Linux нуждается..."	–6 +/–
	Сообщение от Аноним (42), 24-Фев-24, 04:54
	> Но они не делали драйвер для нвидии дык они и собственный драйвер не могут починить, куда уж там. =) P.S. Или кто-то в реальном времени отслеживает наше общение, или ты ставишь себе плюсик и мне минусик после каждого сообщения. Ахахах) Боже... Всё, я умываю руки.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	100. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
	Сообщение от name (??), 24-Фев-24, 05:37
	Зачем им его чинить, если он работает? Поставил минус глупому посту.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	245. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (42), 25-Фев-24, 06:44
	>Зачем им его чинить, если он работает? написал под новостью, где разраб амд расписался в неспособности снизить потребление amdgpu. Всё работает, жги)
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

35. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
Сообщение от name (??), 24-Фев-24, 01:08
Эх, а ведь зайчатки стека для воспроизведения видео уже есть, dmabuf, vaapi/v4l2, осталось вейланду протокол добавить, композиторы код подтянут. Вообще, можно было бы добавить ещё одну абстракцию, над всеми этими разными api, а то никак не могут прийти к единому решению. Выглядит перспективным vulkan, посмотрим, будут ли его юзать производители железа.
Ответить | Правка | Наверх | Cообщить модератору

36. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
Сообщение от Аноним (36), 24-Фев-24, 01:12
Привязка к железу - вредна. 21 век на дворе. Виртуализация. Доступ к экрану за тысячи киллометров.
Ответить | Правка | Наверх | Cообщить модератору

	43. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (38), 24-Фев-24, 01:23
	И как ты получишь доступ к экрану за тысячи километров, если нигде никакой экран никуда не привязан? 21 век ведь.
	Ответить | Правка | Наверх | Cообщить модератору

53. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от mumu (ok), 24-Фев-24, 02:08
Объясните глупому, почему сразу в RGB нельзя? Откуда и зачем берётся YUV?
Ответить | Правка | Наверх | Cообщить модератору

	54. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (-), 24-Фев-24, 02:11
	> Объясните глупому, почему сразу в RGB нельзя? Откуда и зачем берётся YUV? Само видео изначально в YUV. Соответственно его и получаем на выходе декодера. Но граф. подсистема не умеет работать с ним и приходится перекодировать в ргб
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 24-Фев-24, 02:29
	YUV - это цветовая модель, альтернативная RGB,   это древняя вещь для аналогового телевидения. Почему-то она используется в видеокартах, в цифрой форме называется YCbCr. Почему не нравится  RGB не знаю. Но в Х-ах она есть.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	72. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от Аноним (72), 24-Фев-24, 03:24
	Меньше места занимает и хорошо кодируется. Главный компонент: яркость, которую ч/б телевизор показывал + 2 "цветовых" смещения.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 24-Фев-24, 03:31
	А это не наследие древних времен? Ради совместимости? Я не уверен.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Инженер из AMD признал, что графический стек Linux нуждается..."	+6 +/–
	Сообщение от n80 (?), 24-Фев-24, 03:56
	Нет, это было придумано именно с учётом особенностей цветовосприятия человеками (впрочем, повышенная чувствительность к яркости не только у таковых) и позволяет кодировать картинки (и, особенно, видео) более эффективно при менее заметных потерях качества.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 24-Фев-24, 04:26
	RGB возникла тоже неслучайно. Физиологические особенности зрения исследовали. И большинство других моделей также. А CMYK сложился из-за доступности пигментов. Мне кажется YUV была удобна для аналогового телевидения, также накопилась масса видеозаписей, ну и решили раз работает не будем ничего менять, продолжим линию. Удобнее старое декодировать к тому же. Если сейчас по-новому подойти к цифровой видеозаписи может другие методы появятся.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (141), 24-Фев-24, 09:59
	> RGB возникла тоже неслучайно. Физиологические особенности зрения исследовали. RGB бесконечно далеко от человеческого восприятия, может хотел сказать CIELAB или HSV?
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 24-Фев-24, 10:12
	Не хотел. "бесконечно далеко" это явное преувеличение.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (141), 24-Фев-24, 11:50
	RGB — линейное пространство и очень плохо учитывает восприятие глазом, в том числе не учитывает яркостную составляющую. Всё это вылилось в кучу несовместимых профилей с разными коэффициентами и все не то.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 24-Фев-24, 12:44
	Такая техника была -  потому и sRGB, да и вообще 8 бит. Постепенно будут улучшаться мониторы - сменят модель. Они уже давно и такие что нельзя пока физически воплотить даже экспериментально.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Anonymous1 (?), 24-Фев-24, 13:00
	И в другой модели, кстати, тоже не смогут работать иксы.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 25-Фев-24, 03:43
	Значит будем ждать вяленого. Лет 10 ...
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:43
	> RGB возникла тоже неслучайно. Физиологические особенности зрения исследовали. И большинство > других моделей также. А CMYK сложился из-за доступности пигментов. > Мне кажется YUV была удобна для аналогового телевидения, также накопилась масса видеозаписей Она позволяет основательно урезать объем данных или бандвиз в эфире, что примерно одно и то же, не очень сильно слив по качеству картинки. Потому что Y это яркость а U и V кодируют цвета - но это можно передать грубее чем Y и на типичном видеоконтенте никто не заметит особой разницы. Вот на PC-generated графике - вы, конечно, YUV можете и не заценить. Особенно с subsampling типа 4:2:2 - он может цвета в скриншотообразном контенте основательно испортить местами.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	240. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 25-Фев-24, 03:23
	Понятно.
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:28
	> Объясните глупому, почему сразу в RGB нельзя? Откуда и зачем берётся YUV? Видео чаще всего представлено в YUV формате. Это изначально связано с телевизионщиками и их потугами убавить объем передаваемых данных, но при переходе в цифру идея убавить размер видео почему-то всем по прежнему нравится - ибо нежатый видеопоток огромен. Технически это связано с тем что яркость картинки для человека в целом важнее цветности, а в RGB очень много дублирующейся информации в 3 полноразрядных каналах без subsampling по пикселам. Видеокодеки на память об этом как правило оперируют в этом формате пикселей. Ну и декодирующий видеохардвар соответственно тоже. Бывает даже что мониторы могут напрямую жрать YUV поток, скажем в HDMI есть такая опция, характерно для бытовухи типа теликов которым оно как-то более основное чем RGB с компа.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	239. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (118), 25-Фев-24, 03:22
	Значит одновременно существует и RGB и YUV? Первый для интерфейсов и второй для видео?
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от adolfus (ok), 25-Фев-24, 12:52
	Нет. RGB используется для светоизлучающих поверхностей, CMYK -- для светоотражающих, это чтсто технические заморочки. YUV -- чисто физиологические. Поэтому все так и останется. А что, в школе уже это не проходят?
	Ответить | Правка | Наверх | Cообщить модератору

	281. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Фняк (?), 26-Фев-24, 01:06
	А по-моему yuv это не про физиологичность, а про обратную совместимость между цветным и чернбелым ТВ вещанием. Т.е. чтобы абоненты с чб приемником могли без проблем принимать изначально цветные передачи
	Ответить | Правка | Наверх | Cообщить модератору

	285. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n00by (ok), 26-Фев-24, 06:49
	"Физиологичность" не мешает обратной совместимости. ЧБ приёмник игнорирует поднесущую, так что ему всё равно, что там кодируется. Был бы зрителю был важенее цвет, тогда бы инженеры думали, как кодировать цветовые компоненты, а не цветоразностные.
	Ответить | Правка | Наверх | Cообщить модератору

	332. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 06:29
	> Значит одновременно существует и RGB и YUV? Первый для интерфейсов и второй для видео? У современной железки бывает несколько surface'ов при отрисовке на монитор, и в одном может быть RGB для гуя, а в другом YUV для вывода видео. Железо при выводе в провод этого автоматически слепит сие, сконвертирует формат если надо на тот что в проводе, и даже сделает некий композитинг этого на минималочках. Так что воон там UI плеера это "GUI" с его RGB а фактическая картинка YUV, а на экране - они оба, с гуем поверх картинки, ибо surfaces так сетапнуты. Ессно для этого фокуса - софт должен знать что такой фокус вообще провернули.
	Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

55. "Инженер из AMD признал, что графический стек Linux нуждается..."	–3 +/–
Сообщение от Аноним (-), 24-Фев-24, 02:21
On Linux you have lots of compositors and desktop environments, each with their own goals and schedules and features.  The problem is that not all hardware supports this so most compositors and media players tend to focus on the solution that will serve the largest number of users across a wide range of hardware В общем классический пример фрагментации. Наплодили васяноДЕ и никто не хочет клпаться в этой куче. Было бы круто, если бы вендоры выбрали два самых популярных ДЕ, а на всю остальную маргинальщину положили большой и толстый. Ну и заодно бы дропнули некрожелезо. Было бы море нытья, но оно хотя бы работало хоть где-то! А то сейчас оно где угодно работает лучше чем в линуксе...
Ответить | Правка | Наверх | Cообщить модератору

	58. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
	Сообщение от name (??), 24-Фев-24, 02:35
	Да, enlightenment и cde.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (164), 24-Фев-24, 12:56
	Было бы ещё круче если бы разрабы приложений и вендоры железа сказали нет вейланду и гномобанде.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 14:06
	Ахаха, и с кем тогда работать? С васяндрами, сидящими в терминальной консоли? Которые на все новое говорят "нинужна"? Не, так оно не работает. Вендоры работают с теми, кто что-то делает - с вейландом и гномобандой. А других у нас нет.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (181), 24-Фев-24, 14:13
	>Ахаха, и с кем тогда работать? С теми, кто сможет, например, тот же стим доукомплектовать для дистрибутивов с несходящейся glibc без всяких флатпаков, режущих фпс. Линукс - не игрушка для инфантилов.
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от Аноним (267), 24-Фев-24, 15:17
	> Линукс - не игрушка для инфантилов. Почему ж тогда среди пользователей Линукса их так много? Главная проблема в айти — инфантилизм. Остальные так-сяк можно решить.
	Ответить | Правка | Наверх | Cообщить модератору

59. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
Сообщение от Аноним (59), 24-Фев-24, 02:37
Ни разу не эксперт, но хочу отметить пару моментов: 1. Почему Алекс решил, что видеопоток после декодирования должен сразу идти на вывод? Там ещё цветокоррекция и прочая постобработка. Конечно, в нормальных видеоплеерах (а не в софт гумне) это всё через шейдеры реализовано, но всё равно 3D-движок задействован. 2. Такое ощущение, что в линуксе проблема не в том, что на видеокарте кадры перекидываются туда-сюда (это должно быть очень быстро), а словно там ещё куча костылей и слоёв абстракции из-за которых декодированный кадр ещё тошнится через ЦПУ десять раз, и ещё сто раз в ядре потормозит на блокировках.
Ответить | Правка | Наверх | Cообщить модератору

	63. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
	Сообщение от name (??), 24-Фев-24, 02:51
	Это хардверное декодирование здорового человека, так задействуется меньше всего ресурсов. Для качества лучше вообще софтверно декодировать и рендерить качественным рендером, который тоже неплохо так ресурсы жрёт. Но слабые железки, тем более embedded, даже копирование не потянут.
	Ответить | Правка | Наверх | Cообщить модератору

	292. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (292), 26-Фев-24, 07:55
	> Для качества лучше вообще софтверно декодировать Думал, этим только аудиофилы страдают.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
	Сообщение от Аноним (118), 24-Фев-24, 02:54
	В интеле такого потребления нету.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	120. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от iPony129412 (?), 24-Фев-24, 07:58
	Иноел на эту тему работает. У них же и хромобуки. VAAPI они и создали. И в Chromium по этому делу ковыряются.
	Ответить | Правка | Наверх | Cообщить модератору

69. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (4), 24-Фев-24, 03:14
почему молчит nvidia? у них всё в порядке?
Ответить | Правка | Наверх | Cообщить модератору

	73. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от name (??), 24-Фев-24, 03:25
	У них проприетарные nvenc/dec. Вулкан начали внедрять, но нвидии у меня нет, не знаю, где это работает.
	Ответить | Правка | Наверх | Cообщить модератору

	345. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (345), 28-Фев-24, 03:49
	Если ваше бревно не умеет в Vulkan, это только проблема новозного жука.
	Ответить | Правка | Наверх | Cообщить модератору

	346. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от name (??), 28-Фев-24, 06:52
	Можно метафоры попроще? Ничего не понял.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от soarin (ok), 24-Фев-24, 06:01
	так и в новости никто не орал, это просто обсуждение в багтрекере Nvidia понятное дело, тоже имеет кучу проблем с линуксовыми приколами.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

80. "Инженер из AMD признал, что графический стек Linux нуждается..."	+5 +/–
Сообщение от n80 (?), 24-Фев-24, 03:53
Что-то тут недоговаривают. Всю дорогу был Xv (X-Video Extension), который таки позволяет выводить YUV оверлеи в иксах без лишних преобразований, весь вопрос в том чтобы драйвер правильно заявлял таковую поддержку. Более того, там не только вывод, но и пост-обработка может быть заявлена и использоваться приложениями, см. вывод xvinfo. Т.е. проблема, скорее, не в иксах, а в дровах AMD.
Ответить | Правка | Наверх | Cообщить модератору

	83. "Инженер из AMD признал, что графический стек Linux нуждается..."	+6 +/–
	Сообщение от name (??), 24-Фев-24, 04:00
	Оно умерло очень давно. Теперь по xvideo гуглится совсем другое.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от n80 (?), 24-Фев-24, 04:10
	> Оно умерло очень давно. Теперь по xvideo гуглится совсем другое. Судя по выводу xvinfo на машине с intel (и тому что видео у меня таки играется без особого напряга для процессора), не совсем умерло. Другое дело, что у меня direct rendering без композитора, а выше заметили что нужна в композиторе поддержка. В такой постановке уже могу поверить в наличие проблемы, но уверен что тоже какое-то решение давно есть.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Инженер из AMD признал, что графический стек Linux нуждается..."	+3 +/–
	Сообщение от name (??), 24-Фев-24, 04:15
	Ты уверен, что используешь xv, а не vaapi? Насколько древняя машинка?
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n80 (?), 24-Фев-24, 04:43
	> Ты уверен, что используешь xv, а не vaapi? Насколько древняя машинка? Очень хороший вопрос, до этого был уверен, но сейчас включил отладочный вывод mpv и таки через VA-API основная работа идёт (ну т.е. по умолчанию используется vo=gpu, который уже под капотом дёргает vaapi и ещё кое-что, чтобы работали скриншоты и без мыла отрисовывался интерфейс/субтитры). А Xv хоть и работает, но только если его явно попросить и загрузка процессора в этом случае всё же чуть выше, не говоря уж про возможные проблемы с отрисовкой OSD/субтитров. Так что да, Xv действительно остался во временах вторых/третьих пней, хотя поддержка ещё есть, в принципе. Но это я с названием ошибся (ОК, VA-API, а не Xv), а принципиальный-то момент остаётся: есть какой-никакой API для вывода YUV-оверлеев без лишних телодвижений и он даже отлично работает. Чего не хватает AMD, чтобы у них хотя бы так работало — хотелось бы понять.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от name (??), 24-Фев-24, 05:00
	У тебя вывод идёт через рендер на vulkan или opengl, а они прямой хотят сделать, это разгрузит cpu и gpu. На wayland есть dmabuf, mpv его уже поддерживает, но показывает красную картинку, как раз из-за YUV.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n80 (?), 24-Фев-24, 05:40
	> У тебя вывод идёт через рендер на vulkan или opengl, а они прямой хотят сделать, это разгрузит cpu и gpu. По умолчанию через opengl, а минимальная загрузка CPU, вроде, при выводе через vaapi, хотя сложно сравнить, она даже через xv небольшая на фоне собственно декодирования сжатого видео. Насколько можно сделать ещё прямее — посмотрим, буду знать про поддержку dmabuf в wayland.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от name (??), 24-Фев-24, 05:14
	vo=gpu работает, если ты не понял.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	99. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n80 (?), 24-Фев-24, 05:35
	> vo=gpu работает, если ты не понял. Я понимаю что vo=gpu работает по умолчанию, но это же обёртка поверх разных реальных API, соотв-но вопрос в том, что там на самом деле используется. Судя по тому что в логе идёт раньше, там вообще OpenGL ([vo/gpu/opengl] Choosing visual EGL config 0xa, visual ID 0x21), но есть в этом что-то странное. Если Xv и VA-API мне более-менее понятны, то вывод YUV через текстуру GL звучит диковато, хотя и понимаю что так тоже возможно.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от name (??), 24-Фев-24, 05:45
	Декодирует vaapi, рендерит gl, всё понятно. В gpu-next рендерит вулкан, вроде как, проверь. Это позволяет использовать различные фильтры, шейдеры.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n80 (?), 24-Фев-24, 21:14
	gpu-next через libplacebo рендерит: судя по логу, всё равно через opengl, но с добавкой GLSL. Вулкан в логе не упоминался, да и хорошо это: судя по выводу vulkaninfo, у меня на основной машине он только через llvmpipe работает, думаю, из-за старого ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	289. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от mos87 (ok), 26-Фев-24, 07:21
	для gpu-next можно выбрать вывод vulkan >Вулкан в логе не упоминался, да и хорошо это: судя по выводу vulkaninfo, у меня на основной машине он только через llvmpipe работает, думаю, из-за старого ядра. кринж
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от name (??), 24-Фев-24, 04:09
	Постобработка невозможна без копирования, кстати, а они хотят zero copy.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	89. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
	Сообщение от n80 (?), 24-Фев-24, 04:15
	> Постобработка невозможна без копирования, кстати, а они хотят zero copy. Смотря какая. Подкрутить яркость/контраст/насыщенность по запросу приложения-клиента GPU и сам может на лету. Что-то более сложное шейдерами делается, т.е. тоже нет смысла обратно с GPU в основную память через CPU гнать. Что-то совсем замороченное же в любом случае не будет zero copy, но это нормально же.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Tron is Whistling (?), 24-Фев-24, 09:36
	Какая именно постобработка? Постобработка даже при copyback часто ведётся не в RGB.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	136. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Tron is Whistling (?), 24-Фев-24, 09:38
	Плюс современные GPU могут часть постобработки (цвета, скейлинг, деинтерлейс) сделать на GPU + можно шейдер накрутить. В принципе да, зачем это назад гонять через RGB - совершенно непонятно.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	137. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Tron is Whistling (?), 24-Фев-24, 09:39
	Даже слияние с субтитрами в D3D11 уже делается на GPU...
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	221. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:52
	> Что-то тут недоговаривают. Всю дорогу был Xv (X-Video Extension), который таки позволяет > выводить YUV оверлеи в иксах без лишних преобразований, весь вопрос в > том чтобы драйвер правильно заявлял таковую поддержку. Что Xv что Xvideo - страшенные костыли, с зиллионами родовых травм. Это настолько кривые и проблемные субстанции что на них в общем то почти все плееры забили. Если выбор встает так, проще сплевывать кадры как текстуры GL или Vulkan оказывается, ибо так это и то многократно лучше работает. > см. вывод xvinfo. Т.е. проблема, скорее, не в иксах, а в дровах AMD. Да не, чувак, проблема которую захайлайтил амдшник - весьма фундаментальна и связана с тем что кишки иксов изначально жутко далеки от структуры современного железа. И это одна из причин по которой что Xv что XVideo это жуткие непотребные глюкастики. И если горе эксперты еще не заметили: КАК В ТО ГАМНО ВООБШЕ ИНТЕРФЕЙСИТЬ ХАРДВАРНЫЙ ДЕКОДЕР В ТЕХ КОНЦЕПЦИЯХ?! Там это не предусмотрено. И вон тот shortcut не получится. Вот хоть как.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	255. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n80 (?), 25-Фев-24, 13:48
	Один момент: Xv и XVideo — одно и то же. А вторая вымирающая альтернатива называется VA-API и в рамках её концепции таки удобно использовать аппаратный декодер, для того Intel это и сделал изначально. Другое дело, что это сложно использовать для чего-либо кроме просмотра видосов, т.е. не самый универсальный API. Но работает же. Но сделают лучше — я только за.
	Ответить | Правка | Наверх | Cообщить модератору

	282. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Аноним (-), 26-Фев-24, 04:57
	> Один момент: Xv и XVideo — одно и то же. Да и х с ним. На практике это работает - как кусок тормозного глючного гуано. Так что выводить через GL или Vulkan в обход иксов меньше оверхеда, глюков и тормозов. В тех случаях иксы тоже контент экрана могут и не видеть, это же не через них. ...но вон тот фокус, когда выхлоп декодера в yuv-surface железки спихивается без особого участия софта в процессе не получится ни так ни сяк. Для этого надо сетапнуть железо специфичным образом и - проинформировать софт в системе что такой сетап имеет место быть. Софт должен понимать, что рендер на экран - не то что он там себе думал, а вот такое вот теперь. > А вторая вымирающая альтернатива называется VA-API и в рамках её концепции таки удобно > использовать аппаратный декодер, для того Intel это и сделал изначально. Оно вроде никуда не вымирает, в отличие от той отшибленой байды из девяностых. Плееры поддерживают, равно как и драйверы. Там же и VDPAU если мы об этом. А вон то по моему уже половина плееров дропнуло, или где-то на грани. > Другое дело, что это сложно использовать для чего-либо кроме просмотра видосов, Иксы в нужных для вон того абстракциях вообще не оперируют. Они не про менеджмент surface'ов - тем более хардварных. А вот вяленд - примерно это и делал, так что ему такую абстракцию подсунуть не будет огромной проблемой. Что-то поменять придется, но там нет ничего сильно стоящего на пути реализации такой фичи. > т.е. не самый универсальный API. Но работает же. Но сделают лучше — > я только за. Ну вон там господа хотят "short circuit" уметь делать, с вон такой структурой пайплайна. Как это вяленду представить я догадываюсь, а как иксам - ну, если кто в курсе, пусть и покажет. Иначе будет вяленд-онли фичой.
	Ответить | Правка | Наверх | Cообщить модератору

108. "Инженер из AMD признал, что графический стек Linux нуждается..."	+4 +/–
Сообщение от Аноним (-), 24-Фев-24, 06:09
Никто этому инженеру не рассказал, что открытые драйвера от AMD тоже нуждаются в совершенствовании, потому что 50% ядра занимать - это не дело?
Ответить | Правка | Наверх | Cообщить модератору

	352. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 29-Фев-24, 08:54
	> Никто этому инженеру не рассказал, что открытые драйвера от AMD тоже нуждаются > в совершенствовании, потому что 50% ядра занимать - это не дело? Все претензии - AMD Hardware Team! Кто виноват что они понастрогали дохреналион железок с дохреналионом регистров в каждой? Что хотите то и делайте, но без описания регистров железки - кина совершенно точно не будет. Вот вообще совсем! :) Линуховые хидеры - автогенерятся из сорцов амдшных железяк. Что HW Team наваял - то и в хидерах. И да, думаете у остальных сильно лучше? Ах да, нвидия в своей норке просто не отсвечивает :)
	Ответить | Правка | Наверх | Cообщить модератору

109. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
Сообщение от Аноним (-), 24-Фев-24, 06:16
Пора писать юзерспейсный сервер для видимокарт и уже на него натягивать иксы или вяленого как протокол. А стянуть всё это по пути можно будет в netbsd/hurd.
Ответить | Правка | Наверх | Cообщить модератору

	223. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:56
	> Пора писать юзерспейсный сервер для видимокарт и уже на него натягивать иксы > или вяленого как протокол. Внезапно MESA и Wayland примерно оно и есть. Поздравления, Кэп! DRM/KMS вообще так то рулит низкоуровенвыми аспектами работы железа. Типа видеорежимов, управления памятью, интерконект DMA всякий, вот это все. > А стянуть всё это по пути можно будет в netbsd/hurd. Угумс, заодно и покажете точные тайминги для page flipping какого-нибудь в юзермоде, без тиринга то, когда вас кернел может в любой момент - фьють! И конечно памятью GPU рулить из вот именно юзермода будет просто офигенно. GPU VM/MMU тоже наверное отлично оттуда сетапить, и перфоманс воображение поразит.
	Ответить | Правка | Наверх | Cообщить модератору

121. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от какая разница (?), 24-Фев-24, 07:58
На неAMD все работает правильно?
Ответить | Правка | Наверх | Cообщить модератору

132. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (132), 24-Фев-24, 09:24
Помнится мантейнер этих подсистем в Интел и вначале когда Амд драйвер писали, вместо помощи в пешее путешествие посылал. Может это политкорректная жалоба на прикормленных конкурентами мантейнеров.
Ответить | Правка | Наверх | Cообщить модератору

134. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Tron is Whistling (?), 24-Фев-24, 09:35
То есть понятия оверлея с отдельным цветовым пространством нет? Я не силён в графическом стеке, только консольные системы юзаю. Но если оверлея нет - это действительно треш.
Ответить | Правка | Наверх | Cообщить модератору

	278. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Black (??), 25-Фев-24, 22:17
	ИМХО аппаратных оверлеев вне профессиональных карт нет уже очень давно...
	Ответить | Правка | Наверх | Cообщить модератору

	324. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Tron is Whistling (?), 26-Фев-24, 20:58
	> ИМХО аппаратных оверлеев вне профессиональных карт нет уже очень давно... Щито? Оверлей в принципе аппаратный, он для этого и существует, иначе от него толку нет.
	Ответить | Правка | Наверх | Cообщить модератору

149. "Инженер из AMD признал, что графический стек Linux нуждается..."	–2 +/–
Сообщение от Аноним (149), 24-Фев-24, 11:01
>Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании странный заголовок. зачем такие заголовки? не надо. в любой ОС стек нуждается в улучшении. в линукс. в freebsd. в solaris. в линукс тоже. где-то там одно улучшение. где-то там другое. не надо таких заголовков.
Ответить | Правка | Наверх | Cообщить модератору

	224. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 22:58
	> странный заголовок. > зачем такие заголовки? не надо. Да это Ташкинов. Специфичный типок. ЧСХ, он таки и напорется за что борется. Ибо верещать может до упаду - но супротив вон тех это слон и моська. > в любой ОС стек нуждается в улучшении. > в линукс. в freebsd. в solaris. Да эти 2 по сравнению с линухом вообще в ауте по графике, уж простите за честность.
	Ответить | Правка | Наверх | Cообщить модератору

155. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (155), 24-Фев-24, 11:48
Какой стек какого из linux? В 4K-телевизорах так то тоже linux с какой-то графикой.
Ответить | Правка | Наверх | Cообщить модератору

157. "Инженер из AMD признал, что графический стек Linux нуждается..."	+6 +/–
Сообщение от Аноним (155), 24-Фев-24, 11:57
И конечно, как не приплести wayland в качестве универсального решения всех проблем. Wayland и с одной задачей не справляется - ни одна из его реализаций не годится на качественную замену X.org. При этом, там где использование иксов действительно было плохим выбором (на мобильных) иксы давно и успешно заменили. Не на wayland.
Ответить | Правка | Наверх | Cообщить модератору

	159. "Инженер из AMD признал, что графический стек Linux нуждается..."	–3 +/–
	Сообщение от Аноним (-), 24-Фев-24, 12:01
	> И конечно, как не приплести wayland в качестве универсального решения всех проблем А почему сразу приплести? Кто виноват что иксы настолько убогие, что даже в теории не могут решить проблему? > ни одна из его реализаций не годится на качественную замену X.org Уже как минимум две реализации прекрасно заменяют X.org.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от anonymous (??), 24-Фев-24, 12:31
	> Кто виноват что иксы настолько убогие, что даже в теории не могут решить проблему? В чём проблема? > Уже как минимум две реализации прекрасно заменяют X.org. Какие?
	Ответить | Правка | Наверх | Cообщить модератору

	165. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 12:48
	> В чём проблема? Ты баг из новости вообще не читал? Проблему ненужной конвертации yuv в rgb. И как следствие - жор батареи. > Какие? KWin и Weston разумеется.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от 1 (??), 24-Фев-24, 12:57
	It's generally not possible to use multiple planes in X, so this would be wayland only
	Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

	171. "Инженер из AMD признал, что графический стек Linux нуждается..."	+2 +/–
	Сообщение от petrg (ok), 24-Фев-24, 13:26
	> Wayland и с одной задачей не справляется - ни одна из его реализаций не годится на качественную замену X.org. При этом, там где использование иксов действительно было плохим выбором (на мобильных) иксы давно и успешно заменили. Не на wayland. Качественная замена требует времени. K сожалению на этот раз дольше чем хотелось. Если кажется что Wayland это переписывание иксов ради переписывания то вот https://www.kernel.org/doc/ols/2004/ols2004v1-pages-227-238.pdf И надобность в этих изменениях не вчера появилась. Оттуда:    This work represents a long term effort that started in 1999,    and will continue for several years more. История похожая на IPv6. Не видно разницы, но только если network engineer это не ваша работа.
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	183. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (181), 24-Фев-24, 14:18
	>При этом, там где использование иксов действительно было плохим выбором (на мобильных) иксы давно и успешно заменили. Не на wayland. И как у мобильников с энергоэффективностью в итоге получилось?
	Ответить | Правка | К родителю #157 | Наверх | Cообщить модератору

	225. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 23:00
	> И как у мобильников с энергоэффективностью в итоге получилось? При проигрывании видео так то - получше чем у вон тех. Думаете гугол зря surface flinger пилил сам вместо того чтобы иксы взять? От хорошей жизни так не делают.
	Ответить | Правка | Наверх | Cообщить модератору

170. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от iZEN (ok), 24-Фев-24, 13:23
Вот только не Дойкер, а Дойчер.
Ответить | Правка | Наверх | Cообщить модератору

	177. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n00by (ok), 24-Фев-24, 13:52
	Если "eu" читается как "ой", то это похоже на Дойче Шпрехе, где "ч" записывается буквами "tsch". Тогда Deucher звучит скорее как Дойхер.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (180), 24-Фев-24, 14:08
	Посмотрите на YouTube записи с его докладами, он представляется именно как Дойкер, а не Дойчер.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	196. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 18:07
	Как он произносит своё имя на иностранном языке не имеет никакого занчения. Иностранные личные имена при переносе на русский язык должны транскрибироватся по правилам русского языка.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (193), 24-Фев-24, 18:20
	> Как он произносит своё имя на иностранном языке не имеет никакого занчения. > Иностранные личные имена при переносе на русский язык должны транскрибироватся по > правилам русского языка. Нет такого канонического правила и, если посмотреть назад в историю, иностранные слова приходили к нам в самом разнообразном виде. А после заимствования их часто ещё и ломали. Например, "зонтик" стал "зонтом", хотя оригинал, кажется из голландского, не имеет ничего уменьшительно ласкательного.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 25-Фев-24, 11:23
	>Нет такого канонического правила Есть правила русского языка, в их числе правила транскрибирования имён собственных. >если посмотреть назад в историю, иностранные слова приходили к нам в самом разнообразном виде. И что с того? Это отменяет правила русского языка? >А после заимствования их часто ещё и ломали... Не понял, какое отношение исторические казусы имеют, к требованию по транскрибированию иностранных имён? Так и скажи, что ты не признаёшь правила транскрибирования, и что хочешь чтобы иностранные  слова звучали максимально приближенными к оригиналу, даже если это трудно согласуется с гармонией пострения звуков в родном языке. Но учти, любой уважающий себя ресурс должен обязан правил языка. Опеннет, это же не личная васянская страница? Так ведь?
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n00by (ok), 25-Фев-24, 15:59
	>>Нет такого канонического правила > Есть правила русского языка, в их числе правила транскрибирования имён собственных. Всё, что нужно знать об учителе правилам: "Правила транскрибирования" Результатов: примерно 4 170 "Правила транскрипции" Результатов: примерно 356 000 Просить ссылку на правила, понятное дело, даже и не стоит.
	Ответить | Правка | Наверх | Cообщить модератору

	253. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от iZEN (ok), 25-Фев-24, 12:29
	> Посмотрите на YouTube записи с его докладами, он представляется именно как Дойкер, > а не Дойчер. Можно ссылку на видео?
	Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

172. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
Сообщение от pic (?), 24-Фев-24, 13:28
>Контроллер дисплея, который будет преобразовывать палитру, масштабировать и отображать. Имеется ввиду контроллер матрицы LCD в мониторе, а передача сырых данных по видеокабелю в цифровом виде, или видеоадаптер в его оконечной части?
Ответить | Правка | Наверх | Cообщить модератору

	226. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 24-Фев-24, 23:09
	> Имеется ввиду контроллер матрицы LCD в мониторе, а передача сырых данных по > видеокабелю в цифровом виде, или видеоадаптер в его оконечной части? Блок GPU в общем случае. Современные железки умеют держать под framebuffer более 1 слоя (hardware surface), слеплять их между собой при выводе, конвертируя формат пикселей, если надо, внутрях, и вот это уже - в провод. Это не амд придумало, на мобильных девайсах такое уже сто лет. Ведроид в surface flinger этим сто лет пользоваться умеет. Технически при этом UI рисуется в HW surface в RGB формате, а результат видеодекодирования валится в HW surface с форматом YUV. А амд тоже так захотелось, в том числе и на нормальном лине. Почему нет, собссно?! Или лагучая энергожоркая графика через ж@#у - наше все?!
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от pic (?), 25-Фев-24, 14:26
	>[оверквотинг удален] > 1 слоя (hardware surface), слеплять их между собой при выводе, конвертируя > формат пикселей, если надо, внутрях, и вот это уже - в > провод. > Это не амд придумало, на мобильных девайсах такое уже сто лет. Ведроид > в surface flinger этим сто лет пользоваться умеет. Технически при этом > UI рисуется в HW surface в RGB формате, а результат видеодекодирования > валится в HW surface с форматом YUV. > А амд тоже так захотелось, в том числе и на нормальном лине. > Почему нет, собссно?! Или лагучая энергожоркая графика через ж@#у - наше > все?! Т.е. с тех пор ничего не поменялось, RGB у камер не прёт, идёт как у старых ПЗС, яркостной и два цветоразностных сигнала для сужения широкой частотной полосы. И уже потом на оконечном каскаде как у кинескопа на плате электронной пушки, уже 3 управляющих расшифрованных по 3-м основным сигналам цвета. Проблема в дешевых видеоматрицах камер?
	Ответить | Правка | Наверх | Cообщить модератору

	283. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 05:13
	> Т.е. с тех пор ничего не поменялось, RGB у камер не прёт, При чем тут камеры? Там про декодирование видео - а оно чаще всего в YUV представлении. В основном потому что R, G и B каналы обладают ломовой избыточностью (общая структура у всех трех одинакова). Поскольку видеофайлы здоровые by design, этот вариант представления, позволяющий заметно убавить ворочаемые данные там в почете. И на выходе декодера большая часть видиков даст - ну вот это. Стыковка этого с другой RGB картинкой софтварными методами ессно потребует конверсию формата и прочие прелести. Нифига не быстрые и дешевые по энергии. А тут у железа просто разные "planes" (surfaces, framebuffers) есть. Более сложная структура фреймбуфера, несколько слоев. Железки при отправке в провод - умеют делать нечто типа простого хардварного композитинга, слепив эти surface'ы и в этом процессе конвертировав формат пикселей в тот какой надо вон тому монитору. Там все равно были возможны разные варианты и уметь конвертить требовалось и без вон того. Скажем в HDMI поток на монитор может быть как RGB так и YUV, и видяха ессно умеет конвертить на случай если формат фуфера VS монитор не совпадает. > идёт как у старых ПЗС, яркостной и два цветоразностных сигнала для > сужения широкой частотной полосы. Сейчас у матриц байер обычно. По соображениям удобства производства матрицы. Однако это довольно экзотичный формат с которым напрямую вообще мало кто и что работает, а в матрицу или железки рядом может быть встроен чип конвертора, делающий из этого нечто иное, сделав дебайер в железе. > 3-м основным сигналам цвета. Проблема в дешевых видеоматрицах камер? Там вообще другой формат данных нынче нативно - байер. Где в одной линии есть красный и зеленый, а в следующей зеленый и синий. И это как бы сказать "не совсем RGB". У него зеленого в 2 раза больше чем синего и красного. Но именно его вывешивают не особо часто, это в основном для фот практикуется, так называемых RAW. В силу экзотичности формата с ним умеет работать лишь некоторый специализированый софт. Для видео это как-то не прижилось. И там даже нежатый сигнал уже после дебайера и конверсии - в YUV или реже RGB. Но этот поток чаще всего видит только некий хардварный энкодер, особенно в мобильных девайсах, с крутой камерой. Ибо вы опупеете с такого потока и его кодирования в реалтайме энным кодеком.
	Ответить | Правка | Наверх | Cообщить модератору

174. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
Сообщение от Andrei Yankovich (?), 24-Фев-24, 13:37
Ну, так что бы мешало это играть - нет, все работает прекрасно и на Ubuntu и в SteamDeck, я даже видел что челики жаловались что видузятные подделки под SteamDeck разряжали батарею в разы быстрее чем SteamDack. Так что подозреваю что стек нужно оптимазить - но это прям не значительные издержки.
Ответить | Правка | Наверх | Cообщить модератору

191. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
Сообщение от Аноним (191), 24-Фев-24, 16:36
Винду и ведроид ставит в примеры? Еретик!
Ответить | Правка | Наверх | Cообщить модератору

192. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
Сообщение от Капитан (??), 24-Фев-24, 16:46
Признание проблемы - первый шаг к ее решению!
Ответить | Правка | Наверх | Cообщить модератору

214. "Инженер из AMD признал, что графический стек Linux нуждается..."	–3 +/–
Сообщение от Sergey (??), 24-Фев-24, 22:19
Этому инженеру нужно пообщаться с windows, в linux всю работу за них сделали а в windows с дровами полный ж... любой виндузятник это подтвердит.
Ответить | Правка | Наверх | Cообщить модератору

217. "Инженер из AMD признал, что графический стек Linux нуждается..."	–1 +/–
Сообщение от Аноним (-), 24-Фев-24, 22:28
Из моих наблюдений. Хорошо видно в виртуализации. Где хост Windows, гость Linux как ведёт себя видеокарта. Видно в том числе по тому что в Windows есть HWiNFO (драйвер видекарты должен быть установлен) которая всё покажет в реальном времени и вольты и частоты и даже какая скорость задействована PCI-E шины. Включение 3D ускорения для гостя Linux видеокарта работает чаще на максимальных частотах. Не включаешь 3D ускорение  для гостя Linux не везде видеокарта работает на максимальных частотах и реже работает на максимальных частотах. А для Wayland как я вижу надо включать 3D, а x11 может и с 2D нормально работать.
Ответить | Правка | Наверх | Cообщить модератору

	277. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от cheburnator9000 (ok), 25-Фев-24, 21:52
	> Включение 3D ускорения для гостя Linux видеокарта > работает чаще на максимальных частотах. Я об этом постоянно говорил когда шло обсуждение про 3D/Video в линуксе на разных форумах, любой маломальский спецэффект на рабочем столе или плавная анимация чего-либо включает максимальные частоты, прокрутка в браузере, особенно в KDE/Xorg это видно. Под вендой все не так, под вендой GPU намного чаще работает на низкий частотах, включаясь только когда оно реально нужно, отрендерить youtube например, но после того как все загрузится уже на низких.
	Ответить | Правка | Наверх | Cообщить модератору

	286. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n00by (ok), 26-Фев-24, 07:02
	>> Включение 3D ускорения для гостя Linux видеокарта >> работает чаще на максимальных частотах. > Я об этом постоянно говорил когда шло обсуждение про 3D/Video в линуксе > на разных форумах, любой маломальский спецэффект на рабочем столе или плавная > анимация чего-либо включает максимальные частоты, прокрутка в браузере, особенно в KDE/Xorg > это видно. Как в "жирном" Gnome/Wayland такое увидеть? Radeontop показывает 10%...15% для Memory Clock и 0,15%...1% (изредка 3%, удалось зафиксировать максимум 4,72%) для Shader Clock (двигаю мышкой в левый верхний угол, что бы включить "обзор раб. стола", или как там это называется). Впрочем, Shader Clock увеличивается действительно в разы.
	Ответить | Правка | Наверх | Cообщить модератору

	307. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 17:43
	Когда я пользовался разновидностью Убунты с видеокартой NVIDIA, а это до 2022 года. Не одной программы показывающей частоты видеокарты не нашёл с Nouveau. А больше не чем из Linux не пользовался в не виртуализации. Насколько я помню перепроверить надо единственное ( я не нашёл другого) что показывает как меняются частоты видеокарты в зависимости от нагрузки это драйвер NVIDIA. С Nouveau у меня есть предположение, что частоты работают на постоянной цифре и не меняются в зависимости от нагрузки на GPU. Проверить я это не смог не нашёл программы которая это показывает если такая есть, похоже что нет. Напряжение для GPU чем посмотреть с Nouveau нашёл всегда было 0.93 Вольт.
	Ответить | Правка | Наверх | Cообщить модератору

	308. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 17:45
	До 2023, 2022 тоже. Установлено было. Обновлял только.
	Ответить | Правка | Наверх | Cообщить модератору

	312. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 19:03
	Возможно или скорее в сего ещё надо учитывать, что чем слабее видеокарта тем чаще будут подымается частоты до максимума. Предположение по тому, что я не когда не покупал мощные видеокарты в игры не играю, покупаю чем меньше размер и нагрев тем лучше мне, у меня Nvidia GT это Windows. А как в Linux пытаемся отгадать.
	Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

	313. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 19:06
	В Windows понижаются и повышаются чатоты и напряжение у видеокарт. Если это модели не совсем старые, не знаю с каого года выпуска для видеокарт такое сделали.
	Ответить | Правка | Наверх | Cообщить модератору

	316. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 19:22
	Так точнее: Nvidia GeForce GT.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	334. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от n00by (ok), 27-Фев-24, 08:38
	Это понятно, потому проверял на самом слабом варианте из современных дискреток. Со встройкой такой опыт провести сложнее, так как там например частота памяти может подниматься и центральным процессором.
	Ответить | Правка | К родителю #312 | Наверх | Cообщить модератору

	305. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 17:15
	Моё наблюдение. Так тенденция, как для меня это псевдокрависвости тени т.п. мне такое не надо в DE, как я понимаю делают через 3D. Поэтому в KDE отключение всевозможных эфектов в DE должно меньше задействовать видеокарту. Тем же путём пошол WEB, сайты и браузеры используют разновидности GL - WebGL.
	Ответить | Правка | К родителю #277 | Наверх | Cообщить модератору

	310. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 18:06
	разновидности OpenGL
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (230), 25-Фев-24, 22:52
	Ну если ничего кроме пары окон вам не нужно, то можно и без ускорения, но в реальном использовании без ускорения никуда ни с иксами ни с вяленным.
	Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

220. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (-), 24-Фев-24, 22:46
Браузеры для орисовки изображения делают с ращётом что у нас не виртуализация с плохо работающим виртуальным GPU, а полноценный 3D с реальной видеокартой. От этого и не так как задумано в браузерах работает отрисова изображений.
Ответить | Правка | Наверх | Cообщить модератору

246. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Zenitur (ok), 25-Фев-24, 07:46
А на проприетарном драйвере как было? Там GPU меньше грелся при декодировании. Даже по оборотам кулера видно.
Ответить | Правка | Наверх | Cообщить модератору

	276. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от cheburnator9000 (ok), 25-Фев-24, 21:41
	Под линуксом у меня некоторые игры играют с меньшей нагрузкой на GPU (Nvidia) под vulkan чем под вендой, но с большей нагрузкой на CPU (возможно из-за wine, но не факт), видеокарта холоднее - кулер тише, но не на CPU. А если смотреть фильм и на нагрузку Video Engine (де/кодирование) в nvidia-settings всегда работает и 3D Engine тоже в равной степени нагружен, ровно как и сотрудник рассказывает под AMD. Им нужно объединиться, Valve, AMD и Nvidia пусть уже наконец придумают для линукса еденную прослойку/библиотеку, которая хоть Wayland-only и пусть через нее цепляют все драйвера хоть закрытые хоть открытые, VDPAU/VAAPI видимо для этого не годятся иначе как-нибудь раньше они эту проблему решили.
	Ответить | Правка | Наверх | Cообщить модератору

	295. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (292), 26-Фев-24, 08:59
	Для AMD ещё профит есть, а нвидии оно зачем, чужую работу делать?
	Ответить | Правка | Наверх | Cообщить модератору

	297. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от cheburnator9000 (ok), 26-Фев-24, 11:56
	> Для AMD ещё профит есть, а нвидии оно зачем, чужую работу делать? Иначе мы получим очередную порцию не совместимых прослоек.
	Ответить | Правка | Наверх | Cообщить модератору

	298. "Инженер из AMD признал, что графический стек Linux нуждается..."	+1 +/–
	Сообщение от Zenitur (ok), 26-Фев-24, 12:34
	Поясню свой вопрос. Но сначала - вольное отступление. В ноябре 2010 года я приобрёл ноутбук Acer на базе графического чипа Radeon Mobile HD 4250. Я там сразу собрал гентушечку (ох уж этот оверлей kde-sunset, всё время пришлось допиливать напильником), короче, гентушечка в итоге собралась, система оказалась готова к использованию. Я использовал оба драйвера: radeon и fglrx, переключаясь между ними при помощи eselect opengl set 1. Ну и подменой /etc/X11/xorg.conf, разумеется. Драйвер fglrx демонстрировал 64 градуса в простое. Драйвер radeon демонстрировал 80 градусов в простое. ЧТО ЗА ФИГНЯ? Наверное, причина была всё-таки в проце: это был не Atom с тепловыделением в пару ватт, а AMD поколения K10. Но GPU явно подогревал общую температуру... Уже потом, в 2013 году, я установил операционную систему Linux Mint 16 (базируется на Ubuntu 13.10). Там была MATE на базе GTK2 (в 17 версии переедет на GTK3). Драйвер уже был только radeon (fglrx дропнул мой чип в 2012 году, последние дрова были выпущены в январе 2013). И вдруг новость! В открытый драйвер добавили энергосбережение! Я подключаю Oibaf PPA, ставлю новый драйвер, добавляю dpm=1 в загрузку... А вот нихрена. Получше, чем было, но... Ноут всё равно грелся сильнее, чем с закрытым драйвером! Может быть, новость как раз об этом и была? Далее, VA-API. На протяжении всего 2011 года я смотрел ютюб при помощи youtube-dl, потому что в браузере он тормозил. Ну, как тормозил, в 360p приемлимо, но не идеально. Далее, я с сайта Splitted-Desktop качнул libva, пропатченный Интелом (последняя версия ихнего форка вышла в феврале 2011, потом все начали пользоваться ванильным libva с сайта freedesktop). Качнул драйвер, который заставляет fglrx поддерживать VA-API. И пропатченный mplayer. Всё стало настолько гладко и тихо! Смотрю фильм, а проц на 1% загружен... А потом i-Rinat сделал враппер, позволяющий смотреть видео в браузере через VA-API... Вообще красота стала! Воооот. Но потом я накатил Linux Mint 16 и лишился VA-API вообще. Открытый драйвер не поддерживал VA-API! И вдруг выходят новые дрова (всё те же, которые добавили DPM, энергосбережение) с поддержкой VDPAU! То есть, теперь можно пользоваться флешем без враппера от i-Rinat. Я запускаю видео в разрешении 720p и... оно тормозит. Без VDPAU кадра три в секунду. С VDPAU ну кадров 15... Честно, я не знаю, что было потом. Улучлиши ли драйвер? Может он теперь тоже не греет ноут, выдавая 64 градуса? Может он теперь нормально ускоряет VDPAU и VA-API, давая 1% при просмотре 1080p? Проходит 10 лет. Я вставил в свой стационарный комп - видеокарту ATi Radeon R9 290X. Она с отвалом, если на холодную включить игру, будет зависание компьютера. Не важно, с каким именно драйвером: fglrx или radeon. После ресета всё приходит в норму: карта прогрелась и не виснет. И вот, использование VA-API на fglrx делает карточку холодной, а на radeon - горячей. На fglrx обороты кулеров поднимаются едва заметно. А на radeon - воют, как будто бы я запустил игру. Понимаешь о чём я? Возможно, инженер из AMD говорит именно об этом. Он про воспроизведение видео говорит, или про вывод изображения на экран? Если про воспроизведение видео, то могу констатировать, radeon/amdgpu греет карточку сильнее, когда я смотрю 1080p при помощи mpv. Чем fglrx, когда я смотрю при помощи mplayer-vaapi.
	Ответить | Правка | К родителю #276 | Наверх | Cообщить модератору

	299. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от cheburnator9000 (ok), 26-Фев-24, 12:51
	Все именно так и на nvidia если сравнивать линукс и windows. Сейчас проверял и случайно выяснил что у меня НЕ работает декодирование под вендой в firefox! https://i.imgur.com/t2pYLmG.png хотя должен быть и vp8,9,HEVC тоже.. У меня давно был ноутбук на Nvidia 310M если честно на ней было без разницы открытый драйвер или закрытый, оба грели GPU адски, ноутбук дешманский ацер с плохим охлаждением, но под вендой все же холоднее (не на много), любой чих спецэффектов в KDE и сразу турбо-частоты.
	Ответить | Правка | Наверх | Cообщить модератору

	301. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Zenitur (ok), 26-Фев-24, 14:23
	У меня ноут Intel HD 4000 + NVIDIA GeForce 650M. Изначально использовал в конфигурации PRIME, хотя и в Bumblebee тоже пробовал использовать. Потом вышли иксы 1.19 с поддержкой PRIME Syncronization. Потом вышли иксы 1.20.7 + патчи из стороннего PPA (в мануале PRIME Offloading от NVIDIA есть ссылка), стело можно использовать PRIME Offloading. С тех пор пользуюсь. Греется, ну а что поделать. Зато не тормозит.
	Ответить | Правка | Наверх | Cообщить модератору

	303. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (303), 26-Фев-24, 14:41
	> Все именно так и на nvidia если сравнивать линукс и windows. Сейчас > проверял и случайно выяснил что у меня НЕ работает декодирование под > вендой в firefox! https://i.imgur.com/t2pYLmG.png хотя должен быть и vp8,9,HEVC тоже.. > У меня давно был ноутбук на Nvidia 310M если честно на ней > было без разницы открытый драйвер или закрытый, оба грели GPU адски, > ноутбук дешманский ацер с плохим охлаждением, но под вендой все же > холоднее (не на много), любой чих спецэффектов в KDE и сразу > турбо-частоты. Windows 10 LTSC? Там кодеки надо вручную ставить.
	Ответить | Правка | К родителю #299 | Наверх | Cообщить модератору

	311. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от cheburnator9000 (ok), 26-Фев-24, 18:33
	И действительно, так вот почему обычная венда при запуске скачивает VP9/HEVC Video Extensions...
	Ответить | Правка | Наверх | Cообщить модератору

	333. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 27-Фев-24, 08:11
	Когда корпорации объединяются, они обычно придумывают SurfaceFlinger. После этого с юзабилити и ресурсоёмкостью можно попрощаться.
	Ответить | Правка | К родителю #276 | Наверх | Cообщить модератору

275. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от cheburnator9000 (ok), 25-Фев-24, 21:40
А как в варианте "как должно быть" происходит коррекция видео через плеер? Ну там контрастность, яркость, гамму, резкость поменять? Под вендой potplayer делает это и через DXVA или сам?
Ответить | Правка | Наверх | Cообщить модератору

	290. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (292), 26-Фев-24, 07:49
	Аппаратной коррекции цвета на видеокартах лет двадцать как минимум.
	Ответить | Правка | Наверх | Cообщить модератору

300. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (300), 26-Фев-24, 12:52
В конце "как должно быть" цепочки типичный энтерпрайзный комбайн с потенциалом к тивоизации. Нет уж, мы как-нибудь с неэффективным стеком посидим и на похоронах вашей корпорации еще спляшем.
Ответить | Правка | Наверх | Cообщить модератору

	323. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
	Сообщение от Аноним (-), 26-Фев-24, 20:53
	О... какие же вы отбитые... > цепочки типичный энтерпрайзный комбайн с потенциалом к тивоизации. Чел наоборот все упростил, вместо нагромождения овна дефективных иксов. > и на похоронах вашей корпорации еще спляшем. Ну предположим... и что? Будете покупать невидию за дорого? Будете по помойкам шариться выискивая старые видяхи? Хотя это вы уже)))
	Ответить | Правка | Наверх | Cообщить модератору

336. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Tester (??), 27-Фев-24, 17:56
> Более эффективно это может быть решено в Wayland композиторах, но пока реализации нет Реализации нет? Значит это брехня!
Ответить | Правка | Наверх | Cообщить модератору

361. "Инженер из AMD признал, что графический стек Linux нуждается..."	+/–
Сообщение от Аноним (-), 31-Май-24, 12:26
Пора откапывать стюардессу (драйвер xf86-video-radeonhd). Его писали с особенностями новых Radeon-ов, уверен что и необработанный YUV может воспроизвести. М..дак David Airlie мешал разработке radeondhd, чтобы добавлять поддержку карточек hd-серии в обычный драйвер radeon. Зачем? Затем что radeon делают на деньги Red Hat, а radeonhd на деньги Novell - а David получает в RH зарплату. Вот и хаваем далеко идущие последствия.
Ответить | Правка | Наверх | Cообщить модератору

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

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