Литий в самолете

Тема лития в почте (а точнее, в самолете) получила такое вот продолжение:

Где-то в середине ноября я затарился очередной пачкой литиевых енерджайзеров с прицелом на следующий летний сезон. Сегодня они приехали. Трекинг до Москвы - вот такой вот:

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

Такие дела.

LibRaw 0.15.0-Beta3

Вышла LibRaw 0.15-Beta3, доступна в обычном месте.

Никаких серьезных внутренних изменений нет, только поддержка новых камер:

  • Canon 6D и EOS M
  • Casio EX-ZR100
  • Fujifilm X-E1
  • Leica D-LUX6 and V-LUX4
  • Nikon P7700
  • Olympus XZ-2
  • Panasonic G5
  • Samsung EX2F
  • Sony RX-1

Ёж - птица гордая

Дети притащили с благотворительного аукциона

Хозяйке на заметку: Qt, OpenGL и PBO

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

Вот есть QGraphicsView, направленный в QGLWidget. Есть еще QGraphicsScene, у которой с помощью drawBackground() рисуем нужное нам (картинку).

Этот самый drawBackground() использует текстуры, одну или много, текстуры залиты через PBO.

Дальше - пытаюсь вывести на эту Scene другие объекты. Ну, как в документации написано, к примеру так:

QLabel *label = new QLabel("Bla-Bla");
scene->addWidget(label);
(ну чуть побольше кода, потому что прозрачность, возможность двигать, но смысл именно такой)

Результат:

  • Если объекты выводятся, окно открывается и т.п. до создания "моих" текстур (которые рисуются на фоне) - то все отлично.
  • Если все разлеглось так, что свои текстуры и PBO я создал до первого показа (даже не создания) объекта на Scene, то жопа, при добавлении элемента к сцене получаем такое:
    texture upload failed, error code 0x502
    
И так пробовал, и сяк и об косяк, потерял не меньше двух дней (ну то есть - не работает, пытаемся создать свой пример, там работает, из примера переносим код к себе - не работает и так с десяток раз). И, внезапно, ответ нашелся:

Если вы работали с QOpenGLBuffer, то прежде чем отдать управление в Qt - сделайте ему release(). Иначе будет нехорошо.

И ведь натыкался я уже на подобное, но с VBO: если не отцепить их, то вообще ничего не работает.

Об эффективном использовании современных CPU

Практика вот к этой презентации:

Берем 36Mpix файлик с D800, распаковываем егонный RAW в 16-битный однокомпонентный битмеп, дальше начинаем процессить.

Процессим без "интерполяции", т.е. 4 пикселя исходного байера образуют один выходной пиксель (режим half_size у LibRaw/dcraw). Получаем такие вот времена:

  1. LibRaw::dcraw_process() плюс формирование RGBA-битмепа: 420ms.
  2. Перепишем этот самый dcraw_process() на SSE3, процессить будем в плавучке (с эмуляцией особенностей dcraw), выдаем такой же 8-битный RGBA: 110ms (и более-менее понятно где еще выиграть миллисекунд 20).
  3. Добавим в предыдущий суп еще: подсчет RAW-гистограммы и сохранение исходного float-битмепа нетронутым (и без дублирования по памяти), т.е. баланс белого и конверсию цвета делаем два раза, один раз для подсчета гистограммы результирующего файла, а второй раз - прямо на вывод. 180ms.
Это все был один поток. Распараллелим его:
  1. "распараллеленный dcraw_process": 130ms (так в RawDigger сделано, тамошний RGB render устроен именно так, но гистограммы и статистика в эти 130ms не входят, равно как и битмеп для показа там готовится иначе и потому дольше).
  2. "распаралеленный ассемблерный dcraw_process": не делал, ожидаю <50ms (потому что вариант с двойным вычислением, как следующий, но без гистограмм - 57ms).
  3. параллельная ассемблерная версия с гистограммами, сохранением float RAW: 75ms
Сравнивая последний вариант с последовательным C-шным, нужно понимать, что в C-шном варианте еще где-то 200ms придется на гистограммы и еще 200 на конверсию int16 - float. То есть реальное ускорение от SSE и параллельной обработки - раз в 10 (75ms против 800). И это оптимизированный C-шный, в LibRaw это место заметно пооптимизировано в сравнении с исходным dcraw.

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

О процессинге RAW: плавучка или целое

Обработка RAW в плавучке позволяет избавиться от артефактов вылета за диапазон, да и вообще получить более качественную картинку.

Тем интереснее обратные случаи.

Возьмем вот такой вот кадр:

Это D800 с его приколами в светах, вот на света и посмотрим.

Если обработать картинку dcraw (или LibRaw, которая дает побитово такой же процессинг, если автоматическое определение максимума отключить), то в светах в "середине верха кадра" мы увидим такое вот:

Про Mac и 32 бита

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

В связи с этим встает вот такой вот вопрос:

  • Qt5 не билдится как Universal Binary, обещают починить, но там есть препятствие в лице v8 (насколько понял из чтения мейлинг-листов).
  • Qt5 поддерживает Mac OS X начиная с 10.6. Эта самая 10.6 вроде бы требует 64-bit capable CPU (это по комментариям в Qt-шном багтрекере, где обсуждают отсутствие UB). Хотя в Википедии пишут, что 64-bit only - только с 10.7
  • Посмотрел в статистике RawDigger: 32-битных Маков 1%. Не от числа вообще компьютеров а от числа маков. У меня, понятно, статистика смещенная и кривая, но какая уж есть.
Собственно, вопрос: а что будет, если я в мак-версии дропну 32-битность? Целевая аудитория вареза - фотографы, как обычно. Теоретически, это заденет модели 2006-го года и некоторые макмини 2007, но их же должен быть вот тот самый 1%?

По-моему, этот вопрос мы уже обсуждали в этом бложике "вообще", но может у кого есть объемная статистика?

Если в одном месте убудет, в другом - обязательно прибудет

Интересно, когда кулеры станут больше материнских плат?

P.S. mini-ITX как идея - очень понравилось!

О маках у фотографов

Статистика даунлоадов RawDigger 0.9.13 (в процентах)

OSRU (75% - россия+украина)EN (45% США-Канада, остальное - европа)
Windows, x645248
Windows, x323719
Mac1132

Забавно, да.

P.S. Сумма в последней колонке не совпадает т.к. дробные части разлеглись неудачно, .3, .4 и .3.

LibRaw 0.15.0-Beta2

По традиции, анонсирую LibRaw 0.15-Beta2

Полный changelog доступен у библиотеки в гнезде, а тут я остановлюсь только на самом существенном:

  • Поддержано 20 новых камер:
    • Canon: G15, S110, SX50
    • Fujifilm: F800EXR, XF1
    • Nikon: 1 J2, 1 V2, D600
    • Olympus: E-PL5, E-PM2
    • Panasonic: FZ200, GH3, LX7
    • Pentax: K-5 II, K-5 IIs, K-30, Q10
    • Sony: SLT-A99, NEX-5R, NEX-6
  • RawSpeed может использоваться не только для байеровских данных, но и для полноцветных (3-цветные DNG, sRAW).
    Правда если вы захотите использовать эту фишку, то вам придется запатчить RawSpeed. Тот же патч положен в дистрибутив LibRaw (в каталоге RawSpeed).
    Пользы от RawSpeed достаточно много даже для нежатых DNG: к примеру, 60-мегабайтный 3-цветный нежатый DNG распаковывается за 130мс родным кодом LibRaw и за 70мс - при помощи RawSpeed.
  • В API добавились флажки, позволяющие понять - использовалась ли библиотека RawSpeed, а если да, то к чему это привело.
  • В очередной раз перебраны потроха (интересно только тем, кто в них копается, сам LibRaw API не изменился)
    • В 0.15-Alpha-Beta1 в imgdata.rawdata были два указателя: raw_image указывал на буфер с байеровскими данными, а color_image - на буфер с 4-компонентными RGBG. Ну то есть для байеровских RAW первый был не нулевым, а для полноцветных - второй.

      В Beta2 этот самый color_image ращеплен на два: color3_image ненулевой если в буфере (на который он указывает) лежат 3-компонентные данные, а color4_image - если данные надо рассматривать как 4-компонентные.

    • Введенный в Alpha4 параметр imgdata.sizes.raw_pitch (шаг строк в RAW-буфере) теперь в байтах, а не в пикселях. И один и тот же raw_pitch используется для доступа к imgdata.rawdata.raw_image, color3_image, color4_image
    Кому интересно совсем в деталях - читайте исходник LibRaw::raw2image() и понятно будет все.

AMD CPU qs

С несерверными AMD-шными CPU как-то вообще никогда не приходилось сталкиваться (да и с серверными - приходится не очень часто), а их же больше четверти (по статистике Steam).

При этом, хочется всякие новые варезы писать с расчетом на относительно новые процессоры, SSE3+ или вроде того. И если интелы в хозяйстве есть, от Core2 и выше, то с AMD - провал. Отсюда у меня возникает серия вопросов (википедию быстро пролистал, но там реально много, я лучше уточню):

Как оно ваще

  • Верно ли я понимаю, что AMD Llano - это продолжение старой серии, которая началась с K8. Т.е. отлаживаясь-бенчмаркаясь на ней - можно результаты экcтраполировать на более старые горшки?
  • AMD Trinity - это уже бульдозер, другой сокет (?? см. ниже) и все другое.
  • 3Dnow! - един, как в K6 появился, так новых инструкций не добавлялось. Разобрался: These instructions have many names, including 3DNow!+, 3DNow!ext, 3DNow!2, 3DNow! Professional, но ничего существенного для моих нужд не добавилось, ура.
  • Насколько embedded-процессоры (вроде Fusion E-350) позорны относительно десктопных процессоров 5-6-летней давности (ну, скажем, Intel Core2 Duo 1.83)?
Практика
  1. Существует ли сокет, в который можно было бы сунуть и процессор на K10-K12 и процессор на бульдозере (AM3+?)
  2. Вопрос 1, но процессоры берем с графическим ядром (Llano/Trinity) (нет?)
  3. Вопрос 1 или 2, но бывают ли такие сокеты на Mini-ITX мамках? (нет?)
Ну то бишь чешутся руки собрать что-то на AMD-Llano в Micro-ITX корпусе размером с мак-мини или чуть больше, да еще и с возможностью апгрейда на бульдозерные горшки.

Вроде как получается, что полного счастья нету, не бывает чтобы и с GPU и один сокет и два поколения?

В целях упрощения текста, я бульдозер и копер (piledriver) не различаю, оба поддерживают AVX и SSE4.1/2, с моей точки зрения (как разработчика) - это интелы без SSSE3 (да и то не факт, битик этот есть у AMD, может быть в википедии недописали).

О новых технологиях

Со страху заменил оставшиеся в сторадж-боксе старые сигейтовские SAS-овские терабайтники (2008-го года) на терабайтные же WD RE4 (SATA). Старые - пусть дискетками поработают.

Результат:

  • +10% к трансфер рейту, было ~630-650Mb/sec на чтение-запись, стало 720-730.
  • Минус 10 градусов к температуре, старые диски грелись до ~42C, нагревая соседей до 35, а теперь 30 градусов, при том что в комнате 22, а ящик стоит в шкафу, который висит на теплой стене).

Чтобы два раза не вставать: в этом же ящике с середины сентября живет 400-ваттный безвентиляторный БП Seasonic. Впечатления самые благоприятные: хрен с ним с шумом, этот питальник холодный. Понятно что гружу я его отсилы ватт на 200 (8x10вт диски, 65вт. CPU, карточки тоже теплые, а значит жрут, вентиляторы крутятся), но 500-вт Thermaltake, который там стоял до того, грелся при такой нагрузке вполне самостоятельно.

Стоит этот питальник неприлично, но если бороться за тишину или температуру, то он - хороший. Во второй сервер купил такой же, потому что тамошний Zalman тоже противно греется.

Pages

Subscribe to blog.lexa.ru: все статьи