The OpenNET Project / Index page

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

Из открытого драйвера Radeon будет убрана поддержка переключения видеорежимов на пользовательском уровне

15.06.2012 20:20

Разработчики Алекс Дейчер (Alex Deucher) и Михель Дэнцер (Michel Dänzer) из компании AMD совместно с Дэвидом Эйрли (David Airlie) из Red Hat планируют убрать поддержку устаревшего метода переключения видеорежимов на пользовательском уровне (UMS - User Mode Setting) из драйвера Radeon. Напомним, что ранее поддержка UMS была прекращена в драйверах Intel и Nouveau. Предположительно, начиная с версии xf86-video-ati-7.0.0 драйвер будет поддерживать переключение видеорежимов только через более современный интерфейс KMS (Kernel Mode Setting), работающий через модуль на уровне ядра ОС.

К сожалению, в настоящее время KMS-модули реализованы только для ядра Linux. Пользователи других систем, таких как Solaris и *BSD, будут вынуждены пользоваться устаревшими драйверами, в которых ещё поддерживается UMS. Одним из главных недостатков UMS является необходимость наличия прав суперпользователя для работы драйвера. При использовании KMS все привилегированные операции выполняются в отдельном модуле и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя.

Тем не менее, фактически поддержка UMS оставалась в драйвере Radeon лишь формально, так как последнее время поддержка новых видеокарт добавлялась только в DRM/KMS модуль ядра и не была доступна через UMS. Поэтому дальнейшая поддержка UMS всё равно не даст пользователям других систем возможности использования драйвера с новыми видекартами. Для FreeBSD модули KMS уже доступны для карт Intel, но пока развиваются в виде отдельного экспериментального проекта. После завершения разработки, KMS-модули планируется включить в состав будущего релиза FreeBSD 10 и бэкпортировать для ветки FreeBSD 9. Поддержка KMS для видеокарт ATI/AMD и NVIDIA во FreeBSD пока находится на стадии ранних экспериментов.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/34109-xorg
Ключевые слова: xorg, radeon, ati, kms, ums
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 21:43, 15/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    > Одним из главных недостатков UMS является необходимость наличия прав суперпользователя для работы драйвера, при KMS все привилегированные операции выполняются в отдельном модуле и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя.

    Хорошо у вас там в Линуксе. Нам, BSDшникам, такое только сниться может

     
     
  • 2.2, Андрей (??), 22:15, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    и другим альтернативщикам для альтернативы.
     
  • 2.3, Аноним (-), 22:17, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +13 +/
    переползайте :)
     
  • 2.4, Аноним (-), 22:21, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Хорошо у вас там в Линуксе. Нам, BSDшникам, такое только сниться может

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

     
     
  • 3.5, Аноним (-), 22:30, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Ты так говоришь, будто причастен к разработке KMS в Линуксе. Ну нравися человеку BSD, ты зачем бахвалиться перед ним чужими заслугами?
     
     
  • 4.6, Аноним (-), 22:31, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты так говоришь, будто причастен к разработке KMS в Линуксе. Ну нравися
    > человеку BSD, ты зачем бахвалиться перед ним чужими заслугами?

    *бахвалишься

     
     
  • 5.8, Аноним2 (?), 22:52, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Очевидно же - из-за подростковых комплексов.
     
  • 4.21, Аноним (-), 02:05, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты так говоришь, будто причастен к разработке KMS в Линуксе.

    Я всего лишь выступаю Капитаном очевидностью. Про причастность вы сами домыслили.

     
  • 3.7, oops (ok), 22:40, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > всем кому не пофиг

    это кто ж?

     
     
  • 4.28, Аноним (-), 03:07, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > это кто ж?

    А вот это мы как раз и "будем посмотреть". Кто не забьет - тому и не пофиг. Это же элементарно, Ватсон!

     
  • 3.32, Aceler (ok), 09:43, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну то есть если разработчики дров решили, что будут поддерживать только WDK, то семеро одного не ждут, так?
     
     
  • 4.35, фтыщ (?), 11:34, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А что такое - WDK?
     
     
  • 5.36, Aceler (ok), 11:41, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А что такое - WDK?

    https://www.google.ru/search?ix=acb&sourceid=chrome&client=ubuntu&channel=cs&i

     
  • 4.39, ананим (?), 13:40, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну то есть если разработчики дров решили, что будут поддерживать только WDK, то семеро одного не ждут, так?

    так.
    если это разработчики открытых(!!) дров для открытого(!!!) wdk.

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

     
  • 2.10, iZEN (ok), 23:35, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    >> Одним из главных недостатков UMS является необходимость наличия прав суперпользователя для работы драйвера, при KMS все привилегированные операции выполняются в отдельном модуле и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя.
    > Хорошо у вас там в Линуксе. Нам, BSDшникам, такое только сниться может

    Ну да. :)) А купить видеокарту NVIDIA не судьба, если для новой чудо-интеграшки от AMD xf86-video-ati больше не подойдёт?

     
     
  • 3.22, Аноним (-), 02:07, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ну да. :)) А купить видеокарту NVIDIA не судьба,

    А потом обломаться, если это была openbsd, netbsd или что там еще, ага.

     
  • 3.37, ананим (?), 13:04, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >А купить видеокарту NVIDIA не судьба

    и как это поможет, цитата, "и поэтому X-сервер может быть изначально запущен с привилегиями обычного пользователя"?
    оппонент то прямо сказал именно это, не чтобы хоть как-то заработало.

     

  • 1.9, iZEN (ok), 23:31, 15/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно, нежели свободные, не делают поддержку KMS. Странно, почему? Контроль эффективности жизненного цикла софтверной составляющей? Чтобы качество открытых драйверов всегда было заведомо ниже, чем проприетарных для одного и того же оборудования?
     
     
  • 2.13, Eugeni Dodonov (ok), 23:43, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно, нежели свободные, не делают поддержку KMS. Странно, почему?

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

     
     
  • 3.17, Аноним (-), 00:09, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    gplпроблемы же.
     
     
  • 4.43, Eugeni Dodonov (ok), 19:28, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Проблемы не только с gpl, скорее даже они особо с gpl не связаны.

    Дело в том, что при использовании KMS весь код связанный с переключением видео-режимов работает в режиме ядра, так что необходимо учитывать вопросы связанные с распределением памяти (просто s/malloc/kalloc не сработает), поддерживать новые API drm.ko и drm_fb_helper/drm_crtc_helper/drm_kms_helper, и оперативно реагировать на изменение API/ABI (что меняется довольно часто, увы). Ну и, конечно, поддерживать интеграцию с framebuffer на более низком уровне.

    В случае UMS - тот код, что работал раньше, продолжит работать и при обновлении ядра, так как он от ядра не зависит (сервер/ddx обращаются напрямую к графической памяти), и можно использовать все плюшки которые есть в userspace. Но он сломается когда поменяется X server (что в ближайшем будущем и произойдет, когда патчи от airlied войдут в иксы).

    Так что для перехода на KMS придется переписать бОльшую часть кода связанную с modesetting, подготовить ее для совместимости с ядром (через #ifdef'ы и тому подобные вещи, чтобы учитывать различные внутренности drm/kms api), и открыть бОльшую часть кода чем сейчас - как минимум для работы с i2c и sysfs - которые для KMS-based драйверов весьма даже нужны). Увы, в закрытых драйверах этого не будет.

    В случае с BSD наблюдаются похожие проблемы, разве что кода открывать можно меньше. Но все что связано с modesetting'ом придется переписывать в любом случае. И я бы даже предположил что шансы получить KMS в *BSD в закрытых драйверах даже меньше чем под линуксом, так как детали работы видео-режимов в них сильнее отличаются...

     
  • 4.42, Аноним (-), 15:09, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Он разбирается поболее тебя
     
  • 2.23, Аноним (-), 02:08, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно, нежели
    > свободные, не делают поддержку KMS. Странно, почему?

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


     
  • 2.38, ананим (?), 13:11, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно

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

    что это означает на практике - открытые дрова на десктопе ведут себя лучше, пока не запускаешь игры.
    ты запускаешь игры, айзен?

    просто для примера - возьмите любой ливсд, где есть дрова нвидиа и новьё.
    и те, и те рабоатют сносно из коробки, но.
    если грузится с новьё, то грузится уже в нормальном графическом режиме, не переключает эти режимы, грузится быстрее и после загрузки ест озу на 25-30% меньше.
    результат - комфортность работа в любой ДЕ - одинаков.

     
     
  • 3.45, iZEN (ok), 20:33, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>NVIDIA и AMD почему-то в проприетарных драйверах, которые работают более эффективно
    > это что, такой поверхностный взгляд бздишнега?

    У меня интеграшка NVIDIA GeForce 6150 с проприетарным драйвером и интеграшка AMD 785G с открытым драйвером xf86-video-ati 6.14.3. Разницы межде ними не чувствую.

    > открытые дрова уже давно работают лучше и безопасней.

    Безопасность в чём выражается? Открытый драйвер для NVIDIA xf86-video-nouveau 0.0.10.20090728 ломает бинарную совместимость обновлённых и готовых к распространению на AMD-машине пакетов libdrm и dri. Они расходятся по версиям. С проприетарным драйвером ничего такого не происходит — можно держать для обеих машин одну и ту же пакетную базу.

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

    Казуальные, разве что.

    Когда стояла ОС с архитектурой [i386], то в WINE запускал Counter-Strike 1.6 и Comanche4. Вполне сносно работали в полный экран на проприетарном драйвере NVIDIA. На открытом драйвере не помню, чтобы сносно работало — разве что в окне 800x600 тянуло еле-еле.

     
     
  • 4.47, ананим (?), 22:40, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >У меня интеграшка NVIDIA GeForce 6150 с проприетарным драйвером и интеграшка AMD 785G с открытым драйвером xf86-video-ati 6.14.3. Разницы межде ними не чувствую.

    цена таже. свежесть железа?
    >Безопасность в чём выражается? Открытый драйвер для NVIDIA xf86-video-nouveau 0.0.10.20090728 ломает бинарную совместимость обновлённых и готовых к распространению на AMD-машине пакетов libdrm и dri. Они расходятся по версиям. С проприетарным драйвером ничего такого не происходит — можно держать для обеих машин одну и ту же пакетную базу.

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

    именно.
    >в WINE запускал Counter-Strike 1.6 и Comanche4. Вполне сносно работали в полный экран на проприетарном драйвере NVIDIA. На открытом драйвере не помню

    поставь в проприетарном драйвере nvidia в качестве opengl реализацию mesa и осознай разницу опенжл от драйверов.
    хинт:
    # eselect opengl list
    Available OpenGL implementations:
      [1]   nvidia *
      [2]   xorg-x11
    а дрова то сами по себе отличные.


     
     
  • 5.48, iZEN (ok), 22:55, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>У меня интеграшка NVIDIA GeForce 6150 с проприетарным драйвером и интеграшка AMD 785G с открытым драйвером xf86-video-ati 6.14.3. Разницы межде ними не чувствую.
    > цена таже. свежесть железа?

    2006 и 2010 год, соответсвенно.

    >>Безопасность в чём выражается? Открытый драйвер для NVIDIA xf86-video-nouveau 0.0.10.20090728 ломает бинарную совместимость обновлённых и готовых к распространению на AMD-машине пакетов libdrm и dri. Они расходятся по версиям. С проприетарным драйвером ничего такого не происходит — можно держать для обеих машин одну и ту же пакетную базу.
    > безопасность выражается в безопасности.

    В чём-чём, простите?

    > а в неспособности айзена скомпилить бздю под каждую систему.
    > поставь в проприетарном драйвере nvidia в качестве opengl реализацию mesa и осознай разницу опенжл от драйверов.

    Как поставить? Куда поставить? У NVIDIA блоб подменяет собой реализацию OpenGL-библиотек Xorg. Без этого либо не загрузится графический режим, либо будет медленно и печально тормозить (случалось после установки NVIDIA Driver и пересборки пакетов Xorg с ключом "-f").

    > хинт:
    > # eselect opengl list
    > Available OpenGL implementations:
    >   [1]   nvidia *
    >   [2]   xorg-x11
    > а дрова то сами по себе отличные.

    Ни о чём.

     
     
  • 6.49, ананим (?), 23:37, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> цена таже. свежесть железа?
    >2006 и 2010 год, соответсвенно.

    а цена - таже!
    сейчас :D

    >Как поставить? Куда поставить? У NVIDIA блоб подменяет собой реализацию OpenGL-библиотек Xorg.

    ДА!!!!!!!!!!!!!! :D

    ...................
    >Ни о чём.

    понятно.
    понятно что вам не понятно, что в ситеме может быть несколько реализаций опенжл.

     
     
  • 7.50, ананим (?), 23:39, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    зыж
    >понятно что вам не понятно, что в ситеме может быть несколько реализаций опенжл.

    и их можно преключать по ходу. и даже без перезагрузки. :D
    >случалось после установки NVIDIA Driver и пересборки пакетов Xorg с ключом "-f"

    небось перегружался? :D

     
  • 6.54, Аноним (-), 04:09, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    iZEN, похоже что ты и во FreeBSD не разбираешься :)))
     
     
  • 7.58, Аноним (-), 13:36, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно, не разбирается. Он обычный юзер, к-й думает что он умнее остальных
     

  • 1.14, Аноним (-), 23:50, 15/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в чем плюсы ? Система полностью не упадет если что заглючит при переключении ? Блымкание экрана пропадет ?
     
     
  • 2.15, Аноним (-), 23:55, 15/06/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А в чем плюсы ? Система полностью не упадет если что заглючит
    > при переключении ? Блымкание экрана пропадет ?

    1. Можно запускать иксы не от рута.
    2. Переключение на уровне ядра работает быстрее, чем за его пределами (user space)

     
     
  • 3.40, Аноним (-), 14:27, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Переключение чего?
     
     
  • 4.51, Eugeni Dodonov (ok), 01:24, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Переключение чего?

    Видео-режимов (т.е., с 1024x768@60 на 1920x1200@60 например).

     
     
  • 5.52, iZEN (ok), 01:25, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Переключение чего?
    > Видео-режимов (т.е., с 1024x768@60 на 1920x1200@60 например).

    Оно часто требуется? У вас пиксельное поле на мониторе резиновое или мониторы с различным разрешениями переподключаете постоянно?


     
     
  • 6.53, Eugeni Dodonov (ok), 01:59, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Оно часто требуется? У вас пиксельное поле на мониторе резиновое или мониторы
    > с различным разрешениями переподключаете постоянно?

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

    Хотя на будущих ips panels будет только одно разрешение, что не может не радовать :).

     
     
  • 7.55, Аноним (-), 04:13, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотя на будущих ips panels будет только одно разрешение, что не может
    > не радовать :).

    Век ЭЛТ поддерживающих произвольные разрешения давно закончился, а на LCD мониторах и сейчас одно стандартное разрешение, зачем его в процессе работы переключать на ухудшенный вариант с масштабированием пикселей?

     
  • 6.59, fi (ok), 17:09, 18/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вся  малтимедия требует переключения - под размер кадра

     
  • 5.57, Andrey Mitrofanov (?), 12:27, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Видео-режимов (т.е., с 1024x768@60 на 1920x1200@60 например).

    80*25*9*16@75 забыл, BIOS не вспомнил... //Ну, за МС и ЮЕФИ его, вздрогнем!

     
  • 2.16, кевин (?), 00:08, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    э ну теперь уже ни в чём это продолжение дел натвореных 2 года назад когда фактически прекратилась работа над умс.
     

  • 1.18, Wormik (ok), 00:16, 16/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда подключаю к ноутбуку телевизор по HDMI, оба экрана заполняются мусором. С параметром ядра nomodeset такого нет.

    Никогда не понимал, зачем понадобилось тащить бяку в ati из intel. Чтобы получить убийственное преимущество перед закрытым драйвером "зато у нас переключение в терминал без мерцания экрана!"?

     
     
  • 2.19, Аноним (-), 00:45, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Никогда не понимал, зачем понадобилось тащить бяку в ati из intel.

    Ограниченность - она такая, да. Совет - почитай на досуге, зачем.

     
  • 2.25, Аноним (-), 02:59, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поэтому давайте из какого-то 1 бага конкретной конфигурации сделаем глобальные в... большой текст свёрнут, показать
     
     
  • 3.30, Аноним (-), 08:17, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/


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

    вы не мелочитесь - переносите все видео в ядро. Ведь правильно - Windows не может же ошибаться ?
    Это прямее и лучше - потому что это сделано в Windows!

     
     
  • 4.31, Аноним (-), 09:28, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > вы не мелочитесь - переносите все видео в ядро. Ведь правильно - Windows не может же ошибаться ?

    Это прямее и лучше - потому что это сделано в Windows!

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

     
  • 4.34, filosofem (ok), 11:19, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >вы не мелочитесь - переносите все видео в ядро. Ведь правильно - Windows не может же ошибаться ?
    >Это прямее и лучше - потому что это сделано в Windows!

    Если делать как в венде, то надо иксы в ядро засунуть.
    Так что запускать X под рутом идейно ближе к виндовз-вэй, чем переносить в драйвер низкоуровневый функционал, которому там и место.

     
  • 2.33, nmorozov (ok), 09:45, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Когда подключаю к ноутбуку телевизор по HDMI, оба экрана заполняются мусором. С параметром ядра nomodeset такого нет.

    Тоже хотел написать, что на нескольких кофигурациях с ATI видео, правда видео старинные были R200 и К300 наблюдались видео глюки подобные описаному выше, и они пропадали когда radeon.modeset=0 включал...

     
     
  • 3.41, ананим (?), 14:36, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    ну это просто повод завести запрос в багтреккере и не более.
     

  • 1.20, поцц (?), 01:10, 16/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    недавно приобрёл комп с видео от интеллект .HD 3000 все игры просто летают. а драйвера вкомпилированны в ядро.  и кому эта проприетарщина теперь вообще нужна?
     
     
  • 2.24, Аноним (-), 02:21, 16/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > недавно приобрёл комп с видео от интеллект .HD 3000 все игры просто
    > летают. а драйвера вкомпилированны в ядро.  и кому эта проприетарщина
    > теперь вообще нужна?

    1) У интела кажется не было вообще никаких проприетарных дров под линукс :)
    2) Так тут и рассказывается о открытом амдшном драйвере. У него тоже выносок в ядро есть - в общем та же история что и с интелем.

    А так да, драйвер у интеля вполне позитивный. Ну а второе место я с удовольствием отдаю АМД, у которых видеокарты явно мощнее.

     
     
  • 3.56, Michael Shigorin (ok), 11:25, 17/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) У интела кажется не было вообще никаких проприетарных дров под линукс :)

    Были-были -- для недоразумения по имени poulsbo... и дискретная видеокарта у них тоже была :)

    > А так да, драйвер у интеля вполне позитивный.

    Только подламывают с завидной регулярностью (артефакты лезут), но чинят довольно быстро.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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