Свежие комментарии

Title	Comment
Начнем с конца._mm_load_ps -	Начнем с конца. _mm_load_ps - читает 16 байт (в регистр). Инструкция нужна ровно для этого: если значение затем используется (несколько раз), то наверное его стоит поднять в регистр. Далее. Компилятор, конечно, может породить код, который на рантайме проверяет, какой дали указатель и в зависимости от этого - выполняет movaps или movups. Теперь представим себе цикл, который выполняется, скажем, 80 млн. раз при обработке одного 80-mpix изображения и содержит в себе два load и 1 store. У нас будет или 3 локальных проверки (на каждой итерации) или развосьмерение кода (и 3 проверки всего, на все итерации). Оба плохо, как мне кажется.
Ну вопрос собственно	Ну вопрос собственно вот: Компилятор может определить ситуацию, когда в _mm_loadu_ps передаются выровненные данные и для этого случая использовать movaps вместо movups? И зачем тогда нужен _mm_load_ps, если можно через делать через указатели?
В чем ваш вопрос то?	В чем ваш вопрос то?
А нужен ли _mm_load_ps?	Я в GCC проверил два варианта Первый вариант: `float in[]={0,0,0,0,0,0,0,0}; __m128 a, b,c; scanf("%f%f%f%f%f%f%f%f", in,in+1,in+2,in+3,in+4,in+5,in+6,in+7); a = _mm_loadu_ps(in); b = _mm_loadu_ps(in+4); c = _mm_add_ps(a , b ); float out[4]; _mm_store_ps(out, c ); printf("%f %f %f %f", out[0],out[1],out[2],out[3]);` Дает такой ассемблерный выхлоп в GCC: `... call __isoc99_scanf movups 0(%rbp), %xmm1 movups (%rbx), %xmm0 movl $.LC1, %edi addps %xmm1, %xmm0 movl $4, %eax movaps %xmm0, 64(%rsp) cvtss2sd 64(%rsp), %xmm0 cvtss2sd 76(%rsp), %xmm3 cvtss2sd 72(%rsp), %xmm2 cvtss2sd 68(%rsp), %xmm1 call printf ...` И такой вариант с указателями вместо _mm_loadu_ps: `float in[]={0,0,0,0,0,0,0,0}; __m128 a, b,c; scanf("%f%f%f%f%f%f%f%f", in,in+1,in+2,in+3,in+4,in+5,in+6,in+7); a = (void )in; b = (void )(in+4); c = _mm_add_ps(a , b); float out[4]; _mm_store_ps(out, c ); printf("%f %f %f %f", out[0],out[1],out[2],out[3]);` получаем: `... call __isoc99_scanf movaps 32(%rsp), %xmm0 movl $.LC1, %edi addps 48(%rsp), %xmm0 movl $4, %eax movaps %xmm0, 64(%rsp) cvtss2sd 64(%rsp), %xmm0 cvtss2sd 76(%rsp), %xmm3 cvtss2sd 72(%rsp), %xmm2 cvtss2sd 68(%rsp), %xmm1 call printf ...` Если в первом случае вместо _mm_loadu_ps использовать _mm_load_ps, результаты будут одинаковы. Компилятор может определить ситуацию, когда в _mm_loadu_ps передаются выровненные данные и для этого случая использовать movaps вместо movups? И зачем тогда нужен _mm_load_ps, если можно через делать через указатели?
Да, точно, 3-дневные на которые нет ответа - тоже можно. Ну	Да, точно, 3-дневные на которые нет ответа - тоже можно. Ну и прекрасно (с той поправкой, что мой импортирующий варез берет камент один раз)
пока никто не <s>зашкварил</s> ответил на камент. что логичн	пока никто не ~~зашкварил~~ ответил на камент. что логично.
Я пришел - тебя нема. Удалить дают, редактировать - нет. Ed	Я пришел - тебя нема. Удалить дают, редактировать - нет. Edited: ага, дают, редактировать но недолго?
я никак не включал подводишь мышку на свой камент, видишь по	я никак не включал подводишь мышку на свой камент, видишь появляются икнонки. с карандашом -- нужная тебе
Как включить?	Как включить?
нынче редактирование своих каментов в жж бесплатно	нынче редактирование своих каментов в жж бесплатно
Кстати, меня там наверху,	Кстати, меня там наверху, кажется, убедили, что демозаика по яркости тоже невозможна без пространственной интерполяции. Или таки возможна? Я вот уже запутался :)
Хм. Да, кажется, я что-то	Хм. Да, кажется, я что-то недодумал тут. Буду сейчас считать уже, а не в голове придумывать.
>Ровно та же модель. Я не	>Ровно та же модель. Я не понимаю. Можете объяснить как зная только интегральные значения RGB камеры перейти к полному спектру сигнала. Не - там есть всякие предположения о спектральном составе излучения, разные модели и т.д. Но мы уйдем далеко. Ну и на каких длинах волн или диапазонах длин будем работать? Сколько времени это потребует? > Для меня demosaic -- это всегда интерполяция между точками, уже смешение. Которого, по идее, для деконовлюшена, допускать нельзя. Вот давайте на этом остановимся, потом пойдем дальше. Как зная только значения 1(одного) канала в каждом конкретном пикселе без демозаика мы узнаем недостающие 2 или 3 в зависимости от камеры? Можете рассказать? Типа делай раз, делай два и т.д... Либо понятнее для солдата и матроса то с чего началось: "Т.е., кажется, правильный путь..."
> Разные спектры могут дать	> Разные спектры могут дать одинаковые интегральные значения. Да. Это так. Но в этом вообще проблема и с обычной обработкой -- вся наша работа с цветом начинается с того, что мы предполагаем, что знаем свет в сцене (тот самый баланс белого), который описываем всего двумя параметрами, чего явно недостаточно для всех возможных спектров. Но мы с самого начала согласились на некоторую модель и используем её. Вот так и тут. Ровно та же модель. > Ну а я о чем писал? Возможно, мы запутались в терминах. Для меня demosaic -- это всегда интерполяция между точками, уже смешение. Которого, по идее, для деконовлюшена, допускать нельзя.
>Демозаик не делать! Сделать	>Демозаик не делать! Сделать 4 картинки "Как будто все фильтры были красные," "как будто все фильтры были синие," Как? >Переходить каким то способом от интегральных сигналов к полному спектру? >Да. Разные спектры могут дать одинаковые интегральные значения. > Поканально. Каждый канал потом обработать деконволюшеном PSF Ну а я о чем писал? >сложить только нужные точки обратно в RAW Ну так ровно это и получается >напустить обычный дебаер с интерполяцией, как будто ничего и не было. Так а я о чем? 2) demosaic, deconvolution, demosaic
Я бы очень, на самом деле,	Я бы очень, на самом деле, хотел услышать вашу оценку этой идеи. Потому что вы -- профессионал, а я-то так, погулять вышел, начитавшись всякого по верхам. Спасибо.
Демозаик не делать! Сделать 4	Демозаик не делать! Сделать 4 картинки "Как будто все фильтры были красные," "как будто все фильтры были синие," "как будто все фильтры были зелёные-1" и "как будтов се фильтры были зелёные-2". Без интерполяции, который нужен для любого демозаика. Чисто локально, попиксельно. Ну, исходя из того, что мы знаем о спектре освещения (он же -- баланс белого) и характеристиках фильтров (которые нам всё равно нужны для восстановления цвета, так что какой-то профиль у нас обязан быть). Переходить каким то способом от интегральных сигналов к полному спектру? Да. Поканально. Каждый канал потом обработать деконволюшеном PSF (и вот там нам выше старшие товарищи пишут что у каждого канала PSF будет свой), сложить только нужные точки обратно в RAW (из первой картинки в списке выше взять только красные точки, из второй синие и так далее) и напустить обычный дебаер с интерполяцией, как будто ничего и не было.
Демозаика по яркости,	Демозаика по яркости, деконволюция, демозаика по цвету.
>а оно мимо кэша? а то по картинкам мимо кэша не бывает В	>а оно мимо кэша? а то по картинкам мимо кэша не бывает В мане на команду пишут: The non-temporal hint is implemented by using a write combining (WC) memory type protocol when writing the data to memory. Using this protocol, the processor does not write the data into the cache hierarchy, nor does it fetch the corresponding cache line from memory into the cache hierarchy.
Ну вот в той же табличке есть copy: 11Gb/sec. Так как пишем	Ну вот в той же табличке есть copy: 11Gb/sec. Так как пишем со скоростью 22, значит, получается, читаем тоже 22Gb/sec, тогда вместе будет 11.
>Я предложил сделать 4 разных	>Я предложил сделать 4 разных полноразмерных картинки, под каждый канал. Т.е. не 4 картинки с half-интерполяцией из 1 канала. Т.е. в каждом канале учитываются все остальные, просто для красного делается одно домножение на коэффициенты, для зелёных -- на другое, и так далее (сам же обрабатываемый сейчас канал не трогается) Ну а я о чем? Demosaic. Не half. Какие пробовал - написал. Восстановил RGB камеры. А как без демозаика восстановить? Импульсную характеристику байера нарисовать? Как? Там еще больше проблем наберется. Переходить каким то способом от интегральных сигналов к полному спектру? Дальше каждый канал деконволюшн. Получили новые значения RGB камеры. И по новым значениям демозаик. Делать по Y каналу 1) поленился, 2) дополнительные ошибки. Делал еще demosaic -> Lab -> L channel deconvolution, но в лоб не сравнивал.
а, еще -- ты говоришь про запись. а с чтением что?	а, еще -- ты говоришь про запись. а с чтением что?
насчет мелкости -- откуда-то zoom взялся.	насчет мелкости -- откуда-то zoom взялся.
> Табличка (да и код) показываются у меня тремя браузерами н	> Табличка (да и код) показываются у меня тремя браузерами нормально (FF, IE, Chrome), скриншот не нужен. там весь текст очень мелкий. очень. в 18 FF. > А я вот тебе говорю, что movntps (т.е. мимо кэша) а оно мимо кэша? а то по картинкам мимо кэша не бывает
Табличка (да и код) показываются у меня тремя браузерами нор	Табличка (да и код) показываются у меня тремя браузерами нормально (FF, IE, Chrome), скриншот не нужен. То что ты процитировал - это про кэш. Не хочу разбираться, там все очевидно что сложно и случаи разные бывают. А я вот тебе говорю, что movntps (т.е. мимо кэша) работает со скоростью 22Gb/sec у меня (на объеме данных на ~2 порядка больших, чем L3 cache).
боже, по ссылке свершенно не читабельно. скриншот делать? н	боже, по ссылке свершенно не читабельно. скриншот делать? ну вот я читаю Intel 64 and IA-32 Architectures Optimization Reference Manual старница 61 The LLC consists of multiple cache slices. The number of slices is equal to the number of IA cores. Each slice has logic portion and data array portion. The logic portion handles data coherency, memory ordering, access to the data array portion, LLC misses and writeback to memory, and more. The data array portion stores cache lines. Each slice contains a full cache port that can supply 32 bytes/cycle. From the processor cores and the GT view, the LLC act as one shared cache with multiple ports and bandwidth that scales with the number of cores. The LLC hit latency, ranging between 26-31 cycles, depends on the core location relative to the LLC block, and how far the request needs to travel on the ring. ну и получаю, что ядро из L3 кэша будет получать данные примерно со своей частотой
Комментарии становятся всё	Комментарии становятся всё уже! Я предложил сделать 4 разных полноразмерных картинки, под каждый канал. Т.е. не 4 картинки с half-интерполяцией из 1 канала. Т.е. в каждом канале учитываются все остальные, просто для красного делается одно домножение на коэффициенты, для зелёных -- на другое, и так далее (сам же обрабатываемый сейчас канал не трогается). А демозаик не делается вообще. Блин. Рисовать надо :) Я вот пока теоретически всё рассуждаю и не знаю, как там фильры устроены -- я думал вот они просто контролируемо матовые, а там, оказывается, расщепление, ещё какие-то хитрости... Да, и, по идее, нужен не spatial invariant, так как у всех обхективов центр и углы различаются заметно. Но это уже высший какой-то пилотаж.
В дополнение. То что	В дополнение. То что получалось (визуально) с airy за один проход, c гауссом просто за допустим 5 deconvolution итераций.
>Поканальный до демозаика --	>Поканальный до демозаика -- это ведь совсем не правильно, потому что там же каналы явно друг на друга влияют. Дак вроде вы это и предложили вроде, поэтому и ответил. Или я неправильно понял? >И я сиииильно не уверен, что гаусс -- хорошая модель, особенно учитывая что от влияния объектива мы избавиться не можем. Мне показалось что для антиалиас фильтра должно бы подойти (не про D800). Да и для зажатия диафрагмы до некоторой степени тоже. Но в любом случае я пробовал и airy psf (сильное зажатие дырки). Ну а в общем случае - конечно. О spatial invarian psf (во какие слова знаю) в общем случае говорить не совсем корректно, хотя сейчас используют в основном именно такие(IMHO, но видел и другие статьи).
Неправильно. Я бы сказал, что 20-25Gb/sec на одном ядре - эт	Неправильно. Я бы сказал, что 20-25Gb/sec на одном ядре - это нормальная величина для современных горшков. Вот, я мерял: http://blog.lexa.ru/2011/09/08/opyat_pro_movntps.html 22Gb/sec на i7-2600K

Свежие комментарии

Pages