GPU gems in GIMP?

В этой теме 18 ответов, 3 участника, последнее обновление  RPG 4 года/лет, 12 мес. назад.

Просмотр 15 сообщений - с 1 по 15 (из 19 всего)
  • Автор
    Сообщения
  • #901

    RPG
    Участник

    Многие жалуются на то, что гимп очень медлителен, впрочем, я тоже жалуюсь: фотоаппараты у нас уже 14-мегапиксельные, фотки огромные, скорости гимпа уже недостаточно.

    Я слышал что гегль может исправить это, но до него пока как до Китая пешком.

    Нынче модно проводить вычисления, которые хорошо параллелятся, при помощи видеокарты (SIMD). Это отчасти популязирировано компанией Nvidia с её технологией чуда (CUDA). Тот SIMD, что реализован на CPU — смех да и только по сравнению с тысячами текстурных процессоров на современных видеокартах.

    Я же совсем недавно, почитав пару умных статей, понял, что пользоваться возможностью видеокарты для обработки изображений уже можно лет 8 как, с появлением Geforce 6200 и даже может 5200. В качестве языка программирования тут используется GLSL (не о CUDA речь, там требуется очень специфичное железо с не менее специфичным программированием).

    Мои эксперименты увенчались успехом: фильтр генерации шума Перлина, написанный на GLSL обгоняет на два порядка аналогичный фильтр в гимпе. Не менее быстр Gaussian Blur (для маленьких радиусов, преобразование Фурье я пока делать не стал). Операции бленда слоёв можно проводить на видеокарте — там это занимает смешное количество времени, даже на GF 6600.

    Интересно, что думают разработчики гимпа по этому поводу, планируют ли они использовать GPU для ускорения работы?

    Я это себе представляю так: проверятся возможности текущего железа (пробуем скомпилировать шейдр), если ок — выполняем фильтр на GPU, если нет — запускаем классическую реализацию на CPU. Многие алгоритмы обработки изображений уже написаны на шейдрах (операции смешивания слоев, размывание, резкость, выделение края, шум Перлин и другие). На GPU даже можно выполнять рисование на холсте, огромными кистями. Можно и сам хослт держать в памяти GPU и вытаскивать его оттуда только для сохранения. Гимп тогда сделает всех конкурентов:)

    Более того — писать на шейдрах несложно (проще чем на си — там уже есть все готовые функции для работы с графикой, векторная арифметика и другое), причем корявый алгоритм на шейдре значительно быстрее вылизанного на си: пропускная способность памяти моей видеокарты семилетней давности 30 Гб/с, что быстрее любого современного настольного компьютера. Неудивительно, что большая часть операций, которые в гимпе выполняются за секунды, на видеокарте выполняются 10-50 раз в секунду.

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

    Перлин шум, в моей программе Shader Toy:

    скорость — 25 FPS, то есть время генерации 1/25 с.

    #1654

    prokoudine
    Хранитель

    Да в общем-то уже идёт работа :)

    http://gimp.ru/news.php?readmore=161

    Виктор буквально позавчера залил в гит тестовое приложения для применения brightness/contrast на GPU через OpenCL.

    http://git.gnome.org/browse/gegl/log/?h=gsoc2011-opencl-2

    P.S. Я это к чему: если Вы серьёзно настроены этим позаниматься, то присоединяйтесь — работы там предостаточно.

    #1656

    RPG
    Участник

    OpenCL к сожалению требует наличия карточек, которые выпускали недавно:)

    Шейдры имеют боле мягкие ограничения, хотя и работают только в RGB.

    Я кстати обратил внимание, что гегль работает по «тайлам», что приводит к зверским артефактам, скажем, в гауссовом размывании. Но работа по тайлам это то что нужно для GPU, большинство не поддерживают текстуры больше 2048

    И макс радиус — 200:

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

    Гаусс размывание больших радиусов — вообще камень преткновения. Быстрый алгоритм использует преобразование Фурье, не знаю, это уже будет в gegl?

    Но по поводу быстрого гауссиан размывания у меня есть другие идеи:) Это будет очень быстрый алгоритм, хотя и не такой точный, но я надеюсь даже быстрее ПФ.
    Знакомый сейчас делает свой граф. редактор с использованием (надеюсь) шейдров. Если эксперимент удастся, то будет чего показать.

    И ещё такой вопрос — на гегль планируется переписать все фильтры и апи без исплючения?

    ЗЫ

    out_pixel[0] = (in_pixel[0] - 0.5f) * contrast + brightness + 0.5;
    out_pixel[1] = (in_pixel[1] - 0.5f) * contrast + brightness + 0.5;
    out_pixel[2] = (in_pixel[2] - 0.5f) * contrast + brightness + 0.5;

    SSE прям просится:)

    Эта операция, написанная на шейдре:


    uniform sampler2D image;
    uniform float brightness;
    uniform float contrast;
    void main()
    {
    gl_FragColor = vec4((texture2D(image, gl_TexCoord[0].xy).rgb - 0.5f) * contrast + brightness + 0.5, texture2D(image, gl_TexCoord[0].xy).a);
    }

    Время 0.0011 c

    #1658

    RPG
    Участник

    http://meudepositodeideias.wordpress.com/2011/08/08/opencl-on-gegl-results-up-to-now/
    Вот нашёл я эту статью.

    500 мс на картинку 1024х1024?
    400 мс с использованием OpenCL?
    При этом мой наспех написанный шейдр выдаёт 1.1 мс. Что-то в этом гегль не так. Это на моём железе (Nvidia GeForce 6600), которому до тестируемому Tesla C2050 (!!!) как до Китая по-пластунски.
    Да, сделаю скидку что у меня нет пересылки данных, но в данном случае она займет от силы 20 мс, опять же на старом железе где пропускная способность памяти всего 3 Гб/сек. Может я ошибаюсь, и 500 мс это время, за которое контраст изменяется 1000 раз? Очень надеюсь что я ошибаюсь.

    Он правильно пишет, 80% времени потрачено на пересылку данных от CPU к GPU и обратно. Чтобы этого не происходило, нужно держать плоскость редактирования в памяти GPU постоянно, тогда её даже можно легко рендерить при помощи OpenGL.

    Обратил внимание, что даже такая простая операция, как изменения контраста, выполняется у меня секунды 2.

    В камментах же пишут, что даже на ЖАБЕ эта операция выполняется в 1 поток за 16 мс:

    FWIW I made a mistake – the brightness/contrast code is only single threaded. I added some timing and it takes about 16ms to apply on a 1024

    #1660

    prokoudine
    Хранитель

    RPG написал:
    Быстрый алгоритм использует преобразование Фурье, не знаю, это уже будет в gegl?

    На самом деле, это уже было в GEGL :)

    http://git.gnome.org/browse/gegl/log/?h=gsoc2008-frequency-domain

    Там используется FFTW3. Но дальше оказалось, что лицензии FFTW и GEGL несовместимы, поэтому код так и не влили в основную ветку.

    И ещё такой вопрос — на гегль планируется переписать все фильтры и апи без исплючения?

    Да. Причём упразднение libgimp начнётся чуть ли не в 2.10.

    SSE прям просится:)

    Откуда у меня такое чувство, что Вы могли бы слать в проект полезные патчи? :)

    В чем же загадка тормозов?

    Возможно, в отсутствии асинхронности?

    https://mail.gnome.org/archives/gegl-developer-list/2011-October/msg00005.html

    #1661

    RPG
    Участник

    Там используется FFTW3. Но дальше оказалось, что лицензии FFTW и GEGL несовместимы, поэтому код так и не влили в основную ветку.

    Получается, разработчикам нужно писать код FFT самостоятльно? И тогда это будет не быстрее обычного гимпового размывания.

    Откуда у меня такое чувство, что Вы могли бы слать в проект полезные патчи?

    Я пока не понимаю, почему этот код так медленно работает на этом процессоре. Может быть, Виктор ошибся, и там не все так плохо, причем я не думаю, что данные три строчки — боттлнек.

    Возможно, в отсутствии асинхронности?

    Получается, это тайловая природа гегля даёт такой оверхэд? Может, тайлы делать покрупнее, все равно такая производительность нужна только для 2-3-10 мегапиксельных изображений, а в случае с OpenCL тайлы и вовсе можно делать 1024*1024, видеокарта-то обычно одна.

    А тайлы в гауссовом размывании вообще тупиковый путь, на больших радиусах учитывается всё изображение, а не только тайл (как я уже показал на скриншоте, это даёт заметные артефакты). В гауссе нужно применить другой метод разделения потоков: вместо тайлов обрабатывать полосы, где гаусс сможет получить доступ ко всей полосе данных.

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

    #1667

    BigSerpent
    Участник

    OpenCL — не привязанная к вендору платформа…

    #1668

    RPG
    Участник

    OpenCL — не привязанная к вендору платформа…

    Про привязку к вендору — я имел ввиду, технологию ЧУДА, конечно.

    ОпенЦЛ конечно в этом плане более выгодная технология, но тут вот какая арифметика получается: он требует определенные драйвера и довольно-таки современный графический ускоритель. Судя по различным тестам в сети, ОпенЦЛь медленнее CUDA, а CUDA в свою очередь будет медленнее шейдров (если их пишет не обезьяна, а человек, знающий аппаратные особенности GPU).

    При этом поддержка пиксельных GLSL шейдров появилась чуть ли не на джифорсах 5200, а скорость выполнения такой операции как цветокоррекциия там составляет 1-2 миллисекунды, чего не скажешь о теущей гимповой скорости в 1-2 секунды. Ну и конечно GLSL охватывает более широкий спектр железа, а имея современную графическую карту можно глубину цвета держать хоть в double.

    И ещё — пиксельный шейдр просто создан для того, чтобы обрабатывать растровую графику. OpenCL и CUDA все-таки создавались ради другого: обработка не-графики на ГПУ. Это можно делать и шейдрами через бубен, но сложно. Но что касается картиночек то тут даже Low-End видеокарта семилетней давности даёт такой форсаж, что обладатель Core i7 ахнет. Я к сожалению не могу это показать так как все мои шейдерные тесты написаны под линукс, но это реально так:) Есть у меня программа, которая создаёт 1600 бесшовных текстур на основе шума Перлина (512х512) и сохраняет их в jpg за 2 минуты. Разделите и получите несравнимую с гимпом разницу. Моё железо, повторяюсь, не поддерживает никаких модных штук вроде OpenCL, CUDA.

    Я бы мог помочь разработчикам интегрировать фильтры в гегльили гимп (для этого всего лишь надо написать небольшую обёртку для компиляции шейдров) и дальше наделать кучу фильтров с аппаратным ускорением. А если держать холст гимпа внутри памяти видеокарты, получим вообще двойной форсаж с турбонаддувом и нитро. Однако, разработчики гимпа народ необщительный, своего форума у них похоже вообще нет (ненашёл) ну и в том же духе. Это ставит палки в колёса по части проталкивания в гимп всяких идей:)

    #1669

    prokoudine
    Хранитель

    RPG написал:
    Однако, разработчики гимпа народ необщительный, своего форума у них похоже вообще нет (ненашёл) ну и в том же духе. Это ставит палки в колёса по части проталкивания в гимп всяких идей:)

    С трудом понимаю, какое отношение имеет отсутствие форума к общительности разработчиков. Все обсуждения ведутся в IRC.

    #1670

    RPG
    Участник

    С трудом понимаю, какое отношение имеет отсутствие форума к общительности разработчиков. Все обсуждения ведутся в IRC.

    Мне почему-то казалось что ирк каналы разработчиков пустуют:) Да и хистори…

    #1671

    prokoudine
    Хранитель

    RPG написал:
    Мне почему-то казалось что ирк каналы разработчиков пустуют:) Да и хистори…

    На моей памяти #gimp на GIMPnet не пустовал никогда.

    Про хистори не понял :)

    #1672

    RPG
    Участник

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

    На мой взгляд, когда речь идёт о разработке крупного проекта, вроде ГИМП, история обсуждений простой обязательна для сохранения. Это позволяет координировать разработчиков без отрыва от производства (в форум пишешь когда есть время, а в чат — только когда собеседник онлайн)

    ЗЫ Написал. Пока тишь да глушь.

    #1673

    BigSerpent
    Участник

    RPG: интересно, был ответ?

    Chat действительно специфическая штука. Есть рассылка gimp-developer на gnome.org. Если написать туда письмо, оно не будет проигнорировано.

    #1674

    RPG
    Участник

    Да, ответ был. В общем в гегле был эксперимент с glsl, но человек, который его делал, так и не закончил работу. Виктор делает на OpenCL, так как с OpenGL не имел дела, а также считают преимуществом возможность запустать ядра OpenCL на CPU, используя приемы динамической компиляции для генерации фильтров на лету. Также причиной неиспользования GLSL является то, что разработчики боятся, что он где-то не заработает.

    Главная проблема встала как раз в том, что если уж пользоваться GPU ускорением, то все слои желательно держать в памяти видеокарты и перекидывать их на процессор только уж в очень редких случаях. Этим как раз Виктор и занимается, потому что прикрутка OpenCL/OpenGL — дело техники, главное — решение множества проблем, возникающих из-за тайловой природы гегля (что хорошо для CPU будет адом для GPU).

    Я попробовал скачать ветку с glsl, но она не компилируется по неизвестным мне причинам. Поэтому попробую включить OpenGL в код Виктора.

    Также непонятно, как соотносится производительность OpenGL OpenCL. Виктор кроме того теста на 500 ms ничего не проводил, реального сравнения у нас просто нет. Кроме того многие боятся, что работа фильтра отдельно от гегля и работа фильтра с геглем — разные вещи. Так что с производительностью всё очень туманно. Говорят, правда, OpenCL и кудаподобные языки позволяют программисту использовать видеокарту по максимуму, но и GLSL тоже не лыком шит, его компилятор отлаживался в течение 10 лет, в то время как CUDA только-только встает на ноги. Что касается гибкости — у OpenCL намного больше возможностей, но в руках человека, хорошо владеющего шейдерным языком, GLSL станет не менее мощным инструментом. Надо сказать что именно на GLSL появились первые симуляторы тканей и систем частиц.

    Я запустил небольшую программу по тестированию производительности фильтра Гаусса, на видеокартах, которые сейчас можно купить за 4000 руб. фильтр работает за 120 мс для изображения 1024х1024 при радиусе 500, несмотря на неэффективность алгоритма. То есть мне даже не потребовалось делать преобразование фурье, чтобы значительно обставить по производительности фильтр гаусса в гимпе (текущий гимповый фильтр, кстати, работает быстрее геглского).

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

    #1706

    RPG
    Участник

    Ещё один аргумент «за».

    Всё-таки когда мы говорим о вычислениях на GPU, мы говорим о карточках уровня NVidia или ATI, сам я все тесты проводил на GeForce. А ещё интересно было бы посмотреть на как минимум треть рынка: офисные компьютеры, ноутбуки, в общем, девайсы со встроенной графикой от Intel GMA. Intel GMA в последнее время вполне играбельны на ноутбуках, посмотрим, как они поведут себя в качестве сопроцессора для обработки графики.

    Я запустил один из своих шейдров с размыванием по Гауссу на офисном компе с видеокартой Intel. Если честно, я не надеялся что такой сложный шейдр как Гаусс будет вообще работать, но вопреки всему этот «офисный» комп выдал 140 FPS(!!!) на картинке 512х512. Потрясающий результат. Такая видеокарта может с уверенностью использоваться для обработки восьмибитных изображений, и, теоретически, для изображений с 32 битами на канал.

    Я повторно пытаюсь сейчас разобраться в коде gegl чтобы хоть что-то туда присобачить, но я в нём крайне плохо ориентируюсь, совсем непонятно что и как там работает. А ещё непонятно почему забросили gsoc2009.

Просмотр 15 сообщений - с 1 по 15 (из 19 всего)

Для ответа в этой теме необходимо авторизоваться.