История изменений
Исправление Stanson, (текущая версия) :
Насчет твоих GCH одно интересно - сколько они весят и сколько времени нужно процессору чтобы это сгенерить
Весят в зависимости от разрешения SLM - один кадр может сотни мегабайт весить. Очень мелкий 8-мибитный кадр 4096x2304 весит 10Мб. Процессор генерит относительно быстро, там, в общем-то банальнейший raytracing и БПФ всего лишь. С OpenCL вообще хорошо. От нескольких кадров в секунду, до нескольких кадров в минуту в зависимости от сложности 3D модели. Выводится через HDMI. Если SLM 8192х8192 например, или ещё больше то обычно несколько последовательных кадров объединяется, ибо видимокарты не умеют в такие огромные разрешения. Сжимать нельзя, артефакты сжатия всю фазовую малину попортят и получится не голограмма, а срань какая-то непонятная, а lossless кодеки для видео жрут неадекватно много почему-то, а от какого-нибудь относительно шустрого HuffYUV толку в смысле размера мало.
Вообще тяжелые вычислительные задачи и ноутбук - ну это как на феррари навоз возить на поля
Это не тяжёлая вычислительная задача, просто выхлоп очень жирный из-за особенностей голографии.
Разработать оттестить алгоритм на ноуте можно - но по нескольку раз в день генерить терабайты данных?
А как ты оттестишь алгоритм не генеря терабайты? Для SLM 8192х8192х8bit ролик на 10 минут уже 40Гб. Десяток роликов с разными настройками или фичами алгоритма для сравнения - уже почти полтерабайта запилено.
Ну это как типа генерировать, монтировать или там накладывать несложный эффект на совершенно непожатое 4к или 8к видео. Процессорных затрат почти нет, в память не влезает, просто пережёвывает диск.
Ясен пень, что это уж очень специфичный юзкейс, но полно и других, вполне прозаичных задач, где на диск пишется куча данных. Да даже долбаные браузеры (особенно Firefox) постоянно жуют диск (даже если памяти хоть жопой жуй), если не догадаешься на какой-нибудь $HOME/.cache/mozilla tmpfs смонтировать.
Исходная версия Stanson, :
Насчет твоих GCH одно интересно - сколько они весят и сколько времени нужно процессору чтобы это сгенерить
Весят в зависимости от разрешения SLM - один кадр может сотни мегабайт весить. Очень мелкий 8-мибитный кадр 4096x2304 весит 10Мб. Процессор генерит относительно быстро, там, в общем-то банальнейший raytracing и БПФ всего лишь. С OpenCL вообще хорошо. От нескольких кадров в секунду, до нескольких кадров в минуту в зависимости от сложности 3D модели. Выводится через HDMI. Если SLM 8192х8192 например, или ещё больше то обычно несколько последовательных кадров объединяется, ибо видимокарты не умеют в такие огромные разрешения. Сжимать нельзя, артефакты сжатия всю фазовую малину попортят и получится не голограмма, а срань какая-то непонятная, а lossless кодеки для видео жрут неадекватно много почему-то, а от какого-нибудь относительно шустрого HuffYUV толку в смысле размера мало.
Вообще тяжелые вычислительные задачи и ноутбук - ну это как на феррари навоз возить на поля
Это не тяжёлая вычислительная задача, просто выхлоп очень жирный из-за особенностей голографии.
Разработать оттестить алгоритм на ноуте можно - но по нескольку раз в день генерить терабайты данных?
А как ты оттестишь алгоритм не генеря терабайты? Для SLM 8192х8192х8bit ролик на 10 минут уже 40Гб. Десяток роликов с разными настройками или фичами алгоритма для сравнения - уже почти полтерабайта запилено.
Ну это как типа генерировать, монтировать или там накладывать несложный эффект на совершенно непожатое 4к или 8к видео. Процессорных затрат почти нет, в память не влезает, просто пережёвывает диск.