Ir al contenido
Conéctate para seguir esto  
Shiba87

La implementación Wayland de Nvidia no es bien recibida por la comunidad

Recommended Posts

uPMPic0.png

 

Aunque hace tiempo que me decidí por no sucumbir a polémicas a la hora de escribir, en este caso quiero hacer una excepción, porque es un tema que nos llega de cerca a muchos y que podría ser decisivo para el futuro de los entornos gráficos en GNU/Linux

 

Hace muy poco, Nvidia liberó por fin una nueva serie de controladores que, no sólo nos traían Vulkan de manera estable y completamente funcional, sino que nos brindaban soporte para el servidor gráfico Wayland a través de EGL. Algo que llevábamos esperando desde hace ya mucho tiempo.

 

Sin embargo, aunque en principio esta noticia sobre Nvidia suponía un salto importante a la hora de empezar a adoptar masivamente el servidor gráfico Wayland, dejando por fin "de lado" al veterano X11, junto a los controladores oficiales se han liberado una serie de parches de código abierto, que fueron enviados a la comunidad de desarrolladores de Wayland, que no han sido visto con buenos ojos por parte de los desarrolladores del servidor gráfico.

 

In order to make the Weston DRM compositor work with our drivers, wehave used EGLDevice, EGLOutput, and EGLStream objects.For those not familiar with this set of EGL structures, here I try tosummarize the most important part of them, and how would they fit inthe current Weston DRM compositor design:    EGLDevice provides means to enumerate native devices, and then    create an EGL display connection from them.    Similarly, EGLOutput will provide means to access different    portions of display control hardware associated with an EGLDevice.    For instance, EGLOutputLayer represents a portion of display    control hardware that accepts an image as input and processes it    for presentation on a display device.    EGLStream implements a mechanism to communicate frame producers and    frame consumers. By attaching an EGLOutputLayer consumer to a    stream, a producer will be able to present frames on a display    device.    Thus, a compositor could produce frames and feed them to an    EGLOutputLayer through an EGLStream for presentation on a display    device.    In a similar way, by attaching a GLTexture consumer to a stream, a    producer (wayland client) could feed frames to a texture, which in    turn can be used by a compositor to prepare the final frame to be    presented.    Whenever EGL_EXT_device_drm extension is present, EGLDevice can    be used to enumerate and access DRM KMS devices, and EGLOutputLayer    to enumerate and access DRM KMS crtcs and planes.    By using EGLStreams and attaching an EGLOutputLayer consumer    (representing a DRM KMS crtc or plane) to it, compositor-drm can    produce final composition frames and present them on a DRM device.

 

Este código, pensado en principio para permitir que Weston, el compositor base de Wayland pueda correr sobre los controladores gráficos oficiales de Nvidia (privativos), ha sido rechazado.

 

El origen de la polémica parece ser la implementación que ha hecho Nvidia, pues se valen directamente de EGL, haciendo uso de las extensiones EGLDevice y EGLStreams para manejar los buffers, mientras que la implementación oficial de Weston utiliza MESA GBM (Generic Buffer Manager).

Si bien para algunos, incluida la propia Nvidia, esta aproximación supone un acercamiento más "agnóstico", en lugar de tener que desarrollar una versión alternativa de GBM para su línea de controladores, desde el otro lado sólo ven problemas con la alternativa propuesta por la californiana, al hacer uso de extensiones poco usuales o complicar/simplificar demasiado ciertos aspectos del renderizado.

 

Aunque en principio esto no impide que entornos con compositores propios, como Enlightenment, Hawaii, Orbital, Orbment o incluso alguno de los más conocidos como KDE O Gnome, puedan dar soporte a Nvidia, implementándolo por cuenta propia en sus compositores, dentro del seno de Wayland y de cara al compositor Weston, por ahora las cosas están siendo discutidas de manera muy acalorada y no parece que veamos pronto ningún movimiento, al menos hasta que todos los pormenores hayan sido hablados y el código de Nvidia minuciosamente estudiado.

 

https://lists.freedesktop.org/archives/wayland-devel/2016-March/027547.html

Compartir este post


Enlace al post
Compartir en otros sitios

Nvidia libera la primera versión estable de la serie 364.

Con pocos cambios con respecto a las versiones beta al mergen del soporte para dos nuevas GPUs y numerosas correcciones.

 

Lamentablemente la polémica sigue en torno a la implementación Wayland de Nvidia y parece que los desarrolladores de la comunidad y los de la californiana están lejos de llegar al entendimiento.

Al mismo tiempo ha surgido, como no, el FUD. Algunos se aventuran a asegurar que a pesar de haberlo anunciado, es mentira que los controladores de Nvidia cuenten con soporte para Wayland, algo completamente falso. Los controladores son plénamente funionales y, a partir de la 364.19, también estables. El problema no radica en los controladores ahora mismo, sino en la interacción entre estos y los compositores de los distintos entornos gráficos/gestores de ventanas, que no han sido diseñados para funcionar con EGL sino a través de MESA GBM.

 

La versión de Weston parcheada por la propia Nvidia corre sin problemas y al mismo nivel que su equivalente GBM.

 

Nos encontramos ante una situación delicada, porque al contrario que en otras ocasiones, se han desarrollado dos modelos igualmente libres, a la par que competentes, pero que se encuentran en extremos opuestos.

 

La comunidad lleva años trabajando en Wayland centrándose exclusivamente en los controladores MESA, no sólo en lo que respecta al driver, sino también en todo lo demás, componentes gráficos de entornos y gestores, por lo que el cambio de paradigma que plantea Nvidia supone, en cierta manera, volver a empezar para llegar de nuevo al mismo punto al que ya habían llegado con GBM.

 

Por su parte, Nvidia ha obtado por un estándar, EGL, como solución más "agnóstica" y acorde con sus controladores. La opción de cambiar esto por GBM supondría no sólo un cambio profundo en los controladores a nivel de kernel, sino un gran problema legal debido a una incompatibilidad de licencias.

 

Como vemos, en este caso el problema es que las dos partes tiene razón :sweat:

 

Por ahora, lo más probable a corto/medio plazo sea, probablemente, que los distintos compositores incluyan, de forma paralela, EGL junto a GBM. Pero esto dependerá de la buena voluntad y las posibilidades de los desarrolladores de cada entorno.

Compartir este post


Enlace al post
Compartir en otros sitios

 

Como vemos, en este caso el problema es que las dos partes tiene razón :sweat:

 

Por ahora, lo más probable a corto/medio plazo sea, probablemente, que los distintos compositores incluyan, de forma paralela, EGL junto a GBM. Pero esto dependerá de la buena voluntad y las posibilidades de los desarrolladores de cada entorno.

 

y entre medias como siempre los pobrecitos usuarios... :( :(

Compartir este post


Enlace al post
Compartir en otros sitios

Según lo que ha ido apareciendo en Phoronix, la opinión desde el lado de los desarrolladores de la comunidad viene siendo más o menos la siguiente:

En esencia, los desarrolladores actuales de Wayland se oponen fuertemente a todo lo relacionado con EGLStreams por la premisa que no tiene sentido más allá de que Nvidia tenga su propia API, la cual tendrá que ser implementada por todo el mundo sobre GBM. Uno podría decir que es algo equivalente a su módulo del kernel en el espacio de usuario, excepto porque ahora ellos están afirmando que es lo que todos los fabricantes deberían estar utilizando en lugar de lo que actualmente se utiliza, suponiendo más trabajo para todos sin ningún beneficio real.

Es una situación un poco delicada porque Nvidia bien podría decidir seguir con EGLStream independientemente de lo que la comunidad quiera, porque saben que todos deberían dar soporte a su hardware con el fin de satisfacer las demandas de sus usuarios, ya que ellos tienen productos muy populares y una gran cuota de mercado en mundo de los equipos GNU/Linux de escritorio.

 

Mike Blumenkrantz y Carsten Haitzler, desarrolladores de Enlightenment amplían un poco esta idea.

Están proponiendo usar su implementación "Stream-based" que podría existir en paralelo con el estándar actual (y universalmente utilizado) GBM. ¿De manera adicional, para correr en un marca específica de hardware, todos los autores de toolkits y compositores necesitarían implementar la funcionalidad streams propuesta, de otra manera sólo estará disponible el renderizado por software?

Es verdad que resulta un poco extraño para mí que, a pesar de seguir hablando en términos hipotéticos acerca del futuro desarrollo tanto para GBM como para Streams, que estén indicando que GBM no puede mejorar para alcanzar la funcionalidad de la nueva propuesta y estén, en su lugar, instando a todos los que ya han desarrollado el soporte para GBM que ahora también soporten streams. Como alguien con más que un interés casual, tanto en toolkits como compositores, no estoy demasiado entusiasmado con alguien que exige incluso más trabajo de parte de aquellos que desarrollan toolkits y compositores, especialmente cuando el soporte "completo" para Wayland es ya de por sí una enorme empresa.

https://lists.freedesktop.org/archives/wayland-devel/2016-May/028810.html

 

Aún sin tener todos los detalles, de estas palabras podemos añadir algo a lo que ya habíamos comentado anteriormente:

Nvidia ha propuesto un enfoque totalmente diferente después de que todo el mundo hubiera apostado por GBM y, sin bien podemos leer alguna insinuación sobre que Nvidia podría tener razón y EGLStreams ser una solución superior al "estándar" actual, empezar de nuevo o mantener ambos enfoques en paralelo dicen que significaría demasiado trabajo y sería preferible apostar por mejorar GBM y su implementación antes que reinventar la rueda.

 

 

Personalmente y, aunque tampoco puedo hablar con plenos conocimientos sobre el asunto, si bien entiendo a ambos bandos, creo que en esta ocasión la pelota está en el campo de la comunidad, quien decidirá lo que finalmente ocurre, pero para variar, es Nvidia quien tendría la razón en este caso.

Si realmente EGLStreams es una solución superior y agnóstica, como Nvidia afirmó desde un primer momento, dado Que Wayland ahora mismo sigue en pleno desarrollo y no se utiliza más que de manera anecdótica o experimental ¿Qué mejor momento que ahora para plantearse un cambio como el de EGLStreams?

Podríamos pensar en el resto de fabricantes de tarjetas gráficas que también tendrán que hacer cambios, pero teniendo en cuenta que AMD ya no desarrolla Catalyst y que la comunidad, está apenas empezando a moverse con los AMDGPU e, independientemente de lo que finalmente suceda, estos tendrán que ser profundamente modificados, realmente daría igual.

Atarnos a GBM sólo porque es como se planteó inicialmente si, realmente EGLStream supone una mejora, me parecería un error.

Pero insisto, aún hay muchas cosas que se me escapan en cuanto a la complejidad de todo este asunto y lo que supondría hacer este cambio en compositores, entornos y herramientas, así que nos queda una larga espera que terminará, como siempre, con más polémica :sweat:

Compartir este post


Enlace al post
Compartir en otros sitios

Yo tampoco entiendoentiendo,  a mi modo de ver personal,  esto debería desarrollarse por la opción más "potente" y dejarse  de intentar decir,  esto es mio.  Como dice rohilling. 

 

A ver q pasa al final por q lo único malo para nosotros los usuarios es q nidia se niegue a hacerlos de la otra manera :(

Compartir este post


Enlace al post
Compartir en otros sitios

Yo tampoco entiendoentiendo,  a mi modo de ver personal,  esto debería desarrollarse por la opción más "potente" y dejarse  de intentar decir,  esto es mio.  Como dice rohilling. 

 

A ver q pasa al final por q lo único malo para nosotros los usuarios es q nidia se niegue a hacerlos de la otra manera :(

GBM es exclusivo de los controladores MESA. Nvidia, por tema de licencias, no podría hacerlo de otra manera y, en cuanto a la parte técnica, les supondría a ellos tener que reinventar la rueda.

Por eso precisamente pensaron en una solución basada en un estándar como EGL.

 

Lo mire por donde lo mire, yo lo único que veo es un callejón sin salida. O Nvidia se replantea su existencia y reinventa sus drivers para GBM o los desarrolladores de Wayland se bajan del burro e implementan la solución de Nvidia.

No hay un punto intermedio que pueda servir a ambos :muro:

Compartir este post


Enlace al post
Compartir en otros sitios

Ya. Pero hablamos de gente que lleva 4 años trabajando con GBM, para que ahora llegue alguien de fuera y les diga: "¡Oye! Que lo has estado haciendo mal, vuelve a empezar porque es mejor hacerlo de esta forma"
Eso también hay que entenderlo :sweat:

 

Yo, de momento, veo que la gente de Wayland se lo va a pasar por el forro, Nvidia tampoco va a replantear los drivers y serán los entornos y gestores de ventanas los que cedan. Bien metiendo en paralelo los dos enfoques o con capas de abstracción una sobre otra para ofrecer compatibilidad a costa de rendimiento: Wayland -> EGL -> GBM -> KMS -> Driver

 

En lugar del Wayland -> EGL -> Driver que, al parecer, estiman que supone un 10% de rendimiento extra en arquitecturas antiguas y bastante más en las nuevas.

Pero claro ¿Quién le pone el cascabel al gato? :icon_ouch:

Compartir este post


Enlace al post
Compartir en otros sitios

Integrada, sí. Dedicada... es pagar mucho más por bastante menos. A corto plazo, es más probable que Nvidia resuelva el tema Wayland, que AMD ofrezca controladores gráficos funcionales.

En cualquiera de los dos casos, yo esperaría a ver cómo evoluciona, tanto EGL/Wayland, como AMDGPU.

Y de no poder esperar, de gastar dinero en una gráfica, en cuanto a coste/desempeño, las Radeon no son una opción viable :sweat:

Compartir este post


Enlace al post
Compartir en otros sitios

Integrada, sí. Dedicada... es pagar mucho más por bastante menos. A corto plazo, es más probable que Nvidia resuelva el tema Wayland, que AMD ofrezca controladores gráficos funcionales.

En cualquiera de los dos casos, yo esperaría a ver cómo evoluciona, tanto EGL/Wayland, como AMDGPU.

Y de no poder esperar, de gastar dinero en una gráfica, en cuanto a coste/desempeño, las Radeon no son una opción viable :sweat:

nvidia ya me enojo 2 veces, primero con wayland y segundo con vulkan para fermi

Compartir este post


Enlace al post
Compartir en otros sitios

Lo de Fermi no tiene perdón ni excusa de ninguna clase, fue una jugada sucia y a traición, pero en cuanto a Wayland, quien realmente ha "cumplido" ha sido únicamente Intel. Nvidia lo ha intentado yendo por otro camino y se ha encontrado con un muro y AMD no ha hecho absolutamente nada. Se ha encontrado el trabajo ya hecho por la comunidad a la que primero no hacían ni puñetero caso y ahora se aprovechan de su trabajo (que no es que esté mal, simplemente no ha sido gracias a AMD que los controladores actuales medio funcionan, sino todo lo contrario).

 

Otra cosa que a mí me tiene con la mosca detrás de la oreja es que, ahora mismo, AMD es el mayor promotor de  Dx12, con Vulkan relegado a un segundo plano, mientras que Nvidia es quien está impulsando Vulkan y dejando Dx olvidado (seguro que algún cerdo ha empezado a volar y hay por ahí alguna rana hipster).

Hay un toma y daca muy muy raro y se están invirtiendo papeles en muchos aspectos.

Hasta que AMD no tenga controladores funcionales, como llevan años y años diciendo, sin resultados, conmigo que no cuenten.

Y hasta que no vea las cartas que piensa jugar Nvidia y los movimientos que pretenden hacer, pasarán un par de arquitecturas hasta que me decida a renovar componentes.

Compartir este post


Enlace al post
Compartir en otros sitios

Lo de Fermi no tiene perdón ni excusa de ninguna clase, fue una jugada sucia y a traición, pero en cuanto a Wayland, quien realmente ha "cumplido" ha sido únicamente Intel. Nvidia lo ha intentado yendo por otro camino y se ha encontrado con un muro y AMD no ha hecho absolutamente nada. Se ha encontrado el trabajo ya hecho por la comunidad a la que primero no hacían ni puñetero caso y ahora se aprovechan de su trabajo (que no es que esté mal, simplemente no ha sido gracias a AMD que los controladores actuales medio funcionan, sino todo lo contrario).

digamos que lo de wayland se puede dejar pasar.. aunque como has dicho lo de fermi es imperdonable 

 

Otra cosa que a mí me tiene con la mosca detrás de la oreja es que, ahora mismo, AMD es el mayor promotor de  Dx12, con Vulkan relegado a un segundo plano, mientras que Nvidia es quien está impulsando Vulkan y dejando Dx olvidado (seguro que algún cerdo ha empezado a volar y hay por ahí alguna rana hipster).

Hay un toma y daca muy muy raro y se están invirtiendo papeles en muchos aspectos.

Hasta que AMD no tenga controladores funcionales, como llevan años y años diciendo, sin resultados, conmigo que no cuenten.

Y hasta que no vea las cartas que piensa jugar Nvidia y los movimientos que pretenden hacer, pasarán un par de arquitecturas hasta que me decida a renovar componentes.

yo igual voy a seguir usando la PC con la placa de video que tengo actualmente por el futuro medianamente cercano, no tengo un mango partido al medio

Compartir este post


Enlace al post
Compartir en otros sitios

Por su parte, Nvidia ha obtado por un estándar, EGL, como solución más "agnóstica" y acorde con sus controladores. La opción de cambiar esto por GBM supondría no sólo un cambio profundo en los controladores a nivel de kernel, sino un gran problema legal debido a una incompatibilidad de licencias.

 

 

Y eso de solución "agnóstica", ¿ Qué rayos quiere decir? :wacko:

Compartir este post


Enlace al post
Compartir en otros sitios

Del Griego A- (sin) gnōsis (conocimiento), en un entorno tecnológico se traduce como la habilidad de algo de funcionar "sin" conocer los detalles subyacentes del sistema con el que se trabaja.
Esta interoperatibilidad es típicamente el resultado del uso de estándares o elementos añadidos (como pueden ser capas de abstracción)  que permitirían llevar a cabo la función objetivo en una gran variedad de entornos diferentes.

 

:silba:

Compartir este post


Enlace al post
Compartir en otros sitios

Del Griego A- (sin) gnōsis (conocimiento), en un entorno tecnológico se traduce como la habilidad de algo de funcionar "sin" conocer los detalles subyacentes del sistema con el que se trabaja.

Esta interoperatibilidad es típicamente el resultado del uso de estándares o elementos añadidos (como pueden ser capas de abstracción)  que permitirían llevar a cabo la función objetivo en una gran variedad de entornos diferentes.

 

:silba:

Gracias por la aclaración porque en la RAE no dicen nada de esto. De ahora en adelante, cuando diga, soy agnóstico, tengo que aclarar después, pero no desde un punto de vista tecnológico. :wacko:

 

Pero yendo al meollo de la cuestión, ¿ Alguien ha conseguido que le funcione? Yo uso KDE y cuando le doy a iniciar sesión en plasma(wayland), después de un par de segundos, vuelve a la pantalla de selección de sesión (sddm). No he investigado demasiado a ver qué falla porque dudo que consiguiera llegar a ninguna conclusión

Compartir este post


Enlace al post
Compartir en otros sitios

Sonará extraño, pero sigue siendo Nvidia la que insiste en dar solución al problema y ya está planteada una gran reunión entre todos los implicados para el próximo mes de septiembre, aprovechando el marco del multitudinario XDC (X.org Developers Conference) a celebrar en Helsinki.

 

Según he podido "entender" a partir de las noticias de los blogs alemanes, la idea que van a plantear parte de una línea similar a la de GLVND, la ABI que permite la coexistencia de distintas librerías OpenGL de diferentes fabricantes de manera simultánea, mediando y resolviendo las llamadas a la API OpenGL. Sólo que en este caso no hablaríamos de librerías OpenGL, sino de APIs para el manejo del buffer como GBM, EGLStreams o Gralloc, utilizadas por los controladores MESA, Nvidia o Android, respectivamente. De tal manera que puedan coexistir, sin tener que atar a todos los desarrolladores a una única API, que si bien puede ser abierta, supone un ecosistema totalmente cerrado y exclusivo.

 

http://www.golem.de/news/linux-nvidia-ist-bereit-fuer-einheitliche-wayland-unterstuetzung-1607-122294.html

Compartir este post


Enlace al post
Compartir en otros sitios

A mi criterio, si uno ya lleva mucho tiempo en Linux o bien va a comenzar y esta decidido permanecer utilizandolo, creo que la decision mas sabia es huirle a Nvidia.

 

Que opinan?. En mi caso tradicionalmente venia usando AMD , pase por 2 APU's (no el de quickmart) y en el ultimo cambio de hardware , despues de muchos años , regrese a Intel , en gran parte por la diferencia de performance y tambien por el video integrado con drivers que son plug&play , si no jugas a nada debe ser la mejor opcion. AMD creo estan haciendo las cosas bastante bien , ahora bien el tema wayland, a mi modo de ver, aun esta verde y no me seria nada extraño que cuando todas las distros lo incluyan por default va a traer problemas varios, como siempre sucede con las nuevas tecnologias .

Compartir este post


Enlace al post
Compartir en otros sitios

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Invitado
Responder en este tema...

×   Has incluido contenido con formato.   Eliminar formato

  Sólo se permiten 75 emoticonos como máximo.

×   Tu enlace ha sido insertado automáticamente.   Deshacer y mostrar como enlace

×   Su contenido anterior ha sido restaurado.   Limpiar editor

×   No puedes pegar imágenes directamente. Súbelas a algún hosting de imágenes y pega la dirección URL

Conéctate para seguir esto  

×
×
  • Crear Nuevo...