"It actually works for me. I have an HD4870 using mplayer from svn (2009-06-26). "
У одного работает. Кто-нибудь тут, бенчмарки, особенно по энергопотреблению?
//rv280@opensource driver user
http://lists.openmoko.org/pipermail/devel/2009-May/005489.html
---- - Handling of Glamo's command queue done at the kernel level, and access from userspace implemented via an ioctl. (очередь команд посылается через ядро)
- Glamo's VRAM managed in the kernel, with buffers being allocated from userspace via a GEM ioctl interface. (видеопамять выделяется на уровне ядра, через интерфейс GEM)
- Minimal decoupling of DRM from PCI. (по-минимуму отделили DRM от PCI )
Может пригодится (как пример работающего кода) для гудящей на краю стола O2, когда-нибудь.
Поэтому подумалось про медицинский линукс-дистрибутив. Какие к нему должны быть требования? Ясно что это должен быть стабильный вариант, с регулярными обновлениями по стабильности. Но вот обязательна ли для него платная поддержка и другие атрибуты коммерческих дистрибутивов? И не имеет ли смысл выгнать хотя бы из этого дистра всю проприетарщину, которая в Линуксе обычно становится причиной многих трудноисправимых проблем, часто как раз при обновлении? Кто знаком с медтехникой, где применяются ОС общего назначения - там высокие требования к ускорению 2D и 3D графики? Если не ошибаюсь, зачинатели Open Graphics Project изначально занимались именно видеокартами для медицинского применения. Пока ничего на их фронте юзабельного нету, но если высокопроизводительное и фичастое 3D не обязательно - то одним источником проблем меньше. В 2D открытый драйвер вполне может быть быстрым, в крайнем случае опен-сорц можно допилить под свои нужды прямо на месте. Остальные внешние железки, работающие по _стандартным протоколам_ особой проблемы не вызовут, надеюсь.
Замечу, что хотелось бы услышать не столько про учётно-медицинские программы, которые на любом дистрибутиве могут (должны) работать, а про специфические, хм, программно-аппаратные комплексы, где не требуется реалтайм.
Это всё. Доброй ночи.
будьте внимательны, в коде есть наше любимое rm -rf
А так результаты интересные - gcc-4.4 (svn r143046) показывает на чистом C (--disable-amd3dnow --disable-amd3dnowext --disable-mmx --disable-mmx2 --disable-sse --disable-ssse3 --disable-yasm) для ffmpeg скорость на 25% выше, чем gcc 4.2 и 4.3. Gcc 3.4.6 и 4.1.2 самые скоростные из gcc. (У меня на нормальной сборке mplayer'а все же 4.2 был быстрее 3.4.6, а 4.3 .3 сейчас быстрее 4.2.4 gcc-svn пока не удосужился собрать.)
Меряется скорость декодирования. Желающие могут модифицировать исходник
На eee pc 901 OpenArena ускорилась с 5.5fps до 34.7fps. Но это ещё не окончательная версия патча. Так что, народ с "интелом вместо видеокарты", не грустите - будет и у вас праздник (в 3D)
http://www.opengl.org/registry/specs/ARB/texture_float.txt
"IP Status
SGI owns US Patent #6,650,327, issued November 18, 2003. SGI believes this patent contains necessary IP for graphics systems implementing floating point (FP) rasterization and FP framebuffer capabilities.
SGI will not grant the ARB royalty-free use of this IP for use in OpenGL, but will discuss licensing on RAND terms, on an individual basis with companies wishing to use this IP in the context of conformant OpenGL implementations. SGI does not plan to make any special exemption for open source implementations."
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=P...
Я одного не понял - ребятки решили нажиться, запатентовав до кучи не только аппаратные реализации, но и формат хранения данных во фреймбуфере ?!
svn co svn://svn.mplayerhq.hu/soc/wmapro/
Играет потихоньку.
Очень кстати, с учётом удаления win32codecs. (в wmv3/wmapro изредка, но попадаются документальные фильмы).
Забавная машинка.
А также в ядро включили-таки squashfs. Одним патчем меньше. 3 hours ago Linus Torvalds Merge git://git./linux/kernel/git/pkl/squashfs-linus
Вкратце - "не все люди в этом мире желают сидеть на x86" (А разработчики альтернативных осей - не могут по понятным причинам использовать линуксовые драйвера даже на x86. Особенно те, где открыта только небольшая часть, интерфейс для общения с бинарным модулем. Другая причина - плохо документированный, брошенный код - но IMHO это не чисто линуксовая проблема.)
Решил вот поделится своим мнением по поводу открытых архитектур. Я не обладаю достаточными знаниями чтобы утверждать чем MIPS, ARM, SH4 (используемые во многих устройствах бытовой электроники) лучше один другого. Но я могу судить с точки зрения продвинутого пользователя, который не чурается заглядывать в исходники, но при этом желает иметь систему чуть быстрее чем z80.
Ассоциация с z80 не случайна - даже этот крайне маломощный (8 бит регистры и шина данных, 7Mhz тактовая - максимальная скорость переброски данных в районе 1 Мегабайта в секунду, меньше миллиона операций в секунду) процессор был достаточным для однозадачного пргограммирования многих довольно ресурсоёмких задач, и моё первое знакомство с причудами схемотехники и понятием "архитектура компьютера" пришло именно со знакомства с разными русскими Спектрум-ориентированными сайтами в районе 2000-го года.
[link block 0 http://zx.pk.ru/ "Спринтер" и всё такое. ]
Именно тогда я узнал про кульный компьютер Amiga и его подход к мультимедиа (графика высокого разрешения, цифровой звук, видео) как к спец-задачам, лучше всего выполянемым спец-процессорами. Намного позже я узнал некоторые подробности про высокопроизводительные рабочие станции SGI. Используя очень умно запрограммированные спец-контроллеры для повторяющихся вычислений 3D-графики на разных этапах построения картинки + специализированное железо для перевода векторного представления графики в растровое первые графические терминалы SGI показывали крайне интересные результаты на очень маломощном по сегодняшним меркам процессоре. Но наверное самое главное - в поисках информации о работе этих древних по нынешним меркам машин я нашел большое количество информации по теории работы с 3-d графикой на _не очень сложных_ примерах, и самое важное - как это сделано в железе. То есть - более всестороннее и глубокое понимание того, как это делается. Вообще, понимание того как работает информационная машина (компьютер), умение модифицировать его поведение, то есть умение быть когда надо чуть-чуть программистом я считаю важнейшм преимуществом пользователя открытых опереационных систем. А воспитание и "разгон" (к вершинам знаний) такого пользователя - важной задачей ПО с открытми исходниками и лицензиями. К сожалению, когда радость творчества перерастает в рутину (нет дров на контроллер винчестера, нет дров на контроллер USB, нет дров на контроллер сетевой карты, нет дров на .... ) у многих хороших программистов опускаются руки. Вот чтобы такое не происходило и важны открытые спецификации на железо. (плюс разумеется умение и желание работать сообща, иногда талантливые разработчики ведут себя не очень честно и проталкивают собственное решение проблем технических с помощью социального давления. Пример есть в листе v4l , не говоря уже про тоже имеющюй отношение к личности разработчика пример с Гансом Рейзером).
[ link blok 1 http://www.futuretech.blinkenlights.nl/o2/ http://www.futuretech.blinkenlights.nl/iris-faq.html http://www.archive.org/details/Computer1984_6
В Гугле например находится статья "The Geometry Engine: A VLSI Geometry System for Graphics", с картинками и пояснениями (англ, естественно) Было очень познавательно. ]
К сожалнию или к счастью, сегодня на дворе самый конец (окнец? намёк на вездесущие пока винды ....) 2008-го года, и просто красивой 3d-картинкой или _цифровым_ звуком никого не удивишь. Огромные потоки цифровой информации генерируются самим домашним пользователем, и он желает чтобы компютер на его столе был не просто игрушкой для программирования самого себя, но и помогал в обработке этой цифровой информации. И тут спектрум-подобные машины к примеру просто остаются за бортом, потому что даже с использованием всех возможных ухищрений объёмы информации измеряемые в мегабайтах в секунду, с жестким условием реалтайм-отображения им просто не по зубам. Картинка размером 1024*768*24 бит - мой рабочий монитор сейчас - занимает больше двух мегабайт в памяти. С учетом того что таких и даже бОльших картинок обычно не одна, а к примеру 4 (четыре рабочих стола в E16 - очень удобно), то объем необходимой оперативной памяти автоматически устремляется в самом идеальном случае к десяткам мегабайт. Необходимость совершать какие-то действия над подобными картинками приводит к необходимости очень высокого быстродействия памяти, шины данных, процессора. (что получается когда шина становится бутылочным горлышком - можно наблюдать на примере открытого смартфона Neo FreeRunner и его видеоподсистемы, где экран 640*480*16 бит подсоединен к видеоакселератору, который черпает данные из памяти через канал шириной меньше чем ISA-шина. 8 мегабайт в секунду, примерно. Подробности в листе рассылки OpenMoko. Или нечто аналогичное для шины Zorro II на Амиге, про которую я узнал из линксового драйвера для фреймбуфера, drivers/video/fm2fb.c) А это - усложнение схемотехники за пределы доступного обычному юзеру с паяльником. Слишком высокие частоты, слишком большое количество проводников. Нет, продвинутый пользователь, кто на работе имеет дело с подобными высоокочастотыми устройствами может и в домашних условиях нарисовать платку, способную работать, и даже стабльно. Но пока такое умение довольно редкое. А значит, железо по-любому будет производить кто-то другой, пользователь же должен просто иметь возможность собрать из блоков то что ему нужно (для экспериментов, удовольствия, или помощи в работе) и запрограммировать получившийся агрегат в меру своих умений (а это обычно для сложных много(суб)процессорных машин выливается в использование идей, алгоритмов и кода других разработчиков - иначе просто не получается.)
Мне кажется, архитектура графстанции начального уровня SGI O2 очень хорошо отражает идею использования дополнительного программируемого элемента (Image Co-Processor), выделенного для быстрой переброски графических и видео данных, с конвертацией на лету по фиксированным (YUV <-> RGB) и/или по загружаемым алгоритмам. Оригинальное (и к сожалению - проприетарное, закрытое и фактически утерянное для масс) программное обеспечениие в составе ОС Irix использовало данный сопроцессор для декодирования сжатых видео потоков, работы с изображениями, OpenGL. На данный момент существует только крайне экспериментальный и заброшенный драйвер для этого сопроцессора, вместе с очень сырым патчем к старым binutils для использования в качестве именно _программируемого_ элемента. Не говоря уже про систему _отображения_, дисплейный контроллер, знания о работе и программировании которого (необходимо для работы Xfree/Xorg с современными библиотеками GUI поверх с приемлимой скоростью) появились в открытом доступе только в этом году, благодаря старанию разработчика из NetBSD.
Лётчики-самолётчики.
При отсутствии другого компа можно было развлекаться убийством себя своей же ракетой ... А владельцы "мощной тачки" всегда имели преимущество в реакции (больше FPS). Так что до какой-то степени авиасимы - классика игр. Linux'а тогда еще не было - зато уже было(о) GNU и был Emacs.
>>> Подробности (Invalid URL, no host part!)
http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt
И там к примеру за 14 октября Add multithreading for PAFF/MBAFF.
Скачал, собрал (были проблемы с libswscale). Вроде работает, но у меня одноядерник. Кто может с реальной многоядерной или многопроцессорной системой проверить? Там есть патчик простенький для mplayer - его пока не пробовал, не успел.
>>> Подробности (Invalid URL, no host part!)
http://home.tal.org/~milang/o2/
особенно вот это, http://home.tal.org/~milang/o2/7.html (gnome, mplayer -vo x11, 352x240 mpeg1 clip, sound enabled, no scaling) И это все на mips 180 Mhz, 512 kb L2 cache, 128Mb ram, 2.5Gb SCSI disk
http://www.in4tec-mbh.com/O2@600/advantage.html Или вот тут модифицированная машинка - 600Mhz cpu-mod, потребляет в целом, по словам автора 70 ватт. Почти достаточно для просмотра DVD - правда под родной Irix (но mplayer судя по всему тот самый, линуксовый)
В принципе есть маленький шанс допилить аппаратный видеоускоритель для простейших (2d/xv) задач - но таких машин раз два и все .... может лет через 10 будет реплика на FPGA, как сейчас NATAMI или Minimig (amiga-like компы)
>>> Подробности (Invalid URL, no host part!)
>>> Подробности (Invalid URL, no host part!)
| ← назад | следующие → |
