Тёмная тема
FROL
> Кто-нибудь пробовал ISPC (https://ispc.github.io/) ?
Выглядит интересно, но насколько я понял, это только x86. Я бы хотел ещё и ARM поддерживать, поэтому я лучше буду использовать свою кроссплатформенную обёртку над интринсиками.
FROL
> Кто-нибудь пробовал ISPC (https://ispc.github.io/) ?
Как я понимаю попытка сваять язык, более адекватно отражающий современную архитектуру CPU.
Насколько помню комитет по стандартизации рассматривал возможность добавления SIMD-типов в С++.
Но вообще это сильно смахивает на OpenCL, тот тоже может работать на CPU.
v1c
> Но вообще это сильно смахивает на OpenCL, тот тоже может работать на CPU.
а есть сравнения производительности opencl (CPU) vs AVX ?
нашёл вот такую табличку ,
отсюда, OpenCL on the CPU: AVX and SSE
https://streamhpc.com/blog/2010-12-08/opencl-on-the-cpu-avx-and-sse/
opencl c explicit (CPU) - это что ?
> https://ispc.github.io/
Сам не ковырял.
Это фиговина от Intel, предназначенная для написания GPU-подобного кода под CPU.
Так же как шейдер обычно пишется программистом без учёта деталей, как он выполняется над пачкой пикселей.
Для рендера выглядит плюс-минус подходящим.
В рейтрейсинге юзают: https://embree.github.io/ .
> Выглядит интересно, но насколько я понял, это только x86. Я бы хотел ещё и ARM поддерживать, поэтому я лучше буду использовать свою кроссплатформенную обёртку над интринсиками.
Оно ближе к автовекторизации, чем к ручному использованию интринсик.
И вроде же поддерживает NEON.
Люди хвалят:
https://twitter.com/tom_forsyth/status/783069365214130176
Вон человек пробовал ISPC в 2011 г.
https://blog.lexa.ru/tags/ispc
и уже тогда ICC на автовекторизации выдал сравнимый результат. Сейчас Clang/gcc подтянулись, появились векторные расширения, simd-библиотеки и т.п. Хотя может и ISPC с тех пор продвинулся, не знаю.
FordPerfect
> writing SIMD code with intrinsics is a gigantic waste of time.
Перефразирую. Пишите на Джавке и не парьтесь этими Сями/Плюсами дурацкими с ручным контролем памяти, выходом за границы массива и т.д. Это же всё так сложно.
Итак, ещё пара выходных и новый эксперимент! ))
Картинка:
Время:
Код:
https://godbolt.org/z/rUsSiC
Картинка с текстурой:
Время с текстурой:
Код с текстурой:
https://godbolt.org/z/EOvQrb
Время разных режимов растеризации:
fill color -- это просто заливка цветом.
cvex (sse/avx) это:
https://github.com/FROL256/SWGL/blob/master/gl_sc_swr/vfloat4_x64.h
https://github.com/FROL256/SWGL/blob/master/gl_sc_swr/vfloat8_x64.h
cvex (gcc) это:
https://github.com/FROL256/SWGL/blob/master/gl_sc_swr/vfloat4_gcc.h
https://github.com/FROL256/SWGL/blob/master/gl_sc_swr/vfloat8_gcc.h
Обход треугольников тут:
https://github.com/FROL256/SWGL/blob/master/gl_sc_swr/TriRasterHa… ockLineFixp.h
Код всех ROP-ов тут:
https://github.com/FROL256/SWGL/blob/master/gl_sc_swr/HW_VROP.h
Выводы:
1) Интринсики GCC это круто!
2) libsimdpp это полное говно потому что она даже не заработала на более сложном случае с текстурой и я её просто выбросил.
Падает где-то посередине. А когда это пытаешься отлаживать то вообще жесть там внутри такая муть и просто нереальный стэк вызовов
с оптимизацией выражений по методу "С++ страус-труп-оптимизаций-выражений-на-специализациях-шаблонов-выражений-С++-equal-shit"
3) С кодом вроде бы всё нормально, но 8 раз как-то совсем не получается.
Процессор хорошо умеет ООО, но плохо умеет векторы.
Надо попробовать поменять процессор на более более толстый.
4) Увеличение работы не помогло.
В Textured3D 650 инструкций по сравнению со 150 Colored3D (в 4.3 раза больше),
Примерно во столько же раз Textured3D медленнее чем Colored3D.
UPD: Хотя .... там же изображение сложнее, так что удельно наверное больше производительность с текстурой.
Жду ваших комментариев и предложений! ))
FROL
Фрол, не планируешь замутить какие нить новые DXR демки ? )
star123
Лично я пока нет, коллеги да. А вообще у меня и старых не было ...
Конкретно в этом треде я развлекаюсь с векторизованной растеризацией треугольника на SIMD )
FROL
> Лично я пока нет, коллеги да.
кинь ссылку на коллег и их проекты
FROL
> Конкретно в этом треде я развлекаюсь с векторизованной растеризацией
> треугольника на SIMD )
я как то писал растеризатор на j2me - с перспективной коррекцией (текстур) и освещением по Гуро - вот это было круто :D
такой куб еле ворочался на моей моторолке :D щаз уже не так весело - везде аппаратная поддержка 3D , большие экраны .. видно оно интересно пока только находишься на острие прогресса )
itmanager85
> не планируешь
> кинь ссылку на коллег и их проекты
Пока они только планируют ... нету ссылок )
FROL
> Жду ваших комментариев и предложений! ))
Я смотрю, векторизация либо по цветовым компонентам, либо по пикселям (основной вариант).
Может сделать смешанный подход - 2 пикселя в 8-компонентном векторе? Тем самым снижаем кол-во пограничных случаев, когда часть пикселей в треугольнике, часть снаружи, и заодно выкидываем перетасовку цветовых комнонент - все эти сдвиги и |, там что-то около 20 команд получается.
По векторным расширениям, некоторые вещи можно сделать проще и быстрее.
https://gcc.godbolt.org/z/sl-_Cd
Хотя test_bits_any - это уже скорее выпендрёж, проще интринсик воткнуть.
invis
> https://gcc.godbolt.org/z/sl-_Cd
Только что не открывался, сейчас открылся.
Я бы юзал memcpy вместо нарушения strict aliasing.
Вообще использование типизированных указателей в оригинальном коде - спорно, я бы юзал void* для load/store.
vint8u забавный, был не в курсе, что так можно.
Для test_bits_any действительно movmskps выглядит логичнее.
Вообще, да:
> По векторным расширениям, некоторые вещи можно сделать проще и быстрее.
itmanager85
> нашёл вот такую табличку
Сейчас модно делать выводы из рандомных картинок анонимусов при неизвестных условиях из гуглокартинок.
