[eside-ghost] configurando xorg con radeon

[Jon Ander Hernandez]

Aupi!

El día 15 de septiembre de 2009 13:03, altern <altern2 en gmail.com> escribió:
> aupa
>
> he instalado el ultimo ubuntu en un ordenador y me va como una patata.
> el caso es que mirando como ponerlo un poco mas rapido he encontrado
> esta documentacion sobre como configurar xorg.conf con el driver libre.
> Me han parecido bastante buenos pq explican paso a paso cada opcion. He
> pensado que igual a alguno os interesa y por si alguno no los conoce ahi
> van.
>
> https://help.ubuntu.com/community/RadeonDriver
> http://www.thinkwiki.org/wiki/Additional_options_for_the_radeon_driver

La verdad es que ya siento desilusionarte, pero la verdad es que no
son páginas muy útiles en el escenario actual :-S :

- La aceleración 2D se activa con EXA, y aún no está muy optimizada
para todas las tarjetas, a veces jugando con los parámetros se suele
deshabilitar, que puede dar la falsa sensación de que ahora ya
funciona la aceleración, cuando suele ser al revés... que el modo
acelerado lo hace tan mal que desacelera.

- Xinerama (el sistema multihead antiguo) hoy día está deprecado y ha
sido reemplazado por RandR (X Rotate And Resize).

- Page Flip se deshabilita cuando se usa con acceleración (EXA).

- AGPFastWrite, no estoy muy puesto, pero me suena que ya no era
necesario, y cuando se toca equivaler a colgar el equipo.

- El video overlay paso a mejor vida cuando llegaron los gestores de
composición (Compiz, etc...), y además no existe en el hardware
moderno. Ahora el video es tratado a través de texturas y escalado con
la GPU.


La mejor documentación sobre el driver la tienes en "man radeon",
aunque hoy día los valores por defecto suelen tener la mejor
configuración posible (desactivando las óptimizaciones inestables y/o
experimentales), a no ser... que EXA no esté activado, en cuyo caso lo
interesante sería activarlo claro, jejeje. Para ello habría que editar
el xorg.conf (que salvo para esto y 4 cosas más ya es totalmente
prescindible) y añadir la opción AccelMethod "EXA". Después habría que
revisar en el log para comprobar que realmente esté activado, y si no
lo está... malo :-S,  pues ya empezar a investigar a ver cual es el
origen del problema (si la versión actual no soporta tu chip, si el
driver del kernel se pega con tu driver de las X, etc...)


Aquí tienes una tabla donde se muestra el estado actual de los drivers :

http://wiki.x.org/wiki/RadeonFeature


De todas maneras, para las nuevas tarjetas la cosa está un poco verde,
aunque el soporte 2D acelerado y el 3D necesario para Compiz, avanza a
buen ritmo, pero...  el soporte 3D "de verdad" (OpenGL 3.x) tardará en
llegar, pero bueno, lo cierto es que ahora estamos en un escenario
radicalmente diferente al que estábamos hace un par de años, con
especificaciones abiertas y un equipo de desarrolladores pagado a
tiempo completo para completar estos drivers libres.

Lo malo es que crear un driver 3D completo y competitivo es algo
complejo que requiere de una inversión enorme de trabajo, y con los
medios actuales no es suficiente.... :-S. Esto ha llevado a crear un
nuevo proyecto, que lleva ya casi un par de años desarrollándose,
llamado Gallium 3D del que cada día se habla más, y que acaba de ser
recientemente incorporado a Mesa 3D (la implementación OpenGL libre),
lo interesante de Gallium 3D es que replantea la fórmula de los
drivers 3D, de modo que se tendrá una capa común para todos los
drivers que permitirá a todo driver que implemente el soporte Gallium
3D obtener automágicamente soporte OpenGL 3.x, OpenCL, OpenVG, EXA,
etc...

Aunque esto parezca magia, la razón de que se pueda hacer es que
gracias a que las GPUs modernas son cada día más programables y que
están avanzando todas hacia un juego de instrucciones
común/standarizado gracias a los standards de shaders, es posible
plantear una gráfica genérica virtual, de modo que las APIs expuestas
a las aplicaciones (OpenGL, OpenCL, OpenVG, etc...) se traduzcan a
llamadas sobre esa gráfica virtual, y esta a su vez, a través del
driver Gallium 3D se traduzcan y se optimicen a las instrucciones
especificas de la tarjeta gráfica.
Y para toda la labor de optimización recaería sobre LLVM, el cual es
un conjunto de herramientas de compilación, que hoy día ya es usado en
las implementaciones de OpenGL y OpenCL de Apple, que "demuestra" que
la idea "es factible", ya que no hay más que ver que hay Macs que son
capaces de ejecutar shaders decentemente que la GPU no soporta, lo
cual IMHO es MUY acojonante!!!

Y bueno no me extiendo más... jejeje, si eso otro día ya escribo un
artículo sobre Gallium 3D.

Un saludete! ;-)

JonAn.


P.D: Si alguien necesita un diccionario de términos, o que explique
más sencillamente que es cada cosa, no hay problema ;-)