Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Статья, к сожалению, вызывает недоумение, и даже обещание второй части не…
Ну я думаю вы поняли мысль, как это выглядит. Мысль буквально обрывается на середине.
Ну я думаю вы поняли мысль, как это выглядит. Мысль буквально обрывается на середине.
Смутная надежда, — что автор просто вместо «предпросмотр» случайно нажал самую большую «опубликовать» — остается.
Очень хотелось поделиться. Признаю, мысль выглядит оборваной.
У меня уже есть большая часть текста, но нужно провести много тестов. Вот в Cycles нету поддержки физического неба, поэтому сделанные мной тесты «под открытым солнцем» не подходят.
У меня уже есть большая часть текста, но нужно провести много тестов. Вот в Cycles нету поддержки физического неба, поэтому сделанные мной тесты «под открытым солнцем» не подходят.
Я бы посоветовал писать статью в том стиле, будто бы вам в журнал писать. То есть статья отдельно должна быть цельной, если есть необходимость разделать по частям, то каждая часть — наскольо это возможно — самостоятельная. Вот сейчас есть отличная статья про xneur habrahabr.ru/blogs/linux/132851/, и она по частям, что логично.
И я честно говоря не понял к чему там картинка приведена? Она как то с текстом не особо вяжется, никак не выделена.
Я думаю стоит пока убрать, дописать до какого то логического завершения и дать паре людей вычитать. Тогда будет всё ок. Если что, я готов помочь и посоветовать.
Я думаю стоит пока убрать, дописать до какого то логического завершения и дать паре людей вычитать. Тогда будет всё ок. Если что, я готов помочь и посоветовать.
Концовка статьи немного озадачила:
Здесь упомянуты 4 производителя, что наталкивает вас на вывод, что «пишут все, кому не лень»
Здесь же, наоборот, 3 производителя приводят вас к выводу, что «никто всерьез не принимает».
Поясните, пожалуйста этот момент.
CUDA – пишут все, кому не лень (iRay, Octane Render, Arion Render, Cycles, etc).
Здесь упомянуты 4 производителя, что наталкивает вас на вывод, что «пишут все, кому не лень»
OpenCL – SmallLuxGPU, Cycles, Indigo Render. Похоже, никто всерьез не принимает.
Здесь же, наоборот, 3 производителя приводят вас к выводу, что «никто всерьез не принимает».
Поясните, пожалуйста этот момент.
Попробую так:
OpenCL продвигается Intel & AMD
CUDA только компанией nVidia
Карты от nV поддерживают OpenCL & CUDA
Карты от AMD (Intel пропускаю ибо не имел возможности потрогать GPU в Sandy Bridge) поддерживают OpenCL.
А теперь фокус:
Шейдерные процессоры в картах nV отлично работают в float, но никакие с integer.
Stream процессоры от AMD наоборот — для bitcoin mining хорошо, а вот работа с float послабее.
А т.к для нашей задачи нужны операции с float сильнее то и выбирают язык той конторы, чьи карты шустрее в задачах.
OpenCL продвигается Intel & AMD
CUDA только компанией nVidia
Карты от nV поддерживают OpenCL & CUDA
Карты от AMD (Intel пропускаю ибо не имел возможности потрогать GPU в Sandy Bridge) поддерживают OpenCL.
А теперь фокус:
Шейдерные процессоры в картах nV отлично работают в float, но никакие с integer.
Stream процессоры от AMD наоборот — для bitcoin mining хорошо, а вот работа с float послабее.
А т.к для нашей задачи нужны операции с float сильнее то и выбирают язык той конторы, чьи карты шустрее в задачах.
Но ведь OpenCL в nVidia реализован поверх CUDA, т.е. практически нет разницы, на чем писать (проигрыш в производительности около 10%, что не критично), всё равно под капотом это будут вызовы CUDA.
А теперь такой момент: теоретически вы можете переносить код на OpenCL на любые устройства, его поддерживающие (т.к. компиляция kernel в нативный код устройства происходит в рантайме), т.е. если вы пишете рендер на OpenCL, то вы не ограничены каким либо железом (не знаю, как оно на практике).
Вопрос к знатокам: раз OpenCL — это спецификация, и большинство производителей имеют реализацию этой спецификации, то возможно ли часть работы (в данном случае рендеринга, но это не принципиально) отдавать другим устройствам? Т.е. параллелить работу не только между ядрами GPU, но и между CPU и GPU? Иначе говоря, можно ли в рантайме подсовывать разные реализации OpenCL, на которых будут исполняться kernel'ы?
А теперь такой момент: теоретически вы можете переносить код на OpenCL на любые устройства, его поддерживающие (т.к. компиляция kernel в нативный код устройства происходит в рантайме), т.е. если вы пишете рендер на OpenCL, то вы не ограничены каким либо железом (не знаю, как оно на практике).
Вопрос к знатокам: раз OpenCL — это спецификация, и большинство производителей имеют реализацию этой спецификации, то возможно ли часть работы (в данном случае рендеринга, но это не принципиально) отдавать другим устройствам? Т.е. параллелить работу не только между ядрами GPU, но и между CPU и GPU? Иначе говоря, можно ли в рантайме подсовывать разные реализации OpenCL, на которых будут исполняться kernel'ы?
На OpenCL не спешат писать из-за сложности этого языка. CUDA намного проще и понятнее. Да и код получается значительно короче.
В общем, если сравнивать CUDA и OpenCL, то OpenCL — это как реализация многопоточных вычислений с использованием pthreads, а CUDA — с использованием openmp (аналогия, признаюсь, хреновая, но, надеюсь, смысл переносит).
В общем, если сравнивать CUDA и OpenCL, то OpenCL — это как реализация многопоточных вычислений с использованием pthreads, а CUDA — с использованием openmp (аналогия, признаюсь, хреновая, но, надеюсь, смысл переносит).
Да, возможно — тот же самый Cycles от Blender так делает. Только сыровато всё еще.
>OpenCL продвигается Intel & AMD
OpenCL продвигается Intel, AMD, NVIDIA. Только фокус последняя делает больше на CUDA, чем на OpenCL. И это именно продвигает, а не поддерживает, т.к. у них довольно быстро появляется поддержка последних стандартов.
OpenCL продвигается Intel, AMD, NVIDIA. Только фокус последняя делает больше на CUDA, чем на OpenCL. И это именно продвигает, а не поддерживает, т.к. у них довольно быстро появляется поддержка последних стандартов.
SmallLuxGPU, Cycles — опен сорс, находятся на ранней стадии разработки, и множества нужных функций в них нет. Например в Cycles нету физического неба, свойственного практически всем анбиасам.
Indigo — коммерческий рендер, однако от его «GPU-ускорения» ни тепло, ни холодно. Прирост скорости очень малозначительный.
К тому же существует множество CUDA рендеров от любителей, например «шутер от первого лица» в реальном времени.
Nvidia продвигает свою технологию CUDA. А OpenCL либо не оптимизирован до конца, либо умышленно урезается в производительности.
Основное направление деятельности ATI — игры. И при большем количестве шейдерных ядер по сравнению с карточками Nvidia (в той же ценовой категории) абсолютно не использует возможность занять рынок вычислений, не связанных с шейдерами для OpenGL или DirectX.
Indigo — коммерческий рендер, однако от его «GPU-ускорения» ни тепло, ни холодно. Прирост скорости очень малозначительный.
К тому же существует множество CUDA рендеров от любителей, например «шутер от первого лица» в реальном времени.
Nvidia продвигает свою технологию CUDA. А OpenCL либо не оптимизирован до конца, либо умышленно урезается в производительности.
Основное направление деятельности ATI — игры. И при большем количестве шейдерных ядер по сравнению с карточками Nvidia (в той же ценовой категории) абсолютно не использует возможность занять рынок вычислений, не связанных с шейдерами для OpenGL или DirectX.
Мда, кармы маловато, ничего больше опубликовать не могу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Трассировка пути на GPU, часть 1