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

Title	Comment
У меня все в главном потоке	У меня все в главном потоке покаместь. С новым контекстом в отдельном потоке вроде ничего сложного. Это будет следующий шаг. Не то что бы асинхронность 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 уже все хорошо) Ну и значит без моего костра обойдутся.
В 2017-м можно экономить	В 2017-м можно экономить мобильный трафик, например.
libjpeg нет конечно, это	libjpeg нет конечно, это референс, да и откуда ей ум, там надо анализировать ошибку и итеративно подбирать что где он арезко подскочит. За умные денег хотят… Хотели… Нужны ли они в 2017 не ясно. Хотя если хранить петабайты спутниковых снимков, наверное, это возня, позволяющая сэкономить 30% места, окупится. А у простых людей — не очень.
Умные наверное и делают.	Умные наверное и делают. libjpeg вроде нет.
А разве умные упаковщики JPEG	А разве умные упаковщики JPEG не делают ровно это — разная дискретизация DCT-коэффициентов для разных блоков?
И, да, покажите протокол	И, да, покажите протокол теста на котором вы статистически значимо различи 48KHz и 192KHz. «я слышу» — это аудиофильство. Только двойное слепое тестирование что-то значит. Кстати, а где вы музыку взяли для 192KHz? Т.е. где вы взяли музыкальный материал где есть какая-то значимая мощность после 20KHz?
вы правда не слышите разницы	вы правда не слышите разницы между 48 кГц и 192 кГц? Нет. При этом на некоторй (далеко не всей) музыке статистически значимо различаю MP3/320 и loseless. очевидно, что для переходного процесса (а delta-импульс - идеальный переходной процесс) не существует такого понятия, как верхняя частота спектра. она бесконечна. и никакой частоты дискретизации не хватит, чтобы оцифровать delta-импульс. соответственно, для корректной передачи фронтов (атака!) нужна бесконечная частота дискретизации. Дельта-импульса у вас не будет. Физика не позволяет. Ну, знаете, масса струны, ускорение, вот это вот всё. Плюс второй — человек не слышит выше 20KHz, за редким-редким-редким исключением. Спектр всегда ограничен и для музыки он в реальности ограничен 20KHz. Если бы у нас были бы уши как у собак то было бы 192KHz у нас на CD. Но у нас другие уши.
Ну я считаю, что обычный JPEG	Ну я считаю, что обычный JPEG уже освоен без меня и прикладывать усилия в этом месте сравнительно бессмысленно (хотя конечно "переменное сжатие" - богатая идея, можно обдумать)
А, теперь понятно. Я просто в	А, теперь понятно. Я просто в начале года упражнялся с JPEG2000, там по ходу одной задачки надо было кодировать картинки с переменным уровнем сжатия - ну чтобы некоторые области были вообще без потери качества, а остальные с потерей - формат это поддерживает, но вот библиотека, которая у меня под рукой была - нет. Ну и морозным январским утром решил я написать кодировщик сам. С нуля. Две недели холодными зимними вечерами в комнате стояла жара от моих плавящихся мозгов. Я так последний раз трахался наверное лет двадцать назад, когда писал быструю реализацию медианного фильтра на ассемблере с только-только появившимся набором инструкций ММХ. В конце концов я задачку сжатия решил весьма неэлегантным, но вполне себе работоспособным образом.
Не, ну конечно libjpeg	Не, ну конечно libjpeg Просто если jpeg_read_scanlines() сунуть буфер не на полную картинку, а на сканлайн, то получается сюрприз - оно пишет "до начала буфера". И это нормально для progressive, если задуматься.
скорее из образа системы.	скорее из образа системы. пару раз точно приходилось ставить родные для получения opengl, при том что aero/DX работали полностью.

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

Pages