SIMD оптимизации (19 стр)

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
> нашёл вот такую табличку

Сейчас модно делать выводы из рандомных картинок анонимусов при неизвестных условиях из гуглокартинок.