Формально Godavari можно считать просто новым степпингом Kaveri, как это было в ситуации с переходом от Trinity к Richland.
Были изменены частоты CPU/IGP и заменён термоинтерфейс (с пасты на припой). Также немного снижены дефолтные значения напряжения.

Это позволило APU брать более высокие частоты процессорной части при том же или даже меньшем потреблении.
В среднем Godavari имеют на 200-300МГц лучший разгон, чем Kaveri, что может быть плюсом в процессорозависимых задачах.

Рекомендую обычному юзеру взять A8-7650k или A8-7670k и материнскую плату на чипсете A68H.
Их разгон даст производительность сравнимую с топовыми APU (7870k, 7890k) при значительно меньших затратах.

Энтузиастам подойдут A10-7850k/7860k, отличающиеся большим числом потоковых процессоров в IGP и плата на чипсете A88X.

Конкретные модели можете спросить в отдельной теме - Выбор и обсуждение материнских плат под процессоры AMD Socket FM2+ (Trinity, Richland, Kaveri)

Основное ограничение производительности APU в играх приходится на низкую пропускную способность подсистемы памяти.
Именно из-за него недорогие A8 на равных конкурируют с топовыми A10.

#77

Сильно рекомендуется брать две планки памяти с частотами 2133 или 2400 МГц, они дадут почти линейный прирост производительности из-за работы в двухканальном режиме относительно одной планки большей ёмкости.
Частоты выше чем 2400 не поддерживаются процессором и достижимы далеко не на всех связках APU-материнская плата из-за необходимости разгона по шине.

Также рекомендуется по возможности брать dual rank память (в основном это двухсторонние планки), дающую относительно single rank от 5 до 10% прироста производительности в играх:

#77

При покупке и разгоне оперативной памяти следует учесть тот факт, что частота намного сильнее влияет на производительность, чем тайминги.
Связано это с сильной собственной латентностью встроенного контролера.
Память 2400CL11 будет в подавляющем большинстве 3D задач быстрее, чем 2133CL9.

Одна из особенностей данных APU - сброс частот процессорной части при серьёзных нагрузках на видееоядро.
По заявлениям AMD, это было сделано из-за необходимости соблюдения потолка TDP и потребления.

Решением будет использование утилиты amdmsrtweaker или прошивка в материнскую плату модифицированного BIOS, за который спасибо энтузиасту TheStilt

Скачать amdmsrtweaker можно по ссылке - https://drive.google.com/file/d/0B6v9Is ... xECktmBZAA
Инструкция по работе с программой находится в архиве.

Список биосов - https://drive.google.com/drive/folders/ ... sp=sharing
Решение проблем с прошивкой неофициального BIOS в материнские платы ASUS - APU и Athlon линейки AMD «Kaveri» и «Godavari» (Socket FM2+) #13797607

#77

Если кратко - то HSA является технологией, позволяющей полностью использовать доступные ресурсы графической части APU в специально разработанных GPGPU приложениях.
Состоит HSA из двух частей:

Первая из них — hUMA (Heterogeneous Uniform Memory Access). Любое из 12 ядер Kaveri (до 4 процессорных и до 8 gpu compute uniit) имеет равноценный доступ в системную память.
Аппаратная реализация hUMA в Kaveri обеспечивает когерентность кеш-памяти, даёт IGP возможность с виртуальной памятью, а также убирает разделение памяти на системную и видеопамять для GPGPU-задач.

Вторая важная технология, базирующаяся на HSA и делающая Kaveri по-настоящему гетерогенным процессором, это hQ (Heterogeneous Queuing).
В старой традиционной архитектуре вся вычислительная нагрузка проходила через процессорные ядра, в том числе и та, которая предназначена для решения на графическом ядре.
За отправку задач для решения на GPU и контроль их исполнения всё равно отвечал CPU, что вносило дополнительные задержки.
hQ стирает грани между ролями CPU и GPU, уменьшает задержки и упрощает параллельную обработку данных разнородными ядрами.
GPU, как и CPU, получает право создавать и отправлять вычислительные потоки на исполнение.

К сожалению, уже после выхода кристаллов в её спецификацию были внесены изменения, поэтому APU не рекламируются как обладающие "Full HSA Support".
На реальный софт, использующий эти возможности, данный недостаток влияния практически не оказывает (недостаёт GPU Preemption, дающего более плавную работу):

#77

minix ~ # sysbench --num-threads=128 --test=mutex run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 128

Doing mutex performance test
Threads started!
Done.


Test execution summary:
total time: 2.6142s
total number of events: 128
total time taken by event execution: 330.1158
per-request statistics:
min: 2305.10ms
avg: 2579.03ms
max: 2607.78ms
approx. 95 percentile: 2602.22ms

Threads fairness:
events (avg/stddev): 1.0000/0.00
execution time (avg/stddev): 2.5790/0.03

minix ~ # sysbench --num-threads=64 --test=threads --thread-yields=10000 --thread-locks=8 run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 64

Doing thread subsystem performance test
Thread yields per test: 10000 Locks used: 8
Threads started!
Done.


Test execution summary:
total time: 71.6051s
total number of events: 10000
total time taken by event execution: 4572.9476
per-request statistics:
min: 84.54ms
avg: 457.29ms
max: 832.98ms
approx. 95 percentile: 588.87ms

Threads fairness:
events (avg/stddev): 156.2500/2.68
execution time (avg/stddev): 71.4523/0.10

minix ~ # sysbench --num-threads=32 --test=cpu --cpu-max-prime=200000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 32

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 200000


Test execution summary:
total time: 2337.1445s
total number of events: 10000
total time taken by event execution: 74734.4219
per-request statistics:
min: 3193.00ms
avg: 7473.44ms
max: 8830.37ms
approx. 95 percentile: 7688.10ms

Threads fairness:
events (avg/stddev): 312.5000/4.92
execution time (avg/stddev): 2335.4507/1.22