URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 132941
[ Назад ]

Исходное сообщение
"Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании"

Отправлено opennews , 23-Фев-24 23:29 
При  обсуждении ошибки, связанной с относительно высоким по сравнению с Windows потреблением электроэнергии на APU AMD с поддержкой аппаратного декодирования видео, инженер из AMD, Алекс Дойкер (Alex Deucher, основной разработчик драйвера amdgpu), признал, что отображение видео в Linux в принципе неэффективно...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=60656


Содержание

Сообщения в этом обсуждении
"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 23-Фев-24 23:29 
Wayland придёт, порядок наведёт?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено dannyD , 23-Фев-24 23:34 
это был сарказм (?)

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 23-Фев-24 23:38 
Да хоть бы кто-нибудь пришёл, займёшься?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено dannyD , 24-Фев-24 10:09 
тебе надо - сам займись.

меня и Х и консоль устраивает.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 21:54 
> тебе надо - сам займись.
> меня и Х и консоль устраивает.

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:08 
>> тебе надо - сам займись.
>> меня и Х и консоль устраивает.

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено dannyD , 25-Фев-24 21:11 
>>Иди предлагай

вот и иди .!..


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 05:19 
>>>Иди предлагай
> вот и иди .!..

Так это не мне надо, чудак. Мне все равно что с иксами случится. Я не буду скучать по этой свалке костылей и коду с testimonials вида "80 000 строк боли!" от фиксера, уж прости.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:53 
Ой, чейт все больше ощущение что вяленд почи такая же хрень как и иксы. В добавок еще и сыроватая.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 21:52 
> Иксы решали сугубо свои задачи и в юникс-мире в целом всех устраивали.

Только этот юникс мир перестал всех устраивать - и бесславно сдох. А так все хорошо, прекрасная маркиза.

> Но поскольку линукс — не юникс

Вообще-то как минимум 1 из линухов был вот именно сертифицирован как юникс. Что иронично по многим параметрам, но так можно было.

> и даже не полноценный posix,

И сейчас нам эксперты покажут позикс полноценнее? :)

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

Иксы не вписываются в современную графическую архитектуру. By design. На самом фундаментальном уровне.

> Вяленд делают именно с расчётом на линукс, игнорируя всех остальных,

А они самоустранились из процесса и - вот - пиндят что их все устраивает. Ну раз все устраивает - пусть и сидят со своими костяшками, например?

> но его ещё делать и делать, он сам архитектурно плох и всё равно будет
> существовать в условиях мутирующих костылей.

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iZEN , 25-Фев-24 12:27 
> Архитектурно он маппится на современный хардвар на порядок лучше иксов. Одно это
> уже ломовое улучшение. А иксы это та кобыла, которая умерла. Все
> хорошо, прекрасная маркиза. Правда свои типа-юниксы вы тоже - профакали.

User294, хватит шифроваться под Анонима.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 20:22 
> User294, хватит шифроваться под Анонима.

Вау, Изен! Живой, собственной персоной.

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

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


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 19:41 
> ты там забыл отчитаться о разгромной победе btrfs везде

Это к графону в линухе не относится. Но так то, когда вы в проде FB обслуживаете миллиарды, а WD приходит, нанимает тушек, комитит вам поддержку своих накопителей, и все такое - очевидно, авторы ФС все правильно сделали и надо продолжать в том же духе.

> и еще кучу разного бреда про одноплатники давно не пишешь, заболел или
> немного (но не достаточно пока еще) поумнел?

С таким бы ником да про интеллект то рассуждать... :)


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iZEN , 26-Фев-24 19:24 
> Ну, раз ты пришел, то можешь похвастаться что ты там не профакал.

Я забил на графику от AMD — я не смог завести интеграшку AMD760 на последних версиях драйверов серии xf86-video-ati. Это для меня оказалось поистине непосильной задачей. Intel и AMD наконец-то добились своей цели: пользователи бессильны перед их выкрутасами с DRI/KMS ради поддержки Wayland.

А что там у тебя с победой Btrfs? Оно ещё живо?



"Инженер из 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 где оно обслуживает миллиард юзерей это фигня.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iZEN , 12-Мрт-24 21:14 
>> А что там у тебя с победой Btrfs? Оно ещё живо?
> У меня целый небольшой флот одноплатников на этом. Около пары сотен юнитов
> суммарно. Работает, куле. Но по сравнению с FB где оно обслуживает
> миллиард юзерей это фигня.

На вот почитай для разнообразия: https://overclockers.ru/blog/Hard-Workshop/show/143538/poche...



"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Xo , 24-Фев-24 10:49 
Пятой точкой чуешь? А если верхний мозг включить?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 12:48 
Да ну, ты хочешь сказать что графический сервер, который пилят уже 15 лет и который без примочек умеет лишь в простые геометрические фигуры - ХРЕНЬ?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено некая_ычанька , 24-Фев-24 15:43 
>сыроватая

Сыровяленая.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 27-Фев-24 04:59 
Все гораздо хуже. Вялый еще большая хрень. NIH-синдром, вагон не совместимых с друг другом реализаций, отсутствие понимания что должно получиться в конце и, как следствие, костылинг всего и вся.
Лучший вариант — закопать вяленого, учесть шишки от граблей и запилить вменяемый X12.
Десяток лет писания оного старые добрые иксы вполне себе протянут.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:07 
> Wayland придёт, порядок наведёт?

Забавно, но ты прав.
Иксы, в силу своей убогости, не могут так как вейланд:
"It's generally not possible to use multiple planes in X, so this would be wayland only."


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:53 
А Вяленный дискредетировал себя сыростью и спешкой, отчего так и останется недопилком.

Ну, ок. Похоже на правду, пока что.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Chel , 24-Фев-24 20:45 
Это вообще-то набор протоколов

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Илья , 24-Фев-24 21:43 
А в каких дистрибутивах сейчас вейленд не по-умолчанию?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 21:57 
Fedora

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Dima , 28-Фев-24 11:16 
В Федоре вайланд давно по умолчанию.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 08:19 
> Wayland не могут работать

Забавно, но нет.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 03:40 
> Wayland придёт, порядок наведёт?

Он может. Потому что архитектурно он сделан так как работает железо. Он менеджер буферов-surface'ов по сути.

Это именно то что надо чтобы воооооон то получить. Surface flinger и проч - под видео выделяет отдельный хардварный surface, который сразу в YUV - и эта штука сейчас есть и в мобильных GPU, и в десктопных. На wayland это не особо сложно приделать, это логично маппится на его архитектуру согласования буферов. Просто приделать какое-то расширение когда прога может согласовать не абы что и через композитор а хардварный surface под видео, и все завертится.

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

...ну а Xorg - он вообще такими концепциями не оперирует и страшно далек от этого всего. Там динозавры на переходе удивленно смотрят на мамонта - что это за инноватор в шкуру вырядился?!


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 10:47 
> Извини, но это чушь. В Иксах черт знает с каких времен есть расширение XVideo с поддержкой аппаратных YUV сурфейсов.

Ну-ну, а разве иксы могут в несколько planes, ну и чтобы часть из них были YUV, а часть RGB?
Расскажи нам и вон тому чуваку из АМД, может мы все просто не в курсе!


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:33 
> Ну-ну, а разве иксы могут в несколько planes, ну и чтобы часть
> из них были YUV, а часть RGB?
> Расскажи нам и вон тому чуваку из АМД, может мы все просто не в курсе!

А это как раз тот самый инноватор который в волосатую шкуру на переходе вырядился, пытаясь доказать дино что они устарели :)


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 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-х. Всегда считалось, что это самый оптимальный вывод видео (но видео не будет видно на скриншоте).


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 20:35 
> Не совсем понял, а как оно сейчас работает? Ну если у тебя
> медиаплеер делает окошко с opengl и собирается шейдерами (или вообще на
> CPU) конвертить yuv->rgb, то причем тут XVideo?

Ну так АМДшники и написали для бакланов - такие маневры видите ли апскейлят частоты GPU и он жрать начинает. Есть какие-то проблемы с чтением новости? При том это бессмысленное и беспощадное действо сушествует по причине "абстракция такая".

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

> Если плеер выводит через XVideo, то оно и выводится через хардверный конвертер
> нужного yuv-цветового пространства в RGB. Это и есть аппаратное ускорение XVideo.

Ага, теперь расскажите как туда выхлоп ХАРДВАРНОГО ДЕКОДЕРА ВИДЯХИ загнать в эффективном виде?! Если вы декодировали на CPU у вас, конечно, нет этой проблемы ибо когда проц молотил со всемй дури - про экономию питания речь не шла один фиг. Но если видео распаковал хардварный декодер, а сервисный обвес операции начинает жрать больше энергии чем сама операция, это начинает несколько напрягать, вызывая нездоровые лулзы.

> Несколько окон плееров можно открыть и в каждом окне выводится своё видео
> - хочешь в yuy2, хочешь в yv12, в чем хочешь выводит.

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

> Вот адаптер 1 именно по описанному мной алгоритму работает. И работал так
> с середины 90-х. Всегда считалось, что это самый оптимальный вывод видео
> (но видео не будет видно на скриншоте).

Это в ваших серединах девяностых и считалось. С тех пор придумали ряд идей сильно получше. Типа хардварного surface'а в железе, в который к тому же хардварный декодер сам в лучшем случае и будет рисовать. А железо потом слепит эн surface'ов перед посылкой в провод. Нечто типа простого хардварного варианта композитинга.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Anonymous1 , 24-Фев-24 12:54 
> есть расширение XVideo с поддержкой аппаратных YUV сурфейсов.

И что же, зачем нужны все остальные расширения для вывода видео? Почему бы не оставить одно распрекрасное расширение, чтобы всем было хорошо? Может, потому что не всё так прекрасно, как ты пишешь?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 16:06 
А в вяленде что, не вокруг расширений базового протокола всё крутится?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 23:24 
> А в вяленде что, не вокруг расширений базового протокола всё крутится?

А как вы вон то предлагаете обыграть то? Вбить прям в core вяленда жесткий requirement к фичам хардвара - уметь все вон то, со всеми наворотами? Тогда тоже порядком народа резко взвоет, особенно учитывая что воон то, в воооон теми constraints надо было - не всем.

Дизайн софта - это всегда некий набор компромиссов.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:05 
> Извини, но это чушь. В Иксах черт знает с каких времен есть
> расширение XVideo с поддержкой аппаратных YUV сурфейсов.

А еще этот кусок невменяемой блевотины, ушибленной на весь мозг - никому не нужен уже лет как десять. Потому что работает так, что проще через GL или Vulkan рисовать. Хоть плеер и не трехмерная программа, зато иксы - вместе со всей их горбатой бловотой за бортом и проблем сразу в 20 раз меньше и перфоманс в разы лучше. Почему-то. Хоть гнать кадры видео как текстуры и несколько изврат. Зато - цуко работает и цуко лучше.

Но вы можете использовать это угробище - если оно для вас работает.

> То, что оно работает не со всеми дровами - это вопрос к производителям самих дров

Вопрос скорее в том как это угробище вообще работало. За что и выпало из фавора.

> (и к автору новости, который написал, что в Иксах это якобы невозможно).

Вы настолько некомпетентны что не в состоянии понять что именно вам писали амдшники насчет графического пайплайна.

> https://people.freedesktop.org/~mslusarz/nouveau-wiki-dump/X...

Последнее обновление этой паги в 2013 году (всего 11 лет прошло!) - вместе с высокоинновационными family нвидий (последний писк какого именно года, не уточните?) как бы намекает. В 2013 все еще только начиналось. И там вон то еще даже чуть трепыхалось.

Сейчас этот кусок крапа просто мертв. Забудьте про это. Букмарки надо иногда апдейтить. Ваша кобыла давно умерла. И плееры уже на нее почти забили. Такой видео-тормозятор и видео-глюкатор никому не надо, сорян. Это жутчайшее легаси на данный момент, если оно еще вообще работает.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено AlexYeCu , 24-Фев-24 18:03 
>Просто приделать какое-то расширение

Забавно, но вот за такой подход к решению проблем фанаты Вяленого обычно ругают Иксы.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:16 
> Забавно, но вот за такой подход к решению проблем фанаты Вяленого обычно ругают Иксы.

В вот этом конкретном случае иксы скорее просто внутренними абстракциями не вышли. Там на гвозди прибиты совсем другие идеи о том что такое графическая подсистема и как это работает.

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено жорик , 24-Фев-24 16:00 
меня все устраивает.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено User , 26-Фев-24 08:33 
Да хрен знает. Не очень понятно, кому и насколько оно вообще надо. У тех, кому НАДО - оно есть и работает, шо у ведроидов, шо у всяких вебос уже свои слои костылей. А проблемы юзеров линуксодесктопа нннууэээ... вот.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено НяшМяш , 23-Фев-24 23:53 
Онаним новость не прочитал и сделал неверные выводы. Никогда такого не было и вот ещё один.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено ваноним , 24-Фев-24 05:46 
> Никогда такого не было и вот ещё один.

Да раньше надо было "правильное" железо купить или на линуксе нихрена не заведется. А тебе еще и плюсы наставили :)


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:56 
> Линуксокодеров или производителей железа, которые свои железки не поддерживают в линуксе?

Мда... ну допустим всё производители железа ринуться писать поддержку для линукса.
Как это изменит нынешний порядок операций в ядре?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:12 
Всмысле как? Изменят нынешний порядок в ядре. Как по-твоему Интел коммитил KMS в ядро?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:53 
> Как по-твоему Интел коммитил KMS в ядро?

Я не прашивал как. Я срашивал "какого?" то, что "ни X.org, ни Wayland не могут работать с YUV-потоками напрямую" должны исправлять амдщники.
Это не их задача.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 08:41 
Не «не могут», а «не реализовано». Только в Wayland это делается естественным образом, а в Xorg через ж

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено анонимоус , 24-Фев-24 09:44 
> Это не их задача.

Он жалуется что их железо не работает как надо. Чтоб их железо заработало, кто-то за них должен решить задачу?


"Инженер из 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."

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено 128557 , 24-Фев-24 13:43 
Это надо делать только для железа от AMD? И как тогда уживается железо от Intel и Nvidia, логичный Вы наш?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 15:02 
Вполне возможно, что железо от Intel и Nvidia имеют теже проблемы, что и AMD, только молчат об этом, потому что их никто не спрашивал

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 14:31 
А я вот вообще не вижу проблемы: почему линуксоиды на голом энтузиазме просто не напишут правильные реализации и запушат патчи в апстрим — опенсорс же.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено AlexYeCu , 24-Фев-24 18:06 
>Не правда. Их железо прекрасно работает в нормально написанных системах.

Напр. в винде и андроиде

Бггг. Видел я, как оно в Винде работает. Как в Андроиде не видел — это что-то из серии «x86 Андроид в виртуалке»?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:08 
В новых Exynos видео ядро от amd.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iPony129412 , 24-Фев-24 04:19 
> Для винды поди сами написывали

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено анонимоус , 24-Фев-24 09:48 
>  ради мизерной аудитории

Так аудитория мизерная потому, что их железо плохо работает


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 17:34 
> А железо плохо работает, потому что дров нет. А дров нет, потому
> что не пишут.
> И если посмотреть на этот круговорот импотенции, то можно увидеть, что писать
> дрова под линукс — занятие ну просто малоприятное. Поэтому дрова под
> линуксом в массе своей рожают крупные железные конторы, а вот под
> всякими бздями люди умудряются писать обычные кодеры. Уже это должно намекнуть,
> что проблемы носят архитектурный характер.
> Вспомните, сколько амуде пришлось затащить в ядро, чтобы иметь возможность более-мене стабильно
> делать свои дрова. Не от хорошей жизни.

В Линуксе надо постоянно бежать за ломкой API в ядре - в Windows ты нежно и спокойно работаешь с одним и тем же API лет 10 подряд, а то и больше. WDDM практически не менялся с Windows Vista, которой скоро 20 лет.

Понятное, что Линукс разрабы не успевают и всё это выливается в тонне ошибок и регрессий.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено mos87 , 26-Фев-24 07:12 
>в Windows ты нежно и спокойно работаешь с одним и тем же API лет 10

бггг


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:09 
Видеокарты от AMD самые беспроблемные под Linux.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Слава Линуксу , 24-Фев-24 06:51 
Линукс-общество сами выбрали такой путь - мы все сами. Вот пусть и расхлёбывают. А майки это многомиллиардная компания, они денег дадут на это и все будет готово. Решает рыночек. Проснись, а то насмотрелся на Ютубе видосиков про свободное сообщество нетакусиков...

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 07:40 
Тут причина в кривых АМДешных дровах в 5 млн строк.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iPony129412 , 24-Фев-24 07:54 
Как-будто хадача декодирования видео в линуксах работает отлично на AND и Nvidia.
Дело было не в бобине.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:30 
Причина проста. No money, no honey.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено ы , 23-Фев-24 23:49 
Может это тонкий намёк Valve? :)

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:35 
А валв тут при чем?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено ыыы , 24-Фев-24 02:50 
Ооо, давно заметил такую тенденцию. У них в опенсоре никто никому не должен. Но как только появляются реальные рабочие руки, делающие дело, то на них сразу хотят повесить все свое хотелки.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено soarin , 24-Фев-24 06:04 
У них много денег. Их Steam Dеck работает на AMD.
Им бы хорошо, чтобы на нём можно было эффективно смотреть видяшки.
И значит – отдувайтесь за всех 🙂 Ещё бы и Flatpak занялись бы – "отняли" бы у RedHat.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 14:10 
>Ещё бы и Flatpak занялись бы – "отняли" бы у RedHat.

Чтобы что?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:06 
Чтобы занялись.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено AKTEON , 23-Фев-24 23:50 
Мелочная  бездуховность  индустрии
"
    Сжатый видеопоток
    VCN
    Сырые YUV данные
    Контроллер дисплея, который будет преобразовывать палитру, масштабировать и отображать. "
Благолепный академизм
"


    Сжатый видеопоток
    VCN (модуль аппаратного декодирования видео для GPU AMD)
    Сырые YUV данные
    Конвертация палитры, масштабирование на модуле GFX (по сути 3D акселератор в GPU, что заставляет его повышать частоты работы ядра и VRAM)
    RGB данные
    Вывод на дисплей. "


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:36 
Что сказать то хотел?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:14 
Это правка к новости или что?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 23-Фев-24 23:54 
Ставьте оболочкой windows 11. Все в нем работает. Чего мудрить?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:01 
В лиунсе тоже работает, и надежность с безопасностью выше. Просто в графическом режиме видео карты немного больше потребляют. Ну так не гамай.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:57 
> и надежность с безопасностью выше

Как говорил Бендер Родригес:
  Ахаха! Погоди, ты это серьезно?
  Тогда я буду смеяться еще громче!

Читая каждые почти каждую неделю про очередную дыряшку в ядре с повышением привилегий, про вечные уязвимости su/sudo/suid и прочих костылей, про дырки в хорг'е живущие по 30 лет...
Что-то меня терзают смутные сомнения.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:22 
Смех без причины, Билли, признак передёргивания. Всё познаётся в сравнении:

1. https://blog.qualys.com/vulnerabilities-threat-research/2023...
2. https://www.cvedetails.com/top-50-vendors.php

Так что да. Дыряшка та еще. ^_^


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:30 
Ты читаешь про исправления, в том числе и мелких багов и багов, которые существуют чисто теоретически. И все равно исправляют. И находят это благодаря открытости исходников и благодаря тому что Линукс это серверная система №1 и внимание к ее надежности колоссально. Винда же закрыта и МС не заинтересован в афишировании дыр, и поиск их и успешность удаления вызывает сомнения, тем более -  кодят индусы.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 08:23 
Фермы на чем? Вот и ответ на вопрос эффективности. А выше - офтопик тролли (как проплаченные, так и инициативники), да и "новость" тоже.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:54 
> Ставьте оболочкой windows 11. Все в нем работает. Чего мудрить?

Да просто не нужно. Потому и не сделано. Очевидно ж. Ненужно=не_сделано.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 23-Фев-24 23:55 
А что мешает взять из андройда реализацию ?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:38 
Это невозможно, там надо будет переписать 99%. Неужели не ясно?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 13:47 
Ну так сядьте и за пару недель перепишите, но нет - они буду ходить и годами ныть.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено sena , 01-Мрт-24 13:08 
Где "там"?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено ПомидорИзДолины , 24-Фев-24 00:58 
Насколько я понял проблема - на уровне протоколов XOrg и Wayland. Графический стек из андроида в линуксовый десктоп принести можно, но ни одно настольно приложение поверх него работать не сможет.


Плюс в андроиде графический стек построен прибит гвоздями к другим кускам рантайма (Activity и вот это вот все).


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено sena , 01-Мрт-24 13:07 
То есть тулкиты надо допилить? Qt под Андроид вроде бы уже есть? А то что старые приложения не будут работать это нормально. И иксовые приложения в вейланде без спец. поддержки со стороны вейланда не будут работать.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено ПомидорИзДолины , 25-Мрт-24 23:59 
> То есть тулкиты надо допилить? Qt под Андроид вроде бы уже есть?

Да, можно подпилить тулкиты и пересобрать вообще все. Другая проблема, что во время пересборки окажется, что приложения помимо фреймвоков дергают APIшки операционки напрямую. Все такие кейсы придется перепимывать.

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


> А то что старые приложения не будут работать это нормально. И
> иксовые приложения в вейланде без спец. поддержки со стороны вейланда не
> будут работать.

Сегодня иксовые приложения в вяленом работают. Обеспечить их поддержку поверх андроидного стека можно, но нужны хорошие инвестиции.



"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Мрт-24 02:30 
> Другая проблема, что во
> время пересборки окажется, что приложения помимо фреймвоков дергают APIшки операционки
> напрямую.

сисколы ядра линукса или бсди дергают? гуи приложения?

> Все такие кейсы придется перепимывать.

кейсы ^_^

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

не угрожай нам! >_<

> Сегодня иксовые приложения в вяленом работают. Обеспечить их поддержку поверх андроидного
> стека можно, но нужны хорошие инвестиции.

иксы пашут на андроиде. о чем ты вообще? что здесь происходит? O_o
Юзер, ты обдолбался?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено sena , 27-Мрт-24 12:32 
> Сегодня иксовые приложения в вяленом работают. Обеспечить их поддержку поверх андроидного
> стека можно, но нужны хорошие инвестиции.

X-Server под Андроид уже есть. Может допилить его надо...

https://play.google.com/store/apps/details?id=x.org.server&h...


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:20 
> А что мешает взять из андройда реализацию ?

То что у surface flinger'а как-то маловато фич для вот именно десктопа. Он совсем уж на минималочках, ну, можешь посмотреть какая оконная система в андроиде. Если это таковым вообще можно назвать.

А что, хочешь себе ТАКОЕ на десктоп? Если да - ну так андроид и накати?! Он для x86 бывает. Получишь желаемое!


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено sena , 01-Мрт-24 13:03 
А каких фич там не хватает? Окошки можно дописать при необходимости. При чём тут окошки?

Рчь идёт не о переносе Андроида, а только его граф. подсистемы, если она действительно хорошо работает.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:38 
Да у тебя, судя по всему, и клавиатура коряво буквы нажимает.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:27 
вот именно, он жмёт в надежде получить иероглиф, а получается кириллица

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 11:36 
Да ты прорицатель, я и правда на русском могу в японский.
Там и правда только английские символы заменяются,а русский язык пробивает их насквозь.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 11:37 
Ага, это андроидские загоны когда он ошибки выдает вместо нажатий.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 04:52 
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено omnonom , 24-Фев-24 00:23 
> Более эффективно это может быть решено в Wayland композиторах,

А может быть и не решено

> но пока реализации нет.

Ну то есть - безосновательная спекуляция.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:51 
> А может быть и не решено

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Анании.orig , 24-Фев-24 03:49 
> А вот в иксах оно даже в теории не получится - это все иксы переписать придется

Бредовые утверждение


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 10:54 
> Бредовые утверждение

"It's generally not possible to use multiple planes in X, so this would be wayland only."
Угу, расскажи это инженеру АМД))


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:23 
Архитектура wayland позволяет использовать одновременно разный формат поверхностей, а у X нет. Поэтому реализовать гораздо проще в wayland,а иксы придется переписывать что бы подобное заработало.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:33 
Не всем нужен графический стек, можно и в консоли сидеть.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено ПомидорИзДолины , 24-Фев-24 01:01 
Вот она, вся сила современного линуксоида: сидеть в консоли, программно декодировать видео, но ни в коем случае его не смотерть.

Не поняли в чем профит? А это некоммерческая организация!


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:35 
Правда! Я гляжу на свой  ATI Radeon Mobility M6 и плачу дважды: первый раз, когда вижу как он работает и второй раз, когда читаю комменты на опеннете.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено хрю , 24-Фев-24 00:54 
>>ATI Radeon Mobility M6

хммм это ж карта 20 летней давности. Тебе надо радоваться - то что она до сих пор работает уже чудо. Не?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено kusb , 24-Фев-24 20:04 
У меня есть компьютер с ati R 600 и она даже мощная и может работать, я надеюсь. Не включал несколько лет.

"Инженер из 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.

"Инженер из 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


"Инженер из 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 блока нет. Вот хоть там как.


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

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


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

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 27-Фев-24 06:21 
> Я прекрасно понимаю что себе я покупаю и для чего. Не всем
> нужны игры и просмотр видео с 4K или 8K.

Ну тогда и вон та хрень вам ни к чему, и чего мы тогда тут обсуждаем?

> мне подарили видеокарту уровня GeForce GTX четырёхтысячной серии я бы её
> продал или выкинул если бы не захотел заморaчиватся с продажей.

Ну так можно юзать какойнить интеграт и не париться.

> Такая огромная печка мне ненужна в компьютере, нет практичного для меня смыла,

На нее можно дофига вычислений спихнуть так то. Это уже давно generic вычислитель с видеовыходом так то.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 27-Фев-24 20:58 
Чего считать будем? Криптавлюту считать или пароли подбирать? Ушлые счетоводы видеокарты для этого не одну штуку используют, сотнями покупают видеокарты обедняют в кластер, тысячу или больше тысячи видеокарт в кластере используют.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 28-Фев-24 00:07 
> Чего считать будем? Криптавлюту считать или пароли подбирать?

А также всякие фильтры в FFMPEG, фоточки в darktable, ускорение в каком-нибудь CADе... ну да, кому это нужно? Явно не хомячкам с опеннета.

> Ушлые счетоводы видеокарты
> для этого не одну штуку используют, сотнями покупают видеокарты обедняют в
> кластер, тысячу или больше тысячи видеокарт в кластере используют.

Чтобы разговаривать о вкусе устриц надо их хотя-бы раз попробовать.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 28-Фев-24 03:25 
> Кому надо тот использует кому не надо нет. Я знаю, что что-то
> можно, но это всё ещё в массе людей не много. Как
> были основным предназначением мощных видеокарт обслуживать игры так и осталось и
> вся эта мощность для игр на первом месте и проектируются, чтобы
> вся это мощь могла обрабатывать очередную игру.

Осталось все это нвидии и амд обяъснить, а то что-то их а AI-акселерацию потянуло... странные игры какие-то - у половины видях аж видеовыхода нет.


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

"Инженер из 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. Это дает ученым, исследователям и инженерам возможность справляться с задачами, решение которых ранее было невозможно"


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 28-Фев-24 19:41 
"Знать надо" - если надо об этом знать не всем эта информация нужна.

"Инженер из 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%                            


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 21:19 
Не посмотрел, сразу что это S3 Virge. Подумал это что-то современное от AMD. А это видеокарта из 90 годов 1995г. "Ну тогда воткните S3 Virge, с 64 бит шиной разницы будет немного" Дорогой ты мой ребёнок иди ты лесом не нах, а лесом с своим выпендрёжом глупым сравнением. Я написал по хорошему без злобы.

"Инженер из 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МБ. Я даже не знаю, а есть в этот чип смысл больше памяти добавлять не пользовался такой видеокартой в наше время с нынишними операционными сситемами.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 21:56 
PCI-E не для скорости, а для совместимости, чтобы было во что вствлять. Так как S3 ViRGE сделана для PCI.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 28-Фев-24 00:39 
> PCI-E не для скорости, а для совместимости, чтобы было во что вствлять.
> Так как S3 ViRGE сделана для PCI.

Вообще-то в PCI, обычный, 32-битный, видеокарты упирались только в путь. Поэтому и появился AGP. А потом и PCIe, когда кривой переросток-костыль всех утомил.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 22:05 
Вариант с AGP был. Но сути это не меняет.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 00:53 
> Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании

На 20й год индеец Зоркий Глаз увидел что нет четвертой стены...

Да все и так знают что он нуждается в улучшении!
Тоже мне, Капитан Очевидность.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:14 
Не, весь сыр бор в том что под оффтопиком оно кушало 8.5 ватт, в под Fedorой - 13W.
Т.е если тебе не повезло, то твой ноут проживет на 50% меньше времени без розетки.
А это уже серьезно, брать ноут с батарейкой на 12 часов, чтобы его хватало на 8...
Проще уже с виндой взять.

ps я бы предположил, что все дело в лицензии и маленкие столлманы в̶о̶р̶у̶ю̶т̶ ̶е̶м̶а̶к̶с̶ы̶ экспроприируют ватты во благо коммун партии и мировой революции, но раз инджинер АМД уверен в том, что в линуксе граф стек просто овно... наверное он может быть прав.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:26 
>но раз инджинер АМД уверен в том, что в линуксе граф стек просто овно...

а почему конкурент из интела не овно он не знает...

>наверное он может быть прав.

не сомневайся, сомнение преступно.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:29 
А почему вы решили что Интел чем-то отличается, не удивлюсь что в интелах под Линукс просто нет мониторинга потребления втдеочипа, что бы пользователи даже не задумывались о проблеме.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено 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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 08:27 
> А это уже серьезно, брать ноут с батарейкой на 12 часов, чтобы его хватало на 8...

Проще уже с виндой взять.

Каждый устанавливает свои критерии. С таким Вам действительно проще ... взять.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено хрю , 24-Фев-24 10:26 
> Т.е если тебе не повезло, то твой ноут проживет на 50% меньше
> времени без розетки.
> А это уже серьезно, брать ноут с батарейкой на 12 часов, чтобы
> его хватало на 8...

Вы на ноуте при работе от акума часто фильмы смотрите? Максимум в самолёте или в сапсане, вам 8 часов не хватит ? Ну и вот, дальше сами додумаете. Есть гораздо более важные проблемы в линуксячей графике, чем раздутие 6.5 ватт.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:35 
> вам 8 часов не хватит?

Это если у тебя изначально батареи было на 12 часов.
А если на 8? Или на 6? Другой ноут покупать?

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

> Есть гораздо более важные проблемы в линуксячей графике, чем раздутие 6.5 ватт.

И это повод не говорить об этой проблеме?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:40 
Не покупай АМД и все!

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:57 
> Не покупай АМД и все!

Ну да, вас послушай и будет
"АМД не покупай - оно много жрет"
"невидию не покупай - там дрова проприетарные, а открытые глюченые"
"интел не покупай - там intelME"

Так проще выкинуть глючный лиинупс, чем отказываться от AMD.
Потому что в нормальных системах все работает.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 12:39 
В АМД свое МЕ, забыл как оно там. Так что нельзя покупать.
И глючная винда идет лесом.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:30 
Ты думаешь у Intel и Nvidia свой волшебный графический стек в Linux? Там та же проблема.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено 128557 , 24-Фев-24 13:57 
Очередной Евгений Вахтангович, постоянно разъезжающий в междугороднем автобусе, пишущий код тихонько, компилящий, доку читающий, и решающий параллельно сериальчик посмотреть.
Ржу, не могу от таких скоморохов. Чего из пальца не насасаны другие высокие материи? Внезапно решающий спеть оперу, станцевать балет и отправиться в космос ближний, и всё не покидая рейс дальний?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:14 
Ну надо же что-то отвечать на тупейшие вопросы типа
"Вы на ноуте при работе от акума часто фильмы смотрите?" - да часто, люблю взять ноут на балкон, сидеть в кресле и смотреть фильмец.

"Есть гораздо более важные проблемы в линуксячей графике, чем раздутие 6.5 ватт" - не 6.5 ватт, а 1,5 раза.
Гораздо большие проблемы это сборище некрофилов и копролитофилов - иначе бы хорг уже закопали и можно было бы сделать нормальную графику.

ps на твои пуки про оперу и дальний космос отвечать не буду, тк они превысили мою терпимость у человеческому идиотизму


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 00:11 
>пишешь код тихонько, доку читаешь
>И решил параллельно сериальчик посмотреть

Ну и как удаётся это совмещать?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 19:00 
Как удаётся мы можем видеть по новостям о CVE и жалобам на плозую документацию.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Kuromi , 27-Фев-24 21:22 
Так это всегда так было. Хочешь чтобы ноут работал долго - ставь винду, еще 10 лет тому назд говорили, под Линуксом батарея всегда жралась в полтора-два раза быстрее. Можно было конечно подкрутить частоту процессора, но не сильно помогало когда, например, блютус выключался в ОС но продолжал жрать энергию.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 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 ...

Подздравляю обладателей красных видеокарт. ^_^ И да, виноват линукс, и иксы, конечно же.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 01:12 
Иксы отбросили графический стек линукса на десятилетия назад.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:24 
Разумеется, для AMD. Патамушта лапки.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 01:41 
АМД тут каким боком? Дрова они хорошие запилили.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:51 
> АМД тут каким боком? Дрова они хорошие запилили.

Память 3 секунды? :-D Ну отмотай вверх, перечитай.

Не лишним кстати будет напомнить:

https://www.phoronix.com/news/AMD-5-Million-Lines

Еще раз мои поздравления красным.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 02:24 
Последний пост прочитай, у интела другая тема. Амуде нужно, чтобы композитор умел yuv хавать. Прямой рендеринг уже есть, хоть и багнутый.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:38 
Я тебе последний пост и цитировал. :-D

>Амуде нужно, чтобы композитор умел yuv хавать.

AMDу композитор танцевать мешает. Почему Intel не жрёт (конкурент, ёмаё) - он не знает. Но чукча не читатель, чукча писатель. Он уже нашел фатальный недостаток вейланда и иксов.)) Хорошо хоть в ядре им позволяют испражняться тоннами овнокода. Держим кулачки чтоб сломали иксы. Про вейланд молчу, он и так не работает.

>Прямой рендеринг уже есть, хоть и багнутый.

Как и драйвер AMD.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 03:04 
>Зачем им делать свои костыли, когда это должен api предоставлять?

Согласен. Тем более, что свои костыли у АМД получились плохими. Пусть сделают хоть кто-нибудь нормально за них. Только не опционально, прошу, есть тут разрабы вейланда? Сделайте принудительный вывод. Нам нужно порадовать пользователей/разработчиков графики и мультимедия. Все 3%. Ну, и обязательно депрекейт всех [s]radeon[/s] amdgpu драйверов, с аккселератором, слава богу он уже не нужен. ^_^

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

>Про вейланд вообще бред какой-то и про дрова, почему у меня тогда работает?

Ты серьёзно под новостью где у амд всё плохо пишешь что нет, всё хорошо? Всё хорошо, но дальше так жить нельзя? :-D


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 03:20 
Очень полезные комментарии набрасываешь, продолжай. Какой же амд плохой, одни дураки там работают.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 03:30 
> Очень полезные комментарии набрасываешь, продолжай.

Набросил тот, кто написал новость. И мы оба знаем почему.

> Какой же амд плохой, одни дураки там работают.

Зачем выдумываешь соломенное чучело? Я такого не говорил. А если ты думаешь что копроративный сектор автоматически рожает хороший код - то советую заглянуть в соседнюю новость про NetworkManager. Я там набросил ссылки на код красношляпых. Поверь, ты они так пишут, что ты в пьяном угаре такое не напишешь. Ну ладно, напишешь, но для себя любимого ты так софт писать не будешь. Да что там поверь - проверь.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 03:34 
И почему же?
Код, может, и не лучшего качества, но свободный, и во многих кейсах он работает хорошо.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 03:58 
> И почему же?

Срача ради, очевидно же.

> Код, может, и не лучшего качества, но свободный, и во многих кейсах он работает хорошо.

Код плохого качества не может работать хорошо. Это противоестественно.)) Впрочем, кому и кобыла невеста. Что до свободы - это его единственное преимущество, но из за вендорлока и это преимущество коту под хвост. Это абсолютно unmaintainable, как и системд кусок копролита. Который сдохнет сразу как закончатся на него деньги. ;-)


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 04:06 
Слишком много претензий к лучшей линуксовой графике, не находишь?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 04:09 
> Слишком много претензий к лучшей линуксовой графике, не находишь?

Причем от тех, кто сделал худший драйвер. Закономерно, не находишь?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 04:12 
Но они не делали драйвер для нвидии, ты что-то путаешь.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 04:54 
> Но они не делали драйвер для нвидии

дык они и собственный драйвер не могут починить, куда уж там. =)

P.S. Или кто-то в реальном времени отслеживает наше общение, или ты ставишь себе плюсик и мне минусик после каждого сообщения. Ахахах) Боже... Всё, я умываю руки.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 05:37 
Зачем им его чинить, если он работает? Поставил минус глупому посту.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 06:44 
>Зачем им его чинить, если он работает?

написал под новостью, где разраб амд расписался в неспособности снизить потребление amdgpu. Всё работает, жги)


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:12 
Привязка к железу - вредна. 21 век на дворе. Виртуализация. Доступ к экрану за тысячи киллометров.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 01:23 
И как ты получишь доступ к экрану за тысячи километров, если нигде никакой экран никуда не привязан? 21 век ведь.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено mumu , 24-Фев-24 02:08 
Объясните глупому, почему сразу в RGB нельзя? Откуда и зачем берётся YUV?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:11 
> Объясните глупому, почему сразу в RGB нельзя? Откуда и зачем берётся YUV?

Само видео изначально в YUV.
Соответственно его и получаем на выходе декодера.
Но граф. подсистема не умеет работать с ним и приходится перекодировать в ргб



"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:29 
YUV - это цветовая модель, альтернативная RGB,   это древняя вещь для аналогового телевидения. Почему-то она используется в видеокартах, в цифрой форме называется YCbCr. Почему не нравится  RGB не знаю. Но в Х-ах она есть.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 03:31 
А это не наследие древних времен? Ради совместимости? Я не уверен.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 04:26 
RGB возникла тоже неслучайно. Физиологические особенности зрения исследовали. И большинство других моделей также. А CMYK сложился из-за доступности пигментов.
Мне кажется YUV была удобна для аналогового телевидения, также накопилась масса видеозаписей, ну и решили раз работает не будем ничего менять, продолжим линию. Удобнее старое декодировать к тому же.
Если сейчас по-новому подойти к цифровой видеозаписи может другие методы появятся.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 09:59 
> RGB возникла тоже неслучайно. Физиологические особенности зрения исследовали.

RGB бесконечно далеко от человеческого восприятия, может хотел сказать CIELAB или HSV?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 10:12 
Не хотел. "бесконечно далеко" это явное преувеличение.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:50 
RGB — линейное пространство и очень плохо учитывает восприятие глазом, в том числе не учитывает яркостную составляющую. Всё это вылилось в кучу несовместимых профилей с разными коэффициентами и все не то.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Anonymous1 , 24-Фев-24 13:00 
И в другой модели, кстати, тоже не смогут работать иксы.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 03:43 
Значит будем ждать вяленого. Лет 10 ...

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:43 
> RGB возникла тоже неслучайно. Физиологические особенности зрения исследовали. И большинство
> других моделей также. А CMYK сложился из-за доступности пигментов.
> Мне кажется YUV была удобна для аналогового телевидения, также накопилась масса видеозаписей

Она позволяет основательно урезать объем данных или бандвиз в эфире, что примерно одно и то же, не очень сильно слив по качеству картинки. Потому что Y это яркость а U и V кодируют цвета - но это можно передать грубее чем Y и на типичном видеоконтенте никто не заметит особой разницы.

Вот на PC-generated графике - вы, конечно, YUV можете и не заценить. Особенно с subsampling типа 4:2:2 - он может цвета в скриншотообразном контенте основательно испортить местами.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 03:23 
Понятно.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:28 
> Объясните глупому, почему сразу в RGB нельзя? Откуда и зачем берётся YUV?

Видео чаще всего представлено в YUV формате. Это изначально связано с телевизионщиками и их потугами убавить объем передаваемых данных, но при переходе в цифру идея убавить размер видео почему-то всем по прежнему нравится - ибо нежатый видеопоток огромен.

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

Бывает даже что мониторы могут напрямую жрать YUV поток, скажем в HDMI есть такая опция, характерно для бытовухи типа теликов которым оно как-то более основное чем RGB с компа.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 03:22 
Значит одновременно существует и RGB и YUV? Первый для интерфейсов и второй для видео?

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Фняк , 26-Фев-24 01:06 
А по-моему yuv это не про физиологичность, а про обратную совместимость между цветным и чернбелым ТВ вещанием. Т.е. чтобы абоненты с чб приемником могли без проблем принимать изначально цветные передачи

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n00by , 26-Фев-24 06:49 
"Физиологичность" не мешает обратной совместимости. ЧБ приёмник игнорирует поднесущую, так что ему всё равно, что там кодируется. Был бы зрителю был важенее цвет, тогда бы инженеры думали, как кодировать цветовые компоненты, а не цветоразностные.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 27-Фев-24 06:29 
> Значит одновременно существует и RGB и YUV? Первый для интерфейсов и второй для видео?

У современной железки бывает несколько surface'ов при отрисовке на монитор, и в одном может быть RGB для гуя, а в другом YUV для вывода видео.

Железо при выводе в провод этого автоматически слепит сие, сконвертирует формат если надо на тот что в проводе, и даже сделает некий композитинг этого на минималочках. Так что воон там UI плеера это "GUI" с его RGB а фактическая картинка YUV, а на экране - они оба, с гуем поверх картинки, ибо surfaces так сетапнуты.

Ессно для этого фокуса - софт должен знать что такой фокус вообще провернули.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 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

В общем классический пример фрагментации.
Наплодили васяноДЕ и никто не хочет клпаться в этой куче.

Было бы круто, если бы вендоры выбрали два самых популярных ДЕ, а на всю остальную маргинальщину положили большой и толстый.
Ну и заодно бы дропнули некрожелезо.

Было бы море нытья, но оно хотя бы работало хоть где-то!
А то сейчас оно где угодно работает лучше чем в линуксе...


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 02:35 
Да, enlightenment и cde.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 12:56 
Было бы ещё круче если бы разрабы приложений и вендоры железа сказали нет вейланду и гномобанде.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 14:06 
Ахаха, и с кем тогда работать?
С васяндрами, сидящими в терминальной консоли?
Которые на все новое говорят "нинужна"?

Не, так оно не работает. Вендоры работают с теми, кто что-то делает - с вейландом и гномобандой.
А других у нас нет.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 14:13 
>Ахаха, и с кем тогда работать?

С теми, кто сможет, например, тот же стим доукомплектовать для дистрибутивов с несходящейся glibc без всяких флатпаков, режущих фпс. Линукс - не игрушка для инфантилов.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 15:17 
> Линукс - не игрушка для инфантилов.

Почему ж тогда среди пользователей Линукса их так много? Главная проблема в айти — инфантилизм. Остальные так-сяк можно решить.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:37 
Ни разу не эксперт, но хочу отметить пару моментов:

1. Почему Алекс решил, что видеопоток после декодирования должен сразу идти на вывод? Там ещё цветокоррекция и прочая постобработка. Конечно, в нормальных видеоплеерах (а не в софт гумне) это всё через шейдеры реализовано, но всё равно 3D-движок задействован.

2. Такое ощущение, что в линуксе проблема не в том, что на видеокарте кадры перекидываются туда-сюда (это должно быть очень быстро), а словно там ещё куча костылей и слоёв абстракции из-за которых декодированный кадр ещё тошнится через ЦПУ десять раз, и ещё сто раз в ядре потормозит на блокировках.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 02:51 
Это хардверное декодирование здорового человека, так задействуется меньше всего ресурсов. Для качества лучше вообще софтверно декодировать и рендерить качественным рендером, который тоже неплохо так ресурсы жрёт. Но слабые железки, тем более embedded, даже копирование не потянут.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 07:55 
> Для качества лучше вообще софтверно декодировать

Думал, этим только аудиофилы страдают.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 02:54 
В интеле такого потребления нету.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iPony129412 , 24-Фев-24 07:58 
Иноел на эту тему работает.
У них же и хромобуки.
VAAPI они и создали.
И в Chromium по этому делу ковыряются.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 03:14 
почему молчит nvidia? у них всё в порядке?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 03:25 
У них проприетарные nvenc/dec. Вулкан начали внедрять, но нвидии у меня нет, не знаю, где это работает.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 28-Фев-24 03:49 
Если ваше бревно не умеет в Vulkan, это только проблема новозного жука.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 28-Фев-24 06:52 
Можно метафоры попроще? Ничего не понял.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено soarin , 24-Фев-24 06:01 
так и в новости никто не орал, это просто обсуждение в багтрекере
Nvidia понятное дело, тоже имеет кучу проблем с линуксовыми приколами.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 04:00 
Оно умерло очень давно. Теперь по xvideo гуглится совсем другое.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n80 , 24-Фев-24 04:10 
> Оно умерло очень давно. Теперь по xvideo гуглится совсем другое.

Судя по выводу xvinfo на машине с intel (и тому что видео у меня таки играется без особого напряга для процессора), не совсем умерло. Другое дело, что у меня direct rendering без композитора, а выше заметили что нужна в композиторе поддержка. В такой постановке уже могу поверить в наличие проблемы, но уверен что тоже какое-то решение давно есть.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 04:15 
Ты уверен, что используешь xv, а не vaapi? Насколько древняя машинка?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n80 , 24-Фев-24 04:43 
> Ты уверен, что используешь xv, а не vaapi? Насколько древняя машинка?

Очень хороший вопрос, до этого был уверен, но сейчас включил отладочный вывод mpv и таки через VA-API основная работа идёт (ну т.е. по умолчанию используется vo=gpu, который уже под капотом дёргает vaapi и ещё кое-что, чтобы работали скриншоты и без мыла отрисовывался интерфейс/субтитры). А Xv хоть и работает, но только если его явно попросить и загрузка процессора в этом случае всё же чуть выше, не говоря уж про возможные проблемы с отрисовкой OSD/субтитров. Так что да, Xv действительно остался во временах вторых/третьих пней, хотя поддержка ещё есть, в принципе.

Но это я с названием ошибся (ОК, VA-API, а не Xv), а принципиальный-то момент остаётся: есть какой-никакой API для вывода YUV-оверлеев без лишних телодвижений и он даже отлично работает. Чего не хватает AMD, чтобы у них хотя бы так работало — хотелось бы понять.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n80 , 24-Фев-24 05:40 
> У тебя вывод идёт через рендер на vulkan или opengl, а они прямой хотят сделать, это разгрузит cpu и gpu.

По умолчанию через opengl, а минимальная загрузка CPU, вроде, при выводе через vaapi, хотя сложно сравнить, она даже через xv небольшая на фоне собственно декодирования сжатого видео.

Насколько можно сделать ещё прямее — посмотрим, буду знать про поддержку dmabuf в wayland.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 05:14 
vo=gpu работает, если ты не понял.

"Инженер из 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 звучит диковато, хотя и понимаю что так тоже возможно.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 05:45 
Декодирует vaapi, рендерит gl, всё понятно. В gpu-next рендерит вулкан, вроде как, проверь. Это позволяет использовать различные фильтры, шейдеры.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено mos87 , 26-Фев-24 07:21 
для gpu-next можно выбрать вывод vulkan

>Вулкан в логе не упоминался, да и хорошо это: судя по выводу vulkaninfo, у меня на основной машине он только через llvmpipe работает, думаю, из-за старого ядра.

кринж


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено name , 24-Фев-24 04:09 
Постобработка невозможна без копирования, кстати, а они хотят zero copy.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n80 , 24-Фев-24 04:15 
> Постобработка невозможна без копирования, кстати, а они хотят zero copy.

Смотря какая. Подкрутить яркость/контраст/насыщенность по запросу приложения-клиента GPU и сам может на лету. Что-то более сложное шейдерами делается, т.е. тоже нет смысла обратно с GPU в основную память через CPU гнать. Что-то совсем замороченное же в любом случае не будет zero copy, но это нормально же.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Tron is Whistling , 24-Фев-24 09:36 
Какая именно постобработка? Постобработка даже при copyback часто ведётся не в RGB.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Tron is Whistling , 24-Фев-24 09:39 
Даже слияние с субтитрами в D3D11 уже делается на GPU...

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:52 
> Что-то тут недоговаривают. Всю дорогу был Xv (X-Video Extension), который таки позволяет
> выводить YUV оверлеи в иксах без лишних преобразований, весь вопрос в
> том чтобы драйвер правильно заявлял таковую поддержку.

Что Xv что Xvideo - страшенные костыли, с зиллионами родовых травм. Это настолько кривые и проблемные субстанции что на них в общем то почти все плееры забили. Если выбор встает так, проще сплевывать кадры как текстуры GL или Vulkan оказывается, ибо так это и то многократно лучше работает.

> см. вывод xvinfo. Т.е. проблема, скорее, не в иксах, а в дровах AMD.

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

И если горе эксперты еще не заметили: КАК В ТО ГАМНО ВООБШЕ ИНТЕРФЕЙСИТЬ ХАРДВАРНЫЙ ДЕКОДЕР В ТЕХ КОНЦЕПЦИЯХ?! Там это не предусмотрено. И вон тот shortcut не получится. Вот хоть как.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 04:57 
> Один момент: Xv и XVideo — одно и то же.

Да и х с ним. На практике это работает - как кусок тормозного глючного гуано. Так что выводить через GL или Vulkan в обход иксов меньше оверхеда, глюков и тормозов. В тех случаях иксы тоже контент экрана могут и не видеть, это же не через них.

...но вон тот фокус, когда выхлоп декодера в yuv-surface железки спихивается без особого участия софта в процессе не получится ни так ни сяк. Для этого надо сетапнуть железо специфичным образом и - проинформировать софт в системе что такой сетап имеет место быть. Софт должен понимать, что рендер на экран - не то что он там себе думал, а вот такое вот теперь.

> А вторая вымирающая альтернатива называется VA-API и в рамках её концепции таки удобно
> использовать аппаратный декодер, для того Intel это и сделал изначально.

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

> Другое дело, что это сложно использовать для чего-либо кроме просмотра видосов,

Иксы в нужных для вон того абстракциях вообще не оперируют. Они не про менеджмент surface'ов - тем более хардварных. А вот вяленд - примерно это и делал, так что ему такую абстракцию подсунуть не будет огромной проблемой. Что-то поменять придется, но там нет ничего сильно стоящего на пути реализации такой фичи.

> т.е. не самый универсальный API. Но работает же. Но сделают лучше —
> я только за.

Ну вон там господа хотят "short circuit" уметь делать, с вон такой структурой пайплайна. Как это вяленду представить я догадываюсь, а как иксам - ну, если кто в курсе, пусть и покажет. Иначе будет вяленд-онли фичой.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 06:09 
Никто этому инженеру не рассказал, что открытые драйвера от AMD тоже нуждаются в совершенствовании, потому что 50% ядра занимать - это не дело?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 29-Фев-24 08:54 
> Никто этому инженеру не рассказал, что открытые драйвера от AMD тоже нуждаются
> в совершенствовании, потому что 50% ядра занимать - это не дело?

Все претензии - AMD Hardware Team! Кто виноват что они понастрогали дохреналион железок с дохреналионом регистров в каждой? Что хотите то и делайте, но без описания регистров железки - кина совершенно точно не будет. Вот вообще совсем! :)

Линуховые хидеры - автогенерятся из сорцов амдшных железяк. Что HW Team наваял - то и в хидерах. И да, думаете у остальных сильно лучше? Ах да, нвидия в своей норке просто не отсвечивает :)


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 06:16 
Пора писать юзерспейсный сервер для видимокарт и уже на него натягивать иксы или вяленого как протокол. А стянуть всё это по пути можно будет в netbsd/hurd.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:56 
> Пора писать юзерспейсный сервер для видимокарт и уже на него натягивать иксы
> или вяленого как протокол.

Внезапно MESA и Wayland примерно оно и есть. Поздравления, Кэп! DRM/KMS вообще так то рулит низкоуровенвыми аспектами работы железа. Типа видеорежимов, управления памятью, интерконект DMA всякий, вот это все.

> А стянуть всё это по пути можно будет в netbsd/hurd.

Угумс, заодно и покажете точные тайминги для page flipping какого-нибудь в юзермоде, без тиринга то, когда вас кернел может в любой момент - фьють! И конечно памятью GPU рулить из вот именно юзермода будет просто офигенно. GPU VM/MMU тоже наверное отлично оттуда сетапить, и перфоманс воображение поразит.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено какая разница , 24-Фев-24 07:58 
На неAMD все работает правильно?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 09:24 
Помнится мантейнер этих подсистем в Интел и вначале когда Амд драйвер писали, вместо помощи в пешее путешествие посылал. Может это политкорректная жалоба на прикормленных конкурентами мантейнеров.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Tron is Whistling , 24-Фев-24 09:35 
То есть понятия оверлея с отдельным цветовым пространством нет? Я не силён в графическом стеке, только консольные системы юзаю. Но если оверлея нет - это действительно треш.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Black , 25-Фев-24 22:17 
ИМХО аппаратных оверлеев вне профессиональных карт нет уже очень давно...

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Tron is Whistling , 26-Фев-24 20:58 
> ИМХО аппаратных оверлеев вне профессиональных карт нет уже очень давно...

Щито? Оверлей в принципе аппаратный, он для этого и существует, иначе от него толку нет.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:01 
>Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании

странный заголовок.
зачем такие заголовки? не надо.
в любой ОС стек нуждается в улучшении.
в линукс. в freebsd. в solaris.
в линукс тоже.
где-то там одно улучшение. где-то там другое.
не надо таких заголовков.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 22:58 
> странный заголовок.
> зачем такие заголовки? не надо.

Да это Ташкинов. Специфичный типок. ЧСХ, он таки и напорется за что борется. Ибо верещать может до упаду - но супротив вон тех это слон и моська.

> в любой ОС стек нуждается в улучшении.
> в линукс. в freebsd. в solaris.

Да эти 2 по сравнению с линухом вообще в ауте по графике, уж простите за честность.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 11:48 
Какой стек какого из linux? В 4K-телевизорах так то тоже linux с какой-то графикой.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 12:01 
> И конечно, как не приплести wayland в качестве универсального решения всех проблем

А почему сразу приплести?
Кто виноват что иксы настолько убогие, что даже в теории не могут решить проблему?

> ни одна из его реализаций не годится на качественную замену X.org

Уже как минимум две реализации прекрасно заменяют X.org.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено anonymous , 24-Фев-24 12:31 
> Кто виноват что иксы настолько убогие, что даже в теории не могут решить проблему?

В чём проблема?

> Уже как минимум две реализации прекрасно заменяют X.org.

Какие?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 12:48 
> В чём проблема?

Ты баг из новости вообще не читал? Проблему ненужной конвертации yuv в rgb. И как следствие - жор батареи.

> Какие?

KWin и Weston разумеется.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено 1 , 24-Фев-24 12:57 
It's generally not possible to use multiple planes in X, so this would be wayland only

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено petrg , 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 это не ваша работа.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 14:18 
>При этом, там где использование иксов действительно было плохим выбором (на мобильных) иксы давно и успешно заменили. Не на wayland.

И как у мобильников с энергоэффективностью в итоге получилось?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 23:00 
> И как у мобильников с энергоэффективностью в итоге получилось?

При проигрывании видео так то - получше чем у вон тех. Думаете гугол зря surface flinger пилил сам вместо того чтобы иксы взять? От хорошей жизни так не делают.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iZEN , 24-Фев-24 13:23 
Вот только не Дойкер, а Дойчер.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n00by , 24-Фев-24 13:52 
Если "eu" читается как "ой", то это похоже на Дойче Шпрехе, где "ч" записывается буквами "tsch". Тогда Deucher звучит скорее как Дойхер.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 14:08 
Посмотрите на YouTube записи с его докладами, он представляется именно как Дойкер, а не Дойчер.



"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 18:07 
Как он произносит своё имя на иностранном языке не имеет никакого занчения. Иностранные личные имена при переносе на русский язык должны транскрибироватся по правилам русского языка.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 18:20 
> Как он произносит своё имя на иностранном языке не имеет никакого занчения.
> Иностранные личные имена при переносе на русский язык должны транскрибироватся по
> правилам русского языка.

Нет такого канонического правила и, если посмотреть назад в историю, иностранные слова приходили к нам в самом разнообразном виде.

А после заимствования их часто ещё и ломали.

Например, "зонтик" стал "зонтом", хотя оригинал, кажется из голландского, не имеет ничего уменьшительно ласкательного.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 11:23 
>Нет такого канонического правила

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

>если посмотреть назад в историю, иностранные слова приходили к нам в самом разнообразном виде.

И что с того? Это отменяет правила русского языка?

>А после заимствования их часто ещё и ломали...

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


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n00by , 25-Фев-24 15:59 
>>Нет такого канонического правила
> Есть правила русского языка, в их числе правила транскрибирования имён собственных.

Всё, что нужно знать об учителе правилам:

"Правила транскрибирования" Результатов: примерно 4 170
"Правила транскрипции" Результатов: примерно 356 000

Просить ссылку на правила, понятное дело, даже и не стоит.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено iZEN , 25-Фев-24 12:29 
> Посмотрите на YouTube записи с его докладами, он представляется именно как Дойкер,
> а не Дойчер.

Можно ссылку на видео?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено pic , 24-Фев-24 13:28 
>Контроллер дисплея, который будет преобразовывать палитру, масштабировать и отображать.

Имеется ввиду контроллер матрицы LCD в мониторе, а передача сырых данных по видеокабелю в цифровом виде, или видеоадаптер в его оконечной части?


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 23:09 
> Имеется ввиду контроллер матрицы LCD в мониторе, а передача сырых данных по
> видеокабелю в цифровом виде, или видеоадаптер в его оконечной части?

Блок GPU в общем случае. Современные железки умеют держать под framebuffer более 1 слоя (hardware surface), слеплять их между собой при выводе, конвертируя формат пикселей, если надо, внутрях, и вот это уже - в провод.

Это не амд придумало, на мобильных девайсах такое уже сто лет. Ведроид в surface flinger этим сто лет пользоваться умеет. Технически при этом UI рисуется в HW surface в RGB формате, а результат видеодекодирования валится в HW surface с форматом YUV.

А амд тоже так захотелось, в том числе и на нормальном лине. Почему нет, собссно?! Или лагучая энергожоркая графика через ж@#у - наше все?!


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

Т.е. с тех пор ничего не поменялось, RGB у камер не прёт, идёт как у старых ПЗС, яркостной и два цветоразностных сигнала для сужения широкой частотной полосы. И уже потом на оконечном каскаде как у кинескопа на плате электронной пушки, уже 3 управляющих расшифрованных по 3-м основным сигналам цвета. Проблема в дешевых видеоматрицах камер?



"Инженер из 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. Но этот поток чаще всего видит только некий хардварный энкодер, особенно в мобильных девайсах, с крутой камерой. Ибо вы опупеете с такого потока и его кодирования в реалтайме энным кодеком.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Andrei Yankovich , 24-Фев-24 13:37 
Ну, так что бы мешало это играть - нет, все работает прекрасно и на Ubuntu и в SteamDeck, я даже видел что челики жаловались что видузятные подделки под SteamDeck разряжали батарею в разы быстрее чем SteamDack.

Так что подозреваю что стек нужно оптимазить - но это прям не значительные издержки.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 24-Фев-24 16:36 
Винду и ведроид ставит в примеры? Еретик!

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Капитан , 24-Фев-24 16:46 
Признание проблемы - первый шаг к ее решению!

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Sergey , 24-Фев-24 22:19 
Этому инженеру нужно пообщаться с windows, в linux всю работу за них сделали а в windows с дровами полный ж... любой виндузятник это подтвердит.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено cheburnator9000 , 25-Фев-24 21:52 
> Включение 3D ускорения для гостя Linux видеокарта
> работает чаще на максимальных частотах.

Я об этом постоянно говорил когда шло обсуждение про 3D/Video в линуксе на разных форумах, любой маломальский спецэффект на рабочем столе или плавная анимация чего-либо включает максимальные частоты, прокрутка в браузере, особенно в KDE/Xorg это видно.

Под вендой все не так, под вендой GPU намного чаще работает на низкий частотах, включаясь только когда оно реально нужно, отрендерить youtube например, но после того как все загрузится уже на низких.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n00by , 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 увеличивается действительно в разы.


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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 17:45 
До 2023, 2022 тоже. Установлено было. Обновлял только.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 19:03 
Возможно или скорее в сего ещё надо учитывать, что чем слабее видеокарта тем чаще будут подымается частоты до максимума. Предположение по тому, что я не когда не покупал мощные видеокарты в игры не играю, покупаю чем меньше размер и нагрев тем лучше мне, у меня Nvidia GT это Windows. А как в Linux пытаемся отгадать.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 19:06 
В Windows понижаются и повышаются чатоты и напряжение у видеокарт. Если это модели не совсем старые, не знаю с каого года выпуска для видеокарт такое сделали.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 19:22 
Так точнее: Nvidia GeForce GT.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено n00by , 27-Фев-24 08:38 
Это понятно, потому проверял на самом слабом варианте из современных дискреток. Со встройкой такой опыт провести сложнее, так как там например частота памяти может подниматься и центральным процессором.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 18:06 
разновидности OpenGL

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 25-Фев-24 22:52 
Ну если ничего кроме пары окон вам не нужно, то можно и без ускорения, но в реальном использовании без ускорения никуда ни с иксами ни с вяленным.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Zenitur , 25-Фев-24 07:46 
А на проприетарном драйвере как было? Там GPU меньше грелся при декодировании. Даже по оборотам кулера видно.

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено cheburnator9000 , 25-Фев-24 21:41 
Под линуксом у меня некоторые игры играют с меньшей нагрузкой на GPU (Nvidia) под vulkan чем под вендой, но с большей нагрузкой на CPU (возможно из-за wine, но не факт), видеокарта холоднее - кулер тише, но не на CPU.

А если смотреть фильм и на нагрузку Video Engine (де/кодирование) в nvidia-settings всегда работает и 3D Engine тоже в равной степени нагружен, ровно как и сотрудник рассказывает под AMD.

Им нужно объединиться, Valve, AMD и Nvidia пусть уже наконец придумают для линукса еденную прослойку/библиотеку, которая хоть Wayland-only и пусть через нее цепляют все драйвера хоть закрытые хоть открытые, VDPAU/VAAPI видимо для этого не годятся иначе как-нибудь раньше они эту проблему решили.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 08:59 
Для AMD ещё профит есть, а нвидии оно зачем, чужую работу делать?

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено cheburnator9000 , 26-Фев-24 11:56 
> Для AMD ещё профит есть, а нвидии оно зачем, чужую работу делать?

Иначе мы получим очередную порцию не совместимых прослоек.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Zenitur , 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.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено cheburnator9000 , 26-Фев-24 12:51 
Все именно так и на nvidia если сравнивать линукс и windows. Сейчас проверял и случайно выяснил что у меня НЕ работает декодирование под вендой в firefox! https://i.imgur.com/t2pYLmG.png хотя должен быть и vp8,9,HEVC тоже..


У меня давно был ноутбук на Nvidia 310M если честно на ней было без разницы открытый драйвер или закрытый, оба грели GPU адски, ноутбук дешманский ацер с плохим охлаждением, но под вендой все же холоднее (не на много), любой чих спецэффектов в KDE и сразу турбо-частоты.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Zenitur , 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. С тех пор пользуюсь. Греется, ну а что поделать. Зато не тормозит.

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

Windows 10 LTSC? Там кодеки надо вручную ставить.


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено cheburnator9000 , 26-Фев-24 18:33 
И действительно, так вот почему обычная венда при запуске скачивает VP9/HEVC Video Extensions...

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 27-Фев-24 08:11 
Когда корпорации объединяются, они обычно придумывают SurfaceFlinger. После этого с юзабилити и ресурсоёмкостью можно попрощаться.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 07:49 
Аппаратной коррекции цвета на видеокартах лет двадцать как минимум.

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

"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 26-Фев-24 20:53 
О... какие же вы отбитые...

> цепочки типичный энтерпрайзный комбайн с потенциалом к тивоизации.

Чел наоборот все упростил, вместо нагромождения овна дефективных иксов.

> и на похоронах вашей корпорации еще спляшем.

Ну предположим... и что? Будете покупать невидию за дорого?
Будете по помойкам шариться выискивая старые видяхи? Хотя это вы уже)))


  


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Tester , 27-Фев-24 17:56 
> Более эффективно это может быть решено в Wayland композиторах, но пока реализации нет

Реализации нет? Значит это брехня!


"Инженер из AMD признал, что графический стек Linux нуждается..."
Отправлено Аноним , 31-Май-24 12:26 
Пора откапывать стюардессу (драйвер xf86-video-radeonhd). Его писали с особенностями новых Radeon-ов, уверен что и необработанный YUV может воспроизвести.

М..дак David Airlie мешал разработке radeondhd, чтобы добавлять поддержку карточек hd-серии в обычный драйвер radeon. Зачем? Затем что radeon делают на деньги Red Hat, а radeonhd на деньги Novell - а David получает в RH зарплату.

Вот и хаваем далеко идущие последствия.