CUDA vs Vulkan Shaders

Проход в жабу

Тогда не торопимся. Дай мне константные вещи которые будут приняты, типа RGBA 8bit картинко 16384x16384 и тому подобное, сначала просто гауса размыть, а всякие коррекции на потом, сколько проходов гауса и всё вот это. Попробую, но ничего не обещаю и да управляющий код на С. )

Ты опять упарываешься?

Я исходники отдал тому, кто попросил помощи и дал мне доку с требованиями, Если не тупой - сам его найдёшь.

Зависть - это плохо. Если ты сам ничего не можешь дельного написать и даже разобраться в чём-то, не стоит метаться какашками в других.

У меня управляющий на Java.

::)

Этот упоротый молодой тролль тебя тоже достал?

Ну и пофиг, На скорость оно не должно влиять, ну в том плане что если блюрить огромную картинку что у тебя что у меня будет 1-2 fps по итогу. Короче я спать пошёл. Я буду делать исключительно по настроению и ты надеюсь тоже, если бросишь не важно и не страшно, аналогично и я. И любой. Но я попробую. Если всё сложится то будем по итогу сравнивать, ну сначала добиваться 1в1 сходства и что-бы сохранённые изображения заблюренные даже шехом совпадали, а потом уже сравнивать, ну и пытаться обогнать друг друга выжимая максимум

Этот упоротый молодой тролль тебя тоже достал?

i-rinat ? Он не троль. Ну и не особо молодой, хороший дядька такой. Я бы даже сказал добрый.

Давай завтра спишемся по ТЗ.

Могу поискать доки, что мне кидал тутошний разработчик SVG парсера с GPL, которому я отдал исходники алгоритма с требованиями что он попросил.

Ну молодость - понятие относительное, как и доброта. К стати как и честность.

Я бы может и дружил бы с ним, если бы он не метался при каждом разе своими какашками, притом бездоказательно. Я могу привести примеры своей правоты и что я отдаю исходники, Но он... Я ХЗ что у него в голове...

Может ему девушку нужно и секса. Это наверняка.

А я то тут причём...

Короч я спать. Завтра будет яснее. Может вообще болт забъём , всё на добровольных началах с бухты барахты, видно будет:D

Не знаю что у вас там с ренатом за драмма была, но вангую вы просто друг друга не поняли или ещё чего, он адекватный, а шутит по делу обычно. Ну вы там сами, как нибудь разберитесь.

Ок споки. Но тут фигня в том, что я не всегда обязан, а тем более имею возможность отдать исходники. Я имею право делать и не опен сорс проги. А он не имеет права с меня их требовать. Опен сорс проги от меня на этом ресурсе задекларированы. Так что он врёт. Это его не красит как ты заявляешь «хорошего дядьку». ;)

Вам надо по-проще задачу, а не гаусс. Предлагаю посчитать в потоках cuda/openCL/Vulkan хеши от упакованных координат в 2D сетке, 65535x65535 пикселей, каждый пиксель имеет XY [0-65535], упаковываете 2 uint16 координаты в одно uint32 через X << 16 | Y, получаем uint32, и от него считаем хеш через простую:

uint32_t hash( uint32_t a)
{
   a = (a+0x7ed55d16) + (a<<12);
   a = (a^0xc761c23c) ^ (a>>19);
   a = (a+0x165667b1) + (a<<5);
   a = (a+0xd3a2646c) ^ (a<<9);
   a = (a+0xfd7046c5) + (a<<3);
   a = (a^0xb55a4f09) ^ (a>>16);
   return a;
}

Далее шлёте хеши на CPU, и xor их всех друг с другом в последний хеш, замеряете время и result хеш :)

Далее шлёте хеши на CPU, и xor их всех друг с другом в последний хеш, замеряете время и result хеш :)

Тут подробнее. Зачем CPU? И что где и когда замеряем?

Как там Vulkan в плане вычислений на GPU, пошёл в массы со своими шейдерами?

Нет, нету удобных для программиста-среднего-ума инструментов, чтоб использовать это массово. Т.е. типичный процесс разработки Vulkan compute shader сводится к разработке {GL,HL}SL -compute shader-а, и написаннию бойлерплейта обвязки. И OpenCL и CUDA удобнее как в отношении количества бойлерплейта в хостовом коде, так и в девайсном, чем текущий Vulkan c мифическим приростом где-то там.

Ждуны ждут слияния спек OpenCL и Vulkan, другие ждуны ждут поддержки С++ в OpenCL kernels вендорами, а остальные либо фигачат на Сишечке, либо получают радость от анального зонда nvidia.

Причина популярности CUDA в удобности разработки на ней для человека не умеющего в С.

Насчет перформанса, имею одну и ту же сложную задачу (dense multiview stereopsis) реализованную как на OpenCL, так и на CUDA, cuda на железках от nvidia работает до 1.5 раз быстрее, чем OpenCL. Связано в том числе и с тем, что в CUDA-кернелах можно в С++, что местами приводит к более оптимальному конечному коду, ну и плюс всякие ухищрения в месте перегона данный с видяхи и обратно (этого можно добиться в OpenCL на nvidia c помощью nvidia-only флажков, но будет vendor-specific, а раз уже есть полностью cuda-реализация то эти костыли не нужны).

Ну и последний аспект, все также сильно зависит от задачи, на которой будет сравниваться производительность.

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

Есть также примеры обратные, например кодирование видео на каком-нибудь внутрипроцессорном Intel Iris 6200 будет работать быстрее, чем на видяшечке типа Radeon RX 560, просто потому, что у интела есть спец-код для именно этой задачи.

Не со всеми аспектами согласен.

Пефоманс не только от количества потоков зависит, есть нюансы по распределению памяти. И не всегда написанное на одной технологии так же качественно сделано на другой.

А в принципе да. Примерно так и есть.

По крайней мере в планах было слияние OpenCL и Vulkan. Но пока этого нет, и вроде как не все фичи OpenCL могут быть как-то реализованы в Vulkan. Хотя в последних версиях для OpenCL/Vulkan/OpenGL перешли на промежуточное представление SPIR-V. Если раньше была куча языков для вычислений и была морока с их поддержкой то теперь все сводится к тому что их можно скомпилить в SPIR-V. Это сильно упрощает разработку, плюс на этом представлении можно попробовать выжать максимум производительности из видеокарты.
Вообще я наверно как и многие ждут что в Vulkan вольется OpenCL и Video decode/encode блоки.
Чтоб можно было через один Vulkan рассчитывать геометрию сцены с помощью OpenCL, рендерить её и через Video encode блок фреймы кодировать в видео и все это без необходимости гонять туда сюда данные между GPU и CPU. На AMD картах такое сейчас можно только через ROCm, а хочется через стандартный Vulkan.

через Video encode блок фреймы кодировать в видео

Объясни мне пожалуйста про это подробнее.

Я предполагаю, что это делается через те же шейдеры. Как-то ринат начал было тему про это в прошлом году, но заглох не нашедши доказательств в библиотеках, которые использует, что происходит это как-то иначе.

Детальнее я имею ввиду декодирование из MPG формата в изображение в виде пикселей на экран. Это имелось ввиду при упоминании «Video encode блок»?

Хотя да. Как энкод так и декод я имел ввиду.

Я предупредить, взяться сейчас нет возможности. Но если что я просто выплюну суда ссылку на гитхаб с квестом перегнать мой код. Как то так )) (Не факт что это будет гаус, но не суть)

Хотя я всё время путаю HLSL с GLSL, они чем-то отличаются сейчас?

«Сейчас» SPIR-V. Шейдерный байт-код. А вообще HLSL — это вендовский аналог GLSL из DirectX. HLSL вроде проще в разработке, но это не точно.

просто потому, что у интела есть спец-код

У AMD есть VCE, у nVidia есть NVENC.
У обеих фирм до кучи были варианты кодирования на потоковых процессорах в отсутствие выделенного блока обработки видео.

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

Либо опиши алгоритм каким ты размываешь и я напишу свою поделку по нему, либо я выложу тебе доки и алгоритмы просто гаус функции для двумерного массива, а там ты сам разбирайся.

Ну скинь эталонный алгоритм, что бы ни шагу в лево ни шагу в право. Конечно это правильно будет. Тут бенчи, а не оптимизации.

Сегодня найду - кину код и теорию.

Но таки оптимизировать есть всегда где.

ЛОРовцу, которому запилил именно размытие ARGB изображений с вычислением гаммы в начале бросил полу-оптимизацию.

Потом попилил ещё несколько часов и сказал, что есть более оптимизированное, он сказал - «та и этого достаточно, работает корректно, больше мне пока и не нужно»

Да я имею в виду оптимизации такие себе типа хаков, я могу взять текстуру сгенерировать мипмапы, установить LOD_BIAS в -4 и сделать 4 прохода размытия путём сдвига текселя с цветом делёным пополам. Быстрее этого ничего не будет ))))) Тип оптимизации не за счёт эмуляции все дела

Ищу специфическую реализацию фильтра размытия по Гауссу (комментарий)

Потом мы реультаты с «эталоном» из инскейпа сравнивали (результат был не плох). Но у инскейпа жутко всё было. Я написал программу анализирующую картинку после блюра с прозрачностью и гаммой у инскейпа - там просто шокирующе всё выглядит. У меня всё гладенько и чётко. Сравнивал с Фотошопом, да у Фотошопа тоже всё красивенько.

https://d1rkab7tlqy5f1.cloudfront.net/TNW/Over faculteit/Decaan/Publications/...

Ипануться o_O ну ладн чё. Как пойму так и сделаю :D :D:D:D:D:D:D:D:D:D:D

Не... Я пришлю алгоритм упрощённый по двумерной матрице.

Для ARGB там да... мозг прийдётся выкрутить чуток.

Поищу.

Нет не упрощённый. Он более понятен чем теоретический материал на восприятие глазами. Я про это.

К стати с применением обработки гаммы изображения там действительно всё жутко становится.

https://ru.wikipedia.org/wiki/Гамма-коррекция

Тут упрощено, я искал и читал несколько дней литературу по этому поводу для реализации в программе.

HLSL вроде проще

Вендузятские байки, вроде.

Видеокарты аппаратно конвертируют на лету из sRGB в linear и обратно.

И? Что сказать то хотел?

Ты же не полную инфу сказал. Давай выкладывай полностью всю теорию и где нужно это, а где не нужно и какие именно аппаратные средства применяются и в каких случаях..

Сам включаешь выходную конвертацию linear->srgb и входную srgb -> linear. Выходная нужна пожалуй всегда, входная - очевидно если на входе srgb, как большинство картинок.

Не всегда так. Профессиональные мониторы современные поддерживают linear. В старых трубочных мониторах в основном требовалось корректировать гамму.

TC вулкан то тут причём? у него же ничего нет для вычислений в вакууме, теже самые шейдеры что были так и остались.

угу, вулкан для игоря же. КАДА для вычислений, преимущественно параллельных. каким фигом их сравнивать, если жопорукие игроделы так и не осилили в многопоток?

Многопоток в играх таки есть, но там не всё так просто.

Ты же даже не программист.

Многопоточность вулкана это не про то, GPU как жил отдельно так и живёт, но есть буферы кадров, буферы текстур и прочее прочее прочее, вычисления матриц камеры и очень много чего ещё, всё тоесть само API , его реализация именно она паралелится, ибо именно она порой была узком горлышком, видеокарта порой больше ждала данных чем отрисовывала их, суть вулкана уйти от этого, вычисления же на самом GPU какие были такие и остались. Вулкан это про CPU и уход от фиксированного конвеера OpenGL, а не про GPU.

И да, многопоток легко сказать, чаще всего он зло, толку от него только в может быть звуке и физике если про игры говорить ну и всё, остальное это как монетку в небо.

Почти так.

Я когда разрабатывал свой графический движок для андроида... Да, у меня отдельный поток для музыки, отдельно для звуков, отдельно просчитывание некоторых тяжёлых обработок, а вот просчёт изменения графических объектов и их прорисовка один поток.

Хотя недавно я продумал частичный параллелинг.

В вулкане как раз буферы команд можно генерировать в разных потоках одновременно.

покажи экзампл.

https://github.com/SaschaWillems/Vulkan/#-performance

В моих проектах я тоже генерирую много потоков OpenCL одновременно. Тысячи. Да.

Я так понял ты про workgoups на видеокарте, а я про многопоточность апи на процессоре.