Четвертой интересной особенностью OGL3.0 является стремление разработчиков стандарта сделать решительный шаг в сторону эффективно распараллеливающихся драйверов OpenGL на многоядерных процессорах.

Это важно, т.к. я наблюдал в профайлере, что драйвера видеокарты съедают 20-30% процессорного времени. Это довольно много. Если драйвера смогут эффективно использовать многоядерность, выйгрыш в скорости будет ощутимым и, что главное, абсолютно бесплатным для разработчика GL-приложений.

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

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

В противном случае драйверу необходимо было бы синхронизировать установку текущей текстуры среди параллельно работающих потоков. А любая синхронизация в мультитредовой архитектуре пока что зло для общей производительности.

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

Опубликована спецификация OpenGL 3.0.

Что, так сказать, новенького?

Во-первых, несколько экспериментальных расширений отдельных вендоров вошли в стандарт.

Во-вторых, ввели так называемые "устаревшие функции". Часть функций, которая в настоящее время плохо коррелирует с современной аппаратной реализацией объявлены устаревшими. Они будут работать в OGL 3.0, но в будущих версиях API будут убраны.

Такая ситуация объясняется тем, что OpenGL родился еще в 1992 году и с тех пор API ни разу не очищался от откровенно устаревших функций. Лишь добавлялись новые.

Особой необходимости не было, ведь даже в OGL образца 1992 года было многое из того, что появилось в DirectX лишь 5-10 лет спустя.

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

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

Новый API и тенденции его развития мне понравились.

Осуществил некоторые нововведения на блоге:

Вместо трех колонок теперь две. На три колонки объективно было мало материала.

Увеличил шрифт и расстояние между строками. Надеюсь, теперь стало читабильнее.

Общий черный фон поменял на серый для позитивности.

Добавил проверку "человек-робот" в комментарии к записям. Через ввод цифр, отображаемых на картинке. Удалять сообщения роботов все-таки надоедает.

Выделил сообщения-статусы малиновым цветом.

Убрал "Новое у друзей" с главной страницы, т.к. сервис давно не живет.

Привел разделы "Друзья" и "Ссылки" в состояние up-to-date.

Отделил более четко комментарии от самой записи.

Убрал много всего устаревшего, поправил опечятки.

Надеюсь, стало лучше. Комментарии приветствуются.

By complexity I do not mean just the asymptotic complexity but the machine cycle count. In order to learn about it, it is necessary to acquire a habit of writing benchmarks. Time and time again I discovered that my beautiful designs were totally wrong after writing a little benchmark. The most embarrassing case was when after claiming publicly on multiple occasions that STL had the performance of hand-written assembly code, I published my Abstraction Penalty Benchmark that showed that my claims were only true if you were using a specialized preprocessor from KAI. It was particularly embarrassing because it showed that the compiler produced by my employer – Silicon Graphics – was the worst in terms of abstraction penalty and compiling STL. The SGI compiler was eventually fixed, but the performance of STL on the major platforms keeps getting worse precisely because customers as well as vendors do not do benchmarking and seem to be totally unconcerned about performance degradation. Occasionally there will be assignments that require benchmarking. Please do them.

Прочитал интервью с Дональдом Кнутом. Очень понравилось.

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

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

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

Также Кнут не очень хорошо относится к идее повсеместных юнит-тестов и экстремальному программированию. Я думаю - не зря.

Попробовал использовать ATI Tootle 2.0. Это библиотека, которая перестраивает индексы 3д модели так, что во-первых улучшается попадание в кеш (а это значит, что вершина не будет просчитываться лишний раз), а во-вторых снижается overdraw (т.е. соотношение числа реально отрисованных пикселей к числу пикселей экрана).

Вообще говоря, снижение overdraw в режиме independent view в некотором роде попахивает фантастикой. Но в реальности, оказывается, осуществимо. После обработки моделей Tootle получается прирост 4-7%, т.е. примерно тот прирост, который обещают разработчики.

Правда на маленьких моделях иногда падает. Непонятно почему. И только в режиме релиза, запущенного отдельно. ОС точно указывает: падает на библиотеке Tootle. Это, конечно, плохо. Но со временем это, скорее всего, поправят.

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

Я уже писал о МГУ, которому совершенно некуда девать деньги. Ну раз некуда, значит тратит на Нигму.

Ну написал и написал, ссылка была партнерская. На особый заработок не надеялся. Интересно было, набежит ли за год 10 рублей или нет :) Вообщем-то ведь ничего не теряю, обычный пост как и все.

Через неделю или две проверил - накапало 34 копейки. И забыл.

Зашел сравнительно недавно и чуть не выпал в осадок - на счету было 900+ рублей. А сейчас уже ~1140 рублей.

Сейчас там платят:

за решение двух простых задачек типа посчитать пауков на картинке - по 50 рублей за задачку.

100% с заработков друзей

копейки за то, что пользуешься этой поисковой системой

призы по 300, 200, 100 рублей 3, 7, 10 самым активным ежедневно.

Вот ведь куры не клюют!

Понял, какую точно категорию предметов я просто ненавижу.

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

Т.е. по делу практически нет, зато все заклассифицировано. Это же проще всего, когда сказать нечего, начать классифицировать очевидные вещи.