Эволюция современных графических процессоров началась с появления в 1995 году первых 3D-карт, за которым последовало широкое распространение 32-битных операционных систем и недорогих персональных компьютеров.

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

Первые дни потребительской 3D-графики были Диким Западом конкурирующих идей: от способов реализации оборудования до использования различных техник рендеринга и интерфейсов приложений и данных. У первых графических систем имелся фиксированный конвейер функций (fixed function pipeline, FFP) и архитектура, следовавшая по очень строгому пути обработки; при этом графические API практически у каждого производителя 3D-чипов были собственные.

3D-графика превратила довольно унылую PC-индустрию в шоу света и магии, но своим существованием она обязана многим поколениям инноваций. В этой серии статей мы подробно рассмотрим историю GPU: первые дни потребительской 3D-графики, совершившую переворот 3Dfx Voodoo, консолидацию отрасли в начале века и современные GPGPU.

Продвинутое освещение

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

В предыдущей статье мы научились запускать Hello World ядро и написали пару функций для работы со строками. Теперь пришло время расширить библиотеку С чтобы можно было реализовать kprintf и другие необходимые функции. Поехали!

Здравствуй Хабр!

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

Все современные процессоры Intel и AMD поддерживают технологию аппаратной виртулизации.
И так, в моем распоряжении был ноутбук с H77 чипсетом и Intel Core i7-3820QM процессором. Согласно спецификации от производителя, мой процессор поддерживал Intel Virtualization Technology (VT-x) и Intel Virtualization Technology for Directed I/O (VT-d) технологии. Если первая имеется почти на всех новых ноутбуках, то вторая технология встречается только на топовых моделях. Но она дает много преимуществ, как например прямой проброс GDU в виртуальную среду, соответственно клиентская машина получает полную поддержку 3D. Но давайте не будем углубляться в технологии, отличные от тематики данной статьи.

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

Горький опыт сериалов, которые хорошо начинаются и разочаровывающе заканчиваются, удерживал меня от написания восторженного обзора на сериал «Чернобыль» до этой недели. И сейчас, когда вышла последняя, пятая серия, к сожалению, я вынужден сказать, что это отличный сериал, это прекрасный повод узнать больше о чернобыльской катастрофе, его обязательно стоит посмотреть, если вы еще не, но, если первые три серии, на мой взгляд, поднимаются до уровня моего самого любимого фильма «Аполлон-13», то две последние, опять же, по моему мнению, оказываются заметно похуже.


Кадр из сериала

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

Я хотел бы подарить сообществу Хабра статью, в которой стараюсь дать достаточно полное описание подходов к алгоритмам подсчёта единичных битов в переменных размером от 8 до 64 битов. Эти алгоритмы относятся к разделу так называемой «битовой магии» или «битовой алхимии», которая завораживает своей красотой и неочевидностью многих программистов. Я хочу показать, что в основах этой алхимии нет ничего сложного, и вы даже сможете разработать собственные методы подсчёта единичных битов, познакомившись с фундаментальными приёмами, составляющими подобные алгоритмы.

Большинство компиляторов имеют следующую архитектуру:



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

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

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

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


, — cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

Недавно я начал разбираться с рендерингом «Ведьмака 3». В этой игре есть потрясающие приёмы рендеринга. Кроме того, она великолепна с точки зрения сюжета/музыки/геймплея.



В этой статье я расскажу о решениях, использованных для рендеринга The Witcher 3. Она не будет такой всеобъемлющей, как анализ графики GTA V Адриана Корреже, по крайней мере, пока.

Мы начнём с реверс-инжиниринга тональной коррекции.

Гамма-коррекция

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

В данной статье рассматривается перехват функций графического API на примере DirectX 9 под x64 применительно к игре Dota 2.

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

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

Первая часть
Вторая часть

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

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

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

Содержание

1. Память – пустая книга
2. Управление памятью: от оборудования к программному обеспечению
3. Базовая реализация Python
4. Концепция глобальной блокировки интерпретатора (Global Interpreter Lock, GIL)
5. Сборщик мусора
6. Управление памятью в CPython:
   
   • Пулы
   • Блоки
   • Арены
7. Заключение

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

Прочитав эту статью, вы:

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

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

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

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

Введение

Из прошлой статьи мы узнали о принципах страничной организации памяти и о том, как работают четырёхуровневые страничные таблицы на x86_64. Мы также обнаружили, что загрузчик уже настроил иерархию таблиц страниц для нашего ядра, поэтому ядро работает на виртуальных адресах. Это повышает безопасность, но возникает проблема: как получить доступ к настоящим физическим адресам, которые хранятся в записях таблицы страниц или регистре CR3?

Rise of the Tomb Raider (2015 год) — это сиквел превосходного перезапуска Tomb Raider (2013 год). Лично я нахожу обе части интересными, потому что они отошли от стагнирующей оригинальной серии и рассказали историю Лары заново. В этой игре, как и в приквеле, центральное место занимает сюжет, она предоставляет увлекательные механики крафтинга, охоты и скалолазания/исследований.

В Tomb Raider использовался разработанный Crystal Dynamics движок Crystal Engine, также применявшийся в Deus Ex: Human Revolution. В сиквеле использовали новый движок под названием Foundation, ранее разрабатывавшийся для Lara Croft and the Temple of Osiris (2014 год). Его рендеринг можно в целом описать как тайловый движок с предварительным проходом освещения, и позже мы узнаем, что это означает. Движок позволяет выбирать между рендерерами DX11 и DX12; я выбрал последний, по причинам, которые мы обсудим ниже. Для захвата кадра использовался Renderdoc 1.2 на Geforce 980 Ti, в игре включены все функции и украшательства.

Анализируемый кадр

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

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

Сразу скажу, что меня интересовал только вариант, в котором не пришлось бы менять существующий код проекта (как, например, в случае с RCCPP или cr, где весь потенциально перезагружаемый код должен быть в отдельной динамически загружаемой библиотеке).

"Как так?" — подумал я, и принялся раскуривать фимиам.

Предыстория

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

Как-то весенней ночью у меня родилась гениальная идея — попробовать себя в написании собственной ОС, которая может позволить запускать программы, работать с устройствами, да и в общем выжимать всю мощь из Intel'овской архитектуры в своих нуждах: к примеру, для своей фабрики или чего-либо иного. Моей целью было и есть написание такой ОС, которая могла бы позволить максимальную производительность для каких-то конкретных задач, не тратя процессорное время на всяческие излишества. В основном я преследую лишь спортивный интерес, получение опыта для себя в системном программировании и написания драйверов для устройств, которые используются повсеместно. Что из этого вышло — решать вам, сразу говорю, что не надо писать комментарии про создание собственного дистрибутива линукса, и преследовал интерес написать всё «From scratch» — с нуля, дабы хорошо погрузиться в тему ОСдева. Сразу хочу выразить огромную благодарность Бенджамину Лунту и форуму OSDev, так же как их Вики. Бен помог мне разобраться с EHCI, что несомненно внесло огромный вклад в мою ОС — USB устройства, они везде! Так же передо мной стояла задача создать собственную архитектуру, удобную мне, не исключая использование стандартов ELF-файлов.

Представляем вашему вниманию технику создания ассемблерных программ с перекрываемыми инструкциями, – для защиты скомпилированного байт-кода от дизассемблирования. Эта техника способна противостоять как статическому, так и динамическому анализу байт-кода. Идея состоит в том, чтобы подобрать такой поток байтов, при дизассимблировании которого начиная с двух разных смещений – получались две разные цепочки инструкций, то есть два разных пути выполнения программы. Мы для этого берём многобайтовые ассемблерные инструкции, и прячем защищаемый код в изменяемых частях байт-кода этих инструкций. С целью обмануть дизассемблер, пустив его по ложному следу (по маскирующей цепочке инструкций), и уберечь от его взора скрытую цепочку инструкций.

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

Доброго времени суток Хабру и ценителям пиксель-арта, поклонникам квадратных точек, адептам лимитированных разрешений и цветов. Рад представить на ваш суд очередную статью из цикла «Галоп Пикселя». Не буду тратить время на оправдания моего долгого отсутствия и в виду явного присутствия перейду к сути дела. Сегодня мы продолжим изучать анимацию. На этот раз это будет анимация света и тени. Большей частью на статических объектах. Всё помнят – сначала база. Сначала фундамент. Сначала простое. Ну а сложное ввалится в ваши двери само, вслед за детишками.

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

Цель этой статьи показать насколько силён дуэт брата и сестры, Света и Тени в движении. Мы уже видели, как они преображают сцены в статике. Но динамика нам ещё не знакома. Давайте исправим это упущение.

Лопаты в руки.