Mesa , también llamado Mesa3D y Mesa 3D Graphics Library , es una implementación de código abierto de OpenGL , Vulkan y otras especificaciones de API de gráficos . Mesa traduce estas especificaciones a controladores de hardware de gráficos específicos del proveedor.
Sus usuarios más importantes son dos controladores de gráficos desarrollados y financiados principalmente por Intel y AMD para sus respectivos hardware (AMD promociona sus controladores Mesa Radeon y RadeonSI sobre el obsoleto AMD Catalyst , e Intel solo ha admitido el controlador Mesa). Los controladores de gráficos propietarios (por ejemplo, el controlador Nvidia GeForce y Catalyst) reemplazan todo Mesa y proporcionan su propia implementación de una API de gráficos. Un esfuerzo de código abierto para escribir un controlador Mesa Nvidia llamado Nouveau es desarrollado principalmente por la comunidad.
Además de las aplicaciones 3D como los juegos, los servidores de visualización modernos ( Glamour de X.org o Weston de Wayland ) utilizan OpenGL/ EGL ; por lo tanto, todos los gráficos normalmente pasan por Mesa.
Mesa está alojada en freedesktop.org y fue iniciada en agosto de 1993 por Brian Paul , quien todavía está activo en el proyecto. Posteriormente, Mesa fue ampliamente adoptado y ahora contiene numerosas contribuciones de varios individuos y corporaciones de todo el mundo, incluidos los fabricantes de hardware gráfico del Grupo Khronos que administran la especificación OpenGL. Para Linux, el desarrollo también ha sido impulsado en parte por el crowdfunding . [3]
Mesa es conocida por albergar implementaciones de API gráficas . Históricamente la principal API que Mesa ha implementado es OpenGL , junto con otras especificaciones relacionadas con Khronos Group (como OpenVG , OpenGL ES o recientemente EGL ). Pero Mesa puede implementar otras API y de hecho lo hizo con Glide (obsoleto) y Direct3D 9 desde julio de 2013. [5] Mesa tampoco es específico de sistemas operativos tipo Unix: en Windows, por ejemplo, Mesa proporciona una API OpenGL sobre DirectX.
Mesa implementa una capa de traducción entre una API de gráficos como OpenGL y los controladores de hardware de gráficos en el kernel del sistema operativo. La versión soportada de las diferentes API gráficas depende del controlador, porque cada controlador de hardware tiene su propia implementación (y por tanto estado). Esto es especialmente cierto para los controladores "clásicos", mientras que los controladores Gallium3D comparten un código común que tiende a homogeneizar las extensiones y versiones compatibles.
Mesa mantiene una matriz de soporte con el estado de conformidad actual de OpenGL [6] [7] visualizada en mesamatrix.net . Mesa 10 cumple con OpenGL 3.3 para hardware de GPU Intel, AMD/ATI y Nvidia. Mesa 11 se anunció con algunos controladores compatibles con OpenGL 4.1. [8]
Mesa 12 contiene soporte para OpenGL 4.2 y 4.3 e Intel Vulkan 1.0.
Mesa 13 brindó soporte de Intel para OpenGL 4.4 y 4.5 (todas las funciones compatibles con Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), pero no Khronos-Test para 4.5-Label) y soporte experimental para AMD Vulkan 1.0 a través del controlador comunitario RADV. OpenGL ES 3.2 es posible con Intel Skylake (Gen9). [9]
La primera versión estable de 2017 es la 17.0 (contando el año nuevo). [10] [11] [12] Las funciones listas están certificadas OpenGL 4.5, OpenGL 4.5 para Intel Haswell, [13] [14] OpenGL 4.3 para Nvidia Maxwell y Pascal (GM107+). [15] Se midió una enorme ganancia de rendimiento con Maxwell 1 (GeForce GTX 750 Ti y más con GM1xx). Las tarjetas Maxwell-2 (GeForce GTX 980 y más con GM2xx) tienen underclocking sin información de Nvidia. [dieciséis]
El conjunto de pruebas Khronos CTS para OpenGL 4.4, 4.5 y OpenGL ES 3.0+ ya está disponible (24/01/2017) en código abierto y todas las pruebas para Mesa 13 y 17 ahora son posibles sin costos. [17]
La segunda versión estable de 2017, 17.1.0, salió el 10 de mayo de 2017 con algunas mejoras interesantes. OpenGL 4.2+ para Intel Ivy Bridge y OpenGL 3.3+ para Intel Open SWR Rasterizer son dos de los aspectos más destacados. [18] [19]
Debido a la naturaleza modularizada de OpenGL, Mesa puede admitir extensiones de versiones más nuevas de OpenGL sin pretender soporte completo para dichas versiones. Por ejemplo, en julio de 2016, Mesa admitía OpenGL ES 3.1 pero también todas las extensiones de OpenGL ES 3.2 excepto cinco, así como una serie de extensiones que no forman parte de ninguna versión de OpenGL u OpenGL ES. [20]
La tercera versión 17.2 está disponible desde septiembre de 2017 con algunas características nuevas de OpenGL 4.6 y mejoras de velocidad en 3D para Intel y AMD. Sólo el 1,4% de las pruebas fallan para OpenGL 4.5 en Nouveau for Kepler. [21]
La cuarta versión 17.3 está lista desde diciembre de 2017. Hay muchas mejoras disponibles en muchos controladores. OpenGL 4.6 está casi completamente disponible (Spir-V no está listo). AMD Vulkan Driver RADV ahora es totalmente compatible con Khronos-Test. [22]
La primera versión de 2018 es 18.0 y está disponible desde marzo de 2018 según el mismo esquema en 2017. [23] La compatibilidad total con OpenGL 4.6 no está lista, pero muchas funciones y mejoras se probaron con éxito en RC3. La compatibilidad con 10 bits para Intel i965 en colores también es un punto destacado. [24] Lo nuevo es el soporte para Intel Cannon Lake y AMD Vega con la versión actual de Linux. Los chips AMD Evergreen (RV800 o R900) están cerca de ser compatibles con OpenGL 4.5. Los chips AMD R600 o RV700 antiguos solo admiten OpenGL 3.3 con algunas características de OpenGL 4.x. Freedreno es el controlador para hardware Adreno y es casi compatible con OpenGL 3.3.
La segunda versión de 2018 es la 18.1 y está disponible desde mayo. El objetivo es Vulkan 1.1.72 en el controlador Intel ANV y AMD RADV. OpenGL 4.6 con spir-V también es el objetivo principal. El trabajo permanente es posible para completar las funciones y optimizar los controladores para hardware antiguo como AMD R600/Evergreen, Nvidia Tesla y anteriores, Fermi, Kepler o Intel Sandybridge, Ivybridge, Haswell o Broadwell. ARM Architecture también realizó grandes mejoras en Adreno 3xx/4xx/5xx y Broadwell VC4/VC5 para Raspi con el objetivo principal OpenGL ES.
La tercera versión de 2018 es la 18.2 y está disponible en el calendario estable en septiembre. OpenGL 4.6 con spir-V y Vulkan 1.1.80 están en WIP. El software Driver para máquinas virtuales VIRGL está listo para OpenGL 4.3 y OpenGL ES 3.2. RadeonSI también está listo para OpenGL ES 3.2. La compatibilidad con la compresión de texturas ASTC y la compatibilidad con el modo de compatibilidad para OpenGL 4.4 (3.1 en 18.1) son otros aspectos destacados de RadeonSI para tarjetas AMD GCN. Nuevo Vulkan 1.1 y más funciones disponibles para Intel y AMD. Ver más detalles de Vulkan en Mesamatrix. [25]
La cuarta versión de 2018 es la 18.3 y se lanzó como versión estable 18.3.1 en diciembre de 2018. Muchas características detalladas y la compatibilidad con hardware más nuevo son las partes principales. La compatibilidad total con OpenGL 4.6 no está lista. [26] [27]
La primera versión de 2019 es la 19.0 y se lanzó en marzo. El soporte completo de OpenGL 4.6 no está listo, pero hay muchas mejoras en este sentido en todos los controladores. [28] [29]
La segunda versión de 2019 es 19.1. La transición de TGSI a NIR es aquí una característica principal en camino a OpenGL 4.6 con Spir-V y más OpenCL. RadeonSI funciona bien en la versión de desarrollo con NIR. [30]
La tercera versión de 2019 es 19.2. OpenGL 4.6 está preparado para la versión Beta del nuevo controlador Intel Iris. [31]
La cuarta versión de 2019 es 19.3. OpenGL 4.6 está listo para Intel i965 y es opcional para el nuevo controlador Iris. [32]
La primera versión de 2020 es 20.0. Vulkan 1.2 está listo para AMD RADV e Intel ANV. Intel Iris es el valor predeterminado para Intel Broadwell Gen 8+. [33] [34] El controlador RadeonSI cambió para usar NIR de forma predeterminada, en lugar de TGSI.
La segunda versión de 2020 es 20.1. Muchas mejoras están listas en muchos controladores. Zink es un nuevo controlador virtual para OpenGL sobre Vulkan. [35]
La tercera versión de 2020 es 20.2. OpenGL 3.0 para Zink es una característica nueva. LLVMpipe admitirá OpenGL 4.3+ (4.5+ en 20.3). ARM Panfrost se ha mejorado principalmente con muchos módulos. La memoria virtual compartida es posible para OpenCL en Nouveau con Pascal y superior. [36] [37] [38]
La cuarta versión de 2020 es 20.3. v3d y v3dv son nuevos controladores para OpenGL y Vulkan 1.0 con hardware Broadcom como Raspberry Pi 4. OpenCL 1.2 es totalmente compatible con el módulo clover. Zink es compatible con OpenGL 3.3+. El controlador virtual LLVMpipe ahora admite OpenGL 4.5+ con 4.6 a la vista. Se fusiona Lavapipe (originalmente llamado Vallium [39] ) como árbol Vulkan de LLVMpipe. [40] [41] [42] [43] [44]
En Mesa 21.0, d3d12 se fusionará con OpenGL 3.0 a 3.3. Microsoft y Collabora desarrollan una nueva emulación d3d12 en WSL2 para Windows 10 con Direct 3D 12. OpenCL 1.2 también está previsto en d3d12. Se realiza una aceleración del factor 2 a 5 en Benchmark SPECviewperf con código OpenGL mejorado. [45] [46] [47] [48] Muchas características de Mesa 21.0 mejoran el rendimiento. [49] La nueva versión 21.0.0 es pública desde el 11 de marzo de 2021.
Mesa 21.1 es la segunda versión del año 2021. [50] OpenGL 4.6+ y OpenGL ES 3.1+ están disponibles para Zink. AMD Driver 600g puede cambiar a NIR con más posibilidades para las antiguas tarjetas Radeeon HD 5000 y 6000. [51] Qualcomm Turnip llega a Vulkan 1.1+ y la emulación de software Lavapipe Vulkan 1.1+. El controlador Venus de GPU VirtIO de Google con Vulkan 1.2+ se fusiona en estado experimental con bajo rendimiento en el árbol principal de mesa. [52]
Mesa 21.2 es la tercera versión del año 2021. Google Virtual Vulkan IO Driver Venus se presentará oficialmente con soporte completo para Vulkan 1.2+ (más mesamatrix). ARM Panfrost: la compatibilidad con OpenGL ES 3.1+ está disponible y panVK es el nuevo controlador Vulkan. Se inició el soporte inicial para ARM Apple M1 con el nuevo controlador Asahi. 21.2 está disponible desde el 4 de agosto de 2021. [53]
Un viejo plan es dividir los controladores antiguos en un árbol clásico con muchas ventajas en programación, soporte y corrección de errores para la parte moderna de galium 3D. Un problema aquí es Intel i965 con soporte de hardware antiguo popular para Intel Haswell y antes también con soporte para Windows 10. [54] Un nuevo controlador Gallium3D Crocus para gráficos Intel Gen 4 para Haswell está aquí en desarrollo para completar aquí el área galium3D con posible división en la próxima época del año 2021. Crocus es opcional y está disponible en 21.2. [55] La rama ámbar es para controladores antiguos sin funciones Gallium 3D como Radeon R200, Intel i915 y 965 con la versión actual 21.3.9. [56]
En la versión 22.0 Classic, los controladores están retirados. Vulkan 1.3 está disponible para Intel Anvil y AMD RADV. [57]
Microsoft presenta el nuevo controlador "Dozen" para WSL 2 en la etapa inicial de desarrollo como Vulkan sobre d3d12 en Mesa 22.1. [58]
RustiCL está disponible en 22.3 con conformidad oficial con OpenCL 3.0 para gráficos Intel XE. El rendimiento es igual y mejor que AMD ROCm con tarjeta AMD 6700 XT. [59] [60]
Uno de los principales objetivos de desarrollo de Mesa 23.0 fue el trazado de rayos para Vulkan. [61] [62]
Microsoft desarrolla el controlador Dozen para Vulkan en WSL. Vulkan 1.0+ con 80% 1.1 y 1.2 estará disponible en Mesa 23.2 después del retraso hasta 23.1 (ver mesamatrix). [63] RustiCL para hardware AMD está disponible en 23.1. [64]
VirGL para máquinas virtuales salta en Mesa 23.2 a OpenGL 4.6. [65] Apple Asahi para Apple Arm Machines salta de OpenGL 2.1 a 3.1 con un 90% de características de OpenGL 3.2 y 3.3 y OpenGL ES 2.0 a 3.0. [66]
Microsoft admite WSL OpenGL 4.6+ en Mesa 24.0 (en Mesa 23.3: 4.3+) con una docena de controladores de traducción directa. [67]
El Grupo Khronos anunció oficialmente la API de Vulkan en marzo de 2015 y lanzó oficialmente Vulkan 1.0 el 16 de febrero de 2016. Vulkan rompe la compatibilidad con OpenGL y abandona por completo su concepto de máquina de estados monolítica. Los desarrolladores de Gallium3D llamaron a Vulkan algo parecido a Gallium3D 2.0: Gallium3D separa el código que implementa la máquina de estado OpenGL del código que es específico del hardware.
La versión 1.3 está disponible inmediatamente con Mesa 22.0. El hardware compatible con OpenGL ES 3.1 debe ejecutarse en el nivel Vulkan 1.3 y anterior. [105]
Mientras Gallium3D ingiere TGSI, Vulkan ingiere SPIR-V ( versión "V" de representación intermedia portátil estándar como en "Vulkan").
Intel lanzó su implementación de un controlador Vulkan para su hardware el día en que se lanzó oficialmente la especificación, pero solo se introdujo en abril y, por lo tanto, pasó a formar parte de Mesa 12.0, lanzado en julio de 2016. Si bien el controlador i965 no se escribió de acuerdo con las especificaciones de Gallium3D, para el controlador Vulkan tiene aún menos sentido colocarlo encima de Gallium3D. De manera similar, no hay ninguna razón técnica para incluirlo con NIR, pero aun así los empleados de Intel implementaron su controlador Vulkan de esa manera. [106]
Es de esperar que el controlador Vulkan, propiedad de AMD, que se lanzó en marzo [ ¿cuándo? ] , y se anunció que se lanzaría como software gratuito y de código abierto en el futuro y se incluiría en Mesa, también abandona Gallium3D. [107]
RADV es un proyecto gratuito para AMD y está disponible desde la versión 13. [9] La conformidad con Khronos-Test llegó en la versión 17.3. Lo real es soporte total de Vulkan 1.0 y 1.1 desde Mesa 18.1.
Nvidia lanzó su controlador GeForce patentado con soporte Vulkan el día del lanzamiento e Imagination Technologies (PowerVR), Qualcomm (Adreno) y ARM (Mali) hicieron lo mismo o al menos anunciaron controladores Vulkan patentados para Android y otros sistemas operativos. Pero aún está por verse cuándo y si aparecerán implementaciones adicionales de Vulkan gratuitas y de código abierto para estas GPU.
Mesa Software Driver VIRGL inicia Vulkan Development en 2018 con proyectos GSOC para soporte de máquinas virtuales. [108]
Lavapipe es un controlador Software Vulkan basado en CPU y hermano de LLVMpipe. Mesa versión 21.1 es compatible con Vulkan 1.1+. [109]
Google presenta el controlador Venus Vulkan para máquinas virtuales en Mesa 21.1 con soporte completo para Vulkan 1.2+. [52]
Qualcomm Turnip y Broadcom v3dv son nuevos controladores para el hardware Qualcomm Adreno y Broadcom Raspberry 4. Turnip es el hermano Vulkan de freedreno para OpenGL. V3dv es compatible con Vulkan 1.0+ desde Mesa 20.3. En la versión 21.1, Turnip es compatible con Vulkan 1.1+. [110] [111] [112]
Panfrost PanVK para ARM Mali está en camino a Vulkan 1.1, pero solo la versión 1.0 está disponible de forma estable con Mesa 22.0. [113]
Project Dozen está conectando Direct 3D 12 (d3d12) con Vulkan para Emulación de Linux WSL2 en Windows 10 y 11. En Mesa 23.2, Vulkan 1.0 es totalmente compatible y es compatible con el 80% de 1.1 y 1.2 (mesamatrix). [114] [115]
Una especie de barrera de memoria que separa un búfer del resto de la memoria se llama valla. Existen barreras para garantizar que un búfer no se sobrescriba antes de que se hayan completado las operaciones de renderizado y visualización en él. La protección implícita se utiliza para la sincronización entre los controladores de gráficos y el hardware de la GPU. La valla avisa cuando un componente ya no utiliza un amortiguador para que otro pueda utilizarlo o reutilizarlo. En el pasado, el kernel de Linux tenía un mecanismo de protección implícito, en el que una protección se conecta directamente a un búfer (cf. identificadores GEM y FD), pero el espacio de usuario no es consciente de ello. El vallado explícito expone vallas al espacio de usuario, donde el espacio de usuario obtiene vallas tanto del subsistema Direct Rendering Manager (DRM) como de la GPU. Vulkan requiere una protección explícita y ofrece ventajas para el seguimiento y la depuración.
El kernel de Linux 4.9 agregó el marco de sincronización de Android a la línea principal. [116]
Generic Buffer Management (GBM) es una API que proporciona un mecanismo para asignar buffers para la representación de gráficos vinculados a Mesa. GBM está pensado para utilizarse como plataforma nativa para EGL en DRM o openwfd. El identificador que crea se puede utilizar para inicializar EGL y crear búferes de destino de renderizado. [117]
Mesa GBM es una abstracción de las API de administración de búfer específicas del controlador de gráficos (por ejemplo, las diversas bibliotecas libdrm_*), implementadas internamente llamando a los controladores de GPU de Mesa.
Por ejemplo, el compositor de Wayland, Weston, realiza su renderizado utilizando OpenGL ES 2, que inicializa llamando a EGL. Dado que el servidor se ejecuta en el " controlador KMS básico ", utiliza la plataforma EGL DRM, que en realidad podría llamarse plataforma GBM, ya que se basa en la interfaz Mesa GBM.
En XDC2014, Andy Ritger, empleado de Nvidia, propuso mejorar EGL para reemplazar GBM. [118] Esto no fue tomado positivamente por la comunidad, y Nvidia finalmente cambió de opinión, [119] y adoptó otro enfoque.
Hay tres formas posibles de realizar los cálculos necesarios para la codificación y decodificación de transmisiones de vídeo:
Por ejemplo, Nouveau , que se desarrolló como parte de Mesa, pero también incluye un componente del kernel de Linux, que se está desarrollando como parte del kernel de Linux, admite los ASIC de la marca PureVideo y proporciona acceso a ellos a través de VDPAU y en parte a través de XvMC. . [120]
El controlador radeon gratuito es compatible con Unified Video Decoder y Video Coding Engine a través de VDPAU y OpenMAX. [121]
V4L2 es una interfaz de kernel a espacio de usuario para flujos de bits de vídeo entregados por cámaras web o sintonizadores de TV.
Debido a preocupaciones sobre patentes sobre los códecs de video H.264 , H.265 y VC-1 , Fedora Linux deshabilitó el soporte para la aceleración VAAPI para aquellos en su versión de Mesa en septiembre de 2022. [122]
Los controladores de dispositivos gratuitos y de código abierto disponibles para conjuntos de chips gráficos son "administrados" por Mesa (porque la implementación existente de API, gratuita y de código abierto, se desarrolla dentro de Mesa). Actualmente existen dos marcos para escribir controladores de gráficos: "clásico" y Gallium3D. [123] En mesamatrix.net se ofrece una descripción general de algunos (pero no todos) de los controladores disponibles en Mesa .
Hay controladores de dispositivos para tarjetas AMD/ATI R100 a R800, Intel y Nvidia con aceleración 3D. Anteriormente existían controladores para el procesador IBM/Toshiba/Sony Cell de PlayStation 3 , los chipsets S3 Virge y Savage , los chipsets VIA, Matrox G200 y G400, y más. [124]
Los controladores gratuitos y de código abierto compiten con los controladores propietarios de código cerrado. Dependiendo de la disponibilidad de documentación de hardware y mano de obra, el controlador gratuito y de código abierto se queda más o menos atrás en el soporte de aceleración 3D de nuevo hardware. Además, el rendimiento del renderizado 3D suele ser significativamente más lento, con algunas excepciones notables. [125] [126] [127] [128] Hoy en día, esto sigue siendo cierto para Nouveau para la mayoría de las GPU NVIDIA, mientras que en las GPU AMD Radeon el controlador abierto ahora coincide o supera en gran medida el rendimiento del controlador propietario.
En el momento en que las tarjetas gráficas 3D se volvieron más comunes para las PC, personas con el apoyo parcial de algunas empresas comenzaron a trabajar para agregar más soporte para el renderizado 3D acelerado por hardware a Mesa. [ ¿cuando? ] La Infraestructura de renderizado directo (DRI) fue uno de estos enfoques para interconectar Mesa, OpenGL y otras bibliotecas API de renderizado 3D con los controladores y el hardware del dispositivo. Después de alcanzar un nivel básico de usabilidad, se agregó oficialmente el soporte DRI a Mesa. Esto amplió significativamente la gama disponible de soporte de hardware que se puede lograr al utilizar la biblioteca Mesa. [129]
Con la adaptación a DRI, la biblioteca Mesa finalmente asumió el papel del componente frontal de un marco OpenGL a gran escala con diferentes componentes backend que podrían ofrecer diferentes grados de soporte de hardware 3D sin perder la capacidad completa de renderizado del software. El sistema total utilizó muchos componentes de software diferentes. [129]
Si bien el diseño requiere que todos estos componentes interactúen cuidadosamente, las interfaces entre ellos son relativamente fijas. No obstante, como la mayoría de los componentes que interactúan con la pila de Mesa son de código abierto, el trabajo experimental a menudo se realiza modificando varios componentes a la vez, así como las interfaces entre ellos. Si dichos experimentos resultan exitosos, pueden incorporarse en la próxima versión mayor o menor. Esto se aplica, por ejemplo, a la actualización de la especificación DRI desarrollada en el período 2007-2008. El resultado de esta experimentación, DRI2, funciona sin bloqueos y con soporte de buffer trasero mejorado. Para ello, se creó una rama git especial de Mesa. [130]
DRI3 es compatible con el controlador Intel desde 2013 [131] [132] y es predeterminado en algunas distribuciones de Linux desde 2016 [133] para habilitar la compatibilidad con Vulkan y más. También es predeterminado en el hardware AMD desde finales de 2016 (X.Org Server 1.18.3 y posteriores). [134]
Mesa también contiene una implementación de renderizado de software llamada swrast que permite que los sombreadores se ejecuten en la CPU como alternativa cuando no hay aceleradores de hardware de gráficos presentes. El rasterizador de software Gallium se conoce como softpipe o cuando se construye con soporte para LLVM llvmpipe , que genera código de CPU en tiempo de ejecución. [135] [136] Desde Mesa 10.x OpenGL 3.3+ es compatible con Softpipe (10.3) y LLVMpipe (10.2). En realidad, alrededor del 80% de las funciones de OpenGL 4.x están implementadas en Mesa 17.3 (consulte Mesamatrix).
En Mesa 12.0 está disponible un nuevo Intel Rasterizer OpenSWR con altas ventajas en clusters para grandes conjuntos de datos. Está más centrado en la visualización de ingeniería que en juegos o imágenes artísticas y sólo puede funcionar en procesadores x86. [137] Por otro lado, OpenGL 3.1+ ahora es compatible. [138] En algunos ejemplos se midieron valores de aceleración de 29 a 51 relacionados con LLVMPIPE. [139] OpenGL 3.3+ es compatible con OpenSWR desde Mesa 17.1.
VirGL es un Rasterizador para máquinas virtuales implementado en Mesa 11.1 desde 2015 con soporte OpenGL 3.3 y mostrado en Mesamatrix desde Mesa 18. En el nuevo Mesa 18.2 actual es compatible más que los demás con OpenGL 4.3 y OpenGL ES 3.2. Alrededor del 80% de las funciones de OpenGL 4.4 y 4.5 también están listas. Vulkan Development comienza con los proyectos GSOC 2018. [140] [141] [142] [108] [143] [144] [145]
El estado real de virGL en Mesamatrix es soporte total de OpenGL 4.6+ y OpenGL ES 3.2+ con algún software Linux necesario. [146]
D3d12 es un proyecto de Microsoft para la emulación WSL2 de OpenGL 3.3+ y OpenCL 1.2+ con Direct3D 12. D3D12 se fusiona en 21.0. [45] El estado actual en Mesa 23.1 es OpenGL 4.2+ con casi 4.4+ y OpenGL ES 3.1+.
Venus es un nuevo controlador de GPU Vulkan VirtIO para GPU en máquinas virtuales de Google. Venus se fusiona en 21.1 y se presenta para el público en 21.2. [52] Venus admite Vulkan 1.3+ en Mesa 23.1. El hardware mínimo es Vulkan 1.1 con algunas extensiones. [147]
Emma Anholt propuso la idea de agrupar varios controladores en un único "mega" controlador. Permite utilizar una única copia del código Mesa compartido entre varios controladores (en lugar de que exista en cada controlador por separado) y ofrece un mejor rendimiento que una biblioteca compartida separada debido a la eliminación de la interfaz de la biblioteca interna. [148] Los rastreadores de estado para VDPAU y XvMC se han convertido en bibliotecas separadas. [149]
shader-db es una colección de alrededor de 20.000 sombreadores recopilados de varios juegos de computadora y puntos de referencia, así como algunos scripts para compilarlos y recopilar algunas estadísticas. Shader-db está destinado a ayudar a validar una optimización.
Se observó que una cantidad inesperada de sombreadores no están escritos a mano sino generados. Esto significa que estos sombreadores se escribieron originalmente en HLSL y luego se tradujeron a GLSL mediante algún programa traductor, como por ejemplo HLSL2GLSL . El problema es que el código generado suele estar lejos de ser óptimo. Matt Turner dijo que era mucho más fácil arreglar esto en el programa traductor que tener que hacer que el compilador de Mesa cargue con la carga de lidiar con sombreadores tan inflados.
shader-db no puede considerarse software gratuito y de código abierto. Para usarlo legalmente, uno debe tener una licencia para todos los juegos de computadora de los que forman parte los sombreadores.
Los llamados "controladores de dispositivos gráficos en modo de usuario" (UMD) en Mesa tienen muy pocos puntos en común con lo que generalmente se llama controlador de dispositivo . Hay un par de diferencias:
/drivers/gpu/drm/Cada UMD se comunica con su contraparte en modo kernel con la ayuda de una biblioteca específica, llamada libdrm_specific y uno genérico, llamado libdrm . Esta sección se centrará únicamente en la parte del modo de usuario situada encima de libdrm.Uno de los objetivos de Mesa es la optimización del código que ejecutará la GPU respectiva. Otro es compartir código. En lugar de documentar las piezas de software, este artículo analizará las representaciones intermedias utilizadas en el proceso de compilación y optimización. Consulte Árbol de sintaxis abstracta (AST) y Formulario de asignación única estática (formulario SSA).
SPIR-V es una versión determinada de la representación intermedia portátil estándar . La idea es que las aplicaciones de gráficos generen SPIR-V en lugar de GLSL. A diferencia de este último, SPIR-V es binario para evitar diferencias de implementación entre las interfaces del compilador GLSL de diferentes implementaciones de controladores, ya que esto ha sido una fuente importante de incompatibilidades y errores de aplicaciones. Además, el binario SPIR-V generalmente también pasa por algunas optimizaciones generales. La representación binaria de SPIR-V también ofrece cierto grado de ofuscación, lo que podría resultar atractivo para algunos proveedores de software como forma de protección de la propiedad intelectual; sin embargo, SPIR-V contiene amplia información para la reflexión y existen herramientas que traducen SPIR-V nuevamente a código de alto nivel legible por humanos y de alta calidad. Un UMD solo necesita aplicar optimizaciones que sean específicas del hardware compatible.
Se introdujo NIR (Nueva Representación Interna) para superar las limitaciones de TGSI. [150] [151] NIR se amplió en las últimas versiones y en las actuales como base de soporte de Spir-V y desde 2016 es el principal área de desarrollo. LLVMpipe, i965, RadeonSI, Nouveau, freedreno, vc4 se cambian a NIR desde TGSI. RADV, Zink y otros controladores nuevos comienzan con NIR. Todos los controladores con soporte completo para OpenGL 4.6 están relacionados con el soporte NIR mediante SPIR-V. Además, AMD r600 tiene una bifurcación con NIR para un mejor soporte de las series HD5000 y HD6000. Esta opción para r600 es predeterminada desde Mesa 21.0.
La infraestructura de sombreado de gráficos Tungsten (TGSI) fue introducida en 2008 por Tungsten Graphics. Todos los UMD de estilo Gallium3D ingieren TGSI. NIR es ahora el área de desarrollo principal, por lo que TGSI es solo para controladores más antiguos como la infraestructura predeterminada r300g y quedará obsoleto en algunos años.
El código GLSL-To-TGSI se eliminará en Mesa 22.2. El valor predeterminado es NIR a TGSI más nuevo con GLSL a NIR para todos los controladores NIR nativos. Algunos controladores TGSI más antiguos son compatibles con esta ruta de código NIR. Más adelante, NIR-To-TGSI quedará obsoleto solo para los controladores NIR nativos. [152]
Los UMD radeonsiy llvmpipeno generan código de máquina, sino LLVM IR. A partir de ahora, LLVM realiza optimizaciones y compilaciones en código de máquina. Esto significa que también se debe instalar una determinada versión mínima de LLVM.
RADV ACO utiliza IR propio que está cerca de NIR, para optimizar y generar código binario final para sombreadores Vulkan SPIR-V sobre las GPU Radeon (GCN 1+, también conocidas como GFX6+). A partir de la versión 20.1.0, el ACO solo se usa en RADV (controlador Vulkan) y aún no en RadeonSI.
El compilador GLSL de Mesa genera su propio IR. Debido a que cada controlador tiene requisitos muy diferentes a los de un LIR, se diferencia entre HIR (IR de alto nivel) y LIR (IR de bajo nivel).
Gallium3D es un conjunto de interfaces y una colección de bibliotecas de soporte [154] destinadas a facilitar la programación de controladores de dispositivos para conjuntos de chips de gráficos 3D para múltiples sistemas operativos, API de aceleración de video o renderizado. Es un software de controlador de dispositivos gráficos gratuito y de código abierto .
Se proporciona una matriz de funciones en mesamatrix.net .
El desarrollo de Gallium3D comenzó en 2008 en Tungsten Graphics, [155] y la implementación está disponible como software gratuito y de código abierto como parte de Mesa 3D alojado en freedesktop.org . El objetivo principal es facilitar el desarrollo de controladores, agrupar código duplicado de varios controladores diferentes en un solo punto y admitir arquitecturas de hardware modernas. Esto se consigue proporcionando una mejor división del trabajo, por ejemplo, dejando la gestión de la memoria al controlador DRI del núcleo.
Gallium3D ha sido parte de Mesa desde 2009 [156] y actualmente lo utiliza el controlador de gráficos gratuito y de código abierto para Nvidia ( proyecto nouveau ), [157] [158] para AMD R300 – R900 , [159] [160] [161] Controlador 'Iris' de Intel para iGPU de generación 8+ [162] y para otros controladores de dispositivos GPU gratuitos y de código abierto .
Gallium3D facilita la programación de controladores de dispositivos al dividir el controlador del dispositivo de gráficos en tres partes. Esto se logra mediante la introducción de dos interfaces : la interfaz Gallium3D State Tracker y la interfaz Gallium3D WinSys . Los tres componentes se llaman:
Gallium3D proporciona una API unificada que expone funciones de hardware estándar, como las unidades de sombreado que se encuentran en el hardware moderno. Por lo tanto, las API 3D como OpenGL 1.x/2.x, OpenGL 3.x, OpenVG , la infraestructura GPGPU o incluso Direct3D (como se encuentra en la capa de compatibilidad de Wine ) necesitarán solo un único back-end, llamado rastreador de estado. dirigido a la API Gallium3D. Por el contrario, los controladores de dispositivos DRI de estilo clásico requieren un back-end diferente para cada plataforma de hardware y varias otras API necesitan traducción a OpenGL a expensas de la duplicación de código. [163] [164] [165] Todos los controladores de dispositivos de proveedores, debido a su naturaleza patentada y de código cerrado, están escritos de esa manera, lo que significa que, por ejemplo, AMD Catalyst implementa OpenGL y Direct3D , y los controladores de proveedores para GeForce tienen sus implementaciones.
En Gallium3D, los controladores del kernel de Direct Rendering Manager (DRM) administrarán la memoria y los controladores de Direct Rendering Interface (DRI2) estarán más orientados al procesamiento de GPU. [166] Durante el período de transición de la configuración del modo de espacio de usuario a la configuración del modo de espacio de kernel, algunos de los controladores Mesa 3D, como el controlador radeon o los controladores de Intel, terminaron admitiendo tanto DRI1 como DRI2 y usaron DRI2 si estaba disponible en el sistema. Gallium3D además requiere un nivel de soporte de sombreado que no está disponible en tarjetas más antiguas como, por ejemplo, ATi r100-r200, por lo que los usuarios de esas tarjetas deben seguir usando Mesa 3D con DRI2 para su uso 3D.
Tungsten Graphics Shader Infrastructure ( TGSI ) es una representación intermedia como la representación intermedia LLVM o la nueva representación intermedia portátil estándar (SPIR) que utilizará la API de Vulkan y OpenCL 2.1. Los sombreadores escritos en OpenGL Shading Language deben traducirse/compilarse en TGSI, luego se realizan optimizaciones y luego los sombreadores TGSI se compilan en sombreadores para el conjunto de instrucciones de la GPU utilizada.
NIR es la nueva representación de capas en Mesa con soporte completo para SPIR-V y desde 2019 el área de desarrollo principal de todos los controladores más nuevos con soporte para OpenGL 4.6.
Además, utilizando la estructura modular de Gallium3D, se está realizando un esfuerzo para utilizar el conjunto de compiladores LLVM y crear un módulo para optimizar el código de sombreado sobre la marcha. [167]
La biblioteca representa cada programa de sombreado utilizando una representación intermedia binaria extensible llamada Tungsten Graphics Shader Infrastructure (TGSI), que LLVM luego traduce en sombreadores GLSL optimizados para el hardware de destino.
Varios controladores de dispositivos gráficos gratuitos y de código abierto , que se han escrito o se están escribiendo en función de la información obtenida mediante ingeniería inversa en sala limpia , adoptaron el modelo de controlador proporcionado por Gallium3D, por ejemplo, nouveau y otros ( consulte Dispositivo gráfico gratuito y de código abierto). controlador para obtener una lista completa ). La razón principal puede ser que el modelo de controlador Gallium3D reduce la cantidad de código necesario para escribir. [ ¿investigacion original? ] Por supuesto, al tener una licencia de software libre, cualquier persona puede reescribir este código en cualquier momento para implementar el modelo de controlador DRI o algún otro.
Los autores originales de Gallium3D fueron Keith Whitwell y Brian Paul de Tungsten Graphics (adquirida por VMware en 2008). [168]
En el otoño de 2011, había al menos 10 controladores Gallium3D conocidos, maduros y en funcionamiento. [169] [ verificación fallida ] [ cita necesaria ] Controladores de código abierto para tarjetas gráficas Nvidia con el nombre del equipo Nouveau desarrolla sus controladores utilizando el marco Gallium3D. [158] [170]
13/07/2008: El desarrollo Nouveau se realiza exclusivamente para el marco Gallium. El antiguo controlador DRI se eliminó de la rama maestra del repositorio de Mesa en Freedesktop.org. [171]
11/02/2009: La rama galio-0.2 se fusionó con la rama principal Master de Mesa. [172] El desarrollo se realiza en la línea principal de Mesa.
25/02/2009: Gallium3D puede ejecutarse tanto en Linux como en kernels de FreeBSD. [173]
01/05/2009: Zack Rusin de Tungsten Graphics agregó el rastreador de estado OpenVG a Mesa 3D, [174] que permite que los gráficos vectoriales escalables sean acelerados por hardware mediante cualquier controlador basado en Gallium3D.
2009-07-17: Se lanza Mesa3D 7.5, la primera versión que incluye Gallium3D. [175]
10/09/2010: Se agregó soporte inicial para las GPU Evergreen al controlador r600g. [176]
21/09/2010: Hay dos controladores Gallium3D para hardware ATI conocidos como r300g y r600g para las GPU R300-R500 y R600-Evergreen respectivamente.
21/09/2010: Se realizaron importantes compromisos con el código para admitir Direct3D 10 y 11. [177] Con el tiempo, esto podría ofrecer la posibilidad de utilizar implementaciones recientes de Direct3D en sistemas Linux.
30/11/2011: Los controladores Intel 965g y Cell Gallium se eliminaron de la rama maestra de Mesa por no recibir mantenimiento y estar rotos. [178] [179]
30/11/2013: Mesa 10 con OpenGL 3.2, 3.3 y OpenCL 1.0+
18/11/2014: Se realizaron confirmaciones importantes en el código para admitir Direct3D 9. [180]
2015-09-15: Mesa 11 con OpenGL 4.0, 4.1 y OpenCL 1.2 (incompleto)
2015-12-15: Controlador Mesa 11.1 VIRGL para máquinas virtuales con OpenGL 3.3
08-07-2016: Mesa 12 con OpenGL 4.2, 4.3 y Vulkan 1.0 (Intel ANV y AMD RADV)
2016-11-01: Mesa 13 con OpenGL 4.4 y OpenGL ES 3.2
2017-02-13: Mesa 17.0 con OpenGL 4.5 y controlador freedreno con OpenGL 3.0 y 3.1
2017-05-10: Mesa 17.1 OpenGL 4.2+ para Intel Ivy Bridge (más que el controlador Intel para Windows, OpenGL 3.3+ para Intel Open SWR Rasterizer (importante para computadoras en clúster para simulaciones grandes)
2017-12-08: Mesa 17.3 AMD Vulkan Driver RADV totalmente compatible en la prueba Khronos de Vulkan 1.0
2018-05-18: Mesa 18.1 con Vulkan 1.1 (Intel ANV y AMD RADV)
2018-09-07: Mesa 18.2 con OpenGL 4.3 para Soft Driver VIRGL (importante para máquinas virtuales en la nube Cluster Computer), OpenGL ES 3.1 para Freedreno con Adreno A5xx
2019-06-11: Mesa 19.1 lanzado con el controlador de gráficos 'iris' de próxima generación de Intel para iGPU de generación 8+ [181]
2019-12-11: Mesa 19.3 lanzó OpenGL 4.6 con Intel i965 con gen 7+ e Iris Gen 8+ opcional
2020-03-18: Mesa 20.0 lanzó OpenGL 4.6 con AMD GCN y Vulkan 1.2 para Intel
2020-05-27: Mesa 20.1 lanzó soporte de vectorización NIR y soporte de memoria virtual compartida para OpenCL en Clover
2020-11-30: Mesa 20.3 es totalmente compatible con OpenCL 1.2 en Clover [41]
2021-03-11: Soporte inicial de Mesa 21.0 de "D3D12“: Direct 3D 12 para WSL2 en Windows 10 con OpenGL 3.3+, ARM Freedreno: OpenGL 3.3+
2021-05-05: Soporte inicial de Mesa 21.1 para el controlador de GPU VirtIO de Google "Venus" con Vulkan 1.2+; Zink: OpenGL 4.6+, OpenGL ES 3.1+; Qualcomm Turnip, Lavapipe: Vulkan 1.1+
2021-08-04: Soporte inicial de Mesa 21.2 del nuevo controlador Intel Crocus OpenGL 4.6 basado en gallium3D para Intel Sandy Bridge a Haswell para el antiguo i965, Vulkan Driver panVK para ARM Panfrost
2022-03-09: Mesa 22.0 es totalmente compatible con Vulkan 1.3 de Intel Anvil y AMD RADV
2023-05-10: Mesa 23.1 OpenCL con Rust: RustiCL para hardware AMD GCN disponible (más hardware wip) [182]
2023-09-30: Mesa 23.2 con Apple Asahi OpenGL 3.1 y OpenGL ES 3.0, RADV admite Ray Tracing en AMD RDNA 2 y 3, admite decodificación Intel Anvil Vulkan H.265 [183]
El iniciador del proyecto, Brian Paul, era un aficionado a los gráficos. Pensó que sería divertido implementar una biblioteca de gráficos 3D simple usando la API OpenGL, que luego podría usar en lugar de VOGL (una biblioteca similar a GL muy común). [184] A partir de 1993, pasó dieciocho meses de desarrollo a tiempo parcial antes de lanzar el software en Internet en febrero de 1995. [185] El software fue bien recibido y la gente comenzó a contribuir a su desarrollo. Mesa comenzó renderizando todos los gráficos de computadora en 3D en la CPU . A pesar de esto, la arquitectura interna de Mesa fue diseñada para estar abierta para conectarse a la representación 3D acelerada por el procesador de gráficos . En esta primera fase, el renderizado se realizó indirectamente en el servidor de visualización , dejando algo de sobrecarga y una velocidad notable por detrás del máximo teórico. El Diamond Monster 3D , que utiliza el chipset Voodoo Graphics , fue uno de los primeros dispositivos de hardware 3D compatibles con Mesa.
El primer soporte de hardware de gráficos verdadero se agregó a Mesa en 1997, basado en la API Glide para las entonces nuevas tarjetas gráficas 3dfx Voodoo I/II y sus sucesoras. [129] Un problema importante al usar Glide como capa de aceleración era el hábito de Glide de ejecutarse en pantalla completa, que solo era adecuado para juegos de computadora. Además, Glide tomó el bloqueo de la memoria de la pantalla y, por lo tanto, el servidor de visualización no pudo realizar otras tareas de GUI. [186]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}