Отрисовка графиков в реальном времени через GPU

Qt

QGL

GTK

GTKGL

Посмотри у куды пример с динамическим буфером вершин. По аналогии можно и 2D-график забульбенить.

Просмотрел список не нашёл чего-то такого. Можно ссылку поподробнее?

Не могу сходу найти, что-то вроде этого.

http://pyopengl.sourceforge.net/

mathGL. Или gnuplot.

Не надо строить велосипеды там, где без этого не обойтись. В Вашем случае без этого обойтись думаю таки можно (иначе Вы бы не искали фреймворк да еще на питоне;-)).

Интересно, почему ТСу всякий бред предлагают, если он ясно сказал:

параллельная отрисовка в реальном времени

Это — только CUDA с ее динамическими VBO. Двух- и трехмерные графики спокойно рисуй. Особо существенно для 3D, если ты хочешь, скажем, с частотой в 30Гц отрисовывать новую порцию данных 4000х4000 пикселей.

Я гнуплот уже прошерстил. Если бы Вы его знали и(или) внимательно прочитали тему, то гнуплот бы не советовали ;-)

Ибо гнуплот НЕ ХРАНИТ данные которые рисует. Про доступ к акселератору - молчу вообще. А вот MathGl - спасибо - гляну.

Нашёл еще - nanoVG - опенгл только векторный.

Чёто душа к куде не лежит. Хотя, если лучше не найду. А равзе есть разница между кудовским VBO и опенгээльным VBO/PBO/FBO в плане обновляемости и параллелизма.

Да - вобщем-то пока сюда ориентируюсь. Только не до конца разобрался с его доступом к памяти акселератора. Хз, можно ли там памятью управлять также как обычной ОЗУ.

Чёто душа к куде не лежит

Тогда забудь о реальном времени средствами GPU, только полностью буферы перезагонять в оперативу видюхи средствами опенгля.

А равзе есть разница между кудовским VBO и опенгээльным VBO/PBO/FBO в плане обновляемости и параллелизма.

А ты пример пощупай. Скажем, когда я рисую поверхность в 16мегавершин, первичная инициализация буфера VBO занимает аж 2-3 секунды на машине средней мощности. Если же я захочу обновить поверхность, мне придется те же 2-3 тратить. В куде все шустро.

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

Нда, походу решающий аргумент. Ну, значит Cuda. Спасибо за помощь.

Эдди, openGL таки тоже умеет рисовать параллельно в реальном времени.

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

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

Котировки биржевых инструментов. По одному графику приходят до нескольких сотен тиков в секунду + идёт обработка данных параллельно. И отображать на экране надо всё максимально близко к реальному времени. Один массив данных ! параллельно обрабатывается несколькими обработчиками ! и еще должен отрисовываться при этом. С блокировками связываться не хочу, т.к. придется создавать для этого новую структуру с частичными блокировками и кучей подводных камней. Не вижу смысла... пока. Тем более, есть «простаивающая видюха».

Вариант: тупо копировать буфер для отрисовки в отдельный. Да и тут придется семафорить по минимуму + двойной расход ОЗУ - прохладно. Поэтому решил тупо копировать в видюху а не в озу и там рисовать. Ибо нефиг ей простаивать.

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

Как?

Это что ли просто одна функция у(х)? И это надо делать на cuda??? O_O

Шейдерами? В чем проблема то?

Шейдерами?

4.2! Шейдер надо в память загружать, прежде чем он заработает. Невозможно это. И еще: программить опенгль шейдерами — это как на ассемблере писать гуйню! Извращение и BDSM!

Ну загрузил (ОДИН раз) и дальше он параллельно все обрабатывает.

А чем его надо программить?

ТС-у это все вообще не упало, ему максимум 2тыс отрезочков рисовать - это в чем угодно делается, хоть в PIL.

Ну загрузил (ОДИН раз) и дальше он параллельно все обрабатывает.

А данные к нему поступают через божественный флюидный эфир? ☺

MathGL + SetQuality(6) или SetQuality(5), чтобы память лишнюю не использовать.

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

В этом случае динамические кудовские VBO работали бы не шустрей стандартных опенгльных. А таки фиг! 60fps на 16 мегапикселях — как с куста! И это на очень старой видюхе!!!

Э... во первых надыть наврное смотреть что ты рисуешь и как.

Во вторых, если про визуализацию научных результатов - нафик там 60 фпс?

16Мп - а на чем ты это смотришь?:-)

Я вам сейчас немножко поясню. Вообще 1! график инструмента занимает в памяти от 1 сотни мегабайт в день (в несжатом виде) за 1! день, так что

ему максимум 2тыс отрезочков рисовать - это в чем угодно делается, хоть в PIL.

не совсем туда.

У меня есть «рабочий» вариант h5py+matplotlib+numpy.memmap. Оперативка свободная - скорость так себе. Но я решил заморочится, чтобы данные хранить в видюшной оперативке. Не столько из за скорости рендеринга, сколько из за использования видюхи для хранения данных. Есть опенкл для вычислени на графике, но она вроде засохла, поэтому ищу что-то типа того.

ЗЫ

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

100Мб пл нынешним временам это копейки.

Но мы же про отрисовку, да? Вы не сможете нарисвать линию толщиной меньше пикселя. Я не знаю что за монитор у Эдди на 16Мп, но если у предположить что у стандартного монитора разршение по х 1920 пикселей, то все что Вы сможете нарисовать в итоге это 1920 вертикальных отрезочков (все Ваши многочисленные точки в рамках одного шага по х превратятся в вертикальный отрезок).

Это совершенно пофигу на чем делать. Вон Балакин Впм выше посоветовал mathGL. Или можно взять какой нить матплотлиб.

Парадокс на. Человек говнякает на педоне, но волнуется за оверхед двойной буферизации.

- Прототип на питоне!? - Не не слышал. Я только хеловорлды пишу, зато на ассемблере и сишечке. ))

Это я фитс-файл на экране отображал, чтобы кошерненько было. А все 16мегавершин — для простоты, чтобы когда масштабируешь, не надо было тормозить и перерисовывать.

ЯННП:-(

сцылки на «НП» в студию. А то мне как-то одно тело на экскурсии на БТА (я там, кстати, стараюсь так излагать, чтобы даже имбецилы понимали) сказало, что, мол, «ЯННП, идите нафиг со сфоей ѓастрономией»; благо, остальные более разумные были, засмеяли это тело нафиг.

Что такое фитс-файл?

Почему при прорисовке 16 млн вершин каждая вершина отображается одной точкой?

Что такое фитс-файл?

Яфигею. Тебя в гугле забанили что ли? Это — единственный и неповторимый формат для хранения астрофизической информации (параметры+таблицы+изображения). Гугли FITS и cfisio (единственная нормальная библиотека для работы с фитсами). Кстати, префикс «це» в этой библиотеке дает повод задуматься о ненужности всякого це++, жабки, пхытона и прочего шлака.

Почему при прорисовке 16 млн вершин каждая вершина отображается одной точкой?

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

Э... то есть ты сейчас с гордостью говоришь про отрисовку изображения 4000х4000, пусть с каким то продвинутым зумом, на куде?

Эдди, ты смеешься над нами?

По крайней мере, оно работает. Аналогов-то нет! Был бы софт, не нужно было бы лисопедить.

Эдди, я не сомневаюсь в том что оно работает. Я о другом - ты с ГОРДОСТЬЮ рассказываешь как ты написал на куде продвинутый зум, который позволяет смотреть файл размерами 4000х4000. ДВУМЕРНЫЙ файл, Карл!!!

Эдди, у меня коллеги юзают самописный вьювер на куде, который рендерит 10^9 вокселей (сетку 1000х1000х1000). Там конечно не 60 fps, но все плавно, без скачков.

У меня давеча аспирант написал вьювер на OpenGL для просмотра результатов моделирования магнетиков атом-в-атом, каждый атом это красно-синяя сфера, окраска передает направление магнитного момента. Так вот, 16 миллионов атомов (не точек - сфер, каждую сферу можно растнуть на экран, это честное 3D с преобразованием координат и пр. фигней) на моем ноуте с интеловским встроенным адаптером рендерится за секунды без всякой куды.

Для визуализации двумерных массивов я уж сколько лет юзаю самописный однопоточный вьювер, на плюсах и PIL, без всякого openGL, который массивы в неск млн точек рисует влет и зумирует их с биленейной и бикубической интерполяцией (конечно не так изощренно как у тебя). Я не мерял его fps - мне хватает, идет без рывков. Мне даже как то неловко об этом рассказывать...

ДВУМЕРНЫЙ файл, Карл!!!

Ясен пень, двумерный. Чтобы трехмерные данные визуализировать, нужно хитрожопые вещи придумывать. Я как-то на конференции лет 5 назад про подобные вещи слышал. Но таки оно до сих пор не очень-то опопсовело. Таки такие сложные вещи отображать — та еще жуть...

16 миллионов атомов (не точек - сфер, каждую сферу можно растнуть на экран, это честное 3D с преобразованием координат и пр. фигней) на моем ноуте с интеловским встроенным адаптером рендерится за секунды без всякой куды

Кинь ссыль на ПО, pls. Очень интeресно.

Мне даже как то неловко об этом рассказывать...

И тудым ссыль, pls. Весбма ъльимл

Так вот, 16 миллионов атомов (не точек - сфер, каждую сферу можно растнуть на экран, это честное 3D с преобразованием координат и пр. фигней) на моем ноуте с интеловским встроенным адаптером рендерится за секунды без всякой куды.

Увы, вопрос не в секундах, а в микросекундах, ибо новые тики приходят до сотни в секунду (не считая масштабирования). И отложенное рисование не годится. Конечно, общая сумма тиков не 16 млн, но все же.

Эдь, если говорить за двумерные массивы то уже давно в тренде гигапиксельные вещи.

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

Ссылку в почту могу.

Я не спец по системам реального времени, но если это рисуется для человека, то разницу между 20фпс и 100фпс имно хрен заметишь.

Если рисуется хвост (передний фронт) графика то тиков априори мало. Если рисуется график за сутки то тики сливаются.

В питоне взять канвас и добавлять тики по мере поступления например...

https://youtu.be/6TUP8q1ZQs8

Вот, посмотри что люди на куде делают:-)

И таки шо ты прегладаешь?

Это — древнючий кудовский икземпл.

В питоне взять канвас и добавлять тики по мере поступления например...

На данный момент так и делается. И для этого матплотлиба хватает вполне. Но смотрим далее.

Я не спец по системам реального времени,

Есть еще перерисовываемые индикаторы. Это когда не только хвост обновляется, но и тело. Блокировки заранее не просчитать, ибо нет гарантии, что перерисовка пойдет строго определённым образом - будет зависеть от плагина-обработчика. Да и переписывать алгоритм перерисовки под мои блокировки - сомнительное удовольствие. Так что придётся копировать в отрисовку весь буфер а это уже двойной расход озу. Так что с ГПУ я парюсь не просто так. Вобщем, пока на куду смотрю.

зы

Так что придётся копировать в отрисовку весь буфер

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