Charlas 13-12-2000 Umeet'2000

Charlas 13/12/2000

Log de la conferencia. Se han suprimido las líneas correspondientes a entradas y salidas de diferentes personas en el canal durante la conferencia
[19:16] (Fernand0) Hola,
[19:16] (Fernand0) aunque me parece que se nos presentan malas perspectivas
[19:16] (Fernand0) 'marejadilla en la red' :(
[19:16] (Fernand0) estamos muy contentos de presentarles hoy aquí a Marcelo Magallón.
[19:16] (Fernand0) Es
[19:16] (Fernand0) Físico y nació en Costa Rica, pero está desarrollando su trabajo de tesis
[19:16] (Fernand0) doctoral en Stuttgart, con el Departamento de Informática, trabajando en
[19:16] (Fernand0) Visualización y Sistemas Interactivos.
[19:17] (Fernand0) También está implicado en la distribución Debian (http://www.debian.org
[19:17] (Fernand0) visitenla) y en varios proyectos de software 3D.
[19:17] (Fernand0) Su charla se titula:
[19:17] (Fernand0) Soporte para hardware de aceleración 3D bajo Linux.
[19:17] (Fernand0) Estamos muy agradecidos por la presencia de todos ustedes asi como por la
[19:17] (Fernand0) amabilidad del conferenciante al ofrecernos esta conferencia.
[19:17] (Fernand0) Marcelo ...
[19:17] (m2) Gracias Fernand0, nada más una corrección... yo nací en Chile pero soy costarricense :)
[19:17] (Fernand0) ops
[19:17] (Fernand0) perdón
[19:17] (m2) np
[19:18] (m2) La charla la enfoqué no tanto a aspectos técnicos, sino más bien a una
[19:18] (m2) introducción de como y porqué apareció el soporte para 3D bajo
[19:18] (m2) linux. Es algo que resulta interesante para mí, pues a diario tengo
[19:18] (m2) que trabajar con diversos aceleradores gráficos, ya sea en PCs o en estaciones
[19:19] (m2) de trabajo de SGI.
[19:19] (m2) En las PCs nuestro grupo utiliza fundamentalmente tarjetas tipo GeForce
[19:19] (m2) algo con lo que yo no estoy muy satisfecho (al final de la charla
[19:19] (m2) discutiré por qué), pero que sirve mejor a nuestras intenciones
[19:19] (m2) de investigación.
[19:20] (m2) Recientemente hemos comenzado a probar con tarjetas de ATI también
[19:20] (m2) y al final de la charla mencionaré también algo al respecto
[19:20] (m2) Bueno, de aquí en adelante está casi todo escrito ya, así que si
[19:21] (m2) voy muy rápido nada más me avisan
[19:21] (m2) hmm...
[19:21] (m2) Ok. Como decía, de aquí en adelante está casi todo previamente
[19:22] (m2) escrito pero trataré de no ir muy rápido.
[19:22] (m2) A lo largo de los últimos años el soporte para generación de
[19:22] (m2) gráficos en 3D asistida por hardware en PCs estándar ha mejorado
[19:22] (m2) de forma contínua. Durante el mismo periódo de tiempo, esto se a
[19:22] (m2) pasado de ser un mercado vertical compuesto primordialmente por
[19:22] (m2) usuarios de CADs a un mercado general ampliamente dominado por el
[19:22] (m2) sector de juegos en PCs. En estos días, el sistema "orientado a
[19:22] (m2) juegos" más rápido del mercado se vende por un monto inferior a
[19:22] (m2) US$500 y existen ofertas por debajo de los US$100. Por otra
[19:22] (m2) parte, soluciones denominadas "profesionales", tal como la
[19:22] (m2) Diamond Fire GL, 3Dlabs Oxygen y Wildcat, y las REALimage de
[19:23] (m2) Evans & Sutherland se venden por US$2000 o más. Dejando de lado
[19:23] (m2) las consideraciones de velocidad, la diferencia yace básicamente
[19:23] (m2) en las características ofrecidas: un pipeline de OpenGL completo
[19:23] (m2) en hardware, formatos internos de mayor precisión,
[19:23] (m2) configuraciones dual-head, capacidades de displays en estéreo,
[19:23] (m2) etc. Dados los avances vistos en el mercado "low end", una vez
[19:23] (m2) que se introduce el rendimiento en la ecuación, las ventajas
[19:23] (m2) ofrecidas por estos sistemas avanzados no resultan tan obvias.
[19:24] (m2)
[19:24] (m2) El desarrollo en Linux (y en general, dentro de la comunidad de
[19:24] (m2) Software Libre/Open Source) comienza pues alguien tiene necesidad
[19:24] (m2) de llenar un vacío. Como norma, los vendedores de hardware
[19:24] (m2) obtienen ganacias vendiendo hardware, no escribiendo software
[19:24] (m2) para el mismo. Para la mayoría de los productores de hardware,
[19:25] (m2) escribir y mantener drivers representa una inversión no trivial
[19:25] (m2) en términos de recursos humanos y tiempo de desarrollo. Dada la
[19:25] (m2) relativamente reciente explosión de juegos en el mercado que
[19:25] (m2) *requiren* de generación de imágenes asistida por hardware, no es
[19:25] (m2) solamente la disponibilidad de los drivers sino también la
[19:25] (m2) calidad de los mismos lo que resulta un factor determinante para
[19:25] (m2) el éxito comercial que un producto dado obtenga, lo cual quiere
[19:25] (m2) decir que la inversión de parte del vendedor debe ser mayor. Aún
[19:25] (m2) tomando las proyecciones más optimistas, Linux representa apenas
[19:26] (m2) un 4% del mercado de PCs de escritorio, que es lo que importa en
[19:26] (m2) el caso de aceleradores gráficos de 3D (AG3D). Si aceptamos que
[19:26] (m2) el 100% del mercado de PCs de escritorio es también el mercado
[19:26] (m2) para AG3D, lo cual es por falso por un amplio margen, hoy en día
[19:26] (m2) un vendedor de hardware difícilmente se verá presionado para
[19:26] (m2) proveer soporte para Linux al momento del lazamiento de un nuevo
[19:26] (m2) producto.
[19:27] (m2) En esta revisión se tratarán de responder las preguntas de
[19:27] (m2) cuándo, cómo y por qué existen drivers para AG3D para Linux
[19:27] (m2) hoy en día, así como evaluar que tan buenos (o malos) son
[19:27] (m2) dichos drivers, y qué se puede hacer con ellos, primordialmente
[19:27] (m2) en el contexto de desarrollo de Software Libre, pero sin ignorar
[19:27] (m2) el lado comercial del asunto. Primero se dará un transfondo
[19:27] (m2) histórico, seguido de una revisión de hardware actualmente
[19:27] (m2) soportado para finalizar con posibles vías de desarrollo a
[19:28] (m2) futuro.
[19:28] (m2) Transfondo histórico
[19:28] (m2) Actualmente varios juegos comerciales están disponibles para
[19:28] (m2) Linux, y en su mayoría no son títulos originales sino
[19:29] (m2) versiones "traducidas" a partir de sus antiguas contrapartes para
[19:29] (m2) Windows, además de unos pocos que han sido publicados
[19:29] (m2) simultáneamente para Windows y Linux (i386). Una gran parte de
[19:29] (m2) este trabajo de "traducción" ha sido realizado bajo contrato
[19:29] (m2) por parte de Loki Entertainment Software. La página de
[19:29] (m2) productos de dicha compañía presenta más de una docena de
[19:29] (m2) juegos, ya sea disponibles para la compra o a punto de ser
[19:29] (m2) publicados, y que requieren de un AG3D para funcionar, cifra
[19:29] (m2) minúscula si se la compara con la oferta para el mundo de
[19:29] (m2) Windows, pero que representa un aumento de 10x respecto a la
[19:29] (m2) cantidad disponible hace un año. Se podría decir que la
[19:29] (m2) situación está "resuelta" ahora, pero esto no era tan claro
[19:30] (m2) hace dos años. ¿Quién querría trabajar en driver para
[19:30] (m2) AG3D si no había software para usarlos y quién querría
[19:30] (m2) escribir el software si no habían drivers? Desde el punto de
[19:30] (m2) vista del mercado de los juegos, la respuesta es iD software, los
[19:30] (m2) creadores de la serie Quake, y en particular John Carmak.
[19:30] (m2)
[19:31] (m2-) (John Carmak participó durante varios meses en el desarrollo de drivers para Linux, en especial para G400 y ATI Rage, considero que require una mención especial aquí pues era en la mejor tradición de software libre, un hobby)
[19:31] (m2-)
[19:31] (m2) Retornando un poco más atrás en el tiempo, hasta el momento
[19:31] (m2) cuando la idea misma de Quake todavía estaba en gestación, a
[19:32] (m2) inicios de los noventa Silicon Graphics, Inc. (SGI) se había
[19:32] (m2) establecido a sí mismo como el proveedor por excelencia de
[19:32] (m2) soluciones relacionadas con aceleración de hardware en 3D. SGI
[19:32] (m2) ofrecía el espectro completo de productos: tanto estaciones de
[19:32] (m2) trabajo completas así como aditamentos, ya fuese para clientes
[19:32] (m2) pequeños, medianos o grandes. Para dar soporte a este amplio
[19:32] (m2) rango de tecnologías SGI había desarrollado la biblioteca
[19:32] (m2) gráfica para IRIS (IRIS Graphics Library), IRIS GL. IRIS GL
[19:32] (m2) estaba fundamentalmente unida al pipeline gráfico de las
[19:32] (m2) estaciones de trabajo de SGI y era difícil de llevar a otros
[19:32] (m2) sistemas (si se llevó a otros sistemas, HP/UX, por ejemplo).
[19:33] (m2) En 1992 se dió un paso importante: se introdujo OpenGL y se
[19:33] (m2) creó el OpenGL Architecture Review Board (OpenGL ARB), una
[19:33] (m2) organización neutral con respecto a los vendedores de hardware
[19:33] (m2) cuya función es velar por el desarrollo de la especificación
[19:33] (m2) de OpenGL. Desde entonces se han dado dos actualizaciones de la
[19:33] (m2) especificación, y se ha establecido como el estándar de facto
[19:33] (m2) para gráficos en 3D en la comunidad de Unix, y se utiliza
[19:33] (m2) ampliamente en el mundo de Windows, donde coexiste con Direct 3D
[19:33] (m2) de Microsoft.
[19:33] (m2)
[19:34] (m2-) (la funcionalidad que Direct 3D ofrece es similar a OpenGL, aunque la implementación se desvía de la de OpenGL. Si OpenGL está diseñado para ser portátil y eficiente, Direct 3D está fuertemente ligado a PCs)
[19:35] (m2-)
[19:35] (m2) Una de las razones por las cuales OpenGL ha resultado exitoso es
[19:35] (m2) el hecho que es un estándar definido. Para proteger y
[19:35] (m2) preservar esta cualidad, cualquier implementación que desee
[19:35] (m2) proclamarse como OpenGL debe adquirir una licencia para este
[19:35] (m2) propósito. Hasta hace poco (inicios del 2000), esta licencia
[19:35] (m2) se encontraba disponible solo contra pago, ya sea a Microsoft (si
[19:35] (m2) es una implementación para Windows) o SGI (en otro caso). En
[19:35] (m2) cualquier caso, el monto a pagar no es bajo. Lo que esto quiere
[19:35] (m2) decir es que las posibilidades de contar con una implementación
[19:35] (m2) libre de OpenGL eran pocas. Aún así, en 1995, mientras
[19:36] (m2) trabajaba para el Space Science and Engineering Center de la
[19:36] (m2) University of Wisconsin - Madison, Brian Paul hizo pública (con
[19:36] (m2) el permiso legal del SGI) la biblioteca Mesa 1.0, que contaba con
[19:36] (m2) el mismo API de OpenGL (pero no podía ser llamada OpenGL).
[19:36] (m2)
[19:36] (m2-) (Se habló varias veces respecto a la posibilidad de que una compañía *pagara* por esta licencia, pero nunca se hizo realidad)
[19:36] (m2)
[19:37] (m2) Una de las cosas buenas respecto a OpenGL es que es independiente
[19:37] (m2) de el sistema de ventanas que se utilice. En su lugar es
[19:37] (m2) necesario un poco de "pegamento" entre el sistema de ventanas y
[19:37] (m2) la implementación de OpenGL que se utilice. En el caso de
[19:37] (m2) Unix, el sistema de ventanas subyacente es casi con seguridad el
[19:37] (m2) X Window System (X para abreviar), y el "pegamento" asociado es
[19:37] (m2) GLX. Sin entrar en los detalles sangrientos del funcionamiento
[19:37] (m2) de X, es suficiente con decir que fue diseñado desde un inicio
[19:37] (m2) con transparencia en redes en mente. Esto, entre otras cosas,
[19:37] (m2) quiere decir que hay clientes y hay servidores. Con este
[19:37] (m2) diseño, el servidor de X soporta extensiones, y GLX es una de
[19:37] (m2) ellas. Poco tiempo después de la salida de Mesa, un *pseudo
[19:38] (m2) implementación* de GLX le fué añadida. No es una
[19:38] (m2) implementación real pues reside al nivel de biblioteca, es
[19:38] (m2) decir, al nivel del cliente, no a nivel del servidor de X. Esta
[19:38] (m2) implementación genera la escena en un buffer interno que luego
[19:38] (m2) es copiado a un X pixmap que el servidor de X coloca en la
[19:38] (m2) pantalla.
[19:38] (m2)
[19:38] (m2-) (sobra decir, esto es lento)
[19:38] (m2)
[19:38] (m2) Históricamente las tarjetas Voodoo de 3Dfx no fueron las
[19:38] (m2) primeras para las cuales hubo soporte de OpenGL acelerado por
[19:38] (m2) hardware generado a través de Mesa, pero fueron las primeras
[19:38] (m2) tarjetas en *amplia circulación* que estuvieron en dicha
[19:39] (m2) posición. Esto fue posible gracias a la existencia de glide,
[19:39] (m2) una biblioteca no-libre que servía como capa de interface
[19:39] (m2) delgada para el hardware subyacente. Esta no era una
[19:39] (m2) arquitectura basada en GLX y necesitaba de algunos cambios a
[19:39] (m2) nivel de código fuente en los programas diseñados para
[19:39] (m2) trabajar con GLX. Si bien su aplicabilidad era reducida, este
[19:39] (m2) trabajo fue importante pues atrajo tanto usuarios como
[19:39] (m2) desarrolladores hacia Mesa y por extensión hacia OpenGL bajo
[19:39] (m2) Linux.
[19:39] (m2)
[19:40] (m2-) (el código fuente de glide fue liberado hace relativamente poco tiempo por 3Dfx, pero es importante recordar que durante varios años se tuvo que trabajar solo a través de una interface y no con el código mismo)
[19:41] (m2)
[19:41] (m2) Un evento importante ocurrió a inicios de 1999: SGI liberó el
[19:41] (m2) código fuente de GLX y ya había empezado a trabajar con
[19:41] (m2) Presicion Insight, patrón para ese entonces, entre otros, de
[19:41] (m2) Brian Paul, en la integración de este código dentro de
[19:41] (m2) XFree86, la implementación de X usada en Linux. Esta
[19:41] (m2) integración estaba enfocada al rededor de XFree86 4.0. En el
[19:41] (m2) intermedio, los AG3D se estaban haciendo cada vez más baratos y
[19:41] (m2) populares, lo cual llevó a algunos programadores a buscar una
[19:41] (m2) solución más immediata (se preveía que la primera versión
[19:41] (m2) de XF86 4.0 estaría lista no antes de un año). En ese
[19:41] (m2) momento, una implementación de GLX había sido escrita en la
[19:42] (m2) Universidad de Utah, y era usable con la versión 3.3.5 de
[19:42] (m2) XFree86, pero carecía de soporte para chipsets populares.
[19:42] (m2) Resultó que varios vendedores de hardware proveieron a
[19:42] (m2) programadores con suficiente información como para escribir
[19:42] (m2) driver para los diferentes chipsets. Tal como ocurre con otros
[19:42] (m2) proyectos de Software Libre, varios programadores al rededor del
[19:42] (m2) mundo unieron fuerzas en torno a esta iniciativa, llamada "Utah
[19:42] (m2) GLX".
[19:42] (m2)
[19:43] (m2-) (la lista de programadores involucrados con utah-glx es bastante grande, aunque la mayor parte del trabajo fue llevada a cabo por un grupo relativamente pequeño de más o menos 7 u 8 personas.
[19:43] (m2-) Entre los involucrados habían varios empleados de PI)
[19:43] (m2)
[19:43] (m2) Dos eventos adicionales ocurrieron luego, uno en enero del 2000 y
[19:43] (m2) el otro en agosto del mismo año. El primero: SGI liberó la
[19:44] (m2) implementación de referencia de OpenGL (OpenGL SI). La SI es
[19:44] (m2) una implementación de OpenGL en software que ofrece ganchos
[19:44] (m2) para aceleración por hardware, y previamente estaba disponible
[19:44] (m2) únicamente bajo una licencia comercial. El segundo: SGI ahora
[19:44] (m2) permite que proyectos *Open Source* utilicen la marca OpenGL y el
[19:44] (m2) logo, luego de pasar las pruebas de conformidad, sin que sea
[19:44] (m2) necesario el pago de una licencia para ese propósito.
[19:44] (m2)
[19:44] (m2-) (no encontré mi diccionario: conformidad == conformance)
[19:45] (m2)
[19:45] (m2) Situación actual
[19:45] (m2)
[19:45] (m2) Y llegamos al día de hoy, con XFree86 4.0 finalmente publicado,
[19:45] (m2) aunque aún en desarrollo. Tal como SGI/PI habían previsto
[19:45] (m2) casi dos años antes, XFree86 4.0 contiene el código de GLX
[19:45] (m2) liberado por SGI y lo utiliza para ofrecer la interface necesaria
[19:45] (m2) para arbitrar el uso de recursos por parte del servidor de X y la
[19:45] (m2) biblioteca de OpenGL. Para que esto funcione, además de la
[19:45] (m2) extensión GLX en el servidor es necesaria una implementación
[19:45] (m2) de OpenGL que el cliente pueda utilizar. Esta implementación
[19:45] (m2) es Mesa, que ya se encuentra en su versión 3.4. Mesa ofrece
[19:46] (m2) hoy en día una implementación completa de OpenGL 1.2 y de
[19:46] (m2) acuerdo con los últimos resultados publicados por Brian Paul,
[19:46] (m2) pasa casi la totalidad de los tests de conformidad. (El
[19:46] (m2) "conformance test" no está disponible al público, aunque
[19:46] (m2) existe el proyecto glean, que busca proveer un medio de
[19:46] (m2) comparación entre diferentes implementaciones de OpenGL) La
[19:46] (m2) totalidad de los componentes que implementan OpenGL para XFree86
[19:46] (m2) 4.0 conforman el proyecto DRI: Direct Rendering Interface. El
[19:46] (m2) nombre hace incapié en el hecho que un cliente utilizando
[19:46] (m2) OpenGL puede acceder directamente al hardware gráfico, *sin
[19:46] (m2) pasar necesariamente* por el servidor de X (como es el caso de
[19:46] (m2) Mesa o clientes remotos). Es una interface completa en el
[19:46] (m2) sentido que ofrece servicios no solamente como biblioteca de
[19:46] (m2) OpenGL sino de coordinación y mantenimiento de recursos tanto
[19:46] (m2) con el servidor de X como con el kernel de Linux.
[19:46] (m2)
[19:47] (m2-) (varias notas:
[19:47] (m2-) glean busca comparar la calidad de una implementación con otra, no busca ser un reemplazo para el conformance test
[19:48] (m2-) DRI existe fundamentalmente en Linux, y se ha mencionado varias veces la posibilidad de llevarlo a FreeBSD y Solaris, pero no sé realmente que tan avanzados estén estos proyectos
[19:49] (m2)
[19:49] (m2) Actualmente el DRI soporta tarjetas gráficas de ATI (Rage 128),
[19:49] (m2) Intel (i810 e i815), Matrox (G200 y G400/G450), 3Dfx (Voodoo 3 y
[19:49] (m2) 5) y 3Dlabs (Oxygen GMX 2000). Algunos de los drivers están en
[19:49] (m2) constante desarrollo y otros están en una situación estable.
[19:49] (m2) Además PI ha iniciado el trabajo en drivers para el chip Radeon
[19:49] (m2) de ATI y Gareth Hughes desarrolla independientemente el driver
[19:49] (m2) para chipsets Mach64.
[19:49] (m2)
[19:49] (m2-) (además existen drivers para, creo, 3D Creator de Sun)
[19:49] (m2-)
[19:50] (m2) Respecto a la calidad de la implementación de DRI, un punto que
[19:50] (m2) será importante luego, mi experiencia es que es estable además
[19:51] (m2) de sólido. Algunas personas han tenido problemas con los
[19:51] (m2) drivers para G400 (lo que yo utilizo), pero yo no puedo reproducirlos
[19:51] (m2) También se que algunas personas han tenido problemas en particular
[19:52] (m2) con Ultima Tournament, pero no sé. Módulo Q3A y Tux Racer, yo no
[19:52] (m2) uso DRI para jugar sino para el trabajo de la Universidad.
[19:52] (m2)
[19:52] (m2) Además del DRI, existen otras posibilidades para obtener
[19:52] (m2) aceleración para 3D bajo linux:
[19:52] (m2)
[19:53] (m2) * Utah-GLX: sigue siendo una opción válida para obtener
[19:53] (m2) aceleración 3D bajo linux, y en algunos casos es la única o
[19:53] (m2) una mejor opción si se le compara con DRI. El manejo de
[19:53] (m2) recursos es diferente al de DRI y por tanto ofrece en algunos
[19:53] (m2) casos un conjunto diferente de planos auxiliares al que ofrece
[19:53] (m2) DRI. Dentro de los chipsets soportados están la serie RIVA
[19:53] (m2) de NVIDIA, RagePRO de ATI, el 6326 de SiS y los ViRGE y Savage
[19:53] (m2) 3D de S3.
[19:53] (m2)
[19:54] (m2) Los drivers de Utah para RIVA son particularmente inestables
[19:54] (m2) debido a la forma en la que NVIDIA liberó las especificaciones
[19:54] (m2) para ese chipset.
[19:54] (m2)
[19:54] (m2) * NVIDIA: Por diferentes motivos internos, NVIDIA ha optado por
[19:54] (m2) no hacer públicas las especificaciones de sus chipsets y ha
[19:55] (m2) desarrollado internamente los drivers para Linux. ¿Por qué
[19:55] (m2) NVIDIA ve con interés el mercado de Linux? Eso lo sabe solo
[19:55] (m2) NVIDIA, pero probablemente tiene que ver más con publicidad
[19:55] (m2) que con otra cosa. Actualmente NVIDIA ofrece soporte para toda
[19:55] (m2) la línea entre el TNT2 y el GeForce2. La calidad de los
[19:55] (m2) drivers, en términos de rendimiento, es comparable con la de
[19:55] (m2) Windows, y en términos de características soportadas son
[19:55] (m2) idénticos.
[19:55] (m2)
[19:55] (m2) En favor de NVIDIA debo decir que los drivers bajo Windows y
[19:56] (m2) Linux son idénticos (o casi), pues comparten el mismo código
[19:56] (m2) base, lo cual hace fácil para *ellos* corregir problemas
[19:56] (m2) que se presenten en la implementación de OpenGL.
[19:56] (m2)
[19:56] (m2) El problema con los drivers de NVIDIA (y algo que es de admirar
[19:57] (m2) en la compañía es que mantienen sus labios herméticamente
[19:57] (m2) cerrados con respecto a detalles de los drivers.
[19:57] (m2)
[19:57] (m2) Digo que es admirable pues para otras compañías eso ha resultado
[19:57] (m2) particularmente difícil de lograr, sin ir más lejos, ATI.
[19:58] (m2) La otra ventaja que tiene envidia a nivel de diseño e implementación
[19:58] (m2) es que cuenta entre sus empleados a varios desarrolladores
[19:58] (m2) originales de hardwara para SGI y los correspondientes drivers.
[19:58] (m2)
[19:59] (m2) De hecho algo que resulta preocupante (si uno tiene equipo de SGI)
[19:59] (m2) es que las tarjetas de NVIDIA se comparan favorablemente con
[19:59] (m2) las soluciones "low" y "mid-end" de SGI.
[19:59] (m2)
[19:59] (m2) En términos de *extensiones* NVIDIA tiene puntos a favor y puntos
[19:59] (m2) en contra.... pero eso es otra historia.
[19:59] (m2)
[20:00] (m2) Mi otra queja con respecto a esto es que NVIDIA es particularmente
[20:00] (m2) hermética para con los desarrolladores, lo cual introduce dificultades
[20:01] (m2) a varios niveles. Y para terminar este rant, los drivers de
[20:01] (m2) NVIDIA carecen de un ambiente de desarrollo completo.
[20:01] (m2)
[20:01] (m2) *sigh*
[20:01] (m2)
[20:01] (m2) * Xi Graphics ofrece soporte para diversas tarjetas como parte de
[20:01] (m2) su paquete de X Windows. Dentro de los chipsets soportados
[20:01] (m2) están el Radeon y Rage 128 de ATI, Oxygen y Permedia de
[20:01] (m2) 3Dlabs, Lighting y Tornado de E&S, Voodoo 3 de 3Dfx, G400 de
[20:01] (m2) Matrox, y Savage 4 de S3.
[20:01] (m2)
[20:02] (m2) Últimamente he tenido experiencia con los drivers de XiG para
[20:02] (m2) Radeon, y debo decir que es simplemente sorprendente lo que
[20:02] (m2) el chip puede hacer.
[20:02] (m2) Se compara favorablemente con máquinas tales como Octane
[20:02] (m2) y Octane2 de SGI en términos de texturas en 3D, una cosa
[20:03] (m2) de particular importante en, para nombrar solo un ejemplo,
[20:03] (m2) aplicaciones médicas.
[20:03] (m2)
[20:03] (m2) * Metrolink ofrece también drivers para una gama similar de
[20:03] (m2) productos
[20:03] (m2)
[20:04] (m2) Los drivers de Metrolink nunca los he utilizado así que no tengo una
[20:04] (m2) opinión en ningún sentido respecto a ellos, pero supongo
[20:04] (m2) que deben ser similares a los de XiG.
[20:04] (m2)
[20:04] (m2) Volviendo a XiG, lo molesto de sus drivers que es son eso
[20:05] (m2) nada más: drivers. Por el contrario, en términos de la calidad
[20:05] (m2) de la implementación de XFree86, XFree86 gana por mucho.
[20:05] (m2) Es mucho más configurable, más fácil de entender, y se ve
[20:06] (m2) en general más pulido. Además XFree86 4.0 con su nueva estrategia
[20:06] (m2) para las extensiones de X es mucho más extensible que las
[20:06] (m2) otras ofertas.
[20:06] (m2) Sobra decir que el equipo de desarrolladores de XFree86 supera
[20:06] (m2) por uno o dos órdenes de magnitud al de XiG/Metrolink
[20:06] (m2)
[20:07] (m2) Quizás alguno por aquí ha visto los anuncios de Metrolink en
[20:07] (m2) el Linux Journal, donde en algún momento decían que su
[20:07] (m2) implementación era mejor que la de XFree86. Quizás eso
[20:07] (m2) sería cierto para un grupo reducido de personas con necesidades
[20:08] (m2) particulares, pero yo personalmente dudo que siga siendo cierto hoy
[20:08] (m2) en día.
[20:08] (m2)
[20:08] (m2) Y aquí entonces en donde llego a la parte que a mí más me interesa
[20:08] (m2) por mi trabajo en la Universidad.
[20:08] (m2)
[20:09] (m2) Las posibilidades de extensibilidad que ofrece XFree86 respecto
[20:09] (m2) a sus contrapartes comerciales representan para mí la ventaja
[20:09] (m2) más grande que este proyecto tiene.
[20:09] (m2)
[20:10] (m2) Antes mencioné GLX. Al igual que OpenGL, la especificación de
[20:10] (m2) GLX a pasado por varias revisiones. La especificación actual
[20:10] (m2) es la 1.3 que alguien mencionaba antes (la versión actual
[20:11] (m2) de OpenGL es 1.2.1) pero la versión implementada por el código
[20:11] (m2) liberado por SGI es la 1.2. ¿Cuál es la diferencia?
[20:11] (m2) Una característica bastante obscura introducida hace bastante tiempo
[20:11] (m2) en la implementación en SGI/IRIX, a saber los llamados PBuffers.
[20:12] (m2) Un PBuffer (Pixel/Picture Buffer) es una región de memoria en
[20:12] (m2) el adaptador gráfico donde se puede generar una imagen, *aprovechando*
[20:12] (m2) el hardware de aceleración de la máquina. La implementación es
[20:13] (m2) relativamente sencilla excepto por un par de detalles que complican
[20:13] (m2) todo el asuto y que es lo que yo estoy haciendo en este momento
[20:13] (m2) (pero que he tenido que posponer un poco por otras cosas en la
[20:13] (m2) Universidad).
[20:13] (m2) ¿Para qué quiero yo un PBuffer? Un PBuffer me permite dos cosas
[20:14] (m2) Una es generar imágenes más grandes que la pantalla
[20:14] (m2) Y la otra es generar imágenes remotamente. Algunos conocerán
[20:15] (m2) el "Visualization Server" de SGI. La forma en la que esto se
[20:15] (m2) implementa es utilizando PBuffers. (Y eso será tema de otra conferencia
[20:15] (m2) pues la versión 'sin PBuffers' es la otra cosa en la que
[20:16] (m2) estoy trabajando ahora, pero queda algo de tiempo antes de que
[20:16] (m2) esté finalizado)
[20:16] (m2)
[20:16] (m2) ¿Funciona OpenGL bajo Linux hoy en día? Sí.
[20:16] (m2) ¿Se compara con la funcionalidad de Windows? Sí.
[20:16] (m2) ¿Es mejor? Depende.
[20:17] (m2) Depende de que se quiera hacer exactamente. Por ejemplo, hasta
[20:17] (m2) ahora no hay aún un driver de uso "común" con el cual se puedan
[20:18] (m2) utilizar anteojos para imágenes en estéreo.
[20:18] (m2)
[20:18] (m2) ¿Hace falta trabajo en los drivers? Sí.
[20:19] (m2) ¿Alguna forma de colaborar? Una es el proyecto DRI. Otra es obviamente Mesa.
[20:19] (m2) fin.
[20:19] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:19] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:19] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:19] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:19] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:19] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:19] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:20] (m2) Nada más algunas notas antes de pasar a las preguntas...
[20:20] (m2) En la sección donde yo trabajo se ha desarrollado un programa
[20:20] (Fernand0) plas plas plas plas plas pls plas plas plas
[20:20] (m2) para medir la velocidad de características particulares
[20:20] (Beltzak) PLA PLA PLA PLA PLA pla pla pla pla
[20:20] (m2) de una implementación de OpenGL. Los que tengan interés
[20:21] (m2) pueden visitar http://wwwvis.informatik.uni-stuttgart.de/machtest /
[20:21] (m2) Allí encuentran resultados para varias tarjetas de NVIDIA
[20:21] (m2) así como un par de ATI y una G400.
[20:21] (m2) Si alguien tiene interés en colaborar, es posible enviar
[20:22] (m2) resultados y nosotros los ponemos en las páginas...
[20:22] (m2) :)
[20:22] (m2) gracias
[20:22] (Mapi) plas plas plas plas
[20:22] (Mapi) plas plas plas plas
[20:22] (Mapi) plas plas plas plas
[20:22] (Mapi) plas plas plas plas
[20:22] (Mapi) plas plas plas plas
[20:23] (Fernand0) plas plas plas plas plas pls plas plas plas
[20:23] (Fernand0) plas plas plas plas plas pls plas plas plas
[20:23] (Fernand0) plas plas plas plas plas pls plas plas plas
[20:23] (Fernand0) plas plas plas plas plas pls plas plas plas
[20:23] (Fernand0) plas plas plas plas plas pls plas plas plas
[20:23] (Beltzak) PLAs PLAs PLAs PLAs PLAs plaS plaS plaS plaS
[20:23] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:23] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:23] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:23] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:23] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:23] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:23] (MJesus) 4plas 5plas 6plas 7plas 8plas 9plas 10plas 11plas 12plas 13plas
[20:23] (Beltzak) PLAs PLAs PLAs PLAs PLAs plaS plaS plaS plaS
[20:23] (MJesus) 4clap 5clap 6clap 7clap 8clap 9clap 10clap 11clap 12clap 13clap
[20:23] (Fernand0) preguntas, comentarios ??
[20:23] (debUgo-) yo tengo una algo off-topic
[20:24] (m2) debUgo-?
[20:25] (Beltzak) komo se si realmente tengo bien configurao la aceleracion en las Xfree3.3.x (una 3dfx ;)
[20:25] (debUgo-) que pasa con el rendimiento (aceleración o como quieran llamaro) en 2D? Tengo una Voodoo3 y en linux casi no uso 3d, pero el rendimiento (comparado con Win) es algo quedado
[20:26] (m2) Beltzak: lo más fácil es usar gears (tengo una copia en http://wwwvis.informatik.uni-stuttgart.de/~magallon/gears.c), si te da más de 500/600 frames por segundo, está bien. ~100-150 es lo que una implementación por software logra.
[20:27] (m2) Beltzak: mi G400 da ~ 900 fps y un GeForce2 como ~1400. No sé realmente en qué rango debería estar un Voodoo.
[20:27] (Beltzak) yo tampoko ;)
[20:28] (m2) debUgo- respecto al driver de 3Dfx en 2D no sé realmente. Depende mucho de si se han implementdo todos los puntos de entrada que XFree86 necesita o si se está haciendo todo en software.
[20:28] (m2) debUgo- sin fanatismo, el mejor driver 2D en linux es el de Matrox, todo lo que es posible acelerar está acelerado.
[20:29] (debUgo-) uy, el jefe... me tengo que ir :o(
[20:29] (debUgo-) eso he oido, pero Matrox se queda en 3d frente a otras
[20:29] (debUgo-) y yo no quiero eso
[20:30] (m2) debUgo- si, es una pregunta de que tan rápido es suficientemente rápido. En Q3A mi G400 con un Athlon/500 a 800x600x16 da 60-90 fps.
[20:30] (debUgo-) hmmm...
[20:30] (m2) debUgo- un GeForce2 en los mismos niveles da 10-15% más.
[20:30] (m2) con un P3/500.
[20:31] (m2) hay niveles (donde hay que subir y bajar muchas texturas de la/hacia la tarjeta donde la velocidad se cae hasta 40-50 fps)
[20:31] (debUgo-) y las distintas interfaces (PCI, AGP 1/2/4x), si hacen diferencia (sustancial)?
[20:31] (m2) mientras que el GeForce2 se mantiene en el mismo rango.
[20:32] (m2) debUgo- para geometría, no. Para texturas/imágenes, sí.
[20:32] (debUgo-) lo de la caida, se puede deber al ancho de banda que maneja la tarjeta no? IIRC, GF2 tiene DDR-SDRAM a 128 bits
[20:32] (debUgo-) aunque ni idea que maneje Matrox
[20:33] (m2) debUgo- hay varios factores, primero, ¿qué tantas texturas deben estar residentes? Unreal Tournament es particularmente sensible a esto.
[20:33] * Beltzak p___ unreal :(
[20:33] (m2) debUgo- exacto, las tarjetas de Matrox están por debajo de las GeForce respecto a la velocidad de transferencia hacia la tarjeta...
[20:34] (debUgo-) es decir chipset-video ram
[20:35] (debUgo-) bueh, ahora si me fui que el jefe me está mirando feo...
[20:35] (debUgo-) gracias m2
[20:36] (m2) respecto a lo que alguien preguntaba de por qué NVIDIA no libera los drivers, la primera razón que dieron fueron patentes/licencias en la interface AGP, pero luego cambiaron el motivo a "proteger propiedad intelectual"
[20:36] (FuL) toma
[20:36] (FuL) ups
[20:37] (m2) (Beltzak) para usar DRI es necesario un kernel superior a 2.3.5?¿ no ,lo lei
[20:37] (m2) en una revista
[20:37] (m2) No, el módulo de drm funciona tanto con 2.2 como con 2.4.
[20:38] (m2) De hecho es más problemático con 2.4 pues no hay forma de diferenciar entre 2.4.0-test1 y 2.4.0-test12, así que si usas 2.4 tienes que usar 2.4.0-test(lo último que exista)
[20:40] (MJesus) bueno, mas preguntas ?
[20:41] (Beltzak) perdon
[20:41] (Fernand0) Seguro que las hay mjesus
[20:41] (Fernand0) pero seguro que también es un buen momento
[20:41] (Beltzak) esque yo he hablao en #qc ;)
[20:41] (m2) Beltzak: leí hoy en Gareth Hughes estaba muy alegre pues la instalación de UT es más fácil. Mira en loki, tal vez hay algo nuevo...
[20:41] (Fernand0) para agradecer al conferenciante y a todos ustedes
[20:41] (m2) s/en/que/
[20:41] (Fernand0) su presencia aqui
[20:42] (MJesus) magaly, va a preguntar
[20:42] (magaly) 5?
[20:42] (MJesus) adelante
[20:43] (magaly) si mi pregunta es que significa DRI?
[20:44] (m2) magaly: Direct Rendering Interface
[20:44] (Beltzak) ?
[20:44] (m2) se refiere a que el cliente tiene acceso directo al hardware
[20:44] (m2) contrario al caso donde se debe codificar los comandos de OpenGL
[20:45] (m2) dentro de un stream de GLX que el servidor decodifica y ejecuta.
[20:45] (m2) En GLX existen dos modos: Directo e Indirecto.
[20:45] (magaly) y cual es su proposito o funcion?
[20:45] (m2) Idealmente los clientes locales usan el modo directo y los clientes
[20:46] (m2) remotos usan el modo indirecto. Es posible que los clientes
[20:46] (m2) locales usen el modo indirecto por diversas razones (falta de recursos
[20:46] (m2) por ejemplo).
[20:46] (Beltzak) DRI es una posible alternativa a directX, tendremos juegos comerciales en linux, en un futuro no muy lejano?¿ ;)
[20:46] (m2) En el modo directo, lo que DRI implementa, el cliente accede y se comunica directamente con
[20:47] (m2) el adaptador gráfico. Eso quiere decir que el servidor de X
[20:47] (m2) no está medio limitando la velocidad de comunicación.
[20:47] (m2) Para que esto funcione es necesario tener un árbitro que diga
[20:47] (m2) cuando el servidor de X puede hablarle a la tarjeta y cuando
[20:47] (m2) lo puede hacer el cliente.
[20:48] (m2) Además es necesario manejar los recursos en la tarjeta (memoria, entrada y salida, etc)
[20:48] (m2) Todo esto unido es lo que se ha implementado para XFree86 con el nombre de DRI.
[20:49] (m2) DRI son entonces varios componentes: un driver en el servidor, una biblioteca en el servidor y el cliente y un módulo en el kernel.
[20:49] (m2) Beltzak: apt-get install glutg3-dev
[20:50] (m2) y luego:
[20:50] (m2) cc -o gears gears.c -lglut
[20:51] (Beltzak) thX m2
[20:53] (MJesus) mas preguntas ??
[20:53] (MJesus) mas preguntas ??
[20:53] (Beltzak) una mas por mi parte
[20:53] (Beltzak) ;)
[20:54] (magaly) muchas gracias por aclarar mi duda su respuesta fue muy extensa
[20:54] (magaly) e importante, gracas
[20:54] (Beltzak) m2 segun he entendido el tener un gestor o otro da exactamente igual para la aceleracion sea correcta no?
[20:55] (m2) Beltzak: si, da igual. En principio.
[20:55] (m2) Beltzak: recientemente en el diseño del DRI se introdujo el concepto de "pantalla completa"
[20:55] (m2) mediante el cual se bloquea el acceso de los clientes 2D a la tarjeta
[20:56] (m2) gráfica en caso de que exista una aplicación en modo directo usando la pantalla completa (es decir: un juego)
[20:56] (Beltzak) ok
[20:56] (m2) esto es bueno por ejemplo si tienes algún monitor de actividad/red o un reloj o algo que cambia en forma constante.
[20:57] (m2) No me sorprendería que E haga algún tipo de desastre similar...
[20:58] (Beltzak) E?¿
[20:59] (m2) Enlightenment
[20:59] (Beltzak) ahp
[20:59] (Beltzak) ;)
[21:00] (Beltzak) nada pos gracias por mi parte yo he acabado de preguntar ;)
[21:01] (MJesus) mas preguntas ??
[21:01] (MJesus) mas preguntas ??
[21:02] (MJesus) Bueno, me parece que quedan muchas cosas interesantes que comentar, pero llevamos ya casi dos horas
[21:02] (MJesus) con marcelo, que debemos tenerle exhausto,
[21:02] (MJesus) Muchisimas gracias Marcelo!
[21:03] (m2) MJesus: :) Quería agradecer por la invitación, realmente me ha gustado la experiencia.
[21:03] (MJesus) y queriamos pedirle que nos de su palabra de acudir a la proxima edicion de Umeet
[21:03] (Beltzak) Mil gracias ;)
[21:03] (MJesus) el año que viene,
[21:04] (m2) MJesus: por supuesto. Para la próxima espero poder entonces hablar sobre "Visualización distribuída bajo Linux" ;-)
[21:04] (MJesus) de verdad que ha sido gratisimo: con estos son ya dos los chilenos que han edjado el pabellon de su ais muy muy alto
Y seguimos un buen rato más charlando...

Contact: