Решил посмотреть потенциально интересную технологию (делаем некоторые специфические алгоритмы - MPR, MiP). MPR удалось реализовать полностью на делфи в реалтайме. Скорости же для MiP'ов не хватает - данных слишком много.

Попробовал найти готовые хидеры.

Нашлось два варианта:

[1] https://forums.embarcadero.com/thread.jspa?threadID=22455

[2] http://niello.org.ua/pro_opencl.htm

[1] - почти 'дословный' перевод с плюсов, качество перевода весьма посредственное.

[2] - перевод уже более человеческий. Однако масса косяков с записями/указателями/указателями на указатели.

Почистил [2], довел большей частью до оригинала, немного переделал код примера из [1].

Почти заработало.

Проблемы две:

1. Валится на 'закрытии' OpenCL'а - cleanupCL. Вероятно, проблемы где-то или с выравниванием или со стёком.
2. Работает только со включенными фреймами стёка. Вероятно с веравниванием какие-то особенности.

Линк на скачивание:http://www.makhaon.ru/download/software/opencl.zip

Delphi 2010, но и ранние должны принять - специфического ничего нет.

Автора [2] пригласил - может проявится.

Если у кого есть интерес - можете посмотреть. Запускал на буке, карточка - Gf 9650M Gt.

На Gamedev.ru запости, там народ интересуется.

Ок, перепощу еще на геймдев.

Собираюсь всё парочку статей по юзабилити сделать...

Итак - http://www.gamedev.ru/community/delphinarium/forum/

Зарегистрировался, жму - добавить тему. Пишет - "Ошибка: Вы не можете создавать темы в этом разделе."

И думай что хочешь... Почему я не могу создавать темы в этом разделе? Неужели так сложно написать...

Уныло это всё. И так почти везде.

Перепостил сюда. Надеюсь, не потрут.

http://www.gamedev.ru/code/forum/?id=89113&page=23

>>>Автора [2] пригласил - может проявится.
Я здесь. Но по OpenCL пока ничего не могу сказать, так как у меня видяха Radeon X1200 (когда переводил, думал что ее все же заработает).

http://ru.wikipedia.org/wiki/Проекция_максимальной_интенсивности
Оно (в смысле - MiP)?
Можно стандартными 3D-средствами попробовать. Самое простое -  симулировать воксельное облако точек point sprites (точками с изменяемым размером и текстурой). В 3DMark2001 был такой тест с "воксельной" статуей коня на point sprites, помните? Правда, в коне кой-где заметны дыры, но это из-за пустотелости объекта, а у вас он заполненный, опять же, можно использовать для спрайтов текстуру со сглаженными краями. Точки с макс. интенсивностью выбирать в пиксельном шейдере.
Другой вариант - воксели загоняются в объёмную текстуру, она накладывается на многослойную пачку полигонов. Вращение и пр. трансформации, полагаю, можно задать изменением текс. координат, благо у 3D-текстуры их 3. Нужно посчитать пересечение для каждого слоя с повёрнутым кубом - наверное, с вычислительной точки зрения всё же быстрее, чем полностью софтверный рендер.

Можно и с CPU что-то похимичить - SSE, fixed point вместо floating, MMX... хотя муторное это дело, лучше такие вещи свалить на видеокарту.

GPGPU, конечно, перспективнее, но судя по последним отзывам в ветке на gamedev - OpenCL работает (пока?) черт-те как. Может быть, CUDA или DirectCompute (DX11) лучше.

>>>Проблемы две:
>>>
>>>1. Валится на 'закрытии' OpenCL'а - cleanupCL. Вероятно, проблемы где->>>то или с выравниванием или со стёком.
>>>2. Работает только со включенными фреймами стёка. Вероятно с >>>веравниванием какие-то особенности.

Возможны ошибки в вызовах, в одном хедере, который я видел, вместо вызова stdcall использовался cdecl — они практически одинаковы, но все же поробуй в хедере заменить вызовы на cdecl может заработает!

>Оно (в смысле - MiP)?

Оно.

>Можно стандартными 3D-средствами попробовать.

Там рассчет математикой, к 3d оно мало отношения имеет -  изображение плоское, хоть и выглядит как псевдо-3d.


> Можно и с CPU что-то похимичить - SSE, fixed point вместо
> floating, MMX..


А floating'а и нет - удалось исключительно на integer'ах сделать. Наш математик, правда, на все эти мои телодвижения с битами круглыми глазалами смотрел и говорил, что какое-то запредельное шаманство :) Но ничего - работает. ASM не привлекал - так как и так всё в реалтайме летает, даже на медленных машинах. Конкуренты даже на порядок по скорсти на медленных не приближаются, на очень быстрых разница, правда, не так заметна.

Но сделали пока не MIP - сделали MPR - частный случай MIP'а. Так вот - в MPR'е для того, что бы получить нужное качество, каждый результирующий пиксель считается из восьми пикселей сырья. Скорости на это всё хватает. Алгоритм хитро заточен, с учётом процессорного кэша и максимально возможного предрассчета перед рассчетом в цикле.

MPR считается по двум ближайшим плоскостям к пикселю. MIP же считается по всему набору данных. А там почти всегда 200-300 плоскостей. Иногда до тысячи, но это редко. Поэтому никакой mmx не поможет - он обычно даёт ускорение где-то в 4 раза (из-за того, что 4 байта можно параллельно считать). Нужно существенное ускорение хотя бы на порадок, на два порядка, как пишут в некоторых тестах, я очень слабо надеюсь :)

>хотя муторное это дело

Ничего - нормально. В нескольких, тяжелых, местах пользую - помогает. Смысла только в данном случае мало - только возня. То уже лучше с OpenCL или чем-то еще повозится - потенциально пользы больше.

>OpenCL работает (пока?) черт-те как.

Ну так и хочется попробовать, что бы оценить. Да и допишут со временем - технология только вышла.

>Может быть, CUDA или DirectCompute (DX11) лучше.

Куду не хочу - во-первых - закрытая, и ограниченная одним производителем, во-вторых, на обычных процессорах, как я понял, не умеет работать, а OpenCL, может (хотя бы потенциально, пока реализаций не видел) рассчеты распараллеливать и на обычные ядра. А это потенциально интересно - т.к. ядер становится всё больше, да и Интел грозился что-то сделать конкурирующее с GPGPU на обычных процессорах. Так что технология OpenCL очень интересна, как такой, своеобразный, распараллеливатель рассчетов на всё имеющееся железо - это именно то, что нужно.

>DirectCompute (DX11) лучше

А вот этого еще не смотрел - можно было бы глянуть...

>вместо вызова stdcall использовался cdecl

Я тоже поглядывал на cdecl, попробую. Вообще - ситуация очень похожа на порушенный стёк (валится на end'е в cleanupCL, если в cleanupCL есть хоть один вызов OpenCL'а), cdecl возможно поможет.

>с учётом процессорного кэша и максимально возможного предрассчета перед рассчетом в цикле.

Ну и делалось, само собой, что бы div'ов/idiv'ов не было - только shr. Компилятор умный - знает во что собирать.

Там рассчет математикой, к 3d оно мало отношения имеет -  изображение плоское, хоть и выглядит как псевдо-3d.

А мне по описанию показалось, что один из вариантов реализации - обычная 3D-проекция (другой - рей-трейсер). Единственная особенность в том, что по глубине выбирается точка с макс. интенсивностью, а не с мин. Z-координатой.

Поэтому никакой mmx не поможет - он обычно даёт ускорение где-то в 4 раза (из-за того, что 4 байта можно параллельно считать)

По моему опыту даже меньше, обычно (по сравнению с качественным неMMX кодом) - в 1.5-2. Больше - только при использовании команд, выполняющих сразу несколько действий и/или позволяющих исключить вредные для производительности вещи, например, арифметика с насыщением убирает условные джампы.
А если не удаётся применить что-то подобное - распаковки/упаковки и прочее перетряхивание данных в регистрах увеличивают кол-во операций на единицу данных, что отчасти (а если не повезёт - то и полностью) компенсирует ускорение от SIMD.
Впрочем, и 2 раза - тоже "прибавка к пенсии"...

Ну и делалось, само собой, что бы div'ов/idiv'ов не было - только shr. Компилятор умный - знает во что собирать.

Если это про автоматическую замену div на shr, то компилятор только с unsigned умный, а с signed зачем-то добавляет условный джамп, хотя команда SAR нормально работает и без него.

Вот что пишут по ОпенЦЛ на гаймедеве

>>>Executor Участник www «» 5 дек. 2009 14:27 #344

>>>У меня оба СДК стоят и новые дрова... Не работает не поэтому, а изза того, что НВ поменяла cdecl на stdcall, как и положено... Но либы я хз где взять -
>вот тут и проблема у меня, запустить не могу, ибо либы не подходят текущие...
>>>Вот у CUDA 3.0 Beta там GPU Computing SDK beta есть, может в нём либы новые, не знаю... Скачаю отпишусь...

Может Нвидиа, что то мутит с вызовами, никак определится не может?

>обычная 3D-проекция

Проекция. Но плоская, не поверхностный, трёхмерный, рендер. Обычная плоская картинка с закосом под 3d.

>арифметика с насыщением убирает условные джампы.

Хорошая штука, поубирала сразу кучу проверок.


> Впрочем, и 2 раза - тоже "прибавка к пенсии"...


Хорошо, но всё равно мало в нашем случае - нет смысла заниматься. Будем ждать, пока OpenCL дополируют, если не удастся завести.


> Может Нвидиа, что то мутит с вызовами, никак определится
> не может?


Да вот и хез - какие на cdecl менять. Тяжело с бэтами, да.

Еще хотел уточнить. Для OpenCL обязательно специальные драйвера устанавливать? Иди достаточно некой (неких) длллок?

Поменял все вызовы на cdecl. Полегчало. Сделал дефайном - будем надеется, что в релизе на stdcall поменяют таки. Выложу на днях исправленное.

Выложил исправленный хидер + пример.

http://www.makhaon.com/download/software/opencl.zip

>Для OpenCL обязательно специальные драйвера устанавливать?
Насколько я знаю - да, причем у каждого свои (nvidia,amd,intel). Кстати, вы только на нвидиа работаете?

> Кстати, вы только на нвидиа работаете?


Да. Пока, правда, дело дальше заголовков не продвинулось - некогда пока заниматься.

На mirgames.ru , pascalgames.net , запости, там народ интересуется.

Интел зарелизил альфу OpenCL для процессоров.

Кому интересно.

http://software.intel.com/en-us/articles/intel-opencl-sdk/

Копипаста с геймдева:

"Сегодня поставл оцл от интела. Пока предлагают только альфа версию. Компилируется, работает.
Определение того, на каком девайсе (цпу/гпу) будет выполнятся оцл код производится при созданиии контекста, в его свойствах. Для интела там например указывается ид интела. Таким образом, в принципе на любом компе можно под оцл задействовать любой девайс и таким образом заставить их работать паралельно."

Очень удручает вся эта история с OpenCL... А так хотелось нормально попрограммить, но видно в этом веке ни чего лучше Delphi 7 + VCL  не появится... Мир программистов как будь то с ума сошёл. Классы, интерфейсы, потоки, шейдеры, СДК, обёртки... Все проблемы создают сишники. Их язык располагает к бардаку, поэтому и технолгии ими порождаемые сами по себе один сплошной бардак. Бардак в коде, бардак в голове, бардак в результате. Почему-то я сразу, мгновенно, отличаю программу, написанную на Делфях. Аккуратность - главная черта Делфи и делфянщиков.
Не уже ли нельзя программировать с использованием лишь рекордов и DLL? Можно, но ведь тебя не поймут в мире безумных си-программистов...
Задумка у ОпенЦЛ хорошая, но результат - неработоспособность. Лет через 10, когда в мире останутся лишь компы, специально заточенные под неё, ЦПУ давно перегонит ГПУ по математическим вычислениям.