ПрограммированиеФорумГрафика

Ищу сверхбыстрый метод ресайза текстуры (4 стр)

Страницы: 1 2 3 4
#45
20:40, 4 мая 2010

IronPeter
а boost::pool хорош?

> Расчет координаты попытайся закешировать, сохранив массив смещений. Когда мы
> работаем по строчкам, то эти смещения постоянные.
хм, скорость тогда увеличится еще раза в два, спасибо :)

keltar
> Что там такое жуткое делается, что упёрлись в скорость аллока?
как минимум три аллока, итого ~ 30мс. зачем тогда оптимизоровать код, если закрывать глаза на такие нюансы?

#46
21:44, 4 мая 2010

Можно координаты для src считать во время копирования, а не до, если использовать fixed point возможно даже будет быстрее для такой фильтрации без усреднения, думаю, что будет, но не проверял, интересно было бы увидеть числа (время). Для больших разрешений надо проверить как там с точностью будет.

Если размеры dst кратны степеням 2, то можно бесплатно сделать разворот внутреннего цикла, на 4, 8, 16, и т.д. итераций.

Дальше остается подстраиваться под отношения разрешений src и dst, делать быстрые ресайзеры частных случаев (2x2 -> 1x1), либо "компилить" оптимальный ресайзер для каждого.

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

Ну да, и без фильтрации не интересно.

#47
1:00, 5 мая 2010

быстрей, ещё быстрей!
системный тик 10мс

#48
6:21, 5 мая 2010

Мать-мать. Аж с перепугу проверять полез, 65535 аллоков улетело за ~200мс. Если три за 30, тогда трындец и надо стековый аллокатор, пул и прочее. Не, правда, всё так плохо? Или аллок огромного блока под текстуру совмешён с его memset(0)? (что ещё может так тормозить - не предположу)

#49
10:29, 5 мая 2010

У меня когда-то была функция для ресайза такая:

// Приведение текстуры к нужному размеру
// type - количество цветовых компонент
// data - старое изображение
// data2 - новое изображение
void CopyResize (int oldX, int oldY, int newX, int newY, int type, char *data, char *data2){
    float resizeX = (float)oldX/newX, resizeY = (float)oldY/newY;
    for(int line=0; line<=newY-1; line++){
        for(int seg=0; seg<=newX-1; seg++){
            for (int i=0; i<type; i++){
                int offset1 = int(line*newX+seg)*type+i;
                int offset2 = int(line*newX*resizeX+seg*resizeY)*type+i;
                *(data2+offset1) = *(data+offset2);
} } } }

Сейчас использую функцию iluScale(); из библиотеки DewIL.

#50
13:42, 5 мая 2010

namot
> Можно координаты для src считать во время копирования, а не до,
да, я тоже про это подумал. попробую


keltar
> Мать-мать. Аж с перепугу проверять полез, 65535 аллоков улетело за ~200мс
200мс/65535 = 0,003мс на одну аллокацию? что-то не верится. покажи код полностью как тестировал. какой размер блоков? компилятор?

#51
17:31, 5 мая 2010
#define N 65535
#define BLOCKSIZE 1024*1024
  uint64_t timepad = get_time();
  void *ptrs[N];
  for(int i = 0; i != N; ++i) {
    ptrs[i] = malloc(BLOCKSIZE);
  }
  uint64_t timeresult = get_time() - timepad;
  printf("%lld\n", timeresult);

Компилял на gcc 4.3 и sun studio 12. Внутри get_time соответственно gettimeofday.
Блоки по мегабайту; на мелких пошустрее, но не в разы. Если разбавить вычислениями/логикой - конечно будет помедленее, но не в тысячу же раз.

#52
18:58, 5 мая 2010

keltar
хм, накидал такой вот тест

http://www.everfall.com/paste/id.php?krd1zo0d9quz

к своему удивлению обнаружил, что аллок блока на 1 Мбайт составляет 0,003мс, как ты и говорил. значит в моем коде где-то сильный косяк.

PS.  у тебя 65535 аллоков по 1Мбайт - это 65Гбайт. мощно :)

#53
19:29, 5 мая 2010

Особенности виртуальной памяти :-)
Я к чему говорил-то - аллок тормозит в больших количествах. Почему меня это и удивило.
А по поводу "не выделять память": конкретно в указанной ситуации - что-то мешает взять большой буфер с запасом, и в него класть любую картинку? Ну реаллочить его по мере роста, если совсем критично не_знать_максимальный_размер, скажем.

#54
19:42, 5 мая 2010

keltar
ну смотри, возьмем худший вариант, максимум 5 аллоков на полный ресайз с фильтрацией, с мипмапами и т.д.
0,003мс * 5 = 0,015мс
для моего случая это мизер. вообщем, пока аллоков мало - по данному поводу заморачиваться не буду :)

Прошло более 1 года
#55
3:08, 21 авг 2011

Нет ничего проще. Изменить размер изображения без потери качества на GPU. Если размер изображения слишком большой для GPU, то разрезать большое изображение на мелкие. Изменить размер на GPU до нужного размера для каждого. Снова склеить изображение.

#56
8:12, 21 авг 2011

Lamer007
wtf???
Помимо того, что ты не умеешь внимательно читать, ты еще не догадался посмотреть на дату.

Страницы: 1 2 3 4
ПрограммированиеФорумГрафика

Тема в архиве.

Тема закрыта.