Ага, математика time warp — такая же. На «сферу» проецируется изображение полученное рендером из одного положения головы, грубо говоря. Вместо сферы рисуется тот самый distortion mesh, и математика — в шейдере, но иначе все так.
Собственно действительно есть в GearVR режим когда вместо того чтобы рисовать 3д сцену и отдавать 2д картинку в time warp, можно в time warp сразу отдать cubemap — 6 2д картинок составляющих куб. Примерно так работает видео.
Да, я в курсе, поэтому и комментарий в начале статьи оставил. Я в основном говорю и пишу на английском, поэтому в свободном полете мысли сложно автоматически переводить, особенно когда четко не знаешь перевод (как перевести experiences? :). Надеюсь в целом не слишком режет глаз!
Я не очень понял про сферы, но ощущение что описано нечто эквивалентное timewarp… :)
Про предугадывание. Безусловно, все используют prediction. Главная проблема в том что движение головы предсказуемо фактически только на линейных участках. И гарантированно непредсказуемо в самом начале движения (резкие повороты головы). Поэтому prediction несколько улучшает tracking, и те самые последние 10-15 ms им можно «убирать», но если latency условно 40 ms, то prediction не может их скрыть так чтобы было не заметно.
С 60 Hz люди бьются на три группы:
— Недостаточно чувствительные — не видят мерцания вообще
— Достаточно чувствительные чтобы видеть мерцание смотря на телефон (в GearVR есть такой режим при котором low persistence mode включается прямо в операционной системе без всякого VR), но недостаточно чтобы видеть его в VR
— Достаточно чувствительные чтобы видеть мерцание везде
Насколько я знаю, пояснение второго пункта условно в отсутствие reference point — в VR мерцает ВСЕ :)
Говорят, порог чувствительности примерно 85 Hz — т.е. людей которые видят мерцание на 90 Hz исчезающе мало. Так что проблема в целом решается более высоким refresh rate (который все равно надо бы делать чтобы уменьшать latency до time warp и иметь меньше проблем с его артефактами — например, для устройств с positional tracking time warp компенсирует целиком повороты, но ничего не делает для движений головы — поэтому надо базовую latency вытягивать в районе 20 ms без time warp. У Oculus Rift и HTC Vive это в целом получается)
Отсутствие positional tracking — это недостаток всех текущих мобильных VR устройств.
Все не-мобильные устройства — Oculus Rift, HTC Vive, PSVR — имеют positional tracking.
Проблема в том что существующие технологии которые достаточно хороши чтобы их можно было положить в основу продукта требуют внешних камер (Oculus Rift / PSVR), внешних лазерных излучателей (HTC Vive) либо большого количества хитрых камер в самом устройстве (Hololens). Для маленькой дешевой коробочки в которую вставляется телефон это все не очень практично.
Наверняка Oculus работает в этом направлении, будет интересно — но я не ожидаю никаких новостей в мире mobile positional tracking в 2016.
Да, разумеется, в общем случае оно так.
В частном случае это был libpng, где предполагается делать error handling с помощью setjmp, но исключения тоже работают… на некоторых платформах :)
По стандарту extern «C» функции не могут кидать исключения (чем кстати некоторые компиляторы на некоторых платформах пользуются, отключая генерацию unwind info, после чего отваливается пробрасывание исключений через С-шный код из С++-ных коллбеков, увы)
По поводу двух последних багов, которые не просто UB а самое настоящее падение.
Вы пробовали написать тесты на эти примеры?
Кажется что либо возможно написать такой С++ код который соответствует необходимым условиям для креша — и тогда он должен быть в тестах — либо анализатор (как и авторы кода!) запутался в логике и не понял почему условия недостижимы.
Например, есть плагин к Visual Studio — VsVim. Open-source F# код. Работает очень хорошо, полностью покрывает мой сабсет. Допускаю что есть люди чей сабсет покрыт не полностью, но думаю что таки очень большой процент пользователей Vim будет доволен.
Например, есть плагин к Sublime Text — Vintageous. Open-source Python код. Работает очень плохо, очень легко сломать стейт загнав плагин в перманентное исключение, плюс автор видимо мало пользуется Vim или пользуется другим сабсетом чем я т.к. половина нужной мне Vim функциональности не работает или работает иначе.
Конечно, ряд вещей типа плагинов или всяких Ex фишек типа argdo отсутствует и там и там, но с VsVim приятно работать, а с Vintageous — нет. Т.е. если Vim workflow подразумевает кучу кастомных key bindings и плагинов то наверное никуда не деться.
Читать код и находить в нем ошибки без сторонних утилит и документации — незаменимое умение. По ряду причин, как то:
— code review: практика вообще целиком про это (у тех у кого это больше чем «тут маленькую букву надо заменить на большую»)
— post-mortem отладка: умения строго недостаточно но без него даже начинать бессмысленно
— собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Конечно, всегда есть скользкий момент, что именно спрашивать и как именно трактовать ответ — если человек пишет в резюме про С++ но не умеет сортировать встроенными средствами, это сразу «нет» или можно еще поговорить? А если не умеет выводить данные в файл? А если пишет про C но не знает что такое malloc?
Но если спрашивать много и разнообразно — то кругозор становится виден очень четко. Если человек в целом знает как пользоваться платформой но не в курсе в каком порядке идут аргументы memcpy то есть маленький шанс что он это выучит когда наймем, а если он путается в показаниях в каждом углу стандартной библиотеки то может лучше не надо?
Список отфильтрованных полей — ну, есть разные варианты.
Есть вариант при котором последующие поля читаются с дырками — в зависимости от результатов фильтрации по предыдущим. Выглядит так что с битовой упаковкой такое точно не работает.
Есть вариант при котором все поля читают все объекты, и обновляют битовую/байтовую маску, а потом маску надо еще раз прочитать. Это читать больше данных в реальности, но все равно иногда меньше чем AoS.
Есть промежуточный вариант при котором мы обрабатываем объекты группами по например 128, и для каждого объекта последовательно обрабатываем все поля. Это скорее всего лучше предыдущих двух способов (первого — потому что можно все равно делать битовую упаковку; второго — потому что не тратим memory bandwidth на запись-чтение маски).
Но я согласен с тем что надо пробовать, не очевидно что лучше на данном примере.
Битовая упаковка не является преимуществом — просто если ее не делать то точно будет хуже (т.к. заметно больше данных читать), а если делать то непонятно.
SoA с битовой упаковкой оставит количество данных тем же — но есть возможность часть данных не читать, если по данному полю фильтрации нет.
Конечно, надо *очень* аккуратно будет писать код который сравнивает каждое поле. Т.е. наверное быстрый код с SoA в данном случае написать заметно сложнее. Зато потом можно добавлять поля не меняя код :)
Собственно действительно есть в GearVR режим когда вместо того чтобы рисовать 3д сцену и отдавать 2д картинку в time warp, можно в time warp сразу отдать cubemap — 6 2д картинок составляющих куб. Примерно так работает видео.
Про предугадывание. Безусловно, все используют prediction. Главная проблема в том что движение головы предсказуемо фактически только на линейных участках. И гарантированно непредсказуемо в самом начале движения (резкие повороты головы). Поэтому prediction несколько улучшает tracking, и те самые последние 10-15 ms им можно «убирать», но если latency условно 40 ms, то prediction не может их скрыть так чтобы было не заметно.
— Недостаточно чувствительные — не видят мерцания вообще
— Достаточно чувствительные чтобы видеть мерцание смотря на телефон (в GearVR есть такой режим при котором low persistence mode включается прямо в операционной системе без всякого VR), но недостаточно чтобы видеть его в VR
— Достаточно чувствительные чтобы видеть мерцание везде
Насколько я знаю, пояснение второго пункта условно в отсутствие reference point — в VR мерцает ВСЕ :)
Говорят, порог чувствительности примерно 85 Hz — т.е. людей которые видят мерцание на 90 Hz исчезающе мало. Так что проблема в целом решается более высоким refresh rate (который все равно надо бы делать чтобы уменьшать latency до time warp и иметь меньше проблем с его артефактами — например, для устройств с positional tracking time warp компенсирует целиком повороты, но ничего не делает для движений головы — поэтому надо базовую latency вытягивать в районе 20 ms без time warp. У Oculus Rift и HTC Vive это в целом получается)
Все не-мобильные устройства — Oculus Rift, HTC Vive, PSVR — имеют positional tracking.
Проблема в том что существующие технологии которые достаточно хороши чтобы их можно было положить в основу продукта требуют внешних камер (Oculus Rift / PSVR), внешних лазерных излучателей (HTC Vive) либо большого количества хитрых камер в самом устройстве (Hololens). Для маленькой дешевой коробочки в которую вставляется телефон это все не очень практично.
Наверняка Oculus работает в этом направлении, будет интересно — но я не ожидаю никаких новостей в мире mobile positional tracking в 2016.
В частном случае это был libpng, где предполагается делать error handling с помощью setjmp, но исключения тоже работают… на некоторых платформах :)
Вы пробовали написать тесты на эти примеры?
Кажется что либо возможно написать такой С++ код который соответствует необходимым условиям для креша — и тогда он должен быть в тестах — либо анализатор (как и авторы кода!) запутался в логике и не понял почему условия недостижимы.
Например, есть плагин к Visual Studio — VsVim. Open-source F# код. Работает очень хорошо, полностью покрывает мой сабсет. Допускаю что есть люди чей сабсет покрыт не полностью, но думаю что таки очень большой процент пользователей Vim будет доволен.
Например, есть плагин к Sublime Text — Vintageous. Open-source Python код. Работает очень плохо, очень легко сломать стейт загнав плагин в перманентное исключение, плюс автор видимо мало пользуется Vim или пользуется другим сабсетом чем я т.к. половина нужной мне Vim функциональности не работает или работает иначе.
Конечно, ряд вещей типа плагинов или всяких Ex фишек типа argdo отсутствует и там и там, но с VsVim приятно работать, а с Vintageous — нет. Т.е. если Vim workflow подразумевает кучу кастомных key bindings и плагинов то наверное никуда не деться.
— code review: практика вообще целиком про это (у тех у кого это больше чем «тут маленькую букву надо заменить на большую»)
— post-mortem отладка: умения строго недостаточно но без него даже начинать бессмысленно
— собственно написание кода: код с этим умением пишется быстро и радостно (у тех у кого это больше чем «google -> stack overflow -> copy & paste -> profit»), и является правильным с гораздо большей вероятностью
Конечно, всегда есть скользкий момент, что именно спрашивать и как именно трактовать ответ — если человек пишет в резюме про С++ но не умеет сортировать встроенными средствами, это сразу «нет» или можно еще поговорить? А если не умеет выводить данные в файл? А если пишет про C но не знает что такое malloc?
Но если спрашивать много и разнообразно — то кругозор становится виден очень четко. Если человек в целом знает как пользоваться платформой но не в курсе в каком порядке идут аргументы memcpy то есть маленький шанс что он это выучит когда наймем, а если он путается в показаниях в каждом углу стандартной библиотеки то может лучше не надо?
Уже не говоря о том что мерять людей по производной их роста это вполне хороший подход в зависимости от того куда и на какую должность нанимать.
Есть вариант при котором последующие поля читаются с дырками — в зависимости от результатов фильтрации по предыдущим. Выглядит так что с битовой упаковкой такое точно не работает.
Есть вариант при котором все поля читают все объекты, и обновляют битовую/байтовую маску, а потом маску надо еще раз прочитать. Это читать больше данных в реальности, но все равно иногда меньше чем AoS.
Есть промежуточный вариант при котором мы обрабатываем объекты группами по например 128, и для каждого объекта последовательно обрабатываем все поля. Это скорее всего лучше предыдущих двух способов (первого — потому что можно все равно делать битовую упаковку; второго — потому что не тратим memory bandwidth на запись-чтение маски).
Но я согласен с тем что надо пробовать, не очевидно что лучше на данном примере.
Битовая упаковка не является преимуществом — просто если ее не делать то точно будет хуже (т.к. заметно больше данных читать), а если делать то непонятно.
Т.е. отфильтровали целиком по первому полю, потом целиком по второму итп.
clang 4.2 build 425 это старый clang из Xcode, как я понимаю.
gcc 4.7.3 — 1 минута 46 секунд (тайминг выше был из mingw-gcc 4.7.2)
clang 3.2.1 — 2 минуты 6 секунд
SoA с битовой упаковкой оставит количество данных тем же — но есть возможность часть данных не читать, если по данному полю фильтрации нет.
Конечно, надо *очень* аккуратно будет писать код который сравнивает каждое поле. Т.е. наверное быстрый код с SoA в данном случае написать заметно сложнее. Зато потом можно добавлять поля не меняя код :)
cl /Ox /EHsc /bigobj
g++ -O3
Core i5 @ 2.6 (мой), cl 17.00.50727.1 — время 7 минут 11 секунд
Core i5 @ 2.6 (мой), gcc 4.6.1 — падает :(
Core i7 @ 3.3, cl 17.00.60315.1 — время 3 минуты 2 секунды
Core i7 @ 3.3, gcc 4.7.2 — время 2 минуты 30 секунд
Мораль — мне пора обновить компиляторы!
Я компилирую вот этот файл:
github.com/AlexeyAB/cpp_find_order/blob/ba568e1f9652ae106d4e50f978ff074269d16bc9/main.cpp
Точная версия (64-битного) компилятора 17.00.50727.1.
Жду результатов компиляции этим же компилятором с Вашего калькулятора.