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

Title Comment
Оно именно противоречит т.к.

Оно именно противоречит т.к. все встроенные кэши и тп - индексированы именем файла но так как переименование папок мы уже освоили - то с кэшами тоже справимся.

Ну таки да. Я ее не буду

Ну таки да. Я ее не буду обещать на 1.5.0, но вообще целимся мы в эту версию

PS: а функция изменения имени

PS: а функция изменения имени файла планируется eventually ? или это противоречит ...

Ну возможно там есть какие-то

Ну возможно там есть какие-то неявные синхронизации, я не задумывался

Вообщем, glTextSubImage2d из

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

TTL в случае сони это face

TTL в случае сони это face detection + matrix metering ... оно там стабильно хорошо и предсказуемо (насколько это применимо к TTL) меряет лица со вспышкой - сцена была из манекена (голова)

> То есть я правильно понимаю

> То есть я правильно понимаю, что X1T-S + TT685S (ну к примеру эта) работает некорректно?

у меня ихниe (который Adorama продает как FlashPoint) "биг айрон" = FlashPoint XPlor 600 TTL ( XPLOR600TTL ) он же в девичестве Godox Wistro AD600B ... но управление в X1T-S ... в принципе жить можно - редко надо на открытых диафрагмах снимать освещая сюжет такими strobe'ами и используя TTL замер (TTL мне нужен потому что снимая морды лица на ходу можно обходиться вполне без экспонометров и прочих пристрелок) - но сам принцип что зная (и признавая наличие) о дефекте уже 12 месяцев как никакого решения нет... у Jinbei такие же проблемы были - но там признали и за два месяца хоть как-то поправили

Jinbei было = https://s26.postimg.org/mgb9xqmeh/Orlit-_Jinbei-_Sony_TTL-suxx.jpg

пожаловался

Jinebei стало = https://s26.postimg.org/pf711rnl5/Jinbei_ORLIT_rulez_and_Godox_Flash_Poi...

тяп ляп, но уже лучше

для сравнения родная TTL впышка на той же самой сцене по сравнению с вообще без вспышки = https://s26.postimg.org/8z7r9it61/on_camera_flash_TTL_is_the_gold_standa...

замер и управление мощностью = тетива, хотя тот же китай поди

То есть я правильно понимаю,

То есть я правильно понимаю, что X1T-S + TT685S (ну к примеру эта) работает некорректно?

Вот уроды то....

это firmware в X1T-S = https:

это firmware в X1T-S = https://s26.postimg.org/le57lqzu1/Godox_TTL.jpg
это firmware в родной вспышкe = https://s26.postimg.org/vphkeerjd/Sony_TTL.jpg

> Вот про AD200 написано,

> Вот про AD200 написано, что она будет TTL с любым их внешним контроллером.

врут немного конечно - они уже год не могут починить firmware в X1T-S (Sony) для того что бы TTL правильно работало в плане управления мощностью импульса внешней вспышки/строба после TTL предвспыха ... на диафрагмах ширше 3.5-4.0 недосвет "обратно" пропорционален диафрагме... т.е. 2.8 будет на стоп темнее 4.0, 2 на два стопа и тд... парадокс, могли бы просто поправить табличкой в firmware X1T-S ... но нет, не могут осилить

У меня все в главном потоке

У меня все в главном потоке покаместь. С новым контекстом в отдельном потоке вроде ничего сложного. Это будет следующий шаг.
Не то что бы асинхронность glTexImage2D меня спасет... На рендеринге выскочит, да и простой memcpy в замапленный пиксельный буффер плюс теже 50мс.
Буду дальше пытаться разбираться...

Даже в 5.4 он есть.

Даже в 5.4 он есть.

Там с вынесением OpenGL в

Там с вынесением OpenGL в другой thread какие-то пляски с бубном.
Впрочем, в районе Qt 5.6 появился пример про threaded OpenGL - возможно эти пляски как-то упростили, не вдавался.

Да, это понятно. Но хотелось

Да, это понятно. Но хотелось избежать именно блокировки в потоке CPU.
Но почему в примере вызов не блокирующий, а у меня блокирующий - не понятно.

У вас в любом случае

У вас в любом случае отрисовка не может начаться до того, как в GPU залита текстура.

В том примерчике - он не

В том примерчике - он не блокирующий. Я там сделал размеры текстуры 4096x4096 и вижу copyTime в режиме c PBO - меньше 1мс.

Ну да, glTex(Sub)Image -

Ну да, glTex(Sub)Image - блокирующий.

Я рассчитывал, что с одним

Я рассчитывал, что с одним PBO буффером glTexSubImage будет работать асинхронно (через DMA) и я не залипну на 50мс в главном потоке. Но, по сути glTexSubImage _у меня_ почему-то блокирующий и занимает те же миллисикунды, что и простой glTexSubImage и memcpy.
Т.е., не учитывая распаковки, получается, что только загнать 80Mb рав в (избыточном, но оптимальном?) формате RGBA8 - это 50мс (macbook pro'14)... А с ним там еще что-то делать нужно. Т.е. в данном случае с OpenGL работать нужно с несколькими контекстами в разных потоках? Или есть какие известные решения? Ну, может, там, из области обработки видео - там, по идее, движение туда-сюда должно быть существенным?

Глянул тот пример.

Глянул тот пример.
pboMode=0 - 500fps,
1,2 = 1000fps
(округленно).

А имеет смысл, похоже, даже с одним буфером (а второй - смысла не имеет). Если вылезет заметно в профайлере - буду пробовать (хотя на фоне распаковки raw - вылезет вряд-ли)

У меня, во всяком случае пока

У меня, во всяком случае пока, не бывает "следующего кадра", соотв. в PBO не вижу смысла.

Алексей, здравсвуйте!

Алексей, здравсвуйте!

Добрался таки и я до Qt/GL... Увы
Уже после дня экспериментов с PBO нашел пример (http://www.songho.ca/opengl/gl_pbo.html). В примере три режима: без PBO, с одним PBO, c двумя PBO

Что вижу в результатах:

PBO mode: 1 (single PBO)
Transfer Rate: 1347.2 MB/s. (21.1 FPS)
Transfer Rate: 1360.9 MB/s. (21.3 FPS)
Transfer Rate: 1419.8 MB/s. (22.2 FPS)

PBO mode: 2 (two PBO)
Transfer Rate: 2405.6 MB/s. (37.6 FPS)
Transfer Rate: 2441.2 MB/s. (38.1 FPS)
Transfer Rate: 2446.7 MB/s. (38.2 FPS)

PBO mode: 0 (glTexSubImage2D)
Transfer Rate: 1855.7 MB/s. (29.0 FPS)
Transfer Rate: 1852.0 MB/s. (28.9 FPS)
Transfer Rate: 1860.3 MB/s. (29.1 FPS)

И что-то не понимаю. Т.е. цикл с glTexSubImage2D быстрее, чем с одним PBO.
Но в примере хоть тайминги glTexSubImage2D соответствуют действительности.

На моем же Qt-шном рабочем примере glTexSubImage2D при включенном буфере ну совсем не non-blocking.
Вызов glTexSubImage2D для данных ~80Mb блокирует на 50мс в пике, почти столько же, сколько занимает вышележащий memcpy в замапленный указатель.

Может, вы с подскажете, что я могу делать не так... Может, Qt резолвит функции OpenGL как-то по своему. Куда смотреть?

Спасибо!

PS: чукча не читатель :-)

PS: чукча не читатель :-)

на новой 1.4.5.1200 работает.

на новой 1.4.5.1200 работает... case dismissed значит

почему может не работать

почему может не работать "show in windows explorer" ? FRV v1.4.4.1194 @ W10x64

Есть, но он потерял смысл.

Есть, но он потерял смысл. Танков этих мне не надо, а на другой интернет - там 200 мегабит и это на 10 рублей дороже 200 мегабит по обычному тарифу.

Этот акционный тариф и сейчас

Этот акционный тариф и сейчас есть.

У них были 200 + какие-то

У них были 200 + какие-то танки 500 (к серверам танков) => 500р. Но я так и не собрался, а сейчас вот уже не надо.

А ещё у них был акционный

А ещё у них был акционный тариф 300 мегабит за 590р, который находился только поисковиком (т.е. в списке акций его не было), я доволен :)
Ещё бы бридж сделали, я был бы вообще счастлив.

нужны, но для другого -

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

Случайно выяснилось, что этот

Случайно выяснилось, что этот баг исправлен в Qt 5.9.3
(ну или раньше, но в 5.9.3 уже все хорошо)

Ну и значит без моего костра обойдутся.

Pages

Subscribe to comments_recent_new