Автор: Вольфганг Энгель (WolfgangEngel), директор компании Confetti

Давайте подробнее рассмотрим привязку ресурсов на платформах Intel^®. Сейчас это особенно актуально в связи с выпуском 6-го поколения процессоров семейства Intel^® Core™ (Skylake) и с выпуском операционной системы Windows 10, который состоялся 29 июля.

В предыдущей статье Введение в привязку ресурсов в Microsoft DirectX* 12были описаны новые способы привязки ресурсов в DirectX 12. Вывод из этой статьи был таким: при наличии настолько широкого выбора основная задача заключается в том, чтобы выбрать наилучший механизм привязки для целевого GPU, оптимальные типы ресурсов и частоту их обновления.

В этой статье описывается выбор различных механизмов привязки ресурсов для эффективного запуска приложений на определенных GPU Intel.

Инструменты

Для разработки игр на основе DirectX 12 требуется следующее:

• Windows 10.
• Visual Studio* 2013 или более поздней версии.
• Пакет DirectX 12 SDK, входящий в состав Visual Studio.
• GPU и драйверы, поддерживающие DirectX 12.

Обзор

Дескриптор — это блок данных, описывающий объект для GPU, в «непрозрачном» формате, предназначенном для GPU. В DirectX 12 поддерживаются следующие дескрипторы, которые ранее назывались «представлениями ресурсов» в DirectX 11:

• Представление буфера констант (CBV).
• Представление ресурсов шейдера (SRV).
• Представление неупорядоченного доступа (UAV).
• Представление семплера (SV).
• Представление цели рендеринга (RTV).
• Представление шаблона глубины (DSV).
• И другие.

Эти дескрипторы или представления ресурсов можно считать структурой (блоком), которая потребляется front end графического процессора. Размер дескрипторов составляет приблизительно 32–64 байта. Дескрипторы содержат информацию о размерах текстур, их формате и разметке.

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

Таблица дескрипторов указывает на дескрипторы в куче с помощью значений смещения. Таблица сопоставляет непрерывный диапазон дескрипторов с ячейками шейдера, делая их доступными с помощью рутовой подписи (root signature). Рутовая подпись также может содержать рутовые константы (root constants), рутовые дескрипторы (root descriptors) и статические семплеры.

Рисунок 1. Дескрипторы, куча дескрипторов, таблицы дескрипторов, рутовая подпись

На рисунке 1 показана взаимосвязь между дескрипторами, кучей дескрипторов, таблицами дескрипторов и рутовой подписью.

Код, описываемый на рисунке 1, выглядит так.

// the init function sets the shader registers

// parameters: type of descriptor, num of descriptors, base shader register

// the first descriptor table entry in the root signature in

// image 1 sets shader registers t1, b1, t4, t5

// performance: order from most frequent to least frequent used

D3D12_DESCRIPTOR_RANGE Param0Ranges[3]; 

Param0Ranges[0].Init(D3D12_DESCRIPTOR_RANGE_SRV, 1, 1); // t1 Param0Ranges[1].Init(D3D12_DESCRIPTOR_RANGE_CBV, 1, 1); // b1 Param0Ranges[2].Init(D3D12_DESCRIPTOR_RANGE_SRV, 2, 4); // t4-t5 

// the second descriptor table entry in the root signature

// in image 1 sets shader registers u0 and b2

D3D12_DESCRIPTOR_RANGE Param1Ranges[2]; Param1Ranges[0].Init(D3D12_DESCRIPTOR_RANGE_UAV, 1, 0); // u0 Param1Ranges[1].Init(D3D12_DESCRIPTOR_RANGE_CBV, 1, 2); // b2 

// set the descriptor tables in the root signature

// parameters: number of descriptor ranges, descriptor ranges, visibility

// visibility to all stages allows sharing binding tables

// with all types of shaders

D3D12_ROOT_PARAMETER Param[4]; 

Param[0].InitAsDescriptorTable(3, Param0Ranges, D3D12_SHADER_VISIBILITY_ALL); 

Param[1].InitAsDescriptorTable(2, Param1Ranges, D3D12_SHADER_VISIBILITY_ALL); // root descriptor

Param[2].InitAsShaderResourceView(1, 0); // t0

// root constants

Param[3].InitAsConstants(4, 0); // b0 (4x32-bit constants)

// writing into the command list

cmdList->SetGraphicsRootDescriptorTable(0, [srvGPUHandle]); 

cmdList->SetGraphicsRootDescriptorTable(1, [uavGPUHandle]);

cmdList->SetGraphicsRootConstantBufferView(2, [srvCPUHandle]);

cmdList->SetGraphicsRoot32BitConstants(3, {1,3,3,7}, 0, 4);

Показанный выше исходный код настраивает рутовую подпись таким образом, чтобы у нее было две таблицы дескрипторов, один рутовый дескриптор и одна рутовая константа. Код также показывает, что у рутовых констант нет косвенного обращения, они предоставляются напрямую вызовом SetGraphicsRoot32bitConstants. Они связаны напрямую с регистрами шейдера; нет ни самого буфера констант, ни дескриптора буфера констант, ни привязки. Рутовые дескрипторы имеют только один уровень косвенного обращения, поскольку они хранят указатель на память (дескриптор -> память), а таблицы дескрипторов имеют два уровня косвенного обращения (таблица дескрипторов -> дескриптор -> память).

Дескрипторы находятся в разных кучах в зависимости от их типов, например SV и CBV/SRV/UAV. Это обусловлено очень большими различиями между размерами дескрипторов разных типов на разных аппаратных платформах. Для каждого типа кучи дескрипторов должна быть выделена только одна куча, поскольку изменение кучи может быть крайне ресурсоемкой операцией.

В целом в DirectX 12 поддерживается заблаговременное выделение более одного миллиона дескрипторов, что вполне достаточно для целого игрового уровня. В прежних версиях DirectX выделение ресурсов происходило при работе драйвера на его собственных «условиях», а в DirectX 12 можно вообще избежать выделения ресурсов при выполнении. Это означает, что выделение дескрипторов больше не влияет на производительность.

Примечание. В процессорах Intel^® Core™ 3-го поколения (Ivy Bridge) и 4-го поколения (Haswell) при использовании DirectX 11 и архитектуры драйверов WDDM (Windows Display Driver Model) версии 1.x ресурсы динамически сопоставлялись с памятью на основе ссылок на ресурсы в буфере команд с операцией сопоставления таблицы страниц. За счет этого удавалось избежать копирования данных. Динамическое сопоставление имело большое значение, поскольку эти архитектуры выделяли графическому процессору только 2 ГБ памяти (в семействе процессоров Intel^® Xeon^® E3-1200 v4 (Broadwell) выделялось больше).
В DirectX 12 и WDDM версии 2.x теперь невозможно переназначать ресурсы в виртуальное адресное пространство GPU по мере необходимости, поскольку ресурсам при создании необходимо назначать статический виртуальный адрес и этот виртуальный адрес невозможно изменить после создания. Даже если ресурс вытеснен из памяти GPU, он сохраняет свой виртуальный адрес для более позднего срока, когда он снова становится резидентным.
Поэтому ограничивающим фактором может стать общий объем памяти в 2 ГБ, выделяемый графическому процессору в семействах Ivy Bridge/Haswell.

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

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

Предполагаемые изменения

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

Начнем с так называемых постоянных (константных) данных. В большинстве игр все постоянные данные обычно хранятся в «системной памяти». Игровой движок изменяет данные в памяти, доступной для ЦП, а затем — в кадре. Целый блок постоянных данных копируется или сопоставляется в память GPU, а затем прочитывается графическим процессором с помощью представления буфера констант или рутового дескриптора.

Если постоянные данные предоставляются с помощью SetGraphicsRoot32BitConstants() в качестве рутовой константы, запись в рутовом дескрипторе не изменяется, но данные могут изменяться. Если они предоставляются с помощью дескриптора CBV == и таблицы дескрипторов, то дескриптор не изменяется, но данные могут изменяться.

В случае если нам нужно несколько представлений буфера констант (например, для двойной или тройной буферизации при рендеринге), CBV или дескриптор могут изменяться для каждого кадра в рутовой подписи.

Для данных текстур предполагается выделение памяти GPU при запуске. Затем будет создан дескриптор SV ==, он будет сохранен в таблице дескрипторов или в статическом семплере, и на него будет указывать ссылка в рутовом дескрипторе. После этого данные и дескриптор или статический семплер не изменяются.

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

Если нам нужно несколько целей рендеринга или буферов (например, для двойной или тройной буферизации при рендеринге), дескрипторы могут изменяться для каждого кадра в рутовой подписи.

В дальнейшем обсуждении изменение считается важным для привязки ресурсов, если оно связано со следующим:

• Изменение или замена дескриптора в таблице дескрипторов, например CBV, RTV или UAV.
• Изменение записи в рутовой подписи.

Дескрипторы в таблицах дескрипторов в семействах процессоров Haswell/Broadwell

На платформах Haswell/Broadwell при изменении одной таблицы дескрипторов в рутовой подписи затрачивается столько же ресурсов, сколько при изменении всех таблиц дескрипторов. Изменение одного аргумента приводит к тому, что оборудованию приходится создавать копию (версию) всех текущих аргументов. Количество рутовых параметров в рутовой подписи — это количество данных, для которых оборудованию приходится создавать новую версию (т. е. полную копию) при изменении любого подмножества.

Примечание.Для всех остальных типов памяти в DirectX 12, таких как кучи дескрипторов, ресурсы буферов и т. п., оборудование не создает новые версии.

Другими словами, на изменение всех параметров затрачивается примерно столько же ресурсов, сколько на изменение одного (см. [Лоритцен] и [MSDN]). Меньше всего ресурсов тратится, разумеется, если ничего не изменять, но это бесполезно.

Примечание.На другом оборудовании, где память разделяется на быструю и медленную, хранилище рутовых аргументов (root arguments) будет создавать новую версию только той области памяти, где изменился аргумент, то есть либо быстрой области, либо медленной области.

На платформах Haswell/Broadwell дополнительные затраты на изменение таблиц дескрипторов могут быть обусловлены ограниченным размером таблицы привязки в оборудовании.

Таблицы дескрипторов на этих аппаратных платформах используют аппаратные «таблицы привязки». Каждая запись таблицы привязки является одиночным значением DWORD, которое можно считать смещением в куче дескрипторов. В кольце размером 64 КБ может храниться 16 384 записи таблиц привязки.

Другими словами, объем памяти, потребляемый каждым вызовом отрисовки, зависит от суммарного количества дескрипторов, которые проиндексированы в таблице дескрипторов и на которые указывают ссылки в рутовой подписи.

Если мы исчерпаем 64 КБ памяти для записей таблицы привязки, драйвер выделит еще одну таблицу привязки размером 64 КБ. Переключение между этими таблицами приводит к остановке конвейера, как показано на рисунке 2.

Рисунок 2. Остановка конвейера (рисунок Эндрю Лоритцена)

Предположим, что рутовая подпись ссылается на 64 дескриптора в таблице дескрипторов. Остановка будет происходить через каждые 16 384/64 = 256 вызовов отрисовки.

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

Следовательно, на платформах Haswell/Broadwell желательно, чтобы в таблицах дескрипторов было как можно меньше ссылок на дескрипторы.

Что это означает с точки зрения рендеринга? При использовании большего количества таблиц дескрипторов с меньшим числом дескрипторов в каждой таблице (и, следовательно, при большем количестве рутовых подписей) увеличивается количество объектов состояния конвейера (PSO), поскольку между такими объектами и рутовыми подписями поддерживаются отношения «один к одному».

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

Рутовые константы и дескрипторы в семействах процессоров Haswell/Broadwell

Как было сказано выше, с точки зрения затрачиваемых ресурсов изменение одной таблицы дескрипторов равноценно изменению всех таблиц дескрипторов. Аналогичным образом изменение одной рутовой константы или рутового дескриптора равноценно изменению всех (см. [Лоритцен]).

Рутовые константы реализованы с помощью «вещательных констант», которые представляют собой буфер, используемый оборудованием для заблаговременного заполнения регистров операционных блоков (EU). Поскольку значения доступны сразу же после запуска потока EU, можно добиться повышения производительности, храня постоянные данные в качестве рутовых констант, а не в таблицах дескрипторов.

Рутовые дескрипторы также реализованы с помощью «вещательных констант». Они представляют собой указатели, передаваемые в виде констант шейдерам с чтением данных посредством обычного пути доступа к памяти.

Таблицы дескрипторов и рутовые константы/дескрипторы в семействах процессоров Haswell/Broadwell

Мы рассмотрели реализацию таблиц дескрипторов, рутовых констант и дескрипторов. Теперь можно ответить на основной вопрос этой статьи: «Что предпочтительнее использовать?». В силу ограниченного размера аппаратной таблицы привязки и возможных остановок, связанных с превышением этого ограничения, изменение рутовых констант и рутовых дескрипторов представляется менее ресурсоемкой операцией на платформах Haswell/Broadwell, поскольку им не требуется аппаратная таблица привязки. Наибольший выигрыш при следовании этому принципу достигается в случае, если данные изменяются при каждом вызове отрисовки.

Статические семплеры в семействах процессоров Haswell/Broadwell

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

На платформах Haswell/Broadwell драйвер помещает статические семплеры в обычную кучу семплеров. Это равноценно помещению их в дескрипторы вручную. На других аппаратных платформах семплеры помещаются в регистры шейдера, поэтому статические семплеры можно компилировать непосредственно в шейдер.

В целом статические семплеры обеспечивают высокую производительность на любых платформах, поэтому можно их использовать без каких-либо оговорок. Тем не менее на платформах Haswell/Broadwell существует вероятность, что при увеличении количества дескрипторов в таблице дескрипторов мы будем чаще сталкиваться с остановкой конвейера, поскольку аппаратная таблица дескрипторов содержит только 16 384 ячейки.

Вот синтаксис статического семплера в HLSL.

StaticSampler( sReg,

        [ filter = FILTER_ANISOTROPIC, 

        addressU = TEXTURE_ADDRESS_WRAP,

        addressV = TEXTURE_ADDRESS_WRAP,

        addressW = TEXTURE_ADDRESS_WRAP,

        mipLODBias = 0.f,   maxAnisotropy = 16,

        comparisonFunc = COMPARISON_LESS_EQUAL,

        borderColor = STATIC_BORDER_COLOR_OPAQUE_WHITE,

        minLOD = 0.f, maxLOD = 3.402823466e+38f,

        space = 0, visibility = SHADER_VISIBILITY_ALL ])

Большая часть параметров не нуждается в пояснении, поскольку они аналогичны используемым на уровне C++. Основное различие заключается в цвете границ: на уровне C++ поддерживается полный цветовой диапазон, тогда как на уровне HLSL доступен только непрозрачный белый, непрозрачный черный и прозрачный черный. Пример статического шейдера.

StaticSampler(s4, filter=FILTER_MIN_MAG_MIP_LINEAR)

Skylake

В Skylake поддерживается динамическое индексирование всей кучи дескрипторов (около 1 миллиона ресурсов) в одной таблице дескрипторов. Это означает, что одной таблицы дескрипторов может быть достаточно для индексирования всей доступной памяти кучи дескрипторов.

По сравнению с прежними архитектурами нет необходимости настолько часто изменять записи таблиц дескрипторов в рутовой подписи. Кроме того, можно также уменьшить количество рутовых подписей. Разумеется, для разных материалов потребуются разные шейдеры и, следовательно, разные объекты состояния конвейера (PSO). Но эти объекты PSO могут ссылаться на одни и те же рутовые подписи.

Современные графические движки используют меньше шейдеров, чем предыдущие версии в DirectX 9 и DirectX 11, поэтому можно избежать расходования ресурсов на смену шейдеров и связанных состояний, уменьшить количество рутовых подписей и (соответственным образом) объектов PSO, что обеспечит прирост производительности на любой аппаратной платформе.

Заключение

Если говорить о платформах Haswell/Broadwell и Skylake, то рекомендации по повышению производительности приложений DirectX 12 зависят от используемой платформы. Для Haswell/Broadwell желательно, чтобы количество дескрипторов в таблице дескрипторов было небольшим, тогда как для Skylake рекомендуется, чтобы таблицы дескрипторов содержали как можно больше дескрипторов, но самих таблиц было меньше.

Для достижения оптимальной производительности разработчик приложений может проверять тип аппаратной платформы при запуске, а затем соответственным образом выбирать способ привязки ресурсов. (Пример определения GPU, показывающий, как обнаруживать различную архитектуру оборудования Intel^®, доступен по адресу https://software.intel.com/ru-ru/articles/gpu-detect-sample/.) Выбор способа привязки ресурсов определяет, каким образом будут записаны шейдеры системы.

Об авторе

Вольфганг Энгель — директор компании Confetti. Компания Confetti занимается исследованиями в области графики реального времени и является поставщиком услуг для кинематографии и отрасли компьютерных игр. До организации компании Confetti Вольфганг более 4 лет работал в должности ведущего графического программиста в студии RAGE — основной технологической группе компании Rockstar. Вольфганг — основатель и редактор серий книг ShaderXи GPUPro, обладатель звания Microsoft MVP, автор нескольких книг и статей, посвященных рендерингу в реальном времени. Он регулярно публикует свои материалы на веб-сайтах и проводит выступления на конференциях. Одна из книг, редактором которой он является (ShaderX4), получила в 2006 году премию Game developer Front line. Вольфганг входит в состав нескольких отраслевых консультативных советов, в частности в консультативный совет Майкрософт по графическим решениям DirectX 12. Вольфганг активно участвует в разработке ряда перспективных стандартов для игровой отрасли. Следите за его публикациями в Twitter: wolfgangengel. Веб-сайт Confetti: www.conffx.com.

Благодарности

Благодарю редакторов этой статьи!

• Эндрю Лоритцен (Andrew Lauritzen)
• Робин Грин (Robin Green)
• Михал Валиент (Michal Valient)
• Дин Калвер (Dean Calver)
• Юул Йостен (Juul Joosten)
• Михал Дробот (Michal Drobot)

Ссылки и полезные материалы

• [Лоритцен] Эндрю Лоритцен и др., «Эффективный рендеринг с помощью DirectX 12 на GPU Intel Graphics», GDC, 2015 г.
• [MSDN] MSDN, «Расширенное использование таблиц дескрипторов». https://msdn.microsoft.com/ru-ru/library/windows/desktop/dn859250(v=vs.85).aspx
• Блог Microsoft DirectX: http://blogs.msdn.com/b/directx/
• DirectX 12 в Twitter: @DirectX12. https://twitter.com/DirectX12
• Direct3D* 12 — эффективность и производительность консольных API на ПК (https://software.intel.com/ru-ru/articles/console-api-efficiency-performance-on-pcs)
• Учебные материалы по графике Microsoft DirectX 12 (канал YouTube). https://www.youtube.com/channel/UCiaX2B8XiXR70jaN7NK-FpA

** Программное обеспечение и нагрузки, использованные в тестах производительности, могли быть оптимизированы для достижения высокой производительности на микропроцессорах Intel. Тесты производительности, такие как SYSmark* и MobileMark*, проводятся на определенных компьютерных системах, компонентах, программах, операциях и функциях. Любые изменения любого из этих элементов могут привести к изменению результатов. При выборе приобретаемых продуктов следует обращаться к другой информации и тестам производительности, в том числе к тестам производительности определенного продукта в сочетании с другими продуктами.

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

Введение

Это руководство поможет быстро приступить к использованию Intel^® RealSense™ SDKна компьютере под управлением Windows 10. Разработка классических приложений для Windows 10 практически не отличается от разработки для Windows 8.1. Если вы располагаете опытом создания приложений Intel^® RealSense™ в Windows 8.1, то вы уже знаете большую часть информации, изложенной в этой статье. С другой стороны, если вы недавно начали пользоваться Intel RealSense SDK и работаете на компьютере под управлением Windows 10, этот материал поможет быстрее начать работать над созданием классических приложений с Intel RealSense.

Целевая аудитория

Эта статья содержит вводные сведения об внедрении возможностей Intel RealSense SDK в классические приложения Windows 10 с помощью интегрированной среды разработки Visual Studio 2015. Для понимания этой статьи пригодятся базовые навыки работы в Visual Studio и знание языка программирования C#, а также некоторый практический опыт использования камеры Intel^® RealSense™с помощью примеров приложений, входящих в состав SDK.

Установите Visual Studio 2015

Если исходить из того, что вы приступаете к работе с "чистым"компьютером с Windows 10 (т. е. на него не установлены ни среда разработки, ни пакет SDK), то прежде всего следует установить Visual Studio 2015. Бесплатную версию Visual Studio Community можно загрузить здесь: https://www.visualstudio.com/ru-ru/downloads/download-visual-studio-vs.aspx. Полные инструкции по установке Visual Studio 2015 см. здесь: https://msdn.microsoft.com/ru-ru/library/e2h7fzkw.aspx.

Для примеров кода, описываемых в этой статье, вполне достаточно типовой установки. Тем не менее, для доступа ко всем новым функциям и возможностям Visual Studio 2015 следует выбрать пользовательскую установку и вручную выбрать компоненты, сторонние SDK и расширения, которые следует установить. Впрочем, если вы выберете типовую установку, то все дополнительные компоненты можно будет установить позже, когда вы будете готовы начать работать с ними.

Загрузите и установите программные компоненты Intel^® RealSense™

Для настройки программных компонентов Intel RealSense на компьютере с Windows 10 необходимо загрузить и установить Intel^® RealSense™ Depth Camera Manager (DCM) — это драйвер камеры. Существует две версии DCM: одна для камеры переднего обзора F200, другая для камеры заднего обзора R200.

Загрузить соответствующий пакет DCM для вашей камеры можно здесь: https://software.intel.com/ru-ru/intel-realsense-sdk/download. Затем загрузите пакет Intel RealSense SDK для Windows: https://registrationcenter.intel.com/ru/forms/?productid=2383.

После установки DCM и SDK перезагрузите компьютер. Чтобы убедиться в правильной работе камеры, запустите один из входящих в пакет примеров в диспетчере примеров Intel RealSense SDK. Нажмите в Windows 10 кнопку "Пуск"в левом нижнем углу экрана. Выберите Все приложенияи найдите папку Intel^®RealSense™ SDK (рис. 1).

Рисунок 1.Меню "Пуск"в Windows*

Создание проекта Visual Studio 2015

Для создания проекта Visual Studio 2015 выполните следующие действия.
В нашем примере назовем проект CameraStreams:

• Запустите Visual Studio 2015.
• Выберите в меню File, New, Project…
• На экране New Project разверните Templates и выберите VisualC#.
• Выберите WPF Application.
• Укажите расположение проекта и его имя. В нашем примере проект будет находиться в папке C:\MyRealSenseProjects, а имя проекта — CameraStreams.
• Нажмите кнопку ОК, чтобы создать новый проект.

Проект Visual Studio должен выглядеть так, как показано на рис. 2.

Рисунок 2.Проект CameraStreams в Visual Studio* 2015

Добавление ссылок на библиотеки Intel^® RealSense™ SDK

Для создания приложений Intel RealSense на языке C# требуются две библиотеки динамической компоновки (DLL):

• libpxcclr.cs.dll — управляемая DLL-библиотека интерфейса C#;
• libpxccpp2c.dll — неуправляемая DLL-библиотека C++ P/Invoke.

Добавить нужные библиотеки Intel RealSense SDK в проект можно разными способами. В этом проекте мы создадим ссылки на нужные DLL-библиотеки, находящиеся в папках вне проекта, созданных при установке SDK.

Щелкните правой кнопкой мыши проект CameraStreamsв обозревателе решений, выберите Properties, затем выберите Build Events (рис. 3).

Рисунок 3.Окно "События сборки"

В командной строке событий после сборки введите следующий оператор:

if "$(Platform)" == "x86" ( copy /y "$(RSSDK_DIR)\bin\win32\libpxccpp2c.dll""$(TargetDir)" ) else ( copy /y "$(RSSDK_DIR)\bin\x64\libpxccpp2c.dll""$(TargetDir)" )

В конце процесса сборки показанный выше оператор даст команду Visual Studio на копирование неуправляемой DLL-библиотеки (libpxccpp2c.dll) из соответствующей папки x86 или x64 в пути установки SDK в выходную папку проекта (в зависимости от указанной платформы назначения).

Затем выберите Build в меню слева. В этом примере мы создаем 64-разрядное приложение, поэтому выберите в раскрывающемся списке x64в качестве платформы назначения. Если теперь собрать проект, то библиотека libpxccpp2c.dll появится в выходной папке, например:

C:\MyRealSenseProjects\CameraStreams\CameraStreams\bin\Debug

Теперь нужно добавить ссылку на управляемую DLL-библиотеку (libpxcclr.cs.dll). Согласно документации Intel^® RealSense™ SDK 2015 R4, в Visual Studio есть известное ограничение: одновременная обработка 32-разрядных и 64-разрядных ссылок невозможна, поэтому необходимо явным образом изменить ссылку перед сборкой для другой платформы.

• В обозревателе решений разверните CameraStreamsи щелкните правой кнопкой мыши References.
• Выберите Add References…, затем нажмите кнопку Browse…в правом нижнем углу экрана.
• Перейдите в папку с 64-разрядной библиотекой. Путь к этой папке зависит от того, какая папка RSSDK была выбрана при установке. На рис. 4 показан путь установки к версии x64 библиотеки libpxcclr.cs.dll, использованной в этом примере.
• Нажмите кнопку ОК и добавьте ссылку в проект.

Рисунок 4.Окно диспетчера ссылок

Теперь готова базовая платформа для создания классического приложения для Windows с Intel RealSense SDK. Дополнительные сведения о разработке приложений на C#/WPF см. в следующей статье корпорации Майкрософт*: Руководство: приступая к работе с WPF.

Ознакомьтесь с примерами кода

На портале IDZ доступно несколько примеров кода и ресурсов, демонстрирующих сборку приложений на описанной выше базовой платформе. Вот некоторые вводные статьи и примеры кода, которые можно загрузить для справки.

Камера Intel^® RealSense™ F200

Если вы разрабатываете приложение для камеры переднего обзора F200, прочтите статью, опубликованную ранее в этом году на портале IDZ: Использование Intel^® RealSense™ SDK для создания проекта "Hello World"на C#/WPF. Пример кода, прилагаемый к этой статье, предназначен для Visual Studio 2013, но вы увидите, что можно будет без каких-либо изменений собрать приложение в Visual Studio 2015 под управлением Windows 10.

Камера Intel^® RealSense™ R200

Если вы разрабатываете приложение для камеры заднего обзора R200, то можно загрузить с портала IDZ примеры кода для работы с различными возможностями этой камеры: передача изображения, отслеживание лица, фотографирование с поддержкой глубины (изменение фокусировки по глубине):

• Образец кода для камеры глубины Intel^® RealSense™ — потоки камеры R200
• Образец кода для камеры глубины Intel^® RealSense™ R200 — отслеживание лица
• Образец кода для камеры глубины Intel^® RealSense™ R200 — изменение фокусировки по глубине

Об авторе

Брайан Браун — инженер по разработке программных приложений в подразделении Developer Relations корпорации Intel. 

• Технология Intel^® RealSense™
• Форум
• Intel^® RealSense™ SDK

Загрузить пример кода  [Zip: 19 KB]

Содержание

• Введение
• Структура проекта
• Начало работы
• Требования
• RSNewImageArg.CS
• RSStreaming.CS
  • public event EventHandler<RSNewImageArg> OnStreamingImage
  • public bool Initialized
  • public bool IsStreaming
  • public void StartStreaming()
  • public void StopStreaming ( )
  • private void InitCamera ( )
  • private pxcmStatus OnNewSample( )
  • private void Dispose ( )
• MainForm.CS
  • public MainForm( )
  • private void btnStream_Click( )
  • private void btnStopStream_Click( )
  • private void UpdateColorImageBox( object source, RSNewImageArg e )
  • private void pictureBox_Paint( object sender, PaintEventArgs e )
  • private void btnExit_Click( )
  • private void bMainForm_FormClosing( )
• Заключение
• Об авторе

Введение

Вы задумали создать простое приложение с потоком цветного изображения, использующее камеру Intel^® RealSense™и Intel^® RealSense™ SDK, или просто собираетесь использовать поток цветного изображения в одном из приложений? Вам нужно понятное приложение, простое в отслеживании его работы, действующее напрямую, без огромного объема дополнительного кода, отвлекающего от того, чему вы хотите научиться? В этом случае вам повезло, поскольку именно такого результата я попытался добиться здесь: я старался создать простой, но эффективный пример приложения и документ, описывающий использование камеры и SDK Intel RealSense. 

Этот пример был написан с помощью Intel RealSense SDK R4 и Visual Studio* на языке C#, он был протестирован в выпуске R5.  Для него требуется камера Intel RealSense F200.

Структура проекта

В этом простом приложении я попытался отделить функциональность Intel RealSense SDK от кода уровня графического пользовательского интерфейса Windows* Form, чтобы разработчикам было удобнее сосредоточиться на функциональности SDK, относящейся к поточной передаче изображения.  Для этого я создал на C# класс-оболочку (RSStreaming), заключив в него несколько классов Intel RealSense SDK. 

Приложение Windows Form содержит лишь несколько кнопок и элемент управления PictureBox, в котором отображается поток цветного изображения.

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

Структура проекта опирается на использование событий для передачи данных, вследствие чего можно обойтись без тесных связей. Был создан вспомогательный класс событий RSNewImageArg, наследующий от EventArg. Он используется для публикации текущего кадра из камеры в клиентское приложение.

Начало работы

Для работы потребуется камера Intel RealSense F200. Также требуется Intel RealSense SDK версии R4 или более поздней версии. Помимо этого, на компьютер необходимо установить соответствующий пакет Depth Camera Manager (DCM). SDK и F200 DCM можно загрузить здесь. 

Требования

Требования к оборудованию

• Процессор Intel^® Core™ 4-го поколения (на основе микроархитектуры Haswell).
• 8 ГБ свободного места на жестком диске.
• Камера Intel RealSense F200 (ее необходимо подключить к порту USB 3).

Требования к программному обеспечению

• 64-разрядная версия операционной системы Microsoft Windows 8.1 или Windows 10.
• Microsoft Visual Studio* 2010–2015 с последней версией пакета обновления.
• Microsoft .NET* 4.0 Framework для разработки на C#.
• Unity* 5.x или более поздней версии для разработки игр на движке Unity.

RSNewImageArg.CS

RSNewImageArg является производным от класса C# EventArgs. Как видите, это небольшой класс-оболочка, к которому добавлен один частный элемент данных. Этот частный элемент данных Bitmap _bitMap содержит текущее растровое изображение, извлеченное из потока камеры.

Этот класс используется как аргумент события, когда класс RSStreaming отправляет событие обратно в класс Form, указывая, что новое растровое изображение готово к показу.

RSStreaming.CS

RSStreaming — это класс-оболочка (своего рода «движок») с данными потока цветного изображения из камеры Intel RealSense. Я написал этот класс, преследуя следующие цели.

• Ясно и четко выделить как можно больше функций Intel RealSense SDK и как можно дальше отделить их от клиентского приложения.
• Попытаться предоставить в коде комментарии, чтобы помочь читателю разобраться в том, что именно делает код.

Ниже описываются все функции, входящие в класс RSSpeechEngine.

public event EventHandler<RSNewImageArg> OnStreamingImage

Событие OnStreamingImage служит для переключения сообщения обратно к клиентскому приложению, сообщая ему о том, что новое цветное растровое изображение готово к показу. Клиент создает обработки событий для обработки объекта RSNewImageArg.

public bool Initialized

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

public bool IsStreaming

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

public void StartStreaming()

Проверяет, инициализирован ли класс. Если нет, вызывает InitCamera, чтобы убедиться в том, что класс запущен и работает. Затем эта функция вызывает функцию _senseManager.StreamFrames( … ). 

Если вы успели ознакомиться с достаточным количеством материалов о разработке приложений для Intel RealSense, то, вероятно, вы обратили внимание, что получение данных с камеры зачастую осуществляется в циклах while. Например, приблизительно так.

while (!Stop)

{

   /* Wait until a frame is ready: Synchronized or Asynchronous */

   if (sm.AcquireFrame(Synced).IsError())

      break;

  /* Display images */

   PXCMCapture.Sample sample = sm.QuerySample();

   /* Render streams */

   EventHandler<RenderFrameEventArgs> render = RenderFrame;

   PXCMImage image = null;

   if (MainPanel != PXCMCapture.StreamType.STREAM_TYPE_ANY && render != null)

   {

      image = sample[MainPanel];

      render(this, new RenderFrameEventArgs(0, image));

   }

   if (PIPPanel != PXCMCapture.StreamType.STREAM_TYPE_ANY && render != null)

     render(this, new RenderFrameEventArgs(1, sample[PIPPanel]));

   /* Optional: Set Mirror State */

   mirror = Mirror ? PXCMCapture.Device.MirrorMode.MIRROR_MODE_HORIZONTAL : 

PXCMCapture.Device.MirrorMode.MIRROR_MODE_DISABLED;

   if (mirror != sm.captureManager.device.QueryMirrorMode())

      sm.captureManager.device.SetMirrorMode(mirror);

   sm.ReleaseFrame();

   /* Optional: Show performance tick */

   if (image!=null)

      timer.Tick(PXCMImage.PixelFormatToString(image.info.format)+""+image.info.width+"x"+image.info.height);

}

Да, это солидная порция кода.  Этот код, возможно, делает гораздо больше, чем мой пример приложения, но я всего лишь хочу сказать, что у меня цикл while не используется таким образом. В моем приложении используется функция StreamFrames(…). Эта функция обрабатывает цикл while внутри себя, а для каждого кадра она включает событие, на которое подписывается RSStreamingRGB. Работает это так.

1. Запускаем поток PXCMSenseManager.StreamFrames(…).
2. Ловим событие обработчиком событий.
3. По окончании поточной передачи вызываем PXCMSenseManager.Close( ).

Мне нравится этот подход, потому что не хочется вручную возиться с циклом while, зная, когда и как останавливать цикл. Лучше пусть SDK позаботится об этом вместо меня. Вы увидите, как устроена эта методика, когда я буду рассказывать о функции InitCamera(), поэтому я не стану рассказывать про нее здесь. Просто убедитесь в том, что вы поняли, как можно передавать поток данных и разрешить SDK управлять циклом над необработанными данными, поступающими из камеры.

После вызова StreamFrames я задаю для логического флага _isStreaming значение true, чтобы уведомить класс и клиентское приложение о начале передачи потока.

public void StopStreaming ( )

Остановка передачи потока — действие, противоположное StartStreaming. Эта функция дает команду SDK для остановки передачи потока данных из камеры и вызывает Dispose() для уничтожения объектов данных.   

private void InitCamera ( )

InitCamera() создает экземпляр PXCMSenseManager и включает нужный нам тип потока. Как видите, я указываю поток цветного изображения с разрешением 320 x 240 при скорости 30 кадров в секунду.  

Если помните, я говорил о возможности использовать событие из PXCMSenseManger, чтобы сообщить классу о доступности нового кадра данных цветного изображения available. Для этого используется класс событий PXCMSenseMananger.Handler. Процесс достаточно прост: создаем экземпляр класса Handler, назначаем его обработчику событий через onNewSample, затем инициализируем объект PXCMSenseManager; _senseMananger с классом обработчика.

Затем задаем флагу _initialized значение true. Как было сказано выше, с помощью этого флага мы сообщаем либо этому классу, либо клиентскому приложению о том, что класс RSStreaming инициализирован.

private pxcmStatus OnNewSample( )

Это обработчик событий для объекта PXCMSenseMananger.Handler(). Если помните, в функции InitCamera() я задаю обработчик событий объектов для этой функции.

Обработчик событий должен соответствовать заданной подписи функции.  Функция должна возвращать значение pxcmStatus и принимать два параметра.

• Mid.Идентификатор потока. Если посредством функции EnableVideoStreams запрошено несколько потоков, то это может быть PXCMCapture.CUID+0, PXCMCapture.CUID+1 и т. д.
• Sample. Доступное изображение.

Нужно преобразовать объект PXCMCapture.Sample в пригодное к использованию растровое изображение, которое может быть показано клиентским приложением.

Сначала я проверяю, что объект sample.color не является пустым и что внутреннее растровое изображение класса _colorImageData также не является пустым.  Нужно убедиться в том, что _colorImageData не содержит никаких данных, а если содержит, то их нужно высвободить.

Затем нужно использовать объект sample.colors для заполнения _colorImagedata. Это, по сути, объект метаданных для объекта цветного изображения PXCMCapture.Sample. После этого можно перейти к созданию растрового изображения, указав его размер.

Получив растровое изображение и убедившись в том, что оно не пустое, я включаю событие OnStreamingImage, указывая источник события и новый объект RSNewImageArg.

Наконец, нам НЕОБХОДИМОвысвободить текущий кадр из объекта PXCMSenseMananger, а также, поскольку это требуется подписью функции, возвратить pxcmStatus. В этом месте можно было добавить код для обработки исключений, но я предпочел этого не делать ради простоты. Если бы я написал такой код, то мог бы возвращать другое состояние pxcmStatus, но я просто возвращаю состояние успеха.

private void Dispose ( )

Dispose() выполняет очистку. Я проверяю, что диспетчер не является пустым и что он был инициализирован. Если оба условия выполнены, то я взываю его метод очистки. Я проверяю, что растровое изображение RSStreaming не является пустым, и очищаю его. Затем я везде устанавливаю значение null.

MainForm.CS

Главная форма — это графический пользовательский интерфейс, в котором отображается поток цветного изображения. В нем можно управлять объектом RSStreaming. У него две глобальных переменных: экземпляр RSStreamingRGB и растровое изображение. Растровое изображение будет содержать текущее изображение из текущего кадра, который отправлен классом RSStreamingRGB.

public MainForm( )

Конструктор форм. Он создает новый объект RSSTreamingRGB и предоставляет событию OnStreamingImage обработчик событий.

private void btnStream_Click( )

Обработчик событий при нажатии кнопки Start Streaming. Дает команду объекту _rsStreaming на начало передачи потока путем вызова функции StartStreaming() этого объекта.

private void btnStopStream_Click( )

Обработчик событий при нажатии кнопки Stop Streaming. Дает команду объекту _rsStreaming на остановку передачи потока путем вызова функции StopStreaming() этого объекта.

private void UpdateColorImageBox( object source, RSNewImageArg e )

UpdateColorImageBox — обработчик событий для события _rsStream.OnStreamingImage.  Проверяет, что аргумент newImage не пуст и присваивает в этом случае _currentBitMap новому растровому изображению, используя newImage в качестве источника растрового изображения.

Если не создать новое растровое изображение, то _currentBitMap формы будет указывать на первоначальное растровое изображение, созданное пакетом SDK. Из-за этого могут возникнуть проблемы при вызове метода RSStreaming.Dispose. В клиентской программе имеется рамка рисунка, а в этой рамке отображается изображение, которое берется из SDK. Если при активной форме и рамке рисунка я попробую вызвать RSStreaming.Dispose, высвобождающий ресурсы SDK, то получится аварийный сбой, поскольку удаляется исходное изображение для рамки рисунка.

После назначения нового изображения для _currentBitMap я вызываю pictureBox.Invalidate() и тем самым запускаю событие Paint рамки рисунка.

private void pictureBox_Paint( object sender, PaintEventArgs e )

Это обработчик события Paint рамки рисунка, он переключается вызовом pictureBox.Invalidate(). Он дает команду на перерисовку рамки рисунка с использованием текущего исходного изображения.

Сначала проверяем, что _currentBitMap не пуст, а затем задаем для него наиболее позднее растровое изображение, которое сохраняется в _currentBitMap.

private void btnExit_Click( )

Здесь все элементарно. Просто вызываем Close(). Нет необходимости обрабатывать очистку, поскольку все это происходит в методе MainForm_FormClosing.

private void bMainForm_FormClosing( )

Это событие форм, закрывающее обработчик событий. При вызове метода Close() в любой заданной функции вызывается событие FormClosing. Чтобы не дублировать код, я разместил здесь весь код очистки. Проверяем, что _rsStream не пуст и что идет передача потока. Если эти условия выполнены, то вызываем _rsStream.StopStreaming(). Нет необходимости вызывать метод очистки для _rsStreaming, поскольку все необходимое уже сделано в StopStreaming.

Заключение

Надеюсь, с помощью этой статьи и примера кода вы лучше поняли, как применять Intel RealSense SDK для создания простых приложений с передачей цветного изображения.  Я стремился продемонстрировать, что это можно сделать в простом и понятном приложении: в нем реализованы все элементы, необходимые для успешного создания вашего собственного приложения для передачи цветного изображения.

Если вы считаете, что я что-то упустил или привел недостаточно понятные пояснения в какой-то области, ЛИБО если вы считаете, что можно было добиться нужной цели иным, более правильным способом, то напишите мне по адресу rick.blacker@intel.comили оставьте комментарий к этой статье.

Об авторе

Рик Блэкер (Rick Blacker) — опытный инженер по программному обеспечению, он уже много лет занимается созданием решений для приложений на основе баз данных.  Недавно Рик перешел в команду, занимающуюся технологией Intel RealSense, и помогает пользователям осваивать эту технологию. 

Download Now  Noise.zip

Об образце кода

Образец кода Noise, прилагаемый к этой статье, включает реализацию алгоритма создания шума Перлина, полезного для формирования текстур естественного вида, таких как мрамор или облака, для трехмерной графики. В состав статьи входит тест, в котором используется алгоритм шума Перлина для создания изображения «облака». (Дополнительные сведения об алгоритме шума Перлина см. в разделе «Справочные материалы».) Включены двухмерная и трехмерная версии алгоритма. Это означает, что функции принимают на вход два или три набора данных, чтобы создать одно выходное значение шума Перлина.

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

Введение и мотивация

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

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

Одним из возможных путей решения этой проблемы является заблаговременное вычисление большой таблицы случайных значений. После того каждый из параллельных потоков будет создавать уникальные, но строго определенные индексы на эту таблицу. Например, ядро OpenCL, обрабатывающее изображение, может выбрать вхождение из заранее созданной таблицы, вычислив индекс на основе координат пикселя, который обрабатывается или создается ядром.

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

В функциях уровня ядра OpenCL в образце кода Noise применяется подход, более подходящий к задействованному в OpenCL алгоритму разделения работы на параллельные операции.

Создание шума и случайных чисел для OpenCL

В OpenCL глобальное рабочее пространство (массив рабочих элементов) определяется с помощью одного, двух или трех измерений. Каждый рабочий элемент в этом глобальном пространстве обладает уникальным набором идентифицирующих целочисленных значений, соответствующих координатам по осям X, Y и Z в глобальном пространстве.

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

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

kernel void genRand()

{

               uint          x = get_global_id(0);

               uint          y = get_global_id(1);

               uint          rand_num = ParallelRNG2( x, y );

               ...

Рисунок 1. Пример использования случайных чисел (два измерения)

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

kernel void multi2dNoise( float fScale, float offset )

{

float         fX = fScale * get_global_id(0);

float         fY = fScale * get_global_id(1);

float         fZ = offset;

float         randResult = Noise_3d(  fX,  fY,  fZ );

...

Рисунок 2. Пример использования алгоритма шума Перлина (три измерения)

Ограничения

В функциях Noise_2d и Noise_3d используется один и тот же базовый алгоритм шума Перлина, но различается реализация на основе рекомендаций Перлина. (См. первую ссылку в списке справочных материалов.) В образце Noise только Noise_3d используется в примере noise, а тестовое ядро Noise_2d включено в файл Noise.cl для читателей, желающих изменить этот пример и поэкспериментировать с ним.

Функции Noise_2d и Noise_3d следует вызывать со входными значениями с плавающей запятой. Значения должны охватывать какой-либо диапазон, например (0.0, 128.0), чтобы задать размер «таблицы» (см. рисунок 3) случайных значений. Читателям следует рассмотреть пример с облаками, чтобы понять, как можно преобразовать шум Перлина в разнообразные изображения «естественного вида».

Функция ParallelRNG по умолчанию, используемая в тесте random, предоставляет случайные (и выглядящие таковыми) результаты, но не является самым быстрым алгоритмом генератора случайных чисел. Эта функция построена на основе «хеша Вонга», который изначально не предназначался для использования в качестве генератора случайных чисел. Тем не менее некоторые распространенные функции генераторов случайных чисел (закомментированный пример в файле Noise.cl) показывали видимую повторяемость при заполнении двухмерных изображений, особенно в битах младшего разряда результатов. Читатели могут поэкспериментировать и с другими (более быстрыми) функциями генераторов случайных чисел.

Используемая по умолчанию функция ParallelRNG создает в качестве результатов только 32-битные целые числа без знака. Если требуются значения с плавающей запятой для диапазона, такого как (0.0, 1.0), то приложение должно применить сопоставление для этого диапазона. Образец randomсопоставляет случайный целочисленный результат без знака с диапазоном (0, 255) для создания значений пикселей в оттенках серого. Для этого просто применяется двоичная операция AND, чтобы выбрать 8 бит.

Используемая по умолчанию функция ParallelRNG не будет создавать все 4 294 967 296 (2^32) целочисленных значений без знака для последовательных вызовов на основе созданного ранее значения. Для каждого отдельного начального значения величина псевдослучайных последовательностей (циклов) может составлять от всего 7000 уникальных значений до приблизительно 2 миллиардов значений. Функция ParallelRNG создает около 20 различных циклов. Автор считает маловероятным, что какому-либо рабочему элементу ядра OpenCL может потребоваться больше последовательно созданных случайных чисел, чем образуется в самом маленьком цикле.

Двухмерные и трехмерные версии этой функции —ParallelRNG2 и ParallelRNG3 — используют «смешение» циклов путем применения двоичной операции XOR между результатом предыдущего вызова ParallelRNG и следующим входным значением, из-за чего изменяются длины циклов. Тем не менее такое измененное поведение не подвергалось подробному анализу, поэтому читателю рекомендуется внимательно убедиться в том, что функции ParallelRNG отвечают потребностям приложения.

Структура проекта

В этом разделе приводятся только основные элементы исходного кода образца приложения.

NoiseMain.cpp:

main()
основная входная функция. После разбора параметров командной строки она инициализирует OpenCL, собирает программу OpenCL из файла Noise.cl, подготавливает одно из ядер к запуску и вызывает ExecuteNoiseKernel(), а затем ExecuteNoiseReference(). Проверив, что эти две реализации выдают одинаковые результаты, main()выдает информацию о времени работы каждой из этих функций и сохраняет изображения, получившиеся в результате их работы.

ExecuteNoiseKernel()
Настройка и запуск выбранного ядра Noise в OpenCL.

ExecuteNoiseReference()
Настройка и запуск выбранного эталонного кода Noise на языке C.

Noise.cl:

defaut_perm[256]
Таблица случайных значений 0–255 для ядра трехмерного шума Перлина. Для дополнительного повышения случайности эту таблицу можно сформировать и передать в ядро шума Перлина.

grads2d[16]
16 однородно распределенных единичных векторов, градиенты для ядра двухмерного шума Перлина.

grads3d[16]
16 векторных градиентов для ядра трехмерного шума Перлина.

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

ParallelRNG2()
Генератор случайных чисел, делающий 2 прохода для 2 входных значений.

ParallelRNG3()
Генератор случайных чисел, делающий 3 прохода для 3 входных значений.

weight_poly3(), weight_poly5() и WEIGHT()
Это альтернативные функции веса, используемые алгоритмом шума Перлина для обеспечения непрерывности градиентов. Вторая (предпочитаемая) функция также обеспечивает непрерывность второй производной. Макрос WEIGHTвыбирает, какая функция используется.

NORM256()
Макрос, преобразующий диапазон (0, 255) в (-1.0, 1.0).

interp()
Билинейная интерполяция, использующая OpenCL.

hash_grad_dot2()
Выбирает градиент и вычисляет скалярное произведение со входными значениями XY в составе функции шума Перлина Noise_2d.

Noise_2d()
Генератор шума Перлина с двумя входными значениями.

hash_grad_dot3()
Выбирает градиент и вычисляет скалярное произведение со входными значениями XYZ в составе функции шума Перлина Noise_3d.

Noise_3d()
Генератор шума Перлина с тремя входными значениями.

cloud()
Создает один пиксель «облачного» выходного изображения для CloudTestс помощью Noise_3d.

map256()
Преобразует выходной диапазон шума Перлина (-1.0, 1.0) в диапазон (0, 255), необходимый для получения пикселей в оттенках серого.

CloudTest()
Тест с созданием изображения облака. Параметр sliceпередается в функцию cloud, чтобы код системы мог создавать другие изображения облаков.

Noise2dTest()
Тест Noise_2dне используется по умолчанию.

Noise3dTest()
Тест Noise_3d — функции шума Перлина по умолчанию. Использует map256для получения значений пикселей изображения в оттенках серого.

RandomTest()
Тест ParallelRNG3использует байт младшего разряда целочисленного результата без знака для получения изображения в оттенках серого.

Предоставляются два файла решений Microsoft Visual Studio для Visual Studio версий 2012 и 2013.  Это файлы Noise_2012.sln и Noise_2013.sln.   Если читатель использует более новую версию Visual Studio, должно быть возможно использовать функцию обновления решений и проектов Visual Studio для создания нового решения на основе этих файлов.

В обоих решениях предполагается, что в системе установлен компонент Intel^® OpenCL™ Code Builder.

Управление образцом

Образец можно запустить из командной строки Microsoft Windows* из папки, в которой находится EXE-файл.

Noise.exe<параметры>

Параметры

-hили --help
Отображение справки в командной строке. Демонстрации при этом не запускаются.

-tили --type [ all | cpu | gpu | acc | default |
<константа типа устройства OpenCL>
Выбор типа устройства, для которого запускается ядро OpenCL. Значение по умолчанию: all.

<константа типа устройства OpenCL>

CL_DEVICE_TYPE_ALL | CL_DEVICE_TYPE_CPU | CL_DEVICE_TYPE_GPU |
CL_DEVICE_TYPE_ACCELERATOR | CL_DEVICE_TYPE_DEFAULT

-pили --platform<число или строка> 
Выбор используемой платформы. При запуске демонстрации выводится список всех номеров и названий платформ. Справа от используемой платформы будет указано [Selected]. При использовании строки укажите достаточно букв для уникального распознавания названия платформы. Значение по умолчанию: Intel.

-dили --device<число или строка>
Выбор устройства, на котором выполняются ядра OpenCL, по номеру или имени. При запуске демонстрации выводится список всех номеров и названий устройств на используемой платформе. Справа от текущего устройства будет указано [Selected]. Значение по умолчанию: 0.

-rили --run [ random | perlin | clouds ]
Выбор демонстрации функции для запуска. У генератора случайных чисел, алгоритма шума Перлина и генератора изображения облака есть демонстрационные ядра. Значение по умолчанию: random.

-sили --seed<целое число>
Целочисленное входное значение, в зависимости от которого изменяется результат работы алгоритма. Значение по умолчанию: 1.

Noise.exeвыводит время работы ядра OpenCL и эталонного эквивалентного кода C, а также имена выходных файлов обоих алгоритмов. По завершении вывода информации программа ожидает нажатия пользователем клавиши ВВОД перед выходом. Обратите внимание, что функции эталонного кода на C не были оптимизированы, их цель состоит лишь в проверке правильности кода ядра OpenCL.

Анализ результатов

После завершения работы Noise.exeпросмотрите файлы изображений в формате BMP OutputOpenCL.bmpи OutputReference.bmpв рабочей папке, чтобы сравнить результаты кода OpenCL и C++. Эти два изображения должны быть одинаковыми, хотя возможны весьма незначительные различия между двумя изображениями шума Перлина или между двумя изображениями облаков.

Результат работы алгоритма noise (шум Перлина) должен выглядеть, как показано на рисунке 3.

Рисунок 3. Результат работы алгоритма шума Перлина

Результат работы алгоритма random (генератор случайных чисел) должен выглядеть, как показано на рисунке 4.

Рисунок 4. Результат работы генератора случайных чисел

Результат работы алгоритма cloud (облака) должен выглядеть, как показано на рисунке 5.

Рисунок 5. Результат работы алгоритма создания облаков

Справочные материалы

1. К. Перлин (Perlin, K.) «Улучшение шума». http://mrl.nyu.edu/~perlin/paper445.pdf
2. «Хеширование 4-байтовых целых чисел». http://burtleburtle.net/bob/hash/integer.html
3. М. Овертон (Overton, M. A.), «Быстрые высококачественные параллельные генераторы случайных чисел», веб-сайт Dr. Dobb’s (2011 г.). http://www.drdobbs.com/tools/fast-high-quality-parallel-random-number/229625477
4. Реализация и использование библиотеки цифрового генератора случайных чисел (DRNG) Intel^®. https://software.intel.com/ru-ru/articles/intel-digital-random-number-generator-drng-library-implementation-and-uses?utm_source=Email&utm_medium=IDZ
5. Лицензионное соглашение корпорации Intel на использование образцов исходного кода. https://software.intel.com/ru-ru/articles/intel-sample-source-code-license-agreement/
6. Intel^® OpenCL™ Code Builder.https://software.intel.com/ru-ru/opencl-code-builder

В этом примере используется Intel^® RealSense™ SDK для сканирования лица пользователя и наложения изображения лица на существующую трехмерную модель персонажа. Код написан на C++ и использует DirectX *. Для этого образца требуется пакет Intel^® RealSense™ SDK R5 или более поздней версии, который можно загрузить здесь.

Пример доступен по адресу https://github.com/GameTechDev/FaceMapping.

Сканирование

В SDK WM5 модуль сканирования лиц значительно улучшен. В частности, усовершенствовано следующее.

• Улучшенные данные цвета.
• Повышена однородность сканирования за счет предоставления подсказок, помогающих идеально сориентировать лицо пользователя в начальном положении.
• Данные реперных точек на лице, указывающие на расположение основных черт лица.

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

Реализация сканирования в этом образце помогает пользователю сориентировать лицо в правильное положение с помощью подсказок Intel^® RealSense™ SDK. После выполнения требований по правильному расположению лица в программе становится активной кнопка запуска сканирования.

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

Выходные данные сканирования — это OBJ-файл модели и связанная с ним текстура, которая будет использована на этапе наложения лица в этой программе.

Рисунок 1. Модуль сканирования лица выдает изображение для предварительного просмотра, помогающее пользователю добиться максимального покрытия при сканировании

Рисунок 2. Трехмерное изображение, полученное при сканировании. На изображении справа показаны реперные точки. Обратите внимание, что сканируется только лицо, а не вся голова. Данные цвета берутся из первого кадра сканирования и затем проецируются на трехмерную модель лица. При таком подходе обеспечивается высокое качество цветопередачи, но текстура растягивается по боковым сторонам головы

Наложение изображения лица на трехмерную модель

Вторая часть программы использует данные цвета отсканированного лица пользователя и данные геометрии и накладывает их на существующую модель головы. Задача состоит в том, чтобы создать полную модель головы, используя отсканированное изображение лица. При этом вместо «склейки» отсканированной модели лица с моделью головы выполняется изменение (смещение) геометрии существующей модели головы. Шейдер выполняет смещение вертексов и смешение цветов между моделями головы и лица. Такое смешение можно выполнять либо каждый раз при рендеринге модели головы, либо однократно, с кэшированием результатов. В этом примере программы поддерживаются оба этих подхода.

Описываемая процедура наложения модели лица на модель головы включает следующие основные этапы.

1. Рендеринг отсканированной модели лица с помощью матрицы ортогональной проекции для создания карты смещения и цветовой карты.
2. Создание матрицы для проецирования определенной модели головы на полученные карты смещения и цветов. Эта проекционная матрица учитывает масштабирование и преобразования, заданные с помощью данных реперных точек на лице.
3. Рендеринг модели головы с помощью проекционной матрицы для сопоставления положений вертексов с координатами текстуры на картах смещения и цветов.
4. Применение полученных карт для деформации вершин и раскрашивания пикселей. Смешение между цветовой картой и изначальной текстурой контролируется с помощью карты управления, создаваемой пользователем.
5. (Необязательно.) Можно использовать эти же алгоритмы смещения и смешения для создания модели со смещением и единой полной цветовой текстуры, содержащей все эффекты смешения.

Ресурсы

В этом примере используются следующие графические ресурсы.

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

Карта черт лица.Текстура, наложенная на двухмерную UV-развертку модели головы, влияющую на яркость головы.

Карта деталей.Повторяющаяся текстура, накладывающая дополнительную детализацию на карту черт лица.

Карта передачи цветов.Управляет смешением между двумя базовыми оттенками кожи. Это позволяет накладывать разные оттенки на разные места головы. Например, оттенок щек и ушей может слегка отличаться от оттенка остальной части лица.

Карта управления.Управляет смешением между картой смещения, картой цветов и существующими данными модели головы. Каждый канал карты управления служит собственной цели.

• Канал красного цвета — величина смещения вертексов по оси Z. Если это значение равно нулю, вертекс располагается на модели головы. Если это значение равно единице, то положение вертекса по оси Z изменяется на основе полученной карты смещения. При промежуточных значениях положение изменяется на промежуточную величину.
• Канал зеленого цвета — величина смешения между цветом общей текстуры головы и цветом на полученной цветовой карте. Значение 0 — используется только цвет общей текстуры головы, значение 1 — только цвет лица.
• Канал синего цвета — дополнительный канал для челюстной кости. Его можно использовать вместе с каналом зеленого цвета, чтобы применять к челюстной области лица отдельный цвет вместо цвета общей текстуры головы. Это может быть полезно, если пользователь носит бороду.

Все карты создаются в двухмерном UV-пространстве модели головы.

Рисунок 3. Модель головы, лицо с высокой плотностью мозаичной сетки («тесселяции»). Отсканированное лицо будет извлечено из области высокого разрешения.

Рисунок 4. Карта черт лица (слева) и карта деталей (справа). Карта деталей накладывается на двухмерную UV-развертку модели головы. Наложение повторяется несколько раз для повышения детализации

Рисунок 5. Карта передачи цветов (слева) и карта передачи цветов, наложенная на модель головы (справа). Эта карта определяет интенсивность двух выбранных пользователем цветов кожи

Рисунок 6. Карта управления (слева) и карта управления, наложенная на модель головы (справа). Канал красного цвета — область, которая будет затронута картой смещения. Канал зеленого цвета — область, к которой будет применена отсканированная цветовая карта. Канал синего цвета — челюстная область лица. Использование цветовой карты в челюстной области поможет лучше отобразить отличительные черты этой части лица, например бороду

Карты смещения и цветов

Первый этап в процессе наложения лица — создание карты смещения и цветовой карты на основе отсканированной модели лица. Эти карты создаются путем рендеринга модели лица с помощью матрицы ортогональной проекции. В этой программе используется несколько целей рендеринга для получения карты смещения по глубине и цветовой карты с помощью всего одного вызова отрисовки. Матрица проекции настраивается таким образом, что все лицо полностью помещается в окно проекции.

Рисунок 7. Карты смещения и цветов, созданные из отсканированной модели лица

Матрица проецирования карт

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

Матрица проецирования карт включает перенос и масштабирование.

• Масштабирование.Коэффициент масштабирования вычисляется на основе соотношения расстояния между глазами на отсканированной модели лица (по координатам на проецируемой карте) и на модели головы.
• Перенос.Перенос вертексов вычисляется с помощью данных реперных точек на модели лица и на отсканированной модели лица. При переносе точка, находящаяся ровно посередине между глазами на модели головы, выравнивается с соответствующей точкой на карте смещения. Для вычисления этой средней точки мы используем реперные точки глаз, получаем среднюю точку между ними, а затем преобразуем ее с помощью матрицы ортогональной проекции, которую мы использовали при получении карты смещения и цветовой карты.
• Поворот.В этом примере предполагается, что отсканированная модель лица уже выровнена по осям, ее не требуется поворачивать. Тем не менее в графическом пользовательском интерфейсе предусмотрены элементы управления поворотом для удобства пользователей.

Рисунок 8. Полученная цветовая карта (слева) ортогонально проецируется на модель головы. Карта преобразуется и масштабируется таким образом, чтобы совпали желтые точки привязки между глазами

Рендеринг

В этом примере карта смещения и цветовая карта применяются во время рендеринга в вертексном шейдере и в пиксельном шейдере.

Вертексный шейдер

Вертексный шейдер смещает вдоль оси Z координаты вертексов модели на основе карты смещения. Координаты текстуры карты смещения передаются в пиксельный шейдер, где они используются для получения цветовой карты для смешения цветов.

Этапы работы вертексного шейдера

1. Преобразование положения вертексов матрицей проецирования карт для получения координат текстур на цветовой карте и карте смещения.
2. Получение текстуры карты смещения по вычисленным координатам.
3. Преобразование значения на карте смещения в значение по оси Z в пространстве модели. Диапазон и масштаб карты смещения проходят через постоянный буфер.
4. Смешение между значением смещения по оси Z и исходным значением по оси Z на основе канала красного цвета в карте управления. Карта управления позволяет пользователю выбирать, какие вершины будут смещены, и позволяет применять постепенный плавный переход к смещенному положению.
5. Передача двухмерных UV-координат карты смещения в пиксельный шейдер, где они используются для получения цветовой карты.

Пиксельный шейдер

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

Рисунок 9. Демонстрация смешения на модели головы без применения карты смещения и цветовой карты

Рисунок 10. Конечный результат, полученный в реальном времени с помощью описываемого примера

Экспорт

Используемая методика применяет несколько уровней смешения в пиксельном шейдере, а также изменяет положение вертексов в вертексном шейдере каждый раз при рендеринге модели. В примере также можно экспортировать полученную текстуру и деформированную модель в OBJ-файл.

Весь процесс получения текстуры и деформации модели по-прежнему происходит в ГП с использованием разновидности исходных шейдеров. Новый вертексный шейдер использует поддержку поточного вывода в Direct3D * для записи вершин после деформации. Вертексный шейдер также использует входные координаты текстуры в качестве выходного положения. Благодаря этому отрисовывается новая наложенная двухмерная текстура.

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

Рисунок 11. Экспортированная модель в формате OBJ (слева), составная двухмерная UV-текстура лица, наложенная на двухмерную UV-развертку модели головы

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

Загрузить PDF [PDF 684 KB]
Загрузить образцы кода  [ZIP 25 KB]

Java*-парсер для фотографий с поддержкой глубины обрабатывает файлы изображений в формате XDM (eXtensible Device Metadata)и извлекает метаданные, внедренные в файлы изображений, создавая XML-файлы. Кроме того, это приложение анализирует XML-файлы, извлекая из них данные цветных изображений и данные карт глубины. Это основа для использования фотографий с поддержкой глубины, например для просмотра изображений, изменения глубины резкости, параллакса и измерений.

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

XDM

Сначала мы описываем входные данные для этого приложения: файлы изображений XDM. XDM — стандарт для хранения метаданных в контейнере изображения при сохранении совместимости с существующими программами для просмотра изображений. Этот стандарт предназначен для технологии Intel^® RealSense^TM. Метаданные включают информацию, связанную с устройством: карту глубины, положение устройства и камеры, модель перспективы объектива, данные о постав­щике, облако точек. На следующем рисунке показан пример, где в файле XDM хранится карта глубины (справа) в качестве метаданных вместе с цветным изображением (слева).

Стандарт Adobe XMP *

В настоящее время спецификация XDM поддерживает четыре типа форматов изображений-контейнеров: JPEG, PNG, TIFF и GIF. Метаданные XDM проходят сериализацию и внедряются в файл изображения-контейнера. Формат хранения основывается на стандарте XMP — стандарте расширяемой платформы метаданных Adobe. Это приложение разработано специально для формата JPEG. Затем мы вкратце описываем, как метаданные XMP внедряются в файлы изображений JPEG и как анализатор обрабатывает XMP-пакеты.

В стандарте XMP фрагменты данных обозначаются двухбайтовыми маркерами. Маркеры типа 0xFFE0–0xFFEF обычно используются для данных приложений, они имеют имя вида APPn. Маркер APPnначинается со строки, указывающей назна­чение. Эта строка называется строкой пространства имен или строкой подписи. Маркер APP1указывает метаданные EXIF и TIFF; маркер APP13обозначает ресурсы изображения Photoshop *, содержащие метаданные IPTC, еще один или несколько маркеров APP1обозначают расположение XMP-пакетов.

В следующей таблице показан формат записей в разделе StandardXMP в файлах JPEG.

• 2-байтовый маркер APP1 0xFFE1.
• Длина этого XMP-пакета — 2 байта.
• Стандартное пространство имен StandardXMP (http://ns.adobe.com/xap/1.0/) длиной 29 байт.
• XMP-пакет длиной не более 65 503 байт.

Если размер XMP-пакета после сериализации превышает 64 КБ, то этот пакет может быть разделен на основной сегмент (StandardXMP) и расширенный сегмент (ExtendedXMP), хранящиеся в нескольких указанных маркерами сегментах JPEG. Формат записей в сегменте ExtendedXMP аналогичен сегменту StandardXMP,
но используется другое пространство имен: http://ns.adobe.com/xmp/extension/.

На следующем рисунке показаны сегменты StandardXMP и ExtendedXMP, внедренные в файл изображения JPEG.

Это приложение определяет три класса следующим образом.

1. XDMJavaParser. Это основной класс, который осуществляет анализ изображения XDM, выводит XML-файлы и анализирует XML-файл XMP для вывода цветных изображений и изображений карт глубины.
2. XMLJavaParser. Этот класс анализирует XML-файл XMP.
3. XMLJavaParserHandler. Это класс-обработчик, реализующий анализ
   XML-файла XMP.

В следующем фрагменте кода показаны две функции, использующиеся для анализа XDM-изображения в классе XDMJavaParser.

• findMarker.Анализ JPEG-файла (т. е. буфера), начиная с указанного места (расположение), и поиск маркера 0xFFE1. Если маркер обнаружен, возвращается расположение маркера, если нет, возвращается –1.
• findHeader.Поиск пространства имен StandardXMP (http://ns.adobe.com/xap/1.0/) и пространства имен ExtendedXMP (http://ns.adobe.com/xmp/extension/) в JPEG-файле (т. е. в буфере), начиная с указанного места (расположение). При обнаружении возвращается соответствующее пространство имен, в противном случае возвращается пустая строка.

XML

Метаданные XMP можно внедрять непосредственно в XML-документ ⁴. Согласно спецификации XDM, структура данных XML определяется следующим образом.

Файл изображения содержит следующие элементы, как показано в приведенной выше таблице, в формате RDF/XML. Вот описание общей структуры.

• Изображение-контейнер. Это внешнее изображение (по отношению к XDM), его можно просматривать в приложениях, не поддерживающих XDM.
• Device. Рутовый объект документа RDF/XML согласно стандарту Adobe XMP.
  • Revision — версия спецификации XDM.
  • VendorInfo — информация о производителе устройства.
  • DevicePose — положение устройства по отношению к окружающему миру.
  • Cameras — последовательность RDF одной или нескольких камер.
    • Camera — вся информация для одной камеры. Для получения любых изображений должна быть хотя бы одна камера. Изображение-контейнер сопоставляется с первой камерой, которая считается основной камерой изображения.
      • VendorInfo — информация о производителе камеры.
      • CameraPose — положение камеры по отношению к устройству.
      • Image — изображение, предоставленное камерой.
      • ImagingModel — модель получения изображения (модель объектива).
      • Depthmap — информация о глубине, включая карту глубины и модель шума.
        • NoiseModel — свойства матрицы камеры, касающиеся шума.
      • PointCloud — данные облака точек.

Следующий фрагмент кода является основной функцией этого приложения в классе XDMJavaParser. Он анализирует входной JPEG-файл, пытаясь найти в нем маркер APP1 0xFFE1. Если такой маркер найден, выполняется поиск строк пространств имен StandardXMP и ExtendedXMP. Если найдена первая строка, код вычисляет началь­ную точку и размер метаданных, извлекает метаданные и создает XML-файл StandardXMP. Если найдена вторая строка, код вычисляет начальную точку и размер метаданных, извлекает метаданные и создает XML-файл ExtendedXMP. Приложение выводит два XML-файла.

Следующий фрагмент кода — класс XDMJavaParser, отвечающий за анализ
XML-файла XMP:

Следующий фрагмент кода в классе XMLJavaParserHandler анализирует XML-файл и извлекает цветное изображение и карту глубины для фотографирования с поддержкой глубины. Все работает очень просто. Функция startElement() ищет атрибут с именем IMAGE:DATAи извлекает соответствующие данные, то есть цветное изображение, в JPEG-файл. При обнаружении нескольких атрибутов создается несколько JPEG-файлов. Функция также ищет атрибут с именем DEPTHMAP:DATAи извлекает соответствующие данные, то есть карту глубины, в PNG-файл. При обнаружении нескольких атрибутов создается несколько
 PNG-файлов. На выходе приложения мы получаем JPEG- и PNG-файлы.

Заключение

В этом документе описывается формат файлов XDM, стандарт Adobe XMP и структура данных XML. Анализатор Java для фотографий с поддержкой глубины обрабатывает файлы изображений XDM и выдает XML-файлы StandardXMP и ExtendedXMP. Затем он обрабатывает XML-файлы и извлекает из них файлы цветных изображений и файлы карт глубины. Это приложение не зависит ни от каких других программ. Оно является базовым для различных сценариев использования фотографий с поддержкой глубины.  

Справочные материалы

«Спецификация eXtensible Device Metadata (XDM), версия 1.0»: /ru-ru/articles/the-extensible-device-metadata-xdm-specification-version-10

Технология Intel^® RealSense^TM: http://www.intel.com/content/www/ru/ru/architecture-and-technology/realsense-overview.html

Центр разработки Adobe XMP: http://www.adobe.com/devnet/xmp.html

«Спецификация XML 1.0», консорциум World Wide Web. Получено 22 августа 2010 г.

Использованные компоненты и решения

В этом проекте используется API SAX (http://www.saxproject.org) для XML в Java. Проект SAX не относится к общественному достоянию. Информацию об авторских правах на этот проект см. по следующей ссылке: http://www.saxproject.org/copying.html

Об авторе

Ю Бай (Yu Bai) — инженер по разработке приложений в отделе Intel^® Software and Services Group (SSG). Она работает с внешними независимыми разработчиками программного обеспечения, добиваясь безупречной работы их приложений на платформах Intel^®. До поступления в SSG она работала в компании Rudolph Technologies в качестве старшего инженера по программному обеспечению, занималась разработкой приложений, используемых при работе высокоточного фотолитографического оборудования, используемого в промышленном оборудовании для производства полупроводников. До компании Rudolph она работала в компании Marvell Semiconductor в качестве штатного инженера и занималась анализом электропитания и моделированием электропитания для прикладных процессоров этой компании. Ю перешла в компанию Marvell при приобретении этой компанией технологии Intel^® XScale в 2006 году.

Ю получила учетную степень магистра, а затем и доктора наук в области электротехники и информатики в Университете Брауна. Ее дипломная работа была посвящена проектированию архитектуры компьютеров высокой производительности с низким потреблением электроэнергии. Ю владеет шестью патентами США и опубликовала в журналах и материалах международных конференций более 10 статей, посвященных управлению и оптимизации мощности и электропитания.

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

Моя жена недавно купила довольно толстую и дорогую книгу. Моя жена — врач, специалист по ультразвуковой диагностике детей, она покупает немало книг, но эта книга меня, прямо скажем, озадачила.  Книга называлась «Ультразвуковая анатомия здорового ребенка».  Какой смысл врачу покупать книгу, которая посвящена только здоровым детям?  Я задал этот вопрос жене, и ее ответ был прост: для диагностики у детей любого заболевания, даже если оно еще не выявлено, необходимо знать, как должен работать организм здорового ребенка. 

В этой статье мы будем действовать по схожему принципу: будем анализировать и сравнивать работу хорошо работающего приложения и не очень хорошо работающего.

Тук-тук-тук.

Врач говорит: «Войдите!»

В кабинет заходит наш пациент — игра WarriorWave*, где ваша рука прокладывает путь, по которому должны пройти воины. Играть в нее очень интересно и необычно. В игре используется технология Intel^® RealSense. 

Но в процессе игры что-то было не так.  Что-то, чего не ощущалось в других играх на основе технологии Intel^® RealSense™.  Проблема может быть вызвана разными причинами, но что не так в этомслучае?  

Как и любой уважающий себя врач, располагающий самыми современными и точными средствами для диагностики, мы располагаем идеальными инструментами для анализа нашего «пациента».

Используя средство Platform Analyzer в составе Intel^® Graphics Performance Analyzer (Intel^® GPA)мы получаем временное представление нагрузки на ЦП, времени создания каждого кадра, кадровой скорости и вызовов отрисовки:

Давайте посмотрим.

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

Для сравнения посмотрим на график кадровой скорости в другой, правильно работающей игре. В этой игре все очень гладко, в нее было приятно играть.  

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

Но в нашем случае явно наблюдаются регулярные скачки. Они происходят примерно 4 раза в секунду.  Давайте изучим проблему подробнее, увеличив один из таких скачков, и посмотрим, что при этом происходит в потоках:

Мы видим, что рабочий поток 2780 тратит большую часть времени на синхронизацию. Этот поток практически ничего не делает, только дожидается следующего кадра из Intel^® RealSense™ SDK:

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

Вместо того, чтобы «активно» ждать следующего кадра от Intel RealSense SDK, игра могла бы делать что-нибудь полезное. Отрисовку и ожидание Intel^® RealSense™ SDK можно было бы поместить в один рабочий поток вместо двух, что упростило бы обмен данными между потоками.

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

Вот пример правильно устроенной игры, в которой работа Intel^® RealSense™ SDK и вызовы DirectX* находятся в одном и том же потоке. 

Специалисты по RealSense™ заявляют, что нет смысла ждать кадры из Intel^® RealSense™ SDK. От этого они не будут появляться быстрее. 

При этом мы видим, что основная проблема находится в верхней части временной шкалы.

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

Теперь перейдем к конвейеру и попробуем разобраться, как идет выполнение кода.  Посмотрите на количество пакетов в Engine 0: конвейер заполнен до краев, но очередь выполнения почти пуста.

Человеческий мозг может обрабатывать до 10–12 изображений в секунду по отдельности. Это поясняет, почему при съемке самых первых кинофильмов пленка протягивалась со скоростью 16 кадров в секунду: это средний порог, после которого большинство людей перестают воспринимать картинку на экране как отдельные изображения и начинают видеть фильм.

Снова посмотрим на профиль правильно работающей игры: 

Обратите внимание, что кадры ГП следуют за кадрами ЦП с небольшим сдвигом. Для каждого кадра ЦП есть соответствующий кадр ГП, выполнение которого начинается после небольшой задержки.

Давайте попробуем понять, почему в нашей игре это не так.

Сначала рассмотрим вызовы DirectX*. Выделенный вызов со всплывающей подсказкой — это наш вызов Present, отправляющий готовый кадр в ГП. На приведенном выше снимке экрана видно, что он создает пакет Present в конвейере ГП (помеченный крестиками).  На отметке 2215 мс он переместился ближе к выполнению, перескочив через три позиции, но на отметке 2231 мс он просто исчез, не завершив выполнение.

Если рассмотреть все вызовы Present в трассировке, окажется, что ни один из них не достиг успешного выполнения.

Вопрос: каким же образом изображение игры вообще появляется на экране, если все вызовы DirectX* Present пропадают?! Хорошо, что у нас есть удобные инструменты, позволяющие получить ответ на этот вопрос. Давайте посмотрим.

Видите нечто любопытное внутри серого овала? Мы видим, что этот пакет, возникший вне всякой связи с какими-либо вызовами DirectX* в нашем коде, все же добирается до выполнения, быстро и без видимого порядка. Минутку, постойте!

Давайте поподробнее изучим наш пакет. 

А теперь — пакет, который все-таки был выполнен. 

Ага! Он появился из ВНЕШНЕГО потока. Что это может означать? Внешние потоки — это потоки, не принадлежащие к игре.

Итак, наши собственные пакеты пропадают, но зато какой-то внешний поток выводит на экран нашу игру? Как это вообще возможно? Может быть, наша программа Platform Analyzer выдает какую-то чепуху?

Нет, на изображении все верно. А объясняется весь этот цирк следующим образом: в системах Windows* (начиная с Windows Vista*) существует программа под названием «диспетчер окон рабочего стола» (DWM), которая и отвечает за фактический вывод изображения на экран. Это пакеты DWM выполнялись быстро и вне очереди, с высоким приоритетом.  А наши пакеты вовсе не пропадали: диспетчер окон рабочего стола перехватывал их для создания итогового изображения.

Но почему диспетчер окон рабочего стола вмешался в работу полноэкранной игры? Подумав, я понял, что ответ прост: к моему компьютеру подключено два монитора. Достаточно было отключить второй монитор из схемы, и все встало на свои места: игра WarriorWaveзаработала точно так же, как все приличные игры: нормальная кадровая скорость ГП, никаких скачков, никаких пакетов DWM.

Пациент будет жить! Хорошая новость!

Но ведь другие игры вполне хорошо работали и в конфигурации с двумя мониторами, не так ли?

Чтобы изучить проблему подробнее, нужен другой инструмент. Intel^® GPA Platform Analyzer позволяет отслеживать работу ЦП и ГП по времени, но не дает возможности подробно изучать каждый кадр.

Следует более внимательно рассмотреть код создания Direct3D* Device. Для этого можно использовать Intel^® GPA Frame Analyzer для DirectX*, но это уже материал для другой статьи.

Итак, подведем итоги.

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

Заключение: Intel^® GPA Platform Analyzer — очень полезный инструмент для анализа проблем на начальном этапе. Изучите его и используйте его.

Об авторе

Александр Рауд (Alexander Raud) работает в команде Intel^® Graphics Performance Analyzers в России, ранее он работал над программой VTune Amplifier. У Александра двойное гражданство России и Евросоюза, он говорит по-русски, по-английски и немного по-французски, а также изучает испанский язык.  Александр женат, у него двое детей, но, несмотря на это, он находит время, чтобы профессионально играть прогрессивный металл в составе рок-группы и руководить международной миссионерской организацией церкви «Дом Божий».

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

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

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

OpenCL и эмблема OpenCL являются товарными знаками Apple Inc. и используются с разрешения Kronos.

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

Загрузить[PDF 343KB]
Загрузить[ZIP 59KB]

Введение

Образец приложения для работы с камерами — это программа, которая обнаруживает и отображает информацию и подробные характеристики всех камер, которые установлены на устройстве с Android *. Зачастую может быть непросто найти технические характеристики (например, количество мегапикселей матрицы, поддерживаемые форматы изображения, режимы работы вспышки) встроенных камер на устройствах, которые не слишком вам привычны. Многие характеристики камер (режимы работы автоматического замера экспозиции, режимы баланса белого, характеристики светочувствительной матрицы) порой и вовсе не удается отыскать. Тем не менее все эти характеристики, да и многие другие, доступны с помощью API платформы Android. В этом образце также демонстрируется использование платформы для доступа к этой информации, преобразования ее в нужный формат и упорядочения для отображения пользователям, чтобы можно было с легкостью узнавать возможности камер, доступных на устройстве.

Поддержка платформы KitKat *

После выпуска платформы KitKat сменилось уже почти два поколения Android, но устройства на основе Android KitKat по-прежнему составляют большинство используемых устройств Android. В архитектуре KitKat и в предыдущих архитектурах для получения информации о камерах и их характеристиках используется иной, более ограниченный метод. В этом образце приложения поддерживается устаревший API KitKat и демонстрируется сбор доступной информации о камерах на устройстве с этой версией Android.

API Camera2 и Lollipop *

В версии Android Lollipop был существенно изменен способ доступа к камерам, их настройки и управления ими. Новая архитектура работы с камерами, известная как API Camera2, включает новый асинхронный конвейер, системную службу Camera Manager и богатейший набор информации о камерах. Этот образец приложения демонстрирует использование Camera Manager для получения технических характеристик и полной подробной информации о всех камерах, которыми оснащено устройство.

Поддержка платформы Marshmallow *

В новой версии Android Marshmallow будет продолжена поддержка API Camera2 API, включая и всю доступную ранее информацию о камерах. При этом также добавлены некоторые дополнительные характеристика камер для специализированных режимов использования. На устройствах с Android Marshmallow доступны новые поля данных (такие как возможность встроенной калибровки, режимы затенения и блокировка автоматической экспозиции). В описываемом образце приложения поддерживаются все эти новые данные.

Заключение

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

Загрузить демонстрационные файлы ZIP 35KB

TouchDesigner* компании Derivative* — популярная платформа и программа, используемая во всем мире для создания интерактивных решений и анимации реального времени в ходе выступлений, а также для отображения трехмерной анимации, создания карт и схем, а также с недавнего времени в системах виртуальной реальности. Благодаря поддержке камеры Intel^® RealSense™ TouchDesigner* становится еще более многоцелевым и мощным средством. Следует отметить и возможность импортировать в TouchDesigner* объекты и анимацию из других трехмерных пакетов с помощью файлов .fbx, а также возможность работать с уже рендеринговыми анимационными роликами и изображениями.

В этой статье, состоящей из двух частей, я расскажу об интеграции камеры Intel^® RealSense™ в TouchDesigner* и о возможностях ее использования. В демонстрациях в первой части используется камера Intel^® RealSense™ с узлами TOP. В демонстрациях во второй части используются узлы CHOP. Во второй части также поясняется создание последовательностей виртуальной реальности и полукруглых панорам с использованием камеры Intel^® RealSense™. Я покажу, как использовать TouchDesigner* Oculus Rift вместе с камерой Intel^® RealSense™. Обе части включают анимации и загружаемые файлы TouchDesigner* (.toe), которые можно использовать для просмотра. Для получения файлов TouchDesigner* (.toe) нажмите кнопку в верхней части этой статьи. Кроме того, доступна бесплатная копия TouchDesigner* для некоммерческого использования. Она полностью функциональна (за исключением того, что максимальное разрешение ограничено значением 1280 на 1280).

Примечание.В настоящее время существует два типа камер Intel^® RealSense™: камера ближнего обзора F200и камера дальнего обзора R200. Благодаря своему сверхкомпактному размеру камера R200 очень удобна для выступлений и других сценариев использования, когда камера должна быть скрытой. В отличие от более крупной модели F200 камера R200 не поддерживает отслеживание рук и пальцев, а также отслеживание маркеров. TouchDesigner* поддерживает обе модели камер Intel^® RealSense™: и F200, и R200.

Цитирую веб-страницу TouchDesigner*: «TouchDesigner* — это революционная программная платформа, дающая возможность художникам и дизайнерам работать с материалами в открытой свободной среде. TouchDesigner* — идеальное решение для интерактивных мультимедиапроектов, использующих видео, звук, трехмерную графику, ввод с помощью контроллеров, Интернет и базы данных, источники света DMX, датчики окружающей среды и вообще все, что только можно вообразить. Это мощная среда для смешения всех названных элементов бесконечным числом способов».

Я попросил Малькольма Бечарда, старшего разработчика Derivative, высказаться по поводу использования камеры Intel^® RealSense™ с TouchDesigner*:

«Благодаря процедурной архитектуре TouchDesigner* на основе узлов данные камеры Intel^® RealSense™ можно немедленно получать, визуализировать, затем передавать на другие узлы, не тратя времени на написание кода. Можно быстро создавать прототипы идей и вести разработку с мгновенной обратной связью. Камера представлена узлом в TouchDesigner*, а это означает, что нет необходимости закрывать и перекомпилировать приложение на каждой итерации разработки. Камера Intel^® RealSense™ дополняет возможности TouchDesigner*, предоставляя пользователям значительное количество готовых модулей, таких как жесты, отслеживание рук, отслеживание лица, данные глубины. Все это можно использовать для взаимодействия. Нет необходимости применять низкоуровневый анализ данных о положении рук для распознавания жестов: это уже сделано».

Использование камеры Intel^® RealSense™ в TouchDesigner*

TouchDesigner* — программа и платформа на основе узлов, использующая Python* в качестве основного языка сценариев. Существует пять категорий узлов, выполняющих разные операции и обладающих разными функциями: узлы TOP (текстуры), SOP (геометрия), CHOP (анимация и звук), DAT (таблицы и текст), COMP (трехмерные геометрические узлы, а также узлы для создания двухмерных панелей управления) и MAT (материалы). Программисты компании TouchDesigner*, посоветовавшись с разработчиками Intel^®, создали два особых узла, узел камеры Intel^® RealSense™ TOP и узел камеры Intel^® RealSense™ CHOP для интеграции камеры Intel^® RealSense™ в программу.

Примечание.Эта статья предназначена для пользователей, уже знакомых с программой TouchDesigner* и с ее интерфейсом. Если у вас нет опыта работы с TouchDesigner* и вы собираетесь постепенно разбираться в этой статье, то рекомендую сначала просмотреть документацию, доступную здесь:

Изучение TouchDesigner*

Примечание.При использовании камеры Intel^® RealSense™ для достижения оптимальных результатов следует учитывать дальность. На этой веб-странице Intel^®указана дальность всех моделей камер и даны рекомендации по использованию камер.

Узел камеры Intel^® RealSense™ TOP

Узлы TOP в TouchDesigner* выполняют множество операций, обычно содержащихся в программах для композиции изображений. Узел камеры Intel^® RealSense™ TOP дополняет эти возможности за счет двухмерных и трехмерных данных, поступающих от камеры Intel^® RealSense™. Узел камеры Intel^® RealSense™ TOP содержит ряд настроекдля получения разных видов данных.

• Цвет.Видео с датчика цвета камеры Intel^® RealSense™.
• Глубина.Вычисленная глубина каждого пикселя. 0 означает, что пиксель находится на расстоянии 0 метров от камеры, 1 означает, что пиксель находится на максимально возможном расстоянии или дальше.
• Необработанная глубина.Значения берутся непосредственно из Intel^® RealSense™ SDK. И вновь 0 означает 1 метр от камеры, 1 означает, что пиксель находится на максимально возможном расстоянии или дальше.
• Наглядная глубина. Изображение Intel^® RealSense™ SDK в оттенках серого, позволяющее наглядно представить глубину. Его невозможно использовать для фактического вычисления точного расстояния каждого пикселя до камеры.
• Отображение глубины на цветной UV-карте. Значения UV из 32-разрядной плавающей текстуры RG (обратите внимание, что в ней только два цвета (красный и зеленый), а синего цвета нет), необходимые для выравнивания изображения глубины в соответствии с цветным изображением. Для выравнивания изображений можно использовать узел TOP Remap.
• Отображение цвета на UV-карте глубины.Значения UV из 32-разрядной плавающей текстуры RG (обратите внимание, что в ней только два цвета (красный и зеленый), а синего цвета нет), необходимые для выравнивания изображения цвета в соответствии с изображением глубины. Для выравнивания изображений можно использовать узел TOP Remap.
• Инфракрасное изображение.Необработанное видео инфракрасного датчика камеры Intel^® RealSense™.
• Облако точек. Это в буквальном смысле облако точек в трехмерном пространстве (с координатами X, Y, Z) или точек данных, созданных сканером камеры Intel^® RealSense™.
• UV-карта цветов облака точек. Можно использовать для получения цвета каждой точки из потока цветного изображения.

Примечание.Можно загрузить этот файл RealSensePointCloudForArticle.toeдля использования в качестве простого начального шаблона для создания трехмерной анимированной геометрии из данных камеры Intel^® RealSense™. Этот файл можно изменять разными способами. Вместе три узла TOP камеры Intel^® RealSense™ — Point Cloud, Color и Point Cloud Color UV — позволяют создать трехмерную геометрию из точек (частиц) с наложением цветного изображения. Это открывает множество интересных возможностей.

Узел CHOP камеры Intel RealSense

Примечание.Существует еще один узел CHOP камеры Intel^® RealSense™, отвечающий за данные трехмерного отслеживания и положения. Мы обсудим его во второй части этой статьи.

Демонстрация 1. Использование узла камеры Intel^® RealSense™ TOP

Для получения первой демонстрации TOP нажмите кнопку в верхней части статьи: settingUpRealNode2b_FINAL.toe.

Демонстрация 1, часть 1. Вы узнаете, как настраивать узел камеры Intel^® RealSense™ TOP и соединять его с другими узлами TOP.

1. Откройте диалоговое окно AddOperator/OPCreate.
2. В разделе TOP щелкните RealSense.
3. На странице параметров Setupузла камеры Intel^® RealSense™ TOP для параметра Image выберите значение Colorв раскрывающемся меню. В узле камеры Intel^® RealSense™ TOP отображается изображение того, на что направлена камера, как при использовании обычной видеокамеры.

1. Задайте для камеры Intel^® RealSense™ разрешение 1920 на 1080.
    

4. На странице параметров Render узла Geo COMP добавьте тип phong1к параметру Material, чтобы использовать узел phong1в качестве материала.

  

Анимация и создание экземпляров геометрии узла Box

Демонстрация 1, часть 4.Вы узнаете, как поворачивать узел Geometry SOP с помощью узла Transform SOP и простого выражения. Затем вы узнаете, как создавать экземпляры геометрии узла Box. В результате мы получим экран с множеством вращающихся кубов, на каждом из которых будут текстуры из узла камеры Intel^® RealSense™ TOP.

1. Для анимации вращения куба вокруг оси X вставьте узел Transform SOP после узла Texture SOP.

1. Поместите выражение в компонент X (первое поле) параметра Rotate в узле transform1 SOP. Это выражение не зависит от кадров, оно будет продолжать работать и не начнет повторяться по окончании кадров на временной шкале. Я умножил значение на 10, чтобы увеличить скорость: absTime.seconds*10
    

2. Заполните параметры TX, TY и TZ, используя соответственно P(0), P(1) и P(2), чтобы указать, какие столбцы из узла sopto1использовать для положений экземпляров.
   
   
    

3. 
   

Рендеринг и анимация в реальном времени

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

1. Для рендеринга проекта добавьте узлы Camera COMP, Light COMP и Render TOP. По умолчанию камера выполняет рендеринг всех компонентов геометрии на сцене.
2. Отведите камеру назад примерно на 20 единиц по оси Z. Для освещения оставьте значения по умолчанию.
3. Задайте разрешение рендеринга 1920 на 1080. По умолчанию фон рендеринга является прозрачным (значение альфа равно 0).
4. Чтобы сделать фон непрозрачным черным, добавьте узел Constant TOP и измените значение параметра Color на 0,0,0, чтобы задать черный цвет, указав для параметра Alpha значение 1. Можно выбрать любой другой цвет.
5. Добавьте узел Over TOP и соедините узел Render TOP с первым подключением, а узел Constant TOP — со вторым. При этом пиксели фона получат значение (0, 0, 0, 1), то есть перестанут быть прозрачными.

Еще один способ изменить значение прозрачности TOP на 1 — использовать узел Reorder TOP и задать для его параметра Output Alpha значения Input 1и One.

Демонстрация 2. Использование данных глубины узла камеры Intel^® RealSense™ TOP

Узел камеры Intel^® RealSense™ TOP содержит ряд других настроек для создания текстур и анимации.

В демонстрации 2 мы используем данные глубины для применения размытия к изображению на основе полученных от камеры данных глубины. Для получения этого файла нажмите кнопку в верхней части статьи: RealSenseDepthBlur.toe.

Сначала создайте узел камеры Intel^® RealSense™ TOP и задайте для параметра Image значение Depth. Изображение глубины содержит пиксели со значением 0 (черные), если они близко к камере, и со значением 1 (белые), если они далеко от камеры. Диапазон значений пикселей определяется параметром Max Depth, его значение указывается в метрах. По умолчанию этот параметр имеет значение 5. Это означает, что пиксели, находящиеся на расстоянии 5 метров от камеры (или дальше), будут белыми. Пиксели со значением 0,5 находятся на расстоянии 2,5 м от камеры. В зависимости от фактического расстояния между камерой и вами имеет смысл изменить это значение на меньшее. В этом примере мы изменили значение данного параметра на 1,5 м.

Затем нужно обработать глубину, чтобы удалить объекты, находящиеся за пределами интересующей нас дальности. Для этого мы используем узел Threshold TOP.

1. Создайте узел Threshold TOP и соедините его с узлом realsense1. Нужно убрать все пиксели, находящиеся дальше определенного расстояния от камеры, поэтому задайте для параметра Comparator значение Greater, а для параметра Threshold — значение 0.8.При этом пиксели со значением больше 0,8 (что соответствует расстоянию 1,2 м или более, если для параметра Max Depth в узле камеры Intel^® RealSense™ TOP задано значение 1,5) станут равными 0, а все остальные пиксели — равными 1.
    

2. Создайте узел Multiply TOP, соедините узел realsense1с первым входом, а узел thresh1 — со вторым входом. При умножении пикселей на 1 они останутся в неизменном виде, а при умножении других пикселей на 0 они будут обнулены. Теперь узел multiply1содержит только пиксели больше 0 для той части изображения, на которой нужно сделать размытие, чем мы сейчас и займемся.
3. Создайте узел Movie File в TOP и выберите новое изображение для параметра File. В этом примере мы выбираем Metter2.jpg из папки TouchDesigner* Samples/Map.
4. Создайте узел Luma Blur TOP и соедините moviefilein1с первым входом lumablur1, а multiply1 — со вторым входом lumablur1.
5. В параметрах lumablur1задайте для параметра White Value значение 0.4, для параметра Black Filter Width значение 20, а для параметра White Filter Width — значение 1. Благодаря этому у пикселей со значением первого входа 0будет ширина фильтра размытия 20, а у пикселей со значением 0.4или больше — ширина размытия 1.
    

Overview

Обзор

Пакет Data Plane Development Kit (DPDK) предоставляет высокопроизводительные библиотеки обработки пакетов и драйверы пользовательского пространства. Начиная с Open vSwitch (OVS) версии 2.4 (http://openvswitch.org/releases/NEWS-2.4.0)мы имеем возможность использовать оптимизированный с помощью DPDK путь vHost в OVS. Поддержка DPDK была доступна OVS с версии 2.2.

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

Кроме того, с помощью библиотек обработки пакетов DPDK была оптимизирована производительность некоторых наиболее важных сегментов OVS. Например, план пересылки оптимизирован для запуска в пользовательском пространстве в виде отдельных потоков процесса vswitch (vswitchd). Реализация оптимизированных с помощью DPDK гостевых интерфейсов vHost обеспечивает высокую производительность при передаче данных с виртуальных машин (ВМ) на ВМ или с ВМ на физический ПК.

В этом документе мы рассмотрим настройку OVS с DPDK для использования между виртуальными машинами. В частности, мы создадим мост OVS vSwitch c двумя портами DPDK vhost-user. Каждый порт будет подключен к отдельной виртуальной машине. Затем мы запустим простой тест пропускной способности iperf3 для анализа производительности. Мы сравним производительность с работой конфигурации OVS без DPDK, чтобы оценить, какие преимущества мы получаем в OVS с DPDK.

Open vSwitch можно установить с помощью стандартных установщиков пакетов в распространенных дистрибутивах Linux*. Поддержка DPDK по умолчанию не включена, поэтому перед дальнейшими действиями нужно собрать Open vSwitch с DPDK.

Подробные инструкции по установке и использованию OVS с DPDK см. по адресу https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK.md. В этом документе мы рассмотрим основные действия и, в частности, сценарий использования пользовательских портов DPDK vhost-user.

Требования для OVSи DPDK

Перед компиляцией DPDK и OVS убедитесь, что выполняются все необходимые требования:

http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#compilation-of-the-dpdk

Пакеты средств разработки в стандартных дистрибутивах Linux обычно отвечают большей части таких требований.

Например, в дистрибутивах на базе yum (или на базе dnf) можно использовать следующую команду для установки:

yum install "@Development Tools" automake tunctl kernel-tools "@Virtualization Platform""@Virtualization" pciutils hwloc numactl

Кроме того, убедитесь, что в системе установлен компонент qemu версии v2.2.0 или более поздней согласно указаниям в документе "DPDK vhost-user Prerequisites"по ссылке https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK.md

Сборка целевой среды DPDKдля OVS

Чтобы собрать OVS с DPDK, нужно загрузить исходный код DPDK и подготовить среду назначения. Дополнительные сведения об использовании DPDK см. по адресу http://www.dpdk.org/doc/guides/linux_gsg/index.html. Основные действия показаны в следующем фрагменте кода:

curl -O http://dpdk.org/browse/dpdk/snapshot/dpdk-2.1.0.tar.gz

tar -xvzf dpdk-2.1.0.tar.gz

cd dpdk-2.1.0

export DPDK_DIR=`pwd`

sed 's/CONFIG_RTE_BUILD_COMBINE_LIBS=n/CONFIG_RTE_BUILD_COMBINE_LIBS=y/' -i config/common_linuxapp

make install T=x86_64-ivshmem-linuxapp-gcc

cd x86_64-ivshmem-linuxapp-gcc

EXTRA_CFLAGS="-g -Ofast" make -j10

Сборка OVSс DPDK

При наличии собранной среды назначения DPDK можно загрузить последние версии исходного кода OVS и выполнить сборку с включенной поддержкой DPDK. Стандартная документация для сборки OVS с DPDK доступна по адресу https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK.md. Здесь мы рассмотрим только основные шаги.

git clone https://github.com/openvswitch/ovs.git

cd ovs

export OVS_DIR=`pwd`

./boot.sh

./configure --with-dpdk="$DPDK_DIR/x86_64-ivshmem-linuxapp-gcc/" CFLAGS="-g -Ofast"

make 'CFLAGS=-g -Ofast -march=native' -j10

Итак, мы располагаем полной собранной OVS с включенной поддержкой DPDK. Все стандартные служебные программы OVS находятся в папке $OVS_DIR/utilities/, а база данных OVS — в папке$OVS_DIR/ovsdb/. Мы используем эти служебные программы в дальнейших действиях.

Создайте базу данных OVSи запустите ovsdb-server

Перед запуском основного процесса OVS "ovs-vswitchd"нужно инициализировать базу данных OVS и запустить ovsdb-server. Следующие команды показывают, как очистить и создать новую базу данных OVS и экземпляр ovsdb_server.

pkill -9 ovs

rm -rf /usr/local/var/run/openvswitch

rm -rf /usr/local/etc/openvswitch/

rm -f /usr/local/etc/openvswitch/conf.db

mkdir -p /usr/local/etc/openvswitch

mkdir -p /usr/local/var/run/openvswitch

cd $OVS_DIR

./ovsdb/ovsdb-tool create /usr/local/etc/openvswitch/conf.db ./vswitchd/vswitch.ovsschema

./ovsdb/ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach

./utilities/ovs-vsctl --no-wait init

Настройка хоста и сетевых адаптеров для использования OVSс DPDK

Для DPDK требуется, чтобы операционная система хоста поддерживала сверхкрупные страницы памяти, а для сетевых адаптеров должны быть включены драйверы опрашиваемого режима (PMD) пользовательского пространства DPDK.

Для включения сверхкрупных страниц памяти и использования драйвера пользовательского пространства VFIO добавьте приведенные ниже параметры в GRUB_CMDLINE_LINUX в /etc/default/grub, затем запустите обновление grub и перезагрузите систему:

default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M hugepages=2048 iommu=pt intel_iommu=on isolcpus=1-13,15-27

grub2-mkconfig -o /boot/grub2/grub.cfg

reboot

В зависимости от объема доступной памяти в системе можно настроить количество и тип сверхкрупных страниц. Параметр isolcpusпозволяет изолировать определенные ЦП от планировщика Linux, поэтому за ними можно будет "закрепить"приложения на основе DPDK.

После перезагрузки системы проверьте командную строку ядра и выделенные сверхкрупные страницы, как показано ниже.

Теперь следует подключить файловую систему сверхкрупных страниц и загрузить драйвер пользовательского пространства vfio-pci.

mkdir -p /mnt/huge

mkdir -p /mnt/huge_2mb

mount -t hugetlbfs hugetlbfs /mnt/huge

mount -t hugetlbfs none /mnt/huge_2mb -o pagesize=2MB

modprobe vfio-pci

cp $DPDK_DIR/tools/dpdk_nic_bind.py /usr/bin/.

dpdk_nic_bind.py --status

dpdk_nic_bind.py --bind=vfio-pci 05:00.1

На следующем снимке экрана показан пример выходных данных для указанных выше команд.

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

Запуск ovs-vswitchd

Итак, база данных OVS настроена, хост настроен для использования OVS с DPDK. Теперь следует запустить основной процесс ovs-vswitchd.

modprobe openvswitch

$OVS_DIR/vswitchd/ovs-vswitchd --dpdk -c 0x2 -n 4 --socket-mem 2048 -- unix:/usr/local/var/run/openvswitch/db.sock --pidfile --detach

Создание моста и портов DPDKvhost-userдля использования между виртуальными машинами

В нашем тестовом образце мы создадим мост и добавим два порта DPDK vhost-user. При желании можно добавить физический сетевой адаптер vfio-pci, который мы настроили ранее.

$OVS_DIR/utilities/ovs-vsctl show

$OVS_DIR/utilities/ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev

$OVS_DIR/utilities/ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk

$OVS_DIR/utilities/ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuser

$OVS_DIR/utilities/ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser

На следующем снимке экрана показана итоговая конфигурация OVS.

Использование портов DPDKvhost-userс виртуальными машинами

Описание создания виртуальных машин выходит за рамки этого документа. После того как у нас будут две виртуальные машины (например f21vm1.qcow2 и f21vm2.qcow2), следующие команды покажут, как использовать созданные ранее порты DPDK vhost-user.

qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda ~/f21vm1.qcow2 -boot c -enable-kvm -no-reboot -nographic -net none \

-chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user1 \

-netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \

-device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 \

-object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on \

-numa node,memdev=mem -mem-prealloc

qemu-system-x86_64 -m 1024 -smp 4 -cpu host -hda ~/f21vm2.qcow2 -boot c -enable-kvm -no-reboot -nographic -net none \

-chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user2 \

-netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \

-device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet1 \

-object memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on \

-numa node,memdev=mem -mem-prealloc

Простой тест производительности DPDKvhost-userмежду виртуальными машинами с помощью iperf3

Войдите на виртуальные машины и настройте для сетевых адаптеров статические IP-адреса в одной и той же подсети. Установите iperf3и запустите простой тест сети.

На одной виртуальной машине запустите iperf3в серверном режиме iperf3 -sи запустите клиент iperf3. Пример результата показан на следующем снимке экрана.

Повторение теста производительности для стандартной сборки OVS (без DPDK)

В предыдущих разделах мы создали и использовали сборку OVS-DPDK непосредственно в папке $OVS_DIR, не устанавливая ее в систему. Чтобы повторить тест для стандартной сборки OVS (без DPDK) можно просто выполнить установку с помощью стандартных установщиков дистрибутива. Например, в системах на базе yum (или на базе dnf) можно использовать следующую команду для установки:

pkill -9 ovs

yum install openvswitch

rm -f /etc/openvswitch/conf.db

mkdir -p /var/run/openvswitch

ovsdb-tool create /etc/openvswitch/conf.db /usr/share/openvswitch/vswitch.ovsschema

ovsdb-server --remote=punix:/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach

ovs-vsctl --no-wait init

ovs-vswitchd unix:/var/run/openvswitch/db.sock --pidfile --detach

ovs-vsctl add-br br0

ovs-vsctl show

На этом этапе мы располагаем настроенной свежей базой данных OVS и запущенным процессом ovs-vswitchd без DPDK.

Сведения о настройке двух виртуальных машин с устройствами прослушивания для моста OVS без DPDK (br0) см. в инструкциях по адресу http://openvswitch.org/support/dist-docs-2.4/INSTALL.KVM.md.txt. Затем запустите виртуальные машины, используя те же образы, что мы уже использовали ранее, например:

qemu-system-x86_64 -m 512 -smp 4 -cpu host -hda ~/f21vm1c1.qcow2 -boot c -enable-kvm -no-reboot -nographic -net nic,macaddr=00:11:22:EE:EE:EE -net tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown

qemu-system-x86_64 -m 512 -smp 4 -cpu host -hda ~/f21vm1c2.qcow2 -boot c -enable-kvm -no-reboot -nographic -net nic,macaddr=00:11:23:EE:EE:EE -net tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown

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

Как видно на приведенном выше рисунке, при использовании OVS с DPDK наблюдается значительный прирост производительности. Оба теста производительности были выполнены в одной и той же системе, разница заключалась лишь в том, что в одном случае использовалась стандартная сборка OVS, а в другом — OVS с DPDK.

Заключение

В Open vSwitch версии 2.4 реализована поддержка DPDK, что означает весьма значительный прирост производительности. В этой статье мы показали, как собрать и использовать OVS с DPDK. Мы рассмотрели настройку простого моста OVS с портами DPDK vhost-user для использования между виртуальными машинами. Мы продемонстрировали повышение производительности с помощью теста iperf3, сравнив OVS с DPDK и без DPDK.

Об авторе

Ашок Эмани (Ashok Emani) — старший инженер по программному обеспечению в корпорации Intel. Его 14-летний стаж работы охватывает следующие области: программирование встроенных систем, технологии хранения данных и ввода-вывода, компьютерная архитектура, виртуализация и анализ производительности. В настоящее время он занимается проектами по поддержке SDN/NFV.

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

Введение

Эта система управления доступом входит в серию упражнений с примерами кода Intel для Интернета вещей. Здесь используется Intel^® IoT Developer Kit, платформа разработки Intel^® Edison, облачные платформы, API и другие технологии.

Выполнив это упражнение, разработчики научатся:

• подключать платформу разработки Intel^® Edison, предназначенную для создания прототипов и носимых компьютерных устройств и решений Интернета вещей;
• подключаться к интерфейсу ввода-вывода платформы Intel^® Edison и хранилищу датчиков с помощью MRAA и UPM из пакета Intel^® IoT Developer Kit, представляющего собой полный набор аппаратных и программных компонентов, помогающих разработчикам изучать возможности Интернета вещей и создавать современные проекты;
• запускать этот пример кода в интегрированной среде разработки Intel^® XDK IoT Edition, предназначенной для создания приложений, взаимодействующих с датчиками и приводами, и помогающей быстро приступить к разработке программного обеспечения для платы Intel^® Edison и Intel^® Galileo;
• настраивать сервер веб-приложения, чтобы предоставить пользователям возможность ввода кода доступа для отключения сигнализации и сохранять данные этой системы с помощью Azure Redis Cache* в Microsoft* Azure*, настраивать облачные решения Интернета вещей, включая решения для анализа данных, машинного обучения и различных рабочих инструментов, чтобы упростить процесс подключения датчиков к облаку и помочь быстрее запустить проект Интернета вещей.

Что это такое

В этом проекте, используя плату Intel^® Edison, можно создать систему управления доступом, обладающую следующими возможностями.

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

Как это работает

Система управления доступом работает следующим образом.

1. Пассивный инфракрасный (ИК) датчик движения следит за наличием движения.
2. При появлении пользователя датчик движения срабатывает. После этого пользователь должен ввести нужный код в браузере в течение 30 секунд.
3. Если пользователь не введет код за заданное время, срабатывает сигнализация.
4. Если пользователь вводит правильный код, то система ждет в течение 30 секунд, а затем позволяет пользователю пройти.

Помимо этого, записываются различные события, в том числе looking-for-motion, motion-detected, invalid-codeи т. д.

Кроме того, все данные можно сохранять с помощью хранилища IoT Examples и учетной записи Microsoft* Azure*.

Требования к оборудованию

Комплект Grove* Starter Kit Plus.

1. Плата Intel^® Edison с коммутационной платой Arduino*
2. Пассивный ИК-датчик движения Grove*
3. Цветной ЖК-экран Grove*

Требования к программному обеспечению

1. Intel^® XDK IoT Edition
2. Учетная запись Microsoft* Azure*

Инструкции по настройке

Чтобы приступить к работе, скопируйте хранилище How-ToIntelIoTCodeSamplesс помощью Git* на компьютер следующим образом:

$ gitclonehttps://github.com/intel-iot-devkit/how-to-code-samples.git

Нужно загрузить ZIP-файл? В веб-браузере перейдите по адресу https://github.com/intel-iot-devkit/how-to-code-samplesи нажмите кнопку DownloadZIPв правой нижней части экрана. После загрузки ZIP-файла распакуйте его и используйте файлы в папке этого примера.

Добавление программы в Intel^® XDK IoT Edition

В Intel^® XDK IoT Edition выберите Import Your Node.js Project.

Затем перейдите в папку примера проекта и выберите его.

Нужно подключить плату Intel^® Edison к компьютеру, чтобы отправлять на нее код.

Щелкните меню IoTDeviceв левой нижней части экрана. Если плата Intel^® Edison автоматически распознана, выберите ее.

В противном случае выберите AddManualConnection. В поле Addressвведите 192.168.2.15. В поле Portвведите 58888. Щелкните Connect, чтобы сохранить подключение.

Установка программы вручную на плату Intel^® Edison

Можно установить код на плату Intel^® Edison вручную.

Скопируйте хранилище How-ToIntelIoTCodeSamplesна плату Intel^® Edison после установки SSH-подключения к этой плате:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Затем перейдите в папку с примером.

Чтобы установить Git* на плату Intel^® Edison, если это еще не сделано, установите SSH-подключение к плате и выполните следующую команду:

$ opkg install git

Подключение датчиков Grove*

Нужно подключить плату Grove* Shield к коммутационной плате, совместимой с Arduino*, и подключить все устройства Grove* к плате Grove* Shield. Убедитесь, что маленький переключатель VCC на плате Grove* Shield установлен в положение 5V.

1. Подключите один конец кабеля Grove* к пассивному ИК-датчику движения Grove*, а другой — к порту D4 на плате Grove* Shield.
2. Подключите один конец кабеля Grove* к цветному ЖК-экрану Grove*, а другой — к любому порту I2C на плате Grove* Shield.

Ручная настройка платы Intel^® Edison

При запуске этого кода на плате Intel^® Edison вручную необходимо установить зависимые компоненты.

Для получения модулей Node.js*, необходимых для запуска этого примера программы на плате Intel^® Edison, выполните следующую команду:

npm install

Настройка сервера Microsoft* Azure*

При желании можно хранить данные, созданные этим образцом программы, во внутренней базе данных, развернутой с помощью Microsoft* Azure*, Node.js* и хранилища данных Redis*.

Сведения о настройке собственного облачного сервера данных см. по адресу

https://github.com/intel-iot-devkit/intel-iot-examples-datastore

Настройка примера программы

Чтобы настроить этот пример для использования хранилища данных Microsoft* Azure*, измените параметры SERVERи AUTH_TOKENв файле config.jsonследующим образом:

{ "SERVER": "http://intel-examples.azurewebsites.net/logger/access-control", "AUTH_TOKEN": "s3cr3t" }

Запуск программы с помощью Intel^® XDK IoT Edition

Перед запуском сохраните все файлы.

Щелкните значок Upload, чтобы отправить файлы на плату Intel^® Edison.

Щелкните значок Runв нижней части окна Intel^® XDK IoT Edition. В этом случае код будет запущен на плате Intel^® Edison.

Если вы внесли изменения в код, щелкните UploadandRun. В этом случае на плате Intel^® Edison будет запущена последняя версия кода со всеми изменениями.

При запущенной программе на экране появится текст, аналогичный показанному выше.

Запуск программы вручную

Чтобы запустить пример программы на плате Intel^® Edison вручную, установите SSH-подключение к этой плате и выполните следующую команду:

node index.js

Отключение сигнализации

Для отключения сигнализации используется одностраничный веб-интерфейс, который загружается непосредственно платой Intel^® Edison при запущенной программе.

Порт веб-сервера — 3000, поэтому при подключении платы Intel^® Edison к Wi-Fi* с IP-адресом 192.168.1.13для подключения к веб-серверу из этой же сети нужно использовать адрес http://192.168.1.13:3000.

Определение IP-адреса платы Intel^® Edison

Определить IP-адрес подключенной платы Intel^® Edison можно с помощью следующей команды:

ip addr show | grep wlan

На экране появится приблизительно следующий текст:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0

IP-адрес показан после слова inet. В приведенном выше примере используется IP-адрес 192.168.1.13.

Полный список образцов кода Intel для Интернета вещей см. на сайте Intel^® Developer Zone.

Дополнительные сведения об этом образце кода см. в GitHub*.

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

Введение

Этот сканер-дальномер входит в серию упражнений с образцами кода Intel для Интернета вещей. Здесь используется Intel^® IoT Developer Kit, платформа разработки Intel^® Edison, облачные платформы, API и другие технологии.

Выполнив это упражнение, разработчики научатся:

• подключать платформу разработки Intel^® Edison, предназначенную для создания прототипов и носимых компьютерных устройств и решений Интернета вещей;
• подключаться к интерфейсу ввода-вывода платформы Intel^® Edison и хранилищу датчиков с помощью MRAA и UPM из пакета Intel^® IoT Developer Kit, представляющего собой полный набор аппаратных и программных компонентов, помогающих разработчикам изучать возможности Интернета вещей и создавать современные проекты;
• запускать этот образец кода в интегрированной среде разработки Intel^® XDK IoT Edition, предназначенной для создания приложений, взаимодействующих с датчиками и приводами, и помогающей быстро приступить к разработке программного обеспечения для платы Intel^® Edison и Intel^® Galileo;
• настраивать сервер веб-приложений для просмотра данных сканера-дальномера с помощью веб-страницы, загружаемой непосредственно платой Intel^® Edison.

Что это такое

В этом проекте, используя плату Intel^® Edison, можно создать сканер-дальномер, обладающий следующими возможностями:

• Отслеживание данных, поступающих с инфракрасного датчика-дальномера Grove*.
• Движение датчика-дальномера по кругу с помощью шагового двигателя.
• Доступ с мобильного телефона через встроенный веб-интерфейс для просмотра данных дальномера.

Как это работает

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

Эти данные можно просмотреть на веб-странице, загружаемой непосредственно платой Intel^® Edison.

Требования к оборудованию

Комплект Grove* Robotics Kit.

1. Плата Intel^® Edison с коммутационной платой Arduino*
2. Инфракрасный датчик-дальномер Grove*
3. Шаговый двигатель и контроллер шагового двигателя

Требования к программному обеспечению

1. Intel^® XDK IoT Edition
2. Учетная запись Microsoft* Azure*

Инструкции по настройке

Чтобы приступить к работе, скопируйте хранилище How-To Intel IoT Code Samplesс помощью Git* на компьютер следующим образом:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Нужно загрузить ZIP-файл? В веб-браузере перейдите по адресу https://github.com/intel-iot-devkit/how-to-code-samplesи нажмите кнопку Download ZIPв правой нижней части экрана. После загрузки ZIP-файла распакуйте его и используйте файлы в папке этого примера.

Добавление программы в Intel^® XDK IoT Edition

В Intel^® XDK IoT Edition выберите Import Your Node.js Project:

Затем перейдите в папку примера проекта и выберите его.

Нужно подключить плату Intel^® Edison к компьютеру, чтобы отправлять на нее код.

Щелкните меню IoT Deviceв левой нижней части экрана. Если плата Intel^® Edison автоматически распознана, выберите ее.

В противном случае выберите Add Manual Connection. В поле Addressвведите 192.168.2.15. В поле Portвведите 58888. Щелкните Connect, чтобы сохранить подключение.

Установка программы вручную на плату Intel^® Edison

Можно установить код на плату Intel^® Edison вручную.

Скопируйте хранилище How-To Intel IoT Code Samplesна плату Intel^® Edison после установки SSH-подключения к этой плате:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Затем перейдите в папку с примером.

Чтобы установить Git* на плату Intel^® Edison, если это еще не сделано, установите SSH-подключение к плате и выполните следующую команду:

$ opkg install git

Подключение датчиков Grove*

Нужно подключить плату Grove* Shield к коммутационной плате, совместимой с Arduino*, и подключить все устройства Grove* к плате Grove* Shield. Убедитесь, что маленький переключатель VCC на плате Grove* Shield установлен в положение 5V.

Плату Intel^® Edison необходимо подключить к адаптеру питания, входящему в комплект, или использовать любой другой внешний источник питания, выдающий 12 В и 1,5 А. Также можно использовать внешний аккумулятор, например USB-аккумулятор напряжением 5 В.

Кроме того, потребуется макетная плата и дополнительный источник питания 5 В для шагового двигателя. Примечание. Для питания двигателя требуется отдельный аккумулятор или источник питания. Невозможно использовать один и тот же источник питания и для платы Intel^® Edison, и для двигателя: нужно либо два аккумулятора, либо два источника питания.

1. Подключите контроллер шагового двигателя к контактам 9, 10, 11 и 12 на коммутационной плате Arduino*, чтобы можно было управлять работой двигателя. Подключите контроллер к земляному контакту (GND), к контакту электропитания 5 В от коммутационной платы Arduino* (VCC) и к отдельному источнику питания 5 В для двигателя (VM).

2. Подключите один конец кабеля Grove* к инфракрасному датчику-дальномеру Grove*, а другой — к порту D2 на плате Grove* Shield.

Ручная настройка платы Intel^® Edison

При запуске этого кода на плате Intel^® Edison вручную необходимо установить зависимые компоненты.

Для получения модулей Node.js*, необходимых для запуска этого примера программы на плате Intel^® Edison, выполните следующую команду:

npm install

Настройка сервера Microsoft* Azure*

При желании можно хранить данные, созданные этим образцом программы, во внутренней базе данных, развернутой с помощью Microsoft* Azure*, Node.js* и хранилища данных Redis*.

Сведения о настройке собственного облачного сервера данных см. по адресу:

https://github.com/intel-iot-devkit/intel-iot-examples-datastore

Настройка примера программы

Чтобы настроить этот пример для использования хранилища данных Microsoft* Azure*, измените параметры SERVERи AUTH_TOKENв файле config.jsonследующим образом:

{"SERVER": "http://intel-examples.azurewebsites.net/logger/line-follower","AUTH_TOKEN": "s3cr3t"
}

Запуск программы с помощью Intel^® XDK IoT Edition

Перед запуском сохраните все файлы.

Щелкните значок Upload, чтобы отправить файлы на плату Intel^® Edison.

Щелкните значок Runв нижней части окна Intel^® XDK IoT Edition. В этом случае код будет запущен на плате Intel^® Edison.

Если вы внесли изменения в код, щелкните Upload and Run. В этом случае на плате Intel^® Edison будет запущена последняя версия кода со всеми изменениями.

При запущенной программе на экране появится текст, аналогичный показанному выше.

Запуск программы вручную

Чтобы запустить пример программы на плате Intel^® Edison вручную, установите SSH-подключение к этой плате и выполните следующую команду:

node index.js

Просмотр данных дальномера

Для просмотра данных дальномера используется одностраничный веб-интерфейс, который загружается платой Intel^® Edison при запущенной программе.

Порт веб-сервера — 3000, поэтому при подключении платы Intel^® Edison к Wi-Fi* с IP-адресом 192.168.1.13для подключения к веб-серверу из этой же сети нужно использовать адрес http://192.168.1.13:3000.

Определение IP-адреса платы Intel^® Edison

Определить IP-адрес подключенной платы Intel^® Edison можно с помощью следующей команды:

ip addr show | grep wlan

На экране появится приблизительно следующий текст:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0

IP-адрес показан после слова inet. В приведенном выше примере используется IP-адрес 192.168.1.13.

Полный список образцов кода Intel для Интернета вещей см. на сайте Intel® Developer Zone.

Дополнительные сведения об этом образце кода см. в GitHub*.

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

Введение

Эта роботизированная рука входит в серию упражнений с образцами кода Intel для Интернета вещей. Здесь используется Intel^® IoT Developer Kit, платформа разработки Intel^® Edison, облачные платформы, API и другие технологии.

Выполнив это упражнение, разработчики научатся:

• подключать платформу разработки Intel^® Edison, предназначенную для создания прототипов и носимых компьютерных устройств и решений Интернета вещей;
• подключаться к интерфейсу ввода-вывода платформы Intel^® Edison и хранилищу датчиков с помощью MRAA и UPM из пакета Intel^® IoT Developer Kit, представляющего собой полный набор аппаратных и программных компонентов, помогающих разработчикам изучать возможности Интернета вещей и создавать современные проекты;
• запускать этот образец кода в интегрированной среде разработки Intel^® XDK IoT Edition, предназначенной для создания приложений, взаимодействующих с датчиками и приводами, и помогающей быстро приступить к разработке программного обеспечения для платы Intel^® Edison и Intel^® Galileo;
• настраивать сервер веб-приложений для управления роботизированной рукой с помощью веб-страницы, загружаемой непосредственно платой Intel^® Edison.

Что это такое

В этом проекте, используя плату Intel^® Edison, можно создать роботизированную руку, обладающую следующими возможностями:

• Непрерывное отслеживание данных, поступающих с джойстика Grove*;
• Движение двух шаговых двигателей в соответствии с положением джойстика;
• Доступ с мобильного телефона через встроенный веб-интерфейс для управления движением.

Как это работает

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

Кроме того, двигателями можно управлять по отдельности на веб-странице, загружаемой непосредственно платой Intel^® Edison.

Требования к оборудованию

Комплект Grove* Robotics Kit:

1. Плата Intel^® Edison с коммутационной платой Arduino*
2. Мини-джойстик Grove*
3. Шаговые двигатели и контроллеры шаговых двигателей (2 шт.)

Требования к программному обеспечению

1. Intel® XDK IoT Edition

Инструкции по настройке

Чтобы приступить к работе, скопируйте хранилище How-To Intel IoT Code Samplesс помощью Git* на компьютер следующим образом:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Нужно загрузить ZIP-файл? В веб-браузере перейдите по адресу https://github.com/intel-iot-devkit/how-to-code-samplesи нажмите кнопку Download ZIPв правой нижней части экрана. После загрузки ZIP-файла распакуйте его и используйте файлы в папке этого примера.

Добавление программы в Intel^® XDK IoT Edition

В Intel^® XDK IoT Edition выберите Import Your Node.js Project.

Затем перейдите в папку примера проекта и выберите его.

Нужно подключить плату Intel^® Edison к компьютеру, чтобы отправлять на нее код.

Щелкните меню IoT Deviceв левой нижней части экрана. Если плата Intel^® Edison автоматически распознана, выберите ее.

В противном случае выберите Add Manual Connection. В поле Addressвведите 192.168.2.15. В поле Portвведите 58888. Щелкните Connect, чтобы сохранить подключение.

Установка программы вручную на плату Intel^® Edison

Можно установить код на плату Intel^® Edison вручную.

Скопируйте хранилище How-To Intel IoT Code Samplesна плату Intel^® Edison после установки SSH-подключения к этой плате:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Затем перейдите в папку с примером.

Чтобы установить Git* на плату Intel^® Edison, если это еще не сделано, установите SSH-подключение к плате и выполните следующую команду:

$ opkg install git

Подключение датчиков Grove*

Нужно подключить плату Grove* Shield к коммутационной плате, совместимой с Arduino*, и подключить все устройства Grove* к плате Grove* Shield. Убедитесь, что маленький переключатель VCC на плате Grove* Shield установлен в положение 5V.

Плату Intel^® Edison необходимо подключить к адаптеру питания, входящему в комплект, или использовать любой другой внешний источник питания, выдающий 12 В и 1,5 А. Также можно использовать внешний аккумулятор, например USB-аккумулятор напряжением 5 В.

Кроме того, потребуется макетная плата и дополнительный источник питания 5 В для обоих двигателей. Примечание. Для питания двигателей требуется отдельный аккумулятор или источник питания. Невозможно использовать один и тот же источник питания и для платы Intel^® Edison, и для двигателей: нужно либо два аккумулятора, либо два источника питания.

1. Подключите контроллеры всех шаговых двигателей к 4 контактам на коммутационной плате Arduino, чтобы можно было управлять работой двигателей. Подключите контроллер шагового двигателя # 1 к контактам 4, 5, 6 и 7. Подключите контроллер шагового двигателя # 2 к контактам 9, 10, 11 и 12. Подключите оба контроллера к земляному контакту (GND), к контакту электропитания 5 В от коммутационной платы Arduino* (VCC) и к отдельному источнику питания 5 В для двигателей (VM).

2. Подключите один конец кабеля Grove* к мини-джойстику Grove*, а другой — к порту A0 на плате Grove* Shield.

Ручная настройка платы Intel^® Edison

При запуске этого кода на плате Intel^® Edison вручную необходимо установить зависимые компоненты.

Для получения модулей Node.js*, необходимых для запуска этого примера программы на плате Intel^® Edison, выполните следующую команду:

npm install

Запуск программы с помощью Intel^® XDK IoT Edition

Перед запуском сохраните все файлы.

Щелкните значок Upload, чтобы отправить файлы на плату Intel^® Edison.

Щелкните значок Runв нижней части окна Intel^® XDK IoT Edition. В этом случае код будет запущен на плате Intel^® Edison.

Если вы внесли изменения в код, щелкните Upload and Run. В этом случае на плате Intel^® Edison будет запущена последняя версия кода со всеми изменениями.

При запущенной программе на экране появится текст, аналогичный показанному выше.

Запуск программы вручную

Чтобы запустить пример программы на плате Intel^® Edison вручную, установите SSH-подключение к этой плате и выполните следующую команду:

node index.js

Управление с помощью браузера

Можно управлять двигателями непосредственно с веб-страницы, работающей на веб-сервере на плате Intel^® Edison.

Порт веб-сервера — 3000, поэтому при подключении платы Intel^® Edison к Wi-Fi* с IP-адресом 192.168.1.13для подключения к веб-серверу из этой же сети нужно использовать адрес http://192.168.1.13:3000.

Определение IP-адреса платы Intel^® Edison

Определить IP-адрес подключенной платы Intel^® Edison можно с помощью следующей команды:

ip addr show | grep wlan

На экране появится приблизительно следующий текст:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0

IP-адрес показан после слова inet. В приведенном выше примере используется IP-адрес 192.168.1.13.

Полный список образцов кода Intel для Интернета вещей см. на сайте Intel® Developer Zone.

Дополнительные сведения об этом образце кода см. в GitHub*.

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

Введение

Этот датчик работы кухонной плиты входит в серию упражнений с образцами кода Intel для Интернета вещей. Здесь используется Intel^® IoT Developer Kit, платформа разработки Intel^® Edison, облачные платформы, API и другие технологии.

Выполнив это упражнение, разработчики научатся:

• подключать платформу разработки Intel^® Edison, предназначенную для создания прототипов и носимых компьютерных устройств и решений Интернета вещей;
• подключаться к интерфейсу ввода-вывода платформы Intel^® Edison и хранилищу датчиков с помощью MRAA и UPM из пакета Intel^® IoT Developer Kit, представляющего собой полный набор аппаратных и программных компонентов, помогающих разработчикам изучать возможности Интернета вещей и создавать современные проекты;
• запускать этот образец кода в интегрированной среде разработки Intel^® XDK IoT Edition, предназначенной для создания приложений, взаимодействующих с датчиками и приводами, и помогающей быстро приступить к разработке программного обеспечения для платы Intel^® Edison и Intel^® Galileo;
• настраивать сервер веб-приложения для настройки целевой температуры плиты и сохранения этих данных с помощью Azure Redis Cache* в Microsoft* Azure*, настраивать облачные решения Интернета вещей, включая решения для анализа данных, машинного обучения и различных рабочих инструментов, чтобы упростить процесс подключения датчиков к облаку и помочь быстрее запустить проект Интернета вещей.

Что это такое

В этом проекте, используя плату Intel^® Edison, можно создать датчик работы кухонной плиты, обладающий следующими возможностями:

• Настройка температуры назначения;
• Отслеживание работы плиты, уведомление при достижении заданной температуры;
• Сохранение журнала данных о температуре с помощью облачного хранилища данных.

Как это работает

Этот датчик работы кухонной плиты обладает целым рядом полезных возможностей, он помогает следить за температурой еды, которую вы готовите на плите, не оборудованной никакими встроенными измерительными устройствами. Целевая температура кастрюли, стоящей на плите, устанавливается с помощью мобильного телефона на веб-странице, загружаемой непосредственно платой Intel^® Edison. При достижении заданной температуры динамик издает звуковой сигнал. В случае обнаружения открытого пламени при перекипании кастрюли срабатывает сигнализация. Кроме того, все данные можно сохранять с помощью хранилища IoT Examples и учетной записи Microsoft* Azure*.

Требования к оборудованию

Комплект Grove* Home Automation Kit.

1. Плата Intel^® Edison с коммутационной платой Arduino*
2. Инфракрасный датчик температуры Grove*
3. Датчик пламени Grove*
4. Динамик Grove*

Требования к программному обеспечению

1. Intel® XDK IoT Edition
2. Учетная запись Microsoft* Azure*

Инструкции по настройке

Чтобы приступить к работе, скопируйте хранилище How-To Intel IoT Code Samplesс помощью Git* на компьютер следующим образом:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Нужно загрузить ZIP-файл? В веб-браузере перейдите по адресу https://github.com/intel-iot-devkit/how-to-code-samplesи нажмите кнопку Download ZIPв правой нижней части экрана. После загрузки ZIP-файла распакуйте его и используйте файлы в папке этого примера.

Добавление программы в Intel^® XDK IoT Edition

В Intel^® XDK IoT Edition выберите Import Your Node.js Project.

Затем перейдите в папку примера проекта и выберите его.

Нужно подключить плату Intel^® Edison к компьютеру, чтобы отправлять на нее код.

Щелкните меню IoT Deviceв левой нижней части экрана. Если плата Intel^® Edison автоматически распознана, выберите ее.

В противном случае выберите Add Manual Connection. В поле Addressвведите 192.168.2.15. В поле Portвведите 58888. Щелкните Connect, чтобы сохранить подключение.

Установка программы вручную на плату Intel^® Edison

Можно установить код на плату Intel^® Edison вручную.

Скопируйте хранилище How-To Intel IoT Code Samplesна плату Intel^® Edison после установки SSH-подключения к этой плате:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Затем перейдите в папку с примером.

Чтобы установить Git* на плату Intel^® Edison, если это еще не сделано, установите SSH-подключение к плате и выполните следующую команду:

$ opkg install git

Подключение датчиков Grove*

Нужно подключить плату Grove* Shield к коммутационной плате, совместимой с Arduino*, и подключить все устройства Grove* к плате Grove* Shield. Убедитесь, что маленький переключатель VCC на плате Grove* Shield установлен в положение 5V.

1. Подключите один конец кабеля Grove* к ИК-датчику температуры Grove*, а другой — к порту A0 на плате Grove* Shield.

2. Подключите один конец кабеля Grove* к датчику пламени Grove*, а другой — к порту D4 на плате Grove* Shield.

3. Подключите один конец кабеля Grove* к динамику Grove*, а другой — к порту D5 на плате Grove* Shield.

Ручная настройка платы Intel^® Edison

При запуске этого кода на плате Intel^® Edison вручную необходимо установить зависимые компоненты.

Для получения модулей Node.js*, необходимых для запуска этого примера программы на плате Intel^® Edison, выполните следующую команду:

npm install

Настройка сервера Microsoft* Azure*

При желании можно хранить данные, созданные этим образцом программы, во внутренней базе данных, развернутой с помощью Microsoft* Azure*, Node.js* и хранилища данных Redis*.

Сведения о настройке собственного облачного сервера данных см. по адресу

https://github.com/intel-iot-devkit/intel-iot-examples-datastore

Настройка примера программы

Чтобы настроить этот пример для использования хранилища данных Microsoft* Azure*, измените параметры SERVERи AUTH_TOKENв файле config.jsonследующим образом:

{"SERVER": "http://intel-examples.azurewebsites.net/logger/stove-top","AUTH_TOKEN": "s3cr3t"
}

Запуск программы с помощью Intel^® XDK IoT Edition

Перед запуском сохраните все файлы.

Щелкните значок Upload, чтобы отправить файлы на плату Intel^® Edison.

Щелкните значок Runв нижней части окна Intel^® XDK IoT Edition. В этом случае код будет запущен на плате Intel^® Edison.

Если вы внесли изменения в код, щелкните Upload and Run. В этом случае на плате Intel^® Edison будет запущена последняя версия кода со всеми изменениями.

При запущенной программе на экране появится текст, аналогичный показанному выше.

Запуск программы вручную

Чтобы запустить пример программы на плате Intel^® Edison вручную, установите SSH-подключение к этой плате и выполните следующую команду:

node index.js

Настройка температуры

Для настройки целевой температуры используется одностраничный веб-интерфейс, который загружается платой Intel^® Edison при запущенной программе.

Порт веб-сервера — 3000, поэтому при подключении платы Intel^® Edison к Wi-Fi* с IP-адресом 192.168.1.13для подключения к веб-серверу из этой же сети нужно использовать адрес http://192.168.1.13:3000.

Определение IP-адреса платы Intel^® Edison

Определить IP-адрес подключенной платы Intel^® Edison можно с помощью следующей команды:

ip addr show | grep wlan

На экране появится приблизительно следующий текст:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0

IP-адрес показан после слова inet. В приведенном выше примере используется IP-адрес 192.168.1.13.

Полный список образцов кода Intel для Интернета вещей см. на сайте Intel® Developer Zone.

Дополнительные сведения об этом образце кода см. в GitHub*.

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

Введение

Этот складской датчик затопления входит в серию упражнений с образцами кода Intel для Интернета вещей. Здесь используется Intel^® IoT Developer Kit, платформа разработки Intel^® Edison, облачные платформы, API и другие технологии.

Выполнив это упражнение, разработчики научатся:

• подключать платформу разработки Intel^® Edison, предназначенную для создания прототипов и носимых компьютерных устройств и решений Интернета вещей;
• подключаться к интерфейсу ввода-вывода платформы Intel^® Edison и хранилищу датчиков с помощью MRAA и UPM из пакета Intel^® IoT Developer Kit, представляющего собой полный набор аппаратных и программных компонентов, помогающих разработчикам изучать возможности Интернета вещей и создавать современные проекты;
• запускать этот образец кода в интегрированной среде разработки Intel^® XDK IoT Edition, предназначенной для создания приложений, взаимодействующих с датчиками и приводами, и помогающей быстро приступить к разработке программного обеспечения для платы Intel^® Edison и Intel^® Galileo;
• сохранять данные об обнаружении воды с помощью Azure Redis Cache* в Microsoft* Azure*, настраивать облачные решения Интернета вещей, включая решения для анализа данных, машинного обучения и различных рабочих инструментов, чтобы упростить процесс подключения датчиков к облаку и помочь быстрее запустить проект Интернета вещей.

Что это такое

В этом проекте, используя плату Intel^® Edison, можно создать складской датчик затопления, обладающий следующими возможностями:

• Непрерывная проверка данных с датчика влажности;
• Звуковая сигнализация в случае возможного затопления;
• Сохранение данных о всех случаях обнаружения воды с помощью облачного хранилища данных.

Как это работает

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

Если уровень влажности превышает заданный порог, выдается звуковой сигнал.

Кроме того, все данные можно сохранять с помощью хранилища IoT Examples и учетной записи Microsoft* Azure*.

Требования к оборудованию

Комплект Grove* Home Automation Kit.

1. Плата Intel^® Edison с коммутационной платой Arduino*
2. Датчик влажности Grove*
3. Динамик Grove*

Требования к программному обеспечению

1. Intel® XDK IoT Edition
2. Учетная запись Microsoft* Azure*

Инструкции по настройке

Чтобы приступить к работе, скопируйте хранилище How-To Intel IoT Code Samplesс помощью Git* на компьютер следующим образом:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Нужно загрузить ZIP-файл? В веб-браузере перейдите по адресу https://github.com/intel-iot-devkit/how-to-code-samplesи нажмите кнопку Download ZIPв правой нижней части экрана. После загрузки ZIP-файла распакуйте его и используйте файлы в папке этого примера.

Добавление программы в Intel^® XDK IoT Edition

В Intel^® XDK IoT Edition выберите Import Your Node.js Project.

Затем перейдите в папку примера проекта и выберите его.

Нужно подключить плату Intel^® Edison к компьютеру, чтобы отправлять на нее код.

Щелкните меню IoT Deviceв левой нижней части экрана. Если плата Intel^® Edison автоматически распознана, выберите ее.

В противном случае выберите Add Manual Connection. В поле Addressвведите 192.168.2.15. В поле Portвведите 58888. Щелкните Connect, чтобы сохранить подключение.

Установка программы вручную на плату Intel^® Edison

Можно установить код на плату Intel^® Edison вручную.

Скопируйте хранилище How-To Intel IoT Code Samplesна плату Intel^® Edison после установки SSH-подключения к этой плате:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Затем перейдите в папку с примером.

Чтобы установить Git* на плату Intel^® Edison, если это еще не сделано, установите SSH-подключение к плате и выполните следующую команду:

$ opkg install git

Подключение датчиков Grove*

Нужно подключить плату Grove* Shield к коммутационной плате, совместимой с Arduino*, и подключить все устройства Grove* к плате Grove* Shield. Убедитесь, что маленький переключатель VCC на плате Grove* Shield установлен в положение 5V.

1. Подключите один конец кабеля Grove* к датчику влажности Grove*, а другой — к порту A0 на плате Grove* Shield.

2. Подключите один конец кабеля Grove* к динамику Grove*, а другой — к порту D5 на плате Grove* Shield.

Ручная настройка платы Intel^® Edison

При запуске этого кода на плате Intel^® Edison вручную необходимо установить зависимые компоненты.

Для получения модулей Node.js*, необходимых для запуска этого примера программы на плате Intel^® Edison, выполните следующую команду:

npm install

Настройка сервера Microsoft* Azure*

При желании можно хранить данные, созданные этим образцом программы, во внутренней базе данных, развернутой с помощью Microsoft* Azure*, Node.js* и хранилища данных Redis*.

Сведения о настройке собственного облачного сервера данных см. по адресу

https://github.com/intel-iot-devkit/intel-iot-examples-datastore

Настройка примера программы

Чтобы настроить этот пример для использования хранилища данных Microsoft* Azure*, измените параметры SERVERи AUTH_TOKENв файле config.jsonследующим образом:

{"SERVER": "http://intel-examples.azurewebsites.net/logger/flood-detect","AUTH_TOKEN": "s3cr3t"
}

Запуск программы с помощью Intel^® XDK IoT Edition

Перед запуском сохраните все файлы.

Щелкните значок Upload, чтобы отправить файлы на плату Intel^® Edison.

Щелкните значок Runв нижней части окна Intel^® XDK IoT Edition. В этом случае код будет запущен на плате Intel^® Edison.

Если вы внесли изменения в код, щелкните Upload and Run. В этом случае на плате Intel^® Edison будет запущена последняя версия кода со всеми изменениями.

При запущенной программе на экране появится текст, аналогичный показанному выше.

Запуск программы вручную

Чтобы запустить пример программы на плате Intel^® Edison вручную, установите SSH-подключение к этой плате и выполните следующую команду:

node index.js

Определение IP-адреса платы Intel^® Edison

Определить IP-адрес подключенной платы Intel^® Edison можно с помощью следующей команды:

ip addr show | grep wlan

На экране появится приблизительно следующий текст:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0

IP-адрес показан после слова inet. В приведенном выше примере используется IP-адрес 192.168.1.13.

Полный список образцов кода Intel для Интернета вещей см. на сайте Intel® Developer Zone.

Дополнительные сведения об этом образце кода см. в GitHub*.

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

Введение

Эта автоматическая система полива входит в серию упражнений с образцами кода Intel для Интернета вещей. Здесь используется Intel^® IoT Developer Kit, платформа разработки Intel^® Edison, облачные платформы, API и другие технологии.

Выполнив это упражнение, разработчики научатся:

• подключать платформу разработки Intel^® Edison, предназначенную для создания прототипов и носимых компьютерных устройств и решений Интернета вещей;
• подключаться к интерфейсу ввода-вывода платформы Intel^® Edison и хранилищу датчиков с помощью MRAA и UPM из пакета Intel^® IoT Developer Kit, представляющего собой полный набор аппаратных и программных компонентов, помогающих разработчикам изучать возможности Интернета вещей и создавать современные проекты;
• запускать этот образец кода в интегрированной среде разработки Intel^® XDK IoT Edition, предназначенной для создания приложений, взаимодействующих с датчиками и приводами, и помогающей быстро приступить к разработке программного обеспечения для платы Intel^® Edison и Intel^® Galileo;
• настраивать сервер веб-приложения для размещения данных системы полива с помощью Azure Redis Cache* в Microsoft* Azure*, настраивать облачные решения Интернета вещей, включая решения для анализа данных, машинного обучения и различных рабочих инструментов, чтобы упростить процесс подключения датчиков к облаку и помочь быстрее запустить проект Интернета вещей;
• вызывать службы API Twilio* для отправки СМС-сообщений.

Что это такое

В этом проекте, используя плату Intel^® Edison, можно создать автоматическую систему полива, обладающую следующими возможностями:

• Включение и выключение водяного насоса по настраиваемому расписанию.
• Определение перекачки воды в заданное время с помощью датчика потока воды.
• Доступ с мобильного телефона через встроенный веб-интерфейс для настройки времени полива.
• Отслеживание событий полива с помощью облачного хранилища данных.
• Отправка СМС-сообщений для оповещения получателей о неисправностях системы.

Как это работает

Эта система полива позволяет настраивать расписание полива на веб-странице, загружаемой непосредственно платой Intel^® Edison, с помощью мобильного телефона.

Система автоматически опрашивает данные датчика влажности с заданными интервалами и отображает эти данные на веб-странице.

Если водяной насос по расписанию должен работать, но датчик потока воды определяет, что подача воды отсутствует, система отправляет СМС-сообщение на указанный номер телефона с помощью Twilio*, чтобы оповестить о необходимости ремонта системы полива.

Кроме того, система может записывать события полива с помощью хранилища IoT Examples и учетной записи Microsoft* Azure*.

Требования к оборудованию

Комплект Grove* Environment & Agriculture Kit.

1. Плата Intel^® Edison с коммутационной платой Arduino*
2. Датчик влажности Grove*
3. Водяной насос
4. Датчик потока воды
5. Реле Grove* Dry-Reed

Требования к программному обеспечению

1. Intel® XDK IoT Edition
2. Учетная запись Microsoft* Azure*
3. Учетная запись Twilio*

Инструкции по настройке

Чтобы приступить к работе, скопируйте хранилище How-To Intel IoT Code Samplesс помощью Git* на компьютер следующим образом:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Нужно загрузить ZIP-файл? В веб-браузере перейдите по адресу https://github.com/intel-iot-devkit/how-to-code-samplesи нажмите кнопку Download ZIPв правой нижней части экрана. После загрузки ZIP-файла распакуйте его и используйте файлы в папке этого примера.

Добавление программы в Intel^® XDK IoT Edition

В Intel^® XDK IoT Edition выберите Import Your Node.js Project.

Затем перейдите в папку примера проекта и выберите его.

Нужно подключить плату Intel^® Edison к компьютеру, чтобы отправлять на нее код.

Щелкните меню IoT Deviceв левой нижней части экрана. Если плата Intel^® Edison автоматически распознана, выберите ее.

В противном случае выберите Add Manual Connection. В поле Addressвведите 192.168.2.15. В поле Portвведите 58888. Щелкните Connect, чтобы сохранить подключение.

Установка программы вручную на плату Intel^® Edison

Можно установить код на плату Intel^® Edison вручную.

Скопируйте хранилище How-To Intel IoT Code Samplesна плату Intel^® Edison после установки SSH-подключения к этой плате:

$ git clone https://github.com/intel-iot-devkit/how-to-code-samples.git

Затем перейдите в папку с примером.

Чтобы установить Git* на плату Intel^® Edison, если это еще не сделано, установите SSH-подключение к плате и выполните следующую команду:

$ opkg install git

Подключение датчиков Grove*

Нужно подключить плату Grove* Shield к коммутационной плате, совместимой с Arduino*, и подключить все устройства Grove* к плате Grove* Shield. Убедитесь, что маленький переключатель VCC на плате Grove* Shield установлен в положение 5V.

Плату Intel^® Edison необходимо подключить к адаптеру питания, входящему в комплект, или использовать любой другой внешний источник питания, выдающий 12 В и 1,5 А. Также можно использовать внешний аккумулятор, например USB-аккумулятор напряжением 5 В.

Кроме того, потребуется макетная плата и дополнительный источник питания 5 В для насоса. Примечание. Для питания насоса требуется отдельный аккумулятор или источник питания. Невозможно использовать один и тот же источник питания и для платы Intel^® Edison, и для насоса: нужно либо два аккумулятора, либо два источника питания.

Для подключения водяного насоса нужно использовать плату реле Grove* Dry-Reed.

1. Подключите один конец кабеля Grove* к реле Grove* Dry-Reed*, а другой — к порту D4 на плате Grove* Shield.
2. Подключите один конец кабеля Grove* к реле Grove* Dry-Reed*, а другой — к порту D4 на плате Grove* Shield.
3. Подключите другой провод насоса к одному из разъемов питания на плате реле Grove* Dry-Reed.
4. Подключите разъем питания на плате реле Grove* Dry-Reed к земляному контакту источника питания 5 В насоса.
5. Подключите датчик потока воды: красный провод — к контакту 5V, черный провод — к контакту GND, а желтый провод — к цифровому контакту 2 на плате Grove* Shield.
6. Подключите один конец кабеля Grove* к датчику влажности Grove*, а другой — к порту A0 на плате Grove* Shield.

Ручная настройка платы Intel^® Edison

При запуске этого кода на плате Intel^® Edison вручную необходимо установить зависимые компоненты.

Для получения модулей Node.js*, необходимых для запуска этого примера программы на плате Intel^® Edison, выполните следующую команду:

npm install

Ключ API Twilio*

Для отправки СМС-сообщений необходимо зарегистрировать учетную запись и получить ключ API на веб-сайте Twilio*:

https://www.twilio.com

Для отправки СМС-сообщений нужно сначала получить ключ API Twilio*. Этот пример программы будет работать и без ключа, но в этом случае не будет СМС-сообщений.

Передайте ключ API Twilio* и маркер проверки подлинности в пример программы, изменив параметры TWILIO_ACCT_SIDи TWILIO_AUTH_TOKENв файле config.jsonследующим образом:

{"TWILIO_ACCT_SID": "YOURAPIKEY","TWILIO_AUTH_TOKEN": "YOURTOKEN"
}

Настройка сервера Microsoft* Azure*

При желании можно хранить данные, созданные этим образцом программы, во внутренней базе данных, развернутой с помощью Microsoft* Azure*, Node.js* и хранилища данных Redis*.

Сведения о настройке собственного облачного сервера данных см. по адресу

https://github.com/intel-iot-devkit/intel-iot-examples-datastore

Настройка примера программы

Чтобы настроить этот пример для отправки СМС-сообщений, получите ключ API на веб-сайте Twilio*, как описано выше, и измените параметры TWILIO_ACCT_SIDи TWILIO_AUTH_TOKENв файле config.jsonследующим образом:

{"TWILIO_ACCT_SID": "YOURAPIKEY","TWILIO_AUTH_TOKEN": "YOURTOKEN"
}

Чтобы настроить этот пример для использования хранилища данных Microsoft* Azure*, измените параметры SERVERи AUTH_TOKENв файле config.jsonследующим образом:

{"SERVER": "http://intel-examples.azurewebsites.net/logger/watering-system","AUTH_TOKEN": "s3cr3t"
}

Чтобы настроить этот пример для использования одновременно и СМС-сообщений, и хранилища данных Microsoft* Azure*, измените параметры TWILIO_ACCT_SID, TWILIO_AUTH_TOKEN, SERVERи AUTH_TOKENв файле config.jsonследующим образом:

{"TWILIO_ACCT_SID": "YOURAPIKEY","TWILIO_AUTH_TOKEN": "YOURTOKEN","SERVER": "http://intel-examples.azurewebsites.net/logger/watering-system","AUTH_TOKEN": "s3cr3t"
}

Запуск программы с помощью Intel^® XDK IoT Edition

Перед запуском сохраните все файлы.

Щелкните значок Upload, чтобы отправить файлы на плату Intel^® Edison.

Щелкните значок Runв нижней части окна Intel^® XDK IoT Edition. В этом случае код будет запущен на плате Intel^® Edison.

Если вы внесли изменения в код, щелкните Upload and Run. В этом случае на плате Intel^® Edison будет запущена последняя версия кода со всеми изменениями.

При запущенной программе на экране появится текст, аналогичный показанному выше.

Запуск программы вручную

Чтобы запустить пример программы на плате Intel^® Edison вручную, установите SSH-подключение к этой плате и выполните следующую команду:

node index.js

Настройка расписания полива

Для настройки расписания полива используется одностраничный веб-интерфейс, который загружается платой Intel^® Edison при запущенной программе.

Порт веб-сервера — 3000, поэтому при подключении платы Intel^® Edison к Wi-Fi* с IP-адресом 192.168.1.13для подключения к веб-серверу из этой же сети нужно использовать адрес http://192.168.1.13:3000.

Определение IP-адреса платы Intel^® Edison

Определить IP-адрес подключенной платы Intel^® Edison можно с помощью следующей команды:

ip addr show | grep wlan

На экране появится приблизительно следующий текст:

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    inet 192.168.1.13/24 brd 192.168.1.255 scope global wlan0

IP-адрес показан после слова inet. В приведенном выше примере используется IP-адрес 192.168.1.13.

Полный список образцов кода Intel для Интернета вещей см. на сайте Intel^® Developer Zone.

Дополнительные сведения об этом образце кода см. в GitHub*.

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

Введение

Wearable Smart Gateway* (WSG*) — это первый в мире носимый шлюз связи, дающий возможность сотрудникам экстренных служб безопасно передавать мультимедиа данные по глобальным сетям в реальном времени.

Устройство WSG разработано компанией Mutualink с помощью технологий Intel^®. WSG предоставляет штабам экстренных служб доступ к оперативным ситуационным данным, включая видео, биометрические данные и данные об окружающей среде. Возможности WSG существенно повышают оперативность получения информации и снижают время реагирования в быстро меняющихся ситуациях. Благодаря этому службы полиции, пожарной охраны и скорой медицинской помощи могут быстрее принимать информированные решения и преодолевать трудности, вызванные нехваткой информации.

WSG — первое устройство, разработанное в рамках инициативы «Интернет вещей общественной безопасности» (IoPST*), возглавляемой компаниями Intel^®и Mutualink. Цель этой инициативы — предоставить экстренным службам современные технологии связи, помогающие спасать жизни. Совместная инициатива была удостоена премии за инновации Integrated Justice Information Systems (IJIS) 2016 года.

В этой статье описывается история разработки WSG и используемые в этих устройствах технологии. На момент написания этой статьи устройство WSG находилось на этапе прототипа, его коммерческое развертывание запланировано на 2016 год. Поэтому в статье также описываются перспективы развития устройства. Помимо этого, обсуждаются технологии WSG в контексте IoPST и широкополосной сети LTE* FirstNet*.

Создание WSG*

Главный офис компании Mutualinkнаходится в г. Уоллингфорд, штат Коннектикут, США. Специалисты этой компании обладают более чем 20-летним опытом разработки технологий связи для сектора общественной безопасности. Службы Mutualink на основе IP-сетей используются организациями в самых разных областях — от обороны и правопорядка до финансов и здравоохранения. Существующие системы этой компании — это оборудование в монтажных стойках, высокопроизводительные программы, сквозное стандартное шифрование для обеспечения внутреннего доступа к видео, голосу и данным.

Рисунок 1. Прототип устройства WearableSmartGateway* (WSG*).

Одной из серьезных проблем в работе экстренных служб является невозможность взаимодействия систем связи: из-за различий в используемых технических стандартах и протоколах обмен данными между разными экстренными службами является сложным и медленным процессом. Компания Mutualink уже много лет выпускает решения, преодолевающие подобные границы. Разработчики впервые решили реализовать свои технологии в компактном носимом устройстве. Специалисты Mutualink в сотрудничестве с Intel решили создать универсальную систему, способную образовать безопасную среду связи между различными техническими решениями, которые применяются экстренными службами, их штабами и содействующими организациями.

Результатом этого сотрудничества стало устройство WSG — носимый шлюз связи, использующий интерфейсы Wi-Fi*, USB и Bluetooth для подключения к устройствам, находящимся у сотрудников экстренных служб с удаленными штабами. При этом устанавливается подключение по безопасной виртуальной частной сети (VPN) к серверу, который может быть локальным или находиться в облаке. Далее эту информацию можно предоставлять любому количеству сотрудничающих организаций и участников по мере необходимости.

Вклад экстренных служб в разработку WSG

Компания Mutualink обладает заслуженной репутацией в области решений связи для экстренных служб. Такого положения удалось добиться благодаря глубокому пониманию нужд и потребностей оперативных сотрудников экстренных служб. В отделе развития бизнеса Mutualink работает несколько бывших сотрудников таких организаций, обладающих десятками лет опыта оперативной работы. Они помогают прорабатывать сценарии использования и точно знают, что сработает, а что нет.

При выработке концепции WSG компании Intel и Mutualink прошли еще дальше и обратились в экстренные службы: с помощью серии подробных опросов были получены данные о необходимой функциональности нового устройства. Внутренние обсуждения и мозговые штурмы помогли скорректировать концепцию перед переходом к созданию прототипов. Отзывы экстренных служб оказались весьма полезными для определения возможностей штабного пользовательского интерфейса и общей функциональности устройств.  

Как и для всех носимых устройств, большое значение имеет размер и вес WSG: устройство должно быть достаточно компактным и легким, чтобы никоим образом не мешать и не отвлекать от работы оперативных сотрудников, которым это устройство призвано помогать. Разработчики решили построить устройство WSG на основе модуля Intel^® Edison, поскольку он очень компактный и при этом отличается высокой производительностью и крайне низким потреблением электроэнергии.

Создание прототипов WSG

Чтобы перейти от концепции WSG к прототипу, специалисты Mutualink начали работать с модулем Intel^® Edison, оснащенным встроенными интерфейсами Wi-Fi, Bluetooth и USB. Даже вместе с аккумулятором устройство обещало быть очень маленьким. Встроенные средства подключения модуля позволяют подсоединять его к различным устройствам, которыми пользуется сотрудник экстренных служб. Например, можно подключить камеру, пульсометр, средства звуковой связи и т. д. Можно использовать и сеть Wi-Fi для подключения к глобальной сети.

Главная система на кристаллеплаты Intel^® Edison — это выполненный по 22-нмтехнологии процессор Intel^® Atom™ серии Z34XX, содержащий два ядра микроархитектуры Silvermont, работающих на частоте 500 МГц, и одно ядро Intel^® Quark™, работающее на частоте 100 МГц (для выполнения операционной системы реального времени Wind River Viper*). В «систему на кристалле» интегрирован 1 ГБ оперативной памяти. Также на плату установлена карта флеш-памяти eMMCобъемом 4 ГБ, контроллеры Wi-Fi, Bluetooth 4и USB. Плата оборудована 70-контактным разъемом Hirose DF40 с портами USB, SD, UARTи GPIO.

Рисунок 2. Модули Intel^®Edisonиспользованы для ряда прототипов WSG

В настоящее время WSG пока не оборудован возможностями связи 4G/LTE* для самостоятельного подключения к сотовым сетям. Вместо этого WSG может либо подключаться к сети 4G/LTE опосредованно (WSG подключается по Wi-Fi к мобильному телефону, который, в свою очередь, подключается к сети 4G/LTE), либо к точке доступа Wi-Fi. Один из прототипов был предназначен для подключения к телефону повышенной прочности Sonim*. В результате получался компактный и очень прочный блок карманного размера. Такое «объединенное» устройство WSG отличается неплохой эргономикой и является относительно небольшим: его можно носить в кармане куртки или штанов карго свободного покроя с большими карманами, но все же весьма желательно сделать устройство еще компактнее. Для этого разработчики изучают возможность встраивания модема 4G/LTE непосредственно в устройство.

Снижение потребления электроэнергии

К электропитанию WSG предъявляются весьма строгие требования, поскольку WSG может использоваться для подключения к любому количеству устройств, способных передавать важные оперативные цифровые данные в любом месте и в любое время. Кроме того, экстренным службам требуется, чтобы на самом устройстве были понятные и простые индикаторы состояния. Если учитывать эти требования, то время работы от аккумулятора является крайне важным для успешной работы устройства в полевых условиях. Именно поэтому был выбран модуль Intel^® Edison, отличающийся низким потреблением электроэнергии.

При выборе аккумулятора разработчики стремились найти компромисс между емкостью и размером: устройство должно быть портативным. Для питания большинства прототипов WSG используется литий-ионный аккумулятор напряжением 3,7 В, емкостью 1200 мА·ч. В зависимости от назначения для WSG можно использовать практически любые аккумуляторы, например емкостью 6000 мА·ч, хотя в этом случае, естественно, увеличиваются размеры устройства. В ходе начального тестирования прототипы WSG сохраняли полную работоспособность в течение 12 часов и дольше. Это важно, чтобы при реагировании на чрезвычайную ситуацию не нужно было заботиться о том, заряжены устройства или нет. Отметим, что заряжать WSG не сложнее, чем заряжать любой сотовый телефон.

Обнаруженные ограничения, обходные меры, работа над прототипами продолжается

Одно из ограничений серийных модулей Intel^® Edison состоит в том, что при электропитании напряжением 3,7 В порт USB OTG не подает питания на подключенное устройство. Из-за этого возникает проблема, если пользователю нужно подать питание напряжением +5 В на внешнюю камеру, подключенную к USB. Разработчики придумали способ обойти это ограничение: подключить дополнительный USB-кабель питания между WSG и внешним периферийным устройством.

Рисунок 3. Обходное решение с дополнительным кабелем USBпозволяет подать электропитание на подключенное устройство

Как видно на рис. 4, последующий прототип WSG использовал набор из трех плат Spark Fun*: одну для модуля Intel^® Edison, вторую для аккумулятора и зарядки, третью для функциональности ввода-вывода.

Рисунок 4. Для создания некоторых прототипов WSGиспользовались платы SparkFun*.

В текущих прототипах WSG предпочтение отдано модулю Intel^® Edison благодаря его компактности и встроенной функциональности. При этом разработчики стремятся решить проблему подачи электропитания через USB. Необходимость электропитания через USB и желание реализовать модем 4G LTE на плате вынудили разработчиков начать создание собственного решения, которое сейчас находится на стадии разработки. Кроме того, разработчики ведут переговоры с производителями аккумуляторов относительно встраивания WSG непосредственно в корпус аккумулятора. Это позволит добиться более оптимального соотношения мощности и размера.

Гибкость использования

Гибкость и широкие возможности адаптации — вот основные идеи, заложенные в конструкцию WSG. Это устройство и его экосистема должны иметь возможность развиваться по мере изменения оборудования и программного обеспечения, а также при появлении новых сценариев использования. Программное обеспечение WSG основано на операционной системе Linux* и написано на JavaScript*. Это открытое и расширяемое решение, поддерживающее удобное добавление новых возможностей.

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

Рисунок 5. Светодиодные индикаторы позволяют быстро узнать состояние VPNи сетевого трафика

Пользовательский интерфейс в штабе

В целях поддержания наибольшей гибкости штабной интерфейс создан на основе компактного веб-клиента Node.js* на платформе веб-приложений. Благодаря этому клиент можно запускать практически на любом устройстве с веб-браузером, будь то смартфон, планшет, ноутбук или устройство Intel^® Compute Stick, подключенное к любому монитору с разъемом HDMI. Руководителям может потребоваться работать удаленно или в поездках или организовать временный штаб при проведении операции, а такой подход предоставляет им нужный уровень гибкости.

Рисунок 6. Пользовательский интерфейс WSGдля штабов основан на веб-браузере и является модульным

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

Использование любых видов сетей, приоритет безопасности

Прототип WSG передает данные (через подключение Wi-Fi к сотовому телефону) в любую коммерческую сеть 4G, а также сможет подключаться к широкополосной сети экстренных служб FirstNet*, которая в данное время разрабатывается для использования на всей территории США. Система устроена таким образом, чтобы работать по всем доступным сетям, но не в ущерб безопасности.

Аналогичный поход используется в WSG и при передаче серверами данных в штаб и другим участникам по виртуальной одноранговой сети без доверия. Распределенные узлы и службы приложений по запросу используют частные серверы Intel, а также службы Amazon Web Services*. Благодаря такому модульному гибкому подходу полностью сохраняется целостность данных, а клиенты могут выбирать ту конфигурацию, которая лучше всего отвечает их потребностям и соответствует существующим ресурсам.

Сетевая безопасность

Безопасность системы имеет первостепенное значение, особенно с учетом того, что устройства WSG потенциально могут повергаться множеству угроз, влияющих на любые обычные компьютеры и сети, — от простых перебоев в работе сетей до распределенных атак типа «Отказ в обслуживании». Для предотвращения подмены и несанкционированного получения данных посторонними устройствами в системе используется стандартная проверка подлинности AES256 на основе сертификатов для каждого устройства в сети.

Разработчики стремятся реализовать оптимальный уровень безопасности на всех уровнях, начиная с оборудования. Это помогает поддерживать целостность данных и позволяет реализовать мощную защиту от вредоносного ПО, но не в ущерб скорости передачи данных.

Поток данных проходит только через туннели VPN со сквозным шифрованием с использованием клиентов на основе открытых стандартов. Подключаемые модули Mutualink загружаются на WSG и на клиент; приложение WSG на клиенте устанавливает туннель VPN и обрабатывает проверку подлинности.

WSG может не только работать с любыми типами сетей, но и поддерживает любые виды подключения к серверам. По зашифрованному туннелю VPN устройство может подключаться к частному серверу или к общедоступному облачному серверу, такому как Amazon Web Services. Поддержание целостности данных важно при передаче данных по любой сети, особенно по общедоступной сети. Именно в этом проявляется многолетний опыт разработчиков Mutualink по организации сетевых подключений с использованием стойкого шифрования и виртуальных частных сетей.

Обмен данными между разными организациями

Рисунок 7. Поток пакетов данных, поступающих от WSG (слева) на сервер и в штаб, а затем к удаленным службам

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

Облачная система поддерживает динамическое предоставление доступа к данным любыми органами, использующими системы Mutualink, для любых допущенных участников. Компактный клиент на основе браузера упрощает доступ к пользовательскому интерфейсу штаба на любых устройствах, включая ноутбуки, планшеты и смартфоны. На практике это означает, что удаленному сотруднику в любой заданной ситуации достаточно лишь телефона и приложения Mutualink для отслеживания всех этапов операции по мере ее развертывания: видео, звук и данные передаются непосредственно на телефон.

Дублирование

Для бесперебойной работы системы WSG в чрезвычайных ситуациях, для которых и предназначено это устройство, применяется дублирование. Сбои могут возникать в разных сегментах системы: возможен отказ оборудования, нарушение подключений, потеря доступа к сетям 4G и Wi-Fi, что нередко происходит в чрезвычайных ситуациях, когда сразу много людей пытается одновременно подключиться к сети.

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

Представляем Mesh*

Компания Mutualink специализируется на децентрализованных решениях архитектуры обмена данными. Поскольку клиентами описываемого устройства являются экстренные службы, в этой модели исключается концентрация всех возможностей в руках только какой-то одной службы: все участники имеют равные условия. Этот принцип децентрализованного потока данных был применен в архитектуре WSG, а решение Mesh*является его дальнейшим развитием; это решение обеспечивает полное резервирование в сети.

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

Для передачи пакетов данных к месту назначения также могут использоваться все устройства WSG (в том числе описанные в разделе «Интернет вещей общественной безопасности» далее в этой статье). К таким устройствам могут относиться лампы аварийного освещения, блоки пожарной сигнализации, а также обычные лампы, в которых можно установить компоненты WSG с интерфейсами Bluetooth, Wi-Fi и 4G.  Система автоматически построит маршрут для передачи данных по сети с высоким уровнем надежности, при этом, с точки зрения пользователей, никаких перебоев при передаче данных не будет.

WSG поддерживает FirstNet*

FirstNet* — это выделенная сеть общественной безопасности в диапазоне LTE. В данное время эта сеть проходит этап консультаций перед общегосударственным развертыванием в США. Эта сеть была разработана в соответствии с итоговыми рекомендациями Комиссии 9/11 и представляет собой общегосударственную беспроводную сеть, предназначенную только для экстренных служб. Применение этой сети позволяет избегать проблем связи, с которыми экстренные службы сталкивались при перегрузках сетей общего пользования.

Ряд проектов FirstNet Early Builder уже используется. Среди них — мобильная сеть JerseyNet в Нью-Джерси, эту сеть использовали в 2015 году при визите Папы Римского. Также проект FirstNet реализован в округе Харрис в штате Техас: технологии Mutualink уже используются экстренными службами. Разработчики Intel и Mutualink позаботились о безопасности WSG на всех уровнях, обеспечили целостность данных и надежную защиту от вредоносного ПО. При этом поддерживается нужная скорость и эффективность устройств, предназначенных для сетей общественной безопасности.

Испытание WSG в полевых условиях

Для успешного внедрения любых новых технологий важно удобство пользователей, в особенности если речь идет о носимых устройствах для экстренных служб, работающих в напряженных ситуациях. Сотрудникам таких служб некогда заботиться о тонкостях работы очередного устройства. Испытания WSG в полевых условиях — вот что помогает улучшить удобство WSG и способствовать более широкому внедрению этих устройств. В настоящее время WSG остается прототипом и пока недоступно для использования в реальных экстренных ситуациях, но на учениях Urban Shieldв сентябре 2015 года разработчики получили возможность испытания системы и проверки ее удобства в условиях, приближенных к реальным. Это дало возможность получить отзывы о фактических трудностях, возникающих в чрезвычайных ситуациях.

Urban Shield — это ежегодные учения длительностью 48 часов, проходящие в Северной Каролине. Команды экстренных служб из разных стран (главным образом это силы правопорядка, но также участвует пожарная охрана и скорая медицинская помощь) выполняют последовательность реалистичных упражнений. На таких учениях команды отрабатывают оперативную тактику и проводят различные испытания для новых технических решений, одним из которых в данном случае стала система WSG.

В ходе исследования перед учениями разработчики провели консультации с сотрудниками экстренных служб из города Саннивейл (штат Калифорния, США) и выпустили несколько прототипов WSG на базе модуля Intel^® Edison. Эти прототипы были устроены таким образом, чтобы при подключении эффективно работать с телефонами FirstNet, которые использовались в качестве точек доступа Wi-Fi для подключения к мобильной сети 4G. В ходе учений устройство WSG передавало в штаб видео, данные пульта и расположения.

Сценарии учений включали похищение и заминированный автобус, при этом полицейские силы использовали стреляющие краской ружья для пейнтбола вместо боевого оружия. Проблема, которую разработчики стремились решить с помощью WSG, заключалась в предоставлении персоналу оперативных штабов экстренных служб более точной и актуальной информации о происходящих событиях в ходе чрезвычайных ситуаций. Дополнительные данные, предоставляемые системой WSG, помогают лучше координировать работу и повысить общую эффективность и безопасность оперативных групп. В ходе этих испытаний были получены важные и полезные выводы, но в целом система WSG работала в соответствии с ожиданиями: руководители получили новую оперативную информацию, которой они не располагали до этого.

Извлечение уроков

Взаимодействие с пользователем — важнейший фактор в создании WSG. Экстренным службам требуется возможность гладкой интеграции устройств в рабочую среду. В случае с носимыми устройствами это означает, что сотрудники экстренных служб будут в буквальном смысле «носить устройства на себе». Если устройство WSG хоть в малейшей степени мешает или затрудняет работу, им попросту не будут пользоваться. Поэтому важно добиваться компактности устройства, его малого веса и простоты в использовании. 

Если говорить о компактности, то прототип WSG, использованный на учениях Urban Shield, не был оборудован модемом 4G, поэтому для подключения к Интернету требовалось подключать WSG к носимому вместе с этим устройством мобильному телефону (который работал в режиме точки доступа Wi-Fi). Прототип WSG, созданный для этих учений, был создан специально для подключения к телефонам Sonim*, поддерживающим FirstNet. Вместе два этих устройства образовали относительно компактный блок толщиной примерно вдвое больше самого телефона. Команды экстренных служб, участвовавших в учениях Urban Shield, не возражали против ношения этого устройства вместе с остальным оборудованием.

С технической точки зрения простота и надежность WSG соответствовали ожиданиям пользователей. При этом испытания в реальной обстановке позволили сделать полезные выводы для дальнейшего совершенствования устройства. Одна из обнаруженных проблем (сам факт ее обнаружения подчеркивает важность испытаний в реальных полевых условиях, а не в лаборатории) связана с нерегулярным увеличением задержек видеопотока, что приводило к рассинхронизации воспроизведения видео в штабе. Это достаточно серьезная проблема. На основе полученных данных программное обеспечение WSG было доработано. Теперь оно автоматически обнаруживает снижение пропускной способности сети и в соответствии с этим снижает кадровую скорость видео. Из-за этого воспроизведение видео становится менее плавным при снижении пропускной способности, но зато видео остается полностью синхронным.

Кроме того, разработчики Mutualink рассматривают возможность замены существующего алгоритма сжатия видео Motion JPEG на формат H.264 для дальнейшего повышения производительности видео. Еще одно направление доработок — встраивание модема 4G LTE в само устройство, чтобы для подключения к Интернету ему не требовалась точка доступа, реализуемая сотовым телефоном.

Решение Instant Command Center™

На учениях Urban Shield был получен ценный урок: было замечено, что для компьютеров штаба требуется столько места, что потребовалось установить дополнительную палатку в дополнение к палаткам, используемым для команд экстренных служб. При этом команды экстренных служб были отделены от штаба, а также потребовались дополнительные ресурсы. Сведение к минимуму таких ресурсоемких операций в быстроразвивающихся и напряженных чрезвычайных ситуациях даст ощутимые преимущества командам экстренных служб, а повышение эффективности будет способствовать более широкому внедрению ими новых технологий.

Эти наблюдения навели разработчиков WSG на идею использовать в штабе устройство Intel^® Compute Stickс четырехъядерными процессорами Intel^® Atom™ вместо полноразмерных ПК.  Использование Intel^® Compute Stick в штабах обеспечивает целый ряд преимуществ по сравнению как с полноразмерными ПК, так и с ноутбуками. Устройство Intel^® Compute Stick значительно компактнее большинства мобильных телефонов, поэтому оно исключительно портативное. Кроме того, оно оборудовано интерфейсами Bluetooth, Wi-Fi и USB, благодаря чему его можно легко подключить к любой сети.

Если установить на такое устройство программное обеспечение WSG для штабов экстренных служб, оператору достаточно будет просто вставить Intel^® Compute Stick в любой монитор или телевизор, оборудованный разъемом HDMI, чтобы за считанные секунды получить действующую штабную систему. Представьте, к примеру, чрезвычайную ситуацию в гостинице: любую комнату с телевизором можно мгновенно превратить в штаб экстренных служб и обеспечить полный контроль над ситуацией, для чего в других случаях потребовалось бы больше времени и ресурсов.

Рисунок 8. В штабе при испытаниях WSGна учениях UrbanShieldв 2015 г. 

Интернет вещей общественной безопасности

Такому направлению развития современных устройств, как Интернет вещей, и его важности для дальнейшего развития посвящено немало материалов, в том числе и подготовленных корпорацией Intel.  В 2015 году в повседневную жизнь вошло значительное количество современных технических решений — от устройств для «умного дома»до радиомаяков Bluetooth для магазинов. Компании Intel и Mutualink увидели возможность применить технологии и концепцию Интернета вещей к области общественной безопасности, в результате чего возникла инициатива «Интернет вещей общественной безопасности» (IoPST*).

WSG стало первым устройством, созданным в рамках сотрудничества этих компаний. За ним последуют и другие современные решения для безопасности. Одна из основных идей состоит в том, что миниатюрные компоненты, находящиеся внутри WSG, необязательно использовать только в носимых устройствах, с ними можно создать и целый ряд стационарных «умных устройств».

Например, на стенде корпорации Intel на выставке Maker Faireв Нью-Йорке компания Mutualink продемонстрировала прототип устройства, которое встраивается в блоки пожарной сигнализации. Идея состоит в том, чтобы не направлять данные в штаб, а развернуть выделенную сеть Wi-Fi для экстренных служб (под названием WiFi911*), которая включается при срабатывании сигнализации. Доступ к этой сети осуществляется автоматически при вводе простого пароля, известного экстренным службам.

Рисунок 9. Модуль Intel^®Edisonвнутри блока пожарной сигнализации как пример реализации инициативы «Интернет вещей общественной безопасности» (IoPST*) на выставке MakerFaireв Нью-Йорке в 2015 г.

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

Точки доступа сети WiFi911* можно встроить в любое электрооборудование, например в лампы освещения. Такие дополнительные компактные устройства легко встраиваются в современные энергосберегающие лампы. Кроме того, здесь реализуются все преимущества платформы Edison, вдохновившей разработчиков Mutualink на создание решений связи. Специалисты Mutualink уже успешно встроили модуль Intel^® Edison в прототип лампы при разработке WSG*.

Награды за современные решения

За новаторскую работу в рамках инициативы «Интернет вещей общественной безопасности» команда Mutualink, корпорации Intel и органов правопорядка Сан-Матео получила премию за инновации института Integrated Justice Information Systems (IJIS) 2016 года. Эта награда предназначена для технических новинок, важных для развития интеграции и взаимодействия в решениях органов правопорядка, общественной безопасности и государственной безопасности. Комитет института IJIS оказал всестороннюю поддержку испытаниям WSG на учениях Urban Shield и выразил благодарность компаниям Mutualink и Intel за достигнутые успехи.

Дальнейшие действия

Устройство WSG* в настоящее время по-прежнему находится на этапе разработки. Его коммерческий выпуск запланирован на 2016 г. Специалисты Intel и Mutualink используют это время, чтобы улучшить конструкцию устройства и добавить в него новые полезные функции, такие как возможность подключения к сотовым сетям 4G LTE и возможность сжатия видео. Также ведется работа над усовершенствованием штабного интерфейса.

Как и любые другие решения, предназначенные для использования в столь ответственных ситуациях, устройства WSG будут подвергнуты всесторонним тщательным испытаниям перед крупномасштабным развертыванием. После этого можно будет реализовать потенциал этих устройств для повышения оперативной эффективности экстренных служб в США.

О компании Mutualink

Компания Mutualink, Inc. занимается разработкой взаимодействующих платформ связи, реализующих возможности радиосвязи, передачи голоса, текста, видео, файлов данных, а также телефонной связи в безопасной среде. Системами Mutualink в настоящее время пользуются сотни государственных и частных организаций во всем мире, в том числе органы государственной безопасности и военные ведомства, войска специальных операций НАТО, полиция и пожарная охрана, больницы, школы, управления городского транспорта, коммунальные службы, магазины, казино и т. д. Mutualink — частная компания. Ее главный офис находится в городе Уоллингфорд, штат Коннектикут, США. Исследовательские центры компании расположены в США (г. Уэстфорд, штат Массачусетс, и г. Аллен, штат Техас) и Пуэрто-Рико (г. Маягуэс); офис по сотрудничеству с Министерством обороны США находится недалеко от Вашингтона. Дополнительные сведения см. на сайте www.mutualink.net.

Дополнительные ресурсы

Подробнее о Mutualinkсм. здесь.

Последняя информация о Urban Shieldдоступна здесь.

Intel, эмблема Intel и Intel Atom являются товарными знаками корпорации Intel в США и в других странах.

* Прочие наименования и товарные знаки могут быть собственностью третьих лиц. 

© Intel Corporation, 2016. Все права защищены.

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

Что это такое и как это можно использовать для повышения производительности NFV?

Обзор

Enhanced Platform Awareness (EPA) — это принцип, опирающийся на набор функций OpenStack Nova*, которые называются пакетами хостов и зонами доступности. Для ознакомления с EPA прочтите документ OpenStack* Enhanced Platform Awareness — Enabling Virtual Machines to Automatically Take Advantage of Advanced Hardware Capabilities(https://01.org/sites/default/files/page/openstack-epa_wp_fin.pdf).

Планировщик Nova использует пакеты хостов и зоны доступности, чтобы определить, на каком хосте следует запускать виртуальную машину. Этот выбор производится в зависимости от возможностей хоста и затребованной функциональности виртуальной машины (ВМ). Большая часть этих функций появилась в выпуске Grizzly, а в выпуске Kilo была доработана до набора фильтров и весов, которые используются планировщиком Nova для определения необходимости развертывания ВМ. Пример реализации NFV см. на портале Intel^® Network Buildersв документе A Path to Line-Rate-Capable NFV Deployments with Intel^® Architecture and the OpenStack* Kilo Release.

Эта статья представляет собой практическую инструкцию, ее цель — показать, каким образом можно использовать EPA в развертываниях OpenStack, а также помочь в использовании EPA, рассказав о таких понятиях, как разновидности, пакеты хостов и зоны доступности.

Архитектура OpenStack

В архитектуре OpenStack наибольшее значение имеет компонент Nova*. Кроме того, мы вкратце рассмотрим использование Glance для упрощения настройки в будущем.

Разновидности, атрибуты фильтров и дополнительные спецификации

Рекомендуется перечислить в списке атрибуты фильтров и определить стандартные атрибуты разновидностей, доступные дополнительные спецификации, обрабатываемые планировщиком, и прочие добавочные атрибуты фильтров, доступные в качестве условий отбора для планировщика.

INSTANCE_ID = “c32ac737-1788-4420-b200-2a107d5ad335”
nova boot --flavor 2 --image $INSTANCE_ID testinstance

В этом примере flavor 2 — это шаблон разновидности с именем m1.bigger, содержащий следующее:

• 1 виртуальный ЦП;
• 2 ГБ оперативной памяти;
• 10 ГБ рутового диска;
• 20 ГБ временного диска.

Управление разновидностями

Разновидность — это тип гостевого экземпляра или шаблона виртуального оборудования. Разновидность задает набор ресурсов ВМ, в том числе количество виртуальных ЦП, объем памяти и место на диске, выделяемое экземпляру ВМ. Пример разновидности экземпляра: зона ядра с 16 виртуальными ЦП и 16 384 МБ оперативной памяти.

Дополнительные сведения

Корпорация IBM представила атрибуты дополнительных спецификаций для некоторых своих решений в этом примере
(http://www-01.ibm.com/support/knowledgecenter/SST55W_4.3.0/liaca/liacaflavorextraspecs.html)

Дополнительные спецификации

Разновидность может включать не только базовые, но и дополнительные свойства. Эти дополнительные спецификации представляют собой пары «параметр — значение», их можно использовать для расширенной настройки в дополнение к настройке, предоставляемой базовыми свойствами разновидности. Эта настройка зависит от гипервизора.

Расширенная настройка, предоставляемая дополнительными спецификациями разновидности, может включать следующее. Обратите внимание, что все пары «параметр — значение», присоединенные к полю дополнительной спецификации, предназначены для фильтров планировщика.

Настройка ограничения операций ввода-вывода для заданного типа экземпляра
nova-manage flavor set_key --name m1.small --key quota:disk_read_bytes_sec --value 10240000
nova-manage flavor set_key --name m1.small --key quota:disk_write_bytes_sec --value 10240000
Настройка ограничения ЦП для заданного типа экземпляра
nova-manage flavor set_key --name m1.small --key quota:cpu_quota --value 5000
nova-manage flavor set_key --name m1.small --key quota:cpu_period --value 2500
Настройка ограничения пропускной способности для сетевого трафика экземпляра
nova-manage flavor set_key --name m1.small --key quota:vif_inboud_average --value 10240
nova-manage flavor set_key --name m1.small --key quota:vif_outboud_average --value 10240

Дополнительные сведения

OpenStack. Введение в разновидности образов: http://docs.openstack.org/openstack-ops/content/flavors.html

Изменение спецификаций разновидностей (из документа Установка и настройка OpenStackв Oracle^®Solaris 11.2 корпорации Oracle): http://docs.orack-aggregate1le.com/cd/E36784_01/html/E54155/flavoredit.html

«Набираем скорость: закрепление ЦП и топология NUMA в OpenStack», Стив Гордон, старший технический менеджер по продуктам, корпорация Red Hat: http://redhatstackblog.redhat.com/2015/05/05/cpu-pinning-and-numa-topology-awareness-in-openstack-compute/

Дополнительные спецификации и пространства имен

extra_specs — дополнительное свойство, содержащее пары «параметр — значение». Если параметр extra specsсодержит двоеточие (:), то все перед двоеточием считается пространством имен, а все после двоеточия считается параметром, с которым производится сравнение.

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

nova flavor-key 1 set capabilities:vcpus='>= 6'
nova flavor-key 1 set capabilities:vcpus_used='== 0'
nova flavor-show 1

+----------------------------+-----------------------------------------------------------------------+
| Property                   | Value                                                                 |
+----------------------------+-----------------------------------------------------------------------+
| OS-FLV-DISABLED:disabled   | False                                                                 |
| OS-FLV-EXT-DATA:ephemeral  | 0                                                                     |
| disk                       | 0                                                                     |
| extra_specs                | {u'capabilities:vcpus': u'>= 6', u:capabilities:vcpus_used': u'== 0'} |
| id                         | 1                                                                     |
| name                       | m1.tiny                                                               |
| os-flavor-access:is_public | True                                                                  |
| ram                        | 512                                                                   |
| rxtx_factor                | 1.0                                                                   |
| swap                       |                                                                       |
| vcpus                      | 1                                                                     |
+----------------------------+-----------------------------------------------------------------------+  

extra_specsполезно использовать при включении нескольких фильтров, чтобы избежать конфликтов.

Стратегии фильтрации

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

• планировщик (https://github.com/openstack/nova/tree/master/nova/scheduler),
• фильтры (https://github.com/openstack/nova/tree/master/nova/scheduler/filters),
• тесты (https://github.com/openstack/nova/tree/master/nova/tests/unit/scheduler/filters).

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

RamFilter

В документации для разработчиков OpenStack простота фильтров подчеркивается на примере RamFilter (https://github.com/openstack/nova/blob/master/nova/scheduler/filters/exact_ram_filter.py). Этот фильтр запрашивает точный объем памяти, необходимый для запуска гостевого образа.

class ExactRamFilter(filters.BaseHostFilter):"""Exact RAM Filter."""

    def host_passes(self, host_state, filter_properties):
        """Return True if host has the exact amount of RAM available."""
        instance_type = filter_properties.get('instance_type')
        requested_ram = instance_type['memory_mb']
        if requested_ram != host_state.free_ram_mb:
            LOG.debug("%(host_state)s does not have exactly ""%(requested_ram)s MB usable RAM, it has ""%(usable_ram)s.",
                      {'host_state': host_state,'requested_ram': requested_ram,'usable_ram': host_state.free_ram_mb})
            return False

        return True

Метод класса host_passesвозвращает значение True, если объем памяти, запрошенный для гостевого образа, в точности соответствует доступному объему на хосте, который в данный момент изучается на предмет отбора. Чуть более сложная и более полезная версия этого фильтра использует ram_allocation_ratioи производит сравнение с учетом коэффициентов выделения виртуальной памяти по отношению к физической памяти; по умолчанию этот коэффициент составляет не менее 1,5.

JsonFilter

Этот фильтр позволяет операторам записывать возможности хостов, соответствующих правилам, на основе простого синтаксиса, подобного JSON. Для сравнения свойств состояния хостов используются операторы «=», «<», «>», «in», «<=» и «>=». Вместе с ними можно использовать и логические операторы not, or и and. Убедитесь, что JsonFilter добавлен в параметр scheduler_default_filtersв /etc/nova/nova.confдля поддержки этой функциональности.

В приведенном ниже примере из теста будут отфильтрованы все хосты с ОЗУ больше или равной 1024 МБ и со свободным местом на диске больше или равном 200 ГБ.

['and',
['>=', '$free_ram_mb', 1024],
['>=', '$free_disk_mb', 200 * 1024]
]

Параметр scheduler_hintsиспользуется во множестве фильтров для команды загрузки Nova при запуске гостевого экземпляра.

nova boot --image cirros-0.3.1-x86_64-uec --flavor 1 \
--hint query=['>=','$free_ram_mb',1024] test-instance

ComputeCapabilitiesFilter

Фильтр ComputeCapabilitiesFilterвыдает только хосты, характеристики которых удовлетворяют запрошенным требованиям. Если не указаны extra_specs, то выводятся все хосты.

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

ImagePropertiesFilter

ImagePropertiesFilterотфильтровывает хосты на основе свойств, определенных в образе экземпляра. Он передает хосты, способные поддерживать указанные свойства образа, содержащиеся в экземпляре. К свойствам относится архитектура, тип гипервизора, версия гипервизора (только для гипервизоров Xen) и режим виртуальных машин.

Например, для экземпляра может требоваться хост с процессором архитектуры ARM* с гипервизором QEMU*. Можно добавить к образу свойства с помощью следующей команды:

glance image-update $img-uuid --property architecture=x86_64 \
   --property hypervisor_type=qemu

Фильтр проверяет следующие свойства образа

• Architecture: архитектура системы, требуемая для образа. Примеры значений: i686, x86_64, arm и ppc64.
• hypervisor_type: гипервизор, требуемый для образа. Примеры значений: xen, qemu и xenapi.
• hypervisor_version_requires: версия гипервизора, требуемая для образа. Это свойство поддерживается только для типа гипервизоров Xen. Его можно использовать, чтобы реализовать поддержку нескольких версий гипервизоров и предотвратить возможность работы экземпляров с новыми версиями Xen на устаревших версиях гипервизора. Если это свойство доступно, его значение сравнивается с версией гипервизора хоста.

Чтобы отфильтровать доступные хосты по версии гипервизора, добавьте свойство hypervisor_version_requiresк образу в качестве метаданных и передайте оператор и требуемую версию гипервизора в качестве значения:

glance image-update img-uuid --property hypervisor_type=xen \
   --property hypervisor_version_requires=">=4.3"

hypervisor_type: описывает двоичный интерфейс приложений (ABI) гипервизора, требуемый для образа. Примеры: xen — паравиртуальный ABI Xen 3.0, hvm — встроенный ABI, uml — паравиртуальный ABI пользовательского режима Linux, exe — виртуальный исполняемый ABI контейнера.

Хост может поддерживать несколько гипервизоров. Например, хост может определять [u'i686', u'qemu', u'hvm'] и [u'x86_64', u'qemu', u'hvm']. Если для гостевого экземпляра заданы свойства образа [u'x86_64', u'qemu', u'hvm'], то этот гостевой экземпляр может быть развернут на этом хосте.

Свойства образа для гостевого экземпляра можно задавать в виде подмножеств. Например, если для гостевого экземпляра заданы свойства образа [u'x86_64', u'hvm'], то этот гостевой экземпляр можно развернуть на хосте с поддерживаемым гипервизором [u'x86_64', u'qemu', u'hvm'].

Вес фильтров

Планировщик фильтров использует весовые коэффициенты в процессе оценки и отбора, чтобы сформировать предпочтения в отношении тех или иных хостов.

Вес хостов в планировщике фильтров основывается на параметре конфигурации scheduler_weight_classes. По умолчанию этот параметр имеет значение nova.scheduler.weights.all_weighers, при котором выбирается единственный доступный весовой коэффициент: RamWeigher. После этого хосты «взвешиваются» и сортируются по весу в порядке по убыванию.

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

В конце процесса планировщик сортирует выбранные хосты по весу и создает на них экземпляры.

Зоны доступности и пакеты хостов

Объединение хостов в пакеты

С помощью пакетов можно группировать хосты, обладающие какой-либо общей функциональностью или возможностью. При этом критерии группировки могут быть как крайне простыми (например, объем установленной памяти или тип ЦП), так и достаточно сложными (например, топология NUMA). Использование пакетов хостов в OpenStack осуществляется совершенно произвольно и не ограничивается никакими рамками.

Для создания пакета хостов используется команда novaaggregate-create.

$ nova aggregate-create rack-aggregate1
+----+-----------------+-------------------+-------+----------+
| Id | Name            | Availability Zone | Hosts | Metadata |
+----+-----------------+-------------------+-------+----------+
| 1  | rack-aggregate1 | None              |       |          |
+----+-----------------+-------------------+-------+----------+

При этом создается пакет хостов, доступный для оператора в качестве зоны доступности.

$ nova aggregate-create rack-aggregate2 tokyo-az
+----+-----------------+-------------------+-------+----------+
| Id | Name            | Availability Zone | Hosts | Metadata |
+----+-----------------+-------------------+-------+----------+
| 2  | test-aggregate2 | test-az           |       |          |
+----+-----------------+-------------------+-------+----------+

Эта команда создает пакет внутри зоны доступности Tokyo, а не в зоне доступности по умолчанию. С помощью пакетов можно дополнительно разделять зоны доступности при запуске гостевого экземпляра с помощью команды загрузки Nova.

Добавьте хост в пакет хостов: rack-aggregate2. Поскольку этот пакет хостов определяет зону дос­тупности tokyo-az, при добавлении хоста в этот пакет хост попадает в зону доступности tokyo-az.

$ nova aggregate-add-host 2 stack-compute1
Aggregate 2 has been successfully updated.

+----+-----------------+-------------------+---------------------+------------------------------------+
| Id | Name            | Availability Zone | Hosts               | Metadata                           |
+----+-----------------+-------------------+---------------------+------------------------------------+
| 2  | test-aggregate2 | tokyo-az          | [u'stack-compute1'] | {u'availability_zone': u'tokyo-az'}|
+----+-----------------+-------------------+---------------------+------------------------------------+

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

Пакеты хостов не раскрываются операторам явным образом. Администраторы сопоставляют разновидности с пакетами хостов. Для этого администраторы задают метаданные в пакете хостов и соответствующие дополнительные спецификации разновидности. После этого планировщик сравнивает запрос на запуск гостевого экземпляра данной разновидности с пакетом хостов, в метаданных которого содержится такая же пара параметра и значения. Вычислительные узлы и хосты могут находиться в составе нескольких пакетов хостов.

Интерфейс командной строки

Командная строка novaподдерживает следующие команды, связанные с пакетами хостов.

nova aggregate-list

Вывод списка всех пакетов хостов.

nova aggregate-create <name> [availability-zone]

Создание нового пакета с именем <имя>в зоне доступности [зона_доступности] (необязательно), если она указана. Команда возвращает идентификатор нового созданного пакета. Хосты могут быть доступными для нескольких пакетов хостов. Соблюдайте осторожность при добавлении хоста в еще один пакет, если этот хост также входит в зону доступности. Будьте внимательны при использовании команд aggregate-set-metadataи aggregate-updateво избежание путаницы при загрузке экземпляров разных зон доступности. При невозможности добавить какой-либо определенный хост в зону доступности, для которой он не предназначен, возникнет ошибка.

nova aggregate-delete <id>

Удалить пакет с идентификатором <ИД>

nova aggregate-details <id>

Показать сведения о пакете с идентификатором <ИД>

nova aggregate-add-host <id> <host>

Добавить хост с именем <хост> в пакет с идентификатором <ИД>

nova aggregate-remove-host <id> <host>

Удалить хост с именем <хост> из пакета с идентификатором <ИД>

nova aggregate-set-metadata <id> <key=value> [<key=value> ...]

Добавить или обновить метаданные (пары «параметр — значение»), связанные с пакетом с идентификатором <ИД>

nova aggregate-update <id> <name> [<availability_zone>]

Обновить имя и зону доступности (необязательно) для пакета.

nova host-list

Вывести список всех хостов службы.

nova host-update --maintenance [enable | disable]

Поместить хост в режим обслуживания или вывести хост из режима обслуживания.

Зоны доступности

С помощью зоны доступности указывается определенное расположение для загрузки гостевого экземпляра.

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

Чтобы указать зону доступности, в которой будет запущен гостевой экземпляр, добавьте параметр availability-zone к команде загрузки Nova.

nova boot --flavor 2 --image 1fe4b52c-bda5-11e2-a40b-f23c91aec05e \
   --availability-zone tokyo-az testinstance
nova show testinstance

+-------------------------------------+--------------------------------------------------------------+
| Property                            | Value                                                        |
+-------------------------------------+--------------------------------------------------------------+
| status                              | BUILD                                                        |
| updated                             | 2013-05-21T19:46:06Z                                         |
| OS-EXT-STS:task_state               | spawning                                                     |
| OS-EXT-SRV-ATTR:host                | styx                                                         |
| key_name                            | None                                                         |
| image                               | cirros-0.3.1-x86_64-uec(64d985ba-2cfa-434d-b789-06eac141c260)|
| private network                     | 10.0.0.2                                                     |
| hostId                              | f038bdf5ff35e90f0a47e08954938b16f731261da344e87ca7172d3b     |
| OS-EXT-STS:vm_state                 | building                                                     |
| OS-EXT-SRV-ATTR:instance_name       | instance-00000002                                            |
| OS-EXT-SRV-ATTR:hypervisor_hostname | styx                                                         |
| flavor                              | m1.bigger (2)                                                |
| id                                  | 107d332a-a351-451e-9cd8-aa251ce56006                         |
| security_groups                     | [{u'name': u'default'}]                                      |
| user_id                             | d0089a5a8f5440b587606bc9c5b2448d                             |
| name                                | testinstance                                                 |
| created                             | 2013-05-21T19:45:48Z                                         |
| tenant_id                           | 6c9cfd6c838d4c29b58049625efad798                             |
| OS-DCF:diskConfig                   | MANUAL                                                       |
| metadata                            | {}                                                           |
| accessIPv4                          |                                                              |
| accessIPv6                          |                                                              |
| progress                            | 0                                                            |
| OS-EXT-STS:power_state              | 0                                                            |
| OS-EXT-AZ:availability_zone         | tokyo-az                                                     |
| config_drive                        |                                                              |
+-------------------------------------+--------------------------------------------------------------+

В этом примере указывается, что экземпляр разновидности m1.bigger будет запущен в зоне доступности центра обработки данных в Токио. Зона доступности хоста задается в файле nova.confс помощью свойства node_availability_zone. Следующие параметры также можно настроить для зон доступности в файле /etc/nova/nova.conf:

default_availability_zone = nova

Зона доступности по умолчанию для вычислительного узла

default_schedule_zone = None

Зона доступности, используемая по умолчанию

internal_service_availability_zone = internal

Зона доступности, с которой связаны внутренние службы

Администраторы могут представить пакет хостов в виде зоны доступности.

Зоны доступности отличаются от пакетов хостов в том, что зоны доступности явным образом раскрыты для оператора, а каждый хост одновременно может быть в составе только одной зоны доступности. Администраторы могут использовать параметр default_availability_zoneдля настройки зоны доступности по умолчанию, в которой будет запланирован запуск экземпляров, если пользователь не укажет зону доступности.

Планировщик и фильтры

Обзор

Определение действий рабочего процесса для развертывания гостевого экземпляра

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

Вот процесс для использования пакетов хостов.

1. Проверьте, включены ли в планировщике пакеты хостов.

$ cat /etc/nova/nova.conf | grep scheduler_default_filters
scheduler_default_filters=AggregateInstanceExtraSpecsFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter

Для этой конкретной конфигурации хоста планировщик будет проверять следующие фильтры.

• Хосты работают и включены? (ComputeFilter)
• Хосты находятся в запрошенной зоне доступности? (AvailabilityZoneFilter)
• На хостах достаточный объем ОЗУ? (RamFilter)
• Хосты могут обслужить этот запрос? (ComputeFilter)
• Хосты соответствуют дополнительным спецификациям, сопоставленным с типом экземпляра? (ComputeCapabilitiesFilter).
• Хосты соответствуют свойствам архитектуры, типа гипервизора и режима ВМ, указанным для образа экземпляра? (ImagePropertiesFilter.

Дополнительные фильтры см. в разделе «Планировщик» в справочнике по настройке  (http://docs.openstack.org/liberty/config-reference/content/section_compute-scheduler.html).

2. Создайте пакет хостов.

nova aggregate-create rack-aggregate1 tokyo-az

Эта команда создает новый пакет хостов в токийской зоне доступности и создает идентификатор.

+----+----------------+-------------------+-------+----------+
| Id | Name           | Availability Zone | Hosts | Metadata |
+----+----------------+-------------------+-------+----------+
| 1  | rack-aggregate1| tokyo-az          |       |          |
+----+----------------+-------------------+-------+----------+

3. Добавьте характеристики пакета хостов с помощью идентификатора rack-aggregate1.

nova aggregate-set-metadata 1 fastnic=true

4. Добавьте хосты в пакет rack-aggregate1, чтобы планировщик мог запускать гостевые экземпляры.

nova aggregate-add-host 1 styx
nova aggregate-add-host 1 kerberos

+----+------------------+-------------------+--------------------- -+----------------------+
| Id | Name             | Availability Zone | Hosts                 | Metadata             |
+----+------------------+-------------------+-----------------------+----------------------+
| 1  | rack-aggregate1  | nova              | [u'styx', u'kerberos']| {u'fastnic': u'true'}|
+----+------------------+-------------------+-----------------------+----------------------+

5. Создайте разновидность m1.bigger и примените свойство rack-aggregate1.

nova flavor-create m1.bigger 6 16384 80 4
nova-manage instance_type set_key --name= m1.bigger --key=rack-aggregate1 --value=true

При этом будет создана новая разновидность и задано свойство extra_specs, что подтверждается командой flavor-show.

nova flavor-show m1.biggerc

+----------------------------+----------------------------+
| Property                   | Value                      |
+----------------------------+----------------------------+
| OS-FLV-DISABLED:disabled   | False                      |
| OS-FLV-EXT-DATA:ephemeral  | 0                          |
| disk                       | 80                         |
| extra_specs                | {u'fastnic': u'true'}      |
| id                         | 42                         |
| name                       | m1.bigger                  |
| os-flavor-access:is_public | True                       |
| ram                        | 16384                      |
| rxtx_factor                | 1.0                        |
| swap                       |                            |
| vcpus                      | 4                          |
+----------------------------+----------------------------+

6. Операторы могут использовать разновидность, чтобы гарантировать запуск гостевых экземпляров в rack-aggregate1.

$ nova boot --image f69a1e3e-bdb1-11e2-a40b-f23c91aec05e --flavor m1.bigger

Теперь зона доступности test-az определена и содержит один хост, поэтому пользователь может загрузить экземпляр и запросить эту зону доступности.

$ nova boot --flavor 10 --image 64d985ba-2cfa-434d-b789-06eac141c260 \    --availability-zone tokyo-az testinstance
$ nova show testinstance

+-------------------------------------+----------------------------------------------------------------+
| Property                            | Value                                                          |
+-------------------------------------+----------------------------------------------------------------+
| status                              | BUILD                                                          |
| updated                             | 2015-05-21T11:36:023                                           |
| OS-EXT-STS:task_state               | spawning                                                       |
| OS-EXT-SRV-ATTR:host                | devstack                                                       |
| key_name                            | None                                                           |
| image                               | cirros-0.3.1-x86_64-uec (64d985ba-2cfa-434d-b789-06eac141c260) |
| private network                     | 10.0.0.2                                                       |
| hostId                              | f038bdf5ff35e90f0a47e08954938b16f731261da344e87ca7172d3b       |
| OS-EXT-STS:vm_state                 | building                                                       |
| OS-EXT-SRV-ATTR:instance_name       | instance-00000002                                              |
| OS-EXT-SRV-ATTR:hypervisor_hostname | styx                                                           |
| flavor                              | m1.bigger (10)                                                 |
| id                                  | 107d332a-a351-451e-9cd8-aa251ce56006                           |
| security_groups                     | [{u'name': u'default'}]                                        |
| user_id                             | d0089a5a8f5440b587606bc9c5b2448d                               |
| name                                | testinstance                                                   |
| created                             | 2015-05-21T11:36:023                                           |
| tenant_id                           | 6c9cfd6c838d4c29b58049625efad798                               |
| OS-DCF:diskConfig                   | MANUAL                                                         |
| metadata                            | {}                                                             |
| accessIPv4                          |                                                                |
| accessIPv6                          |                                                                |
| progress                            | 0                                                              |
| OS-EXT-STS:power_state              | 0                                                              |
| OS-EXT-AZ:availability_zone         | tokyo-az                                                       |
| config_drive                        |                                                                |
+-------------------------------------+----------------------------------------------------------------+

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

Можно добавить метаданные в исходный пакет хостов rack-aggregate1, который не являлся зоной доступности.

$ nova aggregate-set-metadata 1 fastnic=true
Aggregate 1 has been successfully updated.

+----+-----------------+-------------------+-------+----------------------------+
| Id | Name            | Availability Zone | Hosts | Metadata                   |
+----+-----------------+-------------------+-------+----------------------------+
| 1  | rack-aggregate1 | None              | []    | {u'fastnic': u'true'}      |

Планировщику в этом случае известно следующее:

• для разновидности m1.bigger требуется, чтобы параметр fastnic имел значение true;
• у всех хостов в пакете rack-aggregate1 задано fastnic=true;
• хосты kerberos и styx входят в состав пакета rack-aggregate1.

Планировщик запускает новый гостевой экземпляр на наиболее доступном хосте из этих двух.

Существует ряд других соображений, касающихся использования пакетов хостов и зон доступности. Оператор OpenStack может использовать только зоны доступности, при этом только администратор может настраивать пакеты хостов. Пакеты хостов чаще всего настраиваются заблаговременно. Вот рекомендации относительно того, когда лучше использовать зоны доступности, а когда — пакеты хостов.

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

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

Планировщик Nova определяет, на каком хосте или вычислительном узле запустить гостевой экземпляр, основываясь на последовательности настраиваемых фильтров и весов. В следующем выпуске, который называется Liberty, планируется отделить планировщик от Nova и создать объект для метаданных образов. Текущая платформа планировщика играет важную роль в использовании ресурсов.

Новым является и планировщик с кэшированием. Он использует существующие средства для применения фильтров и весов планировщика, но кэширует список доступных хостов. Когда запрос пользователя передается планировщику с кэшированием, планировщик пытается запланировать выделение гостевого экземпляра на основе кэшированного списка хостов, что повышает производительность планировщика.

Появился новый фильтр планировщика AggregateImagePropertiesIsolation. Этот новый фильтр планирует запуск экземпляров на хостах на основе совпадения свойств образа для заданной области пространства имен со свойствами пакета хостов. Хосты, не входящие ни в один пакет хостов, остаются доступными для экземпляров на основе всех образов. Новые параметры настройки службы Nova aggregate_image_properties_isolation_namespaceи aggregate_image_properties_isolation_separatorопределяют, какие свойства образа учитываются фильтром.

Настройка фильтрации для доверенных вычислительных групп
с архитектурой Intel^®

В выпуске OpenStack Folsom появились доверенные вычислительные группы. В них при запуске гостевого экземпляра для определения его разрешений на использование целевого хоста используется сервер аттестации. См. следующие материалы.

http://wiki.openstack.org/TrustedComputingPools
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/trusted_filter.py

1. Задайте следующее значение в nova.conf

scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler,TrustedFilter

2. Добавьте раздел trusted computing в nova.conf

[trusted_computing]
server=10.10.10.10
port=8181
server_ca_file=/etc/nova/ssl.10.1.71.206.crt
api_url=/AttestationService/resources/PoolofHosts
auth_blob=i-am-openstack 

3. Добавьте требование trusted к существующей разновидности, выполнив следующую команду.

nova-manage instance_type set_key m1.tiny trust:trusted_host trusted

4. Перезапустите служб nova-compute и nova-scheduler service.

Сквозная работа PCI и SR-IOV

Убедитесь, что для вычислительного узла включена сквозная работа PCI согласно http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM

Настройте Nova

• Вычислительный узел:

pci_passthrough_whitelist: Список разрешенных PCI-устройств, доступных для виртуальных машин.

Пример:

pci_passthrough_whitelist=[{ "vendor_id":"8086","product_id":"1520"}]

определяет все PCI-устройства на платформе с параметром vendor_id, равным 0 x 8086, и параметром product_id, равным 0 x 1520, как доступные для назначения экземплярам.

• Узел контроллера:

pci_alias: An alias for a PCI passthrough device requirement.

Пример:

pci_alias={"vendor_id":"8086", "product_id":"1520", "name":"a1"}

определяет, что pci alias'a1'представляет запрос на PCI-устройства с параметром vendor_id, равным 0 x 8086, и параметром product_id, равным 0 x 1520.

• Узел планировщика:

включите фильтр PCI-устройств.

Пример:

scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler scheduler_available_filters=nova.scheduler.filters.all_filters scheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter scheduler_default_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter 

Создайте разновидность

Примечание. Этот шаг не требуется для поддержки сетевых адаптеров SR-IOV.

Дополнительные сведения о передаче запросов PCI-устройств посредством создания портов см. по адресу https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking.

Настройте разновидность, запрашивающую PCI-устройства. Пример:

nova flavor-key  m1.large set  "pci_passthrough:alias"="a1:2"

Обновите разновидность, которой требуется два PCI-устройства, каждое с параметром vendor_id, равным 0 x 8086, и параметром product_id, равным 0 x 1520.

Создайте виртуальную машину

Дополнительные сведения о передаче идентификатора порта запроса PCI-устройства: https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking.

nova boot --image new1 --key_name test --flavor m1.large 123

Создайте виртуальную машину с требованием PCI. Образ в этом случае содержит драйвер для назначенных устройств, test — пара из параметра и значения.

Проверьте экземпляр назначения

nova show 123

Для проверки состояния ВМ перед тем, как она станет активной.

nova ssh --private 123 -i test.pem

для входа в гостевой экземпляр. Команда lspci выводит список всех устройств.

Проверка состояния PCIс исправлениями APIPCI

Исправления API PCI предоставляют гипервизору серверов и ОС возможность показывать информацию о PCI для экземпляров и вычислительных узлов, а также предоставляют конечную точку для отображения информации о PCI.

• Получите исправления по адресу https://github.com/yjiang5/pci_api.git, примените исправление или скопируйте файлы подключаемого модуля расширения. Обновите файл политик, добавив две новые политики, и перезапустите службу API Nova.

"compute_extension:instance_pci": "",    "compute_extension:pci": "rule:admin_api",

• Попробуйте использовать API PCI.

nova pci-list node_id

показывает все PCI-устройства вычислительного узла с идентификатором node_id (используйте команду novahypervisor-listдля получения всех compute_nodeв системе)

nova list

получает назначение PCI-устройства экземпляру, os-pci:pci содержит идентификатор PCI-устройства.

nova pci-show id

показывает информацию о PCI-устройстве.

Примечание о сквозном использовании PCI-устройств

• alias "device_type"

Определять псевдоним с помощью device_typeне обязательно. В настоящее время не существует способа определения типа PCI-устройства из гипервизора, поэтому пока не задавайте device_typeв псевдониме:

pci_alias={"vendor_id":"8086", "product_id":"1520", "name":"a1, "device_type":"NIC""}

Если псевдоним с device_typeопределен в nova.conf, то device_typeбудет входить в состав спецификации запроса PCI, поэтому попытка запланировать выделение вычислительного узла согласно такому запросу будет безуспешной. Такое поведение нуждается в доработке путем усовершенствования планировщика, который можно настраивать так, чтобы не обращать внимания на тип устройства.

Дополнительные сведения

https://wiki.openstack.org/wiki/Pci_passthrough

https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking

Заключение

Надеемся, что информация и примеры в этом документе помогли вам понять, как лучше использовать разновидности EPA, пакеты хостов и зоны доступности для оптимизации развертывания OpenStack. Для получения дополнительных сведений прочтите статьи и посмотрите видеоролики, перечисленные в следующем разделе.

Дополнительные сведения

Информационные документы и сопутствующая документация

OpenStack* Enhanced Platform Awareness - Enabling Virtual Machines to Automatically Take Advantage of Advanced Hardware Capabilities (https://01.org/sites/default/files/page/openstack-epa_wp_fin.pdf).

Разработка высокопроизводительных гибких решений SDN и NFV с помощью открытой эталонной архитектуры серверных сетевых платформ Intel^® (http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/software-defined-networks-onp-paper.pdf)

Лекции на видео

«Разделяй и властвуй»: разделение ресурсов в облаке OpenStack (https://www.youtube.com/watch?v=H6I3fauKDb0)

Усовершенствования OpenStack для поддержки сценариев использования NFV (https://www.youtube.com/watch?v=5hZmE8ZCLLo)

Предоставление конечным пользователям облачных приложений с помощью хранилища артефактов Glance (https://www.youtube.com/watch?v=mbRrWFMBlLM)

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

В этой серии из двух статей о производительности и памяти описываются базовые принципы и приводятся советы для разработчиков по повышению производительности программного обеспечения.  Эти статьи затрагивают, в частности, работу памяти и компоновку. В первой частибыло рассказано об использовании регистров и о применении алгоритмов блокирования для повышения многократного использования данных. В этой части статьи сначала описывается компоновка данных для обычного распараллеливания — программирования для общей памяти с потоками, а затем распределенные вычисления по сетям MPI. В статье описываются понятия, связанные с распараллеливанием: векторизация (инструкции SIMD) и работа с общей памятью (многопоточная архитектура), а также вычисления с распределенной памятью. И наконец, в этой статье сравниваются компоновки данных «массив структур» (AOS) и «структура массивов» (SOA).

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

Программирование общей памяти с потоками

Давайте начнем с программирования общей памяти с потоками. Все потоки вместе обращаются к одной и той же памяти в пределах процесса. Существует множество моделей управления потоками. Наиболее известные среди них потоки Posix* и потоки Windows*. В работе, связанной с правильным созданием потоков и управлением ими, могут возникать ошибки. В современных программах, состоящих из множества модулей и создаваемых крупными командами разработчиков, часто возникают ошибки в параллельном программировании с использованием многопоточных вычислений. Разработано несколько пакетов для упрощения создания потоков, управления ими и наиболее эффективного использования параллельных потоков. Два самых популярных пакета — это OpenMP* и Intel^® Threading Building Blocks. Третья модель управления потоками — Intel^® Cilk™ Plus — не получила настолько широкого распространения, как OpenMP и Threading Building blocks. Все эти модели управления потоками создают пул потоков, который многократно используется каждой из параллельных операций и параллельных областей. В OpenMP есть преимущество — ступенчатое распараллеливание с помощью использования директив. При этом директивы OpenMP можно зачастую добавлять к существующим программам в пошаговом процессе и с минимальными изменениями кода. Если позволить библиотеке времени выполнения управлять обслуживанием потоков, это существенно упростит разработку многопоточных программ. Также предоставляется единая модель управления потоками, которой должны придерживаться все разработчики кода, что снижает вероятность возникновения некоторых распространенных ошибок. Оптимизированная библиотека управления потоками используется всеми разработчиками.

Принципы параллельного программирования, упомянутые во вводной части, состоят в том, чтобы размещать данные как можно ближе к месту, где они будут использоваться, и избегать перемещения данных. В многопоточном программировании в модели по умолчанию данные являются общими для всего процесса, к ним могут обращаться все потоки. Во вводных статьях по управлению потоками подчеркивается, насколько просто можно применить OpenMP к циклам do (Fortran*) или циклам for (C). Такие методы обычно значительно ускоряются при выполнении кода на двух или четырех ядрах. Зачастую эти методы наращиваются до 64 потоков или более. Впрочем, не менее часто дополнительные потоки не используются, причем в некоторых таких случаях это обусловлено неподходящей компоновкой данных. Дело в создании архитектуры, пригодной для параллельного кода.

Важно изучать возможности распараллеливания на более высоком уровне в стеке вызовов кода, чем первоначально предполагается разработчиком или средствами разработки. Если разработчик считает, что какие-либо задачи или данные можно обрабатывать параллельно, то попробуйте ответить на следующие вопросы (в свете закона Амдала): «Можно ли начать применять параллельные операции выше в стеке вызовов перед переходом к этому месту?», «Если я это сделаю, то увеличится ли параллельная область кода, что приведет к ускорению работы при задействовании большего числа потоков?».

Следует внимательно обдумать и размещение данных, и то, к каким данным может быть предоставлен общий доступ посредством сообщений. Компоновка данных должна предусматривать размещение данных там, где они используются больше всего, а оттуда их можно отправлять другим системам. Для приложений, представленных в таблице или в физическом домене с заданными разделами, программы MPI часто добавляют строку «фантомных» ячеек вокруг подчиненной таблицы или подчиненного домена. В «фантомных» ячейках сохраняются значения данных, отправленные процессом MPI, обновляющим эти ячейки. В многопоточных программах «фантомные» ячейки обычно не используются, но при снижении длины границы раздела для передачи сообщений желательно уменьшить границы разделов, использующих общую память. При этом снижается необходимость в блокировке потоков (или важных разделов) и вероятность образования конфликтов кэша, связанных с владением кэшем.

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

Рисунок 1. Скорость доступа к памяти, относительные задержки при доступе к данным

Если один поток выделяет и инициализирует данные, то эти данные обычно помещаются в память, ближайшую к процессору, в котором выполняется поток, выделяющий и инициализирующий память (рис. 1). Можно повысить производительность, если заставить каждый поток выделять и давать первую ссылку на память, которая в наибольшей степени будет использоваться этим потоком. Обычно этого достаточно для того, чтобы поток был запущен в области памяти, ближайшей к процессору. Если поток создан и активен, то ОС обычно оставляет его в этом же процессоре. Иногда бывает выгодно явным образом привязать поток к определенному ядру, чтобы избежать переноса потока между ядрами. Если данные имеют определенную компоновку, то может быть выгодно назначить или привязать потоки к определенным ядрам в соответствии с этой компоновкой. Библиотека выполнения Intel OpenMP (в составе Intel^® Parallel Studio XE 2016) содержит явные атрибуты сопоставления, эффективно работающие на сопроцессорах Intel^® Xeon Phi™.

Это атрибуты Compact, Scatter и Balanced. 

• Атрибут Compact сопоставляет последовательные или соседние потоки с симметричными многопоточными множествами (SMT) на одном ядре перед назначением потоков другим ядрам. Это идеальное решение для ситуаций, когда потоки обращаются к данным, общим для потоков с последовательной нумерацией (т. е. соседних потоков).
• Атрибут Scatter назначает по одному потоку каждому ядру, затем возвращается к первоначальному ядру для планирования других потоков в SMT.
• Атрибут Balanced равномерно назначает потоки с последовательными или соседними идентификаторами одному и тому же ядру. Это рекомендуемый начальный атрибут для оптимизации сопоставления потоков в документации компилятора Intel 16.0 C++. Параметр Balanced доступен только для семейства продуктов Intel^® Xeon Phi™. Для обычных ЦП он недействителен. Когда все SMT на платформе Xeon Phi задействованы, атрибуты Balanced и Compact работают одинаково.  Если же на платформе Xeon Phi задействованы лишь некоторые SMT, то метод Compact будет заполнять все SMT на первых ядрах, а некоторые ядра останутся свободными (в идеале).

При работе с десятками потоков важно размещать данные потоков как можно ближе к тому месту, где они будут использоваться. Компоновка данных важна и для программ, использующих сети MPI, и для многопоточных программ.  

В отношении памяти и компоновки данных следует учесть два фактора. Они достаточно просты, при этом могут иметь существенное влияние на работу. Первый — ложный общий доступ, второй — выравнивание данных. Ложный общий доступ — один из интересных факторов производительности в многопоточных программах. Все потоки, работающие с данными, независимы. Общего доступа нет, но строка кэша, содержащая оба фрагмента данных, является общей. Поэтому используется название «ложный общий доступ к данным»: как таковой общий доступ к данным отсутствует, но производительность при этом такая же, как если бы общий доступ применялся.

Представьте ситуацию, когда каждый поток увеличивает значение собственного счетчика, но сам счетчик при этом является одномерным массивом. Каждый поток увеличивает значение своего счетчика. Для увеличения значения счетчика ядро должно владеть строкой кэша. Например, поток A процессора 0 становится владельцем строки кэша и увеличивает значение счетчика iCount[A]. Одновременно поток A+1 процессора 1 увеличивает значение счетчика iCount[A+1]. Для этого ядро процессора 1 становится владельцем строки кэша и поток A+1 обновляет значение счетчика.  Поскольку значение в строке кэша изменяется, эта строка аннулируется для процессора 0. В следующей итерации процессор 0 становится владельцем строки кэша и изменяет значение iCount[A], что, в свою очередь, аннулирует эту строку кэша для процессора 1. Когда поток в процессоре 1 будет готов к записи, цикл повторяется. Значительное количество циклов процессора тратится на поддержку согласованности кэша, поскольку аннулирование строк кэша, восстановление контроля и синхронизация с памятью влияют на производительность.

Наилучшее решение — не аннулировать кэш. Например, при входе в цикл каждый поток может прочитывать свой счетчик и сохранять его в локальной переменной в своем стеке (при чтении кэш не аннулируется). Когда работа завершена, поток может скопировать свое локальное значение обратно в постоянное расположение (см. рис. 2).  Еще одно альтернативное решение — использовать заполнение данных, чтобы данные предпочтительно использовались одним определенным потоком в своей собственной строке кэша.

int iCount[nThreads] ;
      .
      .
      .
      for (some interval){
       //some work . . .
       iCount[myThreadId]++ // may result in false sharing
     }

int iCount[nThreads*16] ;// memory padding to avoid false sharing
      .
      .
      .
      for (some interval){
       //some work . . .
       iCount[myThreadId*16]++ //no false sharing, unused memory
     }

int iCount[nThreads] ; // make temporary local copy

      .
      .
      .
      // every thread creates its own local variable local_count
      int local_Count = iCount[myThreadID] ;
      for (some interval){
       //some work . . .
       local_Count++ ; //no false sharing
     }
     iCount[myThreadId] = local_Count ; //preserve values
     // potential false sharing at the end,
     // but outside of inner work loop much improved
     // better just preserve local_Count for each thread

Рисунок 2.

Ложный общий доступ может возникнуть и при назначении скалярных значений в соседние области памяти. Этот случай показан в приведенном ниже фрагменте кода:

int data1, data2 ; // data1 and data2 may be placed in memory
                   //such that false sharing could occur
declspec(align(64)) int data3;  // data3 and data4 will be
declspec(align(64)) int data4;  // on separate cache lines,
                                // no false sharing

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

Выравнивание данных

Производительность программ является оптимальной, когда данные, обрабатываемые инструкциями SIMD (AVX512, AVX, SSE4), выравниваются по границам строки кэша. Потеря производительности при доступе к невыровненным данным различается в зависимости от семейства процессоров. Работа сопроцессоров Intel^® Xeon Phi™ особенно сильно затрагивается выравниванием данных.    На платформе Intel Xeon Phi выравнивание данных имеет огромное значение. Эта разница не столь велика на других платформах Intel^® Xeon^®, но производительность все же заметно возрастает, когда данные выровнены по границам строки кэша. Поэтому разработчикам программ рекомендуется всегда выравнивать данные по 64-байтовым границам.  В системах Linux* и Mac OS X* для этого даже не нужно менять код, достаточно лишь использовать соответствующий параметр в командной строке компилятора Intel: /align:rec64byte.    

Для динамически выделяемой памяти в C можно заменить malloc()на _mm_alloc(datasize,64). Если используется _mm_alloc(), то следует использовать _mm_free()вместо free(). Подробная статья, посвященная выравниванию данных, находится здесь:  https://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization. 

Также ознакомьтесь с документацией к компилятору. Чтобы показать влияние выравнивания данных на две матрицы одинакового размера, мы создали и запустили блочный код умножения матриц, использованный в первой части этой статьи.   В первом случае матрица А была выровнена. Во втором случае матрица А была намеренно смещена на 24 байта (три значения типа Double). При этом производительность (использовался компилятор Intel 16.0) упала на 56–63 % для матриц размером от 1200 х 1200 до 4000 х 4000.  В первой части я привел таблицу с производительностью упорядочения циклов в разных компиляторах. Когда одна матрица была смещена, компилятор Intel перестал давать прирост производительности.  Разработчикам рекомендуется прочесть документацию к компиляторам, чтобы узнать о выравнивании данных и о доступных параметрах, чтобы компилятор мог с наибольшей эффективностью воспользоваться выровненными данными. Код для измерения производительности матрицы, смещенной по отношению к строке кэша, входит в состав кода для первой части статьи:  https://github.com/drmackay/samplematrixcode

Дополнительные сведения вы найдете в документации к компилятору.

Чтобы показать влияние выравнивания данных на две матрицы одинакового размера, мы создали и запустили блочный код умножения матриц, использованный в первой части этой статьи. Первая матрица была выровнена. Вторая матрица была намеренно смещена на 24 байта (три значения типа Double). При этом производительность (использовался компилятор Intel 16.0) упала на 56–63 % для матриц размером от 1200 х 1200 до 4000 х 4000.

Массив структур или структура массивов

Процессоры работают очень эффективно при последовательном обращении к памяти. Очень хорошо, если каждый элемент строки кэша перемещен в регистры SIMD. Если строки кэша также загружаются последовательно, то упреждающая выборка процессоров работает упорядоченно. В массиве структур компоновка данных может быть приблизительно такой:

struct {
   uint r, g, b, w ; // a possible 2D color rgb pixel layout
} MyAoS[N] ;

В этой компоновке значения rgb расположены последовательно. Если программа работает с данными цветовой плоскости, то с высокой вероятностью в кэш будет помещена вся структура, но каждый раз будет использовано только одно значение, например g. Если данные хранятся в структуре массивов, компоновка может быть примерно такой:

struct {
   uint r[N] ;
   uint g[N] ;
   uint b[N] ;
   uint w[N] ;
} MySoA ;

Если данные хранятся в структуре массивов и программа работает со всеми значениями g (или r, или b), то весь кэш с высокой вероятностью будет использован в работе при помещении в кэш одной строки кэша.    Данные эффективнее загружаются в регистры SIMD, благодаря чему повышается эффективность и производительность. Во многих случаях разработчики программ временно перемещают данные в структуру массивов для обработки, а затем копируют обратно, когда это становится нужно. Во всех возможных случаях лучше избегать этого дополнительного копирования, поскольку из-за него выполнение занимает больше времени.

Анализ Memory Access Pattern (MAP) в Intel (Vectorization) Advisor 2016 выявляет циклы с последовательным, непоследовательным и нерегулярным доступом:

В столбце Strides Distribution предоставляется совокупная статистика о том, насколько часто используется каждая модель в заданном цикле. На приведенном выше рисунке две трети горизонтальной полосы закрашены синим (это последовательный доступ к памяти), а правая треть закрашена красным (это непоследовательный доступ). Для кода с компоновкой «массив структур» Advisor также может получить «рекомендацию» для преобразования массива структур в структуру массивов.  

Анализы моделей доступа и локальности памяти упрощены в Advisor MAP, они дополнительно предоставляют метрику использования памяти и сопоставляют диагностику каждого «шага» (то есть модель доступа) с определенными именами объектов и массивов C++ или Fortran*. Дополнительные сведения о Intel Advisor см. на сайтах

https://software.intel.com/en-us/get-started-with-advisor и https://software.intel.com/en-us/intel-advisor-xe

Компоновки «структура массивов» и «массив структур» применяются во множестве графических программ, в программах для расчета динамики частиц (например, молекулярной динамики), для моментальных данных и свойств (массы, расположения, скорости, заряда), которые могут быть связаны с точкой или с определенным телом. Как правило, структура массивов работает эффективнее и быстрее.

В компиляторе Intel, начиная с версии 2016 Update 1, преобразование «массив структур» -> «структура массивов» упрощено за счет применения шаблонов компоновки данных Intel^® SIMD (Intel^® SDLT). С помощью шаблонов SDLT можно просто переопределить контейнер массива структур следующим образом:

SDLT_PRIMITIVE(Point3s, x, y, z)
sdlt::soa1d_container<Point3s> inputDataSet(count);  

Это позволит обращаться к экземплярам Point3s по модели структуры массивов. Подробнее о SDLT см. здесь.

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

https://software.intel.com/en-us/articles/a-case-study-comparing-aos-arrays-of-structures-and-soa-structures-of-arrays-data-layouts

и

https://software.intel.com/en-us/articles/how-to-manipulate-data-structure-to-optimize-memory-use-on-32-bit-intel-architecture
http://stackoverflow.com/questions/17924705/structure-of-arrays-vs-array-of-structures-in-cuda

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

Заключение

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

Полный код можно загрузить здесь: https://github.com/drmackay/samplematrixcode

Если вы еще не читали первую часть этой статьи, то она находится здесь.

Примените описанные методики и оцените, насколько повысится производительность кода.

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