-
> Кстати, у кого топовое железо - i5, i7, бульдозеры - напишите,
> сколько FPS со стандартным размером окна.
i5 2400 дает в максимуме 598, среднее 588 фпс.
-
>Значит, проблема с загрузкой картинок.
Да, прошёлся по коду, дело действительно оказалось в путях картинок. Когда папку Images подложил в нужное место, заработало.
-
> Кстати, у кого топовое железо - i5, i7, бульдозеры - напишите,
> сколько FPS со стандартным размером окна.
> Исправленный exe по ссылке выше.
на i7 с пониженным потреблением (3770t) около 780, изредка падая на 680-700
-
Sapersky [URL= http://imageshack.us/photo/my-images/824/50422227.png/][IMG]http://img824.imageshack.us/img824/8602/50422227.png[/IMG][/URL]Если я правильно понимаю то чёрное (по стрелкам) - некий фон, Можно ли поменять его цвет? Скрин сделал с Формы типа TForm из VCL.Forms и цвет клиентской области белый
> Про это я писал в [10] в конце.
> На процессорах с гипертредингом получается гарантированная
> рассинхронизация потоков.
Как бы у меня он есть по умолчанию, то бишь 4 физических ядра становятся 8 логическими и всё нормально (метод CPUCount возвращает 8), пробовал с ThrUsed := от 1 до 8 в всё нормально (ну соответственно пропорционально падает fps), но к сожалению не посмотрел что возвращает CPUCount на 2-х ядерном проце из сообщения 9, но уверен там было число 2
-
-
> brother, antonn
Спасибо. В общем, неплохо так для "канваса" :)
FPS, возможно, плавает из-за того, что процессор динамически меняет частоту. Или фоновые приложения мешают.
Если я правильно понимаю то чёрное (по стрелкам) - некий фон, Можно ли поменять его цвет?
Выложил обновление исходников (+ exe) - там цвет фона передаётся параметром в конструкторе TWater.
+ убрал с чёрную полосу внизу и неподвижную рамку у картинки + все фиксы для многопоточности.
https://docs.google.com/file/d/0B_vHqwd58bsUYnFsWUFqeVptRms/edit?usp=sharing
Файл Utils положить в папку библиотеки.
Как бы у меня он есть по умолчанию, то бишь 4 физических ядра становятся 8 логическими и всё нормально (метод CPUCount возвращает 8), пробовал с ThrUsed := от 1 до 8 в всё нормально (ну соответственно пропорционально падает fps), но к сожалению не посмотрел что возвращает CPUCount на 2-х ядерном проце из сообщения 9, но уверен там было число 2
То есть в режиме UseMMTimer работает на i7 с любым количеством потоков, но глючит на 2-ядернике?
Я у себя замечал глюки на Атоме с гипертредингом, поэтому решил, что дело в нём. На 2-ядернике изредка были небольшие подтормаживания одной половины воды.
-
Sapersky
> Выложил обновление исходников (+ exe) - там цвет фона передаётся
> параметром в конструкторе TWater.
> + убрал с чёрную полосу внизу и неподвижную рамку у картинки
> + все фиксы для многопоточности.
> https://docs.google.com/file/d/0B_vHqwd58bsUYnFsWUFqeVptRms/edit?
> usp=sharing
> Файл Utils положить в папку библиотеки.
Спасибо за исправления и обновления! Что вы сделали, у меня теперь 550 (с волнами) - 640 fps? :) http://imageshack.us/photo/my-images/580/59095541.png/
> То есть в режиме UseMMTimer работает на i7 с любым количеством
> потоков, но глючит на 2-ядернике? .... На 2-ядернике изредка были
> небольшие подтормаживания одной половины воды.
Это глюк с тормозом половины воды (нижней) и был. В общем напилю различных екзешников (с таймером и без и вариациями кол-ва потоков) и пойду по возможности к другану на его двухядернике тестить, потом отпишусь
-
> FPS, возможно, плавает из-за того, что процессор динамически
> меняет частоту. Или фоновые приложения мешают.
у меня там TS и 4 виртуалки подняты :)
-
Стандартные размеры окна:
Plasma - 291 fps
Fumes - 503 fps
Bump - 542 fps
Rotozoom 233 fps
TexCube - 173 fps
Water - AV
i7 990X 3.47 ГГц
-
Что вы сделали, у меня теперь 550 (с волнами) - 640 fps? :)
Да вроде почти ничего... обработку сообщений немного изменил. У меня FPS тот же, что и раньше.
Кстати, выложи полноразмерный скриншот без пережатия в jpeg (на ipicture, например), что-то мне не очень нравится картинка.
dmk © (20.04.13 13:44) [28]
fpsWater - AV
А с новой версией (по ссылке из [25])?
BumpMap, кстати, быстрее работает под x64:
https://docs.google.com/file/d/0B_vHqwd58bsUaUN3Ukh0UzZLTjA/edit?usp=sharing
причём на одной машине у меня получилось почти в 2 раза быстрее, не очень понятно почему - вроде бы 64-битных вычислений там нет. На другой машине на 25% быстрее, что более правдоподобно, можно объяснить использованием доп. регистров (точно не скажу, пример не мой, влезать в потроха и разбираться лень).
На других примерах, впрочем, ускорения нет, местами даже замедление. Особенно досталось Water в целочисленном варианте - похоже, x64 компилятор не умеет нормально работать со SmallInt, так что для x64 я включил по умолчанию floating point.
-
>А с новой версией (по ссылке из [25])?
825 fps
-
Как-то не очень впечатляет по сравнению с обычным i7 из [22], теоретически ведь должно быть в полтора раза быстрее, даже больше чем в полтора, с учётом частоты.
Возможно, упирается в вывод битмапа на экран.
Вот ещё версия:
https://docs.google.com/file/d/0B_vHqwd58bsUSjVYWWo5Tm9EaW8/edit?usp=sharing
здесь FPS - чисто расчётный, а Disp - с выводом на экран.
Кроме того, теперь в заголовке пишет размер окна и общий объём данных. Можно помериться на бОльшем размере (если Антон захочет заново тестировать). На стандартном возможно тормозит межпоточная синхронизация.
-
-
дальше 5 не тестировал. Там скорее всего было бы также как и на 5. Всё нормально с 1 потоком!
-
-
-
> Wladimir1987 © (21.04.13 02:37) [32]
Действительно был глюк, исправил.
https://docs.google.com/file/d/0B_vHqwd58bsURGE3N0pVZy1URVk/edit?usp=sharing
Сейчас режим UseMMTimer должен быть вполне рабочим, поставил его по умолчанию. Всё-таки симпатичнее, когда оно не мельтешит с бешеной скоростью.
> dmk © (21.04.13 03:00) [34]
Да, это уже около дела. Правда, у Антона расчётный FPS тоже должен быть выше...
Что касается недогрузки - есть такое, у меня одно ядро 100%, другое 85%. Отчасти из-за того, что битмап приходится выводить на экран в первом потоке (в многопоточном варианте иногда мелькает или ещё как-то глючит). Отчасти из-за выбранной схемы многопоточности - есть главный поток, есть вспомогательные. Главный, кроме выполнения своей части обработки картинки, ждёт прочие потоки, добавляет капли дождя и обрабатывает сообщения. Поэтому видимо и получается неравномерная загрузка.
Пытался компенсировать, задавая главному потоку несколько меньший размер картинки для обработки - не помогает, всё равно потоки какое-то время ждут друг друга. Видимо, для 100% нагрузки надо вообще всё переделывать. Может, как-нибудь займусь. А пока и так неплохо, особенно если сравнить с однопоточным режимом.
-
Sapersky
> Действительно был глюк, исправил.
Спасибо, на двухядернике всё в порядке, теперь глюков нет, ну и у меня тоже! :)
> Всё-таки симпатичнее, когда оно не мельтешит с бешеной скоростью.
поддерживаю
-
> Да, это уже около дела. Правда, у Антона расчётный FPS тоже
> должен быть выше...
У меня там потоки на 80-85% загружены (и проц сам по себе медленнее "обычных" десктопных i7).
-
Я о том, что "правильный" результат dmk (1100) получен без учёта вывода картинки. А твой (700) был с учётом. Без учёта на exe-шнике из [31] у тебя тоже должно быть больше. И тогда результат dmk перестанет быть правильным (в 1.5 раза больше, по кол-ву ядер).
Понятно, что 6 ядер в любом случае круче 4-х, это моя демка плохо масштабируется на 8-12 потоках. Писалось и тестировалось в основном на двухядерниках, для которых недогрузка одного ядра не принципиальна, поэтому не обратил внимания. А сейчас перетряхивать архитектуру не хочется, да и некогда.
|
Есть новые 
Нет новых [120402 +60][b:0][p:0.001]