OpenCL работает поверх CUDA... Даже если это и изменилось, то пилить SDK не будут, ибо есть CUDA.

Иди учи что такое стандарт. Компилятор может быть какой угодно - все компилится из одного кода.

Добавлено спустя 2 минуты 30 секунд:


Спасибо поржал. В рамках одного поколения GPU код одинаковый, а вот под какое-нибудь старье тебе придется код переписывать, равно как и под новую архитектуру (Maxwell).

Есть стандарт. Конкретные реализации - проблемы реализаторов.



Это как писать, что мир разделился на CPU и GPU.
Есть код на opencl. Он - один. Просто один. Есть компилятор, оптимизатор и прочее в одном флаконе. И есть железка.
Юзера вообще не волнует, что делается под капотом. Если рантайм работает хреново, то это его личные проблемы.



Стояяяять. GPU и есть SIMD-юнит, ты чего?

так почему светлое будущее все никак не наступает .. раз везде мир дружба упячка
почему тот же биткойн . лучше работает на [автоцензор3.14] .а не на NV ? раз CL такой портабельный.?



раз все так глючно что же сподвигло лабораторию в оак ридж использовать Nvidia CUDA и TESLA и не пачки fire pro ? или они любят погорячее ?


так цель снять нагрузку с цпу ВОВСЕ .или минимизировать ..
1. контроллер памяти тоже имеет % загрузки.
2. ну ето пожалуй единственный плюс костыля HSA. что не нада копировать между разными устройствами хранения . только слабо применимый в условиях кластера и дискреток . что и является проблемой


в однопотоке ? phi ? u mad bro ? архитектура ета была создана в рассчете на паралелизм . и кластеризацию . какой в дупло однопоток ? ты еще с Xeon E5 сравни . как у этих малышей будет с однопотоком

95%, что уже имеют какой-то код и переписывать не хотят.



Потому что гладиолус, портабельность не имеет ничего общего со скоростью.
Почему программа работает быстрее на 4770k, чем на FX8350?

Биткоин имеет алгоритмы, которые хорошо ложатся на архитектуру AMD.
Были бы другие - фиг знает, может бы nvidia раскупали для майнинга.

На CUDA легче писать + жирафы в DP побыстрее будут. AMD догнала kepler лишь в hawaii.

Зачем это делать, если программа одна и изначально запускается в ОС, которая крутится на CPU?

Конечно имеет

Какого костыля? Костыль был до этого, когда ты данные из одного места системной памяти копировал в другое место, тупо по причине того, что чисто физически GPU не имел доступа ко всей системной памяти.

Есть программа, которая использует одновременно и CPU, и GPU. Phi в таком случае будет посасывать, гоняя данные через PCI-E шину и контроллер памяти центрального CPU. Нужно например перелопатить блок данных в 20Gb (куча таблиц и матриц с данными). Что ты там со своим Phi делать будешь - в память то все не поместится, а еще же нужно промежуточные расчеты где-то хранить. В таком случае Phi будет посасывать. В то время как APU с HSA будет чувствовать себя довольно комфортно.

А речь о кластере и не шло. Таких систем (на APU c HSA) в природе пока еще не существует.

не путай SIMD ( INTEL ) - SIMT - и SMT
разные вещи .также как и разные по принципам паралелизации последние 2 как раз про гпу .



да тока результат получается разный . в силу учитывания или не учитывания целевой платформы .или напомнить как интелевский с++ компилятор обожает процессоры AMD ?



не совсем . одно дело сделать изменения внутри обработчика Cuda . другое дело капитально перепиливать и структуру тоже . изменения того же максвела не несут ультимативный характер . программа может. а может и не использовать unified memory .



таки согласись что стандарт не сильно помог унификации 3х разных вариаций одного и того же якобы


все в нашем мире относительно
998.4 ( fire pro 9000 ) VS 1430 ( к40 )



веселый документ за авторством интеля где сравнивались возможности GT200 и Core I7 . вкратце они пытались обяснить что далеко не каждая задача . пульнутая в гпу и еффективней будет быстрее аналогичной задачи на голом цпу.также затрагивается вариант что возможно и наоборот когда CPU будет быстрее GPU . желающим приобщиться .. пожалуйста http://pcl.intel-research.net/publicati ... 19-lee.pdf

вводится лиш понятие место выполнения ( облако ) . где сливаются возможности различных сред выполнения кода в единое пространство . когда программа может занять какой либо адаптер и не будет чинить препятствий соседнему адаптеру. не кушая на постоянные обращения к общесистемному цпу его время не занимая почем зря шину . и не занимая лишнюю общестстемную память . вести коммуникацию между ускорителями напрямую и в в обход хостовых CPU .. целый новый мир . облачных серверов . и эру начали......................без AMD )

Добавлено спустя 12 минут 58 секунд:


вы слишком одномерно мыслите . для систем в которых используется та же тесла это не актульно фиг знает сколько времени . и называется сие Numa .а также в рамках инициативы унифицированной памяти . когда ос . запуская задачу может использовать память из разных пулов . без лишнего оверхеда ( накладных расходов ) . что и предполагает инициатива Intel и которую подхватили NV

Phi не видеокарта, а непонятно что. У Nvidia пока только на бумаге и непонятно что в итоге получится.

Если программа узкоспециализированная и полностью параллелится, то зачем ей CPU? - залил данные в видеопамять, обработал и выгрузил в оперативку результат. Есть программы, которые требуют работы тандема CPU+GPU и никакие дополнительные ARM ядра на видяхе это не исправят.

А как по твоему подгружаются данные в видеопамять? Или Intel научилась передавать данные по воздуху, минуя контроллер памяти CPU?


Что по воздуху данные получает? Для того, чтобы не было оверхеда ты обязан иметь прямой (физически) доступ к памяти. А иначе ты будешь дергать КП другого процессора. В случае GPU-CPU это невозможно.

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

Вы бы имели представление, о чём пишите.
Ускорять декодирование в реальном времени? Так это невероятно полезно - можно смотреть фильмы на бешеных скоростях. Стоп! Так ведь это же не нужно, для просмотра нужно декодирование в реальном времени, или я ошибаюсь? А при транскодировании технология оказывается столь же бессмысленной как и QuikSync, поскольку GPGPU всё равно выполняет эти задачи несоизмеримо быстрее даже на картах среднего уровня. Единственное применение обеих технологий - ноутбуки без дискретного видео, там они помогут пережать ролик со значительно меньшими затратами энергии. Хотя, в случае с nVidia это тоже не факт, поскольку при использовании GPGPU энергии, вероятно, затрачено будет меньше.



Что, ТЕПЛА??? Беру все свои слова обратно, поскольку не могу спорить с теми, кто определяет количество выделяемого тепла по шине питания ГОЛОГО процессора. Просто сдаюсь.



Я уже устал кидать ссылки, поищите сами любой интерлейсный VC-1 1080i. Или, например, AVC Level@5.1. MVC тоже очень нравится всем i5 до Хасвеллов. При том, что декларируется аппаратная поддержка формата - процессор греется нарядно.
Я не говорю, что с каким-то из этих форматов i5 не справится - нормальный i5 вытянет любой из них, пусть и с редкими подтормаживаниями в отдельных случаях. Речь о том, что UVD3.0 любой из этих форматов декодирует аппаратно, находясь в минимальном положении QnQ, а i5 будет греться в отдельных случаях во весь свой TDP. Про качество картинки говорить не буду - оно без енхансеров заметно не отличается, а вот енхансеров на Intel во многих влучаях Вам не положено, поскольку то недоступна постобработка, то не задействуются шейдеры, то нет полноценной поддержки OpenCL.

Кстати, сабж теперь много где в Москве продается.
A10-7850k в коробке идет вместе с BF4, кто знает? Стоит от ~7k.

технически Phi - массив упрощенных х86 ядер . со своей память и под управлением прошивки на основе Linux осуществляющей управление целевым девайсом . Phi изначально предполагал испоельзование унифицированной памяти . когда софт имеет возможность адресовать в едином пространстве и системную и память ускорителя . согласно модели DSM ( Distributed shared memory ) . Nvidia в максвеле будет предлагать полностью схожий фукнционал


во первых далеко не все задачи паралелятся . да и дабы не повторятся рекомендую зачитать http://pcl.intel-research.net/publicati ... 19-lee.pdf . вопросы такого рода отпадут сами собой .. и мб откроются глаза
ARM ядра нужны лиш для запуска Cuda приложения Вне системного CPU . и снятия нагрузки как с цпу так и с шин . Phi по тем же принципам работает . хост программа там крутится на одном из ядер . которая и занимается управлением как ускорителем так и менеджментом ресурсов . так и коммуникацями с другими ускорителями или нодами кластера .




AS IS она не адресуется в едином пространстве . для етого и нужны переделки под DSM и DM архитектуры . да и обращение вида GPU -> UNCORE -> RAM всяко быстрее чем GPU -> CPU -> UNCORE - > ram . а уж если физических процессоров 2 . и памяти не 1 нод а несколько то придется еще искать какой нод и какой процессор держит искомый фрагмент

и опять же узко мыслиш ) для разрешения коллизий и чтобы лишний раз не дергать системную память на поле появляется еще один игрок - OS которая должна поддерживать модели Numa-DSM и DM. что нынешние ос и научились делать


ну прежде чем лезть в тему о таких вещах .вам бы следовало узнать по аспекты этих вещей http://ru.wikipedia.org/wiki/PureVideo который в MPC называется Cuvid





господа. я в шоке . КОГДА И КТО ОТМЕНИЛ ПЕРВЫЙ ЗАКОН ТЕРМОДИНАМИКИ !?? который применительно к процессорам говорит нам что количество использованного електричества в интегральных схемах расходуется на переключение транзиторов . которое и выделяется ВВИДЕ ТЕПЛА. которое и составляет TDP . ну это же елементарно ватсон . уроки физики . средняя школа .
или ради амд законы физики уже отменили ?


ну а смысл был воздух сотрясать . вот я . да я вам покажу . дам ссылку . и интель будет на задворках истории . такая пафосная бравада . и вся осталась лиш бравадой

Нет, в MPC он называется DXVA. А Cuvid - это аналог HAM под AMD от Cyberlink, когда конвейер VP4+ используется напрямую без DirectDraw или MF. В MPC использование метода возможно только с использованием стороннего LAV, насколько мне известно.
Cuvid имеет свой набор достоинств и недостатков, но ничего нового инструмент не предлагает. Разве что в теории на Кеплерах можно ускорять транскодирование видео, но на практике софта для этого я пока так и не увидел, да и я уже объяснял, что это не нужно, поскольку любой Кеплер сделает это значительно быстрее с помощью GPGPU.



Я Вам говорю о том, что APU, декодируя в программном режиме, выделяет в районе 10Вт тепла, Вы же мне: какие 10! Он 40 потребляет!
Вероятно, выделять он будет тоже 40 по Вашей логике. И, хотя при декодировании нагружен только UVD, а ядра и GPU функционируют в режиме минимальных частот и напряжения с загрузкой 3-5% т.е фактически состояние покоя, но ещё не CX.



Вы не в состоянии сами найти видео по указанным параметрам?
Так я Вам помогу.
Например.
Или вот.
Дурное дело - нехитрое.

Да откуда ОС знает что там высокоуровневая CUDA будет творить? Вся логика софтовая.

Если в случае с Intel это одна компания (ускоритель-материнка-процессор) и есть возможность сделать это на аппаратном уровне, то

тут ничего подобного не будет.

Тем хуже для Phi и других ускорителей, которые в силу аппаратных ограничений вынуждены гонять данные через КП центрального процессора.

Виртуальная память с софтовой логикой сильно медленнее физически единого пула памяти. Особенно когда в программе активно используется CPU+GPU и часто дергается память.

Почитал.
1. Код для gt280 в большинстве случаев быстрее кода для i7-920. Исключения - случаи с активными ветвлениями.
2. Тесты 2010 года. Напомнить тебе, в каком зачаточном состоянии было gpgpu тогда?
3. На кой-то фиг для тестов взяли nvidia, когда в это время уже Radeon 5xxx были.
4. Могу напомнить, что в тот момент вышли драйвера nvidia с поддержкой OpenCL 1.1, но которые были процентов на 30-40 старых.



Профильный при проигрывании видео по первой ссылке таки жрал 40 ватт. Из розетки.
Процессор висел большую часто времени в простое, видео тоже.

Он опять наврал
http://market.yandex.ru/model.xml?hid=9 ... 1&clid=502

CUVID - https://developer.nvidia.com/nvidia-video-codec-sdk .это полностью ОТДЕЛЬНЫЙ продукт не на базе DXVA . Nvidiaевский декодер досутпен в 2 вариациях .
1.DXVA команд . неполный функционал . согласно стандарту и ничего более
2.как CUVID отдельная проприетарная библиотека . с гораздо большим колвом поддерживаемых стандартов . является частью LAV это так .



Core I5 3339Y с TDP 10W передает привет . что он совершенно НЕ ВПЕЧАТЛЕН
Лига Чемпионов 2013-2014 / Группа F / 4-й тур / Боруссия Д (Дортмунд, Германия) - Арсенал (Лондон, Англия) по одной из ссылок . по второй . было качать

и так собственно привет от 10ти ватного процессора

он даже частоту не поднимал


модерновые оси . уже имеют поддержку гибридных моделей распределению . достаточно лиш сделать Pass Through ( возможность прямой внешней адресации набортной памяти ) чтобы хостовая система могла исползовать собственный механизм адресации на новом адаптере и обявить етот адаптер нодом той же DSM или SM модели и все. все остальное уже в новых осях есть . что избавит програмистов от вызова драйверов. и упростит итоговое програмирование. а уж програмисты под кластера и вовсе памятник поставят за возможность кросс нодовой адресации


там нет ничего аппаратного PHI работает под своей прошивкой . которая получает команды от драйвера хоста. никаких черных приемов . или недокументированных возможностей


абсолютно таже модель . только не на базе X86 а на базе ARM процессора . можно хоть мипс влепить . гпу будет работать аналогично . под своей прошивкой ( внутри UEFI GPU модулей ) . которая будет получать директивы хоста. темболее никто не говорит о прямом програмировании денвера . отвечать он будет лиш на код и директивы CUDA от самого драйвера . то есть никто кодить под арм заставлять не будет


полностью аппаратно единый пул с гпу . хороший выход из положения . строго до момента пока процессор один . при 2 и более физ процессоров . речь начинает идти о тех же проблемах что и без апаратно общего контроллера.
но проблема в том что разница невелика PCIEX генерирует сам посебе очень маленькую латентность на DMA доступ . который дополнительно снижают ускорителями . навроде Nvidia GPU DIRECT (RDMA ) https://developer.nvidia.com/gpudirect . PHI предлагает похожее . только грязноватым аппаратным трюком


старая песня .вот мы вам покажем .. СКОРО ..

только ли на это? а как же токи утечки? а как же утечки вольтажа?

вот ты мне скажи, у одного процессора максимальная температура 100 градусов, у другого 50, оба потребляют 100w у них будет одинаков тпд или все же разный?

Неправда. И DXVA и Cuvid работают с помощью блока VPx. Ничего отдельного там нет, просто программная фишка на манер существующей давно HAM. Да, в Cuvid ещё могут задействоваться шейдеры, так Cyberlink так же делал всё это ещё в 2008-м.



Правда? Какие же, например, он поддерживает стандарты из неподдерживаемых DXVA?
Ну, кроме возможности использования рендеров, отличных от EVR.



Лукавите. Ссылка ошибочно дана на 720p, но даже это видео загружает 2500K на 40-60% при полноэкранном воспроизведении.
1080p с этими же параметрами забьёт на 100%.
И да, теперь Вы предпочитаете забыть о термодинамике и предпочитаете ватты мерить по TDP.
Сколько, однако, двойных стандартов.



О, думаю, Вы качали. Просто не хотите делиться результатом.

Я уже натыкался на cuda->opencl транслятор с использованием llvm.
И знаешь, скорость opencl кода была на уровне или даже выше оригинального на cuda.

Он единственный адекватный человек в теме среди вас, тупых фанатиков.