Linux what is mesa
OpenGL is an immediate mode graphics programming API originally developed by SGI based on their previous proprietary Iris GL, and became in industry standard several years ago. It is defined and maintained by the Architectural Revision Board (ARB), an organization that includes members as SGI, IBM, and DEC, and Microsoft.
OpenGL provides a complete feature set for 2D and 3D graphics operations in a pipelined hardware accelerated architecture for triangle and polygon rendering. In a broader sense, OpenGL is a powerful and generic toolset for hardware assisted computer graphics.
The official site for OpenGL maintained by the members of the ARB, is www.opengl.org,
A most recommended site is Mark Kilgard’s Gateway to OpenGL Info at reality.sgi.com/mjk_asd/opengl-links.html: it provides pointers to book, online manual pages, GLUT, GLE, Mesa, ports to several OS, tons of demos and tools.
If you are interested in game programming using OpenGL, there is the OpenGL-GameDev-L@fatcity.com at Listserv@fatcity.com . Be warned, this is a high traffic list with very technical content, and you will probably prefer to use procmail to handle the 100 messages per day coming in. You cut down bandwidth using the SET OpenGL-GameDev-L DIGEST command. It is also not appropriate if you are looking for introductions. The archive is handled by the ListServ software, use the INDEX OpenGL-GameDev-L and GET OpenGL-GameDev-L «filename» commands to get a preview before subscribing.
No, Glide is a proprietary 3Dfx API which several features specific to the Voodoo Graphics ™ and Voodoo Rush ™. A 3Dfx OpenGL is in preparation (see below). Several Glide features would require EXTensions to OpenGL, some of which already found in other implementations (e.g. paletted textures).
The closest thing to a hardware accelerated Linux OpenGL you could currently get is Brian Paul’s Mesa along with David Bucciarelli’s Mesa Voodoo driver (see below).
Both the 3Dfx website and the Quantum3D website announced OpenGL for Voodoo Graphics ™ to be available 4Q97. The driver is currently in Beta, and accessible only to registered deverloper’s under written Beta test agreement.
A linux port has not been announced yet.
I am not aware of any third party commercial OpenGL that supports the Voodoo Graphics ™. Last time I paid attention, neither MetroX nor XInside OpenGL did.
Mesa is a free implementation of the OpenGL API, designed and written by Brian Paul, with contributions from many others. Its performance is competitive, and while it is not officially certified, it is an almost fully compliant OpenGL implementation conforming to the ARB specifications — more complete than some commercial products out, actually.
The latest Mesa MesaVer; release works with Linux Glide 2.4. In fact, support was included in earlier versions, however, this driver is still under development, so be prepared for bugs and less than optimal performance. It is steadily improving, though, and bugs are usually fixed very fast.
You will need to get the Mesa library archive from the iris.ssec.wisc.edu FTP site. It is recommended to subscribe to the mailing list as well, especially when trying to track down bugs, hardware, or driver limitations. Make sure to get the most recent distribution. A Mesa-3.0 is in preparation.
It is available for Linux and Win32, and any application based on Mesa will only have the usual system specific code, which should usually mean XWindows vs. Windows, or GLX vs. WGL. If you use e.g. GLUT or Qt, you should get away with any system specifics at all for virtually most applications. There are only a few issues (like sampling relative mouse movement) that are not adressed by the available portable GUI toolkits.
Mesa/Glide is also available for DOS. The port which is 32bit DOS is maintained by Charlie Wallace and kept up to date with the main Mesa base. See www.geocities.com/
charlie_x/.for the most current releases.
The Mesa home page is at www.ssec.wisc.edu/
brianp/Mesa.html. There is an archive of the Mesa mailing list. at www.iqm.unicamp.br/mesa/. This list is not specific to 3Dfx and Glide, but if you are interested in using 3Dfx hardware to accelerate Mesa, it is a good place to start.
For latest information on the Mesa Voodoo driver maintained by David Bucciarelli tech.hmw@plus.it see the home page at www-hmw.caribel.pisa.it/fxmesa/.
Not yet (as of Mesa 2.6), but it is on the list. In Mesa you will probably have to use the OpenGL EXT_multitexture extension once it is available. There is no final specification for multitextures in OpenGL, which is supposed to be part of the upcoming OpenGL 1.2 revision. There might be a Glide driver specific implementation of the extension in upcoming Mesa releases, but as long as only certain Quantum3D Obsidian boards come with multiple TMU’s, it is not a top priority. This will surely change once Voodoo 2 ™ based boards are in widespread use.
Multiple TMU’s should be used for single pass trilinear mipmapping for improvement image quality without performance penalty in current Linux Glide already. Mesa support is not yet done (as of Mesa 2.6), but is in preparation.
The most recent revisions of Mesa contain an experimental feature for Linux XFree86. Basically, the GLX emulation used by Mesa copies the contents of the Voodoo Graphics ™ board’s most recently finished framebuffer content into video memory on each glXSwapBuffers call. This feature is also available with Mesa for Windows.
This obviously puts some drain on the PCI, doubled by the fact that this uses X11 MIT SHM, not XFree86 DGA to access the video memory. The same approach could theoretically be used with e.g. SVGA. The major benefit is that you could use a Voodoo Graphics ™ board for accelerated rendering into a window, and that you don’t have to use the VGA passthrough mode (video output of the VGA board deteoriates in passing through, which is very visible with high end monitors like e.g. EIZO F784-T).
Note that this experimental feature is NOT Voodoo Rush ™ support by any means. It applies only to the Voodoo Graphics ™ based boards. Moreover, you need to use a modified GLUT, as interfacing the window management system and handling the events appropriately has to be done by the application, it is not handled in the driver.
Make really sure that you have enabled the following environment variables: If you manage to forget one of the SST variables, your VGA board will be shut off, and you will loose the display (but not the actual X). It is pretty hard to get that back being effectively blind.
Finally, note that the libMesaGL.a (or .so) library can contain multiple client interfaces. I.e. the GLX, OSMesa, and fxMesa (and even SVGAMesa) interfaces call all be compiled into the same libMesaGL.a. The client program can use any of them freely, even simultaneously if it’s careful.
Mark Kilgard’s GLUT distribution is a very good place to get sample applications plus a lot of useful utilities. You will find it at reality.sgi.com/mjk_asd/glut3/, and you should get it anyway. The current release is GLUT 3.6, and discussion on a GLUT 3.7 (aka GameGLUT) has begun. Note that Mark Kilgard has left SGI recently, so the archive might move some time this year — for the time being it will be kept at SGI.
There is also a GLUT mailing list, glut@perp.com . Send mail to majordomo@perp.com, with the (on of the) following in the body of your email message:
As GLUT handles double buffers, windows, events, and other operations closely tied to hardware and operating system, using GLUT with Voodoo Graphics ™ requires support, which is currently in development within GLX for Mesa. It already works for most cases.
Источник
The Mesa 3D Graphics Library
Open source implementations of OpenGL, OpenGL ES, Vulkan, OpenCL, and more!
Featured APIs
OpenGL is a cross-platform, industry standard graphics programming API for 3D graphics.
OpenGL ES is the mobile subset of OpenGL. It’s supported on all major mobile platforms, and is also the base for WebGL.
Vulkan is the next-generation graphics programming API from The Khronos® Group.
EGL is an interface between Khronos rendering APIs such as OpenGL or OpenVG and the underlying native platform window system.
OpenMAX is a non-proprietary and royalty-free cross-platform set of C-language programming interfaces, provides abstractions for processing of audio, video, and still images.
OpenCL
OpenCL is a framework for writing programs that execute across heterogeneous platforms consisting of CPUs, GPUs, DSPs, FPGAs and other processors or hardware accelerators.
VDPAU
VDPAU is the Video Decode and Presentation API for UNIX. It provides an interface to video decode acceleration and presentation hardware present in modern GPUs.
VA-API
VA-API is an open-source library and API specification, which provides access to graphics hardware acceleration capabilities for video processing.
XvMC is an extension of the X video extension (Xv) for the X Window System. The XvMC API allows video programs to offload portions of the video decoding process to the GPU hardware.
Even though Mesa provides implementations of the APIs listed above, not all combinations of drivers and APIs are formally conformant to their respective specifications.
Supported Drivers
Hardware
The R600 driver supports AMD’s Radeon HD 2000 GPU series. It’s officially supported by AMD, and is one of two Linux drivers for the hardware.
The RadeonSI OpenGL and OpenCL driver supports AMD’s Southern Island GPUs and later. It’s officially supported by AMD, and is one of two Linux drivers for the hardware.
The AMD RADV Vulkan driver supports AMD’s Southern Island GPUs and later. It’s not officially supported by AMD, but it’s based on public information provided by AMD.
The V3D OpenGL driver supports Broadcom’s VC5 and later GPUs, which is found in the Raspberry Pi 4. It’s officially supported by Broadcom, and is the official Linux driver for the hardware. More information…
The V3DV Vulkan driver supports Broadcom’s VC5 and later GPUs, similar to the V3D driver.
The VC4 driver supports Broadcom’s VC4 GPU, which is found among other other things in most of the Raspberry Pis. It’s officially supported by Broadcom, and is one of two Linux drivers for the hardware. More information…
The Etnaviv driver supports the Vivante GCxxx series of embedded GPUs. It’s a reverse-engineered, community-developed driver, and is not endorsed by Vivante. More information…
The Freedreno driver supports the Qualcomm Adreno GPUs, from the A2xx series to the A6xx series. It’s a reverse-engineered, community-developed driver, and is not endorsed by Qualcomm. More information…
The ANV vulkan driver supports Intel’s Gen 7 hardware and later. It’s officially supported by Intel and is their official Vulkan driver for Linux. More information…
The i965 driver supports Intel’s Gen 4 hardware and later. It’s officially supported by Intel and is their default OpenGL driver for Linux. More information…
The Iris driver supports Intel’s Gen 8 hardware and later. It’s officially supported by Intel and is their next-generation Linux OpenGL driver. More information…
Lima is a free and open source driver for the ARM Mali-4xx family of GPUs. It’s a reverse-engineered, community-developed driver, and is not endorsed by ARM. More information…
The Nouveau drivers supports a large set of NVIDIA chips, ranging from NV04 found in the Riva TNT card to NVF0 found in the GeForce GTX 780, as well as most of the Tegra GPUs. It’s a reverse-engineered, community-developed driver, and is not endorsed by NVIDIA. More information…
Panfrost is a free and open source driver for the ARM Mali Midgard and Bifrost GPUs. It’s a reverse-engineered, community-developed driver, and is not endorsed by ARM. More information…
Layered Drivers
The D3D12 driver is a Gallium driver that emits D3D12 API calls instead of targeting a specific GPU architecture. This can be used to get full desktop OpenGL support on devices that only support D3D12, as well as providing hardware acceleration for applications running under WSL. More information…
The SVGA3D driver gives a Linux virtual machine access to the host GPU for hardware-accellerated 3D when running either on VMware hypervisors (Workstation, Fusion, and ESX). It’s officially supported by VMware. More information…
The Venus driver is a virtual Vulkan GPU driver for sharing a GPU with a host for virtual machines. It uses Vulkan on the host to accelerate rendering.
The VirGL driver is a virtual OpenGL GPU driver for sharing a GPU with a host for virtual machines. It uses OpenGL or OpenGL ES on the host to accelerate rendering. More information…
The Zink driver is a Gallium driver that emits Vulkan API calls instead of targeting a specific GPU architecture. This can be used to get full desktop OpenGL support on devices that only support Vulkan. More information…
Software rendering
The LLVMPipe driver is a high-performance software renderer. It’s useful for systems without a dedicated GPU, or in the process of bringing up a platform. It uses LLVM as a code-generator to dynamically compile efficient machine code for the CPU. More information…
The OpenSWR driver is a high performance, highly scalable software renderer targeted towards visualization workloads. More information…
The Softpipe driver is a reference software rasterizer; it’s slow but accurate. It’s mostly useful for testing, and on systems that lacks support for LLVM.
Legacy Hardware
Due to the age of the hardware, these drivers are no longer very actively developed, and they are entirely community maintained.
The R200 driver supports AMD’s Radeon R200 GPU series.
The R300 driver supports AMD’s Radeon R300 GPU series.
The i915 driver supports Intel’s GMA 916G as well as the i830, i845 and i865 integrated GPU series.
Источник
An explanation of what Mesa is and what graphics cards use it
You’ve most likely heard the term “Mesa” thrown around a lot, but you might not quite understand what it is. This is an attempt to clear up the question of “What exactly is Mesa and do I need it?”.
Note: This is an attempt to keep things simple for the average user to understand, so I won’t go overly technical with this.
Mesa is a term used to encompass the different open source graphics drivers available on Linux, so it can be what powers your GPU. I say can be, since AMD and NVIDIA also have their own closed-source proprietary drivers (what you would download from their website on Windows, if that makes that clearer).
Originally, Mesa began only to serve as an open source Linux implementation of OpenGL, but it has since grown to be a lot more than that. Mesa was started in 1993 by Brian Paul, but now it has many more developers, some of which are employed by the likes of AMD, Intel, Valve and others. Linux game porters like Feral Interactive have also contributed code to Mesa. Plenty of people also help with Mesa development in their spare time too.
Mesa itself is not a driver, as you will be using a different part of Mesa for each graphics card vendor. Still with me? Okay!
Mesa implements various API’s (Application programming interface) like OpenGL, OpenGL ES, OpenCL, OpenMAX, VDPAU, VA API, XvMC and Vulkan.
Mesa versioning
Something also worth noting, is that Mesa has switched to a year-based release numbering scheme. This is why Mesa jumped from 13 to 17 in release numbers.
Usually, it is recommended to update to a new major version of Mesa once they have done the first round of bug fixing. If you’re concerned with stability and reliability stick to point release numbers like 17.0.1.
How to find your current version of Mesa
Do this in terminal:
glxinfo | grep Mesa
Which will give you something like this:
Quote OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.0.1
OpenGL version string: 3.0 Mesa 17.0.1
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.0.1
So you can see your Mesa version, along with what version of OpenGL support you have. This will likely show nothing if you’re not using Mesa.
Intel
The story for Intel is mostly pretty simple, if you’re using Intel integrated graphics, you will be using Mesa. Except for the ‘PowerVR’ based chips in the GMA 500, GMA 600, GMA 3600, GMA 3650 series.
Intel usually supports Mesa quite well and even have their own Mesa update tool named ‘Intel® Graphics Update Tool’ to give certain distributions the latest version of Mesa.
Intel also have the ‘anv’ Vulkan driver, which seems to be largely feature complete and should work.
AMD
There are a number of different Mesa drivers available for AMD cards, you can see a little information on that here.
The latest AMD cards use the ‘amdgpu’ kernel driver (the proprietary AMDGPU-PRO also uses a version of this, which has not yet been accepted into the Linux kernel yet), whereas all older cards use the ‘radeon’ kernel driver. Each part of Mesa listed below hooks into one of those kernel drivers, which part depends on your graphics card model.
As mentioned, the kernel driver (either ‘radeon’ or ‘amdgpu’) is paired with one of these:
radeon — R100 series
r200 — R200 series
r300g — R300, R400, and R500 series
r600g — R600, R700, HD 5000 and HD 6000
radeonsi — HD 7000, HD 8000 and RX 200, RX 300 and RX 400
You also have the ‘radv’ driver for Vulkan, which was officially added in Mesa 13. It’s still in development right now, so it’s to be considered in beta.
Right now, most AMD graphics cards have pretty good support in Mesa, with the closed source driver often not being needed. Our own statistics have users telling us that only around 11% of Linux gamers with an AMD GPU use the proprietary AMD driver.
NVIDIA
NVIDIA isn’t quite such a nice story, as NVIDIA doesn’t help towards development of Mesa, since they prefer their own closed-source proprietary drivers. For NVIDIA cards Mesa is typically quite far behind the closed drivers in terms of performance and features due to this. Mesa also typically doesn’t work well, if at all with the very latest generation of NVIDIA graphics cards.
With Mesa, you have the nouveau (pronounced like nu-vo) kernel driver, but like AMD, NVIDIA uses nouveau plus another part of Mesa depending on your graphics card model.
Later generations of NVIDIA cards require something called ‘signed firmware’ in order for Mesa to interact with them and NVIDIA has been quite slow to release it.
The ‘Pascal’ generation in particular right now has very little support, as NVIDIA has only recently provided the signed firmware required.
For NVIDIA, it’s usually best to stick with the proprietary driver. Older generations have reasonable support in Mesa now, but you will still see better performance with the proprietary NVIDIA driver.
Источник
