Talk:Mesa (computer graphics)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Software (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software (marked as Mid-importance).
WikiProject Free Software / Software / Computing  (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
Taskforce icon
This article is supported by WikiProject Computing.

Where is it used?[edit]

Perhaps some information on where its currently used? (IE practical applications of Mesa that exist)

Hmm, maybe we should add a section called Adoption. But it would be either very short: "everywhere" and a hell of a long list. User:ScotXWt@lk 20:51, 7 June 2014 (UTC)

Software only?[edit]

I'd like to point out that the single item in the Disadvantages section is incorrect. Mesa started as a software renderer, but it is now used as the OpenGL-compatible frontend on many hardware drivers. OpenGL is more than just an interface to the hardware, it's a complex state machine and it would be pointless for every hardware driver/manufacturer to reimplement the "frontend". The DRI drivers use the Mesa code for their libGL and the parts that need software emulation. Even before DRI, there were a few hardware drivers included in the Mesa source e.g The 3dfx Voodoo I/II drivers. IIRC, Brian Paul even wrote most of Mesa with the intent of one day driving hardware, so adding the hardware drivers was relatively simple. Imroy 13:51, 2005 Jun 8 (UTC)

Ok, I finally removed the "Disadvantages" section because no-one else had. It only had one item and it was totally false. Apparently didn't even read the Mesa FAQ when he wrote the original:

1.2 Does Mesa support/use graphics hardware?

Yes. Specifically, Mesa serves as the OpenGL core for the open-source XFree86/DRI OpenGL drivers. See the DRI website for more information.

There have been other hardware drivers for Mesa over the years (such as the 3Dfx Glide/Voodoo driver, an old S3 driver, etc) but the DRI drivers are the modern ones.

Imroy July 6, 2005 14:27 (UTC)

Mesa is *not* free software[edit]

gNewSense had to remove it, Debian also has a running discussion on it: [[1]], [[2]], [[3]], [[4]] bkil (talk) 16:28, 5 August 2008 (UTC)

Of course Mesa is Free and open source software (take a look at this page Debian Packages , it is released under the MIT License. The first link you give is 5 years old, and those refers to XFree86.-- (talk) 17:47, 16 August 2008 (UTC)

The worst part of it all is what you just said: this problem has been known for more than 8 years now! If you gave a look at the links, including the final words up to 2008 (and those referenced from there...), you would understand the full issue, and that it has been on the to-do lists for some time. I repeat: gNewSense has removed all of its 3D support just because of this 'minor' issue. Some of the 'infected' source had spread around Xorg (that's why it's been initially filed at the xfree86 package), but gNewSense has more or less successfully isolated the offending parts. GNU GPL software can only be combined with files using so called GNU compatible licenses, which some of the Mesa sources fail to adhere. To my limited legal understandig, this means that Mesa can not be free software. It could be called open source, if the remaining parts did not use the GPL, but to this point, I'm not sure if the package is legal at all! If you feel the issue has been resolved, please post links to the resolution here, I'm putting the fact tag back until then, if you don't mind. Thank you for your feedback, do keep us posted. bkil (talk) 18:12, 22 August 2008 (UTC)

Quote from :

SGI Free Software License B, version 1.1
   The SGI Free Software License B, although its name says “free”, is not a free software License. [...]

bkil (talk) 18:12, 22 August 2008 (UTC)

Whatever I said, minus the GPL part. So it might end up being a validly licensed open source (but not free software) package. Sorry, but I'm too tired to sort that out at the moment... bkil (talk) 18:29, 22 August 2008 (UTC)

I've received no response from the given editor, and so I've taken the liberty to insert a sentence on the issue. A similarly passive mentality resulted in the problem being "forgotten" for so many years. And by the way, the first link is not from 5 years ago, you would have noticed that if you had given it a few minutes. bkil (talk) 11:31, 6 September 2008 (UTC)

Oops... sorry for that issue with 'its.' :) I'll try to pay more attention next time. bkil (talk) 18:16, 9 September 2008 (UTC)

Recently the licensing issues have been resolved [5], therefore the "not free software" note can be removed. —Preceding unsigned comment added by Potatobackwards (talkcontribs) 18:51, 22 September 2008 (UTC)

Splendid! Thank you for the information Potatobackwards. :) I can't wait to see 3D in gNewSense again! ;) They say full negotiations with later contributors to the licensed parts could take a month or so. Maybe we could copy the link you've given to the main article, or even one or more of these: [6], [7], ... Or perhaps we could wait until things are settled out. bkil (talk) 17:25, 8 October 2008 (UTC)


Can someone say a few words about the relations between Mesa 3D and GLX? Thanks, --Abdull (talk) 13:12, 26 February 2010 (UTC)

Done, see Mesa (computer graphics)#Implementations of rendering APIs.


Is there a reason the title isn't "Mesa 3D"? —danhash (talk) 13:31, 28 September 2011 (UTC)

+1 Doors5678 (talk) 17:10, 13 April 2012 (UTC)
It really should be Mesa 3D ScotXW (talk) 11:10, 8 September 2013 (UTC)
Yes, the project's name is "Mesa". For some reason, the project's domain name is, however. I imagine this is due to's unavailability. --Chealer (talk) 18:18, 6 October 2013 (UTC)

Bad English, fuzzy meaning[edit]


This is my first post to any "talk" page so be kind (even if maybe it seems that I am not).

I just felt compelled to note that the final paragraph in the "History" segment of this article really ought to be rewritten by someone who speaks English. OK, sorry. I don't mean to be a wise-ass. It's just that the verbiage in that paragraph, particularly the first sentence of the paragraph, definitely needs work. I started to try to just simply clean up the English usage in that paragraph myself, but then I realized that I could not effectively do so for the simple reasons that (a) I have little or no knowledge of the subject matter in the first place and also (b) I can't even totally puzzle out what exactly the original author was even _trying_ to say in the paragraph in question. (I can't paraphrase or re-write something that's not even entirely comprehensible in the first place.)

So I guess that the original author is/was trying to say that Mesa is composed of pieces (which he calls "components" in one place and "modules" elsewhere in the same paragraph) and that the interfaces between the pieces are generally stable, and that this fact in turn allows the separate pieces to evolve on their own while still inter-operating with the whole.

Basically, it appears that this entire paragraph is only there so that the author could say (in effect, and three separate times in three separate and different ways) that the parts of Mesa can and have evolved separately.

Separate sub-components and stable internal interfaces are not exactly novel concepts, so I'm kind of left wondering why this aspect of Mesa is even worthy of special mention, let alone why it might best appear in a "History" section, of all places.

As I say, I would be happy to take a whack at revising this paragraph myself, but I thought that I should post here first and see what people who know the subject matter better than I do... which is to say everybody... might have to say.

Rfg-ronbaby (talk) 20:53, 21 October 2012 (UTC)

What does ALSA have to do with Mesa?[edit]

While the fundraising-campains of Mozilla have been very successful, there are only 3.5 people working full-time on the Linux ALSA audio drivers.

I don't think the above is relevant to this article given that ALSA is for sound drivers and nothing to do with graphics. (talk) 11:34, 29 October 2013 (UTC)

Video API implementations[edit]

  1. The storage of motion pictures, aka video, data can requires huge amount of memory, that is storage space.
  2. To avoid that, video data is being compressed before it is being stored.
  3. Video codec is the denomination for all the compression algorithms, whether lossless or lossy that are intended to compress video data. But see the sloppy and unmaintained comparison of video codecs-article...
    1. the algorithm can be available for free or for a fee; Daala is a royalty-free codec.
    2. property rights: the development of such compression algorithms costs money, but AFAIK (User:ScotXW), in most countries of the world, neither the copyright nor the patent right covers algorithm. But albeit from highway robbery, the collection of any royalty fee must be based on some property rights, thus some countries adopted something called software patent. So based upon that, the developers (and patent trolls) collect money. Sometimes this fee is only collected from entities en-coding data. Sometimes entities de-coding have to pay as well. Note that, to avoid all of this fuss, a video compression algorithm could be kept secret and only binary implementation on dongled black-boxes could be distributed to encoders and decoders and the braking of the black-box protection could be forbidden by law.
    3. Implementation: an algorithm must be implemented into software, and then this software can be executed on a computer. For one algorithm, there can be numerous software implementations. Any software is subject to copyright, Mesa is published under a free and open-source license. There are implementations of video compression algorithms, that are published under a free and open-source license as well. There are projects, which comprise a lot of implementations. To avoid code duplication, most implementations are written as software libraries.
    4. Video players: load libraries to decompress the stored data, this decompressed data is output to the screen. Examples: VLC media player, GNOME Videos, etc.
  4. Video container is the denomination of all file formats, that are intended to contain compressed video data and other data. Example: Matroska.
    1. Implementation: again, for a program (file browser, video player, video editor) to be able to deal with any file, there must be some software implementation for the file format. A video player used this library to load the file and then the other library to decompress the video data...

The en-coding as well as the de-coding of the data, that is the application of the codec, that is the execution of its implementation, cost huge amount of CPU time, thus some of the operation have either been outsourced to the GPU (this can consume huge amounts of electrical current) or implemented into silicon. For example, the Radeon HD 2600 had so much computation power, that AMD decided to omit the UVD core and as a result, viewing a video on such a graphics cards, requires the hardware driver to implement the codec in software and also consumes a lot more electrical current.

Semiconductor intellectual property core for the decoding:

Semiconductor intellectual property core for the encoding:

Available APIs for the decoding or the encoding of videos are:

What are these and how do they relate to Mesa, the video compression codec SIP cores and application software? The Video APIs are meant to simplify access of programs to the Video-related parts of the GPUs. There are more then the three mentioned above, but AFAIK only two are relevant for Mesa. A Video API should related to Video player, as the OpenGL API relates to a game engine. It connects the player to the device driver.


Is it correct that the development of some code was financed by crowdfunding? See User:ScotXWt@lk 20:54, 7 June 2014 (UTC)


Regarding Mesa 11.0[edit]

On the onset of Mesa 11.0's release, this article needs to accommodate more info about Mesa 11.0. Whether it is something unclear on the talk about Mesa or this article, but I think a section about 11.0 should be added, as well as clarification that later versions of OpenGL won't affect all drivers. Vormeph 20:41, 26 August 2015 (UTC)

I agree. The third paragraph under Implementations of rendering APIs could be expanded. It would be too exhaustive to mention all drivers though and it does not belong in the corresponding table. Now it seems to imply that other drivers actually support OpenGL 4.2. -- Lightkey (talk) 21:13, 10 September 2015 (UTC)

Compact version table[edit]

I suggest we compact the version table, dropping al minor (.x) releases. They provide no extra information, because the supported OpenGL, EGL, etc versions are equal across the major release. The result would look like this:

API OpenGL OpenGL ES OpenVG EGL GLX Direct3D
Version Date 4.5
Current stable version: 11 2015-09-11 4.2 (Intel 3.3) 3.0 N/A 1.5 1.4 9.0c
Older version, yet still supported: 10 2013-11-30 3.3 3.0 1.1 1.4 1.4 9.0c
Old version, no longer supported: 9 2012-10-08 3.1 2.0 1.1 1.4 1.4 N/A
Old version, no longer supported: 8 2012-02-08 3.0 2.0 1.1 1.4 1.4 N/A
Old version, no longer supported: 7 2007-06-22 2.1 N/A N/A N/A 1.4 N/A
Old version, no longer supported: 6 2004-01-06 1.5 N/A N/A N/A 1.3 N/A
Old version, no longer supported: 5 2002-11-13 1.4 N/A N/A N/A 1.3 N/A
Old version, no longer supported: 4 2001-10-22 1.3 N/A N/A N/A 1.3 N/A
Old version
Older version, still supported
Latest version
Latest preview version
Future release

What do you think? Lonaowna (talk) 12:14, 15 September 2015 (UTC)

I agree. For a detailed history of all released versions I would suggest to add a "Releases" section with a second table ("Version", "Release date" and "New features" columns) like this or this. --JavierCantero (talk) 14:49, 15 September 2015 (UTC)
Why does intel have its own entry in the table? It's not as if all (as a matter of fact, any...) the other drivers supported OpenGL 4.2 ( ).
Also in the case of a separate table, I'd suggest adding the state of each driver. — Preceding unsigned comment added by (talk) 11:43, 8 December 2015 (UTC)
Agree with here and replying to JavierCantero's suggestion from the Vulkan section below, I think the current table should also include every minor Mesa version in which support for any of the other APIs changed, not just OpenGL. -- Lightkey (talk) 20:00, 18 February 2016 (UTC)


I reverted the change of Vulkan support in Mesa 11.2 as Jason Ekstrand from intel wrote that it will still need a few weeks and will end up in 11.3 at the earliest, since 11.2 will be branched tomorrow and only bugfixes allowed after that.

I question the inclusion of Vulkan in the API table as well, since there will be no shared libraries between drivers like for the other APIs, which means it's up to each driver to implement Vulkan. -- Lightkey (talk) 16:53, 18 February 2016 (UTC)

I agree. Also, that table is for API versions changes, not for Mesa version changes —new rows should only be added when there's a major version of Mesa like 12. --JavierCantero (talk) 18:41, 18 February 2016 (UTC


New Software Rasterizer for Cluster with much more Performance.

See and and actual For more.