[eside-ghost] dude, where is my aiglx? ERA: violacion de segmento
aktor
aktor en aktornet.ath.cx
Mie Mayo 3 02:22:16 CEST 2006
Aupa JonAn,
IM-PRE-SIONANTE ;-)
Creo que es imposible explicar algo tan complejo de forma tan sencilla y
a la vez completa. Si no te conociese, diría que no existes :-D
El mar, 02-05-2006 a las 21:32 +0000, Jon Ander Hernández escribió:
> Aupi!!
>
> On Tue, 2006-05-02 at 21:24 +0200, Malkavian wrote:
> > ¡Aupa takeda -dash!:
> >
> > > Prueba a ponerte la cvs de xorg, ya lleva incorporado aiglx, la
> > > alternativa de xgl que saco redhat. Hasta hace poco solo funcionaba con
>
> Explico lo que es aiglx :
>
> - Aiglx no es un xserver nuevo.
> - Aiglx no es una tecnología nueva.
> - Aiglx no es una revolución.
> - Aiglx no es lo único necesario para que Compiz funcione sobre un xorg
> normal.
>
> - Aiglx es un parche, es una feature del servidor de las X que lleva
> años en el ToDo list pero que requería bastante trabajo y no aportaba
> demasiada ventaja.
> - Los drivers privativos de nvidia soportan aiglx desde hace mucho
> tiempo, pero solo con aiglx no conseguimos ejecutar Compiz.
>
> ¿Por lo tanto que es aiglx?
> ----
>
> Aiglx aka air == Accelerated Indirect Rendering. Es decir si usamos
> direct rendering que es lo que usamos normalmente al usar cualquier
> aplicación 3d, el air no nos da ninguna ventaja.
> El direct rendering es un truco para eliminar trafico innecesario entre
> la aplicación y el servidor de las X, de manera que en vez de hacer que
> los comandos opengl vayan al servidor de las X, van directamente a la
> tarjeta gráfica.
> Como el servidor de las X tenía que soportar opengl, se incluyo una
> implementación software de opengl en el servidor de las X, con lo cual
> si no tenías direct rendering había un fallback y usabas la
> implementación software del servidor de las X, de aquí que hasta ahora
> para nosotros direct rendering == aceleración opengl.
>
> ¿Porque no hemos tenido hasta ahora aiglx?
> ----
>
> Porque requería reimplementar el renderer opengl del servidor de las X,
> porque el código del opengl del servidor de las X y el código del opengl
> que usamos cuando usamos direct rendering eran muy diferentes.
> Por lo tanto ahora cuando usamos el xorg 7.1 (que esta en RC1, o el
> cvs), ya no usamos la implementación software de opengl, usamos el
> driver DRI que antes solo se usaba desde la libgl, y el fallback (en
> caso de que no haya driver para nuestra gráfica), es un módulo DRI que
> en vez de ser un driver, es una implementación software.
>
> Tengo los drivers de Nvidia o Xorg 7.1 con aiglx, ¿que me falta para
> poder tener el eyecandy? porque con mi gestor de ventanas es todo igual
> ----
>
> Jejeje, el eyecandy no viene de Xgl, ni de nvidia, ni de xorg+aiglx, el
> eyecandy viene de la 3º generación de gestores de composición.
>
> Un gestor de composición es un programa especial (como un gestor de
> ventanas) el cual se encarga de pintar el escritorio, este programa coge
> los contenidos de las ventanas y los pinta.
>
> Gestores de ventanas :
>
> 1º Generación : Usan XRender que es API 2D de las X, el problema es que
> dependiendo de lo eficiente que sea nuestro servidor de las X con
> XRender obtendremos unos efectos suaves o lentos.
>
> La ventaja de esta primera generación es que el gestor de ventanas y el
> gestor de composición son programas independientes, con lo cual es el
> gestor ideal para tener transpas, sombras y menos consumo de CPU por
> redibujo de ventanas, pero por otro lado no podemos obtener solo usando
> XRender cubos, ni efectos como desenfoque de ventanas, cambios de
> tonalidades de color... etc.. eso es cosa de Compiz.
>
> Programa : xcompmgr
>
> 2º Generación : Usa OpenGL, y he aquí la razón por la que necesitamos
> aiglx, el servidor de las X mantiene el contenido de las ventanas en una
> región de la memoria gráfica que gestiona el Xserver, peeeero... si
> usamos Direct Rendering el OpenGL va directamente a la gráfica sin pasar
> por el servidor, luego... el opengl del cliente no puede ver los buffers
> de las ventanas, con lo cual lo que hace, es un hack guarro, usa
> llamadas de las X normales y copia el contenido del buffer en una
> textura... luego ambas cosas están en la tarjeta gráfica sin verse, y
> para poderse dibujar con opengl, se tiene que pillar el Pixmap de la
> gráfica llevarlo a la memoria y volverlo a escribir en la memoria de
> video pero esta vez como textura... ergo... no va tan fisno.
>
> Programas : glxcompmgr y luminocity
>
> 3º Generación : Compiz, el truquis del almendruquis es una extensión
> OpenGL nueva llamada GLX_EXT_texture_from_pixmap, que basicamente lo que
> hace es asociar un pixmap a una textura y listo... ya no hay que copiar
> pixmap a texturas.
>
> Por lo tanto para que xorg+NVIDIA soporte Compiz TIENE que SACAR un
> DRIVER nuevo que incorpore la EXTENSION GLX_EXT_texture_from_pixmap. Y
> Nvidia ha dicho que lo hará, pero supongo que si no lo han sacado es
> porque aún no lo han terminado.
>
> Aiglx que incluye el rediseño diseño del OpenGL tiene drivers DRI que
> incorporan dicha extensión ergo, con aiglx Compiz funciona.
>
>
> ¿Porque tanta publicidad a aiglx?
> ----
>
> Porque era la respuesta ante tanto pro-xgl. Xgl aún es un proyecto que
> esta verde, y le falta bastante antes de que sea la alternativa a la
> actual modelo de servidor de las X.
> Además hay dos conflictos latentes en xorg+aiglx vs Xgl :
>
> - Marketing :
> - Novell ha conseguido muchísima popularidad con el anuncio de
> Xgl y su distro opensuse ha conseguido mucha atención desde que
> anunció que iba a incorporar Xgl de serie.
> - Red hat tiene a desarrolladores trabajando tanto en las X,
> como en gestores de ventana como metacity, y en el resultado de
> Xgl y Compiz Red hat tiene tanto merito o más que Novell, que se
> ha limitado a contratar al autor de Xgl y Compiz.
>
> - Desarrollo :
> En la comunidad de las X existen tres posturas ante Xgl :
>
> - Partidarios de priorizar el desarrollo de Xgl, para ellos es
> un hecho el que Xgl es el futuro y lo ven como algo cercano si
> se unifican los esfuerzos de todos los desarrolladores.
>
> - Partidarios de Xgl como futuro a la larga, estos son mayoría,
> ellos creen que la arquitectura de Xgl es la solución a la
> actual arquitectura de Xorg (aka XAA), aunque son realistas y
> conscientes de que aún queda mucho trabajo por hacer, y que por
> lo tanto, creen que Xgl debe seguir siendo desarrollado en
> paralelo a Xorg, ya que es necesario seguir avanzando y no parar
> centrados en Xgl durante 2 años hasta terminarlo.
>
> - Partidarios de incorporar las mejoras de Xgl en Xorg y
> abandonar Xgl como nuevo diseño e ir mejorando progresivamente
> Xorg. Estos son los que menos, y entre ellos están los
> desarrolladores de Nvidia.
>
> > Gracias por la información, no sabía que ya estaba hecho en el CVS, pero
> > aún así seguiré feliz cual Abeja Maya XD esperando a que salga en Debian
> > testing o en unstable con soporte para KDE y Nvidia. Quien sabe, si no
> > está para la Euskal Party igual hay que ponerlo como sea para poder
> > fardar ante los que esperan al Windows Vista ese que iba a salir a
> > finales del 2004 XDDD
>
> Nvidia no usa XAA (X Acceleration Architecture, la arquitectura de
> XFree86/Xorg), aiglx es un parche de XAA.
>
> El eyecandy no lo da Xgl/Xorg+aiglx/Nvidia, lo da el gestor de
> composición + el gestor de ventanas, es decir Compiz. Por lo tanto si
> quieres que Kde tenga ese eyecandy tendrás que reemplazar el gestor de
> ventanas de kde (kwin) por Compiz o bien esperar a que los
> desarrolladores de KDE implementen el eyecandy de Compiz dentro de kwin
> (que no parece factible según los hilos que he seguido entre
> desarrolladores de metacity y el desarrollador de Compiz).
>
> Un saludete!!
>
> {X,G}JonAn.
>
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost
--
saludos,
>aktor<
"Sed quis custodiet ipsos custodes?"
-- Juvenal, Satires (c. 120 AD)
Más información sobre la lista de distribución eside-ghost