Mesa , también llamada Mesa3D y The 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 gráficos desarrollados y financiados principalmente por Intel y AMD para su respectivo hardware (AMD promueve sus controladores Mesa Radeon y RadeonSI sobre el obsoleto AMD Catalyst , e Intel solo ha dado soporte al controlador Mesa). Los controladores gráficos propietarios (por ejemplo, el controlador Nvidia GeForce y Catalyst) reemplazan a todos los Mesa, proporcionando su propia implementación de una API de gráficos. Un esfuerzo de código abierto para escribir un controlador Nvidia para Mesa 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á alojado en freedesktop.org y fue iniciado 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 varias personas 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 parcialmente por la financiación colectiva . [3]
Mesa es conocida por albergar implementaciones de API gráficas . Históricamente, la API principal 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 para 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 gráfica como OpenGL y los controladores de hardware gráfico en el núcleo del sistema operativo. La versión compatible de las diferentes API gráficas depende del controlador, ya que cada controlador de hardware tiene su propia implementación (y, por lo tanto, su 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 la conformidad actual con OpenGL [6] [7] visualizada en mesamatrix.net . Mesa 10 cumple con OpenGL 3.3 para hardware GPU Intel, AMD/ATI y Nvidia. Mesa 11 fue anunciado 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 trajo soporte de Intel para OpenGL 4.4 y 4.5 (todas las características soportadas por 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) están underclockeadas sin información de Nvidia. [16]
La suite de pruebas Khronos CTS para OpenGL 4.4, 4.5 y OpenGL ES 3.0+ ya está disponible en código abierto (24/01/2017) y todas las pruebas para Mesa 13 y 17 ahora son posibles sin costo. [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 las más destacadas. [18] [19]
Debido a la naturaleza modular de OpenGL, Mesa puede admitir extensiones de versiones más nuevas de OpenGL sin afirmar que es totalmente compatible con 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 o OpenGL ES. [20]
La tercera versión 17.2 está disponible desde septiembre de 2017 con algunas nuevas características de OpenGL 4.6 y mejoras de velocidad en 3D para Intel y AMD. Solo el 1,4 % de las pruebas fallan con OpenGL 4.5 en Nouveau para Kepler. [21]
La versión 17.3 de la cuarta versión 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). El controlador AMD Vulkan 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 con el mismo esquema en 2017. [23] El soporte completo de OpenGL 4.6 no está listo, pero muchas características y mejoras se probaron con éxito en RC3. El soporte de 10 bits para Intel i965 en Colors también es un punto destacado. [24] Una novedad 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 del soporte de OpenGL 4.5. Los chips AMD R600 o RV700 antiguos solo pueden soportar OpenGL 3.3 con algunas características de OpenGL 4.x. Freedreno es el controlador para hardware Adreno y soporte cercano a 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 los controladores Intel ANV y AMD RADV. OpenGL 4.6 con spir-V también es el objetivo principal. Es posible que se trabaje de forma permanente en la finalización de las funciones y la optimización de los controladores para hardware más antiguo como AMD R600/Evergreen, Nvidia Tesla y, antes, Fermi, Kepler o Intel Sandybridge, Ivybridge, Haswell o Broadwell. La arquitectura ARM 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 estará disponible en el calendario estable en septiembre. OpenGL 4.6 con spir-V y Vulkan 1.1.80 están en proceso. El controlador de software 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 compresión de texturas ASTC y el soporte del modo de compatibilidad para OpenGL 4.4 (3.1 en 18.1) son otros puntos destacados de RadeonSI para tarjetas AMD GCN. El nuevo Vulkan 1.1 y más funciones para Intel y AMD están disponibles. Ver más detalles sobre 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 de las características se detallan y la compatibilidad con hardware más nuevo es una parte importante. La compatibilidad total con OpenGL 4.6 aún 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 aún no está listo, pero hay muchas mejoras en este sentido en todos los controladores. [28] [29]
La segunda versión de 2019 es la 19.1. La transición de TGSI a NIR es una de las principales características de cara 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 la 19.2. OpenGL 4.6 está listo para la versión beta del nuevo controlador Intel Iris. [31]
La cuarta versión de 2019 es la 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 manera predeterminada, en lugar de TGSI.
La segunda versión de 2020 es la 20.1. Hay muchas mejoras listas para 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 en gran medida con muchos módulos. La memoria virtual compartida es posible para OpenCL en Nouveau con Pascal y versiones superiores. [36] [37] [38]
La cuarta versión de 2020 es la 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 es compatible con OpenGL 4.5+ con 4.6 en vista. Lavapipe (originalmente llamado Vallium [39] ) como Vulkan Tree de LLVMpipe se fusionó. [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 de d3d12 en WSL2 para Windows 10 con Direct 3D 12. OpenCL 1.2 también es un objetivo 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 el segundo lanzamiento del año 2021. [50] OpenGL 4.6+ y OpenGL ES 3.1+ están disponibles para Zink. El controlador AMD 600g puede cambiar a NIR con más posibilidades para las antiguas tarjetas Radeon HD 5000 y 6000. [51] Qualcomm Turnip alcanza Vulkan 1.1+ y la emulación de software Lavapipe Vulkan 1.1+. El controlador de GPU Google VirtIO Venus con Vulkan 1.2+ se fusiona en estado experimental con bajo rendimiento en el árbol principal de Mesa. [52]
Mesa 21.2 es el tercer lanzamiento del año 2021. El controlador de E/S de Google Virtual Vulkan Venus se presentará oficialmente con soporte completo para Vulkan 1.2+ (más mesamatrix). ARM Panfrost: está disponible el soporte para OpenGL ES 3.1+ y panVK es el nuevo controlador de Vulkan. El soporte inicial comenzó para ARM Apple M1 con el nuevo controlador Asahi. 21.2 está disponible desde el 4 de agosto de 2021. [53]
Un plan antiguo es dividir los controladores antiguos en un árbol clásico con muchas ventajas en programación, soporte, corrección de errores para la parte moderna de Gallium 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 Intel Gen 4 Graphics para Haswell está aquí en desarrollo para completar aquí el área de gallium3D con posible división en la próxima época del año 2021. Crocus está disponible opcionalmente en 21.2. [55] La rama Amber 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, los controladores clásicos se han retirado. 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 o mejor que el de AMD ROCm con la tarjeta AMD 6700 XT. [59] [60]
Un objetivo principal del 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 de un retraso en la versión 23.1 (consulte mesamatrix). [63] RustiCL para hardware AMD está disponible en la versión 23.1. [64]
VirGL para máquinas virtuales salta de 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 en 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 estados de OpenGL del código específico del hardware.
La versión 1.3 está disponible de inmediato con Mesa 22.0. El hardware compatible con OpenGL ES 3.1 debe funcionar con Vulkan Level 1.3 y versiones anteriores. [105]
Así como Gallium3D ingiere TGSI, Vulkan ingiere SPIR-V ( Representación intermedia portátil estándar versión "V" 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 recién se incorporó a la línea principal en abril y, por lo tanto, se convirtió en 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 sobre Gallium3D. De manera similar, no hay ninguna razón técnica para colocarlo sobre NIR, pero aún así, los empleados de Intel implementaron su controlador Vulkan de esa manera. [106]
Es de esperar que el controlador Vulkan propietario de AMD, que se lanzó en marzo [¿ cuándo? ] y se anunció que se lanzaría como software libre y de código abierto en el futuro y se integraría en Mesa, también abandone Gallium3D. [107]
RADV es un proyecto gratuito para AMD y está disponible desde la versión 13. [9] La compatibilidad con Khronos-Test llegó en la versión 17.3. Actualmente, es totalmente compatible con Vulkan 1.0 y 1.1 desde Mesa 18.1.
Nvidia lanzó su controlador propietario GeForce con soporte Vulkan el día del lanzamiento e Imagination Technologies (PowerVR), Qualcomm (Adreno) y ARM (Mali) han hecho lo mismo o al menos han anunciado controladores propietarios Vulkan para Android y otros sistemas operativos. Pero aún queda por ver cuándo aparecerán implementaciones de Vulkan gratuitas y de código abierto adicionales para estas GPU.
Mesa Software Driver VIRGL comienza el desarrollo de Vulkan en 2018 con proyectos GSOC para brindar soporte a máquinas virtuales. [108]
Lavapipe es un controlador Vulkan basado en software de CPU y hermano de LLVMpipe. La versión 21.1 de Mesa 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 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 estable está disponible con Mesa 22.0. [113]
El proyecto Dozen está conectando Direct 3D 12 (d3d12) con Vulkan para la emulación de Linux WSL2 en Windows 10 y 11. En Mesa 23.2, Vulkan 1.0 es totalmente compatible y tiene un 80 % de compatibilidad con 1.1 y 1.2 (mesamatrix). [114] [115]
Un tipo de barrera de memoria que separa un búfer del resto de la memoria se denomina valla. Las vallas están ahí para garantizar que un búfer no se sobrescriba antes de que se completen las operaciones de renderizado y visualización en él. El vallado implícito se utiliza para la sincronización entre los controladores gráficos y el hardware de la GPU. La valla indica cuándo un componente ya no utiliza un búfer para que otro pueda operar en él o reutilizarlo. En el pasado, el núcleo de Linux tenía un mecanismo de vallado implícito, en el que una valla se adjunta directamente a un búfer (cf. controladores GEM y FD), pero el espacio de usuario no lo sabe. El vallado explícito expone las 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 el vallado explícito y ofrece ventajas para el seguimiento y la depuración.
El kernel 4.9 de Linux agregó el marco de sincronización de Android a la línea principal. [116]
La gestión genérica de búfer (GBM) es una API que proporciona un mecanismo para asignar búferes para la representación gráfica vinculada a Mesa. GBM está pensada 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 representación. [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 mediante llamadas a los controladores de GPU de Mesa.
Por ejemplo, el compositor Wayland Weston realiza su renderización 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 GBM de Mesa.
En XDC2014, el empleado de Nvidia Andy Ritger propuso mejorar EGL para reemplazar a GBM. [118] Esto no fue tomado positivamente por la comunidad y Nvidia eventualmente 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 ha desarrollado como parte de Mesa, pero que también incluye un componente de kernel de Linux, que se está desarrollando como parte del kernel de Linux, admite los ASIC de marca PureVideo y proporciona acceso a ellos a través de VDPAU y en parte a través de XvMC . [120]
El controlador gratuito Radeon admite el decodificador de video unificado y el motor de codificación de video a través de VDPAU y OpenMAX. [121]
V4L2 es una interfaz de kernel a espacio de usuario para transmisiones de bits de video entregadas por cámaras web o sintonizadores de TV.
Debido a preocupaciones sobre patentes con respecto a 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 compilación de Mesa en septiembre de 2022. [122]
Los controladores de dispositivos gratuitos y de código abierto disponibles para chipsets gráficos están "administrados" por Mesa (porque la implementación de API libre y de código abierto existente se desarrolla dentro de Mesa). Actualmente hay dos marcos para escribir controladores 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 .
Existen 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 , chipsets S3 Virge y Savage , 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 de la mano de obra, los controladores gratuitos y de código abierto se quedan más o menos atrás en cuanto a la compatibilidad con la aceleración 3D del nuevo hardware. Además, el rendimiento de la renderización 3D era normalmente significativamente más lento con algunas excepciones notables. [125] [126] [127] [128] Hoy en día esto sigue siendo cierto para Nouveau en la mayoría de las GPU NVIDIA, mientras que en las GPU Radeon de AMD el controlador abierto ahora iguala 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, las personas, parcialmente apoyadas por algunas compañías, comenzaron a trabajar para agregar más soporte para renderizado 3D acelerado por hardware a Mesa. [ ¿Cuándo? ] 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 de dispositivos y el hardware. Después de alcanzar un nivel básico de usabilidad, el soporte DRI se agregó oficialmente a Mesa. Esto amplió significativamente la gama disponible de soporte de hardware que se puede lograr al usar la biblioteca Mesa. [129]
Con la adaptación a DRI, la biblioteca Mesa finalmente asumió el rol de componente front-end de un marco OpenGL a gran escala con diversos componentes back-end que podían ofrecer distintos grados de soporte de hardware 3D sin perder la capacidad total de renderización de 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 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 tales experimentos resultan exitosos, se pueden incorporar en la próxima versión principal o secundaria. 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, opera sin bloqueos y con un soporte de búfer de respaldo mejorado. Para esto, se creó una rama git especial de Mesa. [130]
El controlador Intel admite DRI3 desde 2013 [131] [132] y es la opción predeterminada en algunas distribuciones Linux desde 2016 [133] para habilitar la compatibilidad con Vulkan y más. También es la opción predeterminada en el hardware AMD desde finales de 2016 (X.Org Server 1.18.3 y versiones 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 una alternativa cuando no hay aceleradores de hardware de gráficos presentes. El rasterizador de software Gallium se conoce como softpipe o cuando se crea 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 características 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 grandes ventajas en clústeres para grandes conjuntos de datos. Está más enfocado en la visualización de ingeniería que en la creación de imágenes de juegos o arte y solo puede funcionar en procesadores x86. [137] Por otro lado, ahora se admite OpenGL 3.1+. [138] Se midieron valores de aceleración de 29 a 51 relacionados con LLVMPIPE en algunos ejemplos. [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 para OpenGL 3.3 y mostrado en Mesamatrix desde Mesa 18. En la nueva versión de Mesa 18.2, es compatible con más OpenGL 4.3 y OpenGL ES 3.2 que los demás. Alrededor del 80% de las características de OpenGL 4.4 y 4.5 también están listas. El desarrollo de Vulkan comienza con los proyectos GSOC 2018. [140] [141] [142] [108] [143] [144] [145]
El estado actual de virGL en Mesamatrix es soporte completo 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 fusionó 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 fusionó en la versión 21.1 y se introdujo para el público en la versión 21.2. [52] Venus es compatible con Vulkan 1.3+ en Mesa 23.1. El hardware mínimo es Vulkan 1.1 con algunas extensiones. [147]
La idea de agrupar varios controladores en un único "mega" controlador fue propuesta por Emma Anholt. Permite que se utilice 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 independiente debido a la eliminación de la interfaz de biblioteca interna. [148] Los rastreadores de estado para VDPAU y XvMC se han convertido en bibliotecas independientes. [149]
shader-db es una colección de aproximadamente 20.000 shaders recopilados de varios juegos de computadora y pruebas comparativas, así como algunos scripts para compilarlos y recopilar algunas estadísticas. Shader-db está diseñado para 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 a menudo dista mucho de ser óptimo. Matt Turner dijo que era mucho más fácil solucionar esto en el programa traductor que tener que hacer que el compilador de Mesa se hiciera cargo de lidiar con sombreadores tan inflados.
Shader-db no puede considerarse software libre y de código abierto. Para usarlo legalmente, es necesario tener una licencia para todos los juegos de computadora de los que forman parte los shaders.
Los denominados "controladores de dispositivos gráficos en modo usuario" (UMD) de Mesa tienen muy pocos puntos en común con lo que generalmente se denomina un controlador de dispositivo . Existen 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 una genérica, llamada libdrm . Esta sección se centrará únicamente en la parte del modo de usuario sobre libdrmUno de los objetivos de Mesa es la optimización del código que se va a ejecutar en la GPU correspondiente. Otro es compartir el código. En lugar de documentar las piezas de software, este artículo analizará las representaciones intermedias que se utilizan en el proceso de compilación y optimización. Consulte el árbol de sintaxis abstracta (AST) y el 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 gráficas generen SPIR-V en lugar de GLSL. A diferencia de este último, SPIR-V es binario para evitar diferencias de implementación entre los frontends de compiladores GLSL de diferentes implementaciones de controladores, ya que esto ha sido una fuente importante de incompatibilidades y errores de aplicación. Además, el binario de 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, que puede resultar atractivo para algunos proveedores de software como una forma de protección de la propiedad intelectual; sin embargo, SPIR-V contiene abundante información para la reflexión y existen herramientas que traducen SPIR-V nuevamente a código de alto nivel legible para humanos y de alta calidad. Un UMD solo necesita aplicar optimizaciones que sean específicas para el hardware compatible.
NIR (New Internal Representation) se introdujo para superar las limitaciones de TGSI. [150] [151] NIR se amplió en las últimas versiones y en las actuales como base del soporte de Spir-V y es desde 2016 el área de desarrollo principal. LLVMpipe, i965, RadeonSI, Nouveau, freedreno, vc4 se cambiaron de TGSI a NIR. RADV, Zink y otros controladores nuevos comienzan con NIR. Todos los controladores con soporte completo de OpenGL 4.6 están relacionados con NIR por el soporte de 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.
Tungsten Graphics Shader Infrastructure (TGSI) fue introducida en 2008 por Tungsten Graphics. Todos los UMD de estilo Gallium3D incorporan TGSI. NIR es ahora el área de desarrollo principal, por lo que TGSI solo es 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 el nuevo NIR-to-TGSI con GLSL-to-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 radeonsino llvmpipegeneran código de máquina, sino LLVM IR. A partir de aquí, LLVM realiza optimizaciones y la compilación a código de máquina. Esto significa que también se debe instalar una determinada versión mínima de LLVM.
RADV ACO utiliza su propio IR, cercano al NIR, para optimizar y generar código binario final para los shaders Vulkan SPIR-V sobre GPU Radeon (GCN 1+, también conocidas como GFX6+). A partir de la versión 20.1.0, el ACO solo se utiliza en RADV (controlador Vulkan) y todavía 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, 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 chipsets de gráficos 3D para múltiples sistemas operativos, API de renderizado o aceleración de vídeo. Es un software de controlador de dispositivos gráficos gratuito y de código abierto .
Se proporciona una matriz de características en mesamatrix.net .
El desarrollo de Gallium3D comenzó en 2008 en Tungsten Graphics, [155] y la implementación está disponible como software libre y de código abierto como parte de Mesa 3D alojado por freedesktop.org . El objetivo principal es facilitar el desarrollo de controladores, agrupando el código duplicado de varios controladores diferentes en un solo punto y brindar soporte a las arquitecturas de hardware modernas. Esto se logra 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 R300 – R900 de AMD , [159] [160] [161] el 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 dividiendo el controlador del dispositivo gráfico en tres partes. Esto se logra mediante la introducción de dos interfaces : la interfaz de seguimiento de estado de Gallium3D y la interfaz WinSys de Gallium3D . Los tres componentes se denominan:
Gallium3D proporciona una API unificada que expone funciones de hardware estándar, como unidades de sombreado que se encuentran en hardware moderno. Por lo tanto, las API 3D como OpenGL 1.x/2.x, OpenGL 3.x, OpenVG , 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, que apunte a la API de 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 propietaria y de código cerrado, están escritos de esa manera, lo que significa que, por ejemplo, AMD Catalyst implementa tanto OpenGL como 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 la 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 de 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 compatibilidad con sombreadores 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 se utilizará en la API de Vulkan y OpenCL 2.1. Los sombreadores escritos en lenguaje de sombreado OpenGL se deben traducir/compilar 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 la suite de compiladores LLVM y crear un módulo para optimizar el código de sombreado sobre la marcha. [167]
La biblioteca representa cada programa shader utilizando una representación intermedia binaria extensible llamada Tungsten Graphics Shader Infrastructure (TGSI), que LLVM luego traduce en shaders GLSL optimizados para el hardware de destino.
Varios controladores de dispositivos gráficos libres y de código abierto , que se han escrito o se están escribiendo en base a información obtenida mediante ingeniería inversa en sala limpia , adoptaron el modelo de controlador proporcionado por Gallium3D, por ejemplo, nouveau y otros ( consulte Controlador de dispositivo gráfico libre y de código abierto para obtener una lista completa ). La razón principal puede ser que el modelo de controlador de Gallium3D reduce la cantidad de código que se requiere escribir. [ ¿ Investigación original? ] Por supuesto, al estar licenciado bajo una licencia de software libre, este código puede ser reescrito en cualquier momento por cualquier persona 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 requerida ] El equipo de controladores de código abierto para tarjetas gráficas Nvidia llamado Nouveau desarrolla sus controladores utilizando el marco Gallium3D. [158] [170]
13 de julio de 2008: El desarrollo de Nouveau se realiza exclusivamente para el marco Gallium. El antiguo controlador DRI se eliminó de la rama principal del repositorio Mesa en Freedesktop.org. [171]
11-02-2009: La rama gallium-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 kernels Linux como FreeBSD. [173]
01-05-2009: Zack Rusin de Tungsten Graphics agregó el rastreador de estado OpenVG a Mesa 3D, [174] lo que permite que los gráficos vectoriales escalables sean acelerados por hardware por cualquier controlador basado en Gallium3D.
17-07-2009: 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 modificaciones al código para brindar compatibilidad con Direct3D 10 y 11. [177] Con el tiempo, esto podría ofrecer la posibilidad de usar 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 tener mantenimiento y estar dañados. [178] [179]
30/11/2013: Mesa 10 con OpenGL 3.2, 3.3 y OpenCL 1.0+
18/11/2014: Se realizaron importantes modificaciones al código para dar soporte a Direct3D 9. [180]
15-09-2015: Mesa 11 con OpenGL 4.0, 4.1 y OpenCL 1.2 (incompleto)
15-12-2015: Controlador VIRGL de Mesa 11.1 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)
1 de noviembre de 2016: Mesa 13 con OpenGL 4.4 y OpenGL ES 3.2
13-02-2017: Mesa 17.0 con OpenGL 4.5 y controlador freedreno con OpenGL 3.0 y 3.1
10-05-2017: 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 enormes)
08/12/2017: Controlador AMD Vulkan RADV para Mesa 17.3 totalmente compatible con la prueba Khronos de Vulkan 1.0
18/05/2018: Mesa 18.1 con Vulkan 1.1 (Intel ANV y AMD RADV)
07-09-2018: Mesa 18.2 con OpenGL 4.3 para Soft Driver VIRGL (importante para máquinas virtuales en Cluster Computer en la nube), OpenGL ES 3.1 para Freedreno con Adreno A5xx
11/06/2019: 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]
11/12/2019: Mesa 19.3 lanzó OpenGL 4.6 con Intel i965 con gen 7+ e Iris Gen 8+ opcional
18-03-2020: Mesa 20.0 lanzó OpenGL 4.6 con AMD GCN y Vulkan 1.2 para Intel
27/05/2020: Mesa 20.1 lanzó soporte de vectorización NIR y soporte de memoria virtual compartida para OpenCL en Clover
30/11/2020: Mesa 20.3 ofrece soporte completo para OpenCL 1.2 en Clover [41]
11-03-2021: Soporte inicial de Mesa 21.0 para "D3D12": Direct 3D 12 para WSL2 en Windows 10 con OpenGL 3.3+, ARM Freedreno: OpenGL 3.3+
5 de mayo de 2021: Soporte inicial de Mesa 21.1 para el controlador de GPU Google VirtIO "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 para el 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
09-03-2022: Mesa 22.0 es compatible con Vulkan 1.3 de Intel Anvil y AMD RADV
10/05/2023: Mesa 23.1 OpenCL con Rust: RustiCL para hardware AMD GCN disponible (más hardware en progreso) [182]
30/09/2023: Mesa 23.2 con Apple Asahi OpenGL 3.1 y OpenGL ES 3.0, RADV admite Ray Tracing en AMD RDNA 2 y 3, compatibilidad con 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 utilizando la API OpenGL, que luego podría usar en lugar de VOGL (una biblioteca GL Like Library 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 3D en la CPU . A pesar de esto, la arquitectura interna de Mesa fue diseñada para estar abierta para conectarse a la renderización 3D acelerada por el procesador de gráficos . En esta primera fase, la renderización se realizó indirectamente en el servidor de pantalla , lo que dejó algo de sobrecarga y una velocidad notablemente por detrás del máximo teórico. El Diamond Monster 3D , que usaba el chipset Voodoo Graphics , fue uno de los primeros dispositivos de hardware 3D compatibles con Mesa.
El primer soporte de hardware gráfico real 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 de usar Glide como capa de aceleración era el hábito de Glide de ejecutarse en pantalla completa, lo que solo era adecuado para juegos de computadora. Además, Glide tomaba el bloqueo de la memoria de la pantalla y, por lo tanto, el servidor de pantalla no podía realizar ninguna otra tarea de GUI. [186]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}