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.me/opennews/art.shtml?num=39765
А кто-нибудь может подсказать - проблемы с R9 290 сейчас в основном на уровне ядра Linux или на уровне Mesa/RadeonSI, или обоих?Интересно когда можно будет перейти с софтрендеринга на нормальную эксплуатацию после апгрейда с Radeon HD 6850, которая отлично открытыми дровами поддерживается...
Зачем менять что-то проверенное, вполне ещё актуальное, надёжно и хорошо работающее, на новое, но ещё не раскрывшее свой потенциал и стабильность? Dual Boot с Windows или Bleeding Edge по жизни?
HD 6850 хорош, но устарел - не годиться для некоторых тяжёлых GPU задач из-за старой архитектуры.
очень интересно, что у вас за задачи по linux для тяжелых GPU
Мои задачи не привязаны к Linux. Linux - всего-лишь основная домашняя система для повседневных задач, для которых GPU монстр вовсе не нужен.Что касается тяжёлых задач - то это real-time RayTracing, например, который на старых GPU архитектурах почти не операбелен.
> очень интересно, что у вас за задачи по linux для тяжелых GPUOpenCL например можно и в линуксе гонять. Вон половина майнеров *коинов гоняют по 3-7 штук топовых GPU, в том числе и под линуксом. В линуксе нет ряда специфичных грабель. Например, в винде каталист имеет свойство игнорировать GPU без мониторов, что очень доставляет. Как вам идея насильного требования семи мониторов? Оптимистично звучит, правда? Конечно есть костыли "эмулятор монитора из куска проводов", но это именно костыли :)
Это разные компоненты, работающие в связке (графический стек).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 на максимальных настройках графики!
>то с проприетарщиной вообще всё ужасно!Странно, а вот в проприетарных ОС с проприетарными драйверами всё вроде хорошо.
Может не в проприетарщине дело?
> Странно, а вот в проприетарных ОС с проприетарными драйверами всё вроде хорошо.Понятия о хорошем у всех разные. Знаете, майкрософт как-то публиковал статистику по которой 80% бсодов висты приходилось на драйвера нвидии. А я вот как-то видел девственно чистую семерку которую не успел поставить как она при апдейте зависла наглухо. Когда я согласился заппдейтить видеодрайвер от интеля. Вот при апдейте видеодрайвера система и повисла. Нормальное знакомство с системой - мертвый взвис в первые же полчаса, при выполнении действий которые сама же система и предложила, да?
Вам не кажется что озвученная вами точка зрения - достаточно однобока? Баги есть в любом софте. В том числе и в проприетарных системах и проприетарных графических драйверах. И их даже довольно много с учетом размеров драйверов и систем. И если какой-то баг будет кусаться - доораться до разработчиков закрытого кода как правило вообще нереально. Пробовал. Знаю. Эффективность этого процесса близка к нулю. А разработчиков сабжа выловить живьем и показать крЮтой баг - не особо какая проблема.
> 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 года такого железа не было даже в проекте.
> Новые GPU типа Rx 2xx с старыми ядрами работают от "никак" до "фигово".Просто открой новость про Debian 7.x. Например про 7.0 http://www.opennet.me/opennews/art.shtml?num=36858
> из ядра Linux 3.4 портированы подсистемы drm и agp, что позволило включить более современные графические драйверы intel, nouveau и radeon
Debian 7.1 http://www.opennet.me/opennews/art.shtml?num=38145
> Ядро Linux обновлено до версии 3.2.51, из версии 3.4.6 портированы модули drm и agp, отключен драйвер SATA_INIC162X
Debian 7.4 http://www.opennet.me/opennews/art.shtml?num=39048
> Ядро Linux обновлено до версии 3.2.54, из версии 3.4.76 портированы модули drm и agp
Вывод: из нового ядра всегда можно взять драйверы и пересадить в старое. Так что ламер - ты.
> Вывод: из нового ядра всегда можно взять драйверы и пересадить в старое.
> Так что ламер - ты.Не всегда. И не всегда просто.
"Не-ламер", приведи примеры того, что ты "взял и пересадил в старое" ядро.
> Просто открой новость про Debian 7.x.Чувак, иди ты в пень со своими новостями. Я в отличие от тебя устраивал немного тестовых забегов дебианам на практике с разныи 3D нагрузками с разными GPU и имею отметить что результаты там как правило не вызывают бурного энтузиазма.
>>> Debian 7.4 http://www.opennet.me/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 и загрузись с своим мегазаапдейченным дебианом. Не забудь рассказать как оно там работает, НеЛамер.
> То есть если я возьму линукс 2005 года и установлю на компьютер
> 2014-го, он не увидит мою сетевушку и звуковушку, зато Doom III
> выдаст очень большой FPS на максимальных настройках графики!Зенетур ты такой некрофил. Ага выдаст у тебя дум, он даже не запустится.
>> То есть если я возьму линукс 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?
> Бинaрники декaбря 2004 годa не зaпустятся в системе 2005 годa, aгa?Ядро 2005 года может и не знать чипсет и проц 2014 года, если что. Поэтому большой вопрос насколько там у тебя система стартанет вообще.
В ядре есть универсальный драйвер чипа ввода/вывода для IDE и SCSI. Но вообще ты прав, на EFI вряд ли загрузится что-нибудь старенькое.
> В ядре есть универсальный драйвер чипа ввода/вывода для IDE и SCSI.А нынче на мамках сроду SATA. Который современные ядра как правило насильно переключают в нативный AHCI-режим, независимо от bios setup, т.е. ничего общего с IDE. Потому что так лучше работает. А так чисто теоретически вы вроде правы в том плане что некая псевдо-стандартизация интерфейсов как бы есть. Но практически чипсет таки может требовать нехилой доинициализации и/или воркэраунд специфичных для него багов. И куча новых железок/фич, которых раньше не было. А еще, ядро 10-летней давности не знает как реклокать проц 2014 года выпуска. Я вижу 2 возможных варианта. Один - это когда проц валит на максимум и превращается в солидный отопитель. Второй - когда проц ползает на минимуме и превращается в знатный тормозитель. Вы как предпочитаете? :) Динамически переключать частоты в зависимости от нагрузки проц, вероятно, не сможет, ибо сие требует поддержки драйвера в ядре. Поэтому привычную для современных систем высокую пиковую производительность при малом потреблении в статичном режиме вы врядли увидите.
> Но вообще ты прав, на EFI вряд ли загрузится что-нибудь старенькое.
Разве что если его отключить...
> В ядре есть универсальный драйвер чипа ввода/вывода для IDE и SCSI.Не существует такого драйвера, насколько мне известно (не путать же sd_mod/scsi_mod с модулем для конкретного вида HBA).
> Но вообще ты прав, на EFI вряд ли загрузится что-нибудь старенькое.
На _EFI_ как раз старенькое может и загрузиться (особенно если оно и было для того IA64). UEFI в различных линуксах стал поддерживаться где-то в 2012 году, когда уже и начал попадать на прилавки в хотя бы немного работающем виде.
> Интересно когда можно будет перейти с софтрендеринга на нормальную эксплуатацию после
> апгрейда с Radeon HD 6850, которая отлично открытыми дровами поддерживается...А вы 6850 до аж R9 290 собрались апгрейдить? Если что, R9 290 - самая верхушка, круче только яйца. С соответствующей ценой, потреблением и прочая. Хотя если вы 6850 апгрейдить собираетесь - у вас видимо приличные требования. Так что не думаю что вам сильно понравится.
Со своей стороны могу рассказать про работу R9 270 с открытым драйвером, но 270 - лишь верхушка среднего класса и другое core, как раз нечто типа современного варианта 6850 или чуть постарше.
> А вы 6850 до аж R9 290 собрались апгрейдить? Если что, R9Нет не собираюсь - две недели назад проапгрейдил.
> Нет не собираюсь - две недели назад проапгрейдил.А я вроде не вам отвечал? Вы вообще кто?
> А я вроде не вам отвечал? Вы вообще кто?opennet такой opennet, а аноним отвечает анониму ;).
Я это отвечал.
О, идея! Opennet мог бы генерить какой-нибудь короткий хэш по IP-адресу. И анонимно, и пока адрес не изменится можно точно понять кто кому отвечает.
> И анонимно,Щаз. Короткий хеш подбирается брутфорсом. И длинный тоже, ибо IPv4.
MD5(IPv4 + Salt в куках), а также кнопка "сбросить куку" рядом с кнопкой отправить.
> MD5(IPv4 + Salt в куках),1) Зная свой IP, можно попробовать подобрать salt. Если он не слишком длинный и/или не случайный (а если он длинный - дольше считать хеш) - можно просто подобрать.
2) При утечке или подборе salt узнать айпишники становится тривиально, ибо 32 бита можно брать глупым перебором. Особенно после оптимизации по unused/local/reserved подсетям и прочее.Это я так, говорю потому что видел утилиты которые как раз примерно так снимают cloak с айпишников скрытых по такому принципу ircd-ами. Некоторые экспонаты снимают некоторые виды cloak за буквально секунды. В общем нафиг-нафиг.
>> MD5(IPv4 + Salt в куках),
> 1) Зная свой IP, можно попробовать подобрать salt. Если он не слишком
> длинный и/или не случайный (а если он длинный - дольше считать
> хеш) - можно просто подобрать.логично что если кука per user то и соль pre ip, нет?
> логично что если кука per user то и соль pre ip, нет?В таком виде может даже и прокатит. Кстати а чего тогда просто не вешать достаточно длинную рандомную куку и хеширвоать ее. На айпи при этом вообще забить можно, он вообще нафига в этом процессе? Заодно научный интерес - желающие закосить под Васю будут пытаться найти коллизии в хешах. Если получится - алгоритм фуфло и его надо менять! :)
>> логично что если кука per user то и соль pre ip, нет?
> В таком виде может даже и прокатит. Кстати а чего тогда просто
> не вешать достаточно длинную рандомную куку и хеширвоать ее. На айпи
> при этом вообще забить можно, он вообще нафига в этом процессе?
> Заодно научный интерес - желающие закосить под Васю будут пытаться найти
> коллизии в хешах. Если получится - алгоритм фуфло и его надо
> менять! :)изначально ставилась задача отделение одних ононимов от других ананимов неким числом с зависимосью от ip.
куку пользователя показывать всем остальным как-то немного смешно.
>> И анонимно,
> Щаз. Короткий хеш подбирается брутфорсом.и не имеет смысла т.к. слишком много коллизий (в случае если он меньше 4 октетов)
>И длинный тоже, ибо IPv4.соль решает.
> соль решает.Под нее потребуется немало места на сервере. А если на юзере хранить - тогда не понятно на кой айпи сдался. Повесить рандомную куку и использовать как input для хеша. Остальные даже видя хэш не посчитают куку ведь, если хеш без коллизий и кука рандомная :)
>> соль решает.
> Под нее потребуется немало места на сервере. А если на юзере хранить
> - тогда не понятно на кой айпи сдался. Повесить рандомную куку
> и использовать как input для хеша. Остальные даже видя хэш не
> посчитают куку ведь, если хеш без коллизий и кука рандомная :)соль не нужно где-то хранить т.к. в данном случае речь идёт об ононимах -- соответственно соль определённо храниться в куке юзера
> Я это отвечал.Ну так можно делать это с одинакового ника хотя-бы. Можно с аноимуса, я по контексту догадаюсь. А если ник сменился - логично предположить что это вполне может быть кто-то другой.
На уровне всего, там проблемы начинаются еще с R9 270(x), не работают dpm, управление куллером, vdpau.
> dpm, управление куллером, vdpau.У автора новости есть R9 270, "если что". И по этому поводу я имею заметить что DPM там вполне работает: могучая числодробилка имеет температуру 30C, кукуя на минимальной частоте. И управление кулером работает. И даже VDPAU. Нет, там есть свои проблемы. Но вы попали в ситуацию "играл, но не угадал ни 1 буквы" :).
Вообще же числокрушилки выглядят довольно интересно: по параметрам R9 270 похож на что-то типа x850-x870, с улучшенной скоростной оперативкой. При этом он настолько мало кушает что ему как правило хватает одного 6-контактного разъема, в отличие от упомнутых. Хотя ядро с тем же количеством ALU и даунклокнуто вроде не сильно.
да да хорошо... но вот на HD6310 gpu aceleration в хромике не работает ни с открытыми ни с проприитарщиной
на 6850 все работает и везде .
chrome://gpu не сыпет ошибками при запуске ютубика ?
И выхлоп в консоль чист а не загажен
чем-то вроде
>>> content::GpuVideoDecodeAccelerator::Initialize(media::VideoCodecProfile, IPC::Message*)HW video decode acceleration not available.
chrome://flags/Переопределение списка программного рендеринга - включить.
> chrome://flags/
> Переопределение списка программного рендеринга - включить.Да это баяйн рваный, в первойже ссылке гугля.
оно то включено , но не работает 720p и 1080p как тупили так и тупят , и вся консоль забита ошибками
dmesg после ошибок в консоли? vdpauinfo? Xorg.0.log?
> dmesg после ошибок в консоли? vdpauinfo? Xorg.0.log?dmesg пуст
vdpau работает smplayer, vlc все чудестно
Xorg ответа не дает
попробую метод от Zenitur
> попробую метод от ZeniturЭто какой? С умным видом напыщенно втирать всякую хреноту, не понимая как и что работает?
>> 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
И посмотри что пишет.
> Marek OlšákНе пора ли уже перевести ресурс на Unicode? Как подумаю в каком виде хранится фамилия Марека в базе, сразу вижу изображение костыля.
Похоже у вас какая-то проблема с глазами
У kоi8-r проблемы.
> Похоже у вас какая-то проблема с глазамиНет ты:
Marek Ol&# 353;&# 225;k
> Marek Ol&# 353;&# 225;kЭто так, к вопросу о том почему 1-байтовые кодировки должны умереть жестокой смертью.
Ребята, как запустить на ati mobility 9550? Поиогите
> Ребята, как запустить на ati mobility 9550? Поиогитеdmesg, Xorg.0.log, LIBGL_DEBUG=verbose glxinfo
> Ребята, как запустить на ati mobility 9550? ПоиогитеПоставить свежие ядро и драйвера для начала. Если после этого не стало хорошо - напишите в чем проблема.
На ноуте с 7950M все изумительно работает в новой Убунте, переключаются дискретка и встроенная в процессор, не греется, не гудит и позволяет играть в портал.
Я безумно счастлив.
> На ноуте с 7950M все изумительно работает в новой Убунте, переключаются дискретка
> и встроенная в процессор, не греется, не гудит и позволяет играть
> в портал.
> Я безумно счастлив.На llvm-3.5 и 3.16 ядре оно еще и летать будет >200 fps.
> На llvm-3.5 и 3.16 ядре оно еще и летать будет >200 fps.Пока 3.4.2 хотят для начала выпустить, ибо баги в этом LLVMном глюкалове - задолбали. И да, а M версия точно выжмет 200FPS на хороших настройках? M версии обычно сильно обрублены относительно полноценных.
Сколько у тебя сейчас?
> Сколько у тебя сейчас?- Петька, прибор!
- 38!
- Чего - 38?!
- А чего "Петька, прибор"?К чему это я? А к тому что FPS бывает разный. Могу любой сделать, от 20 до 300 путем подбора сцен. Обычно 60, по рефрешу монитора. Но, правда, это ни о чем без уточнения в каких сценах и прочая.
Что автора новости не устраивает в r9 290? На проприетарных дровах 290-й жжот на уровне титана.http://www.phoronix.com/scan.php?page=article&item=nvidia_am...
> Что автора новости не устраивает в r9 290? На проприетарных дровах 290-й
> жжот на уровне титана.
> http://www.phoronix.com/scan.php?page=article&item=nvidia_am...Вот-вот, R9 290 это даже не "Х"
> жжот на уровне титана.Если почитать новости и посмотреть бенчи - можно заметить что в целом R9 жжот в линуксе как-то слабовато.
Кроме того, у каталиста есть ряд дурных проблем, набрать с ним аптайм более недели довольно сложно, и вообще - граблеопасная и кривая конструкция. Возможно, в том числе и поэтому автора новлсти интересует в основном открытый графический стек.