Есть несколько огромных структур данных. И граф, каждый нод которого или генерит одну из таких структур или как-то принимает эти структуры от других нод, что-то меняет в них, может сливает несколько в одну, или разделяет и отдает на следующие изменения.
Еще важный момент — в каждой ноде данные лежат не кусками по памяти, а сплошным куском. Они в видюху перебрасываются.
Штука в том, чтобы малейшее изменение в одной из нод мгновенно бы отображалось в зависящих от нее нодах.
Копирование всего и вся и распространение сигналов на изменения — крайне неэффективно.
Если делать через ссылки на данные — нарушается условие связности данных.
Здравствуйте, kov_serg, Вы писали:
_>Для начала внятно сформулировать требования и ограничения.
Ну пример.
нода А. Генерит миллион точек какой-то поверхности (по 3 флоата), нормали (по 3 флоата) и индексы треугольников (по три инта). У ноды есть параметры — параметры построения повехрности. То есть при изменении парамера меняются точки, нормали и индексы треугольников самой поверхности. Ну и на каждой вершине пара аттрибутов, например цвет, UV текстуры, может вес какой-то.
Тут как бы оптимизровать по памяти нечего. Миллион точек надо кидать в видюху и рендерить поверхность
нода В. Как А, но только другой алгоритм поверхности. Никак он А не зависит. Тоже свой массив данных.
нода С. На вход принимает ноду А и В и сшивает из них третью поверхность. Аттрибуты так же прнимаются с двух входов
Нода D — принимает на вход ноду С и как-то- искажает повехность
Нода Е — копируети поворачвает повехность от ноды D
Нода F — прнимает на вход D и E и делает булево вычитание поверхностей
Каждая нода может как-то рендриться. То есть мы должны кидать массив в видюху от любой ноды.
И!!! В чем собсвенно суть. Поменяв один параметр в ноде A все поверхности должны моментально пересроиться без копирования кучи данных между нодами.
Это возможно вообще?
Я говрю не про сами геометрческие алгоритмы. А именно про протаскивание кучи структур и оптимизацию этого
Здравствуйте, gyraboo, Вы писали:
G>Здравствуйте, Hоmunculus, Вы писали:
H>>Копирование всего и вся и распространение сигналов на изменения — крайне неэффективно. H>>Как быть?
G>Ну ты тогда не сигналы шли, а уведомление только списку подписчиков ноды. Вариации паттерна Publisher-Subscriber и MVC.
Так вопрос не в обновлении, а в излишнем копировании одних и тех же данных
Здравствуйте, Hоmunculus, Вы писали:
H>нода А. Генерит миллион точек какой-то поверхности (по 3 флоата), нормали (по 3 флоата) и индексы треугольников (по три инта). У ноды есть параметры — параметры построения повехрности. То есть при изменении парамера меняются точки, нормали и индексы треугольников самой поверхности. Ну и на каждой вершине пара аттрибутов, например цвет, UV текстуры, может вес какой-то. H>Тут как бы оптимизровать по памяти нечего. Миллион точек надо кидать в видюху и рендерить поверхность
H>нода В. Как А, но только другой алгоритм поверхности. Никак он А не зависит. Тоже свой массив данных.
H>нода С. На вход принимает ноду А и В и сшивает из них третью поверхность. Аттрибуты так же прнимаются с двух входов
H>Нода D — принимает на вход ноду С и как-то- искажает повехность
H>Нода Е — копируети поворачвает повехность от ноды D
H>Нода F — прнимает на вход D и E и делает булево вычитание поверхностей
H>Каждая нода может как-то рендриться. То есть мы должны кидать массив в видюху от любой ноды.
H>И!!! В чем собсвенно суть. Поменяв один параметр в ноде A все поверхности должны моментально пересроиться без копирования кучи данных между нодами.
Что значит моментально? Любая обработка требует ресурсов. Можно сделать быстрее огрубив результат и потом его утонять (если требуется)
H>Это возможно вообще?
Всё равно не очень понятно что надо. Моментально это сколько микросекунд?
H>Я говрю не про сами геометрческие алгоритмы. А именно про протаскивание кучи структур и оптимизацию этого
Разбить структуры так чтобы были разные уровни детализации, что бы можно было и быстро и точно (аля wavelets) и позволяло распаралеливать (обрабатывать разные уровни независимыми исполнителями)
Постараться держать данные в в видюхе минимизировать перекладывания.
Чтобы не протаскивать оперируйте ухватами (handles) и hash кодами.
Еще из общих соображений можно ужимать данные (в том числе с потерями) что бы не гонять меньше данных (coder-decoder)
Здравствуйте, Hоmunculus, Вы писали:
H>Копирование всего и вся и распространение сигналов на изменения — крайне неэффективно. H>Если делать через ссылки на данные — нарушается условие связности данных.
H>Как быть?
Выгладит так, что у тебя есть потоки данных и ноды-обработчики, которые потребляют потоки на входе и могут генерировать потоки на выходе.
Я бы разделил сущности: потоки отдельно, обработчики отдельно. Обработчики могут "подписываться" на потоки и "публиковать" потоки.
Здравствуйте, Hоmunculus, Вы писали:
H>Да, похоже на то, что в той программе, которую я пытаюсь повторить, тоже используют стримы данных. H>Это паттерн какой-то? Почитать бы поподробнее
Не знаю. Моя проблема в том, что я старый пень и формировался как профессионал одновременно с изобретением всех этих паттернов. Так что я могу знать и понимать какую-то идею (а может даже и переизобрести ее независимо в каком-то из своих проектов), но не знать её модное название. За модой-то не угонишься
Но в принципе, например, media streaming stack в венде как-то так и устроен. Есть медиапотоки, есть ноды-обработчики и есть динамическое построение связей между ними.
Я бы подумал заранее о том, как избежать циклов в получающемся графе соединений. Иначе оно будет не внение данные обрабатывать, а заниматься самоудовлетворением
А что такое «поток данных» в моем случае? Это постоянно меняющийся буфер и ноды просто работают с разными частями этого буфера? Просто с медиа-данными более-менее ясно, там последовательные кадры. А тут не очень
Здравствуйте, Hоmunculus, Вы писали:
H>А что такое «поток данных» в моем случае? Это постоянно меняющийся буфер и ноды просто работают с разными частями этого буфера? Просто с медиа-данными более-менее ясно, там последовательные кадры. А тут не очень
Тут надо посмотреть, что твои потоки по сути из себя представляют.
Если использовать общую память, то у тебя будет проблема, если эта общая память в какой-то момент неконсистентна. Придётся какую-то синхронизацию городить, и тут есть риск, если нода захватит мьютекс и подвиснет, она поставит раком всю систему.
Не получится в виде потока байтов (или фреймов, пакетов и т.п.) организовать? Так сильно проще/удобнее/надежнее, но вызывает потребность копировать данные. Что может быть приемлимо или нет, в зависимости от объема передаваемых данных.
Здравствуйте, Hоmunculus, Вы писали:
H>А что такое «поток данных» в моем случае? Это постоянно меняющийся буфер и ноды просто работают с разными частями этого буфера? Просто с медиа-данными более-менее ясно, там последовательные кадры. А тут не очень
Вообще, если твои данные в конечном итоге пробрасываются в видюху, может их в видюхе и хранить?
Сейчас любой дектоп, что в венде, что в линухе, работает следующим образом. Приложения рисует свои окошки в невидимой области видеопамяти, а window manager потом сводит всё это в единую картинку, заодно добавляя тени, полупрозрачность и прочие красотости. Это называется compositing window manager, в отличии от старомодного, который окошки прямо на экране расставлял, а рисовали они сами прям на экран.
Т.е., в принципе, аппаратура позволяет как хранить свои данные в невидимой области видеопамяти, так и сводить их вместе, добавляя какую-то обработку в процессе.
И я думаю, там синхронизация предусмотрена на уровне видеокарты или видеодрайвера.
Но я не знаток видеоподсистемы. Посмотри туда, может подойдёт...
Здравствуйте, Hоmunculus, Вы писали:
H>Здравствуйте, gyraboo, Вы писали:
G>>Здравствуйте, Hоmunculus, Вы писали:
H>>>Копирование всего и вся и распространение сигналов на изменения — крайне неэффективно. H>>>Как быть?
G>>Ну ты тогда не сигналы шли, а уведомление только списку подписчиков ноды. Вариации паттерна Publisher-Subscriber и MVC.
H>Так вопрос не в обновлении, а в излишнем копировании одних и тех же данных
А зачем их копировать. Что мешает ноде Б получить ссылку на данные из ноды A, и построить на их основе свои данные, которые физически хранятся в ней. Потом послать уведомления нодам, которые зависят от неё (что это за уведомления, вопрос второй, то ли сообщения, то ли прямой вызов Update), которые сделают то же самое. Вроде бы очевидно. Другое дело, что лучше не инициировать немедленный пересчёт у зависимых узлов, а просто инвалидить их, а просчёты делать уже по запросу, который вызовет каскадную валидацию узлов, от которых зависит запрашиваемый.
Здравствуйте, Hоmunculus, Вы писали:
H>Здравствуйте, kov_serg, Вы писали:
_>>Для начала внятно сформулировать требования и ограничения.
H>Ну пример. H>нода А. Генерит миллион точек какой-то поверхности (по 3 флоата), нормали (по 3 флоата) и индексы треугольников (по три инта). У ноды есть параметры — параметры построения повехрности. То есть при изменении парамера меняются точки, нормали и индексы треугольников самой поверхности. Ну и на каждой вершине пара аттрибутов, например цвет, UV текстуры, может вес какой-то. H>Тут как бы оптимизровать по памяти нечего. Миллион точек надо кидать в видюху и рендерить поверхность
H>нода В. Как А, но только другой алгоритм поверхности. Никак он А не зависит. Тоже свой массив данных.
H>нода С. На вход принимает ноду А и В и сшивает из них третью поверхность. Аттрибуты так же прнимаются с двух входов
H>Нода D — принимает на вход ноду С и как-то- искажает повехность
H>Нода Е — копируети поворачвает повехность от ноды D
H>Нода F — прнимает на вход D и E и делает булево вычитание поверхностей
H>Каждая нода может как-то рендриться. То есть мы должны кидать массив в видюху от любой ноды.
H>И!!! В чем собсвенно суть. Поменяв один параметр в ноде A все поверхности должны моментально пересроиться без копирования кучи данных между нодами.
H>Это возможно вообще?
H>Я говрю не про сами геометрческие алгоритмы. А именно про протаскивание кучи структур и оптимизацию этого
ПО сути надо построить графы зависимости и инвалидации.
1) можно хранить данные по ссылке и тогда при расчете все будет актуально
2) можно например построить граф зависмостей и построить дерево обновления.
В ноде А поменяли значение, значит надо пойти в граф зависимостей и пересчитать все значения.
Обновление данных можно делать в разное время: сразу или по какому-то сигналу, вопрос применения
