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

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

Введение

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

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

Алиасинг (aliasing) — это, возможно, наиболее фундаментальный и самый широко обсуждаемый артефакт 3D-рендеринга всех времён. Однако в игровом сообществе его часто недопонимают. В этой статье я подробно расскажу о теме сглаживания (антиалиасинга, anti-aliasing, AA) в реальном времени, особенно о том, что касается игр, и в то же время буду излагать всё достаточно простым языком.

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

Эту программу можно скачать здесь.

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

«Code Monkey like Fritos
Code Monkey like Tab and Mountain Dew
Code Monkey very simple man
With big warm fuzzy secret heart:
Code Monkey like you
Code Monkey like you»

— Jonathan Coulton — Code Monkey

Я думаю, многим знакома эта шикарная песня Jonathan Coulton'а, и эта жизненная ситуация, когда «Rob say Code Monkey very diligent», но «his output stink» и «his code not 'functional' or 'elegant'».

Язык Си, подаривший нам столько полезного софта, потихоньку был вытеснен из десктопа и энтерпрайза такими высокоуровневыми гигантами как Java и C# и занял нишу системного программирования. И все бы хорошо, но системщики — очень отбитые своеобразные ребята. Задачи, которые порой возникают перед ними даже своей формулировкой способны вогнать в ужас простых смертных. Собственно говоря, так же, как и некоторые решения.

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

Возможное, многие из вас думали после ситуации с Фобос-Грунтом — что такого особенного в микросхемах для космоса и почему они столько стоят? Почему нельзя поставить защиту от космического излучения? Что там за история с арестом людей, которые микросхемы экспортировали из США в Россию? Где все полимеры?

На эти вопросы я и попробую ответить в этой статье.

Disclaimer: Сведения получены из открытых источников и могут быть не вполне точными. Я лично с военной электроникой не работаю, а кто работает — те статьи писать не могут. Буду рад дополнить и исправить статью.

Привет, Хаброжители! Эта книга основана на онлайн-курсах по алгоритмам, которые Тим Рафгарден ведет на Coursera и Stanford Lagunita, а появились эти курсы благодаря лекциям для студентов, которые он читает в Стэнфордском университете на протяжении многих лет.

Алгоритмы — это сердце и душа computer science. Без них не обойтись, они есть везде — от сетевой маршрутизации и расчетов по геномике до криптографии и машинного обучения. «Совершенный алгоритм» превратит вас в настоящего профи, который будет ставить задачи и мастерски их решать как в жизни, так и на собеседовании при приеме на работу в любую IT-компанию. Тим Рафгарден расскажет об асимптотическом анализе, нотации большое-О, алгоритмах «разделяй и властвуй», рандомизации, сортировки и отбора. Книга адресована тем, у кого уже есть опыт программирования. Вы перейдете на новый уровень, чтобы увидеть общую картину, разобраться в низкоуровневых концепциях и математических нюансах.

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

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

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

Цель нашего сервиса — решить эту проблему.

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



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

На просторах рунета можно найти достаточно много статей с введением в Verilog HDL. Все они описывают синтаксис и семантику языка, но, к сожалению, не раскрывают основных парадигм, используемых при проектировании цифровых схем. Представьте себе, что вам объясняют синтаксис языка Java, но не рассказывают ничего про объектно-ориентированное проектирование. Если вы знакомы с ООП, то такого введения будет достаточно, но если вы знаете только Си, то писать скорей всего будете “по-старому”, создавая огромные классы со сложными методами.

Примерно так происходит с программистами, изучающими цифровую схемотехнику и языки описания аппаратуры. Быстро разобравшись с несложным синтаксисом языка, они начинают описывать конструкции, безумные с точки зрения хардверного инженера. Среди моих студентов встречались люди, написавшие “сортировку пузырьком” за такт, сумасшедшие асинхронные схемы, которые работали по-разному при каждом запуске и разной погоде за окном, огромные комбинационные делители, уводившие place&route в глубокую многочасовую задумчивость.

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

Какое-то время назад автору довелось читать лекцию во ВГИК, и в аудитории было много людей с операторского факультета. Аудитории был задан вопрос: «С каким максимальным разрешением вы снимали?», и дальше выяснилось, что примерно треть снимала 4К или 8 мегапикселей, остальные — не более 2К или 2 мегапикселя. Это был вызов! Мне предстояло рассказать про камеру с разрешением 755 мегапикселей (raw разрешением, если быть точным, поскольку конечное у нее 4К)  и какие феерические возможности это дает для профессиональной съемки.

Сама камера выглядит так (этакий маленький слоник):



Причем, открою страшную тайну, чтобы сделать этот снимок искали ракурс получше и человека покрупнее. Мне доводилось щупать эту камеру вживую, скажу, что она выглядит намного крупнее. Снимок ниже с Йоном Карафином, с которым мы примерно одного роста, более точно передает масштабы бедствия:



Кому интересны принципиально возможности вычисляемого видео о которых редко пишут — вся правда под катом! )

Я уже перестал вздрагивать и удивляться, когда звонит телефон и в трубке раздается жесткий уверенный голос: «Вас беспокоит капитан такой-то (майор такой-то), вы можете ответить на пару вопросов?» Почему бы не поговорить с родной полицией…

Вопросы всегда одни и те же. «У нас есть видео с подозреваемым, пожалуйста, помогите восстановить лицо»… «Помогите увеличить номер с видеорегистратора»… «Здесь не видно рук человека, пожалуйста, помогите увеличить»… И так далее в том же духе.

Чтобы было понятно о чем речь — вот реальный пример присланного сильно сжатого видео, где просят восстановить размытое лицо (размер которого эквивалентен примерно 8 пикселям):


И ладно бы только русские дяди Степы беспокоили, пишут и западные Пинкертоны.

Многие начинающие разработчики часто недооценивают влияние асинхронности на работу цифровых схем. В проектах с одним тактовым генератором сложностей не возникает: схема полностью синхронна, и от разработчика требуется только соблюдать требования Setup и Hold. Но как только в системе появляется второй тактовый генератор, возникает проблема CDC – Clock Domains Crossing, связанная с асинхронностью работы участков схемы, работающих от независимых (асинхронных) генераторов. На практике эта проблема выливается в усложнение маршрута проектирования, связанное с особенностями статического временного анализа в САПР, а в железе проявляется в виде такого эффекта как метастабильность, и аномальное поведение триггеров. Собственно, о метастабильности здесь уже писали, но я предлагаю чуть глубже разобраться в проблеме.