LINUX.ORG.RU
Форум — Talks  

[amd] открытые драйверы для Fusion APU опубликованы

 


0

1

Ядро:

[PATCH 14/20] drm/radeon/kms: add Ontario APU ucode loading support
[PATCH 20/20] drm/radeon/kms: add Ontario Fusion APU pci ids
[PATCH 19/20] drm/radeon/kms: enable MSIs on fusion APUs
[PATCH 18/20] drm/radeon/kms: add power table parsing support for Ontario fusion APUs
[PATCH 17/20] drm/radeon/kms: refactor atombios power state fetching
[PATCH 16/20] drm/radeon/kms: add bo blit support for Ontario fusion APUs
[PATCH 15/20] drm/radeon/kms: add thermal sensor support for fusion APUs
[PATCH 12/20] drm/radeon/kms: fill in GPU init for AMD Ontario Fusion APUs 
[PATCH 13/20] drm/radeon/kms: add radeon_asic struct for AMD Ontario fusion APUs
[PATCH 11/20] drm/radeon/kms: evergreen.c updates for fusion
[PATCH 10/20] drm/radeon/kms: MC setup changes for fusion APUs
[PATCH 09/20] drm/radeon/kms: move r7xx/evergreen to its own vram_gtt setup function 
[PATCH 08/20] drm/radeon/kms: add support for ss overrides on Fusion APUs
[PATCH 07/20] drm/radeon/kms: Add support for external encoders on fusion APUs
[PATCH 06/20] drm/radeon/kms: atom changes for DCE4.1 devices
[PATCH 05/20] drm/radeon/kms: add new family id for AMD Ontario APUs
[PATCH 04/20] drm/radeon/kms: upstream power table updates
[PATCH 03/20] drm/radeon/kms: upstream atombios.h updates 
[PATCH 02/20] drm/radeon/kms: upstream ObjectID.h updates
[PATCH 01/20] drm/radeon/kms: setup mc chremap properly on r7xx/evergreen
Mesa:
r600g: add support for ontario APUs -0/+36
r600c: add Ontario Fusion APU support -1/+24
xf86-video-ati:
Add EXA/Xv acceleration support for Ontario Fusion APUs    -3/+25
Add Ontario fusion APU pci ids    -0/+24
ontario: add UMS modesetting support    -20/+49

★★★★★

Последнее исправление: madgnu (всего исправлений: 1)
← digiKam && kipi-plugins 1.6.0
[.рф]Крупнейшему регистратору в зоне .рф выдвинули ультиматум →

Щас прибегут блобоносцы.

Pavval ★★★★★
()

Слався AMD.
Собственно новость отличная, железок бы теперь подождать.

Novell-ch ★★★★★
()
Ответ на: комментарий от linuxfan

Я бы не стал обзывать какую-нибудь широко доступную DDR3-1600 жутко тормозной.

У меня в хозяйстве ещё машинки с PC-100 неплохо бегают.

Deleted
()
Ответ на: комментарий от madgnu

>hint: с какой памятью работают интегрированные в чипсет ядра?

hint: что мы можем сказать о производительности таких интегрированных решений?

linuxfan ★
()
Ответ на: комментарий от linuxfan

>hint: что мы можем сказать о производительности таких интегрированных решений?
hint: что мы можем сказать о цене и прожорловости дискретных решений?

Novell-ch ★★★★★
()
Ответ на: комментарий от linuxfan

А ты хотел, чтобы тебе в один кристалл с процессорными и графическими ядрами еще и гиг-другой gddr5 засунули?

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

madgnu ★★★★★
() автор топика
Ответ на: комментарий от Novell-ch

>hint: что мы можем сказать о цене и прожорловости дискретных решений?

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

linuxfan ★
()
Ответ на: комментарий от linuxfan

>> Звучит бредово и бесполезно. Неужели шустрое графическое ядро будет работать с жутко тормозной DDR памятью?

DDR-3 не такая уж и тормозная. Плюс графическое ядро наряду с CPU имеет доступ к кешу 3-го уровня. Хотя это скорее для GPGPU, текстур то туда особо не напихаешь.

vovchik542
()
Ответ на: комментарий от linuxfan

Тут будет 80 потоковых процессоров + блок аппаратного ускорения видео почти всех форматов (сомневаюсь что будет доступно в Linux'е). Вполне себе коппечный дискретный радеон, но внутри процессора (со всеми вытекающими профитами)

vovchik542
()
Ответ на: комментарий от linuxfan

Кривые руки?! Что-то я не замечал у отца на нетбуке тормозов в запущенном под вайном ГАРАНТЕ, в фоксе и опенофисе.

daemonpnz ★★★★★
()
Ответ на: комментарий от vovchik542

блок аппаратного ускорения видео почти всех форматов (сомневаюсь что будет доступно в Linux'е)

UVD прекрасно сейчас работает в линухе через VAAPI и блоб.

daemonpnz ★★★★★
()
Ответ на: комментарий от daemonpnz

ну в блобе то понятно, тут же про открытый драйвер. и где-то на форуме проскакивало что спецификации на UVD открыты не будут.

vovchik542
()
Ответ на: комментарий от vovchik542

Сейчас идет реализация ускорения через 3D. А там может и на UVD спецификации откроют.

daemonpnz ★★★★★
()

Кстати, про ускорение видео, что там про XvMC трекер в галлиуме для r600? Кады его в основную ветку запилют?

daemonpnz ★★★★★
()
Ответ на: комментарий от yoghurt

Как видишь.

2vovchik542:

от Christian König <deathsimple@vodafone.de>

кому mesa-dev@lists.freedesktop.org

Hi everybody,

just wanted to note that I got the first implementation of the XvMC iDCT code working. The luma/chroma scaling and clamping still need some work, but beside from that the pure matrix multiplication seems to work fine.

At the moment it uses a quite inefficient two stage approach and on large resolutions mplayer is complaining that my system is to slow to play this (with only around 8% CPU in use). So the bottleneck is no longer the CPU and starts to be the GPU calculation.

While working on the iDCT code I found a couple of bugs in the command checker, and also implemented support for signed normalized colour buffers in r600g, but I think I will spam the different mailing list with separate patches about this.

Regards, Christian.

madgnu ★★★★★
() автор топика
Ответ на: комментарий от vovchik542

Просто не нужно говорить

сомневаюсь что будет доступно в Linux'е

. Так как это 4.2, ведь в линухе на блобе работает. ;)

daemonpnz ★★★★★
()
Ответ на: комментарий от madgnu

Знаю, только они у AMD многопоточные, а у не нвидии нет.

KPSS
()

Теперь у нас есть собственный Cell с соответсвующими атрибутами?

atrus ★★★★★
()

С возращением!

Новость радует.

Behem0th ★★★★★
()
Ответ на: комментарий от KPSS

Radeon HD 2400 Pro тоже имеет 80, причём архитектурно более старых и работающих на меньшей частоте, это дискретный Low-End. Для композитинга, обычных игр (ниша для которой предназначены эти APU предполагает низкие разрешения) и GPGPU хватит с лихвой. Тем более если добавление GPU на кристалл не удорожит APU по ставнению с вариантом без GPU.

vovchik542
()
Ответ на: комментарий от daemonpnz

согласен
«сомневаюсь что будет доступно в Linux'е в открытых драйверах»
fixed ;)

vovchik542
()
Ответ на: комментарий от vovchik542

Именно. Жаль, конечно, что не через UVD, но это лучше чем ничего.

madgnu ★★★★★
() автор топика
Ответ на: комментарий от KPSS

тем более. а если учытывать что они скорее всего побреют у ШТЕУДа динамический разгон видеоядра под нагрузкой - так вообще прекрасно. осталось дождаться этого всего в железе.

vovchik542
()

Интересно получается. AMD открывает свои новинки, а нвидия - закрывает (даже блобов не даёт). Ждут нвидию муки и смерть с таким подходом к клиентам.

Quasar ★★★★★
()
Ответ на: комментарий от linuxfan

linuxfan> hint: что мы можем сказать о производительности таких интегрированных решений?

За счёт того, что оно будет соединено напрямую, а не через специальную шину, производительность должна возрасти.

Quasar ★★★★★
()
Ответ на: комментарий от linuxfan

linuxfan> Дальше не читал. На этих убогих куркуляторах только ms-dos 5.0 не тормозит.

KDE4 у меня там не тормозит. Что я делаю не так?

Quasar ★★★★★
()
Ответ на: комментарий от Quasar

таким подходом к клиентам.

Главные клиенты под линукс у нвидии - графические студии и всякие компании, которым требуется числодробилки.

Kosyak ★★★★
()
Ответ на: комментарий от Quasar

>KDE4 у меня там не тормозит. Что я делаю не так?

Ты привык к тормозам.

linuxfan ★
()
Ответ на: комментарий от daemonpnz

UVD прекрасно сейчас работает в линухе через VAAPI и блоб.
Правда поддерживается VA-API очень малое число видеокарт AMD, к сожалению. Моя 5850 не поддерживается, например.

RussianNeuroMancer ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← digiKam && kipi-plugins 1.6.0
Talks
[.рф]Крупнейшему регистратору в зоне .рф выдвинули ультиматум →