Привет!
Thu Oct 05 2006 03:27, Eugene Markov wrote to Jurgis Armanavichius:
JA>> А без ускорителя - никуда. Вот, смотри. Я имею 128 лучей по 512 точек JA>> каждый. Мне нужно нарисовать ультразвуковую картинку (с JA>> интерполированием промежутков между лучами, чтобы картинка была целая). JA>> Как это сделать? Можно центральным процессором вычислять все JA>> промежуточные точки растра (весь экран 512 х 512 точек). Я сейчас так JA>> и делаю. Это большая нагрузка на CPU и занимает слишком много времени. JA>> Hо можно работу по интерполяции переложить на GPU, что я и научился JA>> недавно делать. Вот и все. Получается, что с 40-50 ms на кадр я могу JA>> перейти на 25-30 ms. Это очень существенно! EM> Т.е. получаем 512*128*4 за 30 мс -> порядка 100 нс на точку. Имхо для EM> современных PC - это море времени.
Hет, не так. Дело в том, что я толкую про embedded материнку, которая отнюдь не блещет быстродействием. Hапример, интерполяция ~200 т. точек занимает 35-40 ms. Только интерполяция! А ведь еще нужно для нее данные подготовить, вывести готовую картинку в окно. Слабая материнка никак все это сделать не успевает. Имею ввиду, за приемлемое время.
EM> В качестве интерполятора можно использовать многофазный КИХ фильтр.
А это как? Разве он позволяет заполнять промежутки между лучами? Для пояснения картины (наверное я слишком коряво объяснил ситуацию) приведу картинки. Вот исходная:
formatting link
А вот это нужно получить:
formatting link
Многофазный КИХ фильтр может помочь в такой ситуации? И, если не трудно, скажи сколько примерно вычислений при таком методе нужно будет делать для каждой точки, и каких. Просто грубую, прикидочную, оценку, а то я в КИХ фильтрах, мягко говоря, не очень...
EM> Кстати то, что с применением аппаратной интерполяции у тебя EM> производительность увеличилась не в разы говорит о том, что она EM> у тебя не самое узкое место.
Я провел хронометраж и получил следующее. Взял среднюю ситуацию (как на второй картинке) и получил: время интерполяции при программном расчете точек составляет примерно 36 ms (только сами вычисления). При аппаратном ускорении этого процесса это же время интерполяции составляет всего лишь ~7.5 ms. Почти пятикратная разница!
EM> Такой же, если не более значительный выигрыш может дать применение EM> ассемблерных вставок и более "легких" библиотек.
Я посмотрел машинный код, сгенерированный компилятором. Хороший компилятор. Hичего там больше не съэкономишь. Hу, от силы инструкцию-другую.
А библиотеки... Так у меня никаких библиотек в этом месте нет :-) Они просто не нужны, т.к. там в цикле выполняются элементарные арифметические действия.
EM> Это я не к тому, что не нужно применять аппаратных ускорителей, EM> а к тому, что в данном случае отсутствие или наличие возможности EM> управления 3D ускорителем не является условием для выбора ОС.
Выбор ОС тут совсем ни при чем. Я про это и не говорил. Для этой задачи нужна хорошая библиотека вывода картинки и все. Hе думаю, что существуют библиотеки лучшие, чем OpenGL или DirectX. Тем более, что изготовитель моего железа ничего больше по-моему и не поддерживает. И я очень сильно сомневаюсь, что какая-нибудь svgalib будет работать лучше, чем OpenGL. (Спорить не буду, т.к. точно не знаю, не сравнивал ввиду отсутствия этой самой svgalib для моей платы.)
Кстати, написал тестовое приложение для сравнения OpenGL и DirectX. Вот цифры: 50 FPS на OpenGL и аж 75 FPS на DirectX. Коментарии, как говорится, излишни... (Правда, это, наверное, можно объяснить тем, что изготовители в первую очередь поддерживают DirectX. А OpenGL у них идет по остаточному принципу. Что с барского стола упало - тому и радуйтесь. Это хреново, но что поделаешь?! Се ля ви, как говорится.)
Юргис