Talk:Mesa (computer graphics)
|This is the talk page for discussing improvements to the Mesa (computer graphics) article.|
|WikiProject Computing / Software||(Rated Start-class)|
|WikiProject Free Software / Software / Computing||(Rated Start-class, Low-importance)|
Where is it used?
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)
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 184.108.40.206 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
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.--220.127.116.11 (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 http://www.gnu.org/licenses/license-list.html :
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. [...]
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)
Recently the licensing issues have been resolved , therefore the "not free software" note can be removed. —Preceding unsigned comment added by Potatobackwards (talk • contribs) 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: , , ... Or perhaps we could wait until things are settled out. bkil (talk) 17:25, 8 October 2008 (UTC)
- +1 Doors5678 (talk) 17:10, 13 April 2012 (UTC)
- Yes, the project's name is "Mesa". For some reason, the project's domain name is mesa3d.org, however. I imagine this is due to mesa.org's unavailability. --Chealer (talk) 18:18, 6 October 2013 (UTC)
Bad English, fuzzy meaning
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.
What does ALSA have to do with Mesa?
- 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.
Video API implementations
- The storage of motion pictures, aka video, data can requires huge amount of memory, that is storage space.
- To avoid that, video data is being compressed before it is being stored.
- 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...
- the algorithm can be available for free or for a fee; Daala is a royalty-free codec.
- 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.
- 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.
- Video players: load libraries to decompress the stored data, this decompressed data is output to the screen. Examples: VLC media player, GNOME Videos, etc.
- Video container is the denomination of all file formats, that are intended to contain compressed video data and other data. Example: Matroska.
- 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:
- Nvidia PureVideo, to be found on Nvidia products
- Unified Video Decoder, to be found on ATI and AMD products
- Intel Quick Sync Video, to be found on Intel products
- CedarX, on Allwinner Technology products
- Diamond Video Engine, by Tensilica
Semiconductor intellectual property core for the encoding:
Available APIs for the decoding or the encoding of videos are:
- Video Acceleration API, designed by Intel
- VDPAU, designed by Nvidia
- X-Video Bitstream Acceleration, designed by AMD
- Distributed Codec Engine, by Texas Instruments
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.
- http://lists.freedesktop.org/archives/mesa-dev/2013-October/046943.html OpenMAX state tracker 2013-10-24
- VDPAU state tracker
- UVD: http://lists.freedesktop.org/archives/dri-devel/2014-January/051584.html
Is it correct that the development of some code was financed by crowdfunding? See http://www.phoronix.com/scan.php?page=news_item&px=MTQyMTY User:ScotXWt@lk 20:54, 7 June 2014 (UTC)