Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
f0x

Зарегистрирован: 23.09.2007 Сообщения: 498
|
Добавлено: Вт Ноя 08, 2016 13:09 Заголовок сообщения: замена d3dxmatrix |
|
|
есть у кого варианты, чем заменить это семейство функций? а то уж сильно медленное оно. _________________ кто сделал демку тот и выиграл (с) uncle night (?) |
|
Вернуться к началу |
|
 |
Mikle

Зарегистрирован: 02.12.2008 Сообщения: 432 Откуда: Туапсе
|
Добавлено: Вт Ноя 08, 2016 20:11 Заголовок сообщения: |
|
|
Никогда не замечал тормозов. А какие ф-ции конкретно в таких количествах применятся, что тормозят? |
|
Вернуться к началу |
|
 |
f0x

Зарегистрирован: 23.09.2007 Сообщения: 498
|
Добавлено: Вт Ноя 08, 2016 22:38 Заголовок сообщения: |
|
|
Ну пока пару раз на кадр все норм. А если в цикле на десятки тысяч итераций - то все очень плохо. Причем проблема именно в этих функциях, едят процессорное время как мыши крупу. Я профилировал тщательно, изолированный кусок кода.
юзается D3DXMatrixMultiply в основном, и помелочи такие штуки как D3DXMatrixRotationYawPitchRoll, D3DXMatrixDecompose
upd: прогуглил еще раз основательно, везде пишут что d3dx множит матрицы весьма и весьма эффективно. Какого черта у меня боттелнек именно на них, фиг знает. Видимо придется менять подход к задаче и выписывать другой алгоритм _________________ кто сделал демку тот и выиграл (с) uncle night (?) |
|
Вернуться к началу |
|
 |
Mikle

Зарегистрирован: 02.12.2008 Сообщения: 432 Откуда: Туапсе
|
Добавлено: Вт Ноя 08, 2016 23:24 Заголовок сообщения: |
|
|
Цитата: | юзается D3DXMatrixMultiply в основном |
Это простая ф-ция, её можно самому перекомпилировать с использованием SSE2, да ещё убрать лишнее копирование, нужное, когда результирующая матрица совпадает с одним из множителей. |
|
Вернуться к началу |
|
 |
BiTL DOS lover

Зарегистрирован: 22.09.2007 Сообщения: 2950
|
|
Вернуться к началу |
|
 |
f0x

Зарегистрирован: 23.09.2007 Сообщения: 498
|
Добавлено: Вт Ноя 08, 2016 23:44 Заголовок сообщения: |
|
|
ага, прочитал эту ветку тоже. буду разбираться дальше, почему все так. _________________ кто сделал демку тот и выиграл (с) uncle night (?) |
|
Вернуться к началу |
|
 |
f0x

Зарегистрирован: 23.09.2007 Сообщения: 498
|
Добавлено: Ср Ноя 09, 2016 12:04 Заголовок сообщения: |
|
|
Вобщем, проблема более-менее решилась: вместо translation и decompose (вот это реально медленная хрень) - прямой доступ к _41 _42 _43, легкая усушка-утряска кода и тыды. разогналось в два раза. _________________ кто сделал демку тот и выиграл (с) uncle night (?) |
|
Вернуться к началу |
|
 |
Ized shader killer

Зарегистрирован: 28.12.2007 Сообщения: 128
|
Добавлено: Вт Ноя 15, 2016 12:23 Заголовок сообщения: |
|
|
Если ты используешь decompose, то уже что-то не так, как по мне. Можешь вместо матриц попробовать кватернионы + вектор переноса хранить. Я просто подкидываю идей. Пока я не вижу кода, я не могу сказать, поможет ли точно это в твоем случае. |
|
Вернуться к началу |
|
 |
f0x

Зарегистрирован: 23.09.2007 Сообщения: 498
|
Добавлено: Вт Ноя 15, 2016 13:06 Заголовок сообщения: |
|
|
Ну ты все верно говоришь. У меня на самом деле вся проблема вертится на балансе между гибкостью и скоростью - так-то можно предрассчитать все матрицы и просто домножать на mVP... естетственно потеряв возможность "крутить ручки" прямо на выводе... вобщем масса вариантов. _________________ кто сделал демку тот и выиграл (с) uncle night (?) |
|
Вернуться к началу |
|
 |
|