Рендеринг графика с использованием 3D-ускорения - PullRequest
8 голосов
/ 21 октября 2008

Мы генерируем графики для огромных наборов данных. Мы говорим 4096 выборок в секунду и 10 минут на график. Простой расчет составляет 4096 * 60 * 10 = 2457600 выборок на линейный график. Каждый образец представляет собой FP с двойной точностью (8 байт). Кроме того, мы отображаем несколько линейных графиков на одном экране, примерно до ста. Это позволяет нам рендерить около 25 миллионов сэмплов на одном экране. Используя здравый смысл и простые трюки, мы можем добиться того, чтобы этот код выполнялся с помощью процессора, рисуя его на 2D-холсте. Performant, то есть время рендеринга падает ниже одной минуты. Поскольку это научные данные, мы не можем опускать образцы. Серьезно, это не вариант. Даже не начинай думать об этом.

Естественно, мы хотим улучшить время рендеринга, используя все доступные методы. Многоядерность, предварительный рендеринг, кеширование - все это довольно интересно, но не стоит их сокращать. Мы хотим, чтобы рендеринг 30FPS с этими наборами данных был минимальным, предпочтительно 60FPS. У нас сейчас это амбициозная цель.

Естественный способ разгрузки графического рендеринга - использование графического процессора системы. Графические процессоры предназначены для работы с огромными наборами данных и их параллельной обработки. Несколько простых тестов HelloWorld показали разницу между скоростью рендеринга днем ​​и ночью при использовании графического процессора.

Теперь проблема в том, что API-интерфейсы GPU, такие как OpenGL, DirectX и XNA, предназначены для трехмерных сцен. Таким образом, их использование для визуализации 2D-графиков возможно, но не идеально. В доказательстве концепций, которые мы разработали, мы столкнулись с тем, что нам нужно преобразовать 2D-мир в 3D-мир. Неожиданно нам приходится работать с XYZ и системой координат с полигонами, вершинами и многим другим. Это далеко от идеала с точки зрения развития. Код становится нечитаемым, обслуживание - это кошмар, и все больше проблем накапливается.

Каким было бы ваше предложение или идея для этого в 3D? Является ли единственный способ сделать это, чтобы фактически преобразовать две системы (2D-координаты против 3D-координат и объектов)? Или есть более изящный способ добиться этого?

-Почему полезно рендерить несколько семплов на один пиксель? Так как он представляет набор данных лучше. Скажем, на один пиксель у вас есть значения 2, 5 и 8. Из-за некоторого алгоритма пропуска выборки рисуется только 5. Строка будет идти только к 5, а не к 8, следовательно, данные искажены. Вы также можете утверждать об обратном, но факт в том, что первый аргумент имеет значение для наборов данных, с которыми мы работаем. Именно поэтому мы не можем опустить образцы.

Ответы [ 12 ]

6 голосов
/ 22 октября 2008

Я хотел бы прокомментировать ваше утверждение о том, что вы не можете опустить образцы, в конце ответа tgamblin.

Вы должны рассматривать данные, которые вы выводите на экран, как проблему выборки. Вы говорите о 2,4 млн. Точек данных и пытаетесь нарисовать их на экране, который имеет всего несколько тысяч точек (по крайней мере, я предполагаю, что это так, поскольку вы беспокоитесь о частоте обновления 30 к / с)

Таким образом, это означает, что для каждого пикселя на оси x вы рендеритесь в порядке 1000 точек, которые вам не нужны. Даже если вы пойдете по пути использования вашего gpu (например, через использование opengl), это все еще большая работа, которую gpu необходимо выполнить для строк, которые не будут видны.

Методика, которую я использовал для представления образцов данных, заключается в создании набора данных, который является подмножеством всего набора, только для рендеринга. Для данного пикселя по оси x (т.е. заданной экранной координаты оси x) вам необходимо отобразить absolute максимум из 4 точек - это минимум y, максимум y, самый левый y и самый правый y. Это сделает всю информацию, которая может быть полезна. Вы по-прежнему можете видеть минимумы и максимумы и сохраняете связь с соседними пикселями.

Имея это в виду, вы можете определить количество сэмплов, которые попадут в один и тот же пиксель на оси x (представьте их как «ячейки данных»). В пределах данной корзины вы можете определить конкретные выборки для максимумов, минимумов и т. Д.

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

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

5 голосов
/ 21 октября 2008

Действительно популярный инструментарий для научной визуализации - VTK , и я думаю, что он соответствует вашим потребностям:

  1. Это высокоуровневый API, поэтому вам не придется использовать OpenGL (VTK построен поверх OpenGL). Есть интерфейсы для C ++, Python, Java и Tcl. Я думаю, это сделает вашу кодовую базу достаточно чистой.

  2. Вы можете импортировать все виды наборов данных в VTK (существует множество примеров от медицинских изображений до финансовых данных).

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

  4. Относительно:

    Это позволяет нам рендерить около 25 миллионов сэмплов на одном экране.

    [...]

    Поскольку это научные данные, мы не можем опустить образцы. Серьезно, это не вариант. Даже не начинай думать об этом.

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

Вам не нужно удалять точки из вашего фактического набора данных, но вы, несомненно, можете постепенно улучшать их, когда пользователь увеличивает масштаб. Бесполезно отображать 25 миллионов точек на одном экране, когда пользователь не может обработать все эти данные. Я бы порекомендовал вам взглянуть как на библиотеку VTK, так и на руководство пользователя VTK, поскольку там содержится некоторая бесценная информация о способах визуализации больших наборов данных.

5 голосов
/ 21 октября 2008

Вам действительно не нужно беспокоиться об оси Z, если вы этого не хотите. В OpenGL (например), вы можете указать XY вершины (с неявным Z = 0), поворот zbuffer, использовать непроективную проекционную матрицу, и эй, прежде чем вы в 2D.

3 голосов
/ 21 октября 2008

Марк Бесси упомянул об этом, что вам может не хватить пикселей для отображения графика. Но, учитывая ваши объяснения, я предполагаю, что вы знаете, что делаете.

OpenGL имеет ортогональный режим , который имеет z-координату внутри (0; 1). Перспективная проекция отсутствует, нарисованные полигоны будут плоскими относительно области отсечения экрана.

DirectX будет иметь подобное. На OpenGL это называется gluOrtho2d ().

2 голосов
/ 21 октября 2008

OpenGL будет рад отрисовать 2D, если вы настроите проекцию на Орто (без z). Также вы должны уничтожить свои данные. Рендеринг одного и того же пикселя 1000 раз - пустая трата графического процессора. Потратьте свое время заранее с помощью высокопроизводительного многопоточного дециматора. Не забудьте взорвать большие массивы в графическом процессоре, используя массивы вершин или объекты буфера вершин (очевидно, я вроде как парень из OpenGL)

1 голос
/ 09 декабря 2008

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

1) ParaView (paraview.org) - это пользовательский интерфейс, построенный на основе VTK, который значительно упрощает разработку продуктов для научной визуализации. Вы можете отобразить все данные, которые хотите, при условии, что у вас есть оборудование для их обработки, и оно поддерживает MPI для нескольких процессоров / ядер / кластеров. Он расширяется с помощью пользовательских плагинов и использует автоматизированные инструменты для построения и компиляции проекта.

2) ParaViewGeo (paraviewgeo.mirarco.org) является производным от ParaView для геологоразведки и разведки полезных ископаемых, выпущенным компанией, в которой я работаю. Он имеет встроенную поддержку для чтения форматов файлов, которых нет в ParaView, таких как Gocad, Datamine, Geosoft, SGems и другие. Что еще более важно, мы часто работаем с другими группами, которые заинтересованы в научных исследованиях, связанных со свободными связями с майнингом, такими как наша недавняя работа с группой, выполняющей моделирование конечных / дискретных элементов. Возможно, стоит проверить.

В обоих случаях (PV и PVG) ваши данные рассматриваются отдельно от вашего представления этих данных, и поэтому вы никогда не будете «рендерить» все свои данные (поскольку у вас вряд ли будет монитор, достаточно большой для того, чтобы сделайте это), но будьте уверены, что все будет "там" обработано из вашего набора данных, как вы ожидали. Если вы запустите дополнительные фильтры для ваших данных, будет отображено только то, что можно увидеть, но фильтры будут вычисляться для ВСЕХ ваших данных, которые, хотя могут и не быть видны сразу, все будут существовать в памяти.

Если вы ищете числа, сегодня я вычислил три регулярные сетки по 8 миллионов ячеек в PVG. Один содержал свойство вектора с 7 кортежами (двойные значения 7x8 миллионов), два других содержали скалярное свойство (двойные значения 1x8 миллионов каждый), что в общей сложности составляло 72 миллиона двойных значений в памяти. Я считаю, что объем памяти был близок к 500 МБ, но у меня также было задано 400 000 точек, где каждая точка имела свойство вектора из 7 кортежей и некоторые другие доступные данные.

1 голос
/ 21 октября 2008

Вам не нужно удалять точки из вашего фактического набора данных, но вы, безусловно, можете постепенно улучшать их, когда пользователь увеличивает масштаб. Бесполезно отображать 25 миллионов точек на одном экране, когда пользователь не может обработать все эти данные. Я бы порекомендовал вам взглянуть как на библиотеку VTK, так и на руководство пользователя VTK, поскольку там содержится некоторая бесценная информация о способах визуализации больших наборов данных.

Большое спасибо. Это именно то, что я искал. Похоже, что ВТК также использует оборудование для разгрузки такого рода рендеринга. Кстати, я думаю, вы имеете в виду ценный ;). Во-вторых, пользователь получает информацию о примере, который я привел. Однако не очень краткий, обзор данных может быть действительно чистым золотом для ученого. Речь идет не об обработке всех данных для пользователя, а о получении ценной информации из рендеринга. Пользователи, кажется, делают это, даже в самом «уменьшенном» представлении набора данных.

Есть еще предложения?

1 голос
/ 21 октября 2008

Если ваш код становится нечитаемым, потому что вы имеете дело с 3D-материалами напрямую, вам нужно написать тонкий слой адаптера, который инкапсулирует все 3D-компоненты OpenGL и принимает 2D-данные в форме, удобной для вашего приложения.

Простите, если я что-то пропустил, и я проповедую хору базовый объектно-ориентированный дизайн. Просто говорю ...

1 голос
/ 21 октября 2008

Это позволяет нам рендерить около 25 миллионов сэмплов на одном экране.

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

0 голосов
/ 21 октября 2008

Оберните библиотеку в более мягкую, добротную 2D-библиотеку с Z и вращениями, установленными на 0.

-Adam

...