В Спб кто-то такое счастье хочет? Появилась шальная мысль поспрашивать наши ВУЗы, вдруг они могут помочь в этом деле, с оплатой изготовления плат? ВУЗ платит, студенты изучают. Результат доступен всему сообществу. Или у нас такие мечты не прорастают дальше бумаги? Всё-таки в кои то веки есть шанс повозиться с видео-ускорителем .... Нету своих процессоров - так может хоть на видеокарте уедем?
Сидел, смотрел как gentoo компиляет проги (через NFS, на разделе с xfs). Что-то никак coreutils не компилялись, потом компиляция ppl аварийно прервалась. Ребутнул SGI (клиента), на соседнем разделе стал пакетик с Mplayer-ом запаковывать - и опс.
----
May 24 09:19:39 (none) kernel: ------------[ cut here ]------------
May 24 09:19:39 (none) kernel: kernel BUG at lib/radix-tree.c:473!
May 24 09:19:39 (none) kernel: invalid opcode: 0000 [#1] SMP
May 24 09:19:39 (none) kernel: last sysfs file: /sys/devices/platform/w83627hf.656/in8_input
May 24 09:19:39 (none) kernel: Modules linked in: radeon drm ipv6 sg sd_mod snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq s
nd_pcm_oss snd_mixer_oss nfsd lockd nfs_acl auth_rpcgss sunrpc usb_storage scsi_mod libusual tuner_simple tuner_types tda9887 snd_
cs4232 snd_mpu401 tda8290 snd_emu10k1 snd_wavefront snd_via82xx snd_ac97_codec snd_wss_lib saa7134 ac97_bus uhci_hcd snd_pcm ir_co
mmon ehci_hcd snd_opl3_lib videobuf_dma_sg snd_page_alloc snd_timer snd_util_mem snd_mpu401_uart videobuf_core usbcore tveeprom pp
dev shpchp snd_hwdep pci_hotplug emu10k1_gp snd_rawmidi snd_seq_device 8139too rtc_cmos via_agp rtc_core snd rtc_lib ns558 gamepor
t soundcore parport_pc parport xfs exportfs ufs agpgart tuner v4l2_common videodev v4l1_compat w83627hf hwmon_vid hwmon i2c_viapro
i2c_dev
May 24 09:19:39 (none) kernel:
May 24 09:19:39 (none) kernel: Pid: 199, comm: kswapd0 Not tainted (2.6.29.4-i486 #3) MS-6380E
May 24 09:19:39 (none) kernel: EIP: 0060:[<c10ff322>] EFLAGS: 00010202 CPU: 0
May 24 09:19:39 (none) kernel: EIP is at radix_tree_tag_set+0x1d/0xa8
May 24 09:19:39 (none) kernel: EAX: cf083a58 EBX: c6e70280 ECX: 00000000 EDX: 01e1dd64
May 24 09:19:39 (none) kernel: ESI: cf2d8c00 EDI: 00000000 EBP: cfa86e80 ESP: cfa86e60
May 24 09:19:39 (none) kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
May 24 09:19:39 (none) kernel: Process kswapd0 (pid: 199, ti=cfa86000 task=cfa94000 task.ti=cfa86000)
May 24 09:19:39 (none) kernel: Stack:
May 24 09:19:39 (none) kernel: 00000000 01e1dd64 cf083a58 cf083bec ce33ef84 c6e70280 cf2d8c00 cf083a20
May 24 09:19:39 (none) kernel: cfa86e9c d0abbc48 c6e70324 cf083a54 c6e703a4 c6e70280 00000045 cfa86eac
May 24 09:19:39 (none) kernel: d0aaf508 c6e703a4 c6e703ac cfa86eb8 d0aba743 c6e703a4 cfa86ec4 c10961ec
May 24 09:19:39 (none) kernel: Call Trace:
May 24 09:19:39 (none) kernel: [<d0abbc48>] ? xfs_inode_set_reclaim_tag+0x69/0x88 [xfs]
May 24 09:19:39 (none) kernel: [<d0aaf508>] ? xfs_reclaim+0x88/0x8e [xfs]
May 24 09:19:39 (none) kernel: [<d0aba743>] ? xfs_fs_destroy_inode+0x2a/0x43 [xfs]
May 24 09:19:39 (none) kernel: [<c10961ec>] ? destroy_inode+0x27/0x38
May 24 09:19:39 (none) kernel: [<c10962ad>] ? dispose_list+0xb0/0xd9
May 24 09:19:39 (none) kernel: [<c1096486>] ? shrink_icache_memory+0x1b0/0x1dd
May 24 09:19:39 (none) kernel: [<c106c673>] ? shrink_slab+0xd8/0x132
May 24 09:19:39 (none) kernel: [<c106cac3>] ? kswapd+0x3f6/0x56e
May 24 09:19:39 (none) kernel: [<c106b1e4>] ? isolate_pages_global+0x0/0x1b0
May 24 09:19:39 (none) kernel: [<c1034437>] ? autoremove_wake_function+0x0/0x33
May 24 09:19:39 (none) kernel: [<c101b1e6>] ? complete+0x34/0x3e
May 24 09:19:39 (none) kernel: [<c106c6cd>] ? kswapd+0x0/0x56e
May 24 09:19:39 (none) kernel: [<c103415c>] ? kthread+0x3b/0x61
May 24 09:19:39 (none) kernel: [<c1034121>] ? kthread+0x0/0x61
May 24 09:19:39 (none) kernel: [<c10037c7>] ? kernel_thread_helper+0x7/0x10
May 24 09:19:39 (none) kernel: Code: b4 89 42 04 83 c4 4c 89 f0 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 14 89 45 e8 89 55 e4 89 4d
e0 8b 38 3b 14 bd 6c ee 39 c1 76 04 <0f> 0b eb fe 8b 45 e8 8b 55 e0 8b 70 08 6b c7 06 c1 e2 03 89 55
May 24 09:19:39 (none) kernel: EIP: [<c10ff322>] radix_tree_tag_set+0x1d/0xa8 SS:ESP 0068:cfa86e60
May 24 09:19:39 (none) kernel: ---[ end trace 06b8f5f516406ef0 ]---
Кажется не я первый:
lkml.org/lkml/2009/5/14/360
lists.debian.org/debian-kernel/2009/05/msg00000.html
https://lists.linux-foundation.org/pipermail/bugme-new/2009-April/021632.html
Железки нету, в код даже не глядел пока, но описание выглядит интересно:
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 открытый драйвер вполне может быть быстрым, в крайнем случае опен-сорц можно допилить под свои нужды прямо на месте. Остальные внешние железки, работающие по _стандартным протоколам_ особой проблемы не вызовут, надеюсь.
Замечу, что хотелось бы услышать не столько про учётно-медицинские программы, которые на любом дистрибутиве могут (должны) работать, а про специфические, хм, программно-аппаратные комплексы, где не требуется реалтайм.
Это всё. Доброй ночи.
Карта как я понял 4Гб. Была она нестандартной SD, или SDHC - не знаю. В no-name SD - USB картридере карточка сделала вот так:
Apr 24 17:59:30 (none) kernel: sd 0:0:0:1: [sdb] 11981824 512-byte hardware sect
ors (6135 MB)
Apr 24 17:59:30 (none) kernel: sd 0:0:0:1: [sdb] Write Protect is on
Apr 24 17:59:30 (none) kernel: sd 0:0:0:1: [sdb] 11981824 512-byte hardware sect
ors (6135 MB)
Apr 24 17:59:30 (none) kernel: sd 0:0:0:1: [sdb] Write Protect is on
Apr 24 17:59:30 (none) kernel: sdb: sdb1
Apr 24 17:59:30 (none) kernel: sd 0:0:0:1: [sdb] Attached SCSI removable disk
Apr 24 17:59:30 (none) kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Apr 24 17:59:30 (none) kernel: sd 0:0:0:1: Attached scsi generic sg1 type 0
Потом ещё раз ....
Apr 24 18:06:14 (none) kernel: scsi 1:0:0:1: [sdb] Write Protect is off
Apr 24 18:06:45 (none) kernel: usb 1-3: new high speed USB device using ehci_hcd and address 4
Apr 24 18:06:45 (none) kernel: usb 1-3: configuration #1 chosen from 1 choice
Apr 24 18:06:45 (none) kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Apr 24 18:06:50 (none) kernel: scsi 2:0:0:0: Direct-Access Generic USB SD Reader 1.00 PQ: 0 ANSI: 0
Apr 24 18:06:51 (none) kernel: sd 2:0:0:0: [sda] 11981824 512-byte hardware sectors (6135 MB)
Apr 24 18:06:51 (none) kernel: sd 2:0:0:0: [sda] Write Protect is on
Apr 24 18:06:51 (none) kernel: sd 2:0:0:0: [sda] 11981824 512-byte hardware sectors (6135 MB)
Apr 24 18:06:51 (none) kernel: sd 2:0:0:0: [sda] Write Protect is on
Apr 24 18:06:51 (none) kernel: sda: sda1
Apr 24 18:06:51 (none) kernel: sd 2:0:0:0: [sda] Attached SCSI removable disk
Apr 24 18:06:51 (none) kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0
Apr 24 18:06:51 (none) kernel: scsi 2:0:0:1: Direct-Access Generic USB CF Reader 1.01 PQ: 0 ANSI: 0
Apr 24 18:06:51 (none) kernel: sd 2:0:0:1: [sdb] Attached SCSI removable disk
Apr 24 18:06:51 (none) kernel: sd 2:0:0:1: Attached scsi generic sg1 type 0
Apr 24 18:06:51 (none) kernel: scsi 2:0:0:2: Direct-Access Generic USB SM Reader 1.02 PQ: 0 ANSI: 0
Apr 24 18:06:51 (none) kernel: sd 2:0:0:2: [sdc] Attached SCSI removable disk
Apr 24 18:06:51 (none) kernel: sd 2:0:0:2: Attached scsi generic sg2 type 0
Apr 24 18:06:51 (none) kernel: scsi 2:0:0:3: Direct-Access Generic USB MS Reader 1.03 PQ: 0 ANSI: 0
Apr 24 18:06:51 (none) kernel: sd 2:0:0:3: [sdd] Attached SCSI removable disk
Apr 24 18:06:51 (none) kernel: sd 2:0:0:3: Attached scsi generic sg3 type 0
Apr 24 18:06:51 (none) kernel: scsi 2:0:0:4: Direct-Access Generic Mini SD Reader 1.06 PQ: 0 ANSI: 0
Apr 24 18:06:51 (none) kernel: sd 2:0:0:4: [sde] Attached SCSI removable disk
Apr 24 18:06:51 (none) kernel: sd 2:0:0:4: Attached scsi generic sg4 type 0
Apr 24 18:07:02 (none) kernel: agpgart-via 0000:00:00.0: AGP 2.0 bridge
Apr 24 18:07:02 (none) kernel: agpgart-via 0000:00:00.0: putting AGP V2 device into 4x mode
Apr 24 18:07:02 (none) kernel: radeon 0000:01:00.0: putting AGP V2 device into 4x mode
Apr 24 18:07:02 (none) kernel: [drm] Loading R200 Microcode
Apr 24 18:07:21 (none) kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 4
Apr 24 18:07:53 (none) kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 4
Apr 24 18:08:55 (none) last message repeated 2 times
Apr 24 18:09:26 (none) kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 4
Apr 24 18:09:49 (none) kernel: agpgart-via 0000:00:00.0: AGP 2.0 bridge
Apr 24 18:09:49 (none) kernel: agpgart-via 0000:00:00.0: putting AGP V2 device into 4x mode
Apr 24 18:09:49 (none) kernel: radeon 0000:01:00.0: putting AGP V2 device into 4x mode
Apr 24 18:09:49 (none) kernel: [drm] Loading R200 Microcode
Apr 24 18:09:57 (none) kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 4
Apr 24 18:09:58 (none) kernel: sd 2:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00
Apr 24 18:10:28 (none) kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 4
Apr 24 18:10:59 (none) kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 4
Apr 24 18:12:02 (none) last message repeated 2 times
Apr 24 18:13:04 (none) last message repeated 2 times
Apr 24 18:13:05 (none) kernel: sd 2:0:0:0: [sda] Result: hostbyte=0x05 driverbyte=0x00
После чего мы на её отложили подальше. Сам фотик (не мой Pentax) карточку не признавал, а потом вообще не смог запуститься (севшее питание ? индикатор на камере говорил об этом). В общем жду когда друг привезёт всё к себе домой и там проверит.
Карточка ИЗНАЧАЛЬНО отказалась работать во время просмотра фотографий через фотик, в метро. Сижу и думаю - "на коленке" из неё фотки вытащить можно, или без спец-железки не обойтись?
http://multimedia.cx/eggs/icc-vs-gcc-smackdown-round-3/#more-1225
будьте внимательны, в коде есть наше любимое 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 пока не удосужился собрать.)
Меряется скорость декодирования. Желающие могут модифицировать исходник
Получил девайс.
---
sgio2 ~ # uptime
00:04:14 up 4 min, 1 user, load average: 0.85, 0.70, 0.30
sgio2 ~ # cat /proc/cpuinfo
system type : SGI O2
processor : 0
cpu model : R5000 V2.1 FPU V1.0
BogoMIPS : 179.71
wait instruction : yes
microsecond timers : yes
tlb_entries : 48
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available
sgio2 ~ # uname -a
Linux sgio2 2.6.29-rc4-00212-g29f2fa2 #9 Wed Feb 18 02:13:03 GMT 2009 mips64 R5000 V2.1 FPU V1.0 SGI O2 GNU/Linux
Сейчас комп работает без клавиатуры, монитора и мыши - через serial-кабель и NFS (ядро грузится через tftp). На nfs - распакованный stage3 отсюда:
http://dev.gentoo.org/~redhatter/mips/sgi/stages/
распаковал, поправил /etc/conf.d/hostname , /etc/conf.d/net (добавил строчку config_eth0=( "noop" "192.168.1.3/24" ) , закомментировал всё в /etc/fstab).
Потом загрузился ....
cu -l /dev/ttyS1 - коннектимся к ком-порту, получаем доступ к менюшке, выбираем 5, получаем приглашение, куда вбиваем строчку запуска
> bootp():/linux-2.6.29 "nfsaddrs=192.168.1.3 nfsroot=/mnt/hdc6/NFS/sgio2/gentoo console=ttyS0,9600n8 rw"
ядро грузится ....
по ходу старта системы cu несколько раз отваливается, но в конце концов получаем
sgio2 login:
И осознаем что логина-то мы и не знаем!
Пришлось грузится с init=/bin/sh , и использовать passwd для смены пароля внутри системы.
Перезагрузка ...
И получаем то что вначале.
Смонтировать нечисто выключенный диск с XFS от IRIX'а ядро не смогло, но это временные трудности. Главное у меня есть рабочая система для проверки ядер!
(А до linux-а я примерно таким же образом NetBSD-5 заставил грузится, и обновил её до -current. При этом сериальная консоль отвалилась, зато понял как кросс-компилить на линукс-машине NetBSD с помощью ./build.sh, и получил возможность попинать сырой 2D-драйвер под видео)
http://article.gmane.org/gmane.comp.video.dri.devel/33469
На eee pc 901 OpenArena ускорилась с 5.5fps до 34.7fps. Но это ещё не окончательная версия патча. Так что, народ с "интелом вместо видеокарты", не грустите - будет и у вас праздник (в 3D)
http://article.gmane.org/gmane.comp.video.mesa3d.devel/12006
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 изредка, но попадаются документальные фильмы).
http://multimedia.cx/eggs/got-a-cheap-mips-subnotebook/#more-839 А это кажется её процессор/чипсет http://www.rockbox.org/twiki/bin/view/Main/IngenicJz47xx
Забавная машинка.
А также в ядро включили-таки squashfs. Одним патчем меньше. 3 hours ago Linus Torvalds Merge git://git./linux/kernel/git/pkl/squashfs-linus
Навеяно http://www.haiku-os.org/blog/mmu_man/2008-11-03/say_what_you_want_from_us_but...
Вкратце - "не все люди в этом мире желают сидеть на 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.
http://my.opera.com/Macallan/blog/index.dml/tag/O2
сама новость укладывается в несколько строчек:
-------
Make VSync for EXA and Xv configurable Alex Deucher
Optimise RADEONWaitForVLine Pierre Ossman
Improve tearing avoidance for Xvideo in two steps Pierre Ossman
First pass at tear-free accel Alex Deucher
Switch r200 Xv to use rect lists rather than quads to avoid tearing
-------
что в переводе с технического на русский означает что изображение, выводимое через Xvideo на видеокартах r200-r500 не должно теперь (по идее) "разрываться" при просмотре, в комментарии сказано что радеоны от r300 и выше теперь используют один большой треугольник с видео, обрезанный аппаратно до прямоугольника - так получается рендерить видео в один проход, что совместно с изменениями в EXA позволяет синхронизировать изображение с разверткой. Есть специальная опция которая это включает: EXAVSync
А также чуть раньше была добавлена возможность автоматического включения бикубического масштабирования при масштабировании больше 200% (при меньших значениях изображение от бикубической фильтрации было замыленным). Ставится через атрибут xvideo XV_BICUBIC (ставим xvattr, если еще не установлен)
Тестируем, радуемся (или плачемся в багзиллу)
http://groups.google.com/group/comp.sys.sgi/browse_thread/thread/418d43968608...#
Лётчики-самолётчики.
При отсутствии другого компа можно было развлекаться убийством себя своей же ракетой ... А владельцы "мощной тачки" всегда имели преимущество в реакции (больше FPS). Так что до какой-то степени авиасимы - классика игр. Linux'а тогда еще не было - зато уже было(о) GNU и был Emacs.
Нашел такую штуку:
http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt
И там к примеру за 14 октября Add multithreading for PAFF/MBAFF.
Скачал, собрал (были проблемы с libswscale). Вроде работает, но у меня одноядерник. Кто может с реальной многоядерной или многопроцессорной системой проверить? Там есть патчик простенький для mplayer - его пока не пробовал, не успел.
Хм. А машинка-то оказывается даже без своего знаменитого аппаратного ускорения видео и OpenGL весьма неплоха ....
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 компы)
http://img70.imageshack.us/my.php?image=nv40xvmc2ra9.png
Работает, работает :) Первый раз, когда я вижу аппаратно ускоренное (замедленное в данном случае, ибо все сыро до невозможности) видео в открытом драйвере, не просто CSC and scaling (преобразование цвета и масштабирование) а настоящий видеодекодинг!
http://www.bitblit.org/gsoc/g3dvl/index.shtml - страничка проекта
http://gitweb.freedesktop.org/?p=nouveau/mesa.git;a=shortlog;h=gallium-0.1
- а это исходный код.
собрал, поправив makefiles, положил libnouveau_dri.so в /usr/local/lib, ldconfig, далее
LD_PRELOAD=/home/guest/source/nv-experimental/gallium-0.1/mesa/src/libXvMC/libX vMCg3dvl.so mplayer -fs /home/guest/documents/video/20070715-Full-Immersion.mpg -quiet -vo xvmc -vc ffmpeg12mc -vf-clr
В отличие от 3D драйвера оно не потребовало SSE, хотя в ходе грядущих оптимизаций может быть всякое.
Однако круто, круче наверное только вот этот коммит в 2d-драйвере:
nv50: support YUY2 in textured video adaptor
kernel 2.6.25.10 and suspend-to-disk Задали тут вопросец на #radeon, у кого машина после обновления drm/libdrm перестала нормально засыпать-просыпаться? Поскольку у меня радеон, хоть и старый (rv280, radeon9200se) решил проверить и понял что swap-partition у меня не наблюдается (256 Мб памяти). прочитал Documentation/power/swsusp-and-swap-files.txt скомпилировал и поставил suspend-0.8 с http://suspend.sourceforge.net/ (потребовал libx86 с http://www.codon.org.uk/~mjg59/libx86/downloads/, взял Libx86 1.1). Потом сделал как советовалось в документации: dd if=/dev/zero of=/swap.file bs=1024 count=400000 (у меня корень на /dev/hdc1 , у вас будет свое устройство, размер свап-файла в этом примере около 400 Мб) mkswap /swap.file swapon /swap.file cd /home/guest/source/suspend-0.8 (тут у меня лежат сырцы суспенд-0.8) ./swap-offset /swap.file (узнал смещение начала файла) А потом простое echo disk > /sys/power/state НЕ СРАБОТАЛО. Оказалось нужно СНАЧАЛА было добавить в параметры ядру resume= and resume_offset= . Сделал в lilo.conf: append="nocd nopcmcia max_loop=255 nohotplug vt.default_utf8=0 resume=/dev/hdc1 resume_offset=168582" (resume_offset сказала прога swap-offset, в инете видел патчик на -mm ядро который добавлял нужную инфу прямо в лог ядра, но в майнлайне его все еще нет, по крайней мере не в 2.6.25) вот теперь (после перезагрузки с указанными параметрами) echo disk > /sys/power/state работает как надо!
http://nouveau.cvs.sourceforge.net/nouveau/nv40_xvmc/
как предупреждает разработчик, там даже вывода на экран пока не реализовано, либа просто делает Motion Compensation силами аппаратного декодера на nv4x. Подробнее процесс описан в исходниках, и тут: http://nouveau.freedesktop.org/wiki/jb17bsome
Еще один проект: http://www.bitblit.org/gsoc/g3dvl/index.shtml Железонезависимое (в известных пределах) аппаратное ускорение mpeg2, в перспективе и других форматов.
разработчик уже засветился на #nouveau.
А в ffmpeg добавили поддержку libdirac и libschroedinger, идет работа над MLP, E-AC3, rv30/40. Что не может не радовать....
| ← назад | следующие → |
