Обжекшен! Уже давно можно не экономить бумагу, давайте перестанем использовать обозначения в один символ?

но в разумных пределах, иначе шум (sampling noise) будет заметен, да и качество материалов может начать быть «пластилиновым».

Нет, про глобальное качество это понятно. А более локальные изменения можно сделать? Никто не будет придираться, если однотонная серая область будет чуть более однотонной. Никто не будет разглядывать, что тень от камешка на заднем плане нарисована чуть более грубым алгоритмом, чем остальная сцена. Вот что-то в таком плане есть? Мало ли, мне пришла в голову божественная бизнес-идея.

Аргумент? :)

Если на то пошло, а сколько стоит аренда фермы для рендера? У них и электричество оптом, и железяки мощнее. При таком раскладе вам и на дискретную видяху тратиться не надо при более быстром результате.

200 рублей разницы, если учитывать 8% ускорения. По хорошему, потребление процессора тоже надо скостить, ну да ладно. Предполагаю, что до этого вы работали дольше чем неделю. Вероятно, не бесплатно. :) Т.е. да, разница есть, но сколько-либо существенным фактором в выборе железа я бы её точно не назвал. А в блендере есть какие-нибудь инструменты, позволяющие настраивать качество картинки? Пожертвовать качеством отражений в каком-нибудь темном углу и сразу выиграть часов десять на рендер, скажем. Вот здесь уже можно разглядеть потенциал для экономии.

Я потерял чудный сайтик, который вместе с прочими характеристиками еще и стоимость содержания показывает, но, скажем, вот видео, демонстрирующее (6:01), что будет, если энергопотребление увеличить вдвое (тут для процессоров, и методики измерения меня смущают, но, скорее всего, если сделать нормальные испытания, результаты на порядок не поменяются). Это при нагрузке 100%. Я не особо в курсе специфики работы дизайнеров, но я сомневаюсь, что они 24\7 что-то рендерят. Скорее всего, видеокарта вместе с процессором в это время практически простаивают, а в этом случае разницы видюхами AMD и Nvidia практически нет. Процессор, монитор и кофемашина вместе перекрывают эти несчастные 100 ватт.
www.youtube.com/watch?v=IeIFj-3RYKU

либо совсем немногим дольше ждать финальной прорисовки сцен за счёт ощутимой экономии на электричестве

Ощутимой ли? Из расчетов, которые я видел, следует, что за год набегает разница порядка тысячи рублей. Это несерьезно, разве что понадобится собирать кластер.

В 2.1 появится возможность писать ядра на подмножестве С++17 (и вообще на чем угодно, благодаря компиляции в промежуточный код SPIR-V), если вы про это.

На некоторых платформах можно из ядер вызывать printf. Для всего остального придется сначала отладить их как обычные Си-функции и надеяться, что багов с многопоточностью там не осталось.

Так и с С API никто не мешает функцию написать. Суть в том, что OpenCL сам по себе мало помогает определять зависимости между вычислениями. Низкоуровневый слишком. Это даже хорошо, можно даже пойти еще дальше и сделать что-то типа Vulkan с поддержкой OpenCL C, чтобы не было всяких нубских clCreateBuffer, но если я в курсаче на десяток ядер запутался, то как что-то серьезное на этом писать я не представляю. Я хочу сесть и подумать над либой, которая позволит составить граф вычислений декларативно, чтобы библиотека сама расставляла примитивы синхронизации, создавала промежуточные буферы, но, честно говоря, даже не представляю, с чего начинать.

По-моему, базовый ОпенЦЛ это аналог JDBC в СУБД. Писать программы но можно, но в определенный момент есть риск немножко поехать, так что для начала следует написать себе небольшой фреймворк под задачу. То, что можно писать на один параметр благодаря плюсам это классно, но это не избавит от десятков clSetKernelArg подряд. С другой стороны, если в качестве будущего OpenCL разработки собираются позиционировать этот ад: www.khronos.org/registry/sycl/specs/sycl-1.2.pdf, то это даже не такое и зло.

У мышей просто физически меньше ресурсов на борьбу с болезнью, потому и такая смертность. У человека вероятность выкарабкаться больше.

Связка Intel + GeForce будет быстрее, но потребует купить отдельно процессор Интел и видеокарту NVIDIA и будет стоить в полтора раза дороже.

>которая не поддерживает кучу игровых технологий.

Архитектура GCN с т.з. программируемости (например, нет отдельной константной памяти, отсюда вытекает неограниченное число одновременно забинденных текстур) и по количеству лошадей под капотом наиболее продвинута на текущий момент. Проблемы с производительностью, которые иногда встречаются, исходят из того, что под изначально ущербную программную модель D3D11 сложно написать качественный драйвер.

Ну, как я и писал, пусть работает, пока не станет проблемой. Захотите картинки 20k x 20k — придется этим заниматься. :)

Возможно, NVIDIA этого и не поддерживает, хотя это странно (в этом случае можно задействовать карту Интела, т.к. связка популярная). Но табличка по ссылке показывает, что у AMD скорость чтения видеокартой системной памяти всего в два раз меньше, чем процессором. Разве что для записи всё достаточно грустно. но это вполне может сгладиться, да и никто не заставляет сразу всё отгружать на GPU.
developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/opencl-optimization-guide/#50401315_77912

Можно ВООБЩЕ ничего не отправлять на CPU, потому что текстуру OpenGL тоже можно сгенерировать на месте. Но для этого придется писать всё с нуля. Однако, ничто не мешает переходить на OpenCL постепенно, а той части программы, которая не переписана, просто скармливать указатель clMapBuffer. Это, скорее всего, будет работать быстрее, гарантированно жрать меньше батереи и будет запускаться везде (в комментриях на Кикстартере видел просьбу портировать на Андроид). Насколько это вообще нужно проекту — это другой вопрос.

CL_MEM_USE_HOST_PTR и, вуаля, GPU напрямую общается с RAM через PCI-E на почти полной скорости шины. В случае AMD APU или встроенных видях Haswell и выше, видеокарта и процессор вообще одним проводом с памятью соединены. Но точных цифр у меня нет, спорить не буду.

Вся область разбивается на несколько потоков, которые, мало того выполняются параллельно, так еще используют векторные инструкции SSE/AVX, позволяющие обрабатывать до 8 пикселов одновременно.

Звучит, скорее, как работа для видеокарты, чем для процессора. Раз нормально работает, то пусть работает, но немного кощунственно какой-нибудь GTX или R2 заставлять рисовать единственный прямоугольник.

Современные видеокарты поддерживают аппаратно считывание ужатых текстур.

Мне нужно скачать с вашего сайта один-единственный файлик, после чего я забуду про него как про летний сон. МОЖНО МНЕ УЖЕ ЗАРЕГИСТРИРОВАТЬСЯ, ПОЖАЛУЙСТА?!

Пример с Twitch.tv. Отключаю adBlock, захожу на страницу к человеку, которого не против поддержать. Через пять секунд включается 30-секундная реклама прокладок. Нельзя пропустить как на Ютубе, ну да бог с ней. Ролик кончается, но стрим не идет. В этот момент чат взрывается, и я понимаю, что пропустил какой-то адово эпичный момент, которой, естественно, уже нельзя перемотать. Стрим всё не идет, я обновляю страницу. Через пять секунд включается 30-секундная реклама прокладок… Ну вы поняли. Я понимаю, что мой интернет — дерьмо и это чисто мои проблемы, но это общага, тут другого и нету, поэтому сервис без резалки рекламы тупо неюзабелен.

Я, например, разбирался с OpenGL, неделю медитируя на Красную книгу и теперь, в принципе, знаю, как воссоздать основной конвеер «вертексный шейдер -> создание примитивов -> пиксельный шейдер». Понятно, что сначала придется подсмотреть пару алгоритмов, но сверхъестественных препятствий не вижу.