MPlayer 0.90-pre7 released - 2002.09.05

Насколько я понял, в 2d разницы теоретически быть не должно. Потому как 2d в этих драйверах - просто смерженный gatos:) Зато есть 3d. Если оно _совсем_ не надо - действительно, ходить на dri не стОит.

>Про mplayerxp и новый драйвер - понял. Да, тут меньше проблем с безопасностью. Хотя непонятно, зачем 2 модуля в
>ядре - для видео vidix и dri. Немножко как-то бардачком попахивает. Но это все уже перфекционизм:)
Потому что DRM выполняет кое-какие проверки, чтобы предотвратить попытки
обращения к нему не со стороны xfree86 - лень подстраиваться под него.
Второе - он в любом случае не может обеспечить работу программы без SUID бита.
(см. права на /usr/X11R6/bin/xfree86)

>Про отрицание Владимиром других форматов я не знал, сорри. Очень жаль. А чем он это аргументирует. Неужели
>только ленью поддерживать?:)
Там нужен triplebuffering а это меняет внутреннюю логику драйвера.

>Про копирование памяти. Т.е. Вы утверждаете, что это делает проц? Почему же тогда загрузка такая маленькая - даже
>в полноэкранной моде? Все-таки копировать N экранов в минуту, да еще и разжимать mpeg - должно быть достаточно
>работы для проца. Как-то даже стало непонятно, почему у меня всего 5% загрузки...
5% на чем? 320x200 или 720x560?
А полноэкранный vs оконный режим значения не имеет благодаря HW scaler'у
Хотя мой страый Duron-700 грузился макс на 30% по average behcnmark при
при декодировании самых тяжелых потоков.

>vo_x11 я пробовал. Очень грузит проц. Соббсно, я именно поэтому не очень верил ругани в сторону xv. Ведь, по-Вашему,
>получается, разницы между ними почти нет. А я ее реально вижу на индикаторе. Почему?
Имелось ввиду что не должно быть framedropping'а а не разницы вообще.
По крайней мере я на своем DHD-1200 смотрю mpeg4 720x560@30fps без потери кадров на vo_x11.

>В любом случае, спасибо за инфу.
;)

>Зато есть 3d
Видел я это 3d :)
Во первых в десятки раз тормознее чем под виндой :(
во-вторых quake3 макс через 15 мин перезагружает комп :(

nick (*) (2002-09-09 13:17:00.242) насчет 3d это гон

nick (*) (2002-09-09 13:17:00.242) насчет 3d это гон

Uman

и все таки ,насколько реальнее быстрее копирование YUV12 или что там еше в mmap video memory сразу , по сравнению с xvideo где кадр копируется через system memory ?

Uman

Про 3d - не согласен. Сравнимо с винюковской скоростью opengl. Eсли у кого-нибудь есть glxgears.exe - могу померить fps. А про перезагрузку - не знаю, не видел. Прошел весь rtcw от начала до конца. Завис ОДИН раз - после того, как игра кончилась, на экране благодарности id software:)

Ага, "лень подстраиваться" - поэтому будем изобретать свой лисапед. Да, X должен быть suid. Но уж проги, использующие X - могут получить все богатство железа через механизм x extensions (одно из них - xv). А вот "обходные пути", собственные интерфейсы - это как-то некрасиво в архитектурном плане. Типа - "мы тут по быстрому хакнем". В перспективе такой подход неизбежно приводит к бараку.

5% - на чем угодно. Сейчас специально посмотрел тизер Two Towers (.mov) в окне порядка 1200х900. Не увидел нагрузки больше 2%. Проц - PIII-80.

Про разницу vo_x11 - я имел в виду разницу проца. Очень этот vo проц грузит (по сравнению с xv).

Короче, vidix предлагает (сомнительное?) преимущество в скорости за счет архитектурных излишеств. Вот если бы авторы vidix помогли Владимиру расширить список форматов (и ввести упоминаемый Вами triplebuffer) - было бы намного лучше, мне кажется. Тогда бы все пользователи xv (который все-таки более распространен как стандарт, мне кажется) смогли бы иметь advantage от этого дела...

Только что посмотрел результат xvinfo:

Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) Так что у меня есть и YUV2 и YUV12. Или Вы считаете, что это программно делается?

Только что посмотрел результат xvinfo:

 Number of image formats: 4
      id: 0x32595559 (YUY2)
        guid: 59555932-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x59565955 (UYVY)
        guid: 55595659-0000-0010-8000-00aa00389b71
        bits per pixel: 16
        number of planes: 1
        type: YUV (packed)
      id: 0x32315659 (YV12)
        guid: 59563132-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
      id: 0x30323449 (I420)
        guid: 49343230-0000-0010-8000-00aa00389b71
        bits per pixel: 12
        number of planes: 3
        type: YUV (planar)
Так что у меня есть и YUV2 и YUV12. Или Вы считаете, что это программно делается?

>и все таки ,насколько реальнее быстрее копирование YUV12 или что там еше в mmap video memory сразу , по сравнению
>с xvideo где кадр копируется через system memory ?
Все очень просто:
1. (Xv) decode->RAM
copy RAM->Video
2. (VIDIX) decode->video
общий прирост скорости равен минус одна memcpy RAM->RAM

Практически все кодеки используют специальные MMX2 инструкции
ускоряющие memcpy RAM->RAM на 600% а RAM->VIDEO (по тестам Arpi
c 95 до 225 fps)

так что generic optimized Xv's memcpy vs MMX2 optimized запись в видео память
в случае с VIDIX - делайте выводы.

>Только что посмотрел результат xvinfo:
>
> Number of image formats: 4
[snip]
>Так что у меня есть и YUV2 и YUV12. Или Вы считаете, что это программно делается?
100% софтово!
Смотрите сорцы - сильно помогает избавиться от подобных сомнений ;)

P.S.: Теже результаты xvinfo будут и для s3virge! ;)

>Ага, "лень подстраиваться" - поэтому будем изобретать свой лисапед. Да, X должен быть suid. Но уж проги,
>использующие X - могут получить все богатство железа через механизм x extensions (одно из них - xv). А вот "обходные
>пути", собственные интерфейсы - это как-то некрасиво в архитектурном плане. Типа - "мы тут по быстрому хакнем". В
>перспективе такой подход неизбежно приводит к бараку.
Я уже сказал - mplayerxp работает без SUID бита!
А DRM не предлагает подобных решений. А с SUID - он мне нафиг не нужен.

>5% - на чем угодно. Сейчас специально посмотрел тизер Two Towers (.mov) в окне порядка 1200х900. Не увидел
>нагрузки больше 2%. Проц - PIII-80.
Если что - .mov это практически .raw! ;)
Вы бы на mpeg4 потестировали.

>Про разницу vo_x11 - я имел в виду разницу проца. Очень этот vo проц грузит (по сравнению с xv).
Если стоит P4 - меньше на индикаторы смотреть надо - оно Вам не пофиг
насколько проц загружен если все и так летает? ;)

>Короче, vidix предлагает (сомнительное?) преимущество в скорости за счет архитектурных излишеств. Вот если бы
Я уже сказал - владельцам P4 просьба не беспокоиться! ;)
>авторы vidix помогли Владимиру расширить список форматов (и ввести упоминаемый Вами triplebuffer) - было бы
>намного лучше, мне кажется. Тогда бы все пользователи xv (который все-таки более распространен как стандарт, мне
>кажется) смогли бы иметь advantage от этого дела...
Владимир и сам все это сделать может. Но оно ему как-бы не сильно надо.
А так как архитектура xfree86 в принципе не может предоставить что-то
аналогичное vidix'у - то мне оно тоже как-бы не сильно надо.
А по поводу стандартов - нафига делали alsa если есть oss?
Здесь мотивы теже - потому что лучше!

>Eсли у кого-нибудь есть glxgears.exe - могу померить fps!
Был бы признателен! ;)

>Ага, "лень подстраиваться" - поэтому будем изобретать свой лисапед.
Я бы сказал что подобного рода "подстройка" была бы illegal activity
с моей стороны и скорее всего они что-нибудь переделали бы в будущих
версиях чтобы исключить unatorized access from side of 3rd programs.

>Практически все кодеки используют специальные MMX2 инструкции >ускоряющие memcpy RAM->RAM на 600% а RAM->VIDEO (по тестам Arpi >c 95 до 225 fps) можно ли ссылку ? очень интересно.

кстати насчет драйвера для которого я писал немного кода для xvideo (c&t), в hardware сделано только YV12 остальное - memcpy Вопрос к Nick: имеет ли смысл заменить memcpy на mmx2 | SSE optimized memcpy прямо в xfree драйвере ? Uman

to anonymous (*) (2002-09-09 00:24:14.645) :

> Я ковырял, причем долго и упорно. Только у меня ничего
> не получалось:)

:)

> Перечитал кучу литературы, но, к сожалению в ней
> не встретилось и упоминания ReiserFS, коя в суси
> ставится по умолчанию, а с ней, насколько я понял,
> и была главная проблема.

EXT3 есть правильный выбор, кроме того можно без проблем
www.partimage.org backup-ить.


>Сегодня попробовал собрать на ext3 - вроде ничего >получилось, >заработало. Правда, очень тихо:). В
>смысле пропал звук.

А конфиг ядра от SuSE брать не пробовал ? ;-)

zcat /proc/config.gz > /root/kernel_config

а потом в xconfig его грузишь, изменяешь, собираешь...

>кстати насчет драйвера для которого я писал немного кода для xvideo (c&t), в hardware сделано только YV12 остальное - memcpy Вопрос к Nick: имеет ли смысл заменить >memcpy на mmx2 | SSE optimized memcpy прямо в xfree драйвере ? Uman
Да конечно! Но такой оптимизации требует весь проект целиком а не только отдельный драйвер!
В любом случае это не догонет по производительности VIDIX так как
лишняя memcpy все-равно остается!

Только такой, чтобы прямо работал с opengl/win32. А то - я попробовал это запустить из cygwin, так оно вообще начало страшно ключить...

В смысле - чтобы не glx, чтобы без X работал. Есть у кого-нибудь такое щастье? Или visual studio - чтобы подрихтовать сырцы glxgears для работы с винюками напрямую.

>Только такой, чтобы прямо работал с opengl/win32. А то - я попробовал это запустить из cygwin, так оно вообще начало >страшно ключить...
Вы бы просто опубликовали fps под linux. Например Matrox G400 под linux
дает 1200 fps а вот radeon8500 - что-то около 350-400fps всего.
(По крайней мере на момент моего последнего анализа этой проблемы)

По просьбам трудящихся. На моей Mobility (семейство Mach64!, AGP) 8M RAM. Максимальный fps в 16битах - 283.4 (800x600). Средний - около 260 (1024х768, 1280х1024). Понятное дело, радеонам и гефорсам просьба не беспокоиться:). Неужели плохо для mach64? Измерения сделаны glxgears с размером окна "по умолчанию" (т.е. как стартует - так и работает).

С xfree86-4.2.0+gatos у меня на RadeonVE - 160 fps (это на новом проце - на старом было 120)
А где бы diff скачать для XFree86-CVS или 4.2.0?
Не хочу еще один CVS выкачавать!

160 fps ? так это в софте http://dri.sourceforge.net/snapshots/radeon-20020909-linux.i386.tar.bz2

На всякий случай - мои результаты взяты не с XFree из CVS. Это обычный XFree 4.2.0 (ну, точнее, redhat rawhide) и бинарники проекта dri. В главном дереве XFree этого всего нет. Хотя, про радеон наверняка сказать не могу.

В софте или не в софте - поможет узнать glxinfo. Посмотрите, что она Вам говорит, увидите. У меня первые 2 строки:

display: :0.0 screen:0

direct rendering: Yes

у меня все тоже самое:

display: :0 screen: 0
direct rendering: Yes
server glx vendor string: Brian Paul
server glx version string: 1.3 Mesa 3.4.2
...

но это gatos а не dri.

Странно. Даю весь выхлоп:

display: :0.0  screen:0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Gareth Hughes
OpenGL renderer string: Mesa DRI Mach64 20020227 [Rage Pro] AGP 2x x86/MMX/SSE
OpenGL version string: 1.2 Mesa 4.0.3
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_transpose_matrix, 
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, 
    GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, 
    GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, 
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, 
    GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, 
    GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, 
    GL_SGI_color_table
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x24 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x25 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x26 16 tc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow
0x27 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0  0  0  0  0  0 0 None
0x28 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8  0  0  0  0  0 0 Slow
0x29 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  0 16 16 16  0  0 0 Slow
0x2a 16 dc  0 16  0 r  y  .  5  6  5  0  0 16  8 16 16 16  0  0 0 Slow

мой выхлоп почти такой же только версия побольше.
Насколько я знаю просто обновить дрова и drm не достаточно
поскольку ATI'шные дрова для fx8700 подновляют и libGL* тоже
поскольку именно она содержит софтовую эмуляцию всех перечисленных
выше функций. А это уже затрагивает все дерево CVS.
Но если dri-devel не делают никаких патчей к xfree86 то для меня
это полный облом ;)

Да, в этом случае Вас действительно жалко. Насколько лучше иметь mach64!:) У меня-то libGL тот же самый, поэтому бинарники ставятся "на раз". А вообще - сходите в dri mailing list. Там народ отзывчивый, может, пособят...

Nick: ili ya chego to ne ponimayu ili.. eto is radeon_video i vidno chto v zhelezhe sdelany FOURCC_YV12 i FOURCC_YUY2 gde zhe zdes' soft dlya FOURCC_YV12 ???

if(id == FOURCC_UYVY) OUTREG(RADEON_OV0_SCALE_CNTL, RADEON_SCALER_SOURCE_YVYU422 \ | RADEON_SCALER_ADAPTIVE_DEINT \ | RADEON_SCALER_SMART_SWITCH \ | RADEON_SCALER_DOUBLE_BUFFER \ | RADEON_SCALER_ENABLE); else OUTREG(RADEON_OV0_SCALE_CNTL, RADEON_SCALER_SOURCE_VYUY422 \ | RADEON_SCALER_ADAPTIVE_DEINT \ | RADEON_SCALER_SMART_SWITCH \ | RADEON_SCALER_DOUBLE_BUFFER \ | RADEON_SCALER_ENABLE); Uman

Не надо путать yv12 и yvyu422.
yv12 это yvu420 в других обозначениях
Т.е. драйвер поддерживает только YUV422 и YVYU422 - оба
упаскованные т.е. packed и не поддерживает ни одного planar
формата

2svu а за какое число ты драйвер используешь? я пробовал августовские снапшоты в них gl работает, xv - нет, а сейчас выкачал вообще ничего не работает, dri, drm, glx,GLcore грузятся, а glxinfo пишет что нет поддержки. карта - ATI Rage Mobility M1

Может расскажете как дела обстоят с этой кучей драйверов айтишных? К чему каждые нужны ? Интересуют под райдж про.