LINUX.ORG.RU

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

 ,


0

2

Подскажите кроссплатформенный фрэймворк, желательно на питоне, чтобы можно было при минимальном программировании отрисовывать графики через ГПУ.

Почему через ГПУ?

Графики довольно емкие и хочется сэконоить оперативку при двойной буферизации.

С одним буфером же параллельная отрисовка в реальному времени - геморой тот ещё.

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

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

Eddy_Em ☆☆☆☆☆
()

mathGL. Или gnuplot.

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от AIv

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

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

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

BuzzBomb
() автор топика
Ответ на: комментарий от Eddy_Em

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

BuzzBomb
() автор топика
Ответ на: комментарий от CatsCantFly

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

BuzzBomb
() автор топика
Ответ на: комментарий от BuzzBomb

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

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

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

BuzzBomb
() автор топика
Ответ на: комментарий от AIv

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

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

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

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

BuzzBomb
() автор топика
Ответ на: комментарий от BuzzBomb

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

Шейдерами?

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

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

AIv ★★★★★
()
Последнее исправление: AIv (всего исправлений: 1)
Ответ на: комментарий от AIv

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от BuzzBomb

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

abalakin ★★
()
Ответ на: комментарий от AIv

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

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

AIv ★★★★★
()
Последнее исправление: AIv (всего исправлений: 1)
Ответ на: комментарий от AIv

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

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

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

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

BuzzBomb
() автор топика
Ответ на: комментарий от BuzzBomb

ЗЫ

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

BuzzBomb
() автор топика
Ответ на: комментарий от BuzzBomb

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

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

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

AIv ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

BuzzBomb
() автор топика
Ответ на: комментарий от AIv

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от AIv

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

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

AIv ★★★★★
()
Ответ на: комментарий от Eddy_Em

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

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

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

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

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

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от AIv

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

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

BuzzBomb
() автор топика
Ответ на: комментарий от Eddy_Em

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

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

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

AIv ★★★★★
()
Ответ на: комментарий от BuzzBomb

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

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

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

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

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

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

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

BuzzBomb
() автор топика
Ответ на: комментарий от BuzzBomb

зы

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

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

BuzzBomb
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.