Лучшая практика для создания сервера - корутины или poll / select
Добрый день, коллеги.
Возможно, вы уже видели данный пост уже есть на stackoverflow .ru, но та площадка плохо подходит для активного обсуждения, если оно завяжется.
Некоторое время писал разное прикладное клиент-серверное ПО на C++ по линуксовые ОС. Моя обычная практика (в общих чертах):
создать "серверный" сокет для приема входящих подключений
тем или иным образом "отметить" его как "серверный"
написать фрагмент кода/функцию приема входящих подключений (1)
написать фрагмент кода/функцию обслуживающий принятые подключения (клиентов) (2)
написать фрагмент кода/функцию обслуживающий таймаут ожидания (3)
завести массив / вектор для файл-дескрипторов
запустить select / poll для этого массива
при наступлении какого либо события (1),(2) или (3) - дернуть соответствующую функцию.
В принципе, для не сильно нагруженных приложений всегда хватало такого подхода. Корутины C++ для этого не использовал в основном потому, что они в этом языке неудобные (мнение субъективное). Однако прочитал я про замечательные примеры корутин в Go и, соответственно, примеры реализации клиент-серверных приложений на этих корутинах (ибо там они очень удобно выглядят). Как я понял, в общих чертах подход следующий:
создать "серверный" сокет для приема входящих подключений
написать функцию-корутину приема входящих подключений (1)
написать функцию-корутину обслуживающую принятые подключения (клиентов) (2)
на каждого из принятых клиентов заводить "свою" корутину
корутины "сами дергаются" при наступлении события
Данный подход я практически полностью переписал с примера "кричащий сервер на go", как я его увидел и понял. В данном случае вообще не важно что там под капотом, особенно если смотреть с верхнего уровня.
Пытаюсь для себя вывести соображения, какой подход лучше и почему. Первый подход, кажется, более платформозависимым, в отличие от второго. При первом подходе мне проще отслеживать состояние сокета: готовность на чтение, запись (иногда полезно знать, что сокет именно готов), отключение корреспондирующей стороны. На первый подход хорошо ложится "машина состояний".
Со вторым подходом я знаком сильно хуже, но все же. Второй подход условно более расширяемый, в том плане, что в корутины закатать можно и какие-то другие операции. Пожалуй, асинхронно удобнее писать в сокет большие объемы данных. Большего придумать не сумел.
Предлагаю высказать свои соображения по этому поводу или собственный опыт.
Предлагаю не переходить к вечному спору "какой язык круче", а обсудить какой подход выгоднее и продуктивнее.
Считается, что корутины это не альтернатива поллингу, но в достаточном количестве примеров выглядит как буд-то это так.
Если у вас есть собственный опыт написания серверов на классическом юниксовом поллинге, корутинах или горутинах (если так принципиально), то прошу поделиться соображениями почему именно так и какие преимущества дает. Я за конструктивное обсуждение)
В программировании главное не возраст, а желание учиться
Здравствуйте, друзья!
Сегодня я хочу поговорить о вопросе, который мне часто задают - можно ли начать изучать программирование после 40 лет? Многие считают, что программирование - это удел молодежи. Что если ты не начал кодить в подростковом возрасте, то уже "поздно запрягать". Но я абсолютно не согласен с этим мнением!
Во-первых, сейчас огромное количество людей приходят в IT именно после 30 или даже 40 лет. У них за плечами богатый жизненный опыт, высшее образование в других сферах. И эти знания помогают им стать отличными программистами. К примеру, человек с экономическим образованием легче разберется в бизнес-логике проектов. А опыт работы менеджером или предпринимателем пригодится в разработке ПО для своей отрасли.
Во-вторых, взрослый человек обладает большей целеустремленностью и самодисциплиной. Он точно знает, чего хочет - получить новую интересную профессию и стабильный доход. Поэтому он будет изучать программирование осознанно и упорно. У него достаточно терпения "шаг за шагом" осваивать новую науку.
Конечно, людям после 40 приходится прикладывать больше усилий, чем молодым. Новая информация усваивается медленнее, а некоторые технические тонкости даются сложнее. Но зато жизненный опыт помогает видеть главное и не тратить время на второстепенные детали.Взрослые обучающиеся отличаются ответственностью и внимательностью. Они не будут пропускать занятия и сроки сдачи проектов. И главное - у них есть сильная мотивация получить реальную работу как можно скорее. Это придает им дополнительные силы идти к цели.
Так что не важно, сколько вам лет - 20, 30 или даже 50. Никогда не поздно освоить новую профессию, если есть желание и целеустремленность. Программирование - именно та сфера, где опыт и зрелость ценятся работодателями не меньше, чем молодость и энтузиазм.
В общем, не бойтесь браться за изучение IT в любом возрасте. Главное - быть готовым много и упорно учиться. Постепенно накапливайте базу знаний, не торопитесь сразу на сложные вещи. И тогда результат обязательно придет!
Молодые специалисты
Не но любят повыделываться юные "разработчики" С++ :) как они "выучили" любой язык за три секунды после СИ++ .
Язык это 5% синтаксиса, и 95% знание его инструментов . Мне самому питоновские обработки массивов, мозг вынесли. Не помог мне Си за три секунды разобраться :)
Почему игнорируется условие IF
Привет всем. Прошу помочь знающих людей. Пробую немного разобраться в программировании микроконтроллеров на С++. Создал программу тестера батареек. Функция Void loop состоит по сути из трех условий:
1) если напряжение на батарейке больше 1,6 в то горит зеленый светодиод (newLed),
2) если от 1,4 до 1,6в, то горит желтый светодиод (okLed),
3) и все остальное - горит красный (oldLed).
Загрузке в ардуину происходит немного другое. Программа начинает бесконечный цикл и , даже без подключения проверяемой батарейки)загорается красный (ну это понятно, т.к. нулевое напряжение соответствует третьему условию), но далее программа возвращается к первому условию и загорается зеленый светодиод. И так бесконечно происходит игнорирование условия IF, по которому зеленый светодиод включается только когда более 1,6 в.
#define newLed 2
#define okLed 4
#define oldLed 6
int analogValue = 0;
float voltage = 0;
int ledDelay = 2000;
void setup()
{
pinMode(newLed,OUTPUT);
pinMode(okLed,OUTPUT);
pinMode(oldLed,OUTPUT);
}
void loop()
{
analogValue = analogRead(0);
voltage = 0.0048*analogValue;
if (voltage >= 1.6)
{ digitalWrite(newLed, HIGH);
delay(ledDelay);
digitalWrite(newLed, LOW);
}
else if(voltage < 1.6 && voltage > 1.4)
{
digitalWrite(okLed, HIGH);
delay(ledDelay);
digitalWrite(okLed, LOW);
}
else
{
digitalWrite(oldLed, HIGH);
delay(ledDelay);
digitalWrite(oldLed, LOW);
}}
_______________________________
кстати такое поведение ардуины заметил не только в этой программе. Там где программы состоят из условий IF постоянно игнорируется первое условие (оно постоянно выполняется). При загрузке скетча в симулятор Arduino в интернете пограммы работают корректно. В чем может быть дело?
Выполняем сторонние программы на микроконтроллерах с Гарвардской архитектурой: как загружать программы без знания ABI?
Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!
❯ Как это работает?
Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.
Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:
1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.
2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти.
Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).
3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:
Где по итогу:
.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.
И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.
А ведь чаще всего нужно просто загрузить небольшую программу, которой не нужны комплексные загрузчики: немного кода, немного данных и всё. И тут у нас есть три выхода:
Писать полноценный загрузчик ELF-бинарников. ELF может оказаться громоздким для некоторых окружений и его реализация может оказаться тривиальной не для всех.
Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.
Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.
В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!
Однако в таком подходе есть несколько серьезных ограничений:
Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).
Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).
Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!
❯ Практическая реализация
Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!
Заголовок нашего бинарника будет выглядеть вот так:
Программа общается с основной прошивкой посредством псевдо-syscall'ов: функции, которая в качестве первого аргумента ожидает номер нужной службы и один 32х-битный указатель для описания структуры с параметрами. Реализация syscall'ов — одна из самых простых и неприхотливых с точки зрения обратной совместимости с будущими прошивками.
Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.
Собираем нашу программу:
xtensa-esp32-elf-cc.exe test.c -fno-pic -nostdlib -nostartfiles -Wl,--section-start=.text=0x0
xtensa-esp32-elf-objcopy.exe --only-section=.text --output-target binary a.out run.bin
-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld).
objcopy скопирует из полученного ELF только необходимую нам секцию .text.
Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:
Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.
По итогу всё, что нужно от загрузчика бинарников — это загрузить программу в память для инструкций, выделить память для структуры с стейтом программы и передать управление Start. Всё!
Конкретно в случае ESP32, у нас есть два возможных решения задачи загрузки программы в память:
Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.
Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.
Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:
# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 0x6000,
phy_init, data, phy, 0xf000, 0x1000,
factory, app, factory, 0x10000, 1M,
executable, data, undefined, 0x110000, 0x10000
Для заливки программы можно использовать соответствующее Partition API, либо parttool.py:
parttool.py --port "COM41" write_partition --partition-name=executable --input "run.bin"
Переходим к загрузчику программы:
Прошиваем ESP32:
И смотрим результат:
SysCall 25
SysCall 35
SysCall 15
Всё работает!
❯ Заключение
Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.
Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :)
И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?
Продолжение поста «Игровая легенда из 90-х: Как работала 3dfx Voodoo "под капотом"? Пишем 3D-приложение нуля на Glide (1/2)»
Это вторая часть лонга про 3dfx Voodoo. Пришлось разбить его на две части из-за ограничений в 30.000 символов на пост у Пикабу. Сначала читайте первую часть.
Скрин с криво-наложенной текстурой: здесь уже был настроен сэмплер, но неправильно. А ещё тут видно артефакты отсутствия Z-сортировки наглядно.
Пока не впечатляет, да? Где же текстуры? А об этом — в следующей главе!
❯ Текстуры
Плоские модельки без текстур — это не очень круто. Ну что можно сделать с плоскими моделями, пусть даже они будут с освещением?
Те читатели, которые имеют опыт программирования графики наверняка знают, что видеодрайвер сам распоряжается видеопамятью с точки зрения аллокатора (механизм, управляющий выделением динамической памятью — т. е. той памятью, которая может быть выделена под объект, освобождена и затем занята другим объектом). Программист лишь создаёт текстуру, указывает число мипов и выгружает её на видеокарту — сейчас даже генерация мипов это задача видеодрайвера и самой видеокарты.
Но в Glide всё было иначе — ведь там не было понятия текстуры как объекта! Как-так? Glide позволял нам получить верхнюю и нижнюю границу адресного пространства памяти одного конкретного TMU и программист волен был выгружать текстуру куда угодно! Затем программист сохранял указатель на текстуру в видеопамяти и передавал её… в комбайнер, дабы он мог использовать текстуру по назначению! При этом TMU даже характеристики текстур не знал — эту информацию отсылал программист.
TMU поддерживает множество пиксельформатов: RGB332 (8 бит на пиксель), RGB565 (16 бит на пиксель), палитровый и собственный формат сжатия с NCC-компрессией. Тем не менее, 565 у 3dfx требует какого-то особого формата пикселей, иначе текстуры превращаются в кашу. Благо для загрузки текстур с диска, в Glide есть удобные функции и тулза texUS для создания текстур и всего набора мипов для них — gu3dfGetInfo и gu3dfLoad. Кроме того, есть функция grTexCalcMemRequired для расчета необходимого размера для текстуры в видеопамяти с учетом мипов, формата и выравнивания.
Я не стал писать сложный аллокатор, поскольку игра не требует динамической видеопамяти и может сразу загрузить уровень «пачкой», а при загрузке следующего — просто освободить всю память.
После этого, нам необходимо загрузить текстуру в видеопамять юнита с помощью grTexDownloadMipMap.
Как же теперь указать текстуру для сэмплинга, ведь glBindTexture здесь нет? Для этого есть функция glTexSource, которая принимает адрес первого мипа и конфигурацию текстуры — которая хранится на стороне ЦПУ!
Но если мы сейчас запустим программу, то никакой текстуры мы не увидим. Потому что сначала нужно настроить сэмплер и комбайнеры!
Для этого, мы настраиваем комбайнеры на сэмплинг текстур напрямую, без умножения на цвет вершины. Альфа-канал мы не трогаем вообще — у нас нет альфа-буфера для него.
Запускаем программу и вот результат:
Да, первая полноценная 3D-модель с текстурой! Мы реализовали половину работы видеодрайвера вручную, однако по концовке всё равно очень приятно! Игры здесь пока ещё нет — материал вышел бы слишком большим.
❯ А где практика?
К сожалению, сегодня без практической части :( Изначально я думал что у меня всё схвачено и моя материнка на 478 с AGP-слотом вполне справиться с ролью тестового стенда для нашей демки. Однако, я не учел важный факт — существовало несколько физических версий AGP и на 478 уже поздний вариант с 1.5в/0.8в уровнями.
Материал был обещан в четверг на 11 утра, времени на заказ через почту у меня не было (новый год, посылки 1.5-2 недели задерживаются только на сортировке в Краснодаре), поэтому я начал написывать всем сервисникам у себя в городе, в надежде что у кого-то лежит на складе материнка на PGA370… в любом состоянии.
И материнка нашлась! Ей оказалась поздняя ECS P6IPAT на 815 чипсете с универсальным AGP-разъемом, который поддерживал все стандарты AGP одновременно. Продавал её мужичок всего за 100 рублей, сразу с процом и охладом :) Однако возникли определенные проблемы с поднятием платы (все электролиты необходимо менять «вкруг», а нужных номиналов под рукой не оказалось, плата стартовала раза с 3го) и накатыванием винды (помер IDE-привод), поэтому практическая часть немного откладывается…
❯ Заключение
И мы приходим к выводам, что для написания 3D-игры, программист в 90-х годах должен был как минимум:
Иметь представлении о трансформации геометрии, что такое матрицы (геометрию можно трансформировать и без матриц, однако это не очень удобно).
Понимать, как работает конвейер видеокарты, что такое стейты, комбайнеры, каким образом происходит управление памятью, организация фреймбуфера и Depth-буфера.
Иметь представление об основных техниках в растеризации 3D-графики: что такое перспективное деление, Z-буфер, форматы вершин, фильтрация текстур, мипмаппинг, затенение по Гуро, какие-либо методы анимации, если была необходимость и т. п.
Материал получился очень объёмным, для меня это абсолютный рекорд. Я старался собрать всю информацию о 3dfx Voodoo, которую изучил и поделится с вами не только архитектурой конкретно видеокарт, но и рассказать о программировании графических API на низком уровне и подробно рассказать, как же строится изображение «под капотом» и вашей видеокарты.
Касательно баек насчет 3dfx в СНГ: я лично родился в 2001 году, так что могу судить исключительно из услышанных мной баек и историй. А какая история с 3dfx Voodoo была у вас? Пишите в комментах!
Надеюсь, материал был вам интересен. :) Статья писалась несколько бессонных ночей, дабы успеть под новый год! Больше бэкстейджа, мыслей и проектов у меня вTelegram.
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!