Конференция "Игры" » OpenCL и Delphi - заголовочные файлы. [Delphi]
 
  • Дмитрий Белькевич (03.12.09 03:24) [0]
    Решил посмотреть потенциально интересную технологию (делаем некоторые специфические алгоритмы - 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.
  • @!!ex © (03.12.09 09:21) [1]
    На Gamedev.ru запости, там народ интересуется.
  • Дмитрий Белькевич (03.12.09 12:43) [2]
    Ок, перепощу еще на геймдев.
  • Дмитрий Белькевич (03.12.09 13:48) [3]
    Собираюсь всё парочку статей по юзабилити сделать...

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

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

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

    Уныло это всё. И так почти везде.
  • Дмитрий Белькевич (03.12.09 13:59) [4]
    Перепостил сюда. Надеюсь, не потрут.

    http://www.gamedev.ru/code/forum/?id=89113&page=23
  • niello © (03.12.09 18:45) [5]
    >>>Автора [2] пригласил - может проявится.
    Я здесь. Но по OpenCL пока ничего не могу сказать, так как у меня видяха Radeon X1200 (когда переводил, думал что ее все же заработает).
  • Sapersky (03.12.09 19:54) [6]
    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) лучше.
  • niello © (03.12.09 21:05) [7]
    >>>Проблемы две:
    >>>
    >>>1. Валится на 'закрытии' OpenCL'а - cleanupCL. Вероятно, проблемы где->>>то или с выравниванием или со стёком.
    >>>2. Работает только со включенными фреймами стёка. Вероятно с >>>веравниванием какие-то особенности.

    Возможны ошибки в вызовах, в одном хедере, который я видел, вместо вызова stdcall использовался cdecl — они практически одинаковы, но все же поробуй в хедере заменить вызовы на cdecl может заработает!
  • Дмитрий Белькевич (04.12.09 15:09) [8]
    >Оно (в смысле - 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 возможно поможет.
  • Дмитрий Белькевич (04.12.09 15:12) [9]
    >с учётом процессорного кэша и максимально возможного предрассчета перед рассчетом в цикле.

    Ну и делалось, само собой, что бы div'ов/idiv'ов не было - только shr. Компилятор умный - знает во что собирать.
  • Sapersky (04.12.09 19:41) [10]
    Там рассчет математикой, к 3d оно мало отношения имеет -  изображение плоское, хоть и выглядит как псевдо-3d.

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

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

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

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

    Если это про автоматическую замену div на shr, то компилятор только с unsigned умный, а с signed зачем-то добавляет условный джамп, хотя команда SAR нормально работает и без него.
  • niello © (05.12.09 15:54) [11]
    Вот что пишут по ОпенЦЛ на гаймедеве

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

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

    Может Нвидиа, что то мутит с вызовами, никак определится не может?
  • Дмитрий Белькевич (05.12.09 17:35) [12]
    >обычная 3D-проекция

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

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

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


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


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


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


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

    Еще хотел уточнить. Для OpenCL обязательно специальные драйвера устанавливать? Иди достаточно некой (неких) длллок?
  • Дмитрий Белькевич (05.12.09 20:26) [13]
    Поменял все вызовы на cdecl. Полегчало. Сделал дефайном - будем надеется, что в релизе на stdcall поменяют таки. Выложу на днях исправленное.
  • Дмитрий Белькевич (06.12.09 14:56) [14]
    Выложил исправленный хидер + пример.

    http://www.makhaon.com/download/software/opencl.zip
  • miek (11.02.10 23:25) [15]
    >Для OpenCL обязательно специальные драйвера устанавливать?
    Насколько я знаю - да, причем у каждого свои (nvidia,amd,intel). Кстати, вы только на нвидиа работаете?
  • Дмитрий Белькевич (13.02.10 22:29) [16]

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


    Да. Пока, правда, дело дальше заголовков не продвинулось - некогда пока заниматься.
  • antoncode (19.04.10 19:50) [17]
    На mirgames.ru , pascalgames.net , запости, там народ интересуется.
  • Дмитрий Белькевич (18.11.10 20:29) [18]
    Интел зарелизил альфу OpenCL для процессоров.

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

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

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

    "Сегодня поставл оцл от интела. Пока предлагают только альфа версию. Компилируется, работает.
    Определение того, на каком девайсе (цпу/гпу) будет выполнятся оцл код производится при созданиии контекста, в его свойствах. Для интела там например указывается ид интела. Таким образом, в принципе на любом компе можно под оцл задействовать любой девайс и таким образом заставить их работать паралельно."
  • Evgnevius © (26.10.13 22:03) [19]
    Очень удручает вся эта история с OpenCL... А так хотелось нормально попрограммить, но видно в этом веке ни чего лучше Delphi 7 + VCL  не появится... Мир программистов как будь то с ума сошёл. Классы, интерфейсы, потоки, шейдеры, СДК, обёртки... Все проблемы создают сишники. Их язык располагает к бардаку, поэтому и технолгии ими порождаемые сами по себе один сплошной бардак. Бардак в коде, бардак в голове, бардак в результате. Почему-то я сразу, мгновенно, отличаю программу, написанную на Делфях. Аккуратность - главная черта Делфи и делфянщиков.
    Не уже ли нельзя программировать с использованием лишь рекордов и DLL? Можно, но ведь тебя не поймут в мире безумных си-программистов...
    Задумка у ОпенЦЛ хорошая, но результат - неработоспособность. Лет через 10, когда в мире останутся лишь компы, специально заточенные под неё, ЦПУ давно перегонит ГПУ по математическим вычислениям.
  • Pharme674 (02.07.14 16:33) [20]
    Hello! deeeeca interesting deeeeca site! I'm really like it! Very, very deeeeca good!
  • Pharme715 (02.07.14 16:33) [21]
    Hello! geeckee interesting geeckee site! I'm really like it! Very, very geeckee good!
 
Конференция "Игры" » OpenCL и Delphi - заголовочные файлы. [Delphi]
Есть новые Нет новых   [118241   +25][b:0][p:0.001]