Вступление

Недавно, почитав различных статей и презентаций про GPGPU, я решил тоже попробовать для себя программирование под видеокарты. Фактически, выбор технологий в этой области не велик — сейчас живы и развиваются только CUDA (проприетарный стандарт nVidia) и OpenCL (свободный стандарт, работает на GPU от ATI, nVidia, а также на центральных процессорах). В связи с тем, что мой ноутбук располагает видеокартой ATI (Mobility Radeon 5650 HD), то выбор и вовсе свёлся к одному варианту — OpenCL. В этой статье речь пойдёт о процессе изучения OpenCL с нуля, а также о том, что из этого получилось.

В недавнем проекте с Qt пришлось разбираться с классом QThread. В результате вышел на «правильную» технологию работы c QThread, которую буду использовать в других проектах.

Введение

В настоящий момент сложно себе представить программное обеспечение, работающее в одном потоке. Конечно, существует ряд простых задач, для которых один поток более, чем достаточен. Однако так бывает далеко не всегда и большинство задач средней или высокой сложности так или иначе используют многопоточность. В этой статье я буду говорить об использовании синглтонов в многопоточной среде. Несмотря на кажущуюся простоту эта тема содержит множество нюансов и интересных вопросов, поэтому считаю, что она заслуживает отдельной статьи. Здесь не будет затрагиваться обсуждение того, зачем использовать синглтоны, а также как их правильно использовать. Для прояснения этих вопросов я рекомендую обратиться к моим предыдущим статьям, посвященным разным вопросам, связанным с синглтонами [1], [2], [3]. В этой статье речь будет идти о влиянии многопоточности на реализацию синглтонов и обсуждению вопросов, которые всплывают при разработке.

От переводчика

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

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

Почему я решил перевести этот текст (ведь он короткий и не особо насыщенный откровениями)? Потому, что это выступление Кармака. А он, как-никак, знаковая фигура в отрасли разработки ПО. То, что написано ниже, показывает отрыв теории разработки ПО от практики. Ведь, если эти мысли посещают такого разработчика и выносятся на QuakeCon, — то что тогда творится в головах рядовых прикладных программистов?

Этот пост является 2-ой и последней частью статьи о разработке системы частиц на DirectX 9. Если вы еще не читали первую часть, то рекомендую с ней ознакомиться.

В этой части статьи будет рассмотрено: работа со спрайтами, вершинные и пиксельные шейдеры, эффекты, пост-эффекты. В частности для реализации пост-эффекта — приём рендера в текстуру.

Данный пост будет о том, как разработать свою собственную, и достаточно производительную (на моем компьютере спокойно отрисовывается и анимируется 1 000 000 частиц в реальном времени), систему частиц. Писать будем на языке C++, в качестве платформы будет использован DirectX 9.

Вторая часть доступна здесь.

Пример одного из кадров визуализации (кликабельно):

За последние месяцев 20 я написал немало постов о Qt5, QML Scene Graph, шейдерах и многом другом. Сейчас, когда бета-версия Qt5 уже на подходе, я думаю что пора показать очередное технологическое демо. Оно называется 'Cinematic Experience' и выглядит следующим образом:

В начале августа Energia (среда разработки для Launchpad) обновилась до версии 0101E0008.

Некоторое время назад в одном из обсуждений я упомянул о том, что контрол «a-la ribbon» (который был использован в MS Office 2007 для организации меню) легко и непринуждённо реализуется средствами Qt.

Я не хочу спорить о том, удобен ribbon или нет (сам я больше склоняюсь ко второму мнению). Но на его примере можно отлично раскрыть возможности каскадных таблиц стилей для Qt (которые были представлены в Qt 4.2), чем я и займусь. Сразу прошу прощения: я не дизайнер, поэтому с точки зрения эстетики мой QRibbon скорее всего не дотянет до своего собрата от МС, но дизайнеры в МС, полагаю, в своей области превосходят меня на 2 головы, да и человеко-часов, думаю, там было затрачено в слегка побольше. Я же всего лишь демонстрирую общий принцип и базовые возможности.

Так как я сейчас изучаю язык Python, то для демонстрации был выбран именно он, но для C++ всё делается абсолютно так же. Заранее прошу прощения: Python я только-только изучаю, поэтому код может быть полон корявостей, так что прошу больно не пинать :)

Итак, начнём!

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

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

Давайте посмотрим на простую функцию:

QCoreApplication app(argc, argv);
QTimer::singleShot(3000, &app, SLOT(quit()));
return app.exec();

Это Qt-приложение, не имеющее графического интерфейса. Оно работает 3 секунды и затем завершается.

Предисловие

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

Введение

Это заметка, в которой я хотел бы немного описать архитектуру и систему расширений среды разработки Qt Creator. Изначально, я предполагал лишь перевести документ Writing-Qt-Cretor-plugins.pdf, но так уж вышло, что развитие Qt Creator не стоит на месте и во первых, данный документ уже не столь актуален (сам устарел, API поменялось, куски кода не полные и часто не работают), а во вторых со времени его написания появлись дополнительные возможности расширения Qt Creator, которые хотелось бы описать.

Тем не менее, не будь этого документа, не было бы и данной заметки: из него я взял очень много, вплоть до структуры поста, при этом постаравшись где-то что-то выкидывая/заменяя/добавляя сделать пост актуальным для последней на текущий момент времени версии Qt Creator 2.4.0.

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

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

Итак, что же нас ожидает под катом (жирным отмечены готовые разделы):

1. Сборка Qt Creator
2. Первое расширение
3. Добавление новых меню и пунктов меню
4. Архитектура Qt Creator
5. Добавление нового редактора (Editor)
6. Добавление боковой навигационной панели
7. Добавление страницы в диалог настроек
8. Добавление фильтра в диалог поиска
9. Добавление нового типа проекта

Напомню, что Qt Creator является кросс-платформенной свободной IDE для работы с фреймворком Qt, разработанной Trolltech (Nokia). Что не мешает сделать из него простой текстовый редактор с подсветкой синтаксиса, простым отключением всех расширений. Внимание, сотни картинок!

Волею судеб поступил в один из Российских вузов. На дипломе было решено исследовать одно из направлений биометрической идентификации – идентификацию по рисунку вен ладони. На начальных стадиях было задумано предоставить к защите работающую модель устройства (но все оказалось не так просто).

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

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

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

Я постоянно дёргал их, снова и снова расспрашивал о всяких мелочах, а потом эти мелочи благополучно забывал. В конце концов, я задал им вопрос — а нет ли какого-нибудь обзорного документа, уткнувшись в который я бы избавил ребят от своего назойливого внимания? Не получив утвердительного ответа я решил написать эту статью, которая по завершению была вычитана Эдэмом Джексоном и Дэвидом Эйрли. Они оба работают над этим стеком.

Данный пост навеян статьей "Я, пользователь!", которая вызвала много споров, и была весьма прохладно встречена сообществом. Обсуждение в комментариях показало, что мысль, которую Автор высказал довольно жестко и агрессивно, была воспринята как призыв вернуться к ветряным мельницам. Однако, на мой взгляд, проблема затронутая автором, гораздо глубже.

«Система должна быть спроектирована так,
чтобы оставаться как можно проще
после серии внесенных в нее изменений»
Бьярне Строуструп – программист, автор языка C++

Преамбула

В данной статье мне бы хотелось бы рассказать о довольно популярной, но так редко освещаемой на Хабре библиотеке Portable Components (сокр. POCO). Она будет полезна как разработчикам бизнес-логики программного продукта, так и в решении большинства прикладных задач. При всем изобилии кроссплатформенных библиотек для C++ всё больше людей сталкиваются с POCO лицом к лицу и не знают с чего начать. В данной статье я постараюсь описать технологии, заложенные в библиотеке и дать простейшие примеры решения некоторых задач. Также хотелось бы отметить, что за плечами библиотеки множество успешных как Open Source, так и коммерческих проектов.

Далее — перевод статьи с сайта IBM. Вряд ли вы узнаете что-то принципиально новое из неё. Данную статью хорошо использовать как отправную точку для чтения об интересных или ранее неизвестных вам особенностях Линукс. Часть ссылок я привёл в тексте статьи курсивом, часть можно увидеть в конце оригинальной статьи. Мои пояснения или комментарии выделены курсивом.

В релизы ядра Линукс версий 3.3 и 3.4 вошло впечатляющее количество улучшений. Однако эти релизы не просто развитие ядра, но зловещий рубеж на пути этого развития.
Релиз версии 3.3 — первый релиз ядра линукс, объём которого превысил 15 миллионов строк (пусть даже по откровенно кривому способу измерения). Если вы вычтете изменяемую, непостоянную часть кода (различные драйвера, платформозависимый код и различные утилиты), число строк падает немного ниже 4 миллионов — левиафан собственной персоной.

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

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

Ниже показан результат обработки реального размытого изображения (не с синтетическим размытием). Исходное изображение было получено камерой Canon 500D с объективом EF 85mm/1.8. Фокусировка была выставлена вручную, чтобы получить размытие. Как видно, текст совершенно не читается, лишь угадывается диалоговое окно Windows 7.



И вот результат обработки:



Практически весь текст читается достаточно хорошо, хотя и появились некоторые характерные искажения.

Под катом подробное описание проблем деконволюции, способов их решения, а также множество примеров и сравнений. Осторожно, много картинок!

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

Почему же для устранения смаза и расфокусировки практически ничего нету (unsharp mask не в счет) – может быть это в принципе невозможно? На самом деле возможно – соответствующий математический аппарат начал разрабатываться примерно 70 лет назад, но, как и для многих других алгоритмов обработки изображений, все это нашло широкое применение только в недавнее время. Вот, в качестве демонстрации вау-эффекта, пара картинок:



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

_{Томпсон (сидит) и Ритчи работают на PDP-11, 1972 год.}

Период 1968-69 гг. был очень неопределенным для Bell Labs: проект операционной системы с разделением времени Multics (Multiplexed Information and Computing Service), разрабатываемой с 1964 года для дорогой 36-битной ЭВМ GE-645, не имел четких перспектив и целей, а лишь разрастался в размерах и сложности, всё ясней был виден его предполагаемый провал. В конце концов, American Telephone & Telegraph вышла из проекта, в который за пять лет были вложены миллионы долларов.

Однако, некоторые из инженеров, работавших над Multics — Кен Томпсон, Деннис Ритчи, Малкольм Дуглас Макилрой, Джозеф Оссанна, — ощущали необходимость в продолжении работы над подобным проектом, и не хотели терять успевшую сформироваться уютную рабочую атмосферу. Поэтому в 1969 году они начали искать альтернативу Multics: Оссанна, Томпсон, Ритчи пытались протолкнуть покупку машины средней мощности, для которой группа обещала написать операционную систему. Заказ на предлагаемые ЭВМ DEC PDP-10 и Sigma 7 так и не был сделан, и хотя несколько раз ситуация выходила на грань получения нужного оборудования, было вполне очевидно, что команда просит слишком крупную сумму для проекта с расплывчатым планом, тем более, что после провала Multics операционные системы стали не настолько привлекательной сферой. Поэтому Томпсон (в основном это была его задумка), Кэнэдэй и Ритчи (привнесший идею файлов-устройств) разработали на обычных черных учебных досках и бумаге устройство файловой системы, которая позже стала сердцем Unix.