Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Постановка задачи

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

Итак, задача ставится следующим образом: не используя никаких сторонних библиотек (особенно графических) получить примерно такие картинки:



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

Введение

Я математик-программист. Самый большой скачок в своей карьере я совершил, когда научился говорить:«Я ничего не понимаю!» Сейчас мне не стыдно сказать светилу науки, что мне читает лекцию, что я не понимаю, о чём оно, светило, мне говорит. И это очень сложно. Да, признаться в своём неведении сложно и стыдно. Кому понравится признаваться в том, что он не знает азов чего-то-там. В силу своей профессии я должен присутствовать на большом количестве презентаций и лекций, где, признаюсь, в подавляющем большинстве случаев мне хочется спать, потому что я ничего не понимаю. А не понимаю я потому, что огромная проблема текущей ситуации в науке кроется в математике. Она предполагает, что все слушатели знакомы с абсолютно всеми областями математики (что абсурдно). Признаться в том, что вы не знаете, что такое производная (о том, что это — чуть позже) — стыдно.

Но я научился говорить, что я не знаю, что такое умножение. Да, я не знаю, что такое подалгебра над алгеброй Ли. Да, я не знаю, зачем нужны в жизни квадратные уравнения. К слову, если вы уверены, что вы знаете, то нам есть над чем поговорить! Математика — это серия фокусов. Математики стараются запутать и запугать публику; там, где нет замешательства, нет репутации, нет авторитета. Да, это престижно говорить как можно более абстрактным языком, что есть по себе полная чушь.

Троичные вычисления

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

• Считаем до трёх: раз
• Считаем до трёх: два (память)
• Считаем до трёх: три (счётчики)
• Считаем до трёх: четыре (однотритный вычислитель и система команд трёхтритного)

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

На любые вопросы из разряда «зачем?!» я отвечаю заранее: «Because I can».

Троичные вычисления

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

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

Итак, вот список опубликованных статей цикла (будет обновляться):

• Считаем до трёх: раз (троичный мультиплексор и сумматоры)
• Считаем до трёх: два (память)
• Считаем до трёх: три (счётчики)
• Считаем до трёх: четыре (однотритный вычислитель и система команд трёхтритного)

Напоминаю, что единственным строительным блоком вычислителя будет троичный мультиплексор. Вот фотография оригинального тримукса дизайна Александра Шабаршина и моего исполнения на поверхностном монтаже. Одна такая плата несёт на себе два троичных (де-)мультиплексора:

Троичный счётчик

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

Это уже третья статья, по мере готовности будет продолжение. Оглавление:

• Считаем до трёх: раз (троичный мультиплексор и сумматоры)
• Считаем до трёх: два (память)
• Считаем до трёх: три (счётчики)
• Считаем до трёх: четыре (однотритный вычислитель и система команд трёхтритного)

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

Введение или зачем этот топик

Читая Хабрахабр, я натолкнулся на два топика, «выводящие на чистую воду» вычисления с плавающей запятой.
В одном из них достаточно подробно и качественно дана выжимка из стандарта IEEE754 и основные проблемы при вычислениях с плавающей запятой, другой — короткий топик-заметка про то, что не все так хорошо при вычислениях на ПК. При этом даются рекомендации в случае, когда важна математическая точность результата, использовать целочисленные вычисления, «фиксировать запятую» или как минимум проверять результаты, выдаваемые платформой (компилятор + процессор).
Несмотря на то, что советы дельные, понять, как использовать целочисленные вычисления там, где до этого была плавающая запятая, не так просто, особенно без математической подготовки. Достаточно занимательна в этом смысле попытка одного из «хабровчан» разобраться с фиксированной точкой методом экспериментов.
Данный топик — краткое введение, которое должно дать представление о вычислениях с фиксированной точкой. Математика в данной статье не должна никого напугать — все очень примитивно. Сразу прошу простить: среди моих знакомых устоявшимся выражением является именно «фиксированная точка» (от англ., fixed-point), а не «запятая», поэтому я буду придерживаться именно этого термина.

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

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


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

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


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