Помогите с тестом

← →
VirEx © (2008-01-13 17:33) [80]

> [72] KilkennyCat © (13.01.08 02:09)
> Видеоадаптер Mobile
> Intel(R) 915GM/GMS,910GML Express Chipset Family (128 Мб)
> Видеоадаптер Mobile
> Intel(R) 915GM/GMS,910GML Express Chipset Family (128 Мб)

СЛИ?))

← →
DVM © (2008-01-13 18:24) [81]

> Ketmar_ (13.01.08 16:00) [79]

> кстати, да. отчего бы не взять тот же OpenGL, на котором
> вполне себе можно делать 2d. с поворотами, альфа-каналами,
> масштабированием и причими прелестями, да ещё имея при
> этом удовольствие аппаратного ускорения.

Я не помню точно как называется, но у NVIDIA есть технология и API и SDK к ней, которая схожа чем то с SSE, но позволяет добиться еще большего ускорения некоторых операций. Так декодирование JPEG (заточенная на ее использование Jpeg Library) обгоняет входящую в IPP IJL в несколько раз (по отзывам использовавших). Но технология доступна начиная с FX 4XXX видеочипов.

← →
Ketmar_ (2008-01-13 18:29) [82]

> DVM © (13.01.08 18:24) [81]
ну, это заточка на конкретного производителя и модель. подход верен только в случае узкого ареала софтинки, имо. а OpenGL универсальна. ну, будет он грузить графику не 3 минуты, а 10. фиг с ним, грузится-то один раз. зато работает везде, где есть OpenGL (а это практически все видеокарты, и не только современные). к тому же портируемость на другую ОС упрощается (если надо, конечно %-).

имо.

← →
DVM © (2008-01-13 18:33) [83]

> Ketmar_ (13.01.08 18:29) [82]

Это конечно верно.

Есть еще Intel Perfomance Primitives Library (IPP). Ее функции очень быстры, создать более быстродействующие аналоги очень сложно. На ее основе тоже можно многое построить. Она тоже кроссплатформенная.

← →
DVM © (2008-01-13 18:34) [84]

А технология NVIDIA называется CUDA.
http://www.nvidia.com/object/cuda_get.html

← →
KilkennyCat © (2008-01-13 18:41) [85]

> VirEx © (13.01.08 17:33) [80]
>
> СЛИ?))

Ноут. Двумониторность.

← →
Ketmar_ (2008-01-13 19:12) [86]

> DVM © (13.01.08 18:34) [84]
нет пакетов под Слаку? удавить на месте. %-)

← →
Sapersky (2008-01-13 19:56) [87]

CUDA (требует GeForce 8XXX) в данном случае - не совсем в тему. Это GPGPU, т.е. вычисления общего назначения (не обязательно графики) на GPU. А у antonn"а - стандартные графические операции, их может делать, например, Riva TNT (ну разве что макс. размера текстуры может не хватить, но это решаемо).
Что касается IPP - насколько помню, в ветке про масштабирование картинки без фильтрации её результаты не были такими уж выдающимися...

← →
DVM © (2008-01-13 20:09) [88]

> Sapersky (13.01.08 19:56) [87]

> Что касается IPP - насколько помню, в ветке про масштабирование
> картинки без фильтрации её результаты не были такими уж
> выдающимися

А где такая ветка была?

Насколько я успел разобраться с IPP - ее применить можно совершенно по-разному. Она предлагает примитивы для вычислений - как ими воспользоваться решать программисту.

И компилить надо отдельно под каждый процессор в идеале интеловским компилятором.

← →
DVM © (2008-01-13 20:12) [89]

А уж не моя ли это ветка была про масштабирование? Помнится я спрашивал чего то. Но тогда я юзал даже не IPP, а ее прародителя. Оптимизации под новые процессоры не было соответственно.

← →
DVM © (2008-01-13 20:27) [90]

> Sapersky (13.01.08 19:56) [87]
> CUDA (требует GeForce 8XXX)

Ранее Quadro (и какие то Tesla - не знаю что такое) поддерживали. Но это не для домашнего пользователя конечно.

← →
Kenny (2008-01-13 22:37) [91]

Draw alpha with a: 2,8802308673309
Draw alpha: 1,64891236176665
Draw alpha MMX: 1,54101373219222
Draw transparent color: 1,17464649836781
Draw tr. color opacity MMX: 1,5966358852871
Draw rotate alpha: 5,10885266144161

---
Pentium M (1.73 Ghz, 533Mhz FSB, 2MB L2 cache)

← →
antonn © (2008-01-13 22:38) [92]

> Чтобы не зависеть от памяти - сделать размер картинки таким,
> чтобы гарантированно влезала в кэш.

размеры картинки неизвестны совсем :)

я не собираюсь делать заточки под конкретное железо, мне нужно, чтобы все "просто работало" и побыстрее. Так же мне нафиг не нужно ОГЛ/ДХ, если бы мне захотелось ими воспользоваться, я бы не парился :) Для анимации какого нибудь гуевого элемента окна ОГЛ не очень то и подходит... это так, для примера.

← →
DVM © (2008-01-13 22:43) [93]

> я не собираюсь делать заточки под конкретное железо, мне
> нужно, чтобы все "просто работало" и побыстрее

Но ты уже делаешь заточку. Выжать максимум можно лишь делая разные функции под разные процессоры.

← →
Ketmar © (2008-01-13 22:43) [94]

> antonn © (13.01.08 22:38) [92]
для анимации гуёвого элемента можно и .Pixels[] использовать. нафига там MMX?

зыж ты чего, edje собрался переписать? %-)

← →
antonn © (2008-01-13 23:06) [95]

> DVM © (13.01.08 22:43) [93]
>
>
> Но ты уже делаешь заточку.

да, но унифицированную. В принципе, насколько я понял, сделать еще круче еже не выйдет, и так почти все на асме писано и шагам. Мне просто нужно было увидеть, настолько ли хуже показываются результаты на разных машинах. Могу сваять тот же пример через canvas.pixels :)

> Ketmar © (13.01.08 22:43) [94]
>
> > antonn © (13.01.08 22:38) [92]
> для анимации гуёвого элемента можно и .Pixels[] использовать.
> нафига там MMX?

ты меня извини, но у тебя либо узкий кругозор, либо мало фантазии :) Updatelayerdwindow думает иначе :)

>
> зыж ты чего, edje собрался переписать? %-)

да ну что ты, просто хочу быстрее :) жадный я, хочу больше %)

← →
Ketmar © (2008-01-13 23:18) [96]

> antonn © (13.01.08 23:06) [95]
> Updatelayerdwindow думает иначе :)
отвык-с… у нас composite extension да Enlightenment… %-)

← →
antonn © (2008-01-13 23:21) [97]

> отвык-с… у нас composite extension да Enlightenment… %-)

дада, наслышан %))

кстати, а под ВИНЕ проги с выводом в слой работают? в смысле окно видно вообще?

← →
Ketmar © (2008-01-13 23:35) [98]

> antonn © (13.01.08 23:21) [97]
ты про оверлеи, штоле? фиг знает — это надо на плэйере каком-то проверять. вот мне не хватало мороки — только виндовый плэйер вод вайном пущать да кодеками его кормить. %-)

вообще — должно, директх ж эмулируют. но насколько прямо… в общем, «не то, чтобы совсем не попал… попал, но не в шарик.» (ц)

← →
DVM © (2008-01-13 23:37) [99]

> Могу сваять тот же пример через canvas.pixels

лучше правильно сваять на паскале через Scanline и без ASM и поглядеть разницу. Сравнивать с вариантом без MMX/SSE ессно.

← →
antonn © (2008-01-13 23:41) [100]

> Ketmar © (13.01.08 23:35) [98]
>
> > antonn © (13.01.08 23:21) [97]
> ты про оверлеи, штоле? фиг знает — это надо на плэйере каком-
> то проверять.

не обязательно плеером :) http://desksoft.ru/index.php?forum=4&th=123 (430Кб, правда она папочку пытается создать в аппликейшн_дата:))

> DVM © (13.01.08 23:37) [99]
>
> лучше правильно сваять на паскале через Scanline и без ASM
> и поглядеть разницу.

можно неправильно сваять со сканлайном, скорость тоже будет немалой. Но вот мне мало :) Пример малости по ссылке выше, на моей системе летает, а на Пне4 2,4 тормозит жутко, говорят...

← →
Ketmar © (2008-01-13 23:46) [101]

> antonn © (13.01.08 23:41) [100]
ниасилило.
fixme:win:UpdateLayeredWindow (0x10026,0x30c,0x33fc6c,0x33fc58,0xd24,0x33fc60,0x00000000,0x33fc68,2): stub!

← →
antonn © (2008-01-13 23:47) [102]

вот, это типа если кто то захочет написать прогу, работающую только под винду, можно сделать вывод окошка Эбаут в таком стиле и усе%)

← →
Ketmar © (2008-01-13 23:50) [103]

> antonn © (13.01.08 23:47) [102]
так чего? окошко-то оно рисует, оно то, что в окошке, не рисует. %-)

← →
antonn © (2008-01-13 23:50) [104]

окошко, надо полагать, обычное "контролное"? :)

← →
Ketmar © (2008-01-13 23:52) [105]

> antonn © (13.01.08 23:50) [104]
окошко пустое совсем. так загадочней.

← →
antonn © (2008-01-13 23:59) [106]

да оно и так пустое совсем :) на главной форме ни одного контрола нет

← →
Ketmar © (2008-01-13 23:59) [107]

> antonn © (13.01.08 23:59) [106]
> да оно и так пустое совсем
чую, что меня где-то обманули, но доказать не могу…
%-)

← →
antonn © (2008-01-14 00:04) [108]

там исходники есть :)
какой смысл в контролах, кроме их нажатий-отжатий, если рисовать все равно их вручную? :( ладно бы кнопки, но вот поля ввода я не победил (tedit, tmemo) :((

> [100] antonn © (13.01.08 23:41)
> Пример малости по ссылке выше, на моей системе летает, а
> на Пне4 2,4 тормозит жутко, говорят...

При запуске на 1 сек 30% загрузки, потом, если быстро-быстро по кнопкам мышью перебирать, до 20%, а в самой игре, баже если очень быстро нажимать на игровое поле, загрузка не более 5%. Проц я думаю ты уже заучил, какой у меня :)

← →
OSokin (2008-01-15 17:41) [111]

Draw alpha with a: 7,47367806225078
Draw alpha: 5,44391200093824
Draw alpha MMX: 1,96661823134716
Draw transparent color: 0,878401206206598
Draw tr. color opacity MMX: 2,21392649389789
Draw rotate alpha: 9,88579208537981

← →
OSokin (2008-01-15 17:44) [112]

Пень 4, но было открыто дофига всего жрущего память + тестировался масакр =)

Пень 4 это конечно конкретнейший характеристик процессора)))
памяти там много не нужно, мегабайт 30-40 %))

Draw alpha with a: 6,93901419518927
Draw alpha: 4,69151983359778
Draw alpha MMX: 1,44884304290724
Draw transparent color: 0,639724614661529
Draw tr. color opacity MMX: 1,53418728583048
Draw rotate alpha: 6,99481252416699
P4-3G загрузка проца была 50%

> P4-3G загрузка проца была 50%

1 ядро скорее всего на полную, одно "отдыхало" :)

← →
OSokin (2008-01-15 18:15) [116]

> Пень 4 это конечно конкретнейший характеристик процессора)))

=)
Intel(R)
Pentium(R) 4 CPU 2.80GHz
2.81 ГГц, 1.00 ГМ ОЗУ

ЗЫ Посмотри процедурку плиз =)

← →
Sapersky (2008-01-15 21:20) [117]

DVM © (13.01.08 20:12) [89]
А уж не моя ли это ветка была про масштабирование? Помнится я спрашивал чего то. Но тогда я юзал даже не IPP, а ее прародителя. Оптимизации под новые процессоры не было соответственно.

Да, ваша, конец 2006 г. Может быть, причина низких результатов в старой версии.
Но IPP это всё-таки "тяжёлая артиллерия", применимая в основном для крупных проектов (большой размер дистрибутива из-за DLL + сама библиотека платная, не сказать, что очень дорогая, но...).

2 antonn:
Протестировал на Celeron 2.8 (P4).

Draw alpha with a: 7,26294347465949
Draw alpha: 4,76215748090889
Draw alpha MMX: 1,46059094102742
Draw transparent color: 0,688419058846865
Draw tr. color opacity MMX: 1,63055360387982
Draw rotate alpha: 7,19619309158008

Мой тест:

// 1600 * 1200
// TransColor : 0,7
// Alpha : 1,5
// Alpha MMX: 1,0

Результаты TransColor на самом деле могут варьироваться от 0,3 до 1,6 в зависимости от исходных данных. Наилучший вариант - большие непрерывные области прозрачного/непрозрачного цвета (или один цвет), наихудший - хаотичное распределение цветов, "белый шум". Это связано с методом предсказания переходов ("в этот раз переходим туда же, куда и в прошлый"). На "белом шуме" неизбежно большое кол-во ошибок предсказания - а P4 с его длинным конвейером к ним весьма чувствителен.
То же относится к alpha-процедурам, если в них есть проверки частных случаев Alpha = 0, Alpha = 255 (я в своих убрал).

← →
antonn (pda:) (2008-01-15 21:26) [118]

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

← →
Sapersky (2008-01-16 00:20) [119]

Хотя нет, "белый шум" (у меня было что-то вроде i := Random(255); Color := RGBA(i, i, i, i)) - не самый худший вариант; а если делать Random(255) для каждого байта, то и вовсе неплохой (т.к. относительное кол-во прозрачных пикселей будет очень мало).
Самый худший это (теоретически):
If Random > 0.5 then Color := Transparent else Color := NonTransparent;
Хотя трудно представить, зачем могут потребоваться подобные картинки.

В общем, в TransColor с зависимостью от данных сделать ничего нельзя, разве что в совсем уж плохом случае перейти на вывод с альфой.
В Alpha-функциях проверка на 0 при alpha := Random(255) даёт замедление где-то в 1.5 раза (на P4). Надо проверить на реальных картинках, у которых полностью прозрачные области расположены более упорядоченно - в принципе не исключён и положительный эффект (на полностью прозрачной картинке он определённо есть).

Какой же это белый шум, это вполне низкочастотный.

Помогите с тестом Найти похожие ветки