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

Оптимизация Direct3D приложений. (комментарии)

Страницы: 1 2 Следующая »
#0
5:30, 29 ноя. 2009

Оптимизация Direct3D приложений. (комментарии)

Это сообщение сгенерировано автоматически.


#1
5:30, 29 ноя. 2009

> Загружаем модели в сцене в минимальное количество буферов.

В один?!

#2
7:04, 29 ноя. 2009

Прибой94, думаешь, спустя 7 лет это так важно? ))))

#3
7:07, 29 ноя. 2009

Думаю, да. Ведь часто когда много всякой хрени: блики, динамичекое освешение, многочисленные системы частиц...
Кстати, сколько, по вашем у, сэкономит объединение 20 буфферов в 1?

#4
7:44, 29 ноя. 2009

>>Кстати, сколько, по вашем у, сэкономит объединение 20 буфферов в 1?

  • надцать сферических единиц в вакууме :)))
  • #5
    8:51, 29 ноя. 2009

    >*надцать сферических единиц в вакууме :)))
    Да, примерно столько и сэкономит. 8-)

    Для того, что бы 1 буфер дал заметный выигрыш по сравнению с многими буферами, надо как минимум реализовать грамотный менеджмент рендера и хороший батчинг. И то на фоне всяких там теней, хдр, ссао и прочего - этот выигрыш перестанет быть заметным, ИМХО.

    #6
    15:28, 29 ноя. 2009

    про оптимизацию вычислений на CPU жжот безмерно. замена ftoi на лисопед уже добрый десяток лет ничего не даёт. приближённое вычисление корня тоже не может не радовать.

    #7
    15:34, 29 ноя. 2009

    >>замена ftoi на лисопед уже добрый десяток лет ничего не даёт
    На дату статьи глянь:)))

    #8
    15:57, 29 ноя. 2009

    А какого тогда  сообщение сгенерировалось ??    Смотрю  некоторые подозрительные  нестыковочки.  Про ассемблер ,  по моему тоже лишнее и геморное:  Львиную долю времени занимает обращение к функциям графического апи и геометрия.  И ассемблер тут не поможет. 

    #9
    16:08, 29 ноя. 2009

    Suslik
    > замена ftoi на лисопед уже добрый десяток лет ничего не даёт.
    Дает и очень прилично, разумеется если этих преобразований много, очень много :)

    #10
    17:50, 29 ноя. 2009

    doc.
    я говорю о нормальных оптимизирующих компиляторах. успехов.

    #11
    19:48, 29 ноя. 2009

    Suslik
    > я говорю о нормальных оптимизирующих компиляторах
    Не поверишь, но подобная замена может оказаться актуальной даже для них (для интереса можешь потестить). На самом деле ничего удивительного нет, ведь алгоритмы то разные и если тебе не нужна точность округления то "зачем платить больше"?


    Небольшое приложение:

    #define FtoI(f,i){    \
        __asm fld f       \
        __asm fistp i     \
    }
    
    __inline unsigned ftoi(double d)
    {
        d += 6755399441055744.0;  
        return (unsigned &)d;
    }
    
    
    #include <intrin.h>
    __inline int FloatToInt_SSE(float x)
    {
      return _mm_cvt_ss2si( _mm_load_ss(&x) );
    }

    Правка: поправил "магическое" число во втором способе.

    #12
    23:05, 29 ноя. 2009

    doc.
    Я ещё пару лет назад писал yet another софтварный рендер, в растеризаторе которого нужно было постоянно переводить координаты с плавающей точкой в дискретные экранные. Уж что я тогда только ни перепробовал, лучшее, что удавалось добиться - это не слишком сильное снижение производительности(~5%) по сравнению с тем, что делает оптимизатор. Ещё раз, я говорю о нормальном компиляторе ICL, а не о VC6 треше.

    В коде всё ещё остались добрых полдюжины магических методов "быстрого" приведения этих типов друг к другу, спокойно отдыхают в комментариях.

    #13
    23:08, 29 ноя. 2009

    И, да, если ты и получишь выигрыш своих 3% на среднем по характеристикам оптимизации компиляторе(MSVS) сегодня, то уж точно не факт, что завтра твои танцы с бубном не будут пудрить мозг поумневшему оптимизатору. Лучше заняться чем-нибудь полезным, например, оптимизировать алгоритмическую часть.

    #14
    23:25, 29 ноя. 2009

    Suslik
    > пудрить мозг поумневшему оптимизатору
    У поумневших оптимизаторов есть одно замечательное свойство - они наотрез отказываются компилировать код, написанный под глупый оптимизатор, выдавая в лучшем случае килобайты варнингов, а в худшем - ерроров. Т.е. завтра танцы с бубном будут в любом случае.
    >я говорю о нормальном компиляторе ICL
    ICL?

    Страницы: 1 2 Следующая »
    ПрограммированиеФорумГрафика

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