Из-за двух слов. "Инжинерные образцы".

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

Здравствуй, дерево!
Поучи матчасть, что есть GPGPU. И почему оно отлично используется на дискретках.
А встроенное видеоядро в "APU" - не больше чем встроенное видеоядро.
Вот когда ЦПУ сможет использовать возможности ГПУ напрямую (как сопроцессор) - только тогда это будет APU. А сейчас это встройка. Принципиально от дискретной видеокарты отличающаяся не особо. Так можно и процессор звуковой карты использовать, если исхитриться. И прочего оборудования.
Советую зарубить это себе на носу.

Что-то не особо убегает от 2500k

А вообще не сильно огорчает результат с H.264, так как многие программы используют видеокарты для ускорения работы с ним.

А чем они отличаются?

Привет, "инжИнер"!
Что, не можешь переварить собственный высер?
Сколько не трынди, а в АПУ именно GPGPU и поддерживаются параллельные вычисления. И работает DirectCompute и OpenCL. Так что, высохшая трава в твоей голове.

Если любое вычислительное устройство, после работы, может вернуть данные доступные для дальнейшей обработки, то оно вычислитель. Любой вычислитель можно использовать через библиотеку OpenCL (типа драйвера необходимо).
Сопроцессор программно не используется напрямую, а через библиотеку математических функций. На ассемблере, "страшилы" вроде тебя, не считают, там с ошибками FPU бороться надо. Поэтому одинаково, что есть команды FPU или GPGPU в ядре процессора, что нет - все равно нужна библиотека. Адресное пространство CPU и GPGPU в Trinity будет общим.
Так, что не завидую твоему носу.

Хорошая новость заключается в том, что с тех пор как GPGPU начнут поддерживать Intel(Ivy Bridge), оно реально пойдет в ход...

GPGPU уже используется во многих программах, безо всякого афиширования. Просто, должен стоять драйвер OpenCL и DirectX11(DirectCompute). DirectCompute используется в новых играх (где DirectX11) вместо PhysX ориентированных только на Windows. OpenCL используют мульти-платформенные программы (Win, Linux, Mac ...).

http://ru.wikipedia.org/wiki/GPGPU
определение прочитай.

Та я то знаю что используется, чего один биткоин стоит... Это я к тому, что его начнут применять/воспринимать как обычное явление тогда, когда он сможет работать на любом оборудовании(имеется в виду GPU)...

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

Возможностью исполнения сложного кода а не только графического... Quick Sync - в теперешнем виде представляет собой интегрированный видеокодер/декодер(вроде тех что в ARM-ках аля мобилка), имеющий только ограниченный набор функций связанных с обработкой видео...

И все же GPGPU силmно отличается от сопроцессоров типа x87, 3D Now!, SSE3

Сопроцессором можно эффективно пользоваться, если нужно подсчитать один-единственный синус или длину одного единственного отрезка.
Поэтому программа под сопроцессор - это одна однородная программа, использующая одновременно и целые числа, и дробные для сопроцессора, одновременно работающие над одними и теми же данными..

А для драйверов типа OpenCL / DX Compute нужно готовить пакет из сотен однотипных заданий, сотен синусов или сотен отрезков.
Что-то типа Cell'a. Одни куски программы работают на процессоре, другие на видеокарте и обмениваются большими кусками данных, для каждой части - отдельными, изолированно своими

Разве AMD Video Converter на Llano не работает? Чем не ускорение?

В Llano нет аппаратного ускорителя для кодирования видео. Ускоряется только функция фильтрации (обработки) кадров, но нет анализатора движения.
Нормальный ускоритель кодирования видео AVC будет в Trinity.

Как раз аппаратный ускоритель кодирования видео - это уже не GPGPU(расчеты общего назначения)...так как вычисления производятся не универсальными процессорами, а спецмодулем, который ничего другого и неумеет...
Если так рассуждать то АРМ-ки самые что ни есть умные GPGPU. Там и блок обработки изображений и видеокодировщик с декодером и модемов набор и прочей хрени...только увы - это не GPGPU, а всего лишь сборка разных модулей с фиксированными функциями, пусть зачастую и хорошего качества...

Потому чо в основном нагрузка идет на видеоядро

Я не оспариваю. Это алгоритмический ускоритель (анализ движения) а не число-дробилка.


Если речь идет о встроенной PowerVR, то это полноценный GPGPU.

И не стоит пока обсуждать такие чужие семейства... А может и стоит...

Какие преимущества у AMD APU перед Интелевскими?

1. Графика мощнее
2. GPGPU-считалка (в разы мощнее интеловской, все одно)
3. Цена\баланс

В сегменте APU (не CPU+встройка), а именно APU у AMD нет конкурентов. У Тринити с графикой будет вообще общее адресное пространство, а каике это несет песпективы.. ммм.... Очевидно, что интел опасается этого. Опасается. что родоначальник жанра воплотит свою идею в жизнь. Тогда синим крайне туго придется... Хотя, может и купят нВидиа.

Интересно, что все так к GP прицепились ?
Давайте вообще плавающую точку из процессора уберём, будем её имитировать на целочисленных инструкциях. Будет ещё одним фиксированным модулем меньше.

QuickSync не плохой пример, что если не гордиться идеологической чистотой, то можно и полезно вставлять фиксированные модули.
Наверное настроек у QS меньше, чем у софтового перекодировщика - но никто вроде не жалуется.

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

Вот и будет первый как-бы-Fusion.
А пока это как дискретка или чипсетное видео, разницы нет.


Зачем ?

Если Fusion по прежнему будет опираться на отдельные изолированные вычисления через OpenCL, то Интелу подойдёт любая считалка c OpenCL.
Если Fusion действительно будет слит воедино с x86, то - два варианта.
1) скорее всего - Интел проигнорирует, как проигнорировал 3D Now! и Pacifica. И Fusion останется узконишевой фишкой.
2) если вдруг "выстрелит" - Интел скопирует, как скопировал AMD64 => EM64T, NX => XD, RVI => EPT
При этом nVidia ему ничем не поможет, потому что копировать нужно будет низкоуровневые инструкции, которые у Радеонов и Жирафов разные.

Но скорее всего Fusion реально возможен только как выполнение SSE5-инструкций на GPGPU вместо обычного SSE-блока.
А поскольку SSE5 скорее всего у AMD и Intel будет несовместимым, то опять же Интелу будет наплевать на то, что и как сделает AD.

а где преимущество, на первой и второй картинке для H.264 Quick Sync 2.0 сливает Quick Sync 1.0:
в два раза медленней, и вдвое больше CPU юзает

SSE-5 Это не есть хорошо.
1. Что? Заморозить архитектуру и остановить развитие? Представим развитие в SSE6. Это потребует оставить поддержку SSE5 для совместимости (слегка уменьшив площадь и кол-во универсальных вычислителей) и добавить площадь для SSE6. А дальше SSE8,9... и площадь+площадь? Хватит MMX, SSE1-4, хвосты, которые и отрубить уже просто не получится.
2.SSE5 подразумевает встроенность в ядро на уровне команд, а GPGPU блок-то один на несколько ядер. Нужно ставить блокиратор, чтобы ядро ожидало, пока GPGPU занят другим ядром. Плохо!
3. Программное обеспечение ставится перед широким выбором, что из "зоопарка" использовать. Не всегда будет выбран оптимальный вариант.

Вот OpenCL самое то. Здесь все гибко, универсально и может развиваться без ограничений. Суммирование мощности любых вычислителей, даже разбросанных по всей вселенной.

160 блоков - и это в самом простом из них.

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

для OpenCL APU не нужно. Он действительно может задействовать любые вычислители - но только оптом, крупные блоки данных изолированные от CPU. Всё это уже есть начиная с GF8800/R2600, ничего нового.

Добавлено спустя 5 минут 4 секунды:
Кстати, если считать DirectCompute/OpenCL за правильный образец гибкости - отгда проблема с "совместимостью" и "хвостами" вообще не стоит, отрезать можно что угодно и когда угодно, об остальном позаботятся JVM и CLR