• Анатомия GNU/Linux

    Какое-то время назад на Хабре была небольшая волна постов на тему «Почему я [не] выбрал Linux». Как порядочный фанатик я стриггерился, однако решил, что продуктивнее что-нибудь рассказать о своей любимой системе, чем ломать копии в комментариях.

    У меня сложилось впечатление, что многие пользователи GNU/Linux слабо представляют, из чего сделана эта операционная система, поэтому утверждают, что она сляпана из попавшихся под руку кусков. В то же время, архитектура большинства дистрибутивов является устоявшейся и регламентируется рядом стандартов, включая стандарт графического окружения freedesktop.org и Linux Standard Base, расширяющий стандарты Unix. Мне при знакомстве с GNU/Linux несколько лет назад для погружения не хватало простой анатомической карты типичного дистрибутива, поэтому я попробую рассказать об этом сам.

    Читать далее
  • Linux в режиме реального времени



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

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

      Возможности ядра в реальном времени существует уже более десяти лет в экосистеме программ с открытым исходным кодом. Столько же времени доступна поддержка Red Hat Enterprise Linux (RHEL) для ядра реального времени. Тем не менее многие системные администраторы неверно истолковывают его основные концепции и фактическое рабочее поведение. В этой статье я опишу некоторые из его основных функций, отличия от стандартного ядра и шаги по установке.
      Читать дальше →
    • Суперсовременный OpenGL. Часть 1



        Всем привет. Все кто хоть немного разбирался в теме OpenGL знают, что существует большое количество статей и курсов по этой теме, но многие не затрагивают современный API, а часть из них вообще рассказывают про glBegin и glEnd. Я постараюсь охватить некоторые нюансы нового API начиная с 4-й версии. Ссылка на вторую часть статьи
        Читать дальше →
      • Суперсовременный OpenGL. Часть 2



          Всем хорошего настроения и температуры за окном пониже. Как и обещал, публикую продолжение статьи по супер-пупер современному OpenGL. Кто не читал первую часть — Суперсовременный OpenGL. Часть 1.

          Возможно повезет и я смогу весь оставшийся материал впихнуть в эту статью, это не точно…
          Читать дальше →
        • Туториал по Unreal Engine: Cel Shading

          • Translation
          image

          Благодаря физически точному рендерингу в Unreal Engine 4 удобно разрабатывать реалистичные игры. Модель рендеринга имитирует взаимодействие света с материалами, что приводит к созданию реалистичной картинки. Однако если вы хотите разработать игру со стилизованным внешним видом, то вам придётся исследовать другие техники.

          Один из способов создания стилизации — использование cel shading (также известного как toon-шейдинг). Эта техника подражает затенению, обычно используемому в мультфильмах и аниме. Примеры её использования можно увидеть в таких играх, как Jet Set Radio, The Legend of Zelda: The Wind Waker и Gravity Rush.

          В этом туториале вы научитесь следующему:

          • Создавать и использовать материал постобработки
          • Создавать cel-шейдер
          • Изолировать cel-шейдер для отдельных мешей
          • Управлять цветовыми полосами с помощью таблиц поиска
          Читать дальше →
          • +24
          • 17k
          • 6
        • Тридцать шесть градусов красоты

            Сеточные системы координат, в которых плоскость делится на одинаковые симметричные элементы — на квадраты, треугольники, шестиугольники, достаточно известны. Им соответствуют квадратная, треугольная, шестиугольная симметрия. Но еще существует симметрия десятиугольная.

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



            Расскажу как это нарисовать.
            Читать дальше →
          • Невозможная сковорода и другие победы плиток Пенроуза

            • Translation
            image

            В 1974 году британский математик Роджер Пенроуз создал революционный набор плиток, который можно использовать для заполнения бесконечной плоскости никогда не повторяющимся узором. В 1982 году израильский кристаллограф Даниэль Шехтман открыл металлический сплав, атомы которого были выстроены в порядке, никогда ранее не встречавшемся в материаловедении. Пенроуз достиг масштабного общественного признания, редко достающегося математикам. Шехтман получил Нобелевскую премию. Оба учёных бросили вызов человеческой интуиции и изменили основы понимания структуры природы, обнаружив, что бесконечная вариативность может возникать даже в высокоупорядоченной среде.
            Читать дальше →
          • Окна на чистом WinAPI. Или просто о сложном

              Disclaimer

              Казалось бы, что WinAPI уходит в прошлое. Давно уже существует огромное количество кросс-платформенных фреймфорков, Windows не только на десктопах, да и сами Microsoft в свой магазин не жалуют приложения, которые используют этого монстра. Помимо этого статей о том, как создать окошки на WinAPI, не только здесь, но и по всему интернету, исчисляется тысячами по уровню от дошколят и выше. Весь этот процесс разобран уже даже не по атомам, а по субатомным частицам. Что может быть проще и понятнее? А тут я еще…

              Но не все так просто, как кажется.
              Читать дальше →
            • Sparse residency текстуры в Vulkan

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

              image
              Читать дальше →
              • +21
              • 2.5k
              • 2
            • С++ Concept-Based Polymorphism в продуктовом коде: PassManager в LLVM

                Сегодня речь пойдет про одну интересную идиому, которую ввел Шон Парент (Adobe) — известный деятель в C++-сообществе. Он часто выступает с докладами и публикует цикл статей Better Code. Одна из его идей, которую используют в Photoshop — это Concept-Based Polymorphism. Это когда мы реализуем полиморфизм не через явное наследование, а с помощью техники, включающей обобщенное программирование, и по итогам получаем некоторые дополнительные преимущества.

                Статья устроена следующим образом:

                1. Что вообще такое Concept-Based Polymorphism и зачем он нужен
                2. Немного про LLVM и ее устройство
                3. Пример Concept-Based Polymorphism в LLVM PassManager
                4. Преимущества подхода



                Картинка, иллюстрирующая тезис «Наследование — это зло». Источник
                Читать дальше →
              • Разработка компилятора для TypeScript на TypeScript на базе LLVM



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

                  А что из этого вышло, Дмитрий изложил на прошедшей HolyJS 2019 Moscow. Под катом вы найдете видео и конспект его доклада.
                  Читать дальше →
                  • +30
                  • 4.9k
                  • 4
                • Как работает рендеринг 3D-игр: освещение и тени

                  • Translation
                  Реализация подавляющего большинства визуальных эффектов в современных играх зависит от продуманного использования освещения и теней. Без них игры были бы скучными и безжизненными. В четвёртой части анализа рендеринга 3D-игр мы сосредоточимся на том, что происходит в 3D-мире наряду с обработкой вершин и наложением текстур. Нам снова понадобится много математики, а также уверенного понимания основ оптики.

                  Часть 1: обработка вершин

                  Часть 2: растеризация и трассировка лучей

                  Часть 3: текстурирование и фильтрация текстур

                  Вспомним пройденное


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


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

                  Теней не было, потому что они не входили в задачу программистов: PC того времени представлял собой процессор на 66 МГц (то есть на 0,066 ГГц!), жёсткий диск на 40 МБ и 512-килобайтную графическую карту с минимальными 3D-возможностями. Перенесёмся на 23 вперёд: в знаменитой перезагрузке серии мы видим совершенно другую историю.


                  Для рендеринга этого кадра использовалось множество технологий, он может похвастаться такими этапами, как screen space ambient occlusion, pre-pass depth mapping, фильтры размытия боке, операторы тональной коррекции, и так далее. Расчёт освещения и затенения каждой поверхности выполняется динамически: они постоянно изменяются в зависимости от условий окружающей среды и действий игрока.
                  Читать дальше →
                  • +27
                  • 10.7k
                  • 4
                • WireGuard — быстрый и безопасный VPN в ядре Linux


                    Рис. 1. OpenVPN vs WireGuard, тест Ars Technica

                    WireGuard — свободный и открытый протокол виртуальных частных сетей, призванный заменить IPsec и OpenVPN. В январе 2020 года после полутора лет доработки кода всё-таки состоялось долгожданное событие — Линус Торвальдс принял VPN WireGuard в основную ветку Linux 5.6.

                    Очень скоро этот VPN станет частью ядра Linux — сердца операционной системы с открытым исходным кодом, на которой работает весь мир, от веб-серверов до телефонов Android и автомобилей. Это действительно важное событие, потому что WireGuard устроен на порядок проще и логичнее предыдущих VPN. В июне 2019 года получено автоматизированное криптографическое доказательство математики протокола.
                    Читать дальше →
                  • Программисты, давайте изучать исходники классических программ

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

                    Мы полагаем, что разработчикам следует изучать исходники программ, оказавших большое влияние, подобно тому, как архитекторы изучают здания, оказавшие влияние на архитектуру (и критикуют их). Чем повторять те же ошибки снова и снова, мы должны изучить большую работу, проделанную до нас, и вынести из неё уроки.
                    Читать дальше →
                  • Основы формата GLTF и GLB, часть 1

                      Что такое GLTF и GLB?


                      GLTF (GL Transmission Format) — это формат файла для хранения 3Д сцен и моделей, который является крайне простым в понимании (структура записана в стандарте JSON), расширяемым и легко взаимодействующим с современными веб-технологиями. Данный формат хорошо сжимает трёхмерные сцены и минимизирует обработку во время выполнения приложений, использующих WebGL и другие API. GLTF сейчас активно продвигается Khronos Group как JPEG от мира 3D. На сегодняшний день используется GLTF версии 2.0. Существует и бинарная версия данного формата, которая называется GLB, единственное различие которого в том, что все хранится в одном файле с расширением GLB.


                      Эта статья — 1 часть из 2х. В ней мы с вами рассмотрим такие артефакты формата и их атрибуты, как Scene, Node, Buffer, BufferView, Accessor и Mesh. А во второй статье мы рассмотрим оставшиеся: Material, Texture, Animations, Skin и Camera. Больше общей информации о формате можно найти здесь.
                      Если в процессе просмотра статьи захочется лично поработать с данным форматом, то можете скачать модели GLTF 2.0 с официального репозитория Khronos на GitHub


                      image


                      Проблематика и её решение


                      Изначально GLTF формат был задуман Khronos Group как решение для передачи 3D контента по интернету и был призван минимизировать количество импортеров и конвертеров, разные виды которых создаются при работе с графическими API.


                      image

                      На текущий момент GLTF и его бинарный брат GLB используются как унифицированные форматы и в CAD программах (Autodesk Maya, Blender и т. д.), в игровых движках (Unreal Engine, Unity и прочих), AR/VR приложениях, соц. сетях и т.д.

                      Читать дальше →
                      • +17
                      • 15.7k
                      • 3
                    • Основы формата GLTF и GLB, часть 2

                        Данная статья является продолжением рассмотра основ GLTF и GLB форматов. Вы можете найти первую часть статьи здесь. В первой части мы рассмотрели с вами зачем изначально планировался формат, а также такие артефакты и их атрибуты GLTF формата как Scene, Node, Buffer, BufferView, Accessor и Mesh. В данной же статье мы рассмотрим Material, Texture, Animations, Skin, Camera, а также закончим формировать минимальный валидный GLTF файл.


                        image

                        Material и Texture


                        С мешем неразрывно связаны материалы и текстуры. При необходимости меш может быть анимирован. Материал хранит информацию о том, как модель будет отрендерена движком. GLTF определяет материалы, используя общий набор параметров, которые основаны на Physical-Based Rendering (PBR). PBR модель позволяет создавать “физически корректное” отображение объекта в разных световых условиях благодаря тому, что шейдинговая модель должна работать с “физическими” свойствами поверхности. Есть несколько способов описания PBR. Самая распространенная модель — это metallic-roughness model, которая и используется по умолчанию в GLTF. Также можно использовать и specular-glosiness модель, но только при помощи отдельного расширения (extenstion). Основные атрибуты материала следующие:


                        1. name — имя меша.
                        2. baseColorFactor/baseColorTexture — хранит инфомрацию о цвете. В случае атрибута Factor информация хранится в числовом значении для RGBA, в случае Texture — хранится ссылка на текстуру в объекте textures.
                        3. metallicFactor — хранит информцию о Metallic
                        4. roughnessFactor — хранит информцию об Roughness
                        5. doubleSided — имеет значение true либо false (значение по умолчанию) и указывает на то, будет ли меш рендериться с обоих сторон или только с "лицевой" стороны.
                        Читать дальше →
                        • +13
                        • 5.9k
                        • 8
                      • Learn OpenGL. Урок 6.1. PBR или Физически-корректный рендеринг. Теория

                        • Translation
                        • Tutorial
                        OGL3

                        Физически-корректный рендеринг


                        PBR, или физически-корректный рендеринг (physically-based rendering) это набор техник визуализации, в основе которых лежит теория, довольно хорошо согласующаяся с реальной теорией распространения света. Поскольку целью PBR является физически достоверная имитация света, он выглядит гораздо более реалистичным по сравнению с использованными нами ранее моделями освещения Фонга и Блинна-Фонга. Он не только лучше выглядит, но и дает неплохое приближение к реальной физике, что позволяет нам (и в частности художникам) создавать материалы, основанные на физических свойствах поверхностей, не прибегая к дешевым трюкам дабы заставить освещение выглядеть реалистично. Главным преимуществом такого подхода является то, что создаваемые нами материалы будут выглядеть как задумано независимо от условий освещения, чего нельзя сказать о других, не PBR подходах.

                        Читать дальше →
                      • Маленькие трюки DirectX и HLSL

                          Привет, Хабр! Решил написать статью-заметку о небольших трюках, которые использую в своем скромном движке. Это скорее заметка самому-себе, и матёрые программисты лишь усмехнутся, но, думаю, новичкам она может пригодится.
                          Читать дальше →
                          • +31
                          • 17.1k
                          • 8
                        • Процессорные войны. История синего зайца и красной черепахи

                          Современная история противостояния Intel и AMD на процессорном рынке ведёт свой отсчет еще со второй половины 90-х. Эпоха грандиозных преобразований и выхода в мэйнстрим, когда Intel Pentium позиционировался как универсальное решение, а Intel Inside стал чуть ли не самым узнаваемым слоганом в мире, ознаменовалась яркими страницами в истории не только синих, но и красных – начиная с поколения K6, AMD неустанно соперничали с Intel во многих сегментах рынка. Однако именно события чуть более позднего этапа – первой половины нулевых – и сыграли важнейшую роль в появлении легендарной архитектуры Core, до сих пор лежащей в основе процессорной линейки Intel.

                          Немного истории, истоков и революции


                          Начало 2000-х годов во многом связывают с несколькими этапами в развитии процессоров – это и гонка за заветной частотой 1 ГГц, и появление первого двухъядерного процессора, и ожесточение борьбы за первенство в массовом десктопном сегменте. После безнадежного устаревания Pentium, и выхода на рынок Athlon 64 X2 Intel представила процессоры поколения Core, ставшие в итоге поворотной точкой в развитии индустрии.

                          image

                          Первые процессоры Core 2 Duo были анонсированы в конце июля 2006 года – более чем через год после выхода Athlon 64 X2. В работе над новым поколением Intel руководствовалась в первую очередь вопросами архитектурной оптимизации, добившись высочайших показателей энергоэффективности уже в первых поколениях моделей на базе архитектуры Core под кодовым названием Conroe – они превосходили Pentium 4 в полтора раза, и при заявленном теплопакете в 65 Вт стали, пожалуй, самыми энергоэффективными процессорами на рынке на тот момент. Выступая в роли догоняющей (что бывало нечасто), Intel реализовала в новом поколении поддержку 64-битных операций с архитектурой EM64T, новый набор инструкций SSSE3, а также обширный пакет технологий виртуализации на базе х86.

                          image
                          Кристалл микропроцессора Core 2 Duo

                          Читать дальше →
                        • Ёлочка в командной строке

                            Скоро Новый Год, думать о серьёзной работе уже не хочется.

                            Все стараются что-нибудь украсить к празднику: дом, офис, рабочее место… Давайте и мы что-нибудь украсим! Например, приглашение командной строки. В какой-то мере командная строка – тоже рабочее место.

                            В некоторых дистрибутивах она уже «украшена»:



                            В других – она серая и неприметная:



                            А мы можем сделать, например, вот так:



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