Решил посмотреть потенциально интересную технологию (делаем некоторые специфические алгоритмы - 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, когда в мире останутся лишь компы, специально заточенные под неё, ЦПУ давно перегонит ГПУ по математическим вычислениям.

Hello! deeeeca interesting deeeeca site! I'm really like it! Very, very deeeeca good!

Hello! geeckee interesting geeckee site! I'm really like it! Very, very geeckee good!