форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
Сообщение от opennews (ok) on 14-Май-14, 10:16
Niccolo Belli  произвел (http://www.linuxsystems.it/2014/05/radeonsi-awesome-beats-ca.../) серию (http://www.linuxsystems.it/2014/05/radeonsi-faster-catalyst-.../) измерений производительности текущего состояния открытого графического стека, используя тестовый пакет Phoronix Test Suite. В тесте использоваться максимально свежие компоненты графического стека: Mesa 10.3 из Git, ядро Linux 3.15 с дополнительными патчами для увеличения производительности (предположительно, войдут в состав ядра 3.16), LLVM 3.5 из Git. Интересным в данной серии измерений является то, что в качестве оборудования тестировался GPU HD 7950, основанный на архитектуре GCN, поддержка которой обеспечивается драйвером RadeonSI. Исторически, драйвер RadeonSI несколько отставал от драйвера R600 по производительности и полноте реализации возможностей. Тем не менее, тесты показали что в данный момент ситуация заметно улучшилась. В ходе тестов, драйвер RadeonSI продемонстрировал в игре Xonotic производительность на 14% выше чем проприетарный драйвер. Кроме того, открытый драйвер также победил в тесте с участием игры OpenArena, обогнав Catalyst на 4%. Драйвер также показал 76% производительности от драйвера Catalyst в тяжелом тесте Unigine Heaven, и 62% - в тесте Unigine Valley, что является достаточно неплохим результатом по сравнению с более старыми измерениями. К сожалению, несмотря на данные успехи, можно отметить что ситуация с поддержкой новых серий GPU от AMD в Linux на текущий момент все еще далека от идеала. Так, например, ресурс Phoronix отмечает (http://www.phoronix.com/scan.php?page=news_item&px=MTY4NjA) что поддержка GPU R9 290 в открытом графическом стеке в данный момент испытывает многочисленные проблемы. В частности, поддержка ускорения в открытом драйвере пока отключена из-за многочисленных крахов GPU. Данные GPU работают в Linux с проприетарным драйвером, однако производительность оставляет желать лучшего по сравнению с старшими моделями GPU от Nvidia. Поэтому на данный момент R9 290 сложно рекомендовать пользователям Linux. Также имеются проблемы с рядом иных новых моделей GPU семейства Rx 200. Наиболее заметной проблемой стало зависание при определенных видах нагрузок, в частности, отмечено, что удалось добиться достаточно устойчивого воспроизведения проблемы на игре Xonotic, активно используемой для проведения тестов. К счастью, разработчик Marek Olšák смог локализовать проблему и представит патч для ее исправления. Кроме того, имеются некоторые регрессии в производительности. Ресурс Phoronix планировал большую подборку тестов различных GPU с открытыми и проприетарными драйверами наиболее свежих версий, однако пока данные планы несколько задерживаются из-за проблем с открытыми драйверами на стороне AMD. URL: http://www.phoronix.com/scan.php?page=news_item&px=MTY4NjE Новость: http://www.opennet.dev/opennews/art.shtml?num=39765
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
Сообщение от gkv311 (ok) on 14-Май-14, 10:16
А кто-нибудь может подсказать - проблемы с R9 290 сейчас в основном на уровне ядра Linux или на уровне Mesa/RadeonSI, или обоих? Интересно когда можно будет перейти с софтрендеринга на нормальную эксплуатацию после апгрейда с Radeon HD 6850, которая отлично открытыми дровами поддерживается...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+6 +/–
	Сообщение от Аноним (??) on 14-Май-14, 10:51
	Зачем менять что-то проверенное, вполне ещё актуальное, надёжно и хорошо работающее, на новое, но ещё не раскрывшее свой потенциал и стабильность? Dual Boot с Windows или Bleeding Edge по жизни?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–3 +/–
	Сообщение от gkv311 (ok) on 14-Май-14, 11:35
	HD 6850 хорош, но устарел - не годиться для некоторых тяжёлых GPU задач из-за старой архитектуры.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	23. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от koblin (ok) on 14-Май-14, 17:01
	очень интересно, что у вас за задачи по linux для тяжелых GPU
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	25. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от gkv311 (ok) on 14-Май-14, 17:43
	Мои задачи не привязаны к Linux. Linux - всего-лишь основная домашняя система для повседневных задач, для которых GPU монстр вовсе не нужен. Что касается тяжёлых задач - то это real-time RayTracing, например, который на старых GPU архитектурах почти не операбелен.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	28. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 14-Май-14, 19:39
	> очень интересно, что у вас за задачи по linux для тяжелых GPU OpenCL например можно и в линуксе гонять. Вон половина майнеров *коинов гоняют по 3-7 штук топовых GPU, в том числе и под линуксом. В линуксе нет ряда специфичных грабель. Например, в винде каталист имеет свойство игнорировать GPU без мониторов, что очень доставляет. Как вам идея насильного требования семи мониторов? Оптимистично звучит, правда? Конечно есть костыли "эмулятор монитора из куска проводов", но это именно костыли :)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	20. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Zenitur (ok) on 14-Май-14, 15:35
	Это разные компоненты, работающие в связке (графический стек). 1). Ядро Linux - его версия не важна, так как из ядра используется только драйвер. В Linux все драйверы распространяются с ядром системы, хочешь новые драйверы - просто обнови ядро. Но никто не мешает взять новый drm и драйверы intel, ati и nouveau из нового ядра Linux и установить в старое. Так например делают разработчики Debian. 2). Следом идёт libdrm. У libdrm и драйверов intel, radeon и nouveau нет никакой синхронизации версий! Точнее номеров версий. Допустим, мне надо откатиться на старый драйвер из-за регрессии в 3D-игре, чтобы посмотреть как было там. Устанавливаю старое ядро 3.4, а какой установить libdrm? Вот не очевидно что 4.0.63, а 4.0.62 с этой версией ядра ещё не совместим, а 4.1 уже не совместим! Номера версий придумал просто для примера. За короткое время поддержки ядер Linux разработчиков libdrm наругал Торвальдс, теперь оно длится дольше, а я вот ругаю их за не очевидность того, с какой версией ядра какие версии libdrm совместимы. 3). Далее идёт ещё один драйвер intel, radeon и nouveau, на этот раз для Xorg. И снова короткое время поддержки версий ядер Linux и libdrm. И снова номер версии не синхронизирован ни с ядром, ни с libdrm. Только тут ещё хуже: три драйвера с версиями (например) 2.0.45, 7.1.14 и 4.16.58. Хотя libdrm для этих видеокарт общий. Они бы хоть выпускали компоненты связки с синхронными номерами версий, например 2012.08 или 2014.05. И снова если я захочу откатиться на старую версию, откуда мне знать что для ядра Linux 3.4 нужна версия драйвера 6.12, а 6.11 ещё не поддерживает, а 7.0 уже не поддерживает? 4). И наконец Mesa, одна версия на три видеокарты. Это GLX, DRI и OpenGL. Короткого времени поддерки ядра, libdrm, драйвера Xorg нет, и нет трёх разных Mesa под 3 видеокарты. Казалось бы, всё нормально. Только номера версий теперь как в Google Chrome и udev: - раз в несколько месяцев меняется мажорная версия. 5). Опционально libva и libvdpau, любые версии. Наверное ты думаешь что если с Open Source есть проблемы совместимости, то с проприетарщиной вообще всё ужасно! Поддержка 2-3 версий ядра и ещё куча условий, чтобы заработало! А теперь внимание: ftp://download.nvidia.com/XFree86/Linux-x86_64/304.121/READM... Chapter 2. Minimum Software Requirements Software Element    Supported versions Linux kernel            2.4.22 and newer XFree86*                4.0.1 and newer X.Org*                    1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15 Kernel modutils         2.1.121 glibc                        2.0 * It is only required that you have one of XFree86 or X.Org, not both. Please see “How do I interpret X server version numbers?” for a note about X server version numbers. If you need to build the NVIDIA kernel module: Software Element    Min Requirement binutils                     2.9.5 GNU make                 3.77 gcc                            2.91.66 То есть если я возьму линукс 2005 года и установлю на компьютер 2014-го, он не увидит мою сетевушку и звуковушку, зато Doom III выдаст очень большой FPS на максимальных настройках графики!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	22. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–4 +/–
	Сообщение от rob pike on 14-Май-14, 16:57
	>то с проприетарщиной вообще всё ужасно! Странно, а вот в проприетарных ОС с проприетарными драйверами всё вроде хорошо. Может не в проприетарщине дело?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+3 +/–
	Сообщение от Аноним (??) on 14-Май-14, 18:19
	> Странно, а вот в проприетарных ОС с проприетарными драйверами всё вроде хорошо. Понятия о хорошем у всех разные. Знаете, майкрософт как-то публиковал статистику по которой 80% бсодов висты приходилось на драйвера нвидии. А я вот как-то видел девственно чистую семерку которую не успел поставить как она при апдейте зависла наглухо. Когда я согласился заппдейтить видеодрайвер от интеля. Вот при апдейте видеодрайвера система и повисла. Нормальное знакомство с системой - мертвый взвис в первые же полчаса, при выполнении действий которые сама же система и предложила, да? Вам не кажется что озвученная вами точка зрения - достаточно однобока? Баги есть в любом софте. В том числе и в проприетарных системах и проприетарных графических драйверах. И их даже довольно много с учетом размеров драйверов и систем. И если какой-то баг будет кусаться - доораться до разработчиков закрытого кода как правило вообще нереально. Пробовал. Знаю. Эффективность этого процесса близка к нулю. А разработчиков сабжа выловить живьем и показать крЮтой баг - не особо какая проблема.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	30. "Наш ответ Чемберлену."	+1 +/–
	Сообщение от Аноним (??) on 15-Май-14, 00:38
	> 1). Ядро Linux - его версия не важна, Знакомьтесь, это - Зенитар. Феерический ламер, который однако не прочь толкнуть свое мнение. Код драйверов и сами GPU этот баклан не видел даже на картинке, не говоря про GPU на основе GCN. И поэтому не знает что: 1. Новые GPU типа Rx 2xx с старыми ядрами работают от "никак" до "фигово". Старые ядра их совсем не знают, в менее древних - баги. Даже в 3.15-RC баги! И вероятно не все успеют зашибить до релиза 3.15. Например, "performance patches" скорее всего уже не попадут в 3.15 т.к. не фикс, а улучшение. А баги с зависоном при неких сценариях активной работы с VRAM - локализованы, но опять же, насколько фикс успеет войти в 3.15 - вопрос! С ним иные проблемы есть. Так что если у вас Rx 2xx - вам вообще для полного счастья по идее 3.16 ядро надо, которое только в проекте :-). Оно, конечно, работает и сейчас, просто менее идеально чем могло бы хотеться. 2. Даже если забыть об убер-новых GPU, MESA/libdrm/etc - включают ряд фич в зависимости от умений остальных компонентов, в частности - ядра. DRM и KMS - используют для своей работы возможности ядра. Библы вывешивают фичи кернела юзермоду. Так что если некое ядро не умеет нужные возможности - обновление либ не поможет. Сколько либы не апдейть, UVD-декодер без свежего ядра не заработает. И нормальное управление питанием не появится. 3. Наиболее интересный и полезный код, типа нового управления питанием (реализующий логику наподобие каталиста) - свежак. Потому бажный и протестирован не на всех мыслимых конфигурациях. Баги есть. Их давят. Появилось в 3.10/3.11, но обезбажено до состояния когда его активировали по дефолту только в 3.13. Но лучше использовать ядро 3.14, если не хочется встретить какой-нибудь веселый баг. Типа залипания некоторых GPU на 160МГц, со скоростью счета "почти как у софтварного рендерера MESA". 4. В особо древних ядрах были весьма фееричные баги. Например, ядра до 3.5 не инициализировали у радеонов дополнительные каналы памяти (если они есть). Так что если у вас мощная видеокарта с 128-битной шиной DDR и более - вы очень даже можете получить некислую просадку в скорости "просто потому что забыли проинициализировать дополнительные каналы памяти". И будет ваш шикарный агрегат с турбинами работать с памятью на уровне затычки для слота. Обидно, да?! Всего несколько строк кода дали турбореактивную прибавку. Но этот код - в ядре. Никакие юзермодовые либы это в жизни не починят. В общем, хотите попрыгать по граблям и/или остаться без поддержки полезностей в радеонах - древние ядра в помощь. А как по мне - за предложение возиться с старыми ядрами в контексте радеонов - яйца надо советчику отрывать. Сразу и без обсуждений. > взять новый drm и драйверы intel, ati и nouveau из нового > ядра Linux и установить в старое. Так например делают разработчики Debian. Называя вещи своими именами, дебиан "из коробки" весьма погано работает с большинством GPU с использованием открытого стека. Погано - в том плане что медленно, бажно, без уймы фич и только со старыми GPU. Если у вас древняя затычка для слота и вас от GPU интересовали только эффекты на десктоп - можно и так оставить. Иначе это будет субоптимальным решением. Если честно, самое простое решение которое подобралось со знакомыми дебианщиками - вкатить апдейты из "oibaf PPA" (в большинстве инсталляций дебиана это прекрасно прокатывает) и свежее ядро (опять же, можно взять у убунтуев в так называемом "kernel PPA", который, btw, не столько PPA, сколько просто даунлоады сборок свежих ядер). > 2). Следом идёт libdrm. У libdrm и драйверов intel, radeon и nouveau > нет никакой синхронизации версий! Теоретически, и либы и MESA достаточно хорошо совместимы. Практически - тоже. Отвалов по этим причинам - не попадалось, ибо свежие фичи используют только если нашли их поддержку. Костылестроение, зато совместимость не так страдает. Но лучше выбирать MESA, libdrm и прочих более-менее из одного периода времени, желательно свежие. А если кусаются баги - так их репортить надо. Наступить на проблемы в либах вывешивающих KMS и DRM - еще суметь надо. Реально их апдейтить надо только в паре случаев, когда их меняли чтобы добавить недостающие софту фичи (использование UVD, IIRC, может потребовать обновления этих либ). С другой стороны я еще не видел чтобы от апдейта этих либ становилось хуже. > 3). Далее идёт ещё один драйвер intel, radeon и nouveau, на этот раз для Xorg. А это называется DDX-драйверами. Они являются клиентами DRM/KMS подсистем. От них в радеоне как правило минимум проблем. Интель - где как, зато работает шустренько. Нвидия - фиг ее знает. > 4). И наконец Mesa, одна версия на три видеокарты. Это GLX, DRI и OpenGL. По большому счету MESA - тоже клиент DRM/KMS. Ее тоже libdrm/libkms могут интересовать. Как и ядро. Для использования новых фич. Но если их нет - просто отпадут некоторые фичи, ничего фатального как правило не будет, если различия версий в разумных пределах. Стоит понимать что экзотичные сочетания типа MESA годичной древности в паре с свежим -RC ядра просто мало кто тестирует и поэтому вы рискуете быть первым кто соберет вообще все грабли такой конфигурации, если разработчики где-то просчитались. > 5). Опционально libva и libvdpau, любые версии. Вообще-то 1. Только свежие. Старые версии понятия не имеют как в радеоны с их UVD и некоторые нвидии. Там должна быть либа-довесок с платформоспецифичным бэкэндом. 2. Все это достаточно требовательно к версии ядра и остальной инфраструктуры KMS/DRM. С старыми либами DRM или ядром никакого vdpau на радеоне не будет, потому что они не знают как это делать. А старая либа vdpau не в курсе что радеоны так могут и там нет бэкэнда. Так что опять же, свежак и только так. > куча условий, чтобы заработало! А теперь внимание: Да, внимание. Помним мы как эта ваша нвидия недавно не работала с свежими ядрами вообще. Несколько версий ядра к ряду. Настолько шикарные грабли с открытым стеком отхватить - вообще сложно. > выдаст очень большой FPS на максимальных настройках графики! Зато если взять кернел 2014 года, что для компьютера 2014 года логичнее - можно отхватить по полной программе. И как ты понимаешь, Linux 2005 года ничего не знает о, допустим, USB 3.0 и xhci контроллерах. А проcpaть скорость работы USB в 10 раз - печально! Да и вообще, большой вопрос насколько там чипсет поддерживается ядром 9-летней давности и вообще бутанется ли оно. Ведь на момент написания ядра 2005 года такого железа не было даже в проекте.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	39. "Наш ответ Чемберлену."	–2 +/–
	Сообщение от Аноним (??) on 15-Май-14, 11:59
	> Новые GPU типа Rx 2xx с старыми ядрами работают от "никак" до "фигово". Просто открой новость про Debian 7.x. Например про 7.0 http://www.opennet.dev/opennews/art.shtml?num=36858 > из ядра Linux 3.4 портированы подсистемы drm и agp, что позволило включить более современные графические драйверы intel, nouveau и radeon Debian 7.1 http://www.opennet.dev/opennews/art.shtml?num=38145 > Ядро Linux обновлено до версии 3.2.51, из версии 3.4.6 портированы модули drm и agp, отключен драйвер SATA_INIC162X Debian 7.4 http://www.opennet.dev/opennews/art.shtml?num=39048 > Ядро Linux обновлено до версии 3.2.54, из версии 3.4.76 портированы модули drm и agp Вывод: из нового ядра всегда можно взять драйверы и пересадить в старое. Так что ламер - ты.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	43. "Наш ответ Чемберлену."	+1 +/–
	Сообщение от Led (ok) on 16-Май-14, 01:03
	> Вывод: из нового ядра всегда можно взять драйверы и пересадить в старое. > Так что ламер - ты. Не всегда. И не всегда просто. "Не-ламер", приведи примеры того, что ты "взял и пересадил в старое" ядро.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	44. "Наш ответ Чемберлену."	+1 +/–
	Сообщение от Аноним (??) on 16-Май-14, 01:03
	> Просто открой новость про Debian 7.x. Чувак, иди ты в пень со своими новостями. Я в отличие от тебя устраивал немного тестовых забегов дебианам на практике с разныи 3D нагрузками с разными GPU и имею отметить что результаты там как правило не вызывают бурного энтузиазма. >>> Debian 7.4 http://www.opennet.dev/opennews/art.shtml?num=39048 >> Ядро Linux обновлено до версии 3.2.54, из версии 3.4.76 портированы модули drm и agp А надо из 3.14 примерно. Если нормальная работа радеонов с открытым драйвером интересует. Всего на 10 версий ядер новее. Да-да, чувак, 3.4 ядро в плане работы с радеонами точно такой же крап как и 3.2. Лютый баг с кривой иницилизацией контроллера памяти починен в 3.5, нормальное управление питанием - 3.10, а обезбажено - в 3.13 .. 3.14 примерно. > Так что ламер - ты. Ох, камон. Возьми свежий R9 и загрузись с своим мегазаапдейченным дебианом. Не забудь рассказать как оно там работает, НеЛамер.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	37. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 15-Май-14, 02:41
	> То есть если я возьму линукс 2005 года и установлю на компьютер > 2014-го, он не увидит мою сетевушку и звуковушку, зато Doom III > выдаст очень большой FPS на максимальных настройках графики! Зенетур ты такой некрофил. Ага выдаст у тебя дум, он даже не запустится.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	40. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 15-Май-14, 12:12
	>> То есть если я возьму линукс 2005 годa и устaновлю нa компьютер >> 2014-го, он не увидит мою сетевушку и звуковушку, зaто Doom III >> выдaст очень большой FPS нa мaксимaльных нaстройкaх грaфики! > Зенетур ты тaкой нeкрoфил. a я вообще до рaспaдa СCСР родился - вот я, нaверное, нeкрoфил! Зaстaл портaтивную консоль "Ну, погоди!", спектум, кaрмaнный тетрис, 386-е компы и Денди! Кaк я мог в 1994 году в них игрaть, знaя что в 2014 году это будет жутким стaрьём! a кaк зенетур мог стaвить линукс в 2005 году, ведь все знaют что yбyнтy тогдa ещё не было, a знaчит линукс был без грaфической оболочки и для крaсноглaзых прогрaммистов! > aгa выдaст у тебя дум, он дaже не зaпустится. Бинaрники декaбря 2004 годa не зaпустятся в системе 2005 годa, aгa?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	45. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 01:05
	> Бинaрники декaбря 2004 годa не зaпустятся в системе 2005 годa, aгa? Ядро 2005 года может и не знать чипсет и проц 2014 года, если что. Поэтому большой вопрос насколько там у тебя система стартанет вообще.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	48. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 02:29
	В ядре есть универсальный драйвер чипа ввода/вывода для IDE и SCSI. Но вообще ты прав, на EFI вряд ли загрузится что-нибудь старенькое.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	52. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 06:50
	> В ядре есть универсальный драйвер чипа ввода/вывода для IDE и SCSI. А нынче на мамках сроду SATA. Который современные ядра как правило насильно переключают в нативный AHCI-режим, независимо от bios setup, т.е. ничего общего с IDE. Потому что так лучше работает. А так чисто теоретически вы вроде правы в том плане что некая псевдо-стандартизация интерфейсов как бы есть. Но практически чипсет таки может требовать нехилой доинициализации и/или воркэраунд специфичных для него багов. И куча новых железок/фич, которых раньше не было. А еще, ядро 10-летней давности не знает как реклокать проц 2014 года выпуска. Я вижу 2 возможных варианта. Один - это когда проц валит на максимум и превращается в солидный отопитель. Второй - когда проц ползает на минимуме и превращается в знатный тормозитель. Вы как предпочитаете? :) Динамически переключать частоты в зависимости от нагрузки проц, вероятно, не сможет, ибо сие требует поддержки драйвера в ядре. Поэтому привычную для современных систем высокую пиковую производительность при малом потреблении в статичном режиме вы врядли увидите. > Но вообще ты прав, на EFI вряд ли загрузится что-нибудь старенькое. Разве что если его отключить...
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	59. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Michael Shigorin (ok) on 17-Май-14, 00:01
	> В ядре есть универсальный драйвер чипа ввода/вывода для IDE и SCSI. Не существует такого драйвера, насколько мне известно (не путать же sd_mod/scsi_mod с модулем для конкретного вида HBA). > Но вообще ты прав, на EFI вряд ли загрузится что-нибудь старенькое. На _EFI_ как раз старенькое может и загрузиться (особенно если оно и было для того IA64).  UEFI в различных линуксах стал поддерживаться где-то в 2012 году, когда уже и начал попадать на прилавки в хотя бы немного работающем виде.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	27. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 14-Май-14, 19:35
	> Интересно когда можно будет перейти с софтрендеринга на нормальную эксплуатацию после > апгрейда с Radeon HD 6850, которая отлично открытыми дровами поддерживается... А вы 6850 до аж R9 290 собрались апгрейдить? Если что, R9 290 - самая верхушка, круче только яйца. С соответствующей ценой, потреблением и прочая. Хотя если вы 6850 апгрейдить собираетесь - у вас видимо приличные требования. Так что не думаю что вам сильно понравится. Со своей стороны могу рассказать про работу R9 270 с открытым драйвером, но 270 - лишь верхушка среднего класса и другое core, как раз нечто типа современного варианта 6850 или чуть постарше.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	29. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–2 +/–
	Сообщение от Anonim (??) on 14-Май-14, 21:33
	> А вы 6850 до аж R9 290 собрались апгрейдить? Если что, R9 Нет не собираюсь - две недели назад проапгрейдил.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 15-Май-14, 00:41
	> Нет не собираюсь - две недели назад проапгрейдил. А я вроде не вам отвечал? Вы вообще кто?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	38. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
	Сообщение от gkv311 (ok) on 15-Май-14, 08:27
	> А я вроде не вам отвечал? Вы вообще кто? opennet такой opennet, а аноним отвечает анониму ;). Я это отвечал.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Андрей (??) on 15-Май-14, 19:12
	О, идея! Opennet мог бы генерить какой-нибудь короткий хэш по IP-адресу. И анонимно, и пока адрес не изменится можно точно понять кто кому отвечает.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	46. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 01:06
	> И анонимно, Щаз. Короткий хеш подбирается брутфорсом. И длинный тоже, ибо IPv4.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	49. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 04:47
	MD5(IPv4 + Salt в куках), а также кнопка "сбросить куку" рядом с кнопкой отправить.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	53. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 07:21
	> MD5(IPv4 + Salt в куках), 1) Зная свой IP, можно попробовать подобрать salt. Если он не слишком длинный и/или не случайный (а если он длинный - дольше считать хеш) - можно просто подобрать. 2) При утечке или подборе salt узнать айпишники становится тривиально, ибо 32 бита можно брать глупым перебором. Особенно после оптимизации по unused/local/reserved подсетям и прочее. Это я так, говорю потому что видел утилиты которые как раз примерно так снимают cloak с айпишников скрытых по такому принципу ircd-ами. Некоторые экспонаты снимают некоторые виды cloak за буквально секунды. В общем нафиг-нафиг.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	56. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от pavel_simple (ok) on 16-Май-14, 08:31
	>> MD5(IPv4 + Salt в куках), > 1) Зная свой IP, можно попробовать подобрать salt. Если он не слишком > длинный и/или не случайный (а если он длинный - дольше считать > хеш) - можно просто подобрать. логично что если кука per user то и соль pre ip, нет?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	57. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
	Сообщение от Аноним (??) on 16-Май-14, 11:57
	> логично что если кука per user то и соль pre ip, нет? В таком виде может даже и прокатит. Кстати а чего тогда просто не вешать достаточно длинную рандомную куку и хеширвоать ее. На айпи при этом вообще забить можно, он вообще нафига в этом процессе? Заодно научный интерес - желающие закосить под Васю будут пытаться найти коллизии в хешах. Если получится - алгоритм фуфло и его надо менять! :)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от pavel_simple (ok) on 17-Май-14, 23:13
	>> логично что если кука per user то и соль pre ip, нет? > В таком виде может даже и прокатит. Кстати а чего тогда просто > не вешать достаточно длинную рандомную куку и хеширвоать ее. На айпи > при этом вообще забить можно, он вообще нафига в этом процессе? > Заодно научный интерес - желающие закосить под Васю будут пытаться найти > коллизии в хешах. Если получится - алгоритм фуфло и его надо > менять! :) изначально ставилась задача отделение  одних ононимов от других ананимов неким числом с зависимосью от ip. куку пользователя показывать всем остальным как-то немного смешно.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	55. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от pavel_simple (ok) on 16-Май-14, 08:29
	>> И анонимно, > Щаз. Короткий хеш подбирается брутфорсом. и не имеет смысла т.к. слишком много коллизий (в случае если он меньше 4 октетов) >И длинный тоже, ибо IPv4. соль решает.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	58. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 11:59
	> соль решает. Под нее потребуется немало места на сервере. А если на юзере хранить - тогда не понятно на кой айпи сдался. Повесить рандомную куку и использовать как input для хеша. Остальные даже видя хэш не посчитают куку ведь, если хеш без коллизий и кука рандомная :)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	61. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от pavel_simple (ok) on 17-Май-14, 23:15
	>> соль решает. > Под нее потребуется немало места на сервере. А если на юзере хранить > - тогда не понятно на кой айпи сдался. Повесить рандомную куку > и использовать как input для хеша. Остальные даже видя хэш не > посчитают куку ведь, если хеш без коллизий и кука рандомная :) соль не нужно где-то хранить т.к. в данном случае речь идёт об ононимах -- соответственно соль определённо храниться в куке юзера
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	50. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 06:18
	> Я это отвечал. Ну так можно делать это с одинакового ника хотя-бы. Можно с аноимуса, я по контексту догадаюсь. А если ник сменился - логично предположить что это вполне может быть кто-то другой.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	36. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 15-Май-14, 02:37
	На уровне всего, там проблемы начинаются еще с R9 270(x), не работают dpm, управление куллером, vdpau.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	47. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 01:14
	> dpm, управление куллером, vdpau. У автора новости есть R9 270, "если что". И по этому поводу я имею заметить что DPM там вполне работает: могучая числодробилка имеет температуру 30C, кукуя на минимальной частоте. И управление кулером работает. И даже VDPAU. Нет, там есть свои проблемы. Но вы попали в ситуацию "играл, но не угадал ни 1 буквы" :). Вообще же числокрушилки выглядят довольно интересно: по параметрам R9 270 похож на что-то типа x850-x870, с улучшенной скоростной оперативкой. При этом он настолько мало кушает что ему как правило хватает одного 6-контактного разъема, в отличие от упомнутых. Хотя ядро с тем же количеством ALU и даунклокнуто вроде не сильно.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

3. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–2 +/–
Сообщение от Аноним (??) on 14-Май-14, 11:13
да да хорошо... но вот на HD6310 gpu aceleration в хромике не работает ни с открытыми ни с  проприитарщиной
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
	Сообщение от Аноним (??) on 14-Май-14, 11:28
	на 6850 все работает и везде .
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–2 +/–
	Сообщение от Аноним (??) on 14-Май-14, 12:13
	chrome://gpu не сыпет ошибками при запуске ютубика ?   И выхлоп в консоль чист  а не загажен чем-то вроде >>> content::GpuVideoDecodeAccelerator::Initialize(media::VideoCodecProfile, IPC::Message*)HW video decode acceleration not available.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от commiethebeastie (ok) on 14-Май-14, 13:14
	chrome://flags/ Переопределение списка программного рендеринга - включить.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	14. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–1 +/–
	Сообщение от Аноним (??) on 14-Май-14, 14:13
	> chrome://flags/ > Переопределение списка программного рендеринга - включить. Да это баяйн рваный, в первойже ссылке гугля. оно то включено , но не работает  720p и 1080p как тупили так и тупят , и вся консоль забита ошибками
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от commiethebeastie (ok) on 14-Май-14, 14:38
	dmesg после ошибок в консоли? vdpauinfo? Xorg.0.log?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	24. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 14-Май-14, 17:22
	> dmesg после ошибок в консоли? vdpauinfo? Xorg.0.log? dmesg пуст vdpau работает  smplayer, vlc все чудестно Xorg ответа не дает попробую метод от Zenitur
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	54. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
	Сообщение от Аноним (??) on 16-Май-14, 07:22
	> попробую метод от Zenitur Это какой? С умным видом напыщенно втирать всякую хреноту, не понимая как и что работает?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	21. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Zenitur (ok) on 14-Май-14, 15:53
	>> chrome://flags/ >> Переопределение списка программного рендеринга - включить. > Да это баяйн рваный, в первойже ссылке гугля. > оно то включено , но не работает  720p и 1080p как > тупили так и тупят , и вся консоль забита ошибками Создай каталог /opt/google/chrome/plugins и положи туда Flash Player 11.2. Включи браузер, набери в строке адреса chrome://plugins, нажми "Развернуть подробности", отключи Flash Player 13.0. Теперь видео в 1080p не будет тормозить. Ни воспроизведение, ни перемотка, ни разворачивание на весь экран и обратно. Только я не знаю как отключить воспроизведение через HTML5 в Chrome, так как пользуюсь Firefox. Кто-нибудь подскажите. Если видео всё ещё идёт рывками, запусти из консоли: VDPAU_DRIVER=r600 chrome И посмотри что пишет.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

7. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
Сообщение от Аноним (??) on 14-Май-14, 12:34
> Marek Olšák Не пора ли уже перевести ресурс на Unicode? Как подумаю в каком виде хранится фамилия Марека в базе, сразу вижу изображение костыля.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
	Сообщение от Аноним (??) on 14-Май-14, 13:23
	Похоже у вас какая-то проблема с глазами
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+1 +/–
	Сообщение от Ыр on 14-Май-14, 13:43
	У kоi8-r проблемы.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от commiethebeastie (ok) on 14-Май-14, 14:39
	> Похоже у вас какая-то проблема с глазами Нет ты: Marek Ol&# 353;&# 225;k
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	32. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–3 +/–
	Сообщение от Аноним (??) on 15-Май-14, 00:42
	> Marek Ol&# 353;&# 225;k Это так, к вопросу о том почему 1-байтовые кодировки должны умереть жестокой смертью.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

8. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–1 +/–
Сообщение от Аноним (??) on 14-Май-14, 12:35
Ребята, как запустить на ati mobility 9550? Поиогите
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от commiethebeastie (ok) on 14-Май-14, 13:16
	> Ребята, как запустить на ati mobility 9550? Поиогите dmesg, Xorg.0.log, LIBGL_DEBUG=verbose glxinfo
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	33. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 15-Май-14, 00:43
	> Ребята, как запустить на ati mobility 9550? Поиогите Поставить свежие ядро и драйвера для начала. Если после этого не стало хорошо - напишите в чем проблема.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+2 +/–
Сообщение от Аноним (??) on 14-Май-14, 13:44
На ноуте с 7950M все изумительно работает в новой Убунте, переключаются дискретка и встроенная в процессор, не греется, не гудит и позволяет играть в портал. Я безумно счастлив.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–2 +/–
	Сообщение от commiethebeastie (ok) on 14-Май-14, 14:40
	> На ноуте с 7950M все изумительно работает в новой Убунте, переключаются дискретка > и встроенная в процессор, не греется, не гудит и позволяет играть > в портал. > Я безумно счастлив. На llvm-3.5 и 3.16 ядре оно еще и летать будет >200 fps.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	34. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 15-Май-14, 00:44
	> На llvm-3.5 и 3.16 ядре оно еще и летать будет >200 fps. Пока 3.4.2 хотят для начала выпустить, ибо баги в этом LLVMном глюкалове - задолбали. И да, а M версия точно выжмет 200FPS на хороших настройках? M версии обычно сильно обрублены относительно полноценных.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	41. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от commiethebeastie (ok) on 15-Май-14, 15:04
	Сколько у тебя сейчас?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	51. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от Аноним (??) on 16-Май-14, 06:22
	> Сколько у тебя сейчас? - Петька, прибор! - 38! - Чего - 38?! - А чего "Петька, прибор"? К чему это я? А к тому что FPS бывает разный. Могу любой сделать, от 20 до 300 путем подбора сцен. Обычно 60, по рефрешу монитора. Но, правда, это ни о чем без уточнения в каких сценах и прочая.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

15. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
Сообщение от КВ1С on 14-Май-14, 14:30
Что автора новости не устраивает в r9 290? На проприетарных дровах 290-й жжот на уровне титана. http://www.phoronix.com/scan.php?page=article&item=nvidia_am...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	+/–
	Сообщение от commiethebeastie (ok) on 14-Май-14, 14:40
	> Что автора новости не устраивает в r9 290? На проприетарных дровах 290-й > жжот на уровне титана. > http://www.phoronix.com/scan.php?page=article&item=nvidia_am... Вот-вот, R9 290 это даже не "Х"
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	35. "Оценка состояния поддержки GPU компании AMD в открытом графи..."	–1 +/–
	Сообщение от Аноним (??) on 15-Май-14, 00:48
	> жжот на уровне титана. Если почитать новости и посмотреть бенчи - можно заметить что в целом R9 жжот в линуксе как-то слабовато. Кроме того, у каталиста есть ряд дурных проблем, набрать с ним аптайм более недели довольно сложно, и вообще - граблеопасная и кривая конструкция. Возможно, в том числе и поэтому автора новлсти интересует в основном открытый графический стек.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

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

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