slacky.eu

Allora ragazzi sono arrivato al punto che....Mi sono contraddetto da solo....Vi spiego subito.
Disinstallati i driver proprietari e sto usando quelli open per il semplice fatto che ho risolto il problema con i codec flashplayer.
Il problema ( se potesse servire a qualcuno con la mia stessa scheda video o analoga ) del rallentamento dei filmati web l'ho risolto disabilitando "Enable Hardware Acceleration" facendo click con il tasto destro sul filmato flash e cliccando su "Settings". Sulla voce display c'è una checkbox attivata "Enable Hardware Acceleration",disattivandola ho risolto tutti i miei problemi.
Ora il sunto è che con driver open (radeon_hd) le finestre web che contengono animazioni in flash si aprono molto più rapidamente di prima!
Alla fine ho optato per i driver open

Ciao a tutti ragazzi,
ho anch'io un'ati radeon hd 4200 (integrata in una asus m4a785td-m, chipset amd 785G), ma se uso i driver open è come se avessi l'accelerazione 2D disabilitata la cosa si manifesta soprattutto nello scrolling con firefox, ma si avverte anche in generale con l'uso del sistema. Con i drive proprietari invece va tutto a meraviglia.
Ho descritto nel dettaglio il mio problema in questo thread viewtopic.php?f=51&t=33692 , qualcuno ha qualche dritta?
Grazie mille!!!

Su un computer con Athlon 64, chipset AMD, AGP Radeon 9250, e monitor 1024x768 ho un'impostazione copiata da quella di spina. Senza tali impostazioni, con tale computer non c'è modo di usare nemmeno framebuffer vesa, per cui in runlevel 1/3 dovrei accontentarmi di risoluzione vga.

Su un altro con Athlon XP, chipset VIA, AGP Radeon 3650 HD, e monitor 1280x1024 ho dovuto aggiungere un firmware proprietario AMD/ATI. Dopo aver compilato con le impostazioni di cui sopra (o con solo una parte di esse: avevo fatto diverse compilazioni procedendo con poche modifiche alla volta nel config), il boot si piantava con un messaggio che terminava così:
using builtin firmware radeon/RV635_pfp.bin
using builtin firmware radeon/RV635_me.bin
requesting radeon/R600_rlc.bin

R600_rlc.bin è proprietario e non c'è nei sorgenti del kernel; va scaricato a parte, per esempio dal sito di x.org, ed è soggetto a una licenza specifica (se inserito nel kernel, come pure avverte l'help del config, ne modifica la licenza). Il firmware da integrare dipenderà dal modello di scheda video.

Partendo dal config generic smp "vergine":
Device Drivers > Graphic Support > YES a /dev/agpgart...
Device Drivers > Graphic Support > /dev/agpgart... > NO a tutto, eccetto YES a VIA (il produttore del northbridge)
Device Drivers > Graphic Support > YES a Direct Rendering Manager...
Device Drivers > Graphic Support > Direct Rendering Manager... > NO a tutto, eccetto YES a ATI Radeon + Enable modesettings...
Device Drivers > Graphic support > Support for frame buffer... > NO a tutto
Device Drivers > Generic Driver Options > YES a Include in-kernel firmware blobs in kernel binary
Device Drivers > Generic Driver Options > in External firmware blobs to build into the kernel binary, inserisco la stringa "radeon/R600_rlc.bin"
Device Drivers > Generic Driver Options > in Firmware blobs root directory, inserisco la stringa "/lib/firmware"

Il firmware proprietario è messo ovviamente in /lib/firmware/radeon.
In compilazione, dopo:
make
make modules_install
eseguo anche:
make firmware_install

Se mi limito a installare il firmware proprietario, e uso un kernel generic smp con "radeon.modeset=1" nel boot loader, il compositing non va, e tty6 è nero se mi ci sposto dal menu di kdm. Se uso framebuffer vesa la console è nera sempre. Con il kms attivato nel kernel funziona tutto, per l'uso che ne faccio io (niente giochi, solo grafica statica e visione di video), a parte quando il monitor va in standby, e quando lo riattivo ho degli artefatti (puntini rossi che "si agitano", ben visibili per esempio sullo sfondo nero della console).

Holà,

io posso riportare solo la mia esperienza con le ATI che è stata sempre più che buona tant'è che ho cambiato "l'accoppiata" AMD-nVidia in AMD-ATI ...che poi sono la stessa cosa/casa.

Sul portatile (ASUS K51A acquistato senza SO), funzionano i driver open source (modulo radeon) e i driver closed (fglrx): la scheda grafica è una HD4200. AL momento ho su i driver closed e ci gira di tutto (anche con wine e compresi gli effetti 3D) senza avere grossi problemi di performance. Prima o poi ci proverò anche il test Unigine oltre al Phoronix.

Personalmente, ma può essere solo una mia impressione, penso che ATI/AMD abbia un fatto un gran bel passo in avanti rispetto agli anni passati.

Sul "microserver" casalingo (CPU 500MHz, RAM 384MiB e una Radeon 9000 con 64MiB) gira in maniera "stupefacente" il driver open radeon ...va che è una bellezza. Le distribuzioni: Mandrake 2010.2 sul portatile e Zenwalk con XFCE sul "microserver".

Bye

C'è da dire che, sul versante dei driver open, il passaggio a Gallium (lato Mesa) promette faville, anche se per ora Pat non ha intenzione di includerlo nel pacchetto Mesa (se non per il solo driver nouveau).

414N ha scritto:C'è da dire che, sul versante dei driver open, il passaggio a Gallium (lato Mesa) promette faville, anche se per ora Pat non ha intenzione di includerlo nel pacchetto Mesa (se non per il solo driver nouveau).

Ho letto su OS blog che su Ati-Gallium stanno implementando sia l'accelerazione stile VDPAU
per i video e sopratutto che i nuovi driver superano in prestazioni i drivers proprietari.

Meskalamdug ha scritto:Ho letto su OS blog che su Ati-Gallium stanno implementando sia l'accelerazione stile VDPAU
per i video e sopratutto che i nuovi driver superano in prestazioni i drivers proprietari.

Mah, qui c'è un elenco delle varie caratteristiche implementate finora in Gallium (risale però a Settembre 2010) e sembrano parecchio indietro ancora.
Tuttavia, nell'analoga pagina riguardante i driver radeon, viene riportata come WIP su Gallium l'implementazione dell'accelerazione video usando il motore 3D.
Avevo voglia di riprovare i driver gallium per la mia X800, ma evidentemente le nuove mesa (quelle presenti in current opportunamente ricompilate) non sono compatibili con X.org sulla Slackware 13.1...

Piccolo aggiornamento: sono riuscito a compilare le mesa 7.9 e i driver xf86-video-ati presenti in current sulla 13.1 stable attivando gallium e, a naso, le prestazioni 3D sembrano migliorate sensibilmente.
Ho fatto una prova veloce con Blender 2.56 e risulta molto più reattivo a prima usando lo sculpt tool su una mesh con molti poligoni.

414N ha scritto:Piccolo aggiornamento: sono riuscito a compilare le mesa 7.9 e i driver xf86-video-ati presenti in current sulla 13.1 stable attivando gallium e, a naso, le prestazioni 3D sembrano migliorate sensibilmente.
Ho fatto una prova veloce con Blender 2.56 e risulta molto più reattivo a prima usando lo sculpt tool su una mesh con molti poligoni.

Che modifiche hai fatto su mesa,basta --enable-gallium?

Io è da parecchio tempo che uso libdrm, mesa e drivers video compilati da me.
Ora ho queste versioni installate:

• libdrm 2.4.23
• mesa 7.10
• xf86_video_ati compilati dal git 2010-12-22

L'unico problema che ho avuto è stato con gli ultimi drivers video... Ho rimesso una versione del 22 dicembre perché con quella non ho problemi di sfarfallio e/o disegno.

libdrm è compilato con questi parametri: mesa invece usa questi parametri: xf86_video_ati è invece compilato con questi:

Meskalamdug ha scritto:Che modifiche hai fatto su mesa,basta --enable-gallium?

Non proprio. Sembra che ormai mesa utilizzi di default gallium per i driver r300/r600.
Gli interventi aggiuntivi che ho effettuato riguardano una patch per alcuni file Python (che altrimenti provocano un errore durante la compilazione) e la ricerca della libreria talloc (installata insieme a samba), che altrimenti non viene trovata perché manca il relativo file pkgconfig (che nella current è stato aggiunto al pacchetto di samba).
Inoltre, ho compilato con supporto anche ad LLVM (tanto per non farmi mancare nulla).
Ora glxinfo mi sputa fuori il seguente output: Allego lo SlackBuild modificato che ho usato, per chi si voglia dilettare nella ricompilazione di mesa.
Sappiate che vi servono i sorgenti sia di MesaLib 7.9 che di mesa-demos 8.0.1 (presenti nel ramo source/ della current, sotto x/mesa).

sardylan ha scritto: L'unico problema che ho avuto è stato con gli ultimi drivers video... Ho rimesso una versione del 22 dicembre perché con quella non ho problemi di sfarfallio e/o disegno.

Me ne sono accorto anch'io e sono tornato ai driver X di stock in Slackware 13.1. Probabilmente quelli nuovi hanno qualche bug da levigare, ancora.

Edit:lasciate perdere.

Attenzione: per chi usa slackware current e non funziona il video(x11 da schermo nero)
coi nuovi ati driver..usi questi(sono i vecchi ricompilati per current).


http://reteprivata.dyndns-ip.com/progra ... 64-2mg.txz

Dal changelog di ieri:

pasture/xf86-video-ati-6.13.2-x86_64-1.txz: Added.
Provide an alternate ATI driver in case of problems with the latest one.

Emanuele

spina ha scritto:Dal changelog di ieri:

pasture/xf86-video-ati-6.13.2-x86_64-1.txz: Added.
Provide an alternate ATI driver in case of problems with the latest one.

Emanuele

Tra l'altro usando kms vanno...ma non era abilitato di default?

p.s=ma non va il 3d

Sempre nel changelog dice:

x/xf86-video-ati-6.14.0-x86_64-1.txz: Upgraded.
This new driver requires KMS, which is set by default in the new kernel.
Otherwise, create /etc/modprobe.d/radeon.conf with this content:
options radeon modeset=1
Also, the kernel should be booted with vga=normal.
Problems have been observed when trying to use KMS after starting a VESA
framebuffer console. Sorry about the penguins.

A me il 3d va,
Emanuele