Ассемблер

[uncle]

Через гугл диск немножко не так как я ожидал. Берите через mail.ru
http://files.mail.ru/47AC93067C3F463B89C4D028D8474936

[SWAT]

Спасибо! Выглядит на первый взгляд это не очень быстро Но я надеюсь что будет лучше чем сейчас. Ты про режимы говорил что типа все разом или по очереди макроблоки? Про этот то я знаю, только дело в том что делить то их надо в любом случае. И почему ты делишь на 8х8, ведь можно же побольше - 16х16.
Я видел метод с помощью палитр, но почему то у меня не получилось с ним.

[uncle]

Формат макроблока YUV конвертера: U,V,Y00,Y01,Y10,Y11 - блоками 8x8. Единственное что можно сделать для уменьшения операций при делении на макроблоки (функция mbcopy2) - это заинлайнить вызовы функции block8x8_copy в ее тело. Скорости это скорее всего не прибавит так как bottleneck в скорости RAM. И вообще, возможно, не очень хорошая идея потому что кэш инструкций надо экономить. Скорость же самого YUV конвертера порядка 200 текстур 512x512 в секунду (это примерно, по памяти), что довольно прилично, учитывая что для вывода видео надо 25-30 кадров в секунду. При этом DMA трансфер работает независимо - процессор может заниматься полезной работой. Таким образом данная реализация является довольно производительной.
Что касается варианта с палитрами - он работает я в свое время проверял. Но в реализация в приведенном примере не эффективна. Загрузка текстур в видеопамять производится не по DMA. Более того KOS-овская функция pvr_txr_load_ex конвертирует текстуру в twiddle формат. В KOS вообще почему-то не предусмотрена передача не twiddle текстур по DMA. Но потенциально это можно сделать и этот вариант будет немного быстрее первого.

[SWAT]

Хочешь сказать что в пакованном YUV420P макроблоками картинка??? Мне ffmpeg их выдает просто отдельными буферами Y, U и V с их длинной

[uncle]

Ну правильно три буфера. Из них функция mbcopy2 режет макроблоки, затем запускается DMA трансфер через аппаратный YUV конвертер (функция pvr_txr_load_dma_from_yuv_converter).

[SWAT]

Не могу найти инфы о макроблоках в этом формате, может есть ссылка?
В моей текущей реализации и так используется DMA, только я конвертирую YUV420P в YUV422 и загружаю уже целиком как нативно поддерживаемую текстуру по DMA каналу сразу в видео память.
Не знаю, есть ли смысл заморачиваться с конвертером... Ты бы еще саму mbcopy2 на асме написал и использовал спец. регистры для арифметики (те что для 3D матриц), они выполняют больше операций за такт, чем обычные регистры, главное скомпоновать грамотно.
Конечно если узкое место память, то это не сильно поможет, но все же. Может Store Queues помогут?

[uncle]

Нарезка на макроблоки для YUV конвертера гораздо быстрее конвертации в YUV422 и памяти пересылать немного меньше, так что заморачиваться стоит. Смотри внимательно реализацию mbcopy2 - функция block8x8_copy написана на ассемблере, ее реализация в отдельном файле block8x8.s. Она эффективна, store queues дадут схожую производительность. Формат макроблока YUV420: последовательно блоками 8x8 для макроблока 16x16 пикселей - U, V, Y00, Y01, Y10, Y11. Прочитал когда-то в описании архитектуры. Ты вообще из каких источников берешь информацию о железе? Насчет пересылки по DMA: ты как осуществляешь пересылку (какой косовской функцией)? Если ты сразу после конвертации в YUV422 текстуру запускаешь DMA операцию - обязан словит проблему. Будешь видеть артефакты в выведенном кадре. Если их нет, значит пересылка не по DMA.

[SWAT]

Я вижу что block8x8_copy на асме, а сама mbcopy2 почему не на нем то? Или нет смысла, так как после компиляции код и так хорош типа?
В смысле Store Queues дадут схожую производительность? Их же можно использовать вместе с твоим кодом! В этом случае должно быть лучше...
Я использую функцию pvr_txr_load_dma которая в свою очередь использует функцию pvr_dma_transfer, а она только по DMA и копирует, в TA/YUV в 32 битном режиме, а если напрямую в память, то в 64 битном режиме. Да и с чего бы я начал ловить артефакты вообще? Нет никаких проблем с этим. А вот с YUV-конвертером как раз такое и было, но я там видимо не правильно делил на макроблоки, надо будет попробовать твою функцию.
Информацию я беру из разных источников, допустим о YUV-конвертере я читал в DCDBSysArc990907E.

[uncle]

Саму mbcopy2 не вижу смысла писать на ассемблере. Как вместе задействовать SQ не представляю, вместо можно попробовать. По моим оценкам текущая реализация должна давать чуть больше 400 512x512 фреймов в секунду. Для практических задач этого достаточно и вразы быстрее конвертации в текстуру. Но, конечно это не предел шины памяти. И ради спортивного интереса можно поиграться. Описание формата макроблоков YUV конвертера на 215 странице упомянутого тобой документа. Для DMA трансфера через YUV конвертер можешь использовать стандартный косовский механизм. Для этого:

static vuint32 * const tareg = (vuint32 *)0xa05f8000;

// YUVCONV registers
#define TA_YUV_TEX_BASE 0x148/4
#define TA_YUV_TEX_CTRL 0x14c/4
#define TA_YUV_TEX_CNT 0x150/4

tareg[TA_YUV_TEX_BASE] = dest_addr; // адрес в текстурной памяти
tareg[TA_YUV_TEX_CTRL] = ((w / 16 - 1) << 8) | (h / 16 - 1); // w и h высота и ширина соответственно
val = tareg[TA_YUV_TEX_CTRL]; // просто прочитать

pvr_dma_transfer(src, 0x800000, count, PVR_DMA_TA, block, callback, cbdata); // src - адрес где размещены макроблоки

Про артефакты - непосредственно перед DMA передачей часть данных может находится в линейках кэша процессора для которых еще не было write back. И соответственно в RAM лежат не актуальные данные. DMA операции не когерентны с процессорным кэшем и при трансфере в текстурную память уйдет этот мусорок. Все это относится к реальному железу, на эмуляторах не проявится.

Попробовать стоит. Ускорение по сравнению с конвертацией в текстуру значительное.

[MetalliC]

в теории, если оно упирается в скорость памяти, быстрее всего будет через Store Queue, т.е. в mbcopy2/_block8x8_copy вместо записи в промежуточный буфер писать в SQ и сбрасывать по 32байт PREF-ом в YUV-конвертор, понятно что данные должны идти последовательно, сначала все U, потом V, потом Y, и хз будет ли оно так быстрее на практике)

вообще игры работают и так и сяк, все Katana-вские по DMA целиком текстуру шлют, все WinCE-шные через SQ

(27.09.2013 07:04)SWAT писал(а):  Я вижу что block8x8_copy на асме, а сама mbcopy2 почему не на нем то? Или нет смысла, так как после компиляции код и так хорош типа?

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

а вот в старые компиляторы, типа как в Katana r8/r9 на котором и сделано большинство игр, тупнячковые, генерят код больше похожий на изначальный, т.е. инструкции расположены в порядке типа как и было в С-шном коде, и это с одной стороны хорошо - в отладчике или IDA его не так сложно реверсить

[uncle]

Цитата:в теории, если оно упирается в скорость памяти, быстрее всего будет через Store Queue, т.е. в mbcopy2/_block8x8_copy вместо записи в промежуточный буфер писать в SQ и сбрасывать по 32байт PREF-ом в YUV-конвертор, понятно что данные должны идти последовательно, сначала все U, потом V, потом Y, и хз будет ли оно так быстрее на практике)

Кидать напрямую в конвертер было бы лучшим вариантом. Но будет ли это работать... Есть эмулятор на котором это адекватно эмулируется? С железом я точно заморачиваться не буду. Собрал я вчера последний lxdream, но YUV конвертер у меня не получилось с ним задействовать.

[MetalliC]

на железе должно), на эмуляторах - смотря как и в каком режиме, DMA YUV420 умеют и Demul и NullDC.
SQ тоже, но с оговорками - нуль на этот предмет не тестировался на практике т.к. винце игры под ним не живут,
в Demul есть бага - если в TA_YUV_TEX_CTRL размер по X/Y не равен количеству реально засылаемых макроблоков - картинка будет "плыть" (WinCE игры почему-то так делают, ставят размер по У 32 а засылают раза в два меньше), щас это уже исправлено, но в публичных релизах еще нет.

[SWAT]

Чтобы не было артефактов, нужно очищать кэш (flush cahe) перед отправкой по DMA, на дриме это в порядке вещей. Я это конечно же делаю, поэтому и проблем не наблюдал.
У Store Queue есть один минус, они жрут ресурсы процессора, в отличие от DMA, но действительно работают немного быстрее. Не знаю, как лучше, ведь процессору еще нужно декодировать и видео и аудио, а тут еще на тебе и данные слать.
У WinCE игр по моему вообще нет ничего асинхронного, в отличии от KATANA. У KATANA используются по максимуму все DMA и прерывания, там все на них и держится. А у WinCE, в связи с ее особенностями, повсеместно используются PIO режимы, в том числе у GD-ROM на сколько я знаю. Вполне вероятно что и звук там тоже улетает не по DMA, хотя это я не знаю наверняка. В общем WinCE была удобна для портирования, но железо она использовала коряво, как и все Windows полагаю

[MetalliC]

(29.09.2013 11:02)SWAT писал(а):  У Store Queue есть один минус, они жрут ресурсы процессора, в отличие от DMA, но действительно работают немного быстрее. Не знаю, как лучше, ведь процессору еще нужно декодировать и видео и аудио, а тут еще на тебе и данные слать.

если верить доке то не жрут
когда пишем данные в SQ-область а не в память запись проходит мимо всяких кешей/шин и очень быстро, ведь это просто два 32байт буферка внутри чипа.
по PREF делается один burst (32 байт трансфер), проц не ждет его завершения и после этой команды выполняет дальше код, тормознется он только если попытаемся писать в тот же SQ-буфер еще до окончания трансфера.


на счет WinCE - хз что лучше а что хуже, они с катаной просто разные
но немало фишек дрима использует только винце, на вскидку вспоминается SortDMA и MapleDMA в режиме авто-старта по VBlank.
ну и MMU SH4 понятно, который из катановских игр используют емнип штук пять игр.

[SWAT]

Ну не так конечно как обычный mov, но все же жрет, ибо каждые 32 байта отсылать это накладней для проца чем DMA, где пакет явно больше. Хотя конечно спорить не буду, лучше попробовать и убедиться в этом самостоятельно. Кстати забыл еще упомянуть нагрузку на проц в виде soft-SPI если видео будет с SD карты.
А может SQ использовать для деления на макроблоки? Они ведь могут и в оперативку писать.

То что WinCE использует SortDMA, это не значит что этого нет в KATANA, каждый волен использовать что хочет, возможно в WinCE это было просто сделано в самом SDK скрытно от разработчиков, поэтому и использовалось повсеместно.
А вот MMU для игр (по крайне мере тех времён) вещь ИМХО бесполезная и использовалась в WinCE только потому, что это как никак ОС, со всеми вытекающими.
Кстати не понял про автостарт MapleDMA, что ты имел ввиду? Определение хотсвапа maple девайсов? Это же везде есть...

[uncle]

Код:

#include <kos.h>


static vuint32 * const tareg = (vuint32 *)0xa05f8000;


// YUVCONV registers
#define TA_YUV_TEX_BASE 0x148/4
#define TA_YUV_TEX_CTRL 0x14c/4
#define TA_YUV_TEX_CNT  0x150/4


static void block8x8_sq_copy(uint32 *s, uint32 * &d, int stride_4) {

    d[0] = s[0];
    d[1] = s[1];
    s += stride_4;

    d[2] = s[0];
    d[3] = s[1];
    s += stride_4;

    d[4] = s[0];
    d[5] = s[1];
    s += stride_4;

    d[6] = s[0];
    d[7] = s[1];
    s += stride_4;

    __asm__("pref @%0" : : "r"(d));
    d += 8;

    d[0] = s[0];
    d[1] = s[1];
    s += stride_4;

    d[2] = s[0];
    d[3] = s[1];
    s += stride_4;

    d[4] = s[0];
    d[5] = s[1];
    s += stride_4;

    d[6] = s[0];
    d[7] = s[1];

    __asm__("pref @%0" : : "r"(d));
    d += 8;
}



extern "C" void mbcopy(uint8 *y, uint8 *u, uint8 *v, pvr_ptr_t dest, int w, int h) {

    tareg[TA_YUV_TEX_BASE] = (unsigned long)dest;
    tareg[TA_YUV_TEX_CTRL] = ((w / 16 - 1) << 8) | (h / 16 - 1);

    int val = tareg[TA_YUV_TEX_CTRL];

    dest = (pvr_ptr_t)0x10800000;

    /* Set store queue memory area as desired */
    QACR0 = ((((unsigned int)dest) >> 26) << 2) & 0x1c;
    QACR1 = ((((unsigned int)dest) >> 26) << 2) & 0x1c;

    int stride_y_4 = w / 4;
    int stride_uv_4 = w / 8;

    uint32 *dst = (uint32 *)(void *)
                      (0xe0000000 | (((unsigned long)dest) & 0x03ffffe0));

    for(int y = 0; y < h / 16; y++) {
        for(int x = 0; x < w / 2; x += 8) {
            block8x8_sq_copy((uint32 *)(u + x), dst, stride_uv_4);
            block8x8_sq_copy((uint32 *)(v + x), dst, stride_uv_4);
            block8x8_sq_copy ((uint32 *)(y + x * 2), dst, stride_y_4);
            block8x8_sq_copy ((uint32 *)(y + x * 2 + 8), dst, stride_y_4);
            block8x8_sq_copy ((uint32 *)(y + x * 2 + w * 8), dst, stride_y_4);
            block8x8_sq_copy ((uint32 *)(y + x * 2 + 8 + w * 8), dst, stride_y_4);
        }
        y += w * 16;
        u += w * 4;
        v += w * 4;
    }
}

Сделал пересылку напрямую в YUV конвертер по SQ. В распоряжении был только lxdream и результата нет, но если ему верить в плане скорости - работает очень быстро. На железке проверить пока не могу. Вообще есть сомнения что таким методом вообще можно. Если есть интерес и возможность проверьте. Могу скомпилить реальный тест.
Насчет сброса кэша данных: Как-то странно он реализован в KOS. Затратная операция получается.

[SWAT]

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

И вообще uncle у тебя случайно нет желания повозиться с некоторыми модулями DS? А то у меня из за количества, начинает страдать качество а если начинаю подтягивать качество, то сроки растягиваются до бесконечности.
Для начала я бы с радостью дал тебе модуль ffmpeg, там есть над чем поработать.

[uncle]

(03.10.2013 13:28)SWAT писал(а):  Скоро я доберусь до модуля ffmpeg и попробую все варианты в реальных условиях.
Но пока этого не случилось, было бы не плохо написать тесты с замером скорости работы всех вариантов. Здесь важна не только скорость отправки данных в видео память, но так же важно как можно меньше нагружать процессор, ибо основная и самая приоритетная его задача - это декодирование потоков.

Распаковал свою консоль, заказал SD адаптер. Скоро тоже смогу экспериментировать.

(03.10.2013 13:28)SWAT писал(а):  И вообще uncle у тебя случайно нет желания повозиться с некоторыми модулями DS? А то у меня из за количества, начинает страдать качество а если начинаю подтягивать качество, то сроки растягиваются до бесконечности.
Для начала я бы с радостью дал тебе модуль ffmpeg, там есть над чем поработать.

Давай попробую. Я в свое время баловался с видиопроигрыванием - неплохо ускорил декодер dcdivx-а. Говори что надо делать.

[SWAT]

Замечательно! Я постараюсь подготовить для тебя все необходимое в ближайшее время. А пока тебе нужно решить вопрос с удобным запуском - SD/Serial/BBA.

[SWAT]

uncle, я тебе в личку отписал.