From 2702c90d7a39fca2a3319c5e915fd290cb31fc70 Mon Sep 17 00:00:00 2001 From: Radosław Kujawa Date: Fri, 17 Jul 2026 14:54:32 +0200 Subject: Initial import. --- docs/COPYING | 490 +++++ docs/MESA_agp_offset.spec | 95 + docs/MESA_copy_sub_buffer.spec | 88 + docs/MESA_pack_invert.spec | 138 ++ docs/MESA_packed_depth_stencil.spec | 231 +++ docs/MESA_pixmap_colormap.spec | 90 + docs/MESA_program_debug.spec | 357 ++++ docs/MESA_release_buffers.spec | 85 + docs/MESA_resize_buffers.spec | 82 + docs/MESA_set_3dfx_mode.spec | 85 + docs/MESA_sprite_point.spec | 191 ++ docs/MESA_swap_control.spec | 132 ++ docs/MESA_swap_frame_usage.spec | 201 ++ docs/MESA_trace.spec | 360 ++++ docs/MESA_window_pos.spec | 127 ++ docs/MESA_ycbcr_texture.spec | 204 ++ docs/MiniGLX.html | 547 ++++++ docs/README.3DFX | 828 ++++++++ docs/README.AMIWIN | 181 ++ docs/README.BEOS | 134 ++ docs/README.CYGWIN | 256 +++ docs/README.D3D | 124 ++ docs/README.DJ | 267 +++ docs/README.GGI | 26 + docs/README.LYNXOS | 64 + docs/README.MINGW32 | 81 + docs/README.MITS | 102 + docs/README.NeXT | 6 + docs/README.OS2 | 96 + docs/README.OpenStep | 35 + docs/README.QUAKE | 208 ++ docs/README.THREADS | 52 + docs/README.VMS | 28 + docs/README.WIN32 | 108 ++ docs/README.WINDML | 146 ++ docs/README.X11 | 314 +++ docs/RELNOTES-3.1 | 146 ++ docs/RELNOTES-3.2 | 12 + docs/RELNOTES-3.2.1 | 32 + docs/RELNOTES-3.3 | 271 +++ docs/RELNOTES-3.4 | 22 + docs/RELNOTES-3.4.1 | 22 + docs/RELNOTES-3.4.2 | 22 + docs/RELNOTES-3.5 | 228 +++ docs/RELNOTES-4.0 | 163 ++ docs/RELNOTES-4.0.1 | 22 + docs/RELNOTES-4.0.2 | 50 + docs/RELNOTES-4.0.3 | 52 + docs/RELNOTES-4.1 | 308 +++ docs/RELNOTES-5.0 | 85 + docs/RELNOTES-5.0.1 | 46 + docs/RELNOTES-5.0.2 | 46 + docs/RELNOTES-5.1 | 279 +++ docs/RELNOTES-6.0 | 87 + docs/RELNOTES-6.0.1 | 50 + docs/RELNOTES-6.1 | 112 ++ docs/RELNOTES-6.2 | 49 + docs/RELNOTES-6.2.1 | 50 + docs/VERSIONS | 1336 +++++++++++++ docs/banner.html | 15 + docs/bugs.html | 47 + docs/conform.html | 693 +++++++ docs/contents.html | 81 + docs/custom.html | 25 + docs/cvs_access.html | 102 + docs/cvs_branches.html | 78 + docs/debugging.html | 36 + docs/demos.html | 16 + docs/devinfo.html | 240 +++ docs/download.html | 104 + docs/envvars.html | 40 + docs/extensions.html | 32 + docs/faq.html | 383 ++++ docs/fbdev-dri.html | 313 +++ docs/games.html | 62 + docs/glfbdev-driver.html | 88 + docs/glu.html | 43 + docs/helpwanted.html | 62 + docs/index.html | 23 + docs/install.html | 265 +++ docs/intro.html | 302 +++ docs/libraries.html | 55 + docs/license.html | 115 ++ docs/lists.html | 51 + docs/mangling.html | 26 + docs/modelers.html | 68 + docs/news.html | 963 ++++++++++ docs/osmesa.html | 75 + docs/pbuffers.html | 51 + docs/perf.html | 66 + docs/precompiled.html | 24 + docs/relnotes.html | 39 + docs/science.html | 70 + docs/sourcedocs.html | 24 + docs/subset-A.html | 3579 +++++++++++++++++++++++++++++++++++ docs/subset.html | 31 + docs/systems.html | 109 ++ docs/thanks.html | 124 ++ docs/utilities.html | 24 + docs/utility.html | 42 + docs/webmaster.html | 22 + 101 files changed, 18657 insertions(+) create mode 100644 docs/COPYING create mode 100644 docs/MESA_agp_offset.spec create mode 100644 docs/MESA_copy_sub_buffer.spec create mode 100644 docs/MESA_pack_invert.spec create mode 100644 docs/MESA_packed_depth_stencil.spec create mode 100644 docs/MESA_pixmap_colormap.spec create mode 100644 docs/MESA_program_debug.spec create mode 100644 docs/MESA_release_buffers.spec create mode 100644 docs/MESA_resize_buffers.spec create mode 100644 docs/MESA_set_3dfx_mode.spec create mode 100644 docs/MESA_sprite_point.spec create mode 100644 docs/MESA_swap_control.spec create mode 100644 docs/MESA_swap_frame_usage.spec create mode 100644 docs/MESA_trace.spec create mode 100644 docs/MESA_window_pos.spec create mode 100644 docs/MESA_ycbcr_texture.spec create mode 100644 docs/MiniGLX.html create mode 100644 docs/README.3DFX create mode 100644 docs/README.AMIWIN create mode 100644 docs/README.BEOS create mode 100644 docs/README.CYGWIN create mode 100644 docs/README.D3D create mode 100644 docs/README.DJ create mode 100644 docs/README.GGI create mode 100644 docs/README.LYNXOS create mode 100644 docs/README.MINGW32 create mode 100644 docs/README.MITS create mode 100644 docs/README.NeXT create mode 100644 docs/README.OS2 create mode 100644 docs/README.OpenStep create mode 100644 docs/README.QUAKE create mode 100644 docs/README.THREADS create mode 100644 docs/README.VMS create mode 100644 docs/README.WIN32 create mode 100644 docs/README.WINDML create mode 100644 docs/README.X11 create mode 100644 docs/RELNOTES-3.1 create mode 100644 docs/RELNOTES-3.2 create mode 100644 docs/RELNOTES-3.2.1 create mode 100644 docs/RELNOTES-3.3 create mode 100644 docs/RELNOTES-3.4 create mode 100644 docs/RELNOTES-3.4.1 create mode 100644 docs/RELNOTES-3.4.2 create mode 100644 docs/RELNOTES-3.5 create mode 100644 docs/RELNOTES-4.0 create mode 100644 docs/RELNOTES-4.0.1 create mode 100644 docs/RELNOTES-4.0.2 create mode 100644 docs/RELNOTES-4.0.3 create mode 100644 docs/RELNOTES-4.1 create mode 100644 docs/RELNOTES-5.0 create mode 100644 docs/RELNOTES-5.0.1 create mode 100644 docs/RELNOTES-5.0.2 create mode 100644 docs/RELNOTES-5.1 create mode 100644 docs/RELNOTES-6.0 create mode 100644 docs/RELNOTES-6.0.1 create mode 100644 docs/RELNOTES-6.1 create mode 100644 docs/RELNOTES-6.2 create mode 100644 docs/RELNOTES-6.2.1 create mode 100644 docs/VERSIONS create mode 100644 docs/banner.html create mode 100644 docs/bugs.html create mode 100644 docs/conform.html create mode 100644 docs/contents.html create mode 100644 docs/custom.html create mode 100644 docs/cvs_access.html create mode 100644 docs/cvs_branches.html create mode 100644 docs/debugging.html create mode 100644 docs/demos.html create mode 100644 docs/devinfo.html create mode 100644 docs/download.html create mode 100644 docs/envvars.html create mode 100644 docs/extensions.html create mode 100644 docs/faq.html create mode 100644 docs/fbdev-dri.html create mode 100644 docs/games.html create mode 100644 docs/glfbdev-driver.html create mode 100644 docs/glu.html create mode 100644 docs/helpwanted.html create mode 100644 docs/index.html create mode 100644 docs/install.html create mode 100644 docs/intro.html create mode 100644 docs/libraries.html create mode 100644 docs/license.html create mode 100644 docs/lists.html create mode 100644 docs/mangling.html create mode 100644 docs/modelers.html create mode 100644 docs/news.html create mode 100644 docs/osmesa.html create mode 100644 docs/pbuffers.html create mode 100644 docs/perf.html create mode 100644 docs/precompiled.html create mode 100644 docs/relnotes.html create mode 100644 docs/science.html create mode 100644 docs/sourcedocs.html create mode 100644 docs/subset-A.html create mode 100644 docs/subset.html create mode 100644 docs/systems.html create mode 100644 docs/thanks.html create mode 100644 docs/utilities.html create mode 100644 docs/utility.html create mode 100644 docs/webmaster.html (limited to 'docs') diff --git a/docs/COPYING b/docs/COPYING new file mode 100644 index 0000000..b88946c --- /dev/null +++ b/docs/COPYING @@ -0,0 +1,490 @@ + +Some parts of Mesa are copyrighted under the GNU LGPL. See the +Mesa/docs/COPYRIGHT file for details. + +The following is the standard GNU copyright file. +---------------------------------------------------------------------- + + + GNU LIBRARY GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1991 Free Software Foundation, Inc. + 675 Mass Ave, Cambridge, MA 02139, USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +[This is the first released version of the library GPL. It is + numbered 2 because it goes with version 2 of the ordinary GPL.] + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +Licenses are intended to guarantee your freedom to share and change +free software--to make sure the software is free for all its users. + + This license, the Library General Public License, applies to some +specially designated Free Software Foundation software, and to any +other libraries whose authors decide to use it. You can use it for +your libraries, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if +you distribute copies of the library, or if you modify it. + + For example, if you distribute copies of the library, whether gratis +or for a fee, you must give the recipients all the rights that we gave +you. You must make sure that they, too, receive or can get the source +code. If you link a program with the library, you must provide +complete object files to the recipients so that they can relink them +with the library, after making changes to the library and recompiling +it. And you must show them these terms so they know their rights. + + Our method of protecting your rights has two steps: (1) copyright +the library, and (2) offer you this license which gives you legal +permission to copy, distribute and/or modify the library. + + Also, for each distributor's protection, we want to make certain +that everyone understands that there is no warranty for this free +library. If the library is modified by someone else and passed on, we +want its recipients to know that what they have is not the original +version, so that any problems introduced by others will not reflect on +the original authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that companies distributing free +software will individually obtain patent licenses, thus in effect +transforming the program into proprietary software. To prevent this, +we have made it clear that any patent must be licensed for everyone's +free use or not licensed at all. + + Most GNU software, including some libraries, is covered by the ordinary +GNU General Public License, which was designed for utility programs. This +license, the GNU Library General Public License, applies to certain +designated libraries. This license is quite different from the ordinary +one; be sure to read it in full, and don't assume that anything in it is +the same as in the ordinary license. + + The reason we have a separate public license for some libraries is that +they blur the distinction we usually make between modifying or adding to a +program and simply using it. Linking a program with a library, without +changing the library, is in some sense simply using the library, and is +analogous to running a utility program or application program. However, in +a textual and legal sense, the linked executable is a combined work, a +derivative of the original library, and the ordinary General Public License +treats it as such. + + Because of this blurred distinction, using the ordinary General +Public License for libraries did not effectively promote software +sharing, because most developers did not use the libraries. We +concluded that weaker conditions might promote sharing better. + + However, unrestricted linking of non-free programs would deprive the +users of those programs of all benefit from the free status of the +libraries themselves. This Library General Public License is intended to +permit developers of non-free programs to use free libraries, while +preserving your freedom as a user of such programs to change the free +libraries that are incorporated in them. (We have not seen how to achieve +this as regards changes in header files, but we have achieved it as regards +changes in the actual functions of the Library.) The hope is that this +will lead to faster development of free libraries. + + The precise terms and conditions for copying, distribution and +modification follow. Pay close attention to the difference between a +"work based on the library" and a "work that uses the library". The +former contains code derived from the library, while the latter only +works together with the library. + + Note that it is possible for a library to be covered by the ordinary +General Public License rather than by this special one. + + GNU LIBRARY GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License Agreement applies to any software library which +contains a notice placed by the copyright holder or other authorized +party saying it may be distributed under the terms of this Library +General Public License (also called "this License"). Each licensee is +addressed as "you". + + A "library" means a collection of software functions and/or data +prepared so as to be conveniently linked with application programs +(which use some of those functions and data) to form executables. + + The "Library", below, refers to any such software library or work +which has been distributed under these terms. A "work based on the +Library" means either the Library or any derivative work under +copyright law: that is to say, a work containing the Library or a +portion of it, either verbatim or with modifications and/or translated +straightforwardly into another language. (Hereinafter, translation is +included without limitation in the term "modification".) + + "Source code" for a work means the preferred form of the work for +making modifications to it. For a library, complete source code means +all the source code for all modules it contains, plus any associated +interface definition files, plus the scripts used to control compilation +and installation of the library. + + Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running a program using the Library is not restricted, and output from +such a program is covered only if its contents constitute a work based +on the Library (independent of the use of the Library in a tool for +writing it). Whether that is true depends on what the Library does +and what the program that uses the Library does. + + 1. You may copy and distribute verbatim copies of the Library's +complete source code as you receive it, in any medium, provided that +you conspicuously and appropriately publish on each copy an +appropriate copyright notice and disclaimer of warranty; keep intact +all the notices that refer to this License and to the absence of any +warranty; and distribute a copy of this License along with the +Library. + + You may charge a fee for the physical act of transferring a copy, +and you may at your option offer warranty protection in exchange for a +fee. + + 2. You may modify your copy or copies of the Library or any portion +of it, thus forming a work based on the Library, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) The modified work must itself be a software library. + + b) You must cause the files modified to carry prominent notices + stating that you changed the files and the date of any change. + + c) You must cause the whole of the work to be licensed at no + charge to all third parties under the terms of this License. + + d) If a facility in the modified Library refers to a function or a + table of data to be supplied by an application program that uses + the facility, other than as an argument passed when the facility + is invoked, then you must make a good faith effort to ensure that, + in the event an application does not supply such function or + table, the facility still operates, and performs whatever part of + its purpose remains meaningful. + + (For example, a function in a library to compute square roots has + a purpose that is entirely well-defined independent of the + application. Therefore, Subsection 2d requires that any + application-supplied function or table used by this function must + be optional: if the application does not supply it, the square + root function must still compute square roots.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Library, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Library, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote +it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Library. + +In addition, mere aggregation of another work not based on the Library +with the Library (or with a work based on the Library) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may opt to apply the terms of the ordinary GNU General Public +License instead of this License to a given copy of the Library. To do +this, you must alter all the notices that refer to this License, so +that they refer to the ordinary GNU General Public License, version 2, +instead of to this License. (If a newer version than version 2 of the +ordinary GNU General Public License has appeared, then you can specify +that version instead if you wish.) Do not make any other change in +these notices. + + Once this change is made in a given copy, it is irreversible for +that copy, so the ordinary GNU General Public License applies to all +subsequent copies and derivative works made from that copy. + + This option is useful when you wish to copy part of the code of +the Library into a program that is not a library. + + 4. You may copy and distribute the Library (or a portion or +derivative of it, under Section 2) in object code or executable form +under the terms of Sections 1 and 2 above provided that you accompany +it with the complete corresponding machine-readable source code, which +must be distributed under the terms of Sections 1 and 2 above on a +medium customarily used for software interchange. + + If distribution of object code is made by offering access to copy +from a designated place, then offering equivalent access to copy the +source code from the same place satisfies the requirement to +distribute the source code, even though third parties are not +compelled to copy the source along with the object code. + + 5. A program that contains no derivative of any portion of the +Library, but is designed to work with the Library by being compiled or +linked with it, is called a "work that uses the Library". Such a +work, in isolation, is not a derivative work of the Library, and +therefore falls outside the scope of this License. + + However, linking a "work that uses the Library" with the Library +creates an executable that is a derivative of the Library (because it +contains portions of the Library), rather than a "work that uses the +library". The executable is therefore covered by this License. +Section 6 states terms for distribution of such executables. + + When a "work that uses the Library" uses material from a header file +that is part of the Library, the object code for the work may be a +derivative work of the Library even though the source code is not. +Whether this is true is especially significant if the work can be +linked without the Library, or if the work is itself a library. The +threshold for this to be true is not precisely defined by law. + + If such an object file uses only numerical parameters, data +structure layouts and accessors, and small macros and small inline +functions (ten lines or less in length), then the use of the object +file is unrestricted, regardless of whether it is legally a derivative +work. (Executables containing this object code plus portions of the +Library will still fall under Section 6.) + + Otherwise, if the work is a derivative of the Library, you may +distribute the object code for the work under the terms of Section 6. +Any executables containing that work also fall under Section 6, +whether or not they are linked directly with the Library itself. + + 6. As an exception to the Sections above, you may also compile or +link a "work that uses the Library" with the Library to produce a +work containing portions of the Library, and distribute that work +under terms of your choice, provided that the terms permit +modification of the work for the customer's own use and reverse +engineering for debugging such modifications. + + You must give prominent notice with each copy of the work that the +Library is used in it and that the Library and its use are covered by +this License. You must supply a copy of this License. If the work +during execution displays copyright notices, you must include the +copyright notice for the Library among them, as well as a reference +directing the user to the copy of this License. Also, you must do one +of these things: + + a) Accompany the work with the complete corresponding + machine-readable source code for the Library including whatever + changes were used in the work (which must be distributed under + Sections 1 and 2 above); and, if the work is an executable linked + with the Library, with the complete machine-readable "work that + uses the Library", as object code and/or source code, so that the + user can modify the Library and then relink to produce a modified + executable containing the modified Library. (It is understood + that the user who changes the contents of definitions files in the + Library will not necessarily be able to recompile the application + to use the modified definitions.) + + b) Accompany the work with a written offer, valid for at + least three years, to give the same user the materials + specified in Subsection 6a, above, for a charge no more + than the cost of performing this distribution. + + c) If distribution of the work is made by offering access to copy + from a designated place, offer equivalent access to copy the above + specified materials from the same place. + + d) Verify that the user has already received a copy of these + materials or that you have already sent this user a copy. + + For an executable, the required form of the "work that uses the +Library" must include any data and utility programs needed for +reproducing the executable from it. However, as a special exception, +the source code distributed need not include anything that is normally +distributed (in either source or binary form) with the major +components (compiler, kernel, and so on) of the operating system on +which the executable runs, unless that component itself accompanies +the executable. + + It may happen that this requirement contradicts the license +restrictions of other proprietary libraries that do not normally +accompany the operating system. Such a contradiction means you cannot +use both them and the Library together in an executable that you +distribute. + + 7. You may place library facilities that are a work based on the +Library side-by-side in a single library together with other library +facilities not covered by this License, and distribute such a combined +library, provided that the separate distribution of the work based on +the Library and of the other library facilities is otherwise +permitted, and provided that you do these two things: + + a) Accompany the combined library with a copy of the same work + based on the Library, uncombined with any other library + facilities. This must be distributed under the terms of the + Sections above. + + b) Give prominent notice with the combined library of the fact + that part of it is a work based on the Library, and explaining + where to find the accompanying uncombined form of the same work. + + 8. You may not copy, modify, sublicense, link with, or distribute +the Library except as expressly provided under this License. Any +attempt otherwise to copy, modify, sublicense, link with, or +distribute the Library is void, and will automatically terminate your +rights under this License. However, parties who have received copies, +or rights, from you under this License will not have their licenses +terminated so long as such parties remain in full compliance. + + 9. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Library or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Library (or any work based on the +Library), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Library or works based on it. + + 10. Each time you redistribute the Library (or any work based on the +Library), the recipient automatically receives a license from the +original licensor to copy, distribute, link with or modify the Library +subject to these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 11. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Library at all. For example, if a patent +license would not permit royalty-free redistribution of the Library by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Library. + +If any portion of this section is held invalid or unenforceable under any +particular circumstance, the balance of the section is intended to apply, +and the section as a whole is intended to apply in other circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 12. If the distribution and/or use of the Library is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Library under this License may add +an explicit geographical distribution limitation excluding those countries, +so that distribution is permitted only in or among countries not thus +excluded. In such case, this License incorporates the limitation as if +written in the body of this License. + + 13. The Free Software Foundation may publish revised and/or new +versions of the Library General Public License from time to time. +Such new versions will be similar in spirit to the present version, +but may differ in detail to address new problems or concerns. + +Each version is given a distinguishing version number. If the Library +specifies a version number of this License which applies to it and +"any later version", you have the option of following the terms and +conditions either of that version or of any later version published by +the Free Software Foundation. If the Library does not specify a +license version number, you may choose any version ever published by +the Free Software Foundation. + + 14. If you wish to incorporate parts of the Library into other free +programs whose distribution conditions are incompatible with these, +write to the author to ask for permission. For software which is +copyrighted by the Free Software Foundation, write to the Free +Software Foundation; we sometimes make exceptions for this. Our +decision will be guided by the two goals of preserving the free status +of all derivatives of our free software and of promoting the sharing +and reuse of software generally. + + NO WARRANTY + + 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO +WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. +EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR +OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY +KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE +LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME +THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. + + 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN +WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY +AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU +FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR +CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE +LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING +RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A +FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF +SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH +DAMAGES. + + END OF TERMS AND CONDITIONS + + Appendix: How to Apply These Terms to Your New Libraries + + If you develop a new library, and you want it to be of the greatest +possible use to the public, we recommend making it free software that +everyone can redistribute and change. You can do so by permitting +redistribution under these terms (or, alternatively, under the terms of the +ordinary General Public License). + + To apply these terms, attach the following notices to the library. It is +safest to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least the +"copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + + This library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with this library; if not, write to the Free + Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + +Also add information on how to contact you by electronic and paper mail. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the library, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the + library `Frob' (a library for tweaking knobs) written by James Random Hacker. + + , 1 April 1990 + Ty Coon, President of Vice + +That's all there is to it! + diff --git a/docs/MESA_agp_offset.spec b/docs/MESA_agp_offset.spec new file mode 100644 index 0000000..8dcc723 --- /dev/null +++ b/docs/MESA_agp_offset.spec @@ -0,0 +1,95 @@ +Name + + MESA_agp_offset + +Name Strings + + GLX_MESA_agp_offset + +Contact + + Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com) + Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com) + +Status + + Shipping (Mesa 4.0.4 and later. Only implemented in particular + XFree86/DRI drivers.) + +Version + + 1.0 + +Number + + TBD + +Dependencies + + OpenGL 1.0 or later is required + GLX_NV_vertex_array_range is required. + This extensions is written against the OpenGL 1.4 Specification. + +Overview + + This extensions provides a way to convert pointers in an AGP memory + region into byte offsets into the AGP aperture. + Note, this extension depends on GLX_NV_vertex_array_range, for which + no real specification exists. See GL_NV_vertex_array_range for more + information. + +IP Status + + None + +Issues + + None + +New Procedures and Functions + + unsigned int glXGetAGPOffsetMESA( const void *pointer ) + +New Tokens + + None + +Additions to the OpenGL 1.4 Specification + + None + +Additions to Chapter 3 the GLX 1.4 Specification (Functions and Errors) + + Add a new section, 3.6 as follows: + + 3.6 AGP Memory Access + + On "PC" computers, AGP memory can be allocated with glXAllocateMemoryNV + and freed with glXFreeMemoryNV. Sometimes it's useful to know where a + block of AGP memory is located with respect to the start of the AGP + aperature. The function + + GLuint glXGetAGPOffsetMESA( const GLvoid *pointer ) + + Returns the offset of the given memory block from the start of AGP + memory in basic machine units (i.e. bytes). If pointer is invalid + the value ~0 will be returned. + +GLX Protocol + + None. This is a client side-only extension. + +Errors + + glXGetAGPOffsetMESA will return ~0 if the pointer does not point to + an AGP memory region. + +New State + + None + +Revision History + + 20 September 2002 - Initial draft + 2 October 2002 - finished GLX chapter 3 additions + 27 July 2004 - use unsigned int instead of GLuint, void instead of GLvoid diff --git a/docs/MESA_copy_sub_buffer.spec b/docs/MESA_copy_sub_buffer.spec new file mode 100644 index 0000000..43424a5 --- /dev/null +++ b/docs/MESA_copy_sub_buffer.spec @@ -0,0 +1,88 @@ +Name + + MESA_copy_sub_buffer + +Name Strings + + GLX_MESA_copy_sub_buffer + +Contact + + Brian Paul (brian.paul 'at' tungstengraphics.com) + +Status + + Shipping since Mesa 2.6 in February, 1998. + +Version + + Last Modified Date: 8 June 2000 + +Number + + 215 + +Dependencies + + OpenGL 1.0 or later is required. + GLX 1.0 or later is required. + +Overview + + The glxCopySubBufferMESA() function copies a rectangular region + of the back color buffer to the front color buffer. This can be + used to quickly repaint 3D windows in response to expose events + when the back color buffer cannot be damaged by other windows. + +IP Status + + Open-source; freely implementable. + +Issues + + None. + +New Procedures and Functions + + void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable, + int x, int y, int width, int height ); + +New Tokens + + None. + +Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors) + + Add to section 3.3.10 Double Buffering: + + The function + + void glXCopySubBufferMESA( Display *dpy, GLXDrawable drawable, + int x, int y, int width, int height ); + + may be used to copy a rectangular region of the back color buffer to + the front color buffer. This can be used to quickly repaint 3D windows + in response to expose events when the back color buffer cannot be + damaged by other windows. + + and indicates the lower-left corner of the region to copy and + and indicate the size in pixels. Coordinate (0,0) + corresponds to the lower-left pixel of the window, like glReadPixels. + +GLX Protocol + + None at this time. The extension is implemented in terms of ordinary + Xlib protocol inside of Mesa. + +Errors + + None. + +New State + + None. + +Revision History + + 8 June 2000 - initial specification + diff --git a/docs/MESA_pack_invert.spec b/docs/MESA_pack_invert.spec new file mode 100644 index 0000000..53d5fca --- /dev/null +++ b/docs/MESA_pack_invert.spec @@ -0,0 +1,138 @@ +Name + + MESA_pack_invert + +Name Strings + + GL_MESA_pack_invert + +Contact + + Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com) + Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com) + +Status + + Shipping (Mesa 4.0.4 and later) + +Version + + 1.0 + +Number + + TBD + +Dependencies + + OpenGL 1.0 or later is required + This extensions is written against the OpenGL 1.4 Specification. + +Overview + + This extension adds a new pixel storage parameter to indicate that + images are to be packed in top-to-bottom order instead of OpenGL's + conventional bottom-to-top order. Only pixel packing can be + inverted (i.e. for glReadPixels, glGetTexImage, glGetConvolutionFilter, + etc). + + Almost all known image file formats store images in top-to-bottom + order. As it is, OpenGL reads images from the frame buffer in + bottom-to-top order. Thus, images usually have to be inverted before + writing them to a file with image I/O libraries. This extension + allows images to be read such that inverting isn't needed. + +IP Status + + None + +Issues + + 1. Should we also defined UNPACK_INVERT_MESA for glDrawPixels, etc? + + Resolved: No, we're only concerned with pixel packing. There are other + solutions for inverting images when using glDrawPixels (negative Y pixel + zoom) or glTexImage (invert the vertex T coordinates). It would be easy + enough to define a complementary extension for pixel packing in the + future if needed. + +New Procedures and Functions + + None + +New Tokens + + Accepted by the parameter of PixelStorei and PixelStoref + and the parameter of GetIntegerv, GetFloatv, GetDoublev + and GetBooleanv: + + PACK_INVERT_MESA 0x8758 + +Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) + + None + +Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) + + None + +Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment +Operations and the Frame Buffer) + + Add the following entry to table 4.4 (PixelStore parameters) on page 182: + + Parameter Name Type Initial Value Valid Range + --------------------------------------------------------- + PACK_INVERT_MESA boolean FALSE TRUE/FALSE + + In the section labeled "Placement in Client Memory" on page 184 + insert the following text into the paragraph before the sentence + that starts with "If the format is RED, GREEN, BLUE...": + + "The parameter PACK_INVERT_MESA controls whether the image is packed + in bottom-to-top order (the default) or top-to-bottom order. Equation + 3.8 is modified as follows: + + ... the first element of the Nth row is indicated by + + p + Nk, if PACK_INVERT_MESA is false + p + k * (H - 1) - Nk, if PACK_INVERT_MESA is true, where H is the + image height + " + +Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) + + None + +Additions to Chapter 6 of the OpenGL 1.4 Specification (State and +State Requests) + + None + +Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) + + None + +Additions to the AGL/GLX/WGL Specifications + + None + +GLX Protocol + + None + +Errors + + None + +New State + + Add the following entry to table 6.20 (Pixels) on page 235: + + Get Value Type Get Cmd Initial Value Description Sec Attribute + -------------------------------------------------------------------------------------------------- + PACK_INVERT_MESA boolean GetBoolean FALSE Value of PACK_INVERT_MESA 4.3.2 pixel-store + +Revision History + + 21 September 2002 - Initial draft diff --git a/docs/MESA_packed_depth_stencil.spec b/docs/MESA_packed_depth_stencil.spec new file mode 100644 index 0000000..4f7ab1e --- /dev/null +++ b/docs/MESA_packed_depth_stencil.spec @@ -0,0 +1,231 @@ +Name + + MESA_packed_depth_stencil + +Name Strings + + GL_MESA_packed_depth_stencil + +Contact + + Keith Whitwell, VA Linux Systems Inc. (keithw 'at' valinux.com) + Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com) + +Status + + Obsolete. + +Version + + $Id: MESA_packed_depth_stencil.spec,v 1.2 2003/09/19 14:58:21 brianp Exp $ + +Number + + ??? + +Dependencies + + EXT_abgr affects the definition of this extension + SGIS_texture4D affects the definition of this extension + EXT_cmyka affects the definition of this extension + ARB_packed_pixels affects the definition of this extension + +Overview + + Provides a mechanism for DrawPixels and ReadPixels to efficiently + transfer depth and stencil image data. Specifically, we defined new + packed pixel formats and types which pack both stencil and depth + into one value. + +Issues: + + 1. Is this the right way to distinguish between 24/8 and 8/24 + pixel formats? Should we instead provide both: + + GL_DEPTH_STENCIL_MESA + GL_STENCIL_DEPTH_MESA + + And perhaps just use GL_UNSIGNED_INT, GL_UNSIGNED_SHORT ? + + 2. If not, is it correct to use _REV to indicate that stencil + preceeds depth in the 1_15 and 8_24 formats? + + 3. Do we really want the GL_UNSIGNED_SHORT formats? + + +New Procedures and Functions + + None. + +New Tokens + + Accepted by the parameter of ReadPixels and DrawPixels: + + GL_DEPTH_STENCIL_MESA 0x8750 + + Accepted by the parameter of ReadPixels and DrawPixels: + + GL_UNSIGNED_INT_24_8_MESA 0x8751 + GL_UNSIGNED_INT_8_24_REV_MESA 0x8752 + GL_UNSIGNED_SHORT_15_1_MESA 0x8753 + GL_UNSIGNED_SHORT_1_15_REV_MESA 0x8754 + +Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) + + None + +Additions to Chapter 3 of the 1.1 Specification (Rasterization) + + One entry is added to table 3.5 (DrawPixels and ReadPixels formats). + The new table is: + + Target + Format Name Buffer Element Meaning and Order + ----------- ------ ------------------------- + COLOR_INDEX Color Color index + STENCIL_INDEX Stencil Stencil index + DEPTH_COMPONENT Depth Depth component + RED Color R component + GREEN Color G component + BLUE Color B component + ALPHA Color A component + RGB Color R, G, B components + RGBA Color R, G, B, A components + BGRA Color B, G, R, A components + ABGR_EXT Color A, B, G, R components + CMYK_EXT Color Cyan, Magenta, Yellow, Black components + CMYKA_EXT Color Cyan, Magenta, Yellow, Black, A components + LUMINANCE Color Luminance component + LUMINANCE_ALPHA Color Luminance, A components + DEPTH_STENCIL Depth, Depth component, stencil index. + Stencil + + Table 3.5: DrawPixels and ReadPixels formats. The third column + gives a description of and the number and order of elements in a + group. + + Add to the description of packed pixel formats: + + Parameter Data of Matching + Token Name Type Elements Pixel Formats + ---------------- ---- -------- ------------- + + UNSIGNED_BYTE_3_3_2 ubyte 3 RGB + UNSIGNED_BYTE_2_3_3_REV ubyte 3 RGB + UNSIGNED_SHORT_5_6_5 ushort 3 RGB + UNSIGNED_SHORT_5_6_5_REV ushort 3 RGB + UNSIGNED_SHORT_4_4_4_4 ushort 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT + UNSIGNED_SHORT_4_4_4_4_REV ushort 4 RGBA,BGRA + UNSIGNED_SHORT_5_5_5_1 ushort 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT + UNSIGNED_SHORT_1_5_5_5_REV ushort 4 RGBA,BGRA + UNSIGNED_INT_8_8_8_8 uint 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT + UNSIGNED_INT_8_8_8_8_REV uint 4 RGBA,BGRA + UNSIGNED_INT_10_10_10_2 uint 4 RGBA,BGRA,ABGR_EXT,CMYK_EXT + UNSIGNED_INT_2_10_10_10_REV uint 4 RGBA,BGRA + UNSIGNED_SHORT_15_1_MESA ushort 2 DEPTH_STENCIL_MESA + UNSIGNED_SHORT_1_15_REV_MESA ushort 2 DEPTH_STENCIL_MESA + UNSIGNED_SHORT_24_8_MESA ushort 2 DEPTH_STENCIL_MESA + UNSIGNED_SHORT_8_24_REV_MESA ushort 2 DEPTH_STENCIL_MESA + + UNSIGNED_INT_8_24: + + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + +-----------------------+-----------------------------------------------------------------------+ + | | | + +-----------------------+-----------------------------------------------------------------------+ + + first second + element element + + + UNSIGNED_INT_24_8: + + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + +----------------------------------------------------------------------+------------------------+ + | | | + +----------------------------------------------------------------------+------------------------+ + + first second + element element + + UNSIGNED_SHORT_15_1: + + 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + +-----------------------------------------------------------+---+ + | | | + +-----------------------------------------------------------+---+ + + first second + element element + + + UNSIGNED_SHORT_1_15_REV: + + 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + +---+-----------------------------------------------------------+ + | | | + +---+-----------------------------------------------------------+ + + second first + element element + + The assignment of elements to fields in the packed pixel is as + described in the table below: + + First Second Third Fourth + Format Element Element Element Element + ------ ------- ------- ------- ------- + RGB red green blue + RGBA red green blue alpha + BGRA blue green red alpha + ABGR_EXT alpha blue green red + CMYK_EXT cyan magenta yellow black + DEPTH_STENCIL_MESA depth stencil + +Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations +and the Frame Buffer) + + The new format is added to the discussion of Obtaining Pixels from the + Framebuffer. It should read " If the is one of RED, GREEN, + BLUE, ALPHA, RGB, RGBA, ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, and + the GL is in color index mode, then the color index is obtained." + + The new format is added to the discussion of Index Lookup. It should + read "If is one of RED, GREEN, BLUE, ALPHA, RGB, RGBA, + ABGR_EXT, LUMINANCE, or LUMINANCE_ALPHA, then the index is used to + reference 4 tables of color components: PIXEL_MAP_I_TO_R, + PIXEL_MAP_I_TO_G, PIXEL_MAP_I_TO_B, and PIXEL_MAP_I_TO_A." + + +Additions to Chapter 5 of the 1.1 Specification (Special Functions) + + None + +Additions to Chapter 6 of the 1.1 Specification (State and State Requests) + + None + +Additions to the GLX Specification + + None + +GLX Protocol + + TBD + +Errors + + None + +New State + + None + +Revision History + + Version 1.0 - 23 Sep 2000 + Keith's original version. + + Version 1.1 - 3 Nov 2000 + Brian's edits, assigned values to new enums. + diff --git a/docs/MESA_pixmap_colormap.spec b/docs/MESA_pixmap_colormap.spec new file mode 100644 index 0000000..fb0b441 --- /dev/null +++ b/docs/MESA_pixmap_colormap.spec @@ -0,0 +1,90 @@ +Name + + MESA_pixmap_colormap + +Name Strings + + GLX_MESA_pixmap_colormap + +Contact + + Brian Paul (brian.paul 'at' tungstengraphics.com) + +Status + + Shipping since Mesa 1.2.8 in May, 1996. + +Version + + Last Modified Date: 8 June 2000 + +Number + + 216 + +Dependencies + + OpenGL 1.0 or later is required. + GLX 1.0 or later is required. + +Overview + + Since Mesa allows RGB rendering into drawables with PseudoColor, + StaticColor, GrayScale and StaticGray visuals, Mesa needs a colormap + in order to compute pixel values during rendering. + + The colormap associated with a window can be queried with normal + Xlib functions but there is no colormap associated with pixmaps. + + The glXCreateGLXPixmapMESA function is an alternative to glXCreateGLXPixmap + which allows specification of a colormap. + +IP Status + + Open-source; freely implementable. + +Issues + + None. + +New Procedures and Functions + + GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual, + Pixmap pixmap, Colormap cmap ); + +New Tokens + + None. + +Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors) + + Add to section 3.4.2 Off Screen Rendering + + The Mesa implementation of GLX allows RGB rendering into X windows and + pixmaps of any visual class, not just TrueColor or DirectColor. In order + to compute pixel values from RGB values Mesa requires a colormap. + + The function + + GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual, + Pixmap pixmap, Colormap cmap ); + + allows one to create a GLXPixmap with a specific colormap. The image + rendered into the pixmap may then be copied to a window (which uses the + same colormap and visual) with the expected results. + +GLX Protocol + + None since this is a client-side extension. + +Errors + + None. + +New State + + None. + +Revision History + + 8 June 2000 - initial specification diff --git a/docs/MESA_program_debug.spec b/docs/MESA_program_debug.spec new file mode 100644 index 0000000..391d39f --- /dev/null +++ b/docs/MESA_program_debug.spec @@ -0,0 +1,357 @@ +Name + + MESA_program_debug + +Name Strings + + GL_MESA_program_debug + +Contact + + Brian Paul (brian.paul 'at' tungstengraphics.com) + +Status + + XXX - Not complete yet!!! + +Version + + Last Modified Date: July 20, 2003 + Author Revision: 1.0 + $Date: 2004/03/25 01:42:41 $ $Revision: 1.4 $ + +Number + + TBD + +Dependencies + + OpenGL 1.4 is required + The extension is written against the OpenGL 1.4 specification. + ARB_vertex_program or ARB_fragment_program or NV_vertex_program + or NV_fragment_program is required. + +Overview + + The extension provides facilities for implementing debuggers for + vertex and fragment programs. + + The concept is that vertex and fragment program debuggers will be + implemented outside of the GL as a utility package. This extension + only provides the minimal hooks required to implement a debugger. + + There are facilities to do the following: + 1. Have the GL call a user-specified function prior to executing + each vertex or fragment instruction. + 2. Query the current program string's execution position. + 3. Query the current values of intermediate program values. + + The main feature is the ProgramCallbackMESA function. It allows the + user to register a callback function with the GL. The callback will + be called prior to executing each vertex or fragment program instruction. + + From within the callback, the user may issue Get* commands to + query current GL state. The GetProgramRegisterfvMESA function allows + current program values to be queried (such as temporaries, input + attributes, and result registers). + + There are flags for enabling/disabling the program callbacks. + + The current execution position (as an offset from the start of the + program string) can be queried with + GetIntegerv(GL_FRAGMENT_PROGRAM_POSITION_MESA, &pos) or + GetIntegerv(GL_VERTEX_PROGRAM_POSITION_MESA, &pos). + + +IP Status + + None + +Issues + + 1. Is this the right model for a debugger? + + It seems prudent to minimize the scope of this extension and leave + it up to the developer (or developer community) to write debuggers + that layer on top of this extension. + + If the debugger were fully implemented within the GL it's not + clear how terminal and GUI-based interfaces would work, for + example. + + 2. There aren't any other extensions that register callbacks with + the GL. Isn't there another solution? + + If we want to be able to single-step through vertex/fragment + programs I don't see another way to do it. + + 3. How do we prevent the user from doing something crazy in the + callback function, like trying to call glBegin (leading to + recursion)? + + The rule is that the callback function can only issue glGet*() + functions and no other GL commands. It could be difficult to + enforce this, however. Therefore, calling any non-get GL + command from within the callback will result in undefined + results. + + 4. Is this extension amenable to hardware implementation? + + Hopefully, but if not, the GL implementation will have to fall + back to a software path when debugging. This may be acceptable + for debugging. + + 5. What's the parameter to ProgramCallbackMESA for? + + It's a common programming practice to associate a user-supplied + value with callback functions. + + 6. Debuggers often allow one to modify intermediate program values, + then continue. Does this extension support that? + + No. + + +New Procedures and Functions (and datatypes) + + typedef void (*programcallbackMESA)(enum target, void *data) + + void ProgramCallbackMESA(enum target, programcallbackMESA callback, + void *data) + + void GetProgramRegisterfvMESA(enum target, sizei len, + const ubyte *registerName, float *v) + +New Tokens + + Accepted by the parameter of Enable, Disable, IsEnabled, + GetBooleanv, GetDoublev, GetFloatv and GetIntegerv: + + FRAGMENT_PROGRAM_CALLBACK_MESA 0x8bb1 + VERTEX_PROGRAM_CALLBACK_MESA 0x8bb4 + + Accepted by the parameter GetBooleanv, GetDoublev, + GetFloatv and GetIntegerv: + + FRAGMENT_PROGRAM_POSITION_MESA 0x8bb0 + VERTEX_PROGRAM_POSITION_MESA 0x8bb4 + + Accepted by the parameter of GetPointerv: + + FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA 0x8bb2 + FRAGMENT_PROGRAM_CALLBACK_DATA_MESA 0x8bb3 + VERTEX_PROGRAM_CALLBACK_FUNC_MESA 0x8bb6 + VERTEX_PROGRAM_CALLBACK_DATA_MESA 0x8bb7 + +Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) + + None. + +Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) + + None. + +Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment +Operations and the Frame Buffer) + + None. + +Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) + + In section 5.4 "Display Lists", page 202, add the following command + to the list of those that are not compiled into display lists: + + ProgramCallbackMESA. + + + Add a new section 5.7 "Callback Functions" + + The function + + void ProgramCallbackMESA(enum target, programcallbackMESA callback, + void *data) + + registers a user-defined callback function with the GL. + may be FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB. The enabled + callback functions registered with these targets will be called + prior to executing each instruction in the current fragment or + vertex program, respectively. The callbacks are enabled and + disabled by calling Enable or Disable with + FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB. + + The callback function's signature must match the typedef + + typedef void (*programcallbackMESA)(enum target, void *data) + + When the callback function is called, will either be + FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB to indicate which + program is currently executing and will be the value + specified when ProgramCallbackMESA was called. + + From within the callback function, only the following GL commands + may be called: + + GetBooleanv + GetDoublev + GetFloatv + GetIntegerv + GetProgramLocalParameter + GetProgramEnvParameter + GetProgramRegisterfvMESA + GetProgramivARB + GetProgramStringARB + GetError + + Calling any other command from within the callback results in + undefined behaviour. + + +Additions to Chapter 6 of the OpenGL 1.4 Specification (State and +State Requests) + + Add a new section 6.1.3 "Program Value Queries": + + The command + + void GetProgramRegisterfvMESA(enum target, sizei len, + const ubyte *registerName, + float *v) + + Is used to query the value of program variables and registers + during program execution. GetProgramRegisterfvMESA may only be + called from within a callback function registered with + ProgramCallbackMESA. + + and specify the name a variable, input + attribute, temporary, or result register in the program string. + The current value of the named variable is returned as four + values in . If doesn't exist in the program string, + the error INVALID_OPERATION is generated. + +Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) + + None. + +Additions to the AGL/GLX/WGL Specifications + + None. + +GLX Protocol + + XXX TBD + +Dependencies on NV_vertex_program and NV_fragment_program + + If NV_vertex_program and/or NV_fragment_program are supported, + vertex and/or fragment programs defined by those extensions may + be debugged as well. Register queries will use the syntax used + by those extensions (i.e. "v[X]" to query vertex attributes, + "o[X]" for vertex outputs, etc.) + +Errors + + INVALID_OPERATION is generated if ProgramCallbackMESA is called + between Begin and End. + + INVALID_ENUM is generated by ProgramCallbackMESA if is not + a supported vertex or fragment program type. + + Note: INVALID_OPERAION IS NOT generated by GetProgramRegisterfvMESA, + GetBooleanv, GetDoublev, GetFloatv, or GetIntegerv if called between + Begin and End when a vertex or fragment program is currently executing. + + INVALID_ENUM is generated by ProgramCallbackMESA, + GetProgramRegisterfvMESA if is not a program target supported + by ARB_vertex_program, ARB_fragment_program (or NV_vertex_program or + NV_fragment_program). + + INVALID_VALUE is generated by GetProgramRegisterfvMESA if + does not name a known program register or variable. + + INVALID_OPERATION is generated by GetProgramRegisterfvMESA when a + register query is attempted for a program target that's not currently + being executed. + + +New State + + XXX finish + +(table 6.N, p. ###) + Initial + Get Value Type Get Command Value Description Sec. Attribute + --------- ---- ----------- ----- ----------- ---- --------- + FRAGMENT_PROGRAM_CALLBACK_MESA B IsEnabled FALSE XXX XXX enable + VERTEX_PROGRAM_CALLBACK_MESA B IsEnabled FALSE XXX XXX enable + FRAGMENT_PROGRAM_POSITION_MESA Z+ GetIntegerv -1 XXX XXX - + VERTEX_PROGRAM_POSITION_MESA Z+ GetIntegerv -1 XXX XXX - + FRAGMENT_PROGRAM_CALLBACK_FUNC_MESA P GetPointerv NULL XXX XXX - + VERTEX_PROGRAM_CALLBACK_FUNC_MESA P GetPointerv NULL XXX XXX - + FRAGMENT_PROGRAM_CALLBACK_DATA_MESA P GetPointerv NULL XXX XXX - + VERTEX_PROGRAM_CALLBACK_DATA_MESA P GetPointerv NULL XXX XXX - + + XXX more? + +New Implementation Dependent State + + None. + +Revision History + + 8 July 2003 + Initial draft. (Brian Paul) + 11 July 2003 + Second draft. (Brian Paul) + 20 July 2003 + Third draft. Lots of fundamental changes. (Brian Paul) + 23 July 2003 + Added chapter 5 and 6 spec language. (Brian Paul) + +Example Usage + + The following is a very simple example of how this extension may + be used to print the values of R0, R1, R2 and R3 while executing + vertex programs. + + + /* This is called by the GL when the vertex program is executing. + * We can only make glGet* calls from within this function! + */ + void DebugCallback(GLenum target, GLvoid *data) + { + GLint pos; + GLuint i; + + /* Get PC and current instruction string */ + glGetIntegerv(GL_VERTEX_PROGRAM_POSITION_ARB, &pos); + + printf("Current position: %d\n", pos); + + printf("Current temporary registers:\n"); + for (i = 0; i < 4; i++) { + GLfloat v[4]; + char s[10]; + sprintf(s, "R%d", i); + glGetProgramRegisterfvMESA(GL_VERTEX_PROGRAM_ARB, strlen(s), s, v); + printf("R%d = %g, %g, %g, %g\n", i, v[0], v[1], v[2], v[3]); + } + } + + + /* + * elsewhere... + */ + + /* Register our debugger callback function */ + glProgramCallbackMESA(GL_VERTEX_PROGRAM_ARB, DebugCallback, NULL); + glEnable(GL_VERTEX_PROGRAM_CALLBACK_MESA); + + /* define/bind a vertex program */ + + glEnable(GL_VERTEX_PROGRAM); + + /* render something */ + glBegin(GL_POINTS); + glVertex2f(0, 0); + glEnd(); + diff --git a/docs/MESA_release_buffers.spec b/docs/MESA_release_buffers.spec new file mode 100644 index 0000000..8db9350 --- /dev/null +++ b/docs/MESA_release_buffers.spec @@ -0,0 +1,85 @@ +Name + + MESA_release_buffers + +Name Strings + + GLX_MESA_release_buffers + +Contact + + Brian Paul (brian.paul 'at' tungstengraphics.com) + +Status + + Shipping since Mesa 2.0 in October, 1996. + +Version + + Last Modified Date: 8 June 2000 + +Number + + 217 + +Dependencies + + OpenGL 1.0 or later is required. + GLX 1.0 or later is required. + +Overview + + Mesa's implementation of GLX is entirely implemented on the client side. + Therefore, Mesa cannot immediately detect when an X window or pixmap is + destroyed in order to free any ancilliary data associated with the window + or pixmap. + + The glxMesaReleaseBuffers() function can be used to explicitly indicate + when the back color buffer, depth buffer, stencil buffer, and/or accum- + ulation buffer associated with a drawable can be freed. + +IP Status + + Open-source; freely implementable. + +Issues + + None. + +New Procedures and Functions + + Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d ); + +New Tokens + + None. + +Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors) + + The function + + Bool glXReleaseBuffersMESA( Display *dpy, GLXDrawable d ); + + causes all software ancilliary buffers (back buffer, depth, stencil, + accum, etc) associated with the named drawable to be immediately + deallocated. True is returned if is a valid Mesa GLX drawable, + else False is returned. After calling glXReleaseBuffersMESA, the + drawable should no longer be used for GL rendering. Results of + attempting to do so are undefined. + + +GLX Protocol + + None, since this is a client-side operation. + +Errors + + None. + +New State + + None. + +Revision History + + 8 June 2000 - initial specification diff --git a/docs/MESA_resize_buffers.spec b/docs/MESA_resize_buffers.spec new file mode 100644 index 0000000..f79d29c --- /dev/null +++ b/docs/MESA_resize_buffers.spec @@ -0,0 +1,82 @@ +Name + + MESA_resize_buffers + +Name Strings + + GL_MESA_resize_buffers + +Contact + + Brian Paul (brian.paul 'at' tungstengraphics.com) + +Status + + Shipping (since Mesa version 2.2) + +Version + + $Id: MESA_resize_buffers.spec,v 1.3 2004/03/25 01:42:42 brianp Exp $ + +Number + + 196 + +Dependencies + + Mesa 2.2 or later is required. + +Overview + + Mesa is often used as a client library with no integration with + the computer's window system (an X server, for example). And since + Mesa does not have an event loop nor window system callbacks, it + cannot properly respond to window system events. In particular, + Mesa cannot automatically detect when a window has been resized. + + Mesa's glViewport command queries the current window size and updates + its internal data structors accordingly. This normally works fine + since most applications call glViewport in responce to window size + changes. + + In some situations, however, the application may not call glViewport + when a window size changes but would still like Mesa to adjust to + the new window size. This extension exports a new function to solve + this problem. + +New Procedures and Functions + + void glResizeBuffersMESA( void ) + +New Tokens + + none + +Additions to the OpenGL Specification (no particular section) + + The glResizeBuffersMESA command may be called when the client + determines that a window has been resized. Calling + glResizeBuffersMESA causes Mesa to query the current window size + and adjust its internal data structures. This may include + reallocating depth, stencil, alpha and accumulation buffers. + +Additions to the AGL/GLX/WGL Specifications + + None + +Errors + + INVALID_OPERATION is generated if ResizeBuffersMESA is called betweeen + Begin and End. + +New State + + None. + +New Implementation Dependent State + + None. + +Revision History + + * Revision 1.0 - Initial specification diff --git a/docs/MESA_set_3dfx_mode.spec b/docs/MESA_set_3dfx_mode.spec new file mode 100644 index 0000000..06d97ca --- /dev/null +++ b/docs/MESA_set_3dfx_mode.spec @@ -0,0 +1,85 @@ +Name + + MESA_set_3dfx_mode + +Name Strings + + GLX_MESA_set_3dfx_mode + +Contact + + Brian Paul (brian.paul 'at' tungstengraphics.com) + +Status + + Shipping since Mesa 2.6 in February, 1998. + +Version + + Last Modified Date: 8 June 2000 + +Number + + 218 + +Dependencies + + OpenGL 1.0 or later is required. + GLX 1.0 or later is required. + +Overview + + The Mesa Glide driver allows full-screen rendering or rendering into + an X window. The glXSet3DfxModeMESA() function allows an application + to switch between full-screen and windowed rendering. + +IP Status + + Open-source; freely implementable. + +Issues + + None. + +New Procedures and Functions + + GLboolean glXSet3DfxModeMESA( GLint mode ); + +New Tokens + + GLX_3DFX_WINDOW_MODE_MESA 0x1 + GLX_3DFX_FULLSCREEN_MODE_MESA 0x2 + +Additions to Chapter 3 of the GLX 1.3 Specification (Functions and Errors) + + The Mesa Glide device driver allows either rendering in full-screen + mode or rendering into an X window. An application can switch between + full-screen and window rendering with the command: + + GLboolean glXSet3DfxModeMESA( GLint mode ); + + may either be GLX_3DFX_WINDOW_MODE_MESA to indicate window + rendering or GLX_3DFX_FULLSCREEN_MODE_MESA to indicate full-screen mode. + + GL_TRUE is returned if is valid and the operation completed + normally. GL_FALSE is returned if is invalid or if the Glide + driver is not being used. + + Note that only one drawable and context can be created at any given + time with the Mesa Glide driver. + +GLX Protocol + + None since this is a client-side extension. + +Errors + + None. + +New State + + None. + +Revision History + + 8 June 2000 - initial specification diff --git a/docs/MESA_sprite_point.spec b/docs/MESA_sprite_point.spec new file mode 100644 index 0000000..9422ff5 --- /dev/null +++ b/docs/MESA_sprite_point.spec @@ -0,0 +1,191 @@ +Name + + MESA_sprite_point + +Name Strings + + GL_MESA_sprite_point + +Contact + + Brian Paul, VA Linux Systems Inc. (brianp 'at' valinux.com) + +Status + + Obsolete - see GL_ARB_point_sprite. + +Version + + $Id: MESA_sprite_point.spec,v 1.2 2003/09/19 14:58:21 brianp Exp $ + +Number + + ??? + +Dependencies + + GL_EXT_point_parameters effects the definition of this extension + GL_ARB_multitexture effects the definition of this extension + +Overview + + This extension modifies the way in which points are rendered, + specifically when they're textured. When SPRITE_POINT_MESA is enabled + a point is rendered as if it were a quadrilateral with unique texture + coordinates at each vertex. This extension effectively turns points + into sprites which may be rendered more easily and quickly than using + conventional textured quadrilaterals. + + When using point size > 1 or attenuated points this extension is an + effective way to render many small sprite images for particle systems + or other effects. + +Issues: + + 1. How are the texture coordinates computed? + + The lower-left corner has texture coordinate (0,0,r,q). + The lower-right, (1,0,r,q). The upper-right, (1,1,r,q). + The upper-left, (0,1,r,q). + + 2. What about texgen and texture matrices? + + Texgen and the texture matrix have no effect on the point's s and t + texture coordinates. The r and q coordinates may have been computed + by texgen or the texture matrix. Note that with a 3D texture and/or + texgen that the r coordinate could be used to select a slice in the + 3D texture. + + 3. What about point smoothing? + + When point smoothing is enabled, a triangle fan could be rendered + to approximate a circular point. This could be problematic to + define and implement so POINT_SMOOTH is ignored when drawing sprite + points. + + Smoothed points can be approximated by using an appropriate texture + images, alpha testing and blending. + + POLYGON_SMOOTH does effect the rendering of the quadrilateral, however. + + 4. What about sprite rotation? + + There is none. Sprite points are always rendered as window-aligned + squares. One could define rotated texture images if desired. A 3D + texture and appropriate texture r coordinates could be used to + effectively specify image rotation per point. + + 5. What about POLYGON_MODE? + + POLYGON_MODE does not effect the rasterization of the quadrilateral. + + 6. What about POLYGON_CULL? + + TBD. Polygon culling is normally specified and implemented in the + transformation stage of OpenGL. However, some rasterization hardware + implements it later during triangle setup. + + Polygon culling wouldn't be useful for sprite points since the + quadrilaterals are always defined in counter-clockwise order in + window space. For that reason, polygon culling should probably be + ignored. + + 7. Should sprite points be alpha-attenuated if their size is below the + point parameter's threshold size? + + 8. Should there be an advertisized maximum sprite point size? + + No. Since we're rendering the point as a quadrilateral there's no + need to limit the size. + + +New Procedures and Functions + + None. + +New Tokens + + Accepted by the parameter of Enable, Disable, IsEnabled, + GetIntegerv, GetBooleanv, GetFloatv and GetDoublev: + + SPRITE_POINT_MESA 0x???? + MAX_SPRITE_POINT_SIZE_MESA 0x???? (need this?) + +Additions to Chapter 2 of the 1.1 Specification (OpenGL Operation) + + None + +Additions to Chapter 3 of the 1.1 Specification (Rasterization) + + Section ???. + + When SPRITE_POINT_MESA is enabled points are rasterized as screen- + aligned quadrilaterals. If the four vertices of the quadrilateral + are labeled A, B, C, and D, starting at the lower-left corner and moving + counter-clockwise around the quadrilateral, then the vertex and + texture coordinates are computed as follows: + + vertex window coordinate texture coordinate + A (x-r, y-r, z, w) (0, 0, r, q) + B (x+r, y-r, z, w) (1, 0, r, q) + C (x+r, y+r, z, w) (1, 1, r, q) + D (x-r, y+r, z, w) (0, 1, r, q) + + where x, y, z, w are the point's window coordinates, r and q are the + point's 3rd and 4th texture coordinates and r is half the point's + size. The other vertex attributes (such as the color and fog coordinate) + are simply duplicated from the original point vertex. + + Point size may either be specified with PointSize or computed + according to the EXT_point_parameters extension. + + The new texture coordinates are not effected by texgen or the texture + matrix. Note, however, that the texture r and q coordinates are passed + unchanged and may have been computed with texgen and/or the texture + matrix. + + If multiple texture units are present the same texture coordinate is + used for all texture units. + + The point is then rendered as if it were a quadrilateral using the + normal point sampling rules. POLYGON_MODE does not effect the + rasterization of the quadrilateral but POLYGON_SMOOTH does. + + POINT_SMOOTH has no effect when SPRITE_POINT_MESA is enabled. + +Additions to Chapter 4 of the 1.1 Specification (Per-Fragment Operations +and the Frame Buffer) + + None. + +Additions to Chapter 5 of the 1.1 Specification (Special Functions) + + None + +Additions to Chapter 6 of the 1.1 Specification (State and State Requests) + + None + +Additions to the GLX Specification + + None + +GLX Protocol + + TBD + +Errors + + None + +New State + + Add boolean variable SPRITE_POINT_MESA to the point attribute group. + +Revision History + + Version 1.0 - 4 Dec 2000 + Original draft. + + + diff --git a/docs/MESA_swap_control.spec b/docs/MESA_swap_control.spec new file mode 100644 index 0000000..ecc6746 --- /dev/null +++ b/docs/MESA_swap_control.spec @@ -0,0 +1,132 @@ +Name + + MESA_swap_control + +Name Strings + + GLX_MESA_swap_control + +Contact + + Ian Romanick, IBM, idr at us.ibm.com + +Status + + Deployed in DRI drivers post-XFree86 4.3. + +Version + + Date: 5/1/2003 Revision: 1.1 + +Number + + ??? + +Dependencies + + None + + Based on GLX_SGI_swap_control version 1.9 and WGL_EXT_swap_control + version 1.5. + +Overview + + This extension allows an application to specify a minimum periodicity + of color buffer swaps, measured in video frame periods. + +Issues + + * Should implementations that export GLX_MESA_swap_control also export + GL_EXT_swap_control for compatibility with WGL_EXT_swap_control? + + UNRESOLVED. + +New Procedures and Functions + + int glXSwapIntervalMESA(int interval) + int glXGetSwapIntervalMESA(void) + +New Tokens + + None + +Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation) + + None + +Additions to Chapter 3 of the 1.4 GL Specification (Rasterization) + + None + +Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations +and the Framebuffer) + + None + +Additions to Chapter 5 of the 1.4 GL Specification (Special Functions) + + None + +Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests) + + None + +Additions to the GLX 1.3 Specification + + [Add the following to Section 3.3.10 of the GLX Specification (Double + Buffering)] + + glXSwapIntervalMESA specifies the minimum number of video frame periods + per buffer swap. (e.g. a value of two means that the color buffers + will be swapped at most every other video frame.) A return value + of zero indicates success; otherwise an error occurred. The interval + takes effect when glXSwapBuffers is first called subsequent to the + glXSwapIntervalMESA call. + + A video frame period is the time required by the monitor to display a + full frame of video data. In the case of an interlaced monitor, + this is typically the time required to display both the even and odd + fields of a frame of video data. + + If is set to a value of 0, buffer swaps are not synchron- + ized to a video frame. The value is silently clamped to + the maximum implementation-dependent value supported before being + stored. + + The swap interval is not part of the render context state. It cannot + be pushed or popped. The current swap interval for the window + associated with the current context can be obtained by calling + glXGetSwapIntervalMESA. The default swap interval is 0. + + On XFree86, setting the environment variable LIBGL_THROTTLE_REFRESH sets + the swap interval to 1. + +Errors + + glXSwapIntervalMESA returns GLX_BAD_VALUE if parameter is + less than zero. + + glXSwapIntervalMESA returns GLX_BAD_CONTEXT if there is no current + GLXContext. + +GLX Protocol + + None. This extension only extends to direct rendering contexts. + +New State + + Get Value Get Command Type Initial Value + --------- ----------- ---- ------------- + [swap interval] GetSwapInterval Z+ 0 + +New Implementation Dependent State + + None + + +Revision History + + 1.1, 5/1/03 Added the issues section and contact information. + Changed the default swap interval to 0. + 1.0, 3/17/03 Initial version based on GLX_SGI_swap_control and + WGL_EXT_swap_control. diff --git a/docs/MESA_swap_frame_usage.spec b/docs/MESA_swap_frame_usage.spec new file mode 100644 index 0000000..38cf51a --- /dev/null +++ b/docs/MESA_swap_frame_usage.spec @@ -0,0 +1,201 @@ +Name + + MESA_swap_frame_usage + +Name Strings + + GLX_MESA_swap_frame_usage + +Contact + + Ian Romanick, IBM, idr at us.ibm.com + +Status + + Deployed in DRI drivers post-XFree86 4.3. + +Version + + Date: 5/1/2003 Revision: 1.1 + +Number + + ??? + +Dependencies + + GLX_SGI_swap_control affects the definition of this extension. + GLX_MESA_swap_control affects the definition of this extension. + GLX_OML_sync_control affects the definition of this extension. + + Based on WGL_I3D_swap_frame_usage version 1.3. + +Overview + + This extension allows an application to deterine what portion of the + swap period has elapsed since the last swap operation completed. The + "usage" value is a floating point value on the range [0,max] which is + calculated as follows: + + td + percent = ---- + tf + + where td is the time measured from the last completed buffer swap (or + call to enable the statistic) to when the next buffer swap completes, tf + is the entire time for a frame which may be multiple screen refreshes + depending on the swap interval as set by the GLX_SGI_swap_control or + GLX_OML_sync_control extensions. + + The value, percent, indicates the amount of time spent between the + completion of the two swaps. If the value is in the range [0,1], the + buffer swap occurred within the time period required to maintain a + constant frame rate. If the value is in the range (1,max], a constant + frame rate was not achieved. The value indicates the number of frames + required to draw. + + This definition of "percent" differs slightly from + WGL_I3D_swap_frame_usage. In WGL_I3D_swap_frame_usage, the measurement + is taken from the completion of one swap to the issuance of the next. + This representation may not be as useful as measuring between + completions, as a significant amount of time may pass between the + issuance of a swap and the swap actually occuring. + + There is also a mechanism to determine whether a frame swap was + missed. + +New Procedures and Functions + + int glXGetFrameUsageMESA(Display *dpy, + GLXDrawable drawable, + float *usage) + + int glXBeginFrameTrackingMESA(Display *dpy, + GLXDrawable drawable) + + int glXEndFrameTrackingMESA(Display *dpy, + GLXDrawable drawable) + + int glXQueryFrameTrackingMESA(Display *dpy, + GLXDrawable drawable, + int64_t *swapCount, + int64_t *missedFrames, + float *lastMissedUsage) + +New Tokens + + None + +Additions to Chapter 2 of the 1.4 GL Specification (OpenGL Operation) + + None + +Additions to Chapter 3 of the 1.4 GL Specification (Rasterization) + + None + +Additions to Chapter 4 of the 1.4 GL Specification (Per-Fragment Operations +and the Framebuffer) + + None + +Additions to Chapter 5 of the 1.4 GL Specification (Special Functions) + + None + +Additions to Chapter 6 of the 1.4 GL Specification (State and State Requests) + + None + +Additions to the GLX 1.3 Specification + + The frame usage is measured as the percentage of the swap period elapsed + between two buffer-swap operations being commited. In unextened GLX the + swap period is the vertical refresh time. If SGI_swap_control or + MESA_swap_control are supported, the swap period is the vertical refresh + time multiplied by the swap interval (or one if the swap interval is set + to zero). + + If OML_sync_control is supported, the swap period is the vertical + refresh time multiplied by the divisor parameter to + glXSwapBuffersMscOML. The frame usage in this case is less than 1.0 if + the swap is commited before target_msc, and is greater than or equal to + 1.0 otherwise. The actual usage value is based on the divisor and is + never less than 0.0. + + int glXBeginFrameTrackingMESA(Display *dpy, + GLXDrawable drawable, + float *usage) + + glXGetFrameUsageMESA returns a floating-point value in + that represents the current swap usage, as defined above. + + Missed frame swaps can be tracked by calling the following function: + + int glXBeginFrameTrackingMESA(Display *dpy, + GLXDrawable drawable) + + glXBeginFrameTrackingMESA resets a "missed frame" count and + synchronizes with the next frame vertical sync before it returns. + If a swap is missed based in the rate control specified by the + set by glXSwapIntervalSGI or the default swap of once + per frame, the missed frame count is incremented. + + The current missed frame count and total number of swaps since + the last call to glXBeginFrameTrackingMESA can be obtained by + callling the following function: + + int glXQueryFrameTrackingMESA(Display *dpy, + GLXDrawable drawable, + int64_t *swapCount, + int64_t *missedFrames, + float *lastMissedUsage) + + The location pointed to by will be updated with the + number of swaps that have been commited. This value may not match the + number of swaps that have been requested since swaps may be + queued by the implementation. This function can be called at any + time and does not synchronize to vertical blank. + + The location pointed to by will contain the number + swaps that missed the specified frame. The frame usage for the + last missed frame is returned in the location pointed to by + . + + Frame tracking is disabled by calling the function + + int glXEndFrameTrackingMESA(Display *dpy, + GLXDrawable drawable) + + This function will not return until all swaps have occurred. The + application can call glXQueryFrameTrackingMESA for a final swap and + missed frame count. + + If these functions are succesful, zero is returned. If the context + associated with dpy and drawable is not a direct context, + GLX_BAD_CONTEXT is returned. + +Errors + + If the function succeeds, zero is returned. If the function + fails, one of the following error codes is returned: + + GLX_BAD_CONTEXT The current rendering context is not a direct + context. + +GLX Protocol + + None. This extension only extends to direct rendering contexts. + +New State + + None + +New Implementation Dependent State + + None + +Revision History + + 1.1, 5/1/03 Added contact information. + 1.0, 3/17/03 Initial version based on WGL_I3D_swap_frame_usage. diff --git a/docs/MESA_trace.spec b/docs/MESA_trace.spec new file mode 100644 index 0000000..f0a79c7 --- /dev/null +++ b/docs/MESA_trace.spec @@ -0,0 +1,360 @@ +Name + + MESA_trace + +Name Strings + + GL_MESA_trace + +Contact + + Bernd Kreimeier, Loki Entertainment, bk 'at' lokigames.com + Brian Paul, VA Linux Systems, Inc., brianp 'at' valinux.com + +Status + + Obsolete. + +Version + + $Id: MESA_trace.spec,v 1.4 2004/03/25 01:42:42 brianp Exp $ + +Number + + none yet + +Dependencies + + OpenGL 1.2 is required. + The extension is written against the OpenGL 1.2 Specification + +Overview + + Provides the application with means to enable and disable logging + of GL calls including parameters as readable text. The verbosity + of the generated log can be controlled. The resulting logs are + valid (but possibly incomplete) C code and can be compiled and + linked for standalone test programs. The set of calls and the + amount of static data that is logged can be controlled at runtime. + The application can add comments and enable or disable tracing of GL + operations at any time. The data flow from the application to GL + and back is unaffected except for timing. + + Application-side implementation of these features raises namespace + and linkage issues. In the driver dispatch table a simple + "chain of responsibility" pattern (aka "composable piepline") + can be added. + +IP Status + + The extension spec is in the public domain. The current implementation + in Mesa is covered by Mesa's XFree86-style copyright by the authors above. + This extension is partially inspired by the Quake2 QGL wrapper. + +Issues + + + (1) Is this Extension obsolete because it can + be implemented as a wrapper DLL? + + RESOLVED: No. While certain operating systems (Win32) provide linkers + that facilitate this kind of solution, other operating systems + (Linux) do not support hierarchical linking, so a wrapper solution + would result in symbol collisions. + Further, IHV's might have builtin support for tracing GL execution + that enjoys privileged access, or that they do not wish to separate + the tracing code from their driver code base. + + (2) Should the Trace API explicitely support the notion of "frames? + This would require hooking into glXSwapBuffers calls as well. + + RESOLVED: No. The application can use NewTraceMESA/EndTraceMESA + and TraceComment along with external parsing tools to split the + trace into frames, in whatever way considered adequate. + + (2a) Should GLX calls be traced? + + PBuffers and other render-to-texture solutions demonstrate that + context level commands beyond SwapBuffers might have to be + traced. The GL DLL exports the entry points, so this would not + be out of the question. + + (3) Should the specification mandate the actual output format? + + RESOLVED: No. It is sufficient to guarantee that all data and commands + will be traced as requested by Enable/DisableTraceMESA, in the order + encountered. Whether the resulting trace is available as a readable + text file, binary metafile, compilable source code, much less which + indentation and formatting has been used, is up to the implementation. + For the same reason this specification does not enforce or prohibit + additional information added to the trace (statistics, profiling/timing, + warnings on possible error conditions). + + (4) Should the comment strings associated with names and pointer (ranges) + be considered persistent state? + + RESOLVED: No. The implementation is not forced to use this information + on subsequent occurences of name/pointer, and is free to consider it + transient state. + + (5) Should comment commands be prohibited between Begin/End? + + RESOLVED: Yes, with the exception of TraceCommentMESA. TraceCommentMESA + is transient, the other commands might cause storage of persistent + data in the context. There is no need to have the ability mark names + or pointers between Begin and End. + + +New Procedures and Functions + + void NewTraceMESA( bitfield mask, const ubyte * traceName ) + + void EndTraceMESA( void ) + + void EnableTraceMESA( bitfield mask ) + + void DisableTraceMESA( bitfield mask ) + + void TraceAssertAttribMESA( bitfield attribMask ) + + void TraceCommentMESA( const ubyte* comment ) + + void TraceTextureMESA( uint name, const ubyte* comment ) + + void TraceListMESA( uint name, const ubyte* comment ) + + void TracePointerMESA( void* pointer, const ubyte* comment ) + + void TracePointerRangeMESA( const void* first, + const void* last, + const ubyte* comment ) + +New Tokens + + Accepted by the parameter of EnableTrace and DisableTrace: + + TRACE_ALL_BITS_MESA 0xFFFF + TRACE_OPERATIONS_BIT_MESA 0x0001 + TRACE_PRIMITIVES_BIT_MESA 0x0002 + TRACE_ARRAYS_BIT_MESA 0x0004 + TRACE_TEXTURES_BIT_MESA 0x0008 + TRACE_PIXELS_BIT_MESA 0x0010 + TRACE_ERRORS_BIT_MESA 0x0020 + + Accepted by the parameter of GetIntegerv, GetBooleanv, + GetFloatv, and GetDoublev: + + TRACE_MASK_MESA 0x8755 + + Accepted by the parameter to GetString: + + TRACE_NAME_MESA 0x8756 + + +Additions to Chapter 2 of the OpenGL 1.2.1 Specification (OpenGL Operation) + + None. + +Additions to Chapter 3 of the OpenGL 1.2.1 Specification (OpenGL Operation) + + None. + +Additions to Chapter 4 of the OpenGL 1.2.1 Specification (OpenGL Operation) + + None. + +Additions to Chapter 5 of the OpenGL 1.2.1 Specification (Special Functions) + + Add a new section: + + 5.7 Tracing + + The tracing facility is used to record the execution of a GL program + to a human-readable log. The log appears as a sequence of GL commands + using C syntax. The primary intention of tracing is to aid in program + debugging. + + A trace is started with the command + + void NewTraceMESA( bitfield mask, const GLubyte * traceName ) + + may be any value accepted by PushAttrib and specifies a set of + attribute groups. The state values included in those attribute groups + is written to the trace as a sequence of GL commands. + + specifies a name or label for the trace. It is expected + that will be interpreted as a filename in most implementations. + + A trace is ended by calling the command + + void EndTraceMESA( void ) + + It is illegal to call NewTraceMESA or EndTraceMESA between Begin and End. + + The commands + + void EnableTraceMESA( bitfield mask ) + void DisableTraceMESA( bitfield mask ) + + enable or disable tracing of different classes of GL commands. + may be the union of any of TRACE_OPERATIONS_BIT_MESA, + TRACE_PRIMITIVES_BIT_MESA, TRACE_ARRAYS_BIT_MESA, TRACE_TEXTURES_BIT_MESA, + and TRACE_PIXELS_BIT_MESA. The special token TRACE_ALL_BITS_MESA + indicates all classes of commands are to be logged. + + TRACE_OPERATIONS_BIT_MESA controls logging of all commands outside of + Begin/End, including Begin/End. + + TRACE_PRIMITIVES_BIT_MESA controls logging of all commands inside of + Begin/End, including Begin/End. + + TRACE_ARRAYS_BIT_MESA controls logging of VertexPointer, NormalPointer, + ColorPointer, IndexPointer, TexCoordPointer and EdgeFlagPointer commands. + + TRACE_TEXTURES_BIT_MESA controls logging of texture data dereferenced by + TexImage1D, TexImage2D, TexImage3D, TexSubImage1D, TexSubImage2D, and + TexSubImage3D commands. + + TRACE_PIXELS_BIT_MESA controls logging of image data dereferenced by + Bitmap and DrawPixels commands. + + TRACE_ERRORS_BIT_MESA controls logging of all errors. If this bit is + set, GetError will be executed whereever applicable, and the result will + be added to the trace as a comment. The error returns are cached and + returned to the application on its GetError calls. If the user does not + wish the additional GetError calls to be performed, this bit should not + be set. + + The command + + void TraceCommentMESA( const ubyte* comment ) + + immediately adds the string to the trace output, surrounded + by C-style comment delimiters. + + The commands + + void TraceTextureMESA( uint name, const ubyte* comment ) + void TraceListMESA( uint name, const ubyte* comment ) + + associates with the texture object or display list specified + by . Logged commands which reference the named texture object or + display list will be annotated with . If IsTexture(name) or + IsList(name) fail (respectively) the command is quietly ignored. + + The commands + + void TracePointerMESA( void* pointer, const ubyte* comment ) + + void TracePointerRangeMESA( const void* first, + const void* last, + const ubyte* comment ) + + associate with the address specified by or with + a range of addresses specified by through . + Any logged commands which reference or an address between + and will be annotated with . + + The command + + void TraceAssertAttribMESA( bitfield attribMask ) + + will add GL state queries and assertion statements to the log to + confirm that the current state at the time TraceAssertAttrib is + executed matches the current state when the trace log is executed + in the future. + + is any value accepted by PushAttrib and specifies + the groups of state variables which are to be asserted. + + The commands NewTraceMESA, EndTraceMESA, EnableTraceMESA, DisableTraceMESA, + TraceAssertAttribMESA, TraceCommentMESA, TraceTextureMESA, TraceListMESA, + TracePointerMESA and TracePointerRangeMESA are not compiled into display lists. + + + Examples: + + The command NewTraceMESA(DEPTH_BUFFER_BIT, "log") will query the state + variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE + to get the values , , , and respectively. + Statements equivalent to the following will then be logged: + + glEnable(GL_DEPTH_TEST); (if is true) + glDisable(GL_DEPTH_TEST); (if is false) + glDepthFunc(); + glDepthMask(); + glClearDepth(); + + + The command TraceAssertAttribMESA(DEPTH_BUFFER_BIT) will query the state + variables DEPTH_TEST, DEPTH_FUNC, DEPTH_WRITEMASK, and DEPTH_CLEAR_VALUE + to get the values , , , and respectively. + The resulting trace might then look will like this: + + { + GLboolean b; + GLint i; + GLfloat f; + b = glIsEnabled(GL_DEPTH_TEST); + assert(b == ); + glGetIntegerv(GL_DEPTH_FUNC, &i); + assert(i == ); + glGetIntegerv(GL_DEPTH_MASK, &i); + assert(i == ); + glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f); + assert(f == ); + } + + +Additions to Chapter 6 of the OpenGL 1.2.1 Specification + (State and State Requests) + + Querying TRACE_MASK_MESA with GetIntegerv, GetFloatv, GetBooleanv or + GetDoublev returns the current command class trace mask. + + Querying TRACE_NAME_MESA with GetString returns the current trace name. + + +Additions to Appendix A of the OpenGL 1.2.1 Specification (Invariance) + + The MESA_trace extension can be used in a way that does not affect data + flow from application to OpenGL, as well as data flow from OpenGL to + application, except for timing, possible print I/O. TRACE_ERRORS_BIT_MESA + will add additional GetError queries. Setting a trace mask with NewTraceMESA + as well as use of TraceAssertAttribMESA might cause additional state queries. + With the possible exception of performance, OpenGL rendering should not be + affected at all by a properly chosen logging operation. + +Additions to the AGL/GLX/WGL Specifications + + None. + +GLX Protocol + + None. The logging operation is carried out client-side, by exporting + entry points to the wrapper functions that execute the logging operation. + +Errors + + INVALID_OPERATION is generated if any trace command except TraceCommentMESA + is called between Begin and End. + +New State + + The current trace name and current command class mask are stored + per-context. + +New Implementation Dependent State + + None. + +Revision History + + * Revision 0.1 - Initial draft from template (bk000415) + * Revision 0.2 - Draft (bk000906) + * Revision 0.3 - Draft (bk000913) + * Revision 0.4 - Reworked text, fixed typos (bp000914) + * Revision 0.5 - Assigned final GLenum values (bp001103) + * Revision 0.6 - TRACE_ERRORS_BIT_MESA (bk000916) + * Revision 0.7 - Added MESA postfix (bk010126) + diff --git a/docs/MESA_window_pos.spec b/docs/MESA_window_pos.spec new file mode 100644 index 0000000..eb1d0d1 --- /dev/null +++ b/docs/MESA_window_pos.spec @@ -0,0 +1,127 @@ +Name + + MESA_window_pos + +Name Strings + + GL_MESA_window_pos + +Contact + + Brian Paul, brian.paul 'at' tungstengraphics.com + +Status + + Shipping (since Mesa version 1.2.8) + +Version + + $Id: MESA_window_pos.spec,v 1.4 2004/03/25 01:42:42 brianp Exp $ + +Number + + 197 + +Dependencies + + OpenGL 1.0 is required. + The extension is written against the OpenGL 1.2 Specification + +Overview + + In order to set the current raster position to a specific window + coordinate with the RasterPos command, the modelview matrix, projection + matrix and viewport must be set very carefully. Furthermore, if the + desired window coordinate is outside of the window's bounds one must + rely on a subtle side-effect of the Bitmap command in order to circumvent + frustum clipping. + + This extension provides a set of functions to directly set the + current raster position, bypassing the modelview matrix, the + projection matrix and the viewport to window mapping. Furthermore, + clip testing is not performed. + + This greatly simplifies the process of setting the current raster + position to a specific window coordinate prior to calling DrawPixels, + CopyPixels or Bitmap. + +New Procedures and Functions + + void WindowPos2dMESA(double x, double y) + void WindowPos2fMESA(float x, float y) + void WindowPos2iMESA(int x, int y) + void WindowPos2sMESA(short x, short y) + void WindowPos2ivMESA(const int *p) + void WindowPos2svMESA(const short *p) + void WindowPos2fvMESA(const float *p) + void WindowPos2dvMESA(const double *p) + void WindowPos3iMESA(int x, int y, int z) + void WindowPos3sMESA(short x, short y, short z) + void WindowPos3fMESA(float x, float y, float z) + void WindowPos3dMESA(double x, double y, double z) + void WindowPos3ivMESA(const int *p) + void WindowPos3svMESA(const short *p) + void WindowPos3fvMESA(const float *p) + void WindowPos3dvMESA(const double *p) + void WindowPos4iMESA(int x, int y, int z, int w) + void WindowPos4sMESA(short x, short y, short z, short w) + void WindowPos4fMESA(float x, float y, float z, float w) + void WindowPos4dMESA(double x, double y, double z, double ) + void WindowPos4ivMESA(const int *p) + void WindowPos4svMESA(const short *p) + void WindowPos4fvMESA(const float *p) + void WindowPos4dvMESA(const double *p) + +New Tokens + + none + +Additions to Chapter 2 of the OpenGL 1.2 Specification (OpenGL Operation) + + - (2.12, p. 41) Insert after third paragraph: + + Alternately, the current raster position may be set by one of the + WindowPosMESA commands: + + void WindowPos{234}{sidf}MESA( T coords ); + void WindowPos{234}{sidf}vMESA( T coords ); + + WindosPos4MESA takes four values indicating x, y, z, and w. + WindowPos3MESA (or WindowPos2MESA) is analaguos, but sets only + x, y, and z with w implicitly set to 1 (or only x and y with z + implicititly set to 0 and w implicitly set to 1). + + WindowPosMESA operates like RasterPos except that the current modelview + matrix, projection matrix and viewport parameters are ignored and the + clip test operation always passes. The current raster position values + are directly set to the parameters passed to WindowPosMESA. The current + color, color index and texture coordinate update the current raster + position's associated data. + +Additions to the AGL/GLX/WGL Specifications + + None + +GLX Protocol + + Not specified at this time. However, a protocol message very similar + to that of RasterPos is expected. + +Errors + + INVALID_OPERATION is generated if WindowPosMESA is called betweeen + Begin and End. + +New State + + None. + +New Implementation Dependent State + + None. + +Revision History + + * Revision 1.0 - Initial specification + * Revision 1.1 - Minor clean-up (7 Jan 2000, Brian Paul) + diff --git a/docs/MESA_ycbcr_texture.spec b/docs/MESA_ycbcr_texture.spec new file mode 100644 index 0000000..0fa1f7b --- /dev/null +++ b/docs/MESA_ycbcr_texture.spec @@ -0,0 +1,204 @@ +Name + + MESA_ycbcr_texture + +Name Strings + + GL_MESA_ycbcr_texture + +Contact + + Brian Paul, Tungsten Graphics, Inc. (brian.paul 'at' tungstengraphics.com) + Keith Whitwell, Tungsten Graphics, Inc. (keith 'at' tungstengraphics.com) + +Status + + Shipping (Mesa 4.0.4 and later) + +Version + + 1.0 + +Number + + TBD + +Dependencies + + OpenGL 1.0 or later is required + This extensions is written against the OpenGL 1.4 Specification. + NV_texture_rectangle effects the definition of this extension. + +Overview + + This extension supports texture images stored in the YCbCr format. + There is no support for converting YCbCr images to RGB or vice versa + during pixel transfer. The texture's YCbCr colors are converted to + RGB during texture sampling, after-which, all the usual per-fragment + operations take place. Only 2D texture images are supported (not + glDrawPixels, glReadPixels, etc). + + A YCbCr pixel (texel) is a 16-bit unsigned short with two components. + The first component is luminance (Y). For pixels in even-numbered + image columns, the second component is Cb. For pixels in odd-numbered + image columns, the second component is Cr. If one were to convert the + data to RGB one would need to examine two pixels from columns N and N+1 + (where N is even) to deduce the RGB color. + +IP Status + + None + +Issues + + None + +New Procedures and Functions + + None + +New Tokens + + Accepted by the and parameters of + TexImage2D and TexSubImage2D: + + YCBCR_MESA 0x8757 + + Accepted by the parameter of TexImage2D and TexSubImage2D: + + UNSIGNED_SHORT_8_8_MESA 0x85BA /* same as Apple's */ + UNSIGNED_SHORT_8_8_REV_MESA 0x85BB /* same as Apple's */ + +Additions to Chapter 2 of the OpenGL 1.4 Specification (OpenGL Operation) + + None + +Additions to Chapter 3 of the OpenGL 1.4 Specification (Rasterization) + + In section 3.6.4, Rasterization of Pixel Rectangles, on page 101, + add the following to Table 3.8 (Packed pixel formats): + + type Parameter GL Data Number of Matching + Token Name Type Components Pixel Formats + -------------- ------- ---------- ------------- + UNSIGNED_SHORT_8_8_MESA ushort 2 YCBCR_MESA + UNSIGNED_SHORT_8_8_REV_MESA ushort 2 YCBCR_MESA + + + In section 3.6.4, Rasterization of Pixel Rectangles, on page 102, + add the following to Table 3.10 (UNSIGNED_SHORT formats): + + UNSIGNED_SHORT_8_8_MESA: + + 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + +-------------------------------+-------------------------------+ + | 1st | 2nd | + +-------------------------------+-------------------------------+ + + UNSIGNED_SHORT_8_8_REV_MESA: + + 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + +-------------------------------+-------------------------------+ + | 2nd | 1st | + +-------------------------------+-------------------------------+ + + + In section 3.6.4, Rasterization of Pixel Rectangles, on page 104, + add the following to Table 3.12 (Packed pixel fiedl assignments): + + First Second Third Fourth + Format Element Element Element Element + ------ ------- ------- ------- ------- + YCBCR_MESA luminance chroma + + + In section 3.8.1, Texture Image Specification, on page 125, add + another item to the list of TexImage2D and TexImage3D equivalence + exceptions: + + * The value of internalformat and format may be YCBCR_MESA to + indicate that the image data is in YCbCr format. type must + be either UNSIGNED_SHORT_8_8_MESA or UNSIGNED_SHORT_8_8_REV_MESA + as seen in tables 3.8 and 3.10. Table 3.12 describes the mapping + between Y and Cb/Cr to the components. + If NV_texture_rectangle is supported target may also be + TEXTURE_RECTANGLE_NV or PROXY_TEXTURE_RECTANGLE_NV. + All pixel transfer operations are bypassed. The texture is stored as + YCbCr, not RGB. Queries of the texture's red, green and blue component + sizes will return zero. The YCbCr colors are converted to RGB during + texture sampling using an implementation dependent conversion. + + + In section 3.8.1, Texture Image Specification, on page 126, add + another item to the list of TexImage1D and TexImage2D equivalence + exceptions: + + * The value of internalformat and format can not be YCBCR_MESA. + + + In section 3.8.2, Alternate Texture Image Specification Commands, on + page 129, insert this paragraph after the first full paragraph on the + page: + + "If the internal storage format of the image being updated by + TexSubImage2D is YCBCR_MESA then format must be YCBCR_MESA. + The error INVALID_OPERATION will be generated otherwise." + + +Additions to Chapter 4 of the OpenGL 1.4 Specification (Per-Fragment +Operations and the Frame Buffer) + + None + +Additions to Chapter 5 of the OpenGL 1.4 Specification (Special Functions) + + None + +Additions to Chapter 6 of the OpenGL 1.4 Specification (State and +State Requests) + + None + +Additions to Appendix A of the OpenGL 1.4 Specification (Invariance) + + None + +Additions to the AGL/GLX/WGL Specifications + + None + +GLX Protocol + + None + +Errors + + INVALID_ENUM is generated by TexImage2D if is + MESA_YCBCR but is not MESA_YCBCR. + + INVALID_ENUM is generated by TexImage2D if is MESA_YCBCR but + is not MESA_YCBCR. + + INVALID_VALUE is generated by TexImage2D if is MESA_YCBCR and + is MESA_YCBCR and is not zero. + + INVALID_OPERATION is generated by TexSubImage2D if the internal image + format is YCBCR_MESA and is not YCBCR_MESA. + + INVALID_OPERATION is generated by CopyTexSubImage2D if the internal + image is YCBCR_MESA. + +New State + + Edit table 6.16 on page 231: change the type of TEXTURE_INTERNAL_FORMAT + from n x Z42 to n x Z43 to indicate that internal format may also be + YCBCR_MESA. + +Revision History + + 20 September 2002 - Initial draft + 29 April 2003 - minor updates + 3 September 2003 - further clarify when YCbCr->RGB conversion takes place + 19 September 2003 - a few more updates prior to submitting to extension + registry. + 3 April 2004 - fix assorted inaccuracies diff --git a/docs/MiniGLX.html b/docs/MiniGLX.html new file mode 100644 index 0000000..3429812 --- /dev/null +++ b/docs/MiniGLX.html @@ -0,0 +1,547 @@ + + + + Mini GLX Specification + + +

+
Mini GLX Specification
+

+

+
Tungsten Graphics, Inc.
+
+January 20, 2003
+
+
+

+

Copyright © 2002-2003 by Tungsten Graphics, Inc., Cedar Park, +Texas. All Rights Reserved.
+
+Permission is granted to make and distribute verbatim copies of this +document provided the copyright notice and this permission notice are +preserved on all copies.
+
+

+

1. Introduction

+

The Mini GLX interface facilitates OpenGL rendering on embedded +devices. The interface is a subset of the GLX interface, plus a minimal +set of Xlib-like functions.

+

Programs written to the Mini GLX specification should run unchanged +on systems with the X Window System and the GLX extension. The intention +is to allow flexibility for prototyping and testing.

+

This document serves as both the reference guide and programming +guide for Mini GLX.
+
+

+

2. Mini GLX Concepts

+

The OpenGL specification does not describe how OpenGL rendering +contexts and drawing surfaces (i.e. the frame buffer) are created and +managed. Rather, this is handled by an OpenGL window system interface, +such as Mini GLX.

+

There are three main datatypes or resources managed by Mini GLX. The +resources and their corresponding GLX or Xlib data types are:

+ + + + + + + + + + + + + + + + + + + +
ResourceData type
pixel formatsX Visual and XVisualInfo
drawing surfacesX Window or GLXDrawable
rendering contextsGLXContext
+

Pixel formats or X Visuals describe the per-pixel attributes of the +frame buffer. For example, bits per color component, Z buffer size, +stencil size, TrueColor vs PseudoColor, etc.

+

Drawing surfaces or X Windows typically describe a spatial +allocation of the frame buffer (i.e. the position and size of a +rectangular region of pixels). Since MiniGLX doesn't really support a +window system, the window is effectively the entire frame buffer.

+

A rendering context represents the current OpenGL state such as +current drawing color, line width, blending mode, texture parameters, +etc. Several rendering contexts can be created but only one can be in +use at any given time.

+

The Mini GLX interface provides all the functions needed for +choosing pixel formats, create drawing surfaces, creating rendering +contexts and binding rendering contexts to drawing surfaces.
+
+

+

3. Using Mini GLX

+

To use the Mini GLX interface in your application, include the +GL/miniglx.h header file at compile time:

+
#include <GL/miniglx.h>
+
+Applications should link with libGL.so (i.e. gcc +myprogram.o -lGL -o myprogram).  libGL.so implements the +MiniGLX API functions and, in turn, loads a hardware-specific device +driver (such as radeon_dri.so) at runtime.  The +environment variable LIBGL_DRIVERS_PATH should name the +directory where these modules are located.
+
+Prior to running a MiniGXL application, the following kernel modules +must be installed:
+
+
agpgart.o
+radeonfb.o  (assuming Radeon hardware)
+radeon.o  (assuming Radeon hardware)
+
+
+Finally, MiniGLX reads a configuration file (by default, +/etc/miniglx.conf) to determine basic configuration information. + The configuration file may also be located in the directory +specified by the MINIGLX_CONF environment variable).
+
+The remainder of this section describes the MiniGLX API functions.
+
+

3.1 Initialization

+

The XOpenDisplay function is used to initialize the graphics system:

+
+ 
Display *XOpenDisplay(const char *displayname)
+
+

The displayName parameter is currently ignored in Mini +GLX. It is recommended that NULL be passed as thedisplayName +parameter.

+

If XOpenDisplay is able to initialize the graphics system a pointer +to a Display will be returned. Otherwise, NULL will be returned.

+

3.2 Choosing a Visual

+

A visual (i.e. pixel format) must be chosen before a drawing surface +or rendering context can be created. This is done with the +glXChooseVisual function:

+
+ 
XVisualInfo *glXChooseVisual(Display *dpy, int screen, const int *attribList)
+
+

dpy is a pointer to the display returned by +XOpenDisplay.

+

screen is currently ignored by Mini GLX and should be +zero.

+

attribList is a list of GLX attributes which describe +the desired pixel format. It is terminated by the token None. +The attributes are as follows:

+
+
+
GLX_USE_GL
+
This attribute should always be present in order to maintain +compatibility with GLX.
+
GLX_RGBA
+
If present, only RGBA pixel formats will be considered. +Otherwise, only color index formats are considered.
+
GLX_DOUBLEBUFFER
+
if present, only double-buffered pixel formats will be chosen.
+
GLX_RED_SIZE n
+
Must be followed by a non-negative integer indicating the +minimum number of bits per red pixel component that is acceptable.
+
GLX_GREEN_SIZE n
+
Must be followed by a non-negative integer indicating the +minimum number of bits per green pixel component that is acceptable.
+
GLX_BLUE_SIZE n
+
Must be followed by a non-negative integer indicating the +minimum number of bits per blue pixel component that is acceptable.
+
GLX_ALPHA_SIZE n
+
Must be followed by a non-negative integer indicating the +minimum number of bits per alpha pixel component that is acceptable.
+
GLX_STENCIL_SIZE n
+
Must be followed by a non-negative integer indicating the +minimum number of bits per stencil value that is acceptable.
+
None
+
This token is used to terminate the attribute list.
+
+
+

glXChooseVisual will return a pointer to an XVisualInfo object which +most closely matches the requirements of the attribute list. If there +is no visual which matches the request, NULL will be returned.

+

Note that visuals with accumulation buffers and depth buffers are +not available.
+
+

+

3.3 Creating a Drawing Surface

+

Drawing surfaces are created as X windows.  For Mini GLX, +windows are full-screen; they cover the entire frame buffer. + Also, Mini GLX imposes a limit of one window. A second window +cannot be created until the first one is destroyed.

+

3.3.1 Window Creation

+

The XCreateWindow function is used to create a drawing surface:

+
+ 
Window XCreateWindow( Display *display,
                      Window parent,
                      int x, int y,
                      unsigned int width, unsigned int height,
                      unsigned int borderWidth,
                      int depth,
                      unsigned int class,
                      Visual *visual,
                      unsigned long valuemask,
                      XSetWindowAttributes *attributes )
+
+

The parameters are as follows:

+
+
+
display
+
A Display pointer, as returned by XOpenDisplay.
+
parent
+
The parent window for the new window. For Mini GLX, this +should beRootWindow(dpy, 0).
+
x, y
+
The position of the window. For Mini GLX, both values should +be zero.
+
width, height
+
The size of the window. For Mini GLX, this specifies the +desired screen size such as 1024, 768 or 1280, 1024.
+
borderWidth
+
This parameter should be zero.
+
depth
+
The pixel depth for the window. For Mini GLX this should be +the depth found in the XVisualInfo object returned by glxChooseVisual.
+
class
+
The window class. For Mini GLX this value should be InputOutput.
+
visual
+
This parameter should be the visual field of the XVisualInfo +object returned by glxChooseVisual.
+
valuemask
+
This parameter indicates which fields of the XSetWindowAttributes +are to be used. For Mini GLX this is typically the bitmaskCWBackPixel +| CWBorderPixel | CWColormap.
+
attributes
+
Initial window attributes. Of the fields in the XSetWindowAttributes +structure, thebackground_pixel, border_pixel +and colormap fields should be set.  See the discussion +below regarding colormaps.
+
+
+

XCreateWindow will return a window handle if it succeeds +or zero if it fails.

+

3.3.2 Window Mapping

+

To display the window the XMapWindow function must be called:

+
+ 
void XMapWindow(Display *dpy, Window w)
+
+

This function does nothing in Mini GLX but is required for Xlib/GLX +compatibility

+

3.3.3 Colormaps
+

+

Xlib requires specification of a colormap when creating a window. + For purposes of interoperability, Mini GLX requires this as well, +though the colormap is not actually used.  The XCreateColormap +function is used to create a colormap:

+
Colormap XCreateColormap(Display *dpy, Window window, +Visual *visual, int alloc)
+
+

The parameters are as follows:
+

+
+
+
dpy
+
The display handle as returned by XOpenDisplay.
+
window
+
This parameter is ignored by Mini GLX but should be the value +returned by the RootWindow(dpy, 0) macro.
+
+
visual
+
This parameter is ignored by Mini GLX but should be the visual +field of the XVisualInfo object returned by glXChooseVisual.
+
alloc
+
This parameter is ignored by Mini GLX but should be set to AllocNone.
+
+
+
+

3.4 Creating a Rendering Context

+

An OpenGL rendering context is created with the glXCreateContext +function:

+
+ 
GLXContext glXCreateContext(Display *dpy, XVisualInfo *visInfo, GLXContext shareList, Bool direct)
+
+

The parameters are as follows:

+
+
+
dpy
+
The display handle as returned by XOpenDisplay.
+
visInfo
+
The visual as returned by glXChooseVisual.
+
shareList
+
If non-zero, texture objects and display lists are shared with +the named rendering context. If zero, texture objects and display lists +will (initially) be private to this context. They may be shared when a +subsequent context is created.
+
direct
+
Specifies whether direct or indirect rendering is desired. For +Mini GLX this value is ignored but it should be set to True.
+
+
+

glXCreateContext will return a GLXContext handle if it +succeeds or zero if it fails due to invalid parameter or insufficient +resources.
+
+

+

3.5 Binding a Rendering Context

+

The final step before beginning OpenGL rendering is to bind (i.e. +activate) a rendering context and drawing surface with the +glXMakeCurrent function:

+
+ 
Bool glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)
+
+

The parameters are as follows:

+
+
+
dpy
+
The display handle, as returned by XOpenDisplay.
+
drawable
+
The window or drawable to bind to the rendering context. This +should be the value returned by XCreateWindow.
+
ctx
+
The rendering context to bind, as returned by glXCreateContext.
+
+
+

If glXMakeCurrent succeeds True is returned. Otherwise False is +returned to indicate an invalid display, window or context parameter.

+

After the rendering context has been bound to the drawing surface +OpenGL rendering can begin.

+

The current rendering context may be unbound by calling +glXMakeCurrent with the window and context parameters set to zero.

+

An application may create any number of rendering contexts and bind +them as needed. Note that binding a rendering context is generally not a +light-weight operation.  Most simple OpenGL applications create +only one rendering context.
+
+

+

3.6 Color Buffer Swapping

+

A double buffered window has two color buffers: a front buffer and a +back buffer. Normally, rendering is directed to the back buffer while +the front buffer is displayed. When rendering of a frame is finished +the front and back buffers are swapped to provide the illusion of +instanteous screen updates.

+

The color buffers for a particular window (i.e. drawable) may be +swapped with the glXSwapBuffers command:

+
+ 
void glXSwapBuffers(Display *dpy, GLXDrawable drawable)
+
+Any pending rendering commands will be completed before the buffer swap +takes place.
+
+Calling glXSwapBuffers on a window which is single-buffered has no +effect.
+
+

3.7 Releasing Resources

+

3.7.1 Releasing Rendering Contexts

+

A rendering context may be destroyed by calling glXDestroyContext:

+
+ 
void glXDestroyContext(Display *dpy, GLXContext ctx)
+
+

3.7.2 Releasing Windows

+

A window may be destroyed by calling XDestroyWindow:

+
+ 
void XDestroyWindow(Display *dpy, Window window)
+
+

3.7.3 Releasing Visuals

+

An XVisualInfo object may be freed by calling XFree:

+
+ 
void XFree(void *data)
+
+

3.7.4 Releasing Colormaps

+

A colormap may be freed by calling XFreeColormap:

+
+ 
void XFreeColormap(Display *dpy, Colormap colormap)
+
+

3.7.4 Releasing Display Resources

+

When the application is about to exit, the resources associated with +the graphics system can be released by calling XCloseDisplay:

+
+ 
void XCloseDisplay(Display *dpy)
+
+

The display handle becomes invalid at this point.
+
+

+

3.8 Query Functions

+

3.8.1 Querying Available Visuals

+A list of all available visuals can be obtained with the XGetVisualInfo +function:
+
+
XVisualInfo +*XGetVisualInfo(Display *dpy, long vinfo_mask, XVisualInfo +*vinfo_template, int *nitems_return)
+
+
+The parameters are as follows:
+
+
+
dpy
+
The display handle, as returned by XOpenDisplay.
+
vinfo_mask
+
A bitmask indicating which fields of the vinfo_template are to +be matched.  The value must be VisualScreenMask.
+
vinfo_template
+
A template whose fields indicate which visual attributes must +be matched by the results.  The screen field of this structure must +be zero.
+
nitems_return
+
Returns the number of visuals returned.
+
+
+The return value is the address of an array of all available visuals.
+
+An example of using XGetVisualInfo to get all available visuals follows:
+
+
XVisualInfo visTemplate, *results;
+int numVisuals;
+Display *dpy = XOpenDisplay(NULL);
+visTemplate.screen = 0;
+results = XGetVisualInfo(dpy, VisualScreenMask, &visTemplate, +&numVisuals);
+
+
+

3.8.2 Querying Visual Attributes

+

The GLX attributes of an X visual may be queried with the +glXGetConfig function:

+
+ 
int glXGetConfig(Display *dpy, XVisualInfo *vis, int attribute, int *value)
+
+

The parameters are as follows:

+
+
+
dpy
+
The display handle, as returned by XOpenDisplay.
+
vis
+
The visual, as returned by glXChooseVisual.
+
attribute
+
The attribute to query. The attributes are listed below.
+
value
+
Pointer to an integer in which the result of the query will be +stored.
+
+
+

The return value will be zero if no error occurs. + GLX_INVALID_ATTRIBUTE will be returned if the attribute +parameter is invalid.  GLX_BAD_VISUAL will be returned +if the XVisualInfo parameter is invalid.

+

The following attributes may be queried:

+
+
+
GLX_USE_GL
+
The result will be True or False to +indicate if OpenGL rendering is supported with the visual. Mini GLX +always return True.
+
GLX_RGBA
+
The result will be True for RGBA visuals or False +for color index visuals.
+
GLX_DOUBLEBUFFER
+
The result will be True if the visual has two +color buffers or False if the visual has one color buffer.
+
GLX_RED_SIZE
+
The result will be the number of red bits per pixel.
+
GLX_GREEN_SIZE
+
The result will be the number of green bits per pixel.
+
GLX_BLUE_SIZE
+
The result will be the number of blue bits per pixel.
+
GLX_ALPHA_SIZE
+
The result will be the number of alpha bits per pixel.
+
GLX_DEPTH_SIZE
+
The result will be the number of bits per Z value.
+
GLX_STENCIL_SIZE
+
The result will be the number of bits per stencil value.
+
+
+
+
+

3.8.3 Querying the Current Rendering Context

+

The current rendering context can be queried with +glXGetCurrentContext:

+
+ 
GLXContext glXGetCurrentContext(void)
+
+

Zero will be returned if no context is currently bound.
+
+

+

3.8.4 Querying the Current Drawable

+

The current drawable (i.e. window or drawing surface) can be queried +with glXGetCurrentDrawable:

+
+ 
GLXDrawable glXGetCurrentDrawable(void)
+
+

Zero will be returned if no drawable is currently bound.
+
+

+

3.8.5 Function Address Queries

+

The glXGetProcAddress function will return the address of any +available OpenGL or Mini GLX function:

+
+ 
void *glXGetProcAddress(const GLubyte *procName)
+
+

If procName is a valid function name, a pointer to that +function will be returned.  Otherwise, NULL will be returned.

+

The purpose of glXGetProcAddress is to facilitate using future +extensions to OpenGL or Mini GLX. If a future version of the library +adds new extension functions they'll be accessible via +glXGetProcAddress. The alternative is to hard-code calls to the new +functions in the application but doing so will prevent linking the +application with older versions of the library.
+
+

+

3.9 Versioning

+The Mini GLX version can be queried at run time with glXQueryVersion: +
+ 
Bool glXQueryVersion(Display *dpy, int *major, int *minor)
+
+

major will be set to the major version number andminor +will be set to the minor version number.True will be +returned if the function succeeds. False will be returned +if the function fails due to invalid parameters. The dpy +argument is currently ignored, but should be the value returned by +XOpenDisplay.

+

At compile time, the Mini GLX interface version can be tested with +the MINI_GLX_VERSION_1_x preprocessor tokens. For example, if +version 1.0 of Mini GLX is supported, then MINI_GLX_VERSION_1_0 +will be defined. If version 1.1 of Mini GLX is supported, then +MINI_GLX_VERSION_1_1 will be defined.

+

At the time of writing the current Mini GLX version is 1.0.
+
+

+

4.0 Interoperability with GLX and Xlib

+While Mini GLX strives to be compatible with GLX and Xlib there are +some unavoidable differences which must be taken into consideration.
+

4.1 Public vs Private Structures

+The structure of many X data types is public.  For example, the Display +data type is defined as a structure in /usr/include/X11/Xlib.h and +programmers may access any fields of that structure at will.  Mini +GLX also defines a Display data type but its fields are hidden and not +visiblein miniglx.h.  Duplicating the Xlib +declaration for the Display data type in minigl.h would +require defining a large number of other superfluous Xlib datatypes.
+
+Mini GLX users are discouraged from directly accessing the fields of +Xlib data types to maximize portability - though this is unavoidable to +some extent.  For example, the XVisualInfo and XSetWindowAtttributes +data types must be completely public. +

4.2 Macros

+In some cases, Xlib defines macros which are meant to be used instead +of direct structure accesses.  For example, the RootWindow(dpy, +screen) macro returns the root window for a given screen on a +given display.  Unfortunately, macros do nothing to aid in ABI +compatibility since they are resolved at compile time instead of at +link/run time.
+
+Mini GLX also defines a RootWindow macro since it's +essential for creating windows.  But the implementation of this +macro by Xlib and Mini GLX is completely different.
+

4.3 Summary

+Because Xlib and Mini GLX define data types and macros differently, +Mini GLX applications must be recompiled when retargeting Mini GLX or +native Xlib/GLX.  That is, applications can't simply be re-linked +because of ABI incompatibilities.
+
+Nevertheless, the fact that Mini GLX programs can be recompiled for +Xlib and GLX increases portability and flexibility for testing and +prototyping.
+
+

5.0 Example Program

+

This section shows an example program which uses the Mini GLX +interface. The program simply draws several frames of a rotating square.
+

+

The program may be compiled for use with Xlib/GLX or Mini GLX by +setting the USE_MINIGLX token to 0 or 1, respectively. + Note that the only difference is the header files which are +included.
+

+

+

#define USE_MINIGLX 1  /* 1 = use Mini GLX, 0 = use Xlib/GLX */

#include <stdio.h>
#include <stdlib.h>
#include <GL/gl.h>

#if USE_MINIGLX
#include <GL/miniglx.h>
#else
#include <GL/glx.h>
#include <X11/Xlib.h>
#endif

/*
 * Create a simple double-buffered RGBA window.
 */
static Window
MakeWindow(Display * dpy, unsigned int width, unsigned int height)
{
   int visAttributes[] = {
      GLX_RGBA,
      GLX_RED_SIZE, 1,
      GLX_GREEN_SIZE, 1,
      GLX_BLUE_SIZE, 1,
      GLX_DOUBLEBUFFER,
      None
   };
   XSetWindowAttributes attr;
   unsigned long attrMask;
   Window root;
   Window win;
   GLXContext ctx;
   XVisualInfo *visinfo;

   root = RootWindow(dpy, 0);

   /* Choose GLX visual / pixel format */
   visinfo = glXChooseVisual(dpy, 0, visAttributes);
   if (!visinfo) {
      printf("Error: couldn't get an RGB, Double-buffered visual\n");
      exit(1);
   }

   /* Create the window */
   attr.background_pixel = 0;
   attr.border_pixel = 0;
   attr.colormap = XCreateColormap(dpy, root, visinfo->visual, AllocNone);
   attrMask = CWBackPixel | CWBorderPixel | CWColormap;
   win = XCreateWindow(dpy, root, 0, 0, width, height,
		       0, visinfo->depth, InputOutput,
		       visinfo->visual, attrMask, &attr);
   if (!win) {
      printf("Error: XCreateWindow failed\n");
      exit(1);
   }

   /* Display the window */
   XMapWindow(dpy, win);

   /* Create GLX rendering context */
   ctx = glXCreateContext(dpy, visinfo, NULL, True);
   if (!ctx) {
      printf("Error: glXCreateContext failed\n");
      exit(1);
   }

   /* Bind the rendering context and window */
   glXMakeCurrent(dpy, win, ctx);

   return win;
}


/*
 * Draw a few frames of a rotating square.
 */
static void
DrawFrames(Display * dpy, Window win)
{
   int angle;
   glShadeModel(GL_FLAT);
   glClearColor(0.5, 0.5, 0.5, 1.0);
   for (angle = 0; angle < 360; angle += 10) {
      glClear(GL_COLOR_BUFFER_BIT);
      glColor3f(1.0, 1.0, 0.0);
      glPushMatrix();
      glRotatef(angle, 0, 0, 1);
      glRectf(-0.8, -0.8, 0.8, 0.8);
      glPopMatrix();
      glXSwapBuffers(dpy, win);
   }
}


int
main(int argc, char *argv[])
{
   Display *dpy;
   Window win;

   dpy = XOpenDisplay(NULL);
   if (!dpy) {
      printf("Error: XOpenDisplay failed\n");
      return 1;
   }

   win = MakeWindow(dpy, 300, 300);

   DrawFrames(dpy, win);

   return 0;
}
+
+ + diff --git a/docs/README.3DFX b/docs/README.3DFX new file mode 100644 index 0000000..739d06f --- /dev/null +++ b/docs/README.3DFX @@ -0,0 +1,828 @@ + + 3Dfx Glide device driver + + + +Mesa-6.2 release notes: +----------------------- + +1) Glide2 support has been ceased; please visit the Glide SourceForge and + help us improve Glide3. +2) The current release is a WIP; among other things, the Linux build works + only to some extent. Voodoo Rush not fully tested. Any help will be + appreciated. +3) Although Mesa is designed to work with any Glide3, it would benefit from + interacting with newer Glide libraries, which can export functions like: + `grGetRegistryOrEnvironmentStringExt', `grSetNumPendingBuffers', Texus2 + and pointcast palette. The latest Glide3 can be reached here: + http://sourceforge.net/projects/glide/ + + + +Known supported HW/OS: +---------------------- + +Voodoo-based videocards/accelerators +DOS (DJGPP), Windows9x/2k (MinGW/MSVC), Linux + + + +How to compile: +--------------- + +DJGPP/MinGW: + Place the Glide3 SDK in the top Mesa directory: + $(MESA)/glide3/include/*.h + $(MESA)/glide3/lib/ + Required headers: + 3dfx.h, g3ext.h, glide.h, glidesys.h, glideutl.h, sst1vid.h + Required libraries: + OS specific + Type: + make -f Makefile.DJ X86=1 FX=1 + or + make -f Makefile.mgw X86=1 FX=1 + Look into the corresponding makefiles for further information. + +Linux: + Place the Glide3 SDK in /usr/local/glide + Type: + make linux-glide + or + make linux-x86-glide + + + +Compilation defines: +-------------------- + +FX_DEBUG + enable driver debug code +FX_TRAP_GLIDE + enable Glide trace code +FX_PACKEDCOLOR + use packed color in vertex structure +FX_TC_NAPALM + map GL_COMPRESSED_RGB[A] to FXT1. This will have effect on Napalm + only (can coexist with FX_TC_NCC, but has higher priority) +FX_TC_NCC + experimental + map GL_COMPRESSED_RGB[A] to NCC. This will have effect on any 3dfx + HW (can coexist with FX_TC_NAPALM, but has lesser priority) +FX_COMPRESS_S3TC_AS_FXT1_HACK + map S3TC to FXT1 +FX_RESCALE_BIG_TEXURES_HACK + fake textures larger than HW can support + (see MESA_FX_MAXLOD environment variable) + + + +Environment variables: +---------------------- + +The following environment variables affect MesaFX. Those that affect Glide +only, are beyond the scope of this section. Entries that don't have a "Value" +field, can have any value whatsoever + ex: set MESA_FX_IGNORE_CMBEXT=y + +"Note" (*) means that the environment variable affects Glide, too; also, if +the var is not found in the environment, it is searched in windoze registry. +"Note" (!) means that the environment variable is not working as expected; +may have undefined effects, might have effects only at Glide level or might +not have any effect whatsoever. Caveat emptor! Those are to be revised soon. + +It is recommended to leave the envvars alone, so that Mesa/Glide will run with +default values. Use them only when you experience crashes or strange behavior. + +FX_GLIDE_NUM_TMU + OS: all + HW: dual-TMU cards (Voodoo2, Avenger, Napalm) + Desc: force single-TMU + Note: (*) + Value: "1" +FX_GLIDE_SWAPPENDINGCOUNT + OS: all + HW: all + Desc: max # of buffers allowed to build up + Note: (*) (!) + Value: "0", "1", "2" or "3" +FX_GLIDE_SWAPINTERVAL + OS: all + HW: all + Desc: number of vertical retraces to wait before swapping + Note: (*) (!) works only at Glide-level? +SSTH3_SLI_AA_CONFIGURATION + OS: all + HW: VSA100-based cards + Desc: SLI/AA setup + Note: (*) (!) works only at Glide-level? + Value: + 1, 2, 4 chip cards + "0" - SLI & AA disable + "1" - SLI disabled, 2 sample AA enabled + 2, 4 chip cards + "2" - 2-way SLI enabled, AA disabled + "3" - 2-way SLI enabled, 2 sample AA enabled + "4" - SLI disabled, 4 sample AA enabled + 4 chip cards + "5" - 4-way SLI enabled, AA disabled + "6" - 4-way SLI enabled, 2 sample AA enabled + "7" - 2-way SLI enabled, 4 sample AA enabled + "8" - SLI disabled, 8 sample AA enabled +SST_DUALHEAD + OS: win32 + HW: ? + Desc: ? + Note: (!) disabled? +MESA_FX_NO_SIGNALS + OS: linux + HW: all + Desc: avoid installing signals + Note: (!) untested! +MESA_FX_INFO + OS: all + HW: all + Desc: verbose to stderr + Value: any; special value "r" to redirect stderr to MESA.LOG +MESA_FX_NOSNAP + OS: all + HW: Voodoo1, Rush, Banshee + Desc: do not snap vertices inside Mesa + Note: to be used with Glide3x that snaps vertices itself +MESA_FX_POINTCAST + OS: all + HW: dual-TMU cards (some Voodoo1, Voodoo2, Avenger, Napalm) + Desc: try to use pointcast palette + Note: may give adverse effects on UMA cards (Avenger, Napalm) +MESA_FX_IGNORE_PALEXT + OS: all + HW: all + Desc: disable 6666 palette +MESA_FX_IGNORE_PIXEXT + OS: all + HW: Napalm + Desc: force 565 16bpp mode (traditional Voodoo, no 32/15bpp) +MESA_FX_IGNORE_TEXFMT + OS: all + HW: Napalm + Desc: disable 32bit textures +MESA_FX_IGNORE_CMBEXT + OS: all + HW: Napalm + Desc: disable Napalm combiners (color/alpha/texture) + Note: this option allows dual-TMU cards perform single-pass + trilinear, but some advanced (multi)texturing modes + won't work (GL_EXT_texture_env_combine) +MESA_FX_IGNORE_MIREXT + OS: all + HW: all + Desc: disable mirror extension +MESA_FX_IGNORE_TEXUMA + OS: all + HW: all + Desc: disable UMA +MESA_FX_IGNORE_TEXUS2 + OS: all + HW: all + Desc: disable Texus2 +MESA_FX_MAXLOD + OS: all + HW: non VSA-100 cards + Desc: enable large texture support using SW rescaling + Value: + "9" - 512x512 textures + "10" - 1024x1024 textures + "11" - 2048x2048 textures +MESA_GLX_FX + OS: linux + HW: Voodoo1, Rush, Voodoo2 + Desc: display mode + Note: (!) experimental: "w" may work in Win32 using non-V1/V2 HW + Value: + "w" - windowed mode + "f" - fullscreen mode + "d" - disable glide driver + + + +Contact: +-------- + +Daniel Borca +Hiroshi Morii + + + +WARNING! The info below this line is outdated (yet some of it useful). WARNING! +******************************************************************************* + + + +Info for Mesa 4.1 +----------------- + +The 3dfx Glide driver in Mesa is disabled by default. Not too many people +use this driver anymore and at some point down the road it will be dropped. + +To use/enable the Glide driver either do this: + +'./configure --with-glide=DIR' Where DIR is the location of Glide, like + /usr/ or /usr/local + +OR + +'make linux-x86-glide' If using the old-style Makefile system. + +The rest of this file hasn't changed since Mesa 3.3. Some of it's out of +date, but some is still valid. + + + +What do you need ? +------------------ + + - A PC with a 3Dfx Voodoo1/2 Graphics or Voodoo Rush based board + (Pure3D, Monster 3D, R3D, Obsidian, Stingray 128/3D, etc.). + The Quantum3D Obsidian3D-2 X-24 requires some special env. setting + under Linux (more information in the "Useful Glide Environment + Variables"); + + - The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine). + The Voodoo2 requires the Glide library 2.51. The Glide 3.1 is not + compatible with the Glide 2.x so it doesn't work with the current + version of the driver; + + - A compiler supported by the Glide library (Micro$oft VC++ (tested), + Watcom (tested), GCC for Linux (tested), etc.); + + - It's nice to have two monitors - one for your normal graphics + card and one for your 3Dfx card. If something goes wrong with + an application using the 3Dfx hardware you can still see your + normal screen in order to recover. + + + +Tested on: +---------- + Windows 95 - David Bucciarelli + Windows NT - Henri Fousse + MS-DOS + Linux - Daryll Strauss, Brian Paul, David Bucciarelli + FreeBSD + BeOS - Duncan Wilcox + MacOS - Fazekas Miklos + + +What is able to do ? +-------------------- + + - It is able accelerate points, lines and polygon with flat + shading, gouraud shading, Z-buffer, texture mapping, blending, fog and + antialiasing (when possible). There is also the support for rendering + in a window with a slow trick for the Voodoo Graphics (available only + for Linux) and at full speed with the Voodoo Rush chipset. + Under Linux is also possible to switch on-the-fly between the fullscreen + and in-window rendering hack. + There is also the support for using more than one Voodoo Graphics in the + some application/PC (you can create one context for each board and use + multiple video outputs for driving monitors, videoprojectors or HMDs). + The driver is able to fallback to pure software rendering when afeature + isn't supported by the Voodoo hardware (however software rendering is + very slow compared to hardware supported rendering) + + + +How to compile: +--------------- + +Linux: +------ + Here are the basic steps for using the 3Dfx hardware with Mesa + on Linux: + + - You'll need the Glide library and headers. Mesa expects: + /usr/local/glide/include/*.h // all the Glide headers + /usr/local/glide/lib/libglide2x.so + + If your Glide libraries and headers are in a different directory + you'll have to modify the Mesa-config and mklib.glide files. + + - Unpack the MesaLib-3.1.tar.gz and MesaDemos-3.1.tar.gz archives; + + - If you're going to use a newer Mesa/Glide driver than v0.27 then + unpack the new driver archive over the Mesa directory. + + - In the Mesa-3.1 directory type "make linux-glide" + + - Compilation _should_ finish without errors; + + - Set your LD_LIBRARY_PATH environment variable so that the + libglide2x.so and Mesa library files can be found. For example: + setenv LD_LIBRARY_PATH "/usr/local/glide/lib:/SOMEDIR/Mesa-3.1/lib" + + - You'll have to run Glide-based programs as root or set the suid + bit on executables; + + - Try a demo: + cd gdemos + su + setenv MESA_GLX_FX f + ./gears (hit ESC to exit) + + - You can find the demos especially designed for the Voodoo driver in + in the Mesa-3.1/3Dfx/demos directory (type "make" in order to compile + everything). + +MacOS: +------ + Check the WEB page at http://valerie.inf.elte.hu/~boga/Mesa.html + +MS Windows: +----------- + + For the MSVC++: + - The glide2x.lib have to be in the default MSVC++ lib directory; + + - The Glide headers have to be in the default MSVC++ include directory; + + - You must have the vcvars32.bat script in your PATH; + + - Go to the directory Mesa-3.1 and run the mesafx.bat; + + - The script will compile everything (Mesa-3.1/lib/OpenGL32.{lib,dll}, + Mesa-3.1/lib/GLU32.{lib,dll}, Mesa-3.1/lib/GLUT32.{lib,dll} and + Voodoo demos); + + - At the end, you will be in the Mesa-3.1/3Dfx/demos directory; + + - Try some demo (fire.exe, teapot.exe, etc.) in order to check if + everything is OK (you can use Alt-Tab or Ctrl-F9 to switch between + the Voodoo screen and the windows desktop); + + - Remember to copy the Mesa OpenGL32.dll, GLU32.dll and GLUT32.dll in the + some directory were you run your Mesa based applications. + + - I think that you can easy change the Makefile.fx files in order + to work with other kind of compilers; + + - To discover how open the 3Dfx screen, read the sources under + the Mesa-3.1/3Dfx/demos directory. You can use the GLUT library or + the Diego Picciani's wgl emulator. + + NOTE: the MSVC++ 5.0 optimizer is really buggy. Also if you install the + SP3, you could have some problem (you can disable optimization in order + solve these kind of problems). + + +Doing more with Mesa & Linux Glide: +----------------------------------- + + The MESA_GLX_FX environment variable can be used to coax most + GLX-based programs into using Glide (and the __GLUT library + is GLX-based__). + + Full-screen 3Dfx rendering: + --------------------------- + + 1. Set the MESA_GLX_FX variable to "fullscreen": + + ksh: + export MESA_GLX_FX = "fullscreen" + csh: + setenv MESA_GLX_FX fullscreen + + 2. As root, run a GLX-based program (any GLUT demo on Linux). + + 3. Be careful: once the 3Dfx screen appears you won't be able + to see the GLUT windows on your X display. This can make using + the mouse tricky! One solution is to hook up your 3Dfx card to + a second monitor. If you can do this then set these env vars + first: + + setenv SST_VGA_PASS 1 + setenv SST_NOSHUTDOWN + + or for the Voodoo2: + + setenv SSTV2_VGA_PASS 1 + setenv SSTV2_NOSHUTDOWN + + Rendering into an X window with the help of the Voodoo hardware: + ---------------------------------------------------------------- + + 1. Start your X server in 16 bpp mode (XFree86: startx -- -bpp 16) + in order to have the best performance and the best visual + quality. However you can use any visual depth supported by X. + + 2. Set the following environment variables: + export MESA_GLX_FX="window" # to enable window rendering + export SST_VGA_PASS=1 # to stop video signal switching + export SST_NOSHUTDOWN=1 # to stop video signal switching + OR + setenv MESA_GLX_FX window + setenv SST_VGA_PASS 1 + setenv SST_NOSHUTDOWN 1 + + (the Voodoo2 requires to use "SSTV2_" instead "SST_"). + + 3. As root, try running a GLX-based program + + How does it work? We use the 3Dfx hardware to do rendering then + copy the image from the 3Dfx frame buffer into an X window when + the SwapBuffers() function is called. The problem with this + idea is it's slow. The image must be copied from the 3Dfx frame + buffer to main memory then copied into the X window (and when the X + visual depth doesn't match the Voodoo framebufffer bit per pixel, it + is required also a pixel format translation). + + NOTE: the in-window rendering feature only works with double-buffering. + + + On the fly switching between in window rendering and full screen rendering + -------------------------------------------------------------------------- + + The Mesa 2.6 has introduced the capability of switching + on-the-fly between the fullscreen/fullspeed rendering and the in-window + hack and vice versa. The on-the-fly switching requires a direct support + by the application but it is really easy to add. You have to start + your X server in 16 bpp mode and to add the following lines to your + application: + + #if defined(FX) && define(XMESA) + #include + + static int fullscreen=1; + #endif + + ... + + /* In the GLUT keyboard event callback */ + + #if defined(FX) && !define(WIN32) + case ' ': + fullscreen=(!fullscreen); + XMesaSetFXmode(fullscreen ? XMESA_FX_FULLSCREEN : XMESA_FX_WINDOW); + break; + #endif + ... + + See the 3Dfx/demos/tunnel.c program + for an example. You have to set the -DXMESA flag in the Makefile's COPTS + to enable it. + + Rendering into an X window with the X11 software driver: + -------------------------------------------------------- + + Set the MESA_GLX_FX variable to "disable" your GLX-based program will use + the X11 software driver (the 3Dfx hardware isn't used at all). + + + +Useful Glide Environment Variables: +----------------------------------- + + - To disable the 3Dfx logo, set the FX_GLIDE_NO_SPLASH variable. + + - To disable video signal switching: + setenv SST_VGA_PASS 1 + setenv SST_NOSHUTDOWN + or for the Voodoo2: + setenv SSTV2_VGA_PASS 1 + setenv SSTV2_NOSHUTDOWN + + - To set the default screen refresh rate: + setenv SST_SCREENREFRESH=75 + + the supported values are 60, 70, 72, 75, 80, 85, 90, 100, 120. + + - To force the Mesa library to swap buffers as fast as possible, + without any vertical blanking synchronization (useful for benchmarks): + setenv FX_GLIDE_SWAPINTERVAL 0 + setenv SST_SWAP_EN_WAIT_ON_VIDSYNC 0 + + - You can slight improve the performances of your Voodoo1 board with + the following env. var.: + setenv SST_FASTMEM 1 + setenv SST_PCIRD 1 + setenv SST_GRXCLK 57 + + (don't use this setting with the Quantum3D 100SB or with any other + SLI configuration: it will hang everything !). + The following setting can be used with the Voodoo2: + setenv SSTV2_FASTMEM_RAS_READS=1 + setenv SSTV2_FASTPCIRD=1 + setenv SSTV2_GRXCLK=95 + + - The Quantum3D Obsidian3D-2 X-24 requires some special env. setting + in order to work under Linux: + + export SSTV2_FT_CLKDEL=5 + export SSTV2_TF0_CLKDEL=7 + export SSTV2_TF1_CLKDEL=7 + export SSTV2_TF2_CLKDEL=7 + export SSTV2_SLIM_VIN_CLKDEL=3 + export SSTV2_SLIM_VOUT_CLKDEL=2 + export SSTV2_SLIS_VIN_CLKDEL=3 + export SSTV2_SLIS_VOUT_CLKDEL=2 + + (Thanks to Phil Ross for this trick). + + + + +The Mesa/Voodoo Environment Variables: +-------------------------------------- + + - Only for Windows/Voodoo Rush users, if you define the + env. var. MESA_WGL_FX: + export MESA_WGL_FX=fullscreen + you will get fullscreen rendering; + + - Only for Windows/Voodoo Rush users, if you define the + env. var. MESA_WGL_FX: + export MESA_WGL_FX=window + you will get window rendering (default value); + + - Only for Linux users, you can find more informations about + the env. var. MESA_GLX_FX in the "Doing more with Mesa & Linux Glide" + section; + + - If you define the env. var. MESA_FX_SWAP_PENDING: + export MESA_FX_SWAP_PENDING=4 + you will able to set the maximum number of swapbuffers + commands in the Voodoo FIFO after a swapbuffer (default value: 2); + + - If you define the env. var. MESA_FX_INFO: + export MESA_FX_INFO=1 + you will get some useful statistic. + + - If you define the env. var. MESA_FX_NO_SIGNALS: + export MESA_FX_NO_SIGNALS=1 + Mesa/FX will not install atexit() or signal() handlers. + + + +Know BUGS and Problems: +----------------------- + + - fog doesn't work in the right way when using the glDepthRange() function; + + - Maximum texture size: 256x256 (this is an hardware limit); + + - Texture border aren't yet supported; + + - A GL_BLEND in a glTexEnv() is not supported (it is an hardware limit); + + - Use the glBindTexture extension (standard in OpenGL 1.1) for texture + mapping (the old way: glTexImage inside a display list, download + the texture map each time that you call the display list !!!); + + - Stencil buffer and Accumulation buffer are emulated in software (they are not + directly supported by the Hardware); + + - Color index mode not implemented (this is an hardware limit); + + - Thre is an know bug in the Linux Glide library so the in-window-rendering hack + and any other operations that requires to read the Voodoo frame buffer + (like the accumulation buffer support) doesn't work on Voodoo SLI cards. + + - The driver switch to pure software (_slow_) rendering when: + + - Stencil enabled; + - Using the Accumulation buffer; + - Blend enabled and blend equation != GL_FUNC_ADD_EXT; + - Color logic operation enabled and color logic operation != GL_COPY; + - Using GL_SEPARATE_SPECULAR_COLOR; + - The four values of glColorMask() aren't the some; + - Texture 1D or 3D enabled; + - Texture function is GL_BLEND; + - Using the Multitexture extension with Voodoo cards with only one TMU; + - Using the Multitexture extension with Voodoo cards with more than + one TMU, and texture function isn't GL_MODULATE; + - Point size is != 1.0 or point params vector != (1.0,0.0,0.0); + - Line width != 1.0 or using stipple lines. + - Using polygon offset or stipple polygons; + + NOTE: this is list is not yet complete. + + +Hints and Special Features: +--------------------------- + + - Under Linux and with a Voodoo Graphics board, you can use + XMesaSetFXmode(XMESA_FX_FULLSCREEN or XMESA_FX_WINDOW) in order to + switch on the fly between fullscreen rendering and the in-window-rendering + hack. + + - The driver is able to use all the texture memory available: 2/4MB on + Voodoo1 boards and 8MB (!) on high-end Voodoo1 and Voodoo2 boards. + + - Trilinear filtering is fully supported on Voodoo boards with two TMUs + (high-end Voodoo1 boards and Voodoo2 boards). When only one TMU is + available the driver fallback to bilinear filter also if you ask + for trilinear filtering. + + - The Voodoo driver support multiple Voodoo Graphics boards in the + some PC. Using this feature, you can write applications that use + multiple monitors, videoprojectors or HMDs for the output. See + Mesa-3.1/3Dfx/demos/tunnel2.c for an example of how setup one + context for each board. + + - The v0.19 introduces a new powerful texture memory manager: the + texture memory is used as a cache of the set of all defined texture + maps. You can now define several MBs of texture maps also with a 2MB + of texture memory (the texture memory manager will do automatically + all the swap out/swap in + texture memory work). The new texture memory manager has also + solved a lot of other bugs/no specs compliance/problems + related to the texture memory usage. + + - Use triangles and quads strip: they are a LOT faster than sparse + triangles and quads. + + - The Voodoo driver supports the GL_EXT_paletted_texture. it works + only with GL_COLOR_INDEX8_EXT, GL_RGBA palettes and the alpha value + is ignored because this is a limitation of the the current Glide + version and of the Voodoo hardware. See Mesa-3.1/3Dfx/demos/paltex.c for + a demo of this extension. + + - The Voodoo driver directly supports 3Dfx Global Palette extension. + It was written for GLQuake and I think that it isn't a good idea + to use this extension for any other purpose (it is a trick). See + Mesa-3.1/3Dfx/demos/glbpaltex.c for a demo of this extension. + + - The Voodoo driver chooses the screen resolution according to the + requested window size. If you open a 640x480 window, you will get + a 640x480 screen resolution, if you open a 800x600 window, you + will get a 800x600 screen resolution, etc. + Most GLUT demos support the '-geometry' option, so you can choose + the screen resolution: 'tunnel -geometry 800x600'. + Clearly, you Voodoo board must have enough framebuffer RAM (otherwise + the window creation will fail). + + - The glGetString(GL_RENDERER) returns more information + about the hardware configuration: "Mesa Glide + CARD/ FB/ + TM/ TMU/" + where: CARD is the card used for the current context, + FB is the number of MB for the framebuffer, + TM is the number of MB for the texture memory, + TMU is the number of TMU. You can try to run + Mesa/demos/glinfo in order to have an example of the output. + +Did you find a lot BUGs and problems ? Good, send me an email. + + + +FAQ: +---- + +For a complete FAQ check the Bernd Kreimeier's Linux 3Dfx HOWTO +available at http://www.gamers.org/dEngine/xf3D (it includes also +a lot of informations not strictly related to Linux, so it can be +useful also if you don't use Linux) + +1. What is 3Dfx? + +3Dfx Interactive, Inc. is the company which builds the VooDoo 3-D graphics +chipset (and others) used in popular PC cards such as the Diamond Monster 3D +and the Orchid Righteous 3D (more informations at http://www.3dfx.com). + + +2. What is Glide? + +Glide is a "thin" programming interface for the 3Dfx hardware. It was +originally written for Windows/Intel but has been ported to Linux/Intel +by Daryll Strauss. + +3Dfx, Inc. should be applauded for allowing the Linux version of Glide +to be written. + +You can directly program with the Glide library if you wish. You can +obtain Glide from the "Developer" section of the 3Dfx website: www.3dfx.com +There's a Linux/Glide newsgroup at news://news.3dfx.com/3dfx.glide.linux + + +3. What is fxmesa? + +"fxmesa" is the name of the Mesa device driver for the 3Dfx Glide library. +It was written by David Bucciarelli and others. It works on both Linux +and Windows. Basically, it allows you to write and run OpenGL-style programs +on the 3Dfx hardware. + + +4. What is GLQuake? + +Quake is a very popular game from id software, Inc. See www.idsoftware.com +GLQuake is a version of Quake written for OpenGL. There is now a Linux +version of GLQuake with works with the Mesa/3Dfx/Glide combo. + +Here's what you need to run GLQuake on Linux: + PC with 100MHz Pentium or better + a 3Dfx-based card + Mesa 3.1 libraries: libMesaGL.so libMesaGLU.so + Glide 2.4 libraries: libglide2x.so libtexus.so + GLQuake for Linux. + +Also, the windows version of GLQuake works fine with the Mesa OpenGL32.dll, +you have only to copy the Mesa-3.1/lib/OpenGL32.dll in the GLQuake directory +in order to test 'MesaQuake'. + + +5. What is GLUT? + +GLUT is Mark Kilgard's OpenGL Utility Toolkit. It provides an API for +writing portable OpenGL programs with support for multiple windows, pop- +up menus, event handling, etc. + +Check the Mark's home page for more informations (http://reality.sgi.com/mjk_asd). + +Every OpenGL programmer should check out GLUT. + +GLUT on Linux uses GLX. + + +6. What is GLX? + +GLX is the OpenGL extension to the X Window System. I defines both a +programming API (glX*() functions) and a network protocol. Mesa implements +an emulation of GLX on Linux. A real GLX implementation would requires +hooks into the X server. The 3Dfx hardware can be used with GLX-based +programs via the MESA_GLX_FX environment variable. + + +7. Is the Voodoo driver able to use the 4Mb texture memory of +the Pure3D boards ? + +Yes, the Voodoo driver v0.20 includes the support for Voodoo +Graphics boards with more than 2Mb of texture memory. + + +8. Do the Voodoo driver support the Voodoo Rush under Windows ? + +Yes, Diego Picciani has developed the support for the Voodoo +Rush but David Bucciarelli has a Pure3D and a Monster3D and Brian Paul +has a Monster3D, so the new versions of the Mesa/Voodoo sometime are +not tested with the Voodoo Rush. + + +9. Do the Voodoo driver support the Voodoo Rush under Linux ? + +No because the Linux Glide doesn't (yet) support the Voodoo Rush. + + +10. Can I sell my Mesa/Voodoo based software and include +a binary copy of the Mesa in order to make the software +working out of the box ? + +Yes. + + +11. Which is the best make target for compiling the Mesa for +Linux GLQuake ('make linux-glide', 'make linux-386-glide', etc.) ? + +'make linux-386-opt-glide' for Voodoo1 and 'make linux-386-opt-V2-glide' +for Voodoo2 boards because it doesn't include the '-fPIC' +option (4-5% faster). + + +12. Can I use a Mesa compiled with a 'make linux-386-opt-V2-glide' +for my applications/programs/demos ? + +Yes, there is only one constrain: you can't run two Mesa applications +at the some time. This isn't a big issue with the today Voodoo Graphics. + + +Thanks to: +---------- + +Henri Fousse (he has written several parts of the v0.15 and the old GLUT + emulator for Win); + +Diego Picciani (he has developed all the Voodoo Rush support and the wgl + emulator); + +Daryll Strauss (for the Linux Glide and the first Linux support); + +Brian Paul (of course); + +Dave 'Zoid' Kirsch (for the Linux GLQuake and Linux Quake2test/Q2 ports) + +Bernd Kreimeier (for the Linux 3Dfx HOWTO and for pushing companies to offer + a better Linux support) + +3Dfx and Quantum3D (for actively supporting Linux) + +The most update places where find Mesa VooDoo driver related informations are +the Mesa mailing list and my driver WEB page +(http://www-hmw.caribel.pisa.it/fxmesa/index.shtml) + + +David Bucciarelli (davibu@tin.it) + +Humanware s.r.l. +Via XXIV Maggio 62 +Pisa, Italy +Tel./Fax +39-50-554108 +email: info.hmw@plus.it +www: www-hmw.caribel.pisa.it diff --git a/docs/README.AMIWIN b/docs/README.AMIWIN new file mode 100644 index 0000000..47cf696 --- /dev/null +++ b/docs/README.AMIWIN @@ -0,0 +1,181 @@ +AMIGA AMIWIN PORT of MESA: THE OPENGL SOFTWARE EMULATION +======================================================== +Port by Victor Ng-Thow-Hing (victorng@dgp.toronto.edu) +Original Author (Brian Paul (brianp@ssec.wisc.edu) + +Dec.1 , 1995: Port of release Mesa 1.2.5 + - Modifications made to minimize changes to Mesa distribution. + +Nov.25, 1995: Port of release Mesa 1.2.4 + + +HISTORY +======= +As a 3D graphics progammer, I was increasingly frustrated to see OpenGL +appearing on so many platforms EXCEPT the Amiga. Up to now, the task +of porting OpenGL directly from native Amiga drawing routines seemed like +a daunting task. However, two important events made this port possible. + +First of all, Brian Paul wrote Mesa, the OpenGL software emulator that +can be found on many platforms - except the Amiga and Atari (who cares +about the latter!). This was pretty ironic considering that Mesa was +originally prototyped on an Amiga! The second great event was when +Holger Kruse developed AmiWin, the X11R6 server for the Amiga (definitely +register for this great piece of software) and released a development kit +so one could compile X programs with SAS/C. + +Since Mesa had X routines as its primitive drawing operations, this made +a marriage of Mesa and Amiwin feasible. I copied over the sources from +an ftp site, played with the code, wrote some Smakefiles, and voila, +I had OpenGL programs displaying on my Amiga. + +Although the speed is nothing to be impressed about, this port can be +potentially useful to those who want to quickly test their code in +wireframe or perhaps learn more about programming with the OpenGL API. + +I hope Amiga developers will continue to write excellent software for +their machine, especially more X clients for Amiwin. If you have any +solutions so some of my problems in the porting notes, please send me +some email! + +See you around, +Vic. + +HOW TO CREATE THE LIBRARIES AND SAMPLE CODE +=========================================== + +Just run the shell script mklib.amiwin in the mesa directory. This will +make all the libraries and copy them into the mesa/lib directory. If you +don't want to compile everything, just go to the desired directory and +type smake in that directory. + +Change any of the variables in the smakefiles as necessary. You will REQUIRE +the Amiwin development kit to compile these libraries since you need X11.LIB +and the shareable X libraries. Some examples require the AmiTCP4.0 +net.lib static link library and related header files for unix related +header files and functions like sleep(). + +HOW TO USE THE MESA LIBRARIES +============================= + +Study the Smakefiles in the demos, samples and book directories for the +proper SAS/C options and linkable libraries to use. Basically aux calls +require Mesaaux.LIB, gl calls require MesaGL.LIB, glu calls MesaGLU.LIB, +tk calls Mesatk.LIB. There is a preliminary port of MesaGLUT.LIB toolkit +available in the lib directory with the other Mesa libraries. However, +it seems to cause crashes on some of the sample code. Someone else may want +to attempt a more stable port. + +PORTING NOTES TO AMIWIN +======================= + +My strategy of porting was to leave as much of the code untouched as +possible. I surrounded any amiga specific changes with +#ifdef AMIWIN ... #endif or #ifndef AMIWIN ... #endif preprocessor +symbols. The code was ported on an Amiga 2000, with Fusion 40 accelerator +and a Picasso II graphics card. The SAS/C 6.56 compiler was used, with +the AmiWin 2.16 X development kit. + +All compilations were done for a 68040 CPU with 68882 math coprocessor for +maximum speed. Please edit the smakefile for other compilers. +I wrote smakefiles for the directories I ported. I omitted the Windows +and Widgets directories. The former is for MS Windows and the latter +requires Motif, which is not easily available for the Amiga. + +Here are the changes I did per directory: + +* mesa +Nov. 25, 1995 v 1.2.4 + - added a mklib.amiwin shell script that will make all the libraries and + sample code for Mesa + - created this readme file: readme.AMIGA + +* mesa/include +Dec. 1, 1995 v 1.2.5 + - added the following to GL/xmesa.h + #ifdef AMIWIN + #include + extern struct Library *XLibBase; + #endif +NET CHANGE: xmesa.h + +* mesa/src +Nov. 25, 1995 v 1.2.4 + - added the necessary pragma calls for X functions to the following: + xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, glx.c + This prevents undefined symbols errors during the linking phase for + X library calls + - created smakefile +Dec. 1, 1995 v 1.2.5 + - removed AMIWIN includes from xmesa1.c, xmesa2.c, xmesa3.c, xfonts.c, + glx.c since they are now defined in include/GL/xmesa.h +NET CHANGE: smakefile + +* mesa/src-tk +Nov. 25, 1995 v 1.2.4 + - added the necessary pragma calls for X functions to the following: + private.h + - created smakefile +Dec. 1, 1995 v 1.2.5 + - removed AMIWIN includes from private.h since it is now defined in + include/GL/xmesa.h +NET CHANGE: smakefile + +* mesa/src-glu +Nov. 25, 1995 v 1.2.4 + - created smakefile +NET CHANGE: smakefile + +* mesa/src-aux +Nov. 25, 1995 v 1.2.4 + - added the necessary pragma calls for X functions to the following: + glaux.c + - created smakefile +NET CHANGE: glaux.c, smakefile + +* mesa/demos +Nov. 25, 1995 v 1.2.4 + - added the necessary pragma calls for X functions to the following: + xdemo.c, glxdemo.c, offset.c + - created smakefile + - put #ifndef AMIWIN ... #endif around sleep() calls in xdemo.c since + they are not part of AmigaDOS. +Dec. 1, 1995 v 1.2.5 + - removed AMIWIN defines from xdemo.c, glxdemo.c, offset.c since + already defined in include/GL/xmesa.h + - modified Smakefile to include header and includes from the AmiTCP4.0 + net.lib linkable library to provide unix-compatible sys/time.h and + the sleep() function + - removed AMIWIN defines in xdemo.c since sleep() now defined +NET CHANGE: smakefile + +* mesa/samples +Nov. 25, 1995 v 1.2.4 + - added the necessary pragma calls for X functions to the following: + oglinfo.c + - created smakefile + - put #ifndef AMIWIN ... #endif around sleep() in blendxor.c + - removed olympic from smakefile targets since not defined +Dec. 1, 1995 v 1.2.5 + - removed AMIWIN defines from oglinfo.c, since already defined in + include/GL/xmesa.h + - modified Smakefile to include header and includes from the AmiTCP4.0 + net.lib linkable library to provide unix-compatible sys/time.h and + the sleep() function + - removed AMIWIN defines in blendxor.c for sleep() + - added AMIWIN defines around _MACHTEN_ in olympic.c since xrandom() + functions are not defined in any libraries + - added olympic back into the Smakefile targets +NET CHANGE: smakefile, olympic.c + +* mesa/book +Nov. 25, 1995 v 1.2.4 +- created smakefile +- removed accpersp and dof from smakefile targets since the SAS/C compile seems to + confuse the near,far variables with near/far memory models. +NET CHANGE: smakefile + +* mesa/windows +Dec. 1, 1995 v 1.2.5 +- Removed directory to save space since this is only needed for Windows based + machines. diff --git a/docs/README.BEOS b/docs/README.BEOS new file mode 100644 index 0000000..0a10b00 --- /dev/null +++ b/docs/README.BEOS @@ -0,0 +1,134 @@ + + Mesa / BeOS Information + + + +* Introduction + +Brian Paul added in Mesa 3.1 a driver for BeOS R4.5 operating system. +This driver implements a clone of the BGLView class. This class, +derived from BView, allows OpenGL rendering into any BeOS window. His +driver was updated in Mesa 4.1 and again in version 6.1 by Philippe +Houdoin, who's maintaining this driver since. + +Any application which uses the BGLView should be able to use Mesa +instead of Be's OpenGL without changing any code. + +Since Be's OpenGL implementation (as of R5) is basically just the +SGI sample implementation, it's pretty slow. You'll see that Mesa +is considerably faster. + + +* Source Code + +The source code for the driver is in src/mesa/drivers/beos/ directory. +It's not 100% finished at this time but many GLUT-based demos are +working. No optimizations have been made at this time. + + +* Compiling + +Requirements: + - gcc version 2.95.3 for BeOS + You can find it here: http://www.bebits.com/app/2157 + +To build Mesa-powered BeOS libGL.so version, open an Terminal window, +move to Mesa root folder and type this command: + +$ make beos + +Note that the "beos" argument is only needed the first time to setup build config. +Next times, typing "make" will be enough. + +When it finishes the Mesa based libGL.so library for +BeOS will be in the lib/ directory, along libglut.so library. +Several demo/test programs should have been build too under progs/* folders. +If it stop when building one of the progs/* programs, you may want to ignore it +and force make to move on next target by adding the -k make option: + +$ cd progs +$ make -k + +To install it as Be's default libGL.so replacement, put it in your +/boot/home/config/lib/ directory. All your GL/GLUT apps will use +the Mesa based then. + +By default, it build a non-debug version library. +The x86 (MMX, SSE and 3DNOW) optimizations are also supported for x86 target. +For PowerPC BeOS flavor, sorry, Mesa don't have ppc (Altivec) optimizations +yet. + +To build a DEBUG version, type instead this : + +$ DEBUG=1 make + + +* Example Programs + +Look under progs/beos/ for some BGLView-based programs. +You should find under progs/samples and progs/redbook directories GLUT-based programs too. +They all should have been compiled along with the Mesa library. + + +* GLUT + +A beta version of GLUT 3.7 port for BeOS, made by Jake Hamby, can be found at +http://anobject.com/jehamby/Code/Glut-3.7-x86.zip. +This is the version currently included in Mesa source code, and +build in lib/libglut.so. + +A previous 3.5 version of this GLUT BeOS port used to be available at +http://home.beoscentral.com/jehamby/Glut-3.5-x86.zip. + +They're special versions of GLUT for the BeOS platform. I don't +believe Mark Kilgard's normal GLUT distribution includes BeOS +support. + + +* Special Features + +Mesa's implementation of the BGLView class has an extra member +function: CopySubBufferMESA(). It basically works like SwapBuffers() +but it only copies a sub region from the back buffer to the front +buffer. This is a useful optimization for some applications. +If you use this method in your code be sure that you check at runtime +that you're actually using Mesa (with glGetString) so you don't +cause a fatal error when running with Be's OpenGL. + + +* Work Left To Do + +- BDirectWindow single buffering support is not implemented yet. +- Color index mode is not implemented yet. +- Reading pixels from the front buffer not implemented yet. +- There is also a BGLScreen class in BeOS for full-screen OpenGL rendering. + This should also be implemented for Mesa. +- Multiple renderers add-ons support, first step toward hardware acceleration + support. + +* Other contributors to this BeOS port + +Jake Hamby jhamby anobject com +Marcin Konicki ahwayakchih neoni net +Francois Revol revol free fr + + +* Older BeOS Driver + +Mesa 2.6 had an earlier BeOS driver. It was based on Mesa's Off-screen +rendering interface, not BGLView. If you're interested in the older +driver you should get Mesa 2.6. + + +* BeOS and Glide + +Mesa 3.0 supported the 3Dfx/Glide library on Beos. Download Mesa 3.0 +if interested. Ideally, the 3Dfx/Glide support should be updated to +work with the new Mesa 3.1 BGLView implementation. + +The Glide library hasn't been updated for BeOS R4 and newer, to my knowledge, +as of February, 1999. + + +---------------------------------------------------------------------- +$Id: README.BEOS,v 1.11 2004/08/24 08:31:57 phoudoin Exp $ diff --git a/docs/README.CYGWIN b/docs/README.CYGWIN new file mode 100644 index 0000000..58d5af3 --- /dev/null +++ b/docs/README.CYGWIN @@ -0,0 +1,256 @@ + + Mesa Cygwin/X11 Information + + +WARNING +======= + +If you installed X11 (packages xorg-x11-devel and xorg-x11-bin-dlls ) with the +latest setup.exe from Cygwin the GL (Mesa) libraries and include are already +installed in /usr/X11R6. + +The following will explain how to "replace" them. + +Installation +============ + +How to compile Mesa on Cygwin/X11 systems: + +1. Shared libs: + type 'make cygwin-sl'. + + When finished, the Mesa DLL will be in the Mesa-x.y/lib/ and + Mesa-x.y/bin directories. + + +2. Static libs: + type 'make cygwin-static'. + When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory. + +Header and library files: + After you've compiled Mesa and tried the demos I recommend the following + procedure for "installing" Mesa. + + Copy the Mesa include/GL directory to /usr/X11R6/include: + cp -a include/GL /usr/X11R6/include + + Copy the Mesa library files to /usr/X11R6/lib: + cp -a lib/* /usr/X11R6ocal/lib + + Copy the Mesa bin files (used by the DLL stuff) to /usr/X11R6/bin: + cp -a lib/cyg* /usr/X11R6/bin + +Xt/Motif widgets: + If you want to use Mesa or OpenGL in your Xt/Motif program you can build + the widgets found in either the widgets-mesa or widgets-sgi directories. + The former were written for Mesa and the later are the original SGI + widgets. Look in those directories for more information. + For the Motif widgets you must have downloaded the lesstif package. + + +Using the library +================= + +Configuration options: + The file src/mesa/main/config.h has many parameters which you can adjust + such as maximum number of lights, clipping planes, maximum texture size, + etc. In particular, you may want to change DEPTH_BITS from 16 to 32 + if a 16-bit depth buffer isn't precise enough for your application. + + +Shared libraries: + If you compile shared libraries (Win32 DLLS) you may have to set an + environment variable to specify where the Mesa libraries are located. + Set the PATH variable to include /your-dir/Mesa-2.6/bin. + Otherwise, when you try to run a demo it may fail with a message saying + that one or more DLL couldn't be found. + + +Xt/Motif Widgets: + Two versions of the Xt/Motif OpenGL drawing area widgets are included: + + widgets-sgi/ SGI's stock widgets + widgets-mesa/ Mesa-tuned widgets + + Look in those directories for details + + +Togl: + Togl is an OpenGL/Mesa widget for Tcl/Tk. + See http://togl.sourceforge.net for more information. + + + +X Display Modes: + Mesa supports RGB(A) rendering into almost any X visual type and depth. + + The glXChooseVisual function tries its best to pick an appropriate visual + for the given attribute list. However, if this doesn't suit your needs + you can force Mesa to use any X visual you want (any supported by your + X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL + environment variables. When an RGB visual is requested, glXChooseVisual + will first look if the MESA_RGB_VISUAL variable is defined. If so, it + will try to use the specified visual. Similarly, when a color index + visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL + variable. + + The format of accepted values is: + Here are some examples: + + using the C-shell: + % setenv MESA_RGB_VISUAL "TrueColor 8" // 8-bit TrueColor + % setenv MESA_CI_VISUAL "PseudoColor 12" // 12-bit PseudoColor + % setenv MESA_RGB_VISUAL "PseudoColor 8" // 8-bit PseudoColor + + using the KornShell: + $ export MESA_RGB_VISUAL="TrueColor 8" + $ export MESA_CI_VISUAL="PseudoColor 12" + $ export MESA_RGB_VISUAL="PseudoColor 8" + + +Double buffering: + Mesa can use either an X Pixmap or XImage as the backbuffer when in + double buffer mode. Using GLX, the default is to use an XImage. The + MESA_BACK_BUFFER environment variable can override this. The valid + values for MESA_BACK_BUFFER are: Pixmap and XImage (only the first + letter is checked, case doesn't matter). + + A pixmap is faster when drawing simple lines and polygons while an + XImage is faster when Mesa has to do pixel-by-pixel rendering. If you + need depth buffering the XImage will almost surely be faster. Exper- + iment with the MESA_BACK_BUFFER variable to see which is faster for + your application. + + +Colormaps: + When using Mesa directly or with GLX, it's up to the application writer + to create a window with an appropriate colormap. The aux, tk, and GLUT + toolkits try to minimize colormap "flashing" by sharing colormaps when + possible. Specifically, if the visual and depth of the window matches + that of the root window, the root window's colormap will be shared by + the Mesa window. Otherwise, a new, private colormap will be allocated. + + When sharing the root colormap, Mesa may be unable to allocate the colors + it needs, resulting in poor color quality. This can happen when a + large number of colorcells in the root colormap are already allocated. + To prevent colormap sharing in aux, tk and GLUT, define the environment + variable MESA_PRIVATE_CMAP. The value isn't significant. + + +Gamma correction: + To compensate for the nonlinear relationship between pixel values + and displayed intensities, there is a gamma correction feature in + Mesa. Some systems, such as Silicon Graphics, support gamma + correction in hardware (man gamma) so you won't need to use Mesa's + gamma facility. Other systems, however, may need gamma adjustment + to produce images which look correct. If in the past you thought + Mesa's images were too dim, read on. + + Gamma correction is controlled with the MESA_GAMMA environment + variable. Its value is of the form "Gr Gg Gb" or just "G" where + Gr is the red gamma value, Gg is the green gamma value, Gb is the + blue gamma value and G is one gamma value to use for all three + channels. Each value is a positive real number typically in the + range 1.0 to 2.5. The defaults are all 1.0, effectively disabling + gamma correction. Examples using csh: + + % setenv MESA_GAMMA "2.3 2.2 2.4" // separate R,G,B values + % setenv MESA_GAMMA "2.0" // same gamma for R,G,B + + The demos/gamma.c program may help you to determine reasonable gamma + value for your display. With correct gamma values, the color intensities + displayed in the top row (drawn by dithering) should nearly match those + in the bottom row (drawn as grays). + + Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well + on HP displays using the HP-ColorRecovery technology. + + Mesa implements gamma correction with a lookup table which translates + a "linear" pixel value to a gamma-corrected pixel value. There is a + small performance penalty. Gamma correction only works in RGB mode. + Also be aware that pixel values read back from the frame buffer will + not be "un-corrected" so glReadPixels may not return the same data + drawn with glDrawPixels. + + For more information about gamma correction see: + http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html + + +Overlay Planes + + Overlay planes in the frame buffer are supported by Mesa but require + hardware and X server support. To determine if your X server has + overlay support you can test for the SERVER_OVERLAY_VISUALS property: + + xprop -root | grep SERVER_OVERLAY_VISUALS + + +HPCR glClear(GL_COLOR_BUFFER_BIT) dithering + + If you set the MESA_HPCR_CLEAR environment variable then dithering + will be used when clearing the color buffer. This is only applicable + to HP systems with the HPCR (Color Recovery) system. + + +Extensions +========== + There are three Mesa-specific GLX extensions at this time. + + GLX_MESA_pixmap_colormap + + This extension adds the GLX function: + + GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual, + Pixmap pixmap, Colormap cmap ) + + It is an alternative to the standard glXCreateGLXPixmap() function. + Since Mesa supports RGB rendering into any X visual, not just True- + Color or DirectColor, Mesa needs colormap information to convert RGB + values into pixel values. An X window carries this information but a + pixmap does not. This function associates a colormap to a GLX pixmap. + See the xdemos/glxpixmap.c file for an example of how to use this + extension. + + GLX_MESA_release_buffers + + Mesa associates a set of ancillary (depth, accumulation, stencil and + alpha) buffers with each X window it draws into. These ancillary + buffers are allocated for each X window the first time the X window + is passed to glXMakeCurrent(). Mesa, however, can't detect when an + X window has been destroyed in order to free the ancillary buffers. + + The best it can do is to check for recently destroyed windows whenever + the client calls the glXCreateContext() or glXDestroyContext() + functions. This may not be sufficient in all situations though. + + The GLX_MESA_release_buffers extension allows a client to explicitly + deallocate the ancillary buffers by calling glxReleaseBuffersMESA() + just before an X window is destroyed. For example: + + #ifdef GLX_MESA_release_buffers + glXReleaseBuffersMESA( dpy, window ); + #endif + XDestroyWindow( dpy, window ); + + This extension is new in Mesa 2.0. + + GLX_MESA_copy_sub_buffer + + This extension adds the glXCopySubBufferMESA() function. It works + like glXSwapBuffers() but only copies a sub-region of the window + instead of the whole window. + + This extension is new in Mesa version 2.6 + + + +Summary of X-related environment variables: + MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only) + MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only) + MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only) + MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only) + MESA_GAMMA - gamma correction coefficients (X only) + + +---------------------------------------------------------------------- +README.CYGWIN - lassauge April 2004 - based on README.X11 diff --git a/docs/README.D3D b/docs/README.D3D new file mode 100644 index 0000000..b41fcb6 --- /dev/null +++ b/docs/README.D3D @@ -0,0 +1,124 @@ + + DirectX 6 Driver for Mesa 3.0 + + +This software is distributed under the terms of the GNU Library +General Public License, see the LICENSE file for details. + + + +What do you need ? +------------------ + + - A PC with a DirectX 6 video driver installed. + + - Mesa 3.0 + + - The 3Dfx Glide library 2.3 or later for your OS (the 2.4 works fine). + The Voodoo2 requires the Glide library 2.51. The Glide 3.0 is not + compatible with the Glide 2.x so it doesn't work with the current + version of the driver; + + - Visual C++ 5.0 is only compiler test but others should be ok with + changes to the makefiles (CFLAGS/LFLAGS). + + - DirectX 6 SDK (was a MS download but not sure if still available). + + - SoftIce or another debugger that will get DPF's is nice. + + +Tested on: +---------- + Windows 95 + Windows 98 + Windows NT 5.0 (beta 2) + + +What is able to do ? +-------------------- + + - the driver will try and use DirectX to rasterize the OpenGL primitives + that are sent to the driver. The driver will fall back to SW if the rendering + context is too big. The fallback to SW still uses DirectDraw. If the driver + fails to support and operation (accum, stencil, etc) then it will try and get + Mesa to render it in SW. DirectX 6 features that are unsupported by the + installed DirectX 6 driver will be mapped to some other best fit feature. + + +How to compile: +--------------- + + These instructions assume you have Visual C++ installed. + + You might need to increase you enviroment space. You can do this by + adding the following statement to you config.sys. + + shell=C:\COMMAND.COM C:\ /p /e:8198 + + Next setup you compiler enviroment by running vcvars32.bat in the Visual C++ + 'bin' directoy. + + c:\DevStudio\VC\bin\vcvars32.bat + + Modify the D3D makefile to point at your SDK install. Example has the SDK + installed on my 'f' drive in the root. + + file: \Mesa-3.0\src\makefile.d3d + + SDKROOT=f:\mssdk + + Now you can simply make the project. If you look in the makefile you can see + I have some different targets like 'install'. + + nmake /f makefile.d3d + + +FAQ: +---- + + 1) I don't think the driver is using my DirectX driver. + + This maybe true as the current version will only select the Primary D3D driver + installed. If you 3D card is the secondary (3dfx) then your out of luck for this + release. + + 2) The driver seems like its not HW accelerated. + + If you have a video card with limited memory then you might want to try and + change your destop resolution to a low setting (640x480x16) so that the 3D part + of the card has more resources. Remeber the driver can't make the card better... + + 3) Nothing works. + + Make sure you have a DirectX '6' driver installed. Check you driver docs for this + info or use the SDK info utilities. + The final 'dll' is named opengl32.dll and is either in the same directory as the + OpenGL program or in your system directory (x:\windows\system or x:\winnt\system32). + Check your destop resolution. Most DirectX 6 drivers will only support 16bit and + 32bit color depth. To find out for sure you can check the DirectX Info Viewer in + the SDK. + + + 4) Rendering doesn't look right. + + Sometimes this is because the card doesn't support a feature that that is required. + This is usually due to unsupported alpha functions (test/blend) or texture mapping. + Some cards suffer from too small of an alpha channel. The driver does its best to + fallback on unsupported features. This is not to say the driver may not have a bug(s). + + 5) Textures look bad. + + No mipmapping in this release. + + +Thanks to: +---------- + +Brian Paul + + + + +Leigh McRae (leigh@altsoftware.com) +February 9, 1999 + diff --git a/docs/README.DJ b/docs/README.DJ new file mode 100644 index 0000000..e4000ff --- /dev/null +++ b/docs/README.DJ @@ -0,0 +1,267 @@ + Mesa 6.1 DOS/DJGPP Port v1.6 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + + +Description: +~~~~~~~~~~~~ + +Well, guess what... this is the DOS port of Mesa 6.1, for DJGPP fans... Whoa! +The driver has its origins in ddsample.c, written by Brian Paul and found by me +in Mesa 3.4.2. + + + +Legal: +~~~~~~ + +Mesa copyright applies, provided this package is used within Mesa. For anything +else, see GPL. + + + +Installation: +~~~~~~~~~~~~~ + +Unzip and type: + + make -f Makefile.DJ [OPTIONS...] + +Available options: + + Environment variables: + CPU optimize for the given processor. + default = pentium + GLU=[mesa|sgi] specify GLU directory; can be `sgi' (requires GNU/C++) + or `mesa'. + default = mesa + GLIDE path to Glide3 SDK; used with FX. + default = $(TOP)/glide3 + FX=1 build for 3dfx Glide3. Note that this disables + compilation of most DMesa code and requires fxMesa. + As a consequence, you'll need the DJGPP Glide3 + library to build any application. + default = no + X86=1 optimize for x86 (if possible, use MMX, SSE, 3DNow). + default = no + + Targets: + all: build everything + libgl: build GL + libglu: build GLU + libglut: build GLUT + clean: remove object files + realclean: remove all generated files + + + +Tested on: + CPU: AMD Athlon XP 1800+ + Mainboard: GA-7VTXE w/ 512 MB DDRAM + Video card: Voodoo5 6000 AGP w/ 128 MB SDRAM + DJGPP: djdev 2.04 + gcc v3.3.2 + make v3.80 + OS: DOS and Win98SE + + + +FAQ: +~~~~ + +1. Compilation + + Q) `make' barfs and exits because it cannot find some stupid file. + A) You need LFN support. + A) When compiling for Glide (FX=1), pay attention to Glide path. + + Q) Libraries built OK, but linker complains about `vsnprintf' every time I + compile some demo. + A) Upgrade to DJGPP 2.04. + A) Add `vsnprintf.c' to the CORE_SOURCES in `src/Makefile.DJ' (untested!). + A) Patch `src/mesa/main/imports.c' with the following line: + #define vsnprintf(buf, max, fmt, arg) vsprintf(buf, fmt, arg) + This hack should be safe in 90% of the cases, but if anything goes wrong, + don't come back to me crying. + + Q) `make' complains about DXE3 or something, yet it builds the libraries. + A) DXE3 refers to the DJGPP dynamic modules. You'll need either the latest + DJGPP distro, or download the separate package from my web page. Read the + DXE3 documentation on how to use them. + A) When compiling for Glide (FX=1), make sure `glide3x.dxe' can be found in + LD_LIBRARY_PATH (or top `lib' directory). + +2. Using Mesa for DJGPP + + Q) DMesa is so SLOOOW! The Win32 OpenGL performs so much better... + A) Is that a question? If you have a 3dfx Voodoo or higher card, you're + lucky (check http://sourceforge.net/projects/glide for the DJGPP port). + If you haven't, sorry; everything is done in software. Suggestions? + + Q) I tried to set refresh rate w/ DMesa, but without success. + A) Refresh rate control works only for VESA 3.0 and the 3dfx driver (in + which case FX_GLIDE_REFRESH will be overwritten if it is defined and + is not 0). + + Q) I made a simple application and it does nothing. It exits right away. Not + even a blank screen. + A) Pure software drivers (VESA/VGA/NUL) support only double-buffered modes. + A) Another weird "feature" is that buffer width must be multiple of 8 (I'm a + lazy programmer and I found that the easiest way to keep buffer handling + at peak performance ;-). + + Q) I'm getting a "bad font!" fatal error. + A) By default, DOS GLUT compiles with GLUT_IMPORT_LIB, to cope with variable + access inside dynamic modules (same mechanism used for Win32 _DLL). Since + -DGLUT_IMPORT_LIB affects Mesa's `glut.h', your apps must be compiled the + same way GLUT was compiled (either with or without defining it). If you + want to use another `glut.h' when building your own demos, or just don't + feel happy about this, make sure you remove the line with GLUT_IMPORT_LIB + from `Mesa/src/glut/dos/Makefile.DJ' before (re)making GLUT. Beware, this + means you will never EVER be able to safely use `glut.dxe'! + + Q) What is NUL driver good for, if I don't get any output at all? + A) For debugging. The NUL driver is very much like OSMesa. Everything is + done just the same as VESA/VGA drivers, only it doesn't touch your video + hardware. You can query the actual buffer by issuing: + DMesaGetIntegerv(DMESA_GET_BUFFER_ADDR, &buffer); + and dump it to a file. + + Q) How do I query for a list of available video modes to choose as a visual? + A) This is an ugly hack, for which I'm sure I'll burn in hell. + First, query for a list of modes: + n = DMesaGetIntegerv(DMESA_GET_VIDEO_MODES, NULL); + If `n' is strictly positive, you allocate an array of pointers to a given + struct (which is guaranteed to be extended only - not changed in future): + struct { + int xres, yres; + int bpp; + } **l = malloc(n * sizeof(void **)); + Now pass the newly allocated buffer to fill in: + DMesaGetIntegerv(DMESA_GET_VIDEO_MODES, (GLint *)l); + And collect the info: + for (i = 0; i < n; i++) { + printf("%dx%d:%d\n", l[i]->xres, l[i]->yres, l[i]->bpp); + } + + Q) The GLUT is incomplete. + A) See below. + + + +libGLUT (the toolkit): +~~~~~~~~~~~~~~~~~~~~~~ + +Well, this "skeletal" GLUT implementation was taken from AllegGL project and +heavily changed. Thanks should go to Bernhard Tschirren, Mark Kilgard, Brian +Paul and probably others (or probably not ;-). GLUT functionality will be +extended only on an "as needed" basis. + +GLUT talks to hardware via PC_HW package which was put together from various +pieces I wrote long time ago. It consists from the keyboard, mouse and timer +drivers. + +My keyboard driver used only scancodes; as GLUT requires ASCII values for keys, +I borrowed the translation tables (and maybe more) from Allegro -- many thanks +to Shawn Hargreaves et co. Ctrl-Alt-Del (plus Ctrl-Alt-End, for Windows users) +will shut down the GLUT engine unconditionally: it will raise SIGINT, which in +turn will (hopefully) call the destructors, thus cleaning up your/my mess ;-) +NB: since the DJGPP guys ensured signal handlers won't go beyond program's +space (and since dynamic modules shall) the SIGINT can't be hooked (well, it +can, but it is useless), therefore you must live with the 'Exiting due to +signal SIGINT' message... + +The mouse driver is far from complete (lack of drawing, etc), but is enough to +make almost all the demos work. Supports the CuteMouse WheelAPI. + +The timer is pretty versatile for it supports multiple timers with different +frequencies. While not being the most accurate timer in the known universe, I +think it's OK. Take this example: you have timer A with a very high rate, and +then you have timer B with very low rate compared to A; now, A ticks OK, but +timer B will probably loose precision! + +As an addition, stdout and stderr are redirected and dumped upon exit. This +means that `printf' can be safely called during graphics. A bit of a hack, I +know, because all messages come in bulk, but I think it's better than nothing. +"Borrowed" from LIBRHUTI (Robert Hoehne). + +Window creating defaults: (0, 0, 300, 300), 16bpp. However, the video mode is +chosen in such a way that first window will fit. If you need high resolution +with small windows, set initial position far to the right (or way down); then +you can move them back to any position right before the main loop. + + + +Environment variables: +~~~~~~~~~~~~~~~~~~~~~~ + DMESA_NULDRV - (any value) force NUL driver + GLUT_FPS - print frames/second statistics to stderr + DMESA_GLUT_REFRESH - set vertical screen refresh rate (VESA3) + DMESA_GLUT_BPP - set default bits per pixel (VGA needs 8) + DMESA_GLUT_ALPHA - set default alpha bits (8) + DMESA_GLUT_DEPTH - set default depth bits (16) + DMESA_GLUT_STENCIL - set default stencil bits (8) + DMESA_GLUT_ACCUM - set default accum bits (16) + + + +History: +~~~~~~~~ + +v1.0 (mar-2002) + initial release + +v1.1 (sep-2002) + + added 3dfx Glide3 support + + added refresh rate control + + added fonts in GLUT + * lots of minor changes + +v1.2 (nov-2002) + * synced w/ Mesa-4.1 + - removed dmesadxe.h + +v1.3 (mar-2003) + + enabled OpenGL 1.4 support + + added MMX clear/blit routines + + enabled SGI's GLU compilation + + added samples makefile + + added new GLUT functions + + added color-index modes + + added Matrox Millennium MGA2064W driver + + added 8bit FakeColor (thanks to Neil Funk) + + added VGA support (to keep Ben Decker happy) + ! fixed some compilation errors (reported by Chan Kar Heng) + * optimized driver for faster callback access... yeah, right :) + * overhauled virtual buffer and internal video drivers + * better fxMesa integration + * revamped GLUT + * switched to DXE3 + +v1.4 (dec-2003) + + enabled GLUT fonts with DXE + + truly added multi-window support in GLUT (for Adrian Woodward) + * accomodated makefiles with the new sourcetree + * fixed some ALPHA issues + * minor changes to PC_HW/timer interface + x hacked and slashed the 3dfx driver (w/ help from Hiroshi Morii) + +v1.5 (jan-2004) + + added interface to query available "visuals" (GLFW - Marcus Geelnard) + + added GLUT timer callback + - removed Matrox Millennium MGA2064W driver + x more changes to the 3dfx driver + +v1.6 (aug-2004) + + implemented NUL driver + + added DMesaGetProcAddress and glutGetProcAddress + * reorganized fxMesa wrapper to handle multiple contexts + ! fixed a horrible bug in VGA initialization routine + ! fixed partial clears + + + +Contact: +~~~~~~~~ + +Name: Daniel Borca +E-mail: dborca@users.sourceforge.net +WWW: http://www.geocities.com/dborca/ diff --git a/docs/README.GGI b/docs/README.GGI new file mode 100644 index 0000000..ddb6772 --- /dev/null +++ b/docs/README.GGI @@ -0,0 +1,26 @@ +GGIMesa for LibGGI 2.x + +Requirements: +------------- +LibGGI 2.0 or greater + +Installation: +------------- +To install GGIMesa, follow the instructions in INSTALL.GNU. If you +wish to install GGIGLUT as well, first install GGIMesa and then run + +make +make install (must be root) + +in ggi/ggiglut. + +Notes: +------ + +* Set the environment variables GGIMESA_DEBUG and/or GGIGLUT_DEBUG +to 255 to see lots of debugging output. + +* GGIGLUT contains support for all of the GLUT 3.6 API except for the +high-level primitive drawing functions, but many of the functions (in +particular the menu drawing functions) are just stubs. + diff --git a/docs/README.LYNXOS b/docs/README.LYNXOS new file mode 100644 index 0000000..e3ab980 --- /dev/null +++ b/docs/README.LYNXOS @@ -0,0 +1,64 @@ + +Mesa 3.0 for LynxOS builds in the following way: + +make lynxos + +This will build all the libraries and demo applications. You should have +around 400 megabytes free for everything since everything is done with +static +libraries. + +Before using this make file however, you should perform the following +actions: +0) cd to the Mesa-3.0 directory +1) Copy the GL directory under the include directory to /usr/include. +2) Copy the files in the lib directory to /lib. +3) Make links so that the Mesa libraries look like ordinary OpenGL +libraries +in /lib. This is important for compatibility with other OpenGL apps. This +is done as follows: + +cd /lib +ln -s libMesaGL.a libGL.a +ln -s libMesaGLU.a libGLU.a + +Mesa 3.0 includes the GLUT (GL Utility Toolkit) by default. +The demo applications are done using this toolkit. + +Mesa makefiles for building their apps could be used as well, but the +following one is much more concise. Note that the order of the X libraries +is important to the linker so that all symbols get resolved correctly. +Changing the order may result in having to list a library twice to make +sure all linkages are made correctly. + +----cut here for Makefile ----- + +FILES = your_app.x + +SPECIAL_INCLUDES = -I/usr/include/GL + +SPECIAL_CFLAGS = -g -ansi -pedantic -funroll-loops -ffast-math -DSHM + +SPECIAL_LIBS = -lglut -lGLU -lGL -lm -L/usr/X11/lib -lXext -lXmu -lXi \ +-lX11 -lbsd -g + +STANDARD_OFILES = $(FILES:.x=.o) + +%.o: %.c + gcc -c $(SPECIAL_CFLAGS) $(SPECIAL_INCLUDES) $< -o $@ + +all: $(STANDARD_OFILES) + gcc -o your_app $(STANDARD_OFILES) $(SPECIAL_LIBS) + + +----cut here for Makefile----- + +I have tested Mesa under LynxOS 3.0 and 3.01. It should build fine under +other +versions as well. Note, however, that LynxOS versions prior to 3.0 are not +binary compatible, so you will have to rebuild from source. + + +Vik Sohal +vik@lynx.com +January 13, 1999 diff --git a/docs/README.MINGW32 b/docs/README.MINGW32 new file mode 100644 index 0000000..f337cae --- /dev/null +++ b/docs/README.MINGW32 @@ -0,0 +1,81 @@ + Mesa 6.1 for MinGW32 + ~~~~~~~~~~~~~~~~~~~~ + + + +Quick & dirty start: +-------------------- + + mingw32-make -f Makefile.mgw [OPTIONS...] + + Look into the corresponding makefiles for further information. + Check README.3DFX to find out how to compile Mesa Glide3 driver + with MinGW32! + + + +Contact: +-------- + +Daniel Borca + + + +WARNING! The info below this line is outdated (yet some of it useful). WARNING! +******************************************************************************* + + + +August 30, 1998 -- Paul Garceau +Updated January 13, 2000 -- Paul Garceau (pgarceau@teleport.com) + +DISCLAIMER: I make this port of the Mesa 3-D Graphics Library as a service +to the general public. I can, in no way support or make any guarantee that the +build will work for your system. + + The associated packages and batch files I have included as part of the GCC-2.95.2/Mingw32 extension are provided "As-is" with out any guarantee of support or functionality from this author. + + Feel free to modify or change things as you see fit, just remember that +I can't support any modifications you might want to make to the files which I +have included OR the lgpl protected Mesa 3-D Graphics Library. + + I recommend using GCC-2.95.2/Mingw32 which is available at Mumit Khans' ftp site: + + (ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/) + + This build has been tested under WinNT4/SP6. Win9x and WinNT5 remain untested by me. I have not tested any of the demos included with Mesa3d. + + I recommend using the GCC-2.95.2/Mingw32. + + ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2 + + Much thanks to the combined efforts of Mumit Khan, Jan-Jaap Vanderhagen +and Colin Peters for making it possible for the Mingw32 toolchain to exist. Also, thanks go out to Stephane Rehel for the work that was completed on the Cygwin build. + +Installing GCC-2.95.2/Mingw32 Build: + + a) Open the file archive (either tar.gz or .zip extensions) + + b) Decide the directory you want to move the archived files to. + + d) Extract the files from the archive. + + e) Edit the mingw32.bat file to accomodate your choice of directory structure. + + %mesaroot%: This is your root directory (Mesa-3.3) + %mesasrc%: This is the Mesa-3.3 src directory (Mesa-3.3\src) + %mesalib%: This is where the build will put libGL.a and libGLU.a + +Running the Build: + + Open your Command Prompt or MS-DOS prompt. + Go to your Mesa-3.3 'root' directory + At the command line type: mingw32 + + That's all there is to it. + + Enjoy! + + Peace, + + Paul G. (pgarceau@teleport.com) \ No newline at end of file diff --git a/docs/README.MITS b/docs/README.MITS new file mode 100644 index 0000000..a89176a --- /dev/null +++ b/docs/README.MITS @@ -0,0 +1,102 @@ + + Mesa 3.0 MITS Information + + +This software is distributed under the terms of the GNU Library +General Public License, see the LICENSE file for details. + + +This document is a preliminary introduction to help you get +started. For more detaile information consult the web page. + +http://10-dencies.zkm.de/~mesa/ + + + +Version 0.1 (Yes it's very alpha code so be warned!) +Contributors: + Emil Briggs (briggs@bucky.physics.ncsu.edu) + David Bucciarelli (tech.hmw@plus.it) + Andreas Schiffler (schiffler@zkm.de) + + + +1. Requirements: + Mesa 3.0. + An SMP capable machine running Linux 2.x + libpthread installed on your machine. + + +2. What does MITS stand for? + MITS stands for Mesa Internal Threading System. By adding + internal threading to Mesa it should be possible to improve + performance of OpenGL applications on SMP machines. + + +3. Do applications have to be recoded to take advantage of MITS? + No. The threading is internal to Mesa and transparent to + applications. + + +4. Will all applications benefit from the current implementation of MITS? + No. This implementation splits the processing of the vertex buffer + over two threads. There is a certain amount of overhead involved + with the thread synchronization and if there is not enough work + to be done the extra overhead outweighs any speedup from using + dual processors. You will not for example see any speedup when + running Quake because it uses GL_POLYGON and there is only one + polygon for each vertex buffer processed. Test results on a + dual 200 Mhz. Pentium Pro system show that one needs around + 100-200 vertices in the vertex buffer before any there is any + appreciable benefit from the threading. + + +5. Are there any parameters that I can tune to try to improve performance. + Yes. You can try to vary the size of the vertex buffer which is + define in VB_MAX located in the file src/vb.h from your top level + Mesa distribution. The number needs to be a multiple of 12 and + the optimum value will probably depend on the capabilities of + your machine and the particular application you are running. + + +6. Are there any ways I can modify the application to improve its + performance with the MITS? + Yes. Try to use as many vertices between each Begin/End pair + as possbile. This will reduce the thread synchronization + overhead. + + +7. What sort of speedups can I expect? + On some benchmarks performance gains of up to 30% have been + observerd. Others may see no gain at all and in a few rare + cases even some degradation. + + +8. What still needs to be done? + Lots of testing and benchmarking. + A portable implementation that works within the Mesa thread API. + Threading of additional areas of Mesa to improve performance + even more. + + + +Installation: + + 1. This assumes that you already have a working Mesa 3.0 installation + from source. + 2. Place the tarball MITS.tar.gz in your top level Mesa directory. + 3. Unzip it and untar it. It will replace the following files in + your Mesa source tree so back them up if you want to save them. + + + README.MITS + Make-config + Makefile + mklib.glide + src/vbxform.c + src/vb.h + + 4. Rebuild Mesa using the command + + make linux-386-glide-mits + diff --git a/docs/README.NeXT b/docs/README.NeXT new file mode 100644 index 0000000..1ad9a9e --- /dev/null +++ b/docs/README.NeXT @@ -0,0 +1,6 @@ +The NeXT support has now been incorporated into the OpenStep support. +You can build NeXT libraries simply by typing "make next", though before +linking they will need to be ranlib'd by hand. For more information see +the README.OpenStep file, together with the README files in OpenStep/Old_Demos. + +-Pete French. (pete@ohm.york.ac.uk) 28/5/1998 diff --git a/docs/README.OS2 b/docs/README.OS2 new file mode 100644 index 0000000..b3374ea --- /dev/null +++ b/docs/README.OS2 @@ -0,0 +1,96 @@ + README for port of Mesa 3.x to XFree86 on OS/2 (X/2) + (as of 19990514) + + + Contents: + + 1) Binary release + 2) Building from sources + 3) History + 4) Todo + 5) Mesa Home Page + + +1) Binary release + + Though the Mesa sources should build in a quite reasonable time even on + a 585 class machine a binary relase is available (check topic 4) for an URL) + This package includes: + + - lib/MesaGL.dll, MesaGL.a + - lib/MesaGLU.dll, MesaGLU.a + - lib/glut.dll, glut.a + - include/GL/*.h + + Installing this in your XFree86 tree will enable you to build and + run all applications compatible with Mesa (and the current DLL + interface, of course ;-) + As usual the OMF-style libraries can be created using emxomf. + (e.g. "emxomf foo.a" creates the foo.lib omf-style library). + The static libraries are rarely used and you have to rebuild + Mesa to get them. They're a supported target, so you get + them in a straightforward way (see below). + + The testing of these libraries was limited to the supplied + demos/examples and a quite small number of third-party apps. + No warranty ... as usual ... ;-) + + +2) Instructions to build Mesa 3.x for XFree86/OS2 from sources: + + Except the official Mesa source distribution you need: + - a recent version of XFree86 (3.3.x or above) including + the programming libraries + - EMX 0.9c (0.9d might work, never checked) + - GNU make + - REXX (!) + + The creation of the DLLs as well as of the static libraries + (if you want to have them) is handled in "mklib-emx.cmd", + a small REXX script. Perhaps not the best idea, but this + way it fits best in the scheme used to build libraries + on all platforms in Mesa 3.x. + + To actually build the libraries and demos, check mklib-emx.cmd + and modify it as desired. Then type + make os2-x11 + and wait for completion ;-) + + +3) History + + Initially Darren Abbott (abbott@hiwaay.net) ported Mesa versions 2.x + to XFree86 OS/2. This port might still be available from + http://fly.HiWAAY.net/~abbott/xfree86-os2/xfree86.html + + The current port picked up things during the beta test for 3.0. + No major changes in the source were done. The build mechanism under OS/2 + has been made very similar to other platforms (if you treat mklib-emx.cmd + as a "black box"). + Advantage is that X/2 is now a valid target and all files are + integrated in the official source distribution. + Disadvantage is that this port (i.e. the DLLs' interface itself) is + definitly NOT COMPATIBLE to those of version 2.x. + It's uncertain whether this would be at all possible but since there + a _very_ few those apps it's not worth to find out anyway. + Also some libs (MesaTK, MesaAUX) are withdrawn from the Mesa distribution, + and accordingly from the OS/2 port. + +4) Todo + + By now binary compatiblity is ensured by using the function names + as entry points instead of ordinals. This might cost performance and + is subject to change in future. In addition the supplied X86 assembler + source is not used yet. + +5) Mesa Home Page + + You can get the source code and more information about Mesa from + http://www.mesa3d.org/ + + The OS/2 ports should be available from + http://r350.ee.ntu.edu.tw/~hcchu/os2/ports + +-- +Alexander Mai +st002279@hrzpub.tu-darmstadt.de diff --git a/docs/README.OpenStep b/docs/README.OpenStep new file mode 100644 index 0000000..a566eca --- /dev/null +++ b/docs/README.OpenStep @@ -0,0 +1,35 @@ +This is a port of the GL and GLU libraries to NeXT/Apple object +orientated systems. As these systems have their own window handling +systems we simply use the offscreen rendering capability of Mesa +to generate bitmaps which may then be displayed by the application +with a View as required. Example pieces of code may be found in the +OpenStep directory. + +Sadly there are now a proliferation of different system that we need to +support compilation for: The original NextStep system, The OpenStep +system, the Rhapsody/Mac OS X system and also the windows implementations +of the latter two systems. This version of the code has been compiled and +tested under the following architectures: + + NextStep 3.3 + OpenStep 4.2 + Rhapsody DR2 + WebObjects for NT 3.5 + WebObjects for NT 4.0 + +All tests were done with Intel processors. Feedback on other systems would, +however, be appreciated ! + +On UNIX systems simply type "make openstep". Under Windows systems +with WebObjects run the "win32-openstep.sh" script from within the Bourne +shell provided with the development environment. In both cases this will +build the libraries and place them into the "lib" directory. Some examples +may be found in the OpenStep directory showing how to use the code in an +actual application (MesaView) as well as some command line demos. + +The CC variable may be specified on the command line for doing such things +as building FFAT libraries or using alternative compilers to the standard 'cc' +e.g. make CC='cc -arch m68k -arch i386' openstep" will build the libraries +with both intel and motorola architectures. + +-Pete French. (pete@ohm.york.ac.uk) 7/6/1999 diff --git a/docs/README.QUAKE b/docs/README.QUAKE new file mode 100644 index 0000000..5a13b7a --- /dev/null +++ b/docs/README.QUAKE @@ -0,0 +1,208 @@ + + Info on using Mesa 3.0 with Linux Quake I and Quake II + + + +Disclaimer +---------- + +I am _not_ a Quake expert by any means. I pretty much only run it to +test Mesa. There have been a lot of questions about Linux Quake and +Mesa so I'm trying to provide some useful info here. If this file +doesn't help you then you should look elsewhere for help. The Mesa +mailing list or the news://news.3dfx.com/3dfx.linux.glide newsgroup +might be good. + +Again, all the information I have is in this file. Please don't email +me with questions. + +If you have information to contribute to this file please send it to +me at brianp@elastic.avid.com + + + +Linux Quake +----------- + +You can get Linux Quake from http://www.idsoftware.com/ + +Quake I and II for Linux were tested with, and include, Mesa 2.6. You +shouldn't have too many problems if you simply follow the instructions +in the Quake distribution. + + + +RedHat 5.0 Linux problems +------------------------- + +RedHat Linux 5.x uses the GNU C library ("glibc" or "libc6") whereas +previous RedHat and other Linux distributions use "libc5" for its +runtime C library. + +Linux Quake I and II were compiled for libc5. If you compile Mesa +on a RedHat 5.x system the resulting libMesaGL.so file will not work +with Linux Quake because of the different C runtime libraries. +The symptom of this is a segmentation fault soon after starting Quake. + +If you want to use a newer version of Mesa (like 3.x) with Quake on +RedHat 5.x then read on. + +The solution to the C library problem is to force Mesa to use libc5. +libc5 is in /usr/i486-linux-libc5/lib on RedHat 5.x systems. + +Emil Briggs (briggs@tick.physics.ncsu.edu) nicely gave me the following +info: + +> I only know what works on a RedHat 5.0 distribution. RH5 includes +> a full set of libraries for both libc5 and glibc. The loader ld.so +> uses the libc5 libraries in /usr/i486-linux-libc5/lib for programs +> linked against libc5 while it uses the glibc libraries in /lib and +> /usr/lib for programs linked against glibc. +> +> Anyway I changed line 41 of mklib.glide to +> GLIDELIBS="-L/usr/local/glide/lib -lglide2x -L/usr/i486-linux-libc5/lib" +> +> And I started quake2 up with a script like this +> #!/bin/csh +> setenv LD_LIBRARY_PATH /usr/i486-linux-libc5/lib +> setenv MESA_GLX_FX f +> ./quake2 +set vid_ref gl +> kbd_mode -a +> reset + + +I've already patched the mklib.glide file. You'll have to start Quake +with the script shown above though. + + + +********************** + +Daryll Strauss writes: + +Here's my thoughts on the problem. On a RH 5.x system, you can NOT build +a libc5 executable or library. Red Hat just doesn't include the right +stuff to do it. + +Since Quake is a libc5 based application, you are in trouble. You need +libc5 libraries. + +What can you do about it? Well there's a package called gcc5 that does +MOST of the right stuff to compile with libc5. (It brings back older +header files, makes appropriate symbolic links for libraries, and sets +up the compiler to use the correct directories) You can find gcc5 here: +ftp://ecg.mit.edu/pub/linux/gcc5-1.0-1.i386.rpm + +No, this isn't quite enough. There are still a few tricks to getting +Mesa to compile as a libc5 application. First you have to make sure that +every compile uses gcc5 instead of gcc. Second, in some cases the link +line actually lists -L/usr/lib which breaks gcc5 (because it forces you +to use the glibc version of things) + +If you get all the stuff correctly compiled with gcc5 it should work. +I've run Mesa 3.0B6 and its demos in a window with my Rush on a Red Hat +5.1 system. It is a big hassle, but it can be done. I've only made Quake +segfault, but I think that's from my libRush using the wrong libc. + +Yes, mixing libc5 and glibc is a major pain. I've been working to get +all my libraries compiling correctly with this setup. Someone should +make an RPM out of it and feed changes back to Brian once they get it +all working. If no one else has done so by the time I get the rest of my +stuff straightened out, I'll try to do it myself. + + - |Daryll + + + +********************* + +David Bucciarelli (tech.hmw@plus.it) writes: + +I'm using the Mesa-3.0beta7 and the RedHat 5.1 and QuakeII is +working fine for me. I had only to make a small change to the +Mesa-3.0/mklib.glide file, from: + + + GLIDELIBS="-L/usr/local/glide/lib -lglide2x +-L/usr/i486-linux-libc5/lib -lm" + +to: + + GLIDELIBS="-L/usr/i486-linux-libc5/lib -lglide2x" + +and to make two symbolic links: + +[david@localhost Mesa]$ ln -s libMesaGL.so libMesaGL.so.2 +[david@localhost Mesa]$ ln -s libMesaGLU.so libMesaGLU.so.2 + +I'm using the Daryll's Linux glide rpm for the Voodoo2 and glibc (it +includes also the Glide for the libc5). I'm not using the /dev/3Dfx and +running QuakeII as root with the following env. var: + +export +LD_LIBRARY_PATH=/dsk1/home/david/src/gl/Mesa/lib:/usr/i486-linux-libc5/lib + +I think that all problems are related to the glibc, Quake will never +work if you get the following output: + +[david@localhost Mesa]$ ldd lib/libMesaGL.so + libglide2x.so => /usr/lib/libglide2x.so (0x400f8000) + libm.so.6 => /lib/libm.so.6 (0x40244000) + libc.so.6 => /lib/libc.so.6 (0x4025d000) + /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000) + +You must get the following outputs: + +[david@localhost Mesa]# ldd lib/libMesaGL.so + libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so +(0x400f3000) + +[root@localhost quake2]# ldd quake2 + libdl.so.1 => /lib/libdl.so.1 (0x40005000) + libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x40008000) + libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x40010000) + +[root@localhost quake2]# ldd ref_gl.so + libMesaGL.so.2 => +/dsk1/home/david/src/gl/Mesa/lib/libMesaGL.so.2 (0x400eb000) + libglide2x.so => /usr/i486-linux-libc5/lib/libglide2x.so +(0x401d9000) + libX11.so.6 => /usr/i486-linux-libc5/lib/libX11.so.6 +(0x40324000) + libXext.so.6 => /usr/i486-linux-libc5/lib/libXext.so.6 +(0x403b7000) + libvga.so.1 => /usr/i486-linux-libc5/lib/libvga.so.1 +(0x403c1000) + libm.so.5 => /usr/i486-linux-libc5/lib/libm.so.5 (0x403f5000) + libc.so.5 => /usr/i486-linux-libc5/lib/libc.so.5 (0x403fd000) + + +*********************** + +Steve Davies (steve@one47.demon.co.uk) writes: + + +Try using: + + export LD_LIBRARY_PATH=/usr/i486-linux-libc5/lib + ./quake2 +set vid_ref gl + +to start the game... Works for me, but assumes that you have the +compatability libc5 RPMs installed. + + +*************************** + +WWW resources - you may find additional Linux Quake help at these URLs: + + +http://quake.medina.net/howto + +http://webpages.mr.net/bobz + +http://www.linuxgames.com/quake2/ + + + +---------------------------------------------------------------------- +$Id: README.QUAKE,v 1.3 1998/08/23 15:26:26 brianp Exp $ diff --git a/docs/README.THREADS b/docs/README.THREADS new file mode 100644 index 0000000..fb6e0ff --- /dev/null +++ b/docs/README.THREADS @@ -0,0 +1,52 @@ + + +Mesa Threads README +------------------- + +Thread safety was introduced in Mesa 2.6 by John Stone and +Christoph Poliwoda. + +It was redesigned in Mesa 3.3 so that thread safety is +supported by default (on systems which support threads, +that is). There is no measurable penalty on single +threaded applications. + +NOTE that the only _driver_ which is thread safe at this time +is the OS/Mesa driver! + + +At present the mthreads code supports three thread APIS: + 1) POSIX threads (aka pthreads). + 2) Solaris / Unix International threads. + 3) Win32 threads (Win 95/NT). + +Support for other thread libraries can be added src/glthread.[ch] + + +In order to guarantee proper operation, it is +necessary for both Mesa and application code to use the same threads API. +So, if your application uses Sun's thread API, then you should build Mesa +using one of the targets for Sun threads. + +The mtdemos directory contains some example programs which use +multiple threads to render to osmesa rendering context(s). + +Linux users should be aware that there exist many different POSIX +threads packages. The best solution is the linuxthreads package +(http://pauillac.inria.fr/~xleroy/linuxthreads/) as this package is the +only one that really supports multiprocessor machines (AFAIK). See +http://pauillac.inria.fr/~xleroy/linuxthreads/README for further +information about the usage of linuxthreads. + +If you are interested in helping with thread safety work in Mesa +join the Mesa developers mailing list and post your proposal. + + +Regards, + John Stone -- j.stone@acm.org johns@cs.umr.edu + Christoph Poliwoda -- poliwoda@volumegraphics.com + + +Version info: + Mesa 2.6 - initial thread support. + Mesa 3.3 - thread support mostly rewritten (Brian Paul) diff --git a/docs/README.VMS b/docs/README.VMS new file mode 100644 index 0000000..9cb4724 --- /dev/null +++ b/docs/README.VMS @@ -0,0 +1,28 @@ + +VMS support contributed by Jouk Jansen (joukj@hrem.stm.tudelft.nl) + + +The latest version was tested on a VMSAlpha7.2 system using DECC6.0, but +probably also works for other versions. + +At the moment only the libraries LIBMESGL.EXE/LIBMESGL.OLB, +LIBMESAGLU.EXE/LIBMESAGLU.OLB and LIBGLUT.EXE/LIBGLUT.OLB and the demos of the +directory [.DEMOS] can be build. +However, feel free to create the missing "decrip.mms-files" in the other +directories. + + The make files were tested +using the DIGITAL make utility called MMS. There is also a public domain +clone available (MMK) and I think, but it is not tested, that this +utility will give (hardly) any problem. + +To make everything just type MMS (or MMK) in the main directory of +mesagl. For MMS the deafult makefile is called descrip.mms, and +that is what I have called it. I included alse some config files, +all having mms somewhere in the name which all the makefiles need +(just as your unix makefiles). + +On Alpha platforms at default a sharable images for the libraries are created. +To get a static library make it by typing MMS/MACRO=(NOSHARE=1). +On VAX platforms only static libraries can be build. + diff --git a/docs/README.WIN32 b/docs/README.WIN32 new file mode 100644 index 0000000..e16ee4b --- /dev/null +++ b/docs/README.WIN32 @@ -0,0 +1,108 @@ +File: docs/README.WIN32 + +Last updated: Oct 01, 2004 - Karl Schultz - kschultz@users.sourceforge.net + +Quick Start + +Unzip both ZIP files (MesaLib and MesaDemos) into the same directory. +The libs and demos build separately, so if you do not care about the +demos, you do not have to unzip that zip file. But if you do, it does +need to be unzipped into the same directory as the lib zip file because +the demos depend on the libs. + +The build system has been changed to use Microsoft Visual Studio project +workspaces and projects. Makefiles are no longer shipped or supported, but +can be generated from the projects using Visual Studio. + +The workspace and project files were created with Visual Studio 6, so that +they can be used with VS6 and so that they can also be imported into VS 7. + +Details and Notes + +- To build the Mesa libraries, open the Mesa.dsw workspace file + in the top directory. You will need to build at least one + driver. Currently, only the gdi and osmesa drivers are available. + Select one or the other as the active project and build it. + If you want glu, select the glu project as active and build that as well. + +- Glut is no longer in the Mesa.dsw workspace. It is now built in + the demo workspace (see below). + +- The build process will create a lib directory in the top directory + and will put the following files there as you build them: + OPENGL32.LIB, GLU32.LIB, OSMESA32.LIB + OPENGL32.DLL, GLU32.DLL, OSMESA32.DLL + +- Some users have reported problems building glu with VS7 after importing + and converting the VS6 project files. The problem is caused by a custom + build step that was put in place to work around a problem with VS6 not + recognizing .cc files as C++ source files. It appears that VS7 can be + configured to recognize .cc files as C++ files and so it compiles these + glu files with the default settings, and does not use settings that are + required to compile the files correctly. The easiest way to solve the + problem is to remove the .cc files from the glu project. This does not + delete the files, but removes them from the project so that VS does not + try to compile them at all. This allows the custom build step to compile + the files with the proper settings. + +- After building, you can copy the above DLL files to a place in your PATH + such as $SystemRoot/SYSTEM32. If you don't like putting things in a + system directory, place them in the same directory as the executable(s). + Be careful about accidentially overwriting files of the same name in + the SYSTEM32 directory. + +- Build the demos by opening the appropriate *.dsw file in the + progs directory tree. For example, to build the demos, use + progs/demos/Windows/demos.dsw. The Windows directory contains + the workspace and all the projects for each demo program. Each + project places the executable in the same directory as its source + code, which is required for some demos. + +- The demo projects also copy the Mesa library DLL files from the lib + directory into the same directory as the demo executables, so that + the demos use the Mesa libs you just built. + +- The DLL files are built so that the external entry points use the + stdcall calling convention. + +- Static LIB files are not built. The LIB files that are built with + are the linker import files associated with the DLL files. + +- The si-glu sources are used to build the GLU libs. This was done + mainly to get the better tessellator code. + +- The Windows driver (in src/Windows) builds and runs at least at + a minimal level. I modified this driver to work with the new + Mesa 4.0 code and driver architecture, but I did not do a great + deal of optimization and testing. There are many opportunities + for optimization, many of which can be done by coding more specific + paths for the rasterizers. See src/osmesa/osmesa.c for some good + examples. + +- There is DirectDraw support in the Windows driver, updated by + Daniel Slater. You'll need to uncomment the #define DDRAW line + in src/Windows/wmesadef.h and add ddraw.lib to the list of libraries. + On some systems, you will acheive significantly higher framerates + with DirectDraw. + +- Some of the more specialized code like FX drivers, stereo, and + parallel support isn't compiled or tested. I left much of this + code alone, but it may need some work to get it 'turned on' again. + +- No assembly code is compiled or assembled. Again, this may need + some work to turn it back on or use it again. + +- To build "mangled" Mesa, add the preprocessor define USE_MGL_NAMESPACE + to the project settings. You will also need to edit src/mesa.def to change + all the gl* symbols to mgl*. Because this is easy to do with a global + replace operation in a text editor, no additional mangled version of mesa.def + is maintained or shipped. + +If you have a Windows-related build problem or question, it is +probably better to direct it to me (kschultz@users.sourceforge.net), +rather than directly to the other Mesa developers. I will help you +as much as I can. I also monitor the Mesa mailing lists and will +answer questions in this area there as well. + + +Karl Schultz diff --git a/docs/README.WINDML b/docs/README.WINDML new file mode 100644 index 0000000..448db71 --- /dev/null +++ b/docs/README.WINDML @@ -0,0 +1,146 @@ + + WindML Driver for Mesa 4.0 + + +Requirements +------------ + +Tornado 2 + WindML, Cumulative Patchs are recommended. + +I suppose you have a valid WindML installation. Double buffer hardware +gives better performance than double buffer software so if you can +compile your WindML driver with this option, just do it. I/O +redirection is adviced in target server. + + +Tested on +--------- + +During the development, my main target was a CoolMonster: +- Video card: CT69000 +- CPU: PENTIUM 266MHz + +and my host a Windows NT + Tornado 2. + + +Installation +------------ + +1. Mesa sources must be in root directory (C:\) + +2. Add the following line to your torVars.bat: +set MESA_BASE=C:\Mesa + +OR copy the new torVars.bat in your bin path: +c:/Mesa/src/ugl/tornado/torVars.sample -> +/mnt/nt/Tornado/host/x86-win32/bin/torVars (for example) + +3. In a command prompt: +$ torVars +$ cd c:\Mesa +$ make -f Makefile.ugl CPU=PENTIUM + +Take a long while... + +5. Include all the files from ugldemos folder to build some downloadable + application modules + +4. Download UGL/Mesa object files on target + +For example via the WindShell: +ld < c:\Tornado\target\lib\objMesaGL.o +ld < c:\Tornado\target\lib\objMesaUGL.o +ld < c:\Tornado\target\lib\objMesaGLU.o +ld < c:\Tornado\target\lib\objGLUTshapes.o +ld < c:\Tornado\target\lib\objMesaOS.o + +You can put the previous lines in a file and use: +< filename + +6. Download the application modules. + +7. In WindShell, run: +-> uglalldemos + +During the show some messages will appear, it provides some useful +information on key management. + + +Coding +------ + +Sample Usage: + +In addition to the usual ugl calls to initialize UGL, (may be find an +input driver), you must do the following to use the UGL/Mesa interface: + +1. Call uglMesaCreateContext() to create a UGL/Mesa rendering context, + given the display format. + +2. Call uglMesaMakeCurrent() to bind the UGL/Mesa buffers to an + UGL/Mesa Context and to make the context the current one. + +3. Make gl* calls to render your graphics. + +4. Use uglMesaSwapBuffers() when double buffering to swap front/back buffers. + +5. Before the UGL is destroyed, call MesaDestroyContext(). + +6. Before exiting, call if required uglEventQDestroy and then + uglDeinitialize(); + +Limitations +----------- + +I found the following limitations in my driver : + - Color Indexed management is only in 8 bits + - It's possible to mix UGL/OpenGL application with a software + double buffer + +Modifications +------------ + +New files in Mesa: +- Makefile.ugl +- rules.windmlmesa +- docs/README.UGL +- include/GL/uglmesa.h +- si-glu/Makefile.ugl +- src/Makefile.ugl +- src/ugl/torGLUTShapesInit.c +- src/ugl/torMesaUGLInit.c +- src/ugl/ugl_api.c +- src/ugl/ugl_dd.c +- src/ugl/ugl_glutshapes.c +- src/ugl/ugl_line.c +- src/ugl/ugl_span.c +- src/ugl/ugl_tri.c +- src/ugl/uglmesaP.h +- ugldemos/* + +Modified files in Tornado 2.0: +- c:\Tornado\host\x86-win32\bin\torVars.bat +rem Command line build environments +set WIND_HOST_TYPE=x86-win32 +set WIND_BASE=C:\Tornado +set MESA_BASE=C:\Mesa +set PATH=%WIND_BASE%\host\%WIND_HOST_TYPE%\bin;%PATH% +- c:\Tornado\target\config\comps\VxWorks\01uglmesa.cdf +- c:\Tornado\target\h\GL\* + +Todo +---- +- GCC 2.96, ASM compilation + +Thanks to: +---------- + +Precision Insight team for their great job around Mesa, XFree, and DRI. +Wind River Systems to take me as an intern. + + +Stephane Raimbault + + + +July 24, 2001 diff --git a/docs/README.X11 b/docs/README.X11 new file mode 100644 index 0000000..4cbd126 --- /dev/null +++ b/docs/README.X11 @@ -0,0 +1,314 @@ + + Mesa Unix/X11 Information + + + +Installation +============ + +There are two ways to compile Mesa on Unix/X11 systems: + +1. The old way: + First type 'make' alone to see the list of system + configurations currently supported. If you see your configuration on the + list, type 'make '. Most popular Unix/X workstations are currently + supported. + + If your system configuration is not listed by 'make', you'll have to modify + the top-level Makefile and Make-config files. There are instructions in + each file. + + When finished, the Mesa libraries will be in the Mesa-x.y/lib/ directory. + + +2. The new way: + Type './configure' and then 'make'. This uses GNU autoconfig. + Run 'make check' to build the demos. + See docs/INSTALL for more details. + When finished, the Mesa libraries will be in the Mesa-x.y/src/.libs/, + Mesa-x.y/si-glu/.libs, etc directories. + + +Notes on assembly language optimizations: + + When using the old-style Makefiles, you can specify a configuration + that uses X86 assembly language optimizations (linux-3dnow for example). + + The detection of MMX, 3DNow!, PIII/SSE, etc capability is done at + runtime. That means you can compile Mesa for 3DNow! optimizations + even if you don't have an AMD CPU. + + However, your Linux binutils and assembler must understand the + special instructions in order to compile them. If you have + compilation problems, try upgrading your binutils. + + +Header and library files: + After you've compiled Mesa and tried the demos I recommend the following + procedure for "installing" Mesa. + + Copy the Mesa include/GL directory to /usr/local/include: + cp -r include/GL /usr/local/include + + Copy the Mesa library files to /usr/local/lib: + cp lib/* /usr/local/lib + + (actually, use "cp -d" on Linux to preserve symbolic links) + + +Xt/Motif widgets: + If you want to use Mesa or OpenGL in your Xt/Motif program you can build + the widgets found in either the widgets-mesa or widgets-sgi directories. + The former were written for Mesa and the later are the original SGI + widgets. Look in those directories for more information. + + +Notes: + HP users: a Mesa user reports that the HP-UX 10.01 C compiler has + a bug which effects glReadPixels. A patch for the compiler (PHSS_5743) is + available. Otherwise be sure your compiler is version 10.13 or later. + + QNX users: if you have problems running the demos try setting the + stack size to 200K or larger with -N200K, for example. + + SunOS 5.x users: The X shared memory extension may not work + correctly. If Mesa prints an error message to the effect of "Shared memory + error" then you'll have to append the following three lines to the end of + your /etc/system file then reboot: + set shmsys:shminfo_shmmax = 0x2000000 + set shmsys:shminfo_shmmni = 0x1000 + set shmsys:shminfo_shmseg = 0x100 + + + +Using the library +================= + +Configuration options: + The file src/mesa/main/config.h has many parameters which you can adjust + such as maximum number of lights, clipping planes, maximum texture size, + etc. In particular, you may want to change DEPTH_BITS from 16 to 32 + if a 16-bit depth buffer isn't precise enough for your application. + + +Shared libraries: + If you compile shared libraries you may have to set an environment + variable to specify where the Mesa libraries are located. On Linux and + Sun systems for example, set the LD_LIBRARY_PATH variable to include + /your-dir/Mesa-2.6/lib. Otherwise, when you try to run a demo it + may fail with a message saying that one or more libraries couldn't be + found. + + +Remote display of OpenGL/GLX programs: + As of version 1.2.3, Mesa's header files use the same GLenum and GLUenum + values as SGI's (and most/all other vendor's) OpenGL headers. This means + you can freely mix object files compiled with OpenGL or Mesa headers. + In fact, on systems with dynamic runtime linkers it's possible to dynam- + ically link with Mesa or OpenGL shared libraries at runtime, without + recompiling or relinking anything! + + Using IRIX 5.x as an example, you can run SGI's OpenGL demos with the + Mesa shared libraries as follows. Let's assume you're installing Mesa + in /usr/local/Mesa and using the C-shell: + % cd /usr/local/Mesa + % make irix5-dso + % setenv _RLD_LIST "/usr/local/Mesa/lib/libGL.so:DEFAULT" + % /usr/demos/bin/ideas_ogl // this is a test + + You can now run OpenGL executables on almost any X display! There may + be some problems from the fact that Mesa supports many X visual types + that an OpenGL client may not expect (grayscale for example). In this + case the application may abort, print error messages, or just behave + strangely. You may have to experiment with the MESA_RGB_VISUAL envi- + ronment variable. + + +Xt/Motif Widgets: + Two versions of the Xt/Motif OpenGL drawing area widgets are included: + + widgets-sgi/ SGI's stock widgets + widgets-mesa/ Mesa-tuned widgets + + Look in those directories for details + + +Togl: + Togl is an OpenGL/Mesa widget for Tcl/Tk. + See http://togl.sourceforge.net for more information. + + + +X Display Modes: + Mesa supports RGB(A) rendering into almost any X visual type and depth. + + The glXChooseVisual function tries its best to pick an appropriate visual + for the given attribute list. However, if this doesn't suit your needs + you can force Mesa to use any X visual you want (any supported by your + X server that is) by setting the MESA_RGB_VISUAL and MESA_CI_VISUAL + environment variables. When an RGB visual is requested, glXChooseVisual + will first look if the MESA_RGB_VISUAL variable is defined. If so, it + will try to use the specified visual. Similarly, when a color index + visual is requested, glXChooseVisual will look for the MESA_CI_VISUAL + variable. + + The format of accepted values is: + Here are some examples: + + using the C-shell: + % setenv MESA_RGB_VISUAL "TrueColor 8" // 8-bit TrueColor + % setenv MESA_CI_VISUAL "PseudoColor 12" // 12-bit PseudoColor + % setenv MESA_RGB_VISUAL "PseudoColor 8" // 8-bit PseudoColor + + using the KornShell: + $ export MESA_RGB_VISUAL="TrueColor 8" + $ export MESA_CI_VISUAL="PseudoColor 12" + $ export MESA_RGB_VISUAL="PseudoColor 8" + + +Double buffering: + Mesa can use either an X Pixmap or XImage as the backbuffer when in + double buffer mode. Using GLX, the default is to use an XImage. The + MESA_BACK_BUFFER environment variable can override this. The valid + values for MESA_BACK_BUFFER are: Pixmap and XImage (only the first + letter is checked, case doesn't matter). + + A pixmap is faster when drawing simple lines and polygons while an + XImage is faster when Mesa has to do pixel-by-pixel rendering. If you + need depth buffering the XImage will almost surely be faster. Exper- + iment with the MESA_BACK_BUFFER variable to see which is faster for + your application. + + +Colormaps: + When using Mesa directly or with GLX, it's up to the application writer + to create a window with an appropriate colormap. The aux, tk, and GLUT + toolkits try to minimize colormap "flashing" by sharing colormaps when + possible. Specifically, if the visual and depth of the window matches + that of the root window, the root window's colormap will be shared by + the Mesa window. Otherwise, a new, private colormap will be allocated. + + When sharing the root colormap, Mesa may be unable to allocate the colors + it needs, resulting in poor color quality. This can happen when a + large number of colorcells in the root colormap are already allocated. + To prevent colormap sharing in aux, tk and GLUT, define the environment + variable MESA_PRIVATE_CMAP. The value isn't significant. + + +Gamma correction: + To compensate for the nonlinear relationship between pixel values + and displayed intensities, there is a gamma correction feature in + Mesa. Some systems, such as Silicon Graphics, support gamma + correction in hardware (man gamma) so you won't need to use Mesa's + gamma facility. Other systems, however, may need gamma adjustment + to produce images which look correct. If in the past you thought + Mesa's images were too dim, read on. + + Gamma correction is controlled with the MESA_GAMMA environment + variable. Its value is of the form "Gr Gg Gb" or just "G" where + Gr is the red gamma value, Gg is the green gamma value, Gb is the + blue gamma value and G is one gamma value to use for all three + channels. Each value is a positive real number typically in the + range 1.0 to 2.5. The defaults are all 1.0, effectively disabling + gamma correction. Examples using csh: + + % setenv MESA_GAMMA "2.3 2.2 2.4" // separate R,G,B values + % setenv MESA_GAMMA "2.0" // same gamma for R,G,B + + The demos/gamma.c program may help you to determine reasonable gamma + value for your display. With correct gamma values, the color intensities + displayed in the top row (drawn by dithering) should nearly match those + in the bottom row (drawn as grays). + + Alex De Bruyn reports that gamma values of 1.6, 1.6 and 1.9 work well + on HP displays using the HP-ColorRecovery technology. + + Mesa implements gamma correction with a lookup table which translates + a "linear" pixel value to a gamma-corrected pixel value. There is a + small performance penalty. Gamma correction only works in RGB mode. + Also be aware that pixel values read back from the frame buffer will + not be "un-corrected" so glReadPixels may not return the same data + drawn with glDrawPixels. + + For more information about gamma correction see: + http://www.inforamp.net/~poynton/notes/colour_and_gamma/GammaFAQ.html + + +Overlay Planes + + Overlay planes in the frame buffer are supported by Mesa but require + hardware and X server support. To determine if your X server has + overlay support you can test for the SERVER_OVERLAY_VISUALS property: + + xprop -root | grep SERVER_OVERLAY_VISUALS + + +HPCR glClear(GL_COLOR_BUFFER_BIT) dithering + + If you set the MESA_HPCR_CLEAR environment variable then dithering + will be used when clearing the color buffer. This is only applicable + to HP systems with the HPCR (Color Recovery) system. + + +Extensions +========== + There are three Mesa-specific GLX extensions at this time. + + GLX_MESA_pixmap_colormap + + This extension adds the GLX function: + + GLXPixmap glXCreateGLXPixmapMESA( Display *dpy, XVisualInfo *visual, + Pixmap pixmap, Colormap cmap ) + + It is an alternative to the standard glXCreateGLXPixmap() function. + Since Mesa supports RGB rendering into any X visual, not just True- + Color or DirectColor, Mesa needs colormap information to convert RGB + values into pixel values. An X window carries this information but a + pixmap does not. This function associates a colormap to a GLX pixmap. + See the xdemos/glxpixmap.c file for an example of how to use this + extension. + + GLX_MESA_release_buffers + + Mesa associates a set of ancillary (depth, accumulation, stencil and + alpha) buffers with each X window it draws into. These ancillary + buffers are allocated for each X window the first time the X window + is passed to glXMakeCurrent(). Mesa, however, can't detect when an + X window has been destroyed in order to free the ancillary buffers. + + The best it can do is to check for recently destroyed windows whenever + the client calls the glXCreateContext() or glXDestroyContext() + functions. This may not be sufficient in all situations though. + + The GLX_MESA_release_buffers extension allows a client to explicitly + deallocate the ancillary buffers by calling glxReleaseBuffersMESA() + just before an X window is destroyed. For example: + + #ifdef GLX_MESA_release_buffers + glXReleaseBuffersMESA( dpy, window ); + #endif + XDestroyWindow( dpy, window ); + + This extension is new in Mesa 2.0. + + GLX_MESA_copy_sub_buffer + + This extension adds the glXCopySubBufferMESA() function. It works + like glXSwapBuffers() but only copies a sub-region of the window + instead of the whole window. + + This extension is new in Mesa version 2.6 + + + +Summary of X-related environment variables: + MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only) + MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only) + MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only) + MESA_PRIVATE_CMAP - force aux/tk libraries to use private colormaps (X only) + MESA_GAMMA - gamma correction coefficients (X only) + + +---------------------------------------------------------------------- +$Id: README.X11,v 3.11 2003/12/17 15:14:31 brianp Exp $ diff --git a/docs/RELNOTES-3.1 b/docs/RELNOTES-3.1 new file mode 100644 index 0000000..4d6e3c2 --- /dev/null +++ b/docs/RELNOTES-3.1 @@ -0,0 +1,146 @@ + + Mesa 3.1 release notes + + PLEASE READ!!!! + + +New copyright +------------- + +Mesa 3.1 will be distributed under an XFree86-style copyright instead +of the GNU LGPL. + + +New directories +--------------- + +All documentation files are now in the docs/ directory. +All shell scripts are now in the bin/ directory. + + +New library names +----------------- + +Formerly, the main Mesa library was named libMesaGL.so (or libMesaGL.a) +and the GLU library was named libMesaGLU.so (or libMesaGLU.a). + +Now, the main library is named libGL.so (or libGL.a) and the GLU library +is named libGLU.so (or libGLU.a). + +The change allows Mesa to be more easily substituted for OpenGL. +Specifically, the linker/loader on some Unix-like systems won't +allow libMesaGL.so to be used instead of libGL.so if the application +was linked with the former. + +Warning: if you have another OpenGL implementation installed on your +system (i.e. you have another OpenGL libGL.so) you'll have to be +carefull about which library (OpenGL or Mesa) you link against. Be +aware of -L linker flags and the value of the LD_LIBRARY_PATH environment +variable. + + +New library versioning +---------------------- + +Previously, the Mesa GL library was named libMesaGL.so.3.0 +To better support Linux/OpenGL standards, the Mesa GL library is now +named libGL.so.1.2.030100 This indicates version 1.2 of the OpenGL spec +and Mesa implementation 3.1.0 + +In the long term this will allow better interoperability with other +OpenGL implementations, especially on Linux. In the short term, +OpenGL apps may have to be relinked to use the new library naming. + + + +New makefiles +------------- + +The old Makefiles found in the various directories have been renamed +to Makefile.X11 in order to prevent filename collisions with autoconfig- +generated Makefiles. + +The top-level Makefile simply includes Makefile.X11 +If your top-level Makefile get's overwritten/destroyed you can restore +it by copying Makefile.X11 to Makefile + + +New extensions +-------------- + +GL_EXT_stencil_wrap + Implements two new stencil operations: GL_INCR_WRAP_EXT and + GL_DECR_WRAP_EXT which allow stencil increment and decrement + without clamping. + +GL_INGR_blend_func_separate + Allows specification of blend factors for RGB and Alpha independently. + (INGR = Intergraph) + +GL_ARB_multitexture + Multiple simultaneous textures. (ARB = Architecture Review Board) + +GL_NV_texgen_reflection + nVidia texgen extension for better reflection mapping. + +GL_PGI_misc_hints + Assorted transformation hints. + +GL_EXT_compiled_vertex_array + Compiled vertex arrays. + +GL_EXT_clip_volume_hint + Allows one to disable clip volume (frustum) testing. + + + +Extensions removed +------------------ + +GL_EXT_multitexture - obsolete in favor of GL_ARB_multitexture + + + +Config file +----------- + +By default, /etc/mesa.conf will be read when Mesa starts. This +file controls default hints, enable/disable of extensions, and +more. See the CONFIG file for documentation. + + + +Optimizations +------------- + +Keith Whitwell has contributed significant optimizations to Mesa's +vertex transformation code. Basically, the whole transformation +stage of Mesa has been rewritten. + +It's impossible to give a speedup factor. You'll just have to +try your app and see how it performs. + + + +Device Driver changes +--------------------- + +A bunch of new device driver functions have been added. See src/dd.h +Keith Harrison contributed many of them. I've been planning on adding +a bunch of functions like these to make writing hardware drivers easier. +More such function will probably be added in the near future. + + + +Miscellaneous +------------- + +util/glstate.c has some handy functions for debugging. Basically, it +offers a simple function for printing GL state variables. It's not +finished yet. There's a LOT more GLenum records to be added (see the +code). Anyone want to help? + + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.1,v 1.2 2000/04/07 17:08:06 brianp Exp $ diff --git a/docs/RELNOTES-3.2 b/docs/RELNOTES-3.2 new file mode 100644 index 0000000..7737c28 --- /dev/null +++ b/docs/RELNOTES-3.2 @@ -0,0 +1,12 @@ + + Mesa 3.2 release notes + + PLEASE READ!!!! + + +Mesa 3.2 is a stabilization of the Mesa 3.1 release. No new features +have been added. For a list of bug fixes please read the VERSIONS file. + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.2,v 1.2 2000/04/07 17:08:06 brianp Exp $ diff --git a/docs/RELNOTES-3.2.1 b/docs/RELNOTES-3.2.1 new file mode 100644 index 0000000..2ad5b90 --- /dev/null +++ b/docs/RELNOTES-3.2.1 @@ -0,0 +1,32 @@ + + Mesa 3.2.1 release notes + + PLEASE READ!!!! + + + +The Mesa 3.2.1 release mainly just fixes bugs since the 3.2 release. +See the VERSIONS file for the exact list. + + + +GLU Polygon Tessellator +----------------------- + +The GLU tessellator has been reverted back to the version included +with Mesa 3.0 since it's more stable. The Mesa 3.1/3.2 tessellator +implemented the GLU 1.3 specification but suffered from a number of +bugs. + +Mesa implements GLU 1.1. + +Ideally, people should use the GLU 1.3 library included in SGI's +OpenGL Sample Implementation (SI) available from +http://oss.sgi.com/projects/ogl-sample/ +People are working to make easy-to-install Linux RPMs of the +GLU library. + + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.2.1,v 1.2 2000/07/21 16:32:33 brianp Exp $ diff --git a/docs/RELNOTES-3.3 b/docs/RELNOTES-3.3 new file mode 100644 index 0000000..362a74e --- /dev/null +++ b/docs/RELNOTES-3.3 @@ -0,0 +1,271 @@ + + Mesa 3.3 release notes + + July 21, 2000 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.2.1) designate stable releases. + +Mesa 3.3 has a undergone many internal changes since version 3.2 +and features a lot of new extensions. 3.3 is expected to be pretty +stable, but perhaps not as stable as 3.2 which has been used by +thousands of users over the past months. + +Everyone is encouraged to try Mesa 3.3. Bugs should be reported to +the Mesa bug database on www.sourceforge.net. + + + +Header file / GLenum changes +---------------------------- + +The gl.h and glu.h headers now use #defines to define all GL_* tokens +instead of C-language enums. This change improves Mesa/OpenGL +interoperability. + + + +New API dispatch code +--------------------- + +The core Mesa gl* functions are now implemented with a new dispatch +(jump table) which will allow simultaneous direct/indirect rendering. + +The code is found in the glapi*.[ch] files. + +Of interest: the actual "glFooBar" functions are generated with +templatized code defined in glapitemp.h and included by glapi.c +The glapitemp.h template should be reusable for all sorts of OpenGL +projects. + +The new dispatch code has also optimized with x86 assembly code. +This optimization eliminates copying the function arguments during +dispatch. + + + +New thread support +------------------ + +Thread support in Mesa has been rewritten. The glthread.[ch] files +replace mthreads.[ch]. Thread safety is always enabled (on platforms +which support threads, that is). There is virtually no performance +penalty for typical single-thread applications. See the glapi.c +file for details. + +The Xlib driver (XMesa) is now thread-safe as well. Be sure to +call XInitThreads() in your app first. See the xdemos/glthreads.c +demo for an example. + + + +Make configuration changes +-------------------------- + +If you use the old-style (non GNU automake) method to build Mesa note +that several of the configuration names have changed: + + Old name New name + ------------- ---------------- + linux-elf linux + linux linux-static + linux-386-elf linux-386 + linux-386 linux-386-static + etc. + + + +New extensions +-------------- + +GL_ARB_transpose_matrix + Adds glLoadTransposeMatrixARB() and glMultTransposeMatrixARB() + functions. + +GL_ARB_texture_cube_map + For cube-based reflection mapping. + +GL_EXT_texture_add_env + Adds GL_ADD texture environment mode. + See http://www.berkelium.com/OpenGL/EXT/texture_env_add.txt + +GL_EXT_texture_lod_bias + Allows mipmapped texture blurring and sharpening. + +GLX_EXT_visual_rating extension + This extension has no effect in stand-alone Mesa (used for DRI). + +GL_HP_occlusion_test + Used for bounding box occlusion testing (see demos/occlude.c). + +GL_SGIX_pixel_texture / GL_SGIS_pixel_texture + Lets glDraw/CopyPixels draw a texture coordinate image. + +GL_SGI_color_matrix + Adds a color matrix and another set of scale and bias parameters + to the glDraw/CopyPixels paths. + +GL_SGI_color_table + Adds additional color tables to the glDraw/Read/CopyPixels paths. + +GL_EXT_histogram + Compute histograms for glDraw/Read/CopyPixels. + +GL_EXT_blend_func_separate + This is the same as GL_INGR_blend_func_separate. + +GL_ARB_texture_cube_mapping + 6-face cube mapping, nicer than sphere mapping + +GL_EXT_texture_env_combine + For advanced texture environment effects. + + +Documentation for all these functions can be found at +http://oss.sgi.com/projects/ogl-sample/registry/ + + + +GLX_SGI_make_current_read functionality +--------------------------------------- + +The functionality of this extension is needed for GLX 1.3 (and required +for the Linux/OpenGL standards base). + +Implementing this function required a **DEVICE DRIVER CHANGE**. +The old SetBuffer() function has been replaced by SetReadBuffer() and +SetDrawBuffer(). All device drivers will have to be updated because +of this change. + +The new function, glXMakeContextCurrent(), in GLX 1.3 now works in Mesa. +The xdemos/wincopy.c program demonstrates it. + + + +Image-related code changes +-------------------------- + +The imaging path code used by glDrawPixels, glTexImage[123]D, +glTexSubImage[123], etc has been rewritten. It's now faster, +uses less memory and has several bug fixes. This work was +actually started in Mesa 3.1 with the glTexImage paths but has now +been carried over to glDrawPixels as well. + + + +Device driver interface changes +------------------------------- + +Added new functions for hardware stencil buffer support: + WriteStencilSpan + ReadStencilSpan + WriteStencilPixels + ReadStencilPixels + + +Removed old depth buffer functions: + AllocDepthBuffer + DepthTestSpan + DepthTestPixels + ReadDepthSpanFloat + ReadDepthSpanInt + + +Added new depth buffer functions: + WriteDepthSpan + ReadDepthSpan + WriteDepthPixels + ReadDepthPixels + + These functions always read/write 32-bit GLuints. This will allow + drivers to have anywhere from 0 to 32-bit Z buffers without + recompiling for 16 vs 32 bits as was previously needed. + + +New texture image functions + The entire interface for texture image specification has been updated. + With the new functions, it's optional for Mesa to keep an internal copy + of all textures. Texture download should be a lot faster when the extra + copy isn't made. + +Misc changes + TexEnv now takes a target argument + Removed UseGlobalTexturePalette (use Enable function instead) + + +Also added + ReadPixels + CopyPixels + + +The SetBufffer function has been replaced by SetDrawBuffer and +SetReadBuffer functions. This lets core Mesa independently +specify which buffer is to be used for reading and which for +drawing. + +The Clear function's mask parameter has changed. Instead of +mask being the flags specified by the user to glClear, the +mask is now a bitmask of the DD_*_BIT flags in dd.h. Now +multiple color buffers can be specified for clearing (ala +glDrawBuffers). The driver's Clear function must also +check the glColorMask glIndexMask, and glStencilMask settings +and do the right thing. See the X/Mesa, OS/Mesa, or FX/Mesa +drivers for examples. + + +The depth buffer changes shouldn't be hard to make for existing +drivers. In fact, it should simply the code. Be careful with +the depthBits value passed to gl_create_context(). 1 is a bad +value! It should normally be 0, 16, 24, or 32. + + +gl_create_framebuffer() takes new arguments which explicitly tell +core Mesa which ancillary buffers (depth, stencil, accum, alpha) +should be implemented in software. Mesa hardware drivers should +carefully set these flags depending on which buffers are in the +graphics card. + + + +Internal constants +------------------ + +Point and line size range and granularity limits are now stored +in the gl_constants struct, which is the Const member of GLcontext. +The limits are initialized from values in config.h but may be +overridden by device drivers to reflect the limits of that driver's +hardware. + +Also added constants for NumAuxBuffers and SubPixelBits. + + + +OpenGL Conformance +------------------ + +Mesa now passes all the OpenGL 1.1 conformance tests, except for +antialiased lines. AA lines fail on some, but not all, the tests. +In order to fix the remaining failures, a new AA line algorithm will +be needed (which computes coverage values for end-point fragments). +This will be done for Mesa 3.5/3.6. + + + +OpenGL 1.2 GL_ARB_imaging subset +-------------------------------- + +Mesa 3.3 implements all the features of GL_ARB_imaging except for +image convolution. This will (hopefully) be done for Mesa 3.5/3.6. + + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.3,v 1.8 2000/07/21 16:26:41 brianp Exp $ diff --git a/docs/RELNOTES-3.4 b/docs/RELNOTES-3.4 new file mode 100644 index 0000000..4aa607a --- /dev/null +++ b/docs/RELNOTES-3.4 @@ -0,0 +1,22 @@ + + Mesa 3.4 release notes + + November 3, 2000 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa 3.4 simply fixes bugs found in the Mesa 3.3 release. For details, +see the VERSIONS file. + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.4,v 1.2 2002/03/23 02:37:17 brianp Exp $ diff --git a/docs/RELNOTES-3.4.1 b/docs/RELNOTES-3.4.1 new file mode 100644 index 0000000..1844350 --- /dev/null +++ b/docs/RELNOTES-3.4.1 @@ -0,0 +1,22 @@ + + Mesa 3.4.1 release notes + + February 9, 2001 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa 3.4.1 is a maintenance release that simply fixes bugs found since +the Mesa 3.4 release. For details, see the VERSIONS file. + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.4.1,v 1.2 2001/05/23 14:45:01 brianp Exp $ diff --git a/docs/RELNOTES-3.4.2 b/docs/RELNOTES-3.4.2 new file mode 100644 index 0000000..894ed19 --- /dev/null +++ b/docs/RELNOTES-3.4.2 @@ -0,0 +1,22 @@ + + Mesa 3.4.2 release notes + + May 17, 2001 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa 3.4.2 is a maintenance release that simply fixes bugs found since +the Mesa 3.4.1 release. For details, see the VERSIONS file. + + +---------------------------------------------------------------------- +$Id: RELNOTES-3.4.2,v 1.2 2001/05/23 14:45:01 brianp Exp $ diff --git a/docs/RELNOTES-3.5 b/docs/RELNOTES-3.5 new file mode 100644 index 0000000..52097a1 --- /dev/null +++ b/docs/RELNOTES-3.5 @@ -0,0 +1,228 @@ + + Mesa 3.5 release notes + + June 21, 2001 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.5) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +The biggest change in Mesa 3.5 is a complete overhaul of the source +code in order to make it more modular. This was driven by the DRI +hardware drivers. It simplifies the DRI drivers and opens the door +to hardware transform/clip/lighting (TCL). Keith Whitwell can take +the credit for that. + + + +Driver Support +-------------- + +The device driver interface in Mesa 3.5 has changed a lot since Mesa 3.4 +Not all of the older Mesa drivers have been updated. Here's the status: + +Driver Status +---------------------- ----------- +XMesa (Xlib) updated +OSMesa (off-screen) updated +FX (3dfx Voodoo1/2) updated +SVGA updated +GGI not updated +Windows/Win32 not updated +DOS/DJGPP not updated +BeOS not updated +Allegro not updated +D3D not updated +DOS not updated + +We're looking for volunteers to update the remaining drivers. Please +post to the Mesa3d-dev mailing list if you can help. + + + +GLU 1.3 +------- + +Mesa 3.5 includes the SGI Sample Implementation (SI) GLU library. +This version of GLU supports the GLU 1.3 specification. The old +Mesa GLU library implemented the 1.1 specification. The SI GLU +library should work much better. + +You'll need a C++ compiler to compile the SI GLU library. This may +be a problem on some systems. + + + +New Extensions +-------------- + +GL_EXT_convolution + Adds image convolution to glRead/Copy/DrawPixels/TexImage. + +GL_ARB_imaging + This is the optional imaging subset of OpenGL 1.2. + It's the GL_EXT_convolution, GL_HP_convolution_border_modes, + GL_EXT_histogram, GL_EXT_color_table, GL_EXT_color_subtable + GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract + and GL_SGI_color_matrix extensions all rolled together. + This is supported in all software renderers but not in all + hardware drivers (3dfx for example). + +GL_ARB_texture_compression + This is supported in Mesa but only used by the 3dfx DRI drivers + for Voodoo4 and later. + +GL_ARB_texture_env_add + This is identical to GL_EXT_texture_env_add. + +GL_NV_blend_square + Adds extra blend source and dest factors which allow squaring + of color values. + +GL_EXT_fog_coord + Allows specification of a per-vertex fog coordinate instead of + having fog always computed from the eye distance. + +GL_EXT_secondary_color + Allows specifying the secondary (specular) color for each vertex + instead of getting it only from lighting in GL_SEPARATE_SPECULAR_COLOR + mode. + +GL_ARB_texture_env_combine + Basically the same as GL_EXT_texture_env_combine + +GL_ARB_texture_env_add extension + Texture addition mode. + +GL_ARB_texture_env_dot3 extension + Dot product texture environment. + +GL_ARB_texture_border_clamp + Adds GL_CLAMP_TO_BORDER_ARB texture wrap mode + +GL_SGIX_depth_texture, GL_SGIX_shadow and GL_SGIX_shadow_ambient + Implements a shadow casting algorithm based on depth map textures + +GL_SGIS_generate_mipmap + Automatically generate lower mipmap images whenever the base mipmap + image is changed with glTexImage, glCopyTexImage, etc. + + + +libOSMesa.so +------------ + +libOSMesa.so is a new library which contains the OSMesa interface for +off-screen rendering. Apps which need the OSMesa interface should link +with both -lOSMesa and -lGL. This change was made so that stand-alone +Mesa works the same way as XFree86/DRI's libGL. + + + +Device Driver Changes / Core Mesa Changes +----------------------------------------- + +The ctx->Driver.LogicOp() function has been removed. It used to +be called during state update in order to determine if the driver +could do glLogicOp() operations, and if not, set the SWLogicOpEnabled +flag. Drivers should instead examine the LogicOp state themselves +and choose specialized point, line, and triangle functions appropriately, +or fall back to software rendering. The Xlib driver was the only driver +to use this function. And since the Xlib driver no longer draws +points, lines or triangles using Xlib, the LogicOp function isn't needed. + +The ctx->Driver.Dither() function has been removed. Drivers should +detect dither enable/disable via ctx->Driver.Enable() instead. + +The ctx->Driver.IndexMask() and ctx->Driver.ColorMask() functions +are now just called from glIndexMask and glColorMask like the other +GL state-changing functions. They are no longer called from inside +gl_update_state(). Also, they now return void. The change was made +mostly for sake of uniformity. + +The NEW_DRVSTATE[0123] flags have been removed. They weren't being used +and are obsolete w.r.t. the way state updates are done in DRI drivers. + + +Removed obsolete gl_create_visual() and gl_destroy_visual(). + +Renamed functions (new namespace): + +old new +gl_create_framebuffer _mesa_create_framebuffer +gl_destroy_framebuffer _mesa_destroy_framebuffer +gl_create_context _mesa_create_context +gl_destroy_context _mesa_destroy_context +gl_context_initialize _mesa_context_initialize +gl_copy_context _mesa_copy_context +gl_make_current _mesa_make_current +gl_make_current2 _mesa_make_current2 +gl_get_current_context _mesa_get_current_context +gl_flush_vb _mesa_flush_vb +gl_warning _mesa_warning +gl_compile_error _mesa_compile_error + + +All the drivers have been updated, but not all of them have been +tested since I can't test some platforms (DOS, Windows, Allegro, etc). + + +X/Mesa Driver +------------- + +The source files for the X/Mesa driver in src/X have been renamed. +The xmesa[1234].c files are gone. The new files are xm_api.c, +xm_dd.c, xm_line.c, xm_span.c and xm_tri.c. + + + +Multitexture +------------ + +Eight texture units are now supported by default. + + + +OpenGL SI related changes +------------------------- + +In an effort to make Mesa's internal interfaces more like the OpenGL +SI interfaces, a number of changes have been made: + +1. Importing the SI's glcore.h file which defines a number of +interface structures like __GLimports and __GLexports. + +2. Renamed "struct gl_context" to "struct __GLcontextRec". + +3. Added __glCoreCreateContext() and __glCoreNopDispatch() functions. + +4. The GLcontext member Visual is no longer a pointer. + +5. New file: imports.c to setup default import functions for Mesa. + + + + +16-bit color channels +--------------------- + +There's experimental support for 16-bit color channels (64-bit pixels) +in Mesa 3.5. Only the OSMesa interface can be used for 16-bit rendering. +Type "make linux-osmesa16" in the top-level directory to build the +special libOSMesa16.so library. + +This hasn't been tested very thoroughly yet so please file bug reports +if you have trouble. + +In the future I hope to implement support for 32-bit, floating point +color channels. + +---------------------------------------------------------------------- +$Id: RELNOTES-3.5,v 1.14 2001/06/20 19:02:48 brianp Exp $ diff --git a/docs/RELNOTES-4.0 b/docs/RELNOTES-4.0 new file mode 100644 index 0000000..e4249cf --- /dev/null +++ b/docs/RELNOTES-4.0 @@ -0,0 +1,163 @@ + + Mesa 4.0 release notes + + October 18, 2001 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa version 4.0 signifies two things: + + 1. A stabilization of the 3.5 development release + 2. Implementation of the OpenGL 1.3 specification + + +Note that the Mesa major version number is incremented with the OpenGL +minor version number: + + Mesa 1.x == OpenGL 1.0 + Mesa 2.x == OpenGL 1.1 + Mesa 3.x == OpenGL 1.2 + Mesa 4.x == OpenGL 1.3 + + + +New Features +------------ + +Mesa 3.5 already had all the new features of OpenGL 1.3, implemented as +extensions. These extensions were simply promoted to standard features: + + GL_ARB_multisample + GL_ARB_multitexture + GL_ARB_texture_border_clamp + GL_ARB_texture_compression + GL_ARB_texture_cube_map + GL_ARB_texture_env_add + GL_ARB_texture_env_combine + GL_ARB_texture_env_dot3 + GL_ARB_transpose_matrix + +In Mesa 4.0 the functions defined by these extensions are now available +without the "ARB" suffix. For example, glLoadTransposeMatrixf() is now +a standard API function. The new functions in OpenGL 1.3 and Mesa 4.0 are: + + glActiveTexture + glClientActiveTexture + glCompressedTexImage1D + glCompressedTexImage2D + glCompressedTexImage3D + glCompressedTexSubImage1D + glCompressedTexSubImage2D + glCompressedTexSubImage3D + glGetCompressedTexImage + glLoadTransposeMatrixd + glLoadTransposeMatrixf + glMultiTexCoord1d + glMultiTexCoord1dv + glMultiTexCoord1f + glMultiTexCoord1fv + glMultiTexCoord1i + glMultiTexCoord1iv + glMultiTexCoord1s + glMultiTexCoord1sv + glMultiTexCoord2d + glMultiTexCoord2dv + glMultiTexCoord2f + glMultiTexCoord2fv + glMultiTexCoord2i + glMultiTexCoord2iv + glMultiTexCoord2s + glMultiTexCoord2sv + glMultiTexCoord3d + glMultiTexCoord3dv + glMultiTexCoord3f + glMultiTexCoord3fv + glMultiTexCoord3i + glMultiTexCoord3iv + glMultiTexCoord3s + glMultiTexCoord3sv + glMultiTexCoord4d + glMultiTexCoord4dv + glMultiTexCoord4f + glMultiTexCoord4fv + glMultiTexCoord4i + glMultiTexCoord4iv + glMultiTexCoord4s + glMultiTexCoord4sv + glMultTransposeMatrixd + glMultTransposeMatrixf + glSampleCoverage + glSamplePass + + +GLX 1.4 is the companion to OpenGL 1.3. The only new features in GLX 1.4 +are support for multisampling and the GLX_ARB_get_proc_address extension. +glXGetProcAddress() is the only new function in GLX 1.4. + + + +Multisample and Texture Compression +----------------------------------- + +The OpenGL 1.3 specification allows the multisample and texture compression +features to essentially be no-ops. For example, if you query for multisample +support you'll find none, but the API functions work. + +Similarly, texture compression is not implemented by any of the software +drivers but you can specify a generic compressed texture format (like +GL_COMPRESSED_RGBA) to glTexImage2D and it'll be accepted. + + + +Device Drivers +-------------- + +Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on the +device driver. If the driver enables all the ARB extensions which are part +of OpenGL 1.3 then glGetString(GL_VERSION) will return "1.3". Otherwise, +it'll return "1.2". + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of the drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.3 +OSMesa (off-screen) implements OpenGL 1.3 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.3 +GGI needs updating +DOS/DJGPP needs updating +BeOS needs updating +Allegro needs updating +D3D needs updating +DOS needs updating + +Special thanks go to Karl Schultz for updating the Windows driver. + +The XFree86/DRI drivers have not yet been updated to use Mesa 4.0 as of +September 2001, but that should happen eventually. + + + +Other Changes +------------- + +See the VERSIONS file for more details about bug fixes, etc. in Mesa 4.0. + + +---------------------------------------------------------------------- +$Id: RELNOTES-4.0,v 3.2 2001/10/17 14:59:21 brianp Exp $ diff --git a/docs/RELNOTES-4.0.1 b/docs/RELNOTES-4.0.1 new file mode 100644 index 0000000..b4d7efc --- /dev/null +++ b/docs/RELNOTES-4.0.1 @@ -0,0 +1,22 @@ + + Mesa 4.0.1 release notes + + December 17, 2001 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa 4.0.1 only contains bug fixes since version 4.0. + +See the docs/VERSIONS file for the list of bug fixes. + +---------------------------------------------------------------------- +$Id: RELNOTES-4.0.1,v 1.2 2001/12/18 14:08:23 brianp Exp $ diff --git a/docs/RELNOTES-4.0.2 b/docs/RELNOTES-4.0.2 new file mode 100644 index 0000000..1b7eaaa --- /dev/null +++ b/docs/RELNOTES-4.0.2 @@ -0,0 +1,50 @@ + + Mesa 4.0.2 release notes + + March 25, 2002 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa 4.0.2 only contains bug fixes and a new DOS driver since version 4.0.1. + +See the docs/VERSIONS file for the list of bug fixes. + + +Device Drivers +-------------- + +Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on the +device driver. If the driver enables all the ARB extensions which are part +of OpenGL 1.3 then glGetString(GL_VERSION) will return "1.3". Otherwise, +it'll return "1.2". + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of the drivers. +Here's the current status of all included drivers: + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.3 +OSMesa (off-screen) implements OpenGL 1.3 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.3 +DOS/DJGPP implements OpenGL 1.3 (new in Mesa 4.0.2) +GGI needs updating +BeOS needs updating +Allegro needs updating +D3D needs updating + + +---------------------------------------------------------------------- +$Id: RELNOTES-4.0.2,v 1.2 2002/03/23 02:38:39 brianp Exp $ diff --git a/docs/RELNOTES-4.0.3 b/docs/RELNOTES-4.0.3 new file mode 100644 index 0000000..c69b6a2 --- /dev/null +++ b/docs/RELNOTES-4.0.3 @@ -0,0 +1,52 @@ + + Mesa 4.0.3 release notes + + June 25, 2002 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 3.3) designate new developmental releases. +Even numbered versions (such as 3.4) designate stable releases. + +Mesa 4.0.3 basically just contains bug fixes version 4.0.2. + +See the docs/VERSIONS file for the list of bug fixes. + +The GGI driver has been updated, thanks to Filip Spacek. + + +Device Drivers +-------------- + +Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on the +device driver. If the driver enables all the ARB extensions which are part +of OpenGL 1.3 then glGetString(GL_VERSION) will return "1.3". Otherwise, +it'll return "1.2". + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of the drivers. +Here's the current status of all included drivers: + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.3 +OSMesa (off-screen) implements OpenGL 1.3 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.3 +DOS/DJGPP implements OpenGL 1.3 (new in Mesa 4.0.2) +GGI implements OpenGL 1.3 +BeOS needs updating +Allegro needs updating +D3D needs updating + + +---------------------------------------------------------------------- +$Id: RELNOTES-4.0.3,v 1.2 2002/06/26 02:36:34 brianp Exp $ diff --git a/docs/RELNOTES-4.1 b/docs/RELNOTES-4.1 new file mode 100644 index 0000000..92cf919 --- /dev/null +++ b/docs/RELNOTES-4.1 @@ -0,0 +1,308 @@ + + Mesa 4.1 release notes + + October 29, 2002 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Even numbered versions (such as 4.0) designate stable releases. +Odd numbered versions (such as 4.1) designate new developmental releases. + + +New Features in Mesa 4.1 +------------------------ + +New extensions. Docs at http://oss.sgi.com/projects/ogl-sample/registry/ + +GL_NV_vertex_program + + NVIDIA's vertex programming extension + +GL_NV_vertex_program1_1 + + A few features built on top of GL_NV_vertex_program + +GL_ARB_window_pos + + This is the ARB-approved version of GL_MESA_window_pos + +GL_ARB_depth_texture + + This is the ARB-approved version of GL_SGIX_depth_texture. + It allows depth (Z buffer) data to be stored in textures. + This is used by GL_ARB_shadow + +GL_ARB_shadow + + Shadow mapping with depth textures. + This is the ARB-approved version of GL_SGIX_shadow. + +GL_ARB_shadow_ambient + + Allows one to specify the luminance of shadowed pixels. + This is the ARB-approved version of GL_SGIX_shadow_ambient. + +GL_EXT_shadow_funcs + + Extends the set of GL_ARB_shadow texture comparision functions to + include all eight of standard OpenGL dept-test functions. + +GL_ARB_point_parameters + + This is basically the same as GL_EXT_point_parameters. + +GL_ARB_texture_env_crossbar + + Allows any texture combine stage to reference any texture source unit. + +GL_NV_point_sprite + + For rendering points as textured quads. Useful for particle effects. + +GL_NV_texture_rectangle (new in 4.0.4 actually) + + Allows one to use textures with sizes that are not powers of two. + Note that mipmapping and several texture wrap modes are not allowed. + +GL_EXT_multi_draw_arrays + + Allows arrays of vertex arrays to be rendered with one call. + +GL_EXT_stencil_two_side + + Separate stencil modes for front and back-facing polygons. + +GLX_SGIX_fbconfig & GLX_SGIX_pbuffer + + Off-screen rendering support. + +GL_ATI_texture_mirror_once + + Adds two new texture wrap modes: GL_MIRROR_CLAMP_ATI and + GL_MIRROR_CLAMP_TO_EDGE_ATI. + + + +Device Driver Status +-------------------- + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of these drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.3 +OSMesa (off-screen) implements OpenGL 1.3 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.3 +DOS/DJGPP implements OpenGL 1.3 +GGI implements OpenGL 1.3 +BeOS needs updating (underway) +Allegro needs updating +D3D needs updating +DOS needs updating + + + +New features in GLUT +-------------------- + +1. Frames per second printing + + GLUT now looks for an environment variable called "GLUT_FPS". If it's + set, GLUT will print out a frames/second statistic to stderr when + glutSwapBuffers() is called. By default, frames/second is computed + and displayed once every 5 seconds. You can specify a different + interval (in milliseconds) when you set the env var. For example + 'export GLUT_FPS=1000' or 'setenv GLUT_FPS 1000' will set the interval + to one second. + + NOTE: the demo or application must call the glutInit() function for + this to work. Otherwise, the env var will be ignored. + + Finally, this feature may not be reliable in multi-window programs. + + +2. glutGetProcAddress() function + + The new function: + + void *glutGetProcAddress(const char *procName) + + is a wrapper for glXGetProcAddressARB() and wglGetProcAddress(). It + lets you dynamically get the address of an OpenGL function at runtime. + The GLUT_API_VERSION has been bumped to 5, but I haven't bumped the + GLUT version number from 3.7 since that's probably Mark Kilgard's role. + + This function should probably also be able to return the address of + GLUT functions themselves, but it doesn't do that yet. + + + +XXX Things To Do Yet XXXX +------------------------- + +isosurf with vertex program exhibits some missing triangles (probably +when recycling the vertex buffer for long prims). + + + +Porting Info +------------ + +If you're porting a DRI or other driver from Mesa 4.0.x to Mesa 4.1 here +are some things to change: + +1. ctx->Texture._ReallyEnabled is obsolete. + + Since there are now 5 texture targets (1D, 2D, 3D, cube and rect) that + left room for only 6 units (6*5 < 32) in this field. + This field is being replaced by ctx->Texture._EnabledUnits which has one + bit per texture unit. If the bit k of _EnabledUnits is set, that means + ctx->Texture.Unit[k]._ReallyEnabled is non-zero. You'll have to look at + ctx->Texture.Unit[k]._ReallyEnabled to learn if the 1D, 2D, 3D, cube or + rect texture is enabled for unit k. + + This also means that the constants TEXTURE1_*, TEXTURE2_*, etc are + obsolete. + + The tokens TEXTURE0_* have been replaced as well (since there's no + significance to the "0" part: + + old token new token + TEXTURE0_1D TEXTURE_1D_BIT + TEXTURE0_2D TEXTURE_2D_BIT + TEXTURE0_3D TEXTURE_3D_BIT + TEXTURE0_CUBE TEXTURE_CUBE_BIT + TEXTURE_RECT_BIT + + These tokens are only used for the ctx->Texture.Unit[i].Enabled and + ctx->Texture.Unit[i]._ReallyEnabled fields. Exactly 0 or 1 bits will + be set in _ReallyEnabled at any time! + + Q: "What's the purpose of Unit[i].Enabled vs Unit[i]._ReallyEnabled?" + A: The user can enable GL_TEXTURE_1D, GL_TEXTURE_2D, etc for any + texure unit all at once (an unusual thing to do). + OpenGL defines priorities that basically say GL_TEXTURE_2D has + higher priority than GL_TEXTURE_1D, etc. Also, just because a + texture target is enabled by the user doesn't mean we'll actually + use that texture! If a texture object is incomplete (missing mip- + map levels, etc) it's as if texturing is disabled for that target. + The _ReallyEnabled field will have a bit set ONLY if the texture + target is enabled and complete. This spares the driver writer from + examining a _lot_ of GL state to determine which texture target is + to be used. + + +2. Tnl tokens changes + + During the implementation of GL_NV_vertex_program some of the vertex + buffer code was changed. Specifically, the VERT_* bits defined in + tnl/t_context.h have been renamed to better match the conventions of + GL_NV_vertex_program. The old names are still present but obsolete. + Drivers should use the newer names. + + For example: VERT_RGBA is now VERT_BIT_COLOR0 and + VERT_SPEC_RGB is now VERT_BIT_COLOR1. + + + +3. Read/Draw Buffer changes + + The business of setting the current read/draw buffers in Mesa 4.0.x + was complicated. It's much simpler now in Mesa 4.1. + + Here are the changes: + + - Renamed ctx->Color.DrawDestMask to ctx->Color._DrawDestMask + - Removed ctx->Color.DriverDrawBuffer + - Removed ctx->Pixel.DriverReadBuffer + - Removed ctx->Color.MultiDrawBuffer + - Removed ctx->Driver.SetDrawBuffer() + - Removed swrast->Driver.SetReadBuffer(). + - Added ctx->Color._DrawDestMask - a bitmask of FRONT/BACK_LEFT/RIGHT_BIT + values to indicate the current draw buffers. + - Added ctx->Pixel._ReadSrcMask to indicate the source for pixel reading. + The value is _one_ of the FRONT/BACK_LEFT/RIGHT_BIT values. + - Added ctx->Driver.DrawBuffer() and ctx->Driver.ReadBuffer(). + These functions exactly correspond to glDrawBuffer and glReadBuffer calls. + Many drivers will set ctx->Driver.DrawBuffer = _swrast_DrawBuffer and + leave ctx->Draw.ReadBuffer NULL. + DRI drivers should implement their own function for ctx->Driver.DrawBuffer + and use it to set the current hardware drawing buffer. You'll probably + also want to check for GL_FRONT_AND_BACK mode and fall back to software. + Call _swrast_DrawBuffer() too, to update the swrast state. + - Added swrast->Driver.SetBuffer(). + This function should be implemented by all device drivers that use swrast. + Mesa will call it to specify the buffer to use for span reading AND + writing and point/line/triangle rendering. + There should be no confusion between current read or draw buffer anymore. + - Added swrast->CurrentBuffer to indicate which color buffer to read/draw. + Will be FRONT_LEFT_BIT, BACK_LEFT_BIT, FRONT_RIGHT_BIT or BACK_RIGHT_BIT. + This value is usually passed to swrast->Driver.SetBuffer(). + + +4. _mesa_create_context() changes. This function now takes a pointer to + a __GLimports object. The __GLimports structure contains function + pointers to system functions like fprintf(), malloc(), etc. + The _mesa_init_default_imports() function can be used to initialize + a __GLimports object. Most device drivers (like the DRI drivers) + should use this. + + +5. In tnl's struct vertex_buffer, the field "ProjectedClipCoords" + has been replaced by "NdcPtr" to better match the OpenGL spec's + terminology. + + +6. Since GL_EXT_stencil_two_side has been implemented, many of the + ctx->Stencil fields are now 2-element arrays. For example, + "GLenum Ref" is now "GLenum Ref[2]" The [0] elements are the front-face + values and the [1] elements are the back-face values. + ctx->Stencil.ActiveFace is 0 or 1 to indicate the current face for + the glStencilOp/Func/Mask() functions. + ctx->Stencil.TestTwoSide controls whether or not 1 or 2-sided stenciling + is enabled. + + +7. Removed ctx->Polygon._OffsetAny. Removed ctx->Polygon.OffsetMRD. + + +8. GLfloat / GLchan changes: + + - Changed ctx->Driver.ClearColor() to take GLfloat[4] instead of GLchan[4]. + ctx->Color.ClearColor is now GLfloat[4] too. + - Changed ctx->Driver.AlphaRef() to take GLfloat instead of GLchan. + - ctx->Color.AlphaRef is now GLfloat. + - texObj->BorderColor is now GLfloat[4]. texObj->_BorderChan is GLchan[4]. + + This is part of an effort to remove all GLchan types from core Mesa so + that someday we can support 8, 16 and 32-bit color channels dynamically + at runtime, instead of at compile-time. + + +9. GLboolean ctx->Tranform.ClipEnabled[MAX_CLIP_PLANES] has been replaced + by GLuint ctx->Transform.ClipPlanesEnabled. The later is a bitfield. + + +10. There's a new matrix_stack type in mtypes.h used for the Modelview, + Projection, Color and Texcoord matrix stacks. + + +11. The ctx->Current.* fields have changed a lot. Now, there's a + ctx->Current.Attrib[] array for all vertex attributes which matches + the NV vertex program conventions. + + +---------------------------------------------------------------------- +$Id: RELNOTES-4.1,v 1.22 2002/10/29 15:06:37 brianp Exp $ diff --git a/docs/RELNOTES-5.0 b/docs/RELNOTES-5.0 new file mode 100644 index 0000000..565e4ad --- /dev/null +++ b/docs/RELNOTES-5.0 @@ -0,0 +1,85 @@ + + Mesa 5.0 release notes + + November 13, 2002 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Even-numbered versions (such as 5.0) designate stable releases. +Odd-numbered versions (such as 4.1) designate new developmental releases. + +Mesa 5.0 is basically just a stabilization of Mesa 4.1. To see a list of +bug fixes, etc. see the VERSIONS file. + + + +New Features in Mesa 5.0 +------------------------ + +Mesa 5.0 supports OpenGL 1.4. Note Mesa's versioning convention: + + OpenGL Version Mesa Version + ------------------------------ + 1.0 1.x + 1.1 2.x + 1.2 3.x + 1.3 4.x + 1.4 5.x + +OpenGL 1.4 (and Mesa 5.0) incorporates the following OpenGL extensions as +standard features: + + GL_ARB_depth_texture + GL_ARB_shadow + GL_ARB_texture_env_crossbar + GL_ARB_texture_mirror_repeat + GL_ARB_window_pos + GL_EXT_blend_color + GL_EXT_blend_func_separate + GL_EXT_blend_logic_op + GL_EXT_blend_minmax + GL_EXT_blend_subtract + GL_EXT_fog_coord + GL_EXT_multi_draw_arrays + GL_EXT_point_parameters + GL_EXT_secondary_color + GL_EXT_stencil_wrap + GL_SGIS_generate_mipmap + + + +Device Driver Status +-------------------- + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of these drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.4 +OSMesa (off-screen) implements OpenGL 1.4 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.4 +DOS/DJGPP implements OpenGL 1.3 +GGI implements OpenGL 1.3 +DOS implements OpenGL 1.4 +BeOS needs updating (underway) +Allegro needs updating +D3D needs updating + +Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the +driver call the _mesa_enable_1_4_extensions() function. + + +---------------------------------------------------------------------- +$Id: RELNOTES-5.0,v 3.2 2002/11/13 15:33:51 brianp Exp $ diff --git a/docs/RELNOTES-5.0.1 b/docs/RELNOTES-5.0.1 new file mode 100644 index 0000000..8d72cc4 --- /dev/null +++ b/docs/RELNOTES-5.0.1 @@ -0,0 +1,46 @@ + + Mesa 5.0.1 release notes + + March 30, 2003 + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Even-numbered versions (such as 5.0.x) designate stable releases. +Odd-numbered versions (such as 4.1.x) designate new developmental releases. + +Mesa 5.0.1 just fixes bugs found since the 5.0 release. See the VERSIONS +file for details. + + +Device Driver Status +-------------------- + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of these drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.4 +OSMesa (off-screen) implements OpenGL 1.4 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.4 +DJGPP implements OpenGL 1.4 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.4 +Allegro needs updating +D3D needs updating + +Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the +driver call the _mesa_enable_1_4_extensions() function. + + +---------------------------------------------------------------------- +$Id: RELNOTES-5.0.1,v 3.1 2003/03/30 16:17:54 brianp Exp $ diff --git a/docs/RELNOTES-5.0.2 b/docs/RELNOTES-5.0.2 new file mode 100644 index 0000000..cfc9ad0 --- /dev/null +++ b/docs/RELNOTES-5.0.2 @@ -0,0 +1,46 @@ + + Mesa 5.0.2 release notes + + September 5, 2003 + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Even-numbered versions (such as 5.0.x) designate stable releases. +Odd-numbered versions (such as 4.1.x) designate new developmental releases. + +Mesa 5.0.2 just fixes bugs found since the 5.0.1 release. See the VERSIONS +file for details. + + +Device Driver Status +-------------------- + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of these drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.4 +OSMesa (off-screen) implements OpenGL 1.4 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.4 +DJGPP implements OpenGL 1.4 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.4 +Allegro needs updating +D3D needs updating + +Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the +driver call the _mesa_enable_1_4_extensions() function. + + +---------------------------------------------------------------------- +$Id: RELNOTES-5.0.2,v 1.1 2003/09/04 23:10:38 brianp Exp $ diff --git a/docs/RELNOTES-5.1 b/docs/RELNOTES-5.1 new file mode 100644 index 0000000..aed6e10 --- /dev/null +++ b/docs/RELNOTES-5.1 @@ -0,0 +1,279 @@ + + Mesa 5.1 release notes + + December 17, 2003 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Even-numbered versions (such as 5.0) designate stable releases. +Odd-numbered versions (such as 5.1) designate new developmental releases. + + +Bug fixes +--------- +See the VERSIONS file for a list of bugs fixed in this release. + + + +New Features in Mesa 5.1 +------------------------ + +GL_ARB_vertex_program / GL_ARB_fragment_program + Michal Krol and Karl Rasche implemented these extensions. Thanks! + Be aware that there may be some rough edges and lurking bugs. + +GL_ATI_texture_env_combine3 extension + This adds a few new texture combine modes. + Contributed by Ian Romanick. + +GL_SGI_texture_color_table + Adds a color table lookup to the RGBA texture path. There's a separate + color table for each texture unit. + Contributed by Eric Plante. + +GL_NV_fragment_program + NVIDIA's fragment-level programming feature. + Possible lurking bugs: + - the DDX and DDY commands aren't fully tested + - there may be bugs in the parser + - the TEX and TXP instructions both do perspective correction + - the pack/unpack instructions may not be correct + +GL_EXT_depth_bounds_test + This extension adds a scissor-like test for the Z axis. It's used to + optimize stencil-volume shadow algorithms. + +GL_NV_light_max_exponent + Lifts the 128 limit for max light exponent. + +GL_EXT_texture_rectangle + Identical to GL_NV_texture_rectangle + +GL_ARB_occlusion_query + Useful for visibility-based culling. + +GL_ARB_texture_non_power_of_two + Removes the restriction that texture dimensions must be powers of two. + +GL_ARB_vertex_buffer_object + Allows server-side vertex arrays, optimized host/card data transfers, etc. + +GL_ARB_point_sprite + ARB-approved version of GL_NV_point_sprite. Basically allows textures + to be applied to points. + +GL_IBM_multimode_draw_arrays + Allows multiple vertex arrays to be drawn with one call, including arrays + of different types of primitives. + +GL_SUN_multi_draw_arrays + An alias for GL_EXT_multi_draw_arrays, standard in OpenGL 1.4. + +Faster glDrawPixels / glCopyPixels in X11 driver + If your X screen is 32bpp, glDrawPixels to the front color buffer will + be accelerated (via XPutImage()) if the image format is GL_BGRA and the + type is GL_UNSIGNED_BYTE. No raster operations, such as depth test, + blend, fog, etc. can be enabled. + + If your X screen is 16bpp, glDrawPixels to the front color buffer will + be accelerated (via XPutImage()) if the image format is GL_RGB and the + type is GL_UNSIGNED_SHORT_5_6_5. No raster operations, such as depth + test, blend, fog, etc. can be enabled. + + glCopyPixels() calls for the front color buffer will be accelerated + (via XCopyArea()) if no raster operations, such as depth test, blend, + fog, pixel zoom, etc. are enabled. + + The speed-up over typical software rendering is a factor of 10 for + glDrawPixels and 100 for glCopyPixels. + + +With the addition of GL_ARB_occlusion_query, GL_ARB_vertex_buffer_object, +GL_ARB_texture_non_power_of_two and GL_EXT_shadow_funcs, Mesa 5.1 supports +all the new features of OpenGL 1.5. Mesa 6.0 (the next stable release) +will advertise GL_VERSION = "1.5". + + + +Vertex/Fragment program debugger +-------------------------------- + +GL_MESA_program_debug is an experimental extension to support +interactive debugging of vertex and fragment programs. See the +docs/MESA_program_debug.spec file for details. + +The bulk of the vertex/fragment program debugger is implemented +outside of Mesa. The GL_MESA_program_debug extension just has minimal +hooks for stopping running programs and inspecting programs. + +The progs/tests/debugger.c (only in CVS) program is an example of how +the extension can be used. Presently, the debugger code and demo code +is in the same file. Eventually the debugger code should be moved +into a reusable module. + +As it is now, the demo lets you set breakpoings in vertex/fragment +programs, single step, and print intermediate register values. It's +basically just a proof of concept. + + + +Directory tree reorganization +----------------------------- + +The directory structure for Mesa has been overhauled to improve its layout. +All source code for Mesa, GLU, GLUT, etc is now under the src/ directory +in appropriate subdirectories. + +The Mesa source code and drivers has been reorganized under src/mesa/. + +All demonstration programs and tests are now in subdirectories under progs/. + + + +Build System Changes +-------------------- + +The GNU automake/autoconf support has been removed. As it was, it seldom +worked on anything but Linux. The Mesa developers aren't big fans of +automake/autoconf/libtool and didn't have the time to maintain it. +If someone wants to contribute new automake/autoconf support (and is +willing to maintain it), it may be re-incorporated into Mesa, subject +to some requirements. + +The "old style" makefile system has been updated: + 1. Make-config has been trimmed down to fewer, modern configurations. + 2. Most of the bin/mklib.* scripts have been rolled into a new "mklib" + script that works on all sorts of systems. There are probably some + bugs in it, but it's been tested on Linux, SunOS 5.8 and IRIX 6.5. + Improvements/contributes are greatly appreciated. + 3. The Makefile.X11 files have been cleaned up in various ways + + + +Source File Changes +------------------- + +The mmath.[ch] files are obsolete. Their contents have been moved +into the imports.[ch] and macros.[ch] files. + +The files related to vertex and fragment programming have changed. +Old files: + vpexec.[ch] + vpparse.[ch] + vpstate.[ch] +New files: + program.[ch] - generic ARB/NV program code + arbprogram.[ch] - ARB program API functions + arbfragparse.[ch] - ARB fragment program parsing + arbvertparse.[ch] - ARB vertex program parsing + arbparse.[ch] - ARB vertex/fragment parsing + arbparse_syn.h - vertex/fragment program syntax + nvprogram.[ch] - NV program API functions + nvvertprog.h - NV vertex program definitions + nvfragprog.h - NV fragment program definitions + nvvertparse.[ch] - NV vertex program parser + nvfragparse.[ch] - NV fragment program parser + nvvertexec.[ch] - NV vertex program execution + swrast/s_nvfragprog.[ch] - NV fragment program execution + +The files related to per-vertex handling have changed. +Old files: + tnl/t_eval_api.c - old per-vertex code + tnl/t_imm_alloc.c - old per-vertex code + tnl/t_imm_api.c - old per-vertex code + tnl/t_imm_debug.c - old per-vertex code + tnl/t_imm_dlist.c - old per-vertex code + tnl/t_imm_elt.c - old per-vertex code + tnl/t_imm_eval.c - old per-vertex code + tnl/t_imm_exec.c - old per-vertex code + tnl/t_imm_fixup.c - old per-vertex code + tnl/t_vtx_sse.c - old per-vertex code + tnl/t_vtx_x86.c - old per-vertex code +New files: + tnl/t_save_api.c - new per-vertex code + tnl/t_save_loopback.c - new per-vertex code + tnl/t_save_playback.c - new per-vertex code + tnl/t_vtx_eval.c - old per-vertex code + +Other new files: + bufferobj.[ch] - GL_ARB_vertex_buffer_object functions + version.h - defines the Mesa version info + +Other removed files: + swrast/s_histogram.[ch] - moved into src/histogram.c + + + +Other Changes +------------- + +The ctx->Driver.CreateTexture function has been removed - it wasn't used. + +New device driver hook functions: + NewTextureObject - used to allocate struct gl_texture_objects + NewTextureImage - used to allocate struct gl_texture_images + +New ctx->Texture._EnabledCoordUnits field: + With the addition of GL_NV_fragment_program we may need to interpolate + various sets of texture coordinates even when the corresponding texture + unit is not enabled. That is, glEnable(GL_TEXTURE_xD) may never get + called but we still may have to interpolate texture coordinates across + triangles so that the fragment program will get them. + This new field indicates which sets of texture coordinates are needed. + If a bit is set in the ctx->Texture._EnabledUnits bitmask is set, the + same bit MUST be set in ctx->Texture._EnabledCoordUnits. + +The ctx->_TriangleCaps field is deprecated. + Instead of testing the DD_* bits in _TriangleCaps, you should instead + directly test the relevant state variables, or use one of the helper + functions like NEED_SECONDARY_COLOR() at the bottom of context.h + While testing _TriangleCaps bits was fast, it was kludgey, and setting + the bits in the first place could be error prone. + +New vertex processing code. + The code behind glBegin, glEnd, glVertex, glNormal, etc. has been + totally rewritten. It's a cleaner implementation now and should use + less memory. (Keith) + + + +To Do +----- +Add screen-awareness to fakeglx.c + + + + +Device Driver Status +-------------------- + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of these drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.4 +OSMesa (off-screen) implements OpenGL 1.4 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.4 +DJGPP implements OpenGL 1.4 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.4 +Allegro needs updating +D3D needs updating + +Note: supporting OpenGL 1.4 (vs. 1.3 or 1.2) usually only requires that the +driver call the _mesa_enable_1_4_extensions() function. + + +---------------------------------------------------------------------- diff --git a/docs/RELNOTES-6.0 b/docs/RELNOTES-6.0 new file mode 100644 index 0000000..de01a87 --- /dev/null +++ b/docs/RELNOTES-6.0 @@ -0,0 +1,87 @@ + + Mesa 6.0 release notes + + January 16, 2004 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 5.1) designate new developmental releases. +Even numbered versions (such as 6.0) designate stable releases. + +Mesa version 6.0 signifies two things: + + 1. A stabilization of the 5.1 development release + 2. Implementation of the OpenGL 1.5 specification. When you query + glGetString(GL_VERSION) "1.5" will be returned (as long as the + driver supports all the required features). + + +Note that the Mesa major version number is incremented with the OpenGL +minor version number: + + Mesa 1.x == OpenGL 1.0 + Mesa 2.x == OpenGL 1.1 + Mesa 3.x == OpenGL 1.2 + Mesa 4.x == OpenGL 1.3 + Mesa 5.x == OpenGL 1.4 + Mesa 6.x == OpenGL 1.5 + + + +New Features +------------ + +Mesa 5.1 already had all the new features of OpenGL 1.5, implemented as +extensions. These extensions were simply promoted to standard features: + + GL_ARB_occlusion_query extension + GL_ARB_texture_non_power_of_two extension + GL_ARB_vertex_buffer_object extension + GL_EXT_shadow_funcs + + + +Device Drivers +-------------- + +Mesa advertises itself as either OpenGL 1.2 or OpenGL 1.3 depending on +the device driver. For example, if the driver enables all the ARB +extensions which are part of OpenGL 1.3 then glGetString(GL_VERSION) +will return "1.3". Otherwise, it'll return "1.2". + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of the drivers. +Here's the current status of all included drivers: + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.5 +OSMesa (off-screen) implements OpenGL 1.5 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.5 +DJGPP implements OpenGL 1.5 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.5 +Allegro needs updating +D3D needs updating + + + + +Other Changes +------------- + +See the VERSIONS file for more details about bug fixes, etc. in Mesa 6.0. + + +---------------------------------------------------------------------- +$Id: RELNOTES-6.0,v 1.3 2004/01/15 15:47:57 brianp Exp $ diff --git a/docs/RELNOTES-6.0.1 b/docs/RELNOTES-6.0.1 new file mode 100644 index 0000000..e72d9fe --- /dev/null +++ b/docs/RELNOTES-6.0.1 @@ -0,0 +1,50 @@ + + Mesa 6.0.1 release notes + + April 2, 2003 + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Even-numbered versions (such as 6.0.x) designate stable releases. +Odd-numbered versions (such as 6.1.x) designate new developmental releases. + +Mesa 6.0.1 just fixes bugs found since the 6.0 release. See the VERSIONS +file for details. + + + +Device Drivers +-------------- + +Mesa advertises itself as supporting OpenGL 1.2, 1.3, 1.4 or 1.5 +depending on the device driver's capabilities. For example, if the +driver enables all the ARB extensions which are part of OpenGL 1.5 +then glGetString(GL_VERSION) will return "1.5". Otherwise, it'll +return "1.4" or the next lower version that implements all required +functionality. + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of the drivers. +Here's the current status of all included drivers: + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.5 +OSMesa (off-screen) implements OpenGL 1.5 +FX (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.5 +DJGPP implements OpenGL 1.5 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.5 +Allegro needs updating +D3D needs updating + + +---------------------------------------------------------------------- +$Id: RELNOTES-6.0.1,v 3.1 2004/04/02 23:37:02 brianp Exp $ diff --git a/docs/RELNOTES-6.1 b/docs/RELNOTES-6.1 new file mode 100644 index 0000000..830f1e4 --- /dev/null +++ b/docs/RELNOTES-6.1 @@ -0,0 +1,112 @@ + + Mesa 6.1 release notes + + August 18, 2004 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 6.1) designate new developmental releases. +Even numbered versions (such as 6.0) designate stable releases. + + +New Features +------------ + +Half-precision floating point (GLhalf) pixel formats are supported +in Mesa, but the feature isn't exposed yet since the ARB extension +hasn't been finalized yet. + + +Texture image handling +---------------------- + +The code which implements image conversion, pixel transfer ops, etc +for glTexImage commands has been rewritten. + +Now the gl_texture_format struct has a new StoreImage function +pointer. Each texture format must implement this function. The +function is totally responsible for converting the user's texture +image into the specific format. A few helper functions makes this +relatively simple. + +Overall, the code is much simpler, cleaner and easier to work with +now. Adding new texture formats is straight-forward and there's no +longer any distinction between "hardware" and "software" formats. + +Finally, the code for compressed texture images has been reorganized +as well. + +Removed files: + texutil.c + texutil.h + texutil_tmp.h + +New files: + texcompress_s3tc.c + texcompress_fxt1.c + + + +Driver / context changes +------------------------ + +The _mesa_create_context() and _mesa_initialize_context() function +parameters have changed. They now take a pointer to a struct +dd_function_table. Drivers can initialize this table by calling +_mesa_init_driver_functions(). Drivers should then plug in the special +functions they implement. In particular, the ctx->Driver.NewTextureObject +pointer _must_ be set so that the default texture objects created in +_mesa_create/initialize_context() are correctly built. + +The _mesa_init_driver_functions() function allows a lot of redundant code +to be removed from the device drivers (such as initializing +ctx->Driver.Accum to point to _swrast_Accum). Adding new functions to +the dd_function_table can be done with less hassle since the pointer can +be initialized in _mesa_init_driver_functions() rather than in _all_ the +drivers. + + +Device Drivers +-------------- + +Mesa advertises itself as supporting OpenGL 1.2, 1.3, 1.4 or 1.5 +depending on the device driver's capabilities. For example, if the +driver enables all the ARB extensions which are part of OpenGL 1.5 +then glGetString(GL_VERSION) will return "1.5". Otherwise, it'll +return "1.4" or the next lower version that implements all required +functionality. + +A number of Mesa's software drivers haven't been actively maintained for +some time. We rely on volunteers to maintain many of the drivers. +Here's the current status of all included drivers: + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.5 +OSMesa (off-screen) implements OpenGL 1.5 +Glide (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.5 +DJGPP implements OpenGL 1.5 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.5 +Allegro needs updating +D3D needs updating + + + +Other Changes +------------- + +See the VERSIONS file for more details about bug fixes, etc. in Mesa 6.1. + + +---------------------------------------------------------------------- +$Id: RELNOTES-6.1,v 3.5 2004/08/17 22:58:23 brianp Exp $ diff --git a/docs/RELNOTES-6.2 b/docs/RELNOTES-6.2 new file mode 100644 index 0000000..5362218 --- /dev/null +++ b/docs/RELNOTES-6.2 @@ -0,0 +1,49 @@ + + Mesa 6.2 release notes + + October 2, 2004 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 6.1) designate new developmental releases. +Even numbered versions (such as 6.2) designate stable releases. + + +This release primarily just fixes bugs found in the Mesa 6.1 release. +See the VERSIONS file for details. + + + +Known Issues +------------ + +The GL_EXT_pixel_buffer_object extension isn't fully implemented for +functions like glPolygonStipple, glConvolutionFilter, glColorTable, +etc. The important functions like glRead/DrawPixels, glTex[Sub]Image, +and glBitmap work with PBOs. + + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.5 +OSMesa (off-screen) implements OpenGL 1.5 +Glide (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.5 +DJGPP implements OpenGL 1.5 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.5 +Allegro needs updating +D3D needs updating + + +---------------------------------------------------------------------- +$Id: RELNOTES-6.2,v 3.3 2004/10/02 14:59:29 brianp Exp $ diff --git a/docs/RELNOTES-6.2.1 b/docs/RELNOTES-6.2.1 new file mode 100644 index 0000000..99440e2 --- /dev/null +++ b/docs/RELNOTES-6.2.1 @@ -0,0 +1,50 @@ + + Mesa 6.2.1 release notes + + December 9, 2004 + + PLEASE READ!!!! + + + +Introduction +------------ + +Mesa uses an even/odd version number scheme like the Linux kernel. +Odd numbered versions (such as 6.1) designate new developmental releases. +Even numbered versions (such as 6.2.x) designate stable releases. + + +This release primarily just fixes bugs found in the Mesa 6.2 release. +See the VERSIONS file for details. + + + +Known Issues +------------ + +The GL_EXT_pixel_buffer_object extension isn't fully implemented for +functions like glPolygonStipple, glConvolutionFilter, glColorTable, +etc. The important functions like glRead/DrawPixels, glTex[Sub]Image, +and glBitmap work with PBOs. This has been fixed for Mesa 6.3. + + + + +Driver Status +---------------------- --------------------- +XMesa (Xlib) implements OpenGL 1.5 +OSMesa (off-screen) implements OpenGL 1.5 +Glide (3dfx Voodoo1/2) implements OpenGL 1.3 +SVGA implements OpenGL 1.3 +Wind River UGL implements OpenGL 1.3 +Windows/Win32 implements OpenGL 1.5 +DJGPP implements OpenGL 1.5 +GGI implements OpenGL 1.3 +BeOS implements OpenGL 1.5 +Allegro needs updating +D3D needs updating + + +---------------------------------------------------------------------- +$Id: RELNOTES-6.2.1,v 1.1.2.2 2004/12/09 23:09:19 brianp Exp $ diff --git a/docs/VERSIONS b/docs/VERSIONS new file mode 100644 index 0000000..5f7fd06 --- /dev/null +++ b/docs/VERSIONS @@ -0,0 +1,1336 @@ + + +Mesa Version History +==================== + +1.0 beta February 1995 + Initial release + +1.1 beta March 4, 1995 + Changes: + faster point and line drawing (2x faster) + more systems supported, better Makefiles + Renamed lib*.a files to avoid collisions + many small bug fixes + New: + pseudo-GLX functions added + new implementation of evaluators (eval2.c) + GLUT support + +1.1.1 beta March 7, 1995 + Changes: + Reverted from eval2.c to eval.c due to FPE on Linux + more speed improvements + more Makefile changes + +1.1.2 beta March 14, 1995 + New: + implementation of SGI's blending extensions + glXUseXFont implemented + added MESA_DEBUG environment variable support + Changes: + Using eval2.c again + more FPE-prevention checks (0-length normals are OK) + a few small bug fixes + much faster pixel logic ops! + faster transformation arithmetic + +1.1.3 beta March 31, 1995 + New: + gluScaleImage() and gluBuild2DMipMaps() implemented + Mesa widgets for Xt/Motif + blendEXT demos + added environment variables for selecting visuals + Changes: + almost all GLUT demos work correctly now + faster X device driver functions + more bug fixes + +1.1.4 beta April 20, 1995 + Bug fixes: + - missing #define SEEK_SET in src-tk/image.c + - compile glShadeModel into display lists + - fixed pow() domain error in src/light.c + - fixed "flickering bitmaps" in double buffer mode + - fixed tk.h and aux.h for C++ + - state of LIGHT_MODEL_LOCAL_VIEWER was inverted + New features: + - MUCH, MUCH nicer dithering in 8-bit RGB mode + - updated widgets and widget demos + - Implemented GLXPixmap functions + - Added GLU 1.1 and GLX 1.1 functions + - Changed the X/Mesa interface API, more versatile + - Implemented gluPartialDisk() + +1.2 May 22, 1995 + Bug fixes: + - IRIX 4.x makefile problem + - modified tk to share root colormap as needed + - gluLookAt normalization problem + - suppress Expose, NoExpose events in swapbuffers + - glBitmap() and glDrawPixels() clipping + New features: + - GL_BLEND, GL_MODULATE, GL_DECAL, and GL_REPLACE_EXT texture + modes implemented + - texture maps stored more efficiently + - texture maps can be compiled into display lists + - Bogdan Sikorski's GLU polygon tesselation code + - Linas Vepstas's sweep and extrusion library + - glXCreateContext()'s shareList parameter works as it's supposed to. + XMesaCreateContext() updated to accept a shareList parameter too. + - Mesa can be compiled with real OpenGL .h files + - MESA_BACK_BUFFER environment variable + - better GLX error checking + +1.2.1 June 22, 1995 + Bug fixes: + - X/Mesa double buffer window resize crash + - widgets now pass PointerMotion events + - X/Mesa incorrect default clear color and drawing color + - more robust X MIT-SHM support in X/Mesa + - glTexImage( format=GL_LUMINANCE ) didn't work + - GL_LINE mode polygons with line width > 1.0 could cause a crash + - numerous feedback bugs + - glReadPixels() from depth buffer was wrong + - error prone depth and stencil buffer allocation + New features: + - Preliminary Microsoft Windows driver + - Implemented a number of missing functions: glEvalCoord[12][df]v(), + glGet...(), etc. + - Added a few missing symbols to gl.h and glu.h + - Faster rendering of smooth-shaded, RGBA, depth-buffered polygons. + - Faster rendering of lines when width=2.0 + - Stencil-related functions now work in display lists + Changes: + - renamed aux.h as glaux.h (MS-DOS names can't start with aux) + - most filenames are in 8.3 format to accomodate MS-DOS + - use GLubytes to store arrays of colors instead of GLints + +1.2.2 August 2, 1995 + New features: + - texture mapped points and lines + - NURBS! (but not 100% complete) + - viewports may safely extend beyond window boundaries + - MESA_PRIVATE_CMAP environment variable + - Grayscale X display support + - two new demos: demos/gears.c and demos/shadow.c + - MachTen for Macintosh configuration + Bug fixes: + - glGet*(GL_DEPTH_BITS) returned bytes, not bits + - point, line, and bitmap rasterization suffered from roundoff errors + - fixed a division by zero error in line clippping + - occasional wrong default background color really fixed! + - glDepthFunc(GL_ALWAYS) with glDepthMask(GL_FALSE) didn't work + - gluBuild2DMipmaps malloc problem fixed + - view volume clipping of smooth shaded lines resulted in bad colors + Changes: + - new visual selection method in glXChooseVisual() + - improved GLU quadric functions + - call XSync for glFinish and XFlush for glFlush + - glVertex() calls now use a function pointer to avoid conditionals + - removed contrib directory from Mesa tar file (available on ftp site) + - AIX shared library support + - Removed GLUenum type as it's not in OpenGL + +1.2.3 September 26, 1995 + New features: + - Mesa header files now equivalent to SGI OpenGL headers + - Support for HP's Color Recovery dithering displays + - Faster vertex transformation + - Faster raster operations into X windows under certain conditions + - New configurations: HP w/ shared libs, Ultrix w/ GCC, Data General + - 4-bit visuals now supported + Bug fixes: + - glScissor bug fixed + - round-off errors in clipping lines against clip planes fixed + - byte swapping between hosts and display servers implemented + - glGetError() can be called without a current rendering context + - problem with accidentally culled polygons is fixed + - fixed some widget compilation problems + +1.2.4 November 17, 1995 + New features: + - More speed improvements (lighting, fogging, polygon drawing) + - Window system and OS-independent off-screen rendering + - Preliminary Fortran bindings + - glPolygonOffsetEXT implemented + - glColorMask and glIndexMask now fully implemented + - glPixelZoom implemented + - display lists fully implemented + - gamma correction + - dithering in 8-bit TrueColor/DirectColor visuals + Changes: + - Improved device driver interface + - tk.h renamed to gltk.h to avoid conflicts with Tcl's Tk + - Dithering support moved from core into device driver + Bug fixes: + - glEnable/Disable( GL_LIGHTING ) didn't always take effect + - glReadPixels byte swapping was broken + - glMaterial with pname==GL_AMBIENT_AND_DIFFUSE was broken + - duplicate glColor4b() prototype in GL/gl.h removed + - stripes in wave -ci demo fixed + - GL_LINEAR_MIPMAP_NEAREST had wrong value + - bugs in HP Color Recovery support fixed + - fixed bug when blending lines, points, bitmaps outside of window + +1.2.5 November 30, 1995 + New Features: + - updated MS Windows driver + - new implementation of StaticGray/GrayScale visual support + Bug fixes: + - pixelzooming with gamma correction or blending didn't work + - HP color recovery visual wasn't being picked by glXChooseVisual + - glClear didn't always observe glColorMask changes + - olympic and offset demos didn't compile on some Suns + - texcoord clamping wasn't correct + - a polygon optimization introduced an occasional sampling problem + +1.2.6 January 26, 1996 + New Features: + - faster line and polygon rendering under certain conditions. See + Performance Tips 9 and 10 in README + - profiling + - lighting is a bit faster + - better perspective corrected texture mapping + - Amiga AmiWin (X11) support + - preliminary Linux SVGA driver + Changes: + - now using a 16-bit depth buffer, faster, smaller + - GL_NORMALIZE is disabled by default + Bug fixes: + - projective texture mapping + - fixed a memory leak in the context destroy function + - GL_POLYGON with less than 3 vertices caused a crash + - glGet*() returned wrong result for GL_INDEX_MODE + - reading pixels from an unmapped X window caused a BadMatch error + +1.2.7 March 5, 1996 + New: + - faster lighting + - faster 16-bit TrueColor rendering on Linux + - faster 32-bit TrueColor rendering on Linux, HP, IBM + - non-depth-buffered XImage polygons are faster + - vertex array extension + - software alpha planes + - updated Macintosh driver + - new NeXT driver + - GLU quadric functions generate texture coordinates + - reflect.c demo - reflective, textured surface demo + Changes: + - gamma correction code moved into the X driver for better performance + Bug fixes: + - multiple glClipPlane()'s didn't work reliably + - glPolygonMode() didn't always work + - glCullFace( GL_FRONT_AND_BACK ) didn't work + - texture mapping with gamma correction was buggy + - floating point exceptions in texture coordinate interpolation + - XImage byte swapping didn't always work + - polygon edge flags weren't always used correctly + +1.2.8 May 22, 1996 + New: + - overlay planes on X servers with the SERVER_OVERLAY_VISUALS property + - better monochrome output + - more IRIX 6.x configurations + - more robust RGB mode color allocation + - added MESA_XSYNC environment variable + - GLX_MESA_pixmap_colormap and GLX_EXT_visual_info extensions + - GL_MESA_window_pos extension + - faster glReadPixels/glDrawPixels for GL_DEPTH and GL_UNSIGNED_SHORT + and GL_UNSIGNED_INT + - driver for prototype Cirrus Mondello 3-D board + - updated AmigaDOS driver + - a few small speed optimizations in polygon rendering + Changes: + - internal device driver interface modified to simplify device + driver implementations and to support hardware Z buffers + - several changes to the X/Mesa interface (xmesa.h) + Bug fixes: + - fixed pow(0,0) domain error triggered on some systems + - glStencilClear() in a display list caused an infinite loop + - glRasterPos*() was sometimes off by +/-0.5 in X and Y + - color masking and blending were performed in wrong order + - auxSolidCylinder() sometimes drew a wire-frame cylinder + - fixed file writing bug in osdemo.c + - pixel mapping didn't always work + - the GL_GEQUAL stencil func didn't work + - the GL_INVERT stencil op didn't work + - the stencil write mask didn't work + - glPush/PopAttrib() didn't do enough error checking + - glIsList() didn't always work correctly + +2.0 October 10, 1996 + New: + - Implements OpenGL 1.1 API functions + - all texture filtering modes supported (mipmapping) + - faster texture mapping, see Performance Tip 11 in README + - antialiased RGB points + - X support for line and polygon stippling + - glDrawBuffer( GL_FRONT_AND_BACK ) works + - util/ directory of useful stuff + - demos/texobj demo of texture objects + Changes: + - major internal changes for thread-safeness + - new device driver interface + - MESA_ALPHA env variable removed + - triangle rasterizer replaces polygon rasterizer + Bug fixes: + - glPopAttrib() bug + - glDrawBuffer(GL_NONE) works now + +2.1 December 14, 1996 + New: + - VMS support + - MS-DOS driver + - OpenStep support + - updated, combined Windows 95/NT driver + - implemented glGetLighti() and glGetTexGen*() + - GLX does garbage collection of ancillary buffers + Bug fixes: + - removed unused _EXT constants from gl.h + - fixed polygon offset bugs + - Z coordinates of clipped lines were incorrect + - glEdgeFlag() in display lists didn't always work + - glLight*() in display lists didn't work + - fixed X line stipple bugs (Michael Pichler) + - glXUseXfonts XFreeFont/XFreeFontInfo bug fixed + - fixed a feedback bug + - glTexGen*() now transforms GL_EYE_PLANE by inverse modelview matrix + - polygons were sometimes culled instead of clipped + - triangle rasterizer suffered from float/int overflow exceptions + - fixed FP underflow exception in lighting (specular exponent) + - glEnable/glDisable of GL_EXT_vertex_array enums didn't work + - fixed free(NULL) in GLU tesselator code + - using 24-bit color on some X servers resulted in garbage rendering + - 32-bit per pixel mode for XFree86 now works + - glRotate(a,0,0,0) gave unpredictable results + - GL_LINE_STRIP with > 480 vertices had occasional clipping problems + - 8-bit TrueColor GLXPixmap rendering incorrectly required a colormap + - glMaterial() wasn't ignored when GL_COLOR_MATERIAL was enabled + - glEnable(GL_COLOR_MATERIAL) followed by glColor() didn't work right + - accumulation buffer was limited to positive values + - projective textures didn't work + - selection buffer overflows weren't handled correctly + Changes: + - restored the GL_EXT_polygon_offset extension + - slightly faster RGB dithering + - the SVGA driver works again + - Amiga driver now distributed separately + - NeXT driver updated for Mesa 2.x + +2.2 March 14, 1997 + New: + - better color selection when dithering + - added GL_EXT_texture_object extension + - updated MS-DOS driver for DJGPP + - added openbsd make configuration + - faster dithered flat-shaded triangles + - various compilation problems with Motif widgets fixed + - gl.h, glx.h and glu.h name mangling option + - BeOS driver + - 3D texture mapping extension + - GL_MESA_resize_buffers extension + - morph3d, stex3d and spectex demos + - 3Dfx support + Bug fixes: + - glColorMaterial should finally work right in all respects + - linear interpolation of mipmap levels was incorrectly weighted + - readpix.c didn't compile on Macintosh + - GL_INVERT and related logic ops didn't work right + - glTexImage[12]D() didn't check its parameters consistantly + - fixed a memory leak in glTexImage[12]D() + - kludged around a SunOS 5.x/GCC compiler bug in the feedback code + - glReadPixels aborted instead of normally catching some errors + - a few 1.1 constants were missing or misnamed in gl.h + - glBegin(p); glBegin(q); didn't generate an error + - fixed a memory leak in GLX code + - clipping of concave polygons could cause a core dump + - 1-component alpha texture maps didn't work + - fixed a GLU polygon tesselator bug + - polygons with colinear vertices were sometimes culled + - feedback triangle colors were wrong when using smooth shading + - textures with borders didn't work correctly + - colors returned in feedback mode were wrong when using lighting + - spotlights didn't effect ambient lighting correctly + - gluPartialDisk() had a few bugs + Changes: + - device driver interface expanded to support texture mapping + - faster matrix inversion subroutine + - commented out #include "wmesa_extend.h" from src/wmesa.c + - fixed many compiler warnings in the demo programs + +2.3 June 30, 1997 + New: + - Mesa distribution divided into two pieces: library code and demos + - faster vertex transformation, clip testing, lighting + - faster line drawing + - TrueColor visuals how have dithering (for depths < 24 bits) + - added MESA_NO_DITHER environment variable + - new device driver function: NearFar(), RenderVB(), RasterSetup() + - added LynxOS configuration + - added cygnus Win32 configuration + - added texcyl.c GLUT demo + - added XMesaDitherColor() to X/Mesa interface + - new NURBS code from Bogdan Sikorski + - added demos/shape.c (non-rectangular X window!) + Bug fixes: + - glEnable/DisableClientState() were missing from GL/gl.h + - GL_SPHERE_MAP texcoord generation didn't work correctly + - glXGetConfig() returned wrong number of depth, stencil, accum bits + - glDrawPixels feedback/selection didn't examine RasterPos valid bit + - black and white were reversed on some monochrome displays + - fixed potential image memory leak (wasn't setting reference counter) + - glDrawPixels sometimes didn't recognize some GL state changes + - gluProject/UnProject() didn't check for divide by zero + - stex3d demo called random() and srandom(), not portable + - fixed memory leaks in context.c and drawpix.c + - fixed NULL dereferencing problem in gl_update_texture_state() + - glReadPixels between glBegin/glEnd didn't generate an error. + - fixed memory leak in polygon tesselator (Randy Frank) + - fixed seg fault bug drawing flat-shaded, depth-tested lines + - clipped GL_TRIANGLE_STRIPs sometimes had wrong color when flat-shaded + - glBindTexture sometimes didn't work + - fixed a bug deep in glXReleaseBuffersMESA() + - fog was mistakenly applied to alpha + - glPopMatrix didn't set "dirty matrix" flag + - glPolygonStipple pattern was sometimes wrong + - glClear wasn't disabled during feedback and selection + - fixed memory leak in glTexSubImage[123]D + Changes: + - many library source files reorganized + - faster X color allocation, colors also freed when finished with them + - new texture sampling function pointer in texture objects + - incorporated 3Dfx VooDoo driver v0.16 into main source tree + - many 3Dfx driver updates + - cygnus Makefiles now included + - updated DOS driver + - made a few changes to dosmesa.c and wmesa.c (VB->Unclipped) + - internally, colors now stored in GLubytes, not GLfixed + - optimized changing of GL_SHININESS parameter + +2.4 September 18, 1997 + New: + - updated 3Dfx Glide driver + - hacks for 3Dfx rendering into an X window or fullscreen + - added depth buffer access functions to X/Mesa and OS/Mesa interfaces + Bug fixes: + - pixel buffer could overflow with long, wide lines + - fixed FP underflow problems in lighting + - glTexSubImage1D() had an unitialized variable + - incomplete texture objects could cause a segfault + - glDrawPixels with GL_COMPILE_AND_EXECUTE caused infinite loop + - flat-shaded quads in a strip were miscolored if clipped + - mipmapped triangle lod computation now works correctly + - fixed a few under/overflow bugs in triangle rasterizer + - glArrayElement() assigned bad normal if normal array disabled + - changed argument to glXReleaseBuffersMESA() + - fixed small triangle underflow bugs in tritemp.h (hopefully) + - glBindTexture(target, 0) caused a crash + - glTexImage[123]D() with NULL image pointer caused crash + - glPixelStore parameters are now ignored during display list execution + - fixed a two-sided lighting w/ clipping bug (black vertices) + - textures with width!=height were sometimes mis-rendered + - "weird" projection matrices could cause div by 0, other fp errors + Changes: + - changed precompiled header symbol from PCH to PC_HEADER + - split api.c into api1.c and api2.c + - added hash.c source file (but not used yet) + - a few Sun and HP configuration file changes + - MESA_GLX_FX env var replaces MESA_FX_WINDOW and MESA_FX_FULLSCREEN + - fixed a few cygnus build problems (src/Makefile.cygnus, src/wmesa.c) + +2.5 November 20, 1997 + New: + - updated 3Dfx driver (v20) for GLQuake + - added GL_EXT_paletted_texture extension + - added GL_EXT_shared_texture_palette extension + - added GL_EXT_point_parameters extension + - now including Mark Kilgard's GLUT library v3.6 + - new GLUT-based demos in gdemos/ + - added a few more Unix config targets + - added Intel X86 assembly language vertex transformation code + - 3Dfx/Glide driver for Mesa now recognizes SST_SCREENREFRESH env var + - Windows 95 S3 Virge driver + Bug fixes: + - glCopyTexImage?D would crash due to uninitialized variable + - glColor w/ glColorMaterial in a display list caused a bug + - fixed several glDrawPixels() and ReadPixels() bugs in 3Dfx driver + - glVertex4*() vertices weren't always projected correctly + - trying to use mipmapped textured points or lines caused crash + - glColor[34][fd]() values now clamped to [0,1] before int conversion + Changes: + - new device driver functions for texture mapping + - hash tables used for display list and texture object lookup + - fixed GLX visual handling code to avoid saving redundant visuals + - 3Dfx Glide libraries automatically linked to libMesaGL.so + - dropped the Cirrus Logic Mondello code since it's obsolete + - updated Cygnus Makefiles (Stephane Rehel) + - updated Windows MSVC++ Makefiles (Oleg Letsinsky) + - procedure for making library files has changed: scripts now take + a major and minor version arguments. Make-config changed a lot. + - new implementation of glTexSubImage2D() + - updated widgets-mesa directory to create libMesaGLwM.a (Motif widget) + - separate linux-glide and linux-386-glide configurations + +2.6 February 12, 1998 + New: + - Windows WGL functions + - updated VMS, DOS, Windows, Cygnus, BeOS, Amiga compilation support + - v0.22 of 3Dfx Glide driver + - more X86 assembly language optimizations + - faster blending for some modes + - XMesaSetFXmode() to switch between 3Dfx window and full-screen mode + - added preliminary thread support + - added GLX_MESA_copy_sub_buffer extension + - some clipping optimizations + Bug fixes: + - fixed shading/material bug when drawing long primitive strips + - fixed clipping problem in long primitive strips + - fixed clipping bug when using 3Dfx driver + - fixed a problem when trying to use X fonts w/ 3Dfx driver + - fixed a texture filter bug in 3Dfx/Glide driver + - fixed bug in 3Dfx/Glide driver involving depth mask & clearing + - glLoadMatrix to set projection matrix confused the 3Dfx driver + - non-identity texture matrices didn't work with linux-386 configs + - glGenTextures() didn't reserve the returned texture IDs + - NULL proxy image sent to glTexImageXD() caused crash + - added texture state validation optimization (Henk Kok) + - fixed colormap reuse problem when using both RGB and CI windows + - 32bpp True/DirectColor X visuals weren't recognized + - fixed potential problem in evaluators memory allocation + - fixed assorted demo compilation bugs + Changes: + - replaced old Mesa/windows/ directory with Mesa/WIN32/ directory + - converted a few old glaux/gltk demos to GLUT + - renamed directories: demos -> xdemos, gdemos -> demos + + +3.0 September 17, 1998 + New: + - OpenGL 1.2 API + - GL_EXT_abgr pixel format extension + - GL_SGIS_texture_edge_clamp extension + - GL_SGIS_multitexture extension (to be replaced by GL_ARB_multitex) + - GL_EXT_multitexture extension (to be replaced by GL_ARB_multitex) + - GL_EXT_rescale_normal extension and renormal.c demo + - GLX_SGI_video_sync extension (a no-op) + - antialiased lines + - glGetTexImage() now implemented + - glDraw/Copy/ReadPixels() optimizations + - optimized textured triangle code (Marten Stromberg) + - more optimization of dithered TrueColor triangles in X driver + - Linux GGI driver + - updated MGL driver + Bug fixes: + - lots of assorted compilation fixes + - glInitNames didn't write initial hit record + - glBitmap didn't always check for invalid raster position + - switching between GLX and OSMesa contexts caused a crash + - fixed uninitialized variable in Mesa widget code + - fixed typo in texture code which caused book/texgen to crash + - fixed texture sampling bug when filter=GL_LINEAR and wrap=GL_CLAMP + - gluDisk() in POINT or LINE mode sometimes failed + - fixed texture + fog bug + - GL_COMPILE_AND_EXECUTE mode didn't work reliably + - glMultMatrix in projection matrix mode w/ 3Dfx driver could fail + - glDrawPixels(color index pixels) weren't converted to RGBA + - fixed possible getenv() buffer overflow security bug + - glBitmap in feedback mode was offset by xOrig, yOrig params + - device driver's DrawPixels hook was never used + - glDrawPixels with zoomY!=1 and top/bottom clipping didn't work + - glDrawPixels optimized for GL_LUMINANCE, GL_LUMINANCE_ALPHA, GLubyte + - fixed MakeCurrent bug in GLwRedrawObjects() in MesaWorkstation.c + - glCopyTexSubImage2D() didn't work with 3Dfx driver + - lines with width = 2 could cause crash + - glClear with scissor rect sometimes cleared whole buffer + - glTexSubImage2D( .. GL_COLOR_INDEX .. ) didn't work + - glTexImageXD( .. GL_ABGR_EXT .. ) didn't work + - computation of inverse modelview matrix sometimes failed + - fixed GL_CLAMP mode texture sampling bug + - textured line interpolation was somewhat broken + - textured triangle interpolation was also somewhat broken + - glGet(MODELVIEW/PROJECTION/TEXTURE_MATRIX_STACK_DEPTH) off by one + - evaluator state wasn't fully initialized + - texture coordinate clipping was buggy + - evaluator surfaces could be mis-colored + - glAccum(GL_RETURN, s) didn't obey glColorMask() settings + - zero area polygons shouldn't be culled if polygon mode is point/line + - clipped width and height of glReadPixels was sometimes off by one + - blending with alpha = 0 or 1.0 wasn't always exact + - reading of pixels from clipped region was buggy + - minor tweaking of X visual management in GLX emulator + - glPolygonStipple now obeys pixel unpacking parameters + - glGetPolygonStipple now obeys pixel packing parameters + - interleaved vertex array texture coordinates were broken + - query of proxy texture internal format was broken + - alpha channel wasn't reliably cleared + - fixed divide by zero error in gluScaleImage if dest size = 1 x 1 + Conformance bug fixes: + - GL_SELECTION_BUFFER_POINTER and GL_SELECTION_BUFFER_SIZE were missing + - GL_TEXTURE_INTERNAL_FORMAT was missing + - glGet*(GL_POLYGON_STIPPLE) was broken + - glPush/PopAttrib() didn't save/restore all texture state + - glBitmap in feedback mode didn't work + - feedback of texture coords didn't always work + - glDrawPixels w/ format=GL_DEPTH_COMPONENT, type=GLbyte was broke + - glDrawPixels w/ format=GL_DEPTH_COMPONENT, type=GLubyte was broke + - glDrawPixels w/ format=GL_STENCIL_INDEX, type=GL_BITMAP was broke + Changes: + - upgraded GLUT to version 3.7 + - only GL and GLU library code included in MesaLib.tar.gz + - GLUT and all demos now in MesaDemos.tar.gz + - glaux and gltk libraries removed + - IRIX -n32 and -64 libs go in lib32/ and lib64/ directories + + +3.1 beta 1 November 19, 1998 + New: + - GL_EXT_stencil_wrap extension + - GL_INGR_blend_func_separate extension + - GL_ARB_multitexture extension + - GL_NV_texgen_reflection extension + - newly optimized vertex transformation code + - updated GLUT 3.7 code + - better precision when using 32-bit Z buffer + - Allegro DJGPP driver + Bug fixes: + - glCopyPixels between front/back buffers didn't copy alpha correctly + - fixed out-of-bounds memory access in optimized 2-D texture code + - glPixelStorei didn't accept GL_PACK/UNPACK_IMAGE_HEIGHT parameter + - glGet*() didn't accept GL_MAX_3D_TEXTURE_SIZE parameter + - clipping of texture coordinates sometimes had bad R,Q values + - GL_CLAMP_TO_EDGE texture sampling was off by 0.5 texels + - glEdgeFlagPointer() now takes a GLvoid * instead of GLboolean * + - texture was sometimes applied twice with 3Dfx driver + - glPush/PopAttrib() fouled up texture object reference counts + - glDeleteLists(0, n) caused assertion failure + - bilinear texture sampling wasn't accurate enough + - glClear w/ glDepthMask(GL_FALSE) didn't work right on 3Dfx + - color components were reversed on big endian 32 bpp X visuals + Changes: + - removed GL_EXT_multitexture extension + + +3.1 beta 2 May 24, 1999 + New: + - multi-textured points and lines (mjk@nvidia.com) + - optimized 24bpp X rendering (bernd.paysan@gmx.de) + - added allegro support (bernie-t@geocities.com) + - cleaned-up Windows-related stuff (Ted Jump) + - minor stereo changes (KendallB@scitechsoft.com) + - new BeOS driver which implements BGLView class + - new Direct3D driver (see src/D3D) + - more efficient filled gluCylinder() function + - utilities: util/showbuffer.[ch] and util/glstate.[ch] + - fixed some IRIX compiler warnings + - added support for building Mesa in XFree86 with + SGI's GLX (kevin@precisioninsight.com) + Bug fixes: + - a variety of Windows/Mesa bug fixes (mjk@nvidia.com) + - packed pixel images weren't unpacked correctly + - patches some win32 files in GLUT (mjk@nvidia.com) + - glTexImage[123]D() didn't accept internalFormat == GL_COLOR_INDEX + - fixed lighting bug in Keith's new shading code + - fixed texture segfault seen in Lament screensaver + - fixed miscellaneous low-memory bugs + - glClear(GL_COLOR_BUFFER_BIT) with RGBA or CI masking was broken + - GL_LINEAR sampling of 3D textures was broken + - fixed SVR4 'cc' compiler macro problem (dawes@xfree86.org) + - added GL_TEXTURE_PRIORITY fix (keithh@netcomuk.co.uk) + - fixed wide point and wide line conformance bugs (brianp) + Changes: + - some device driver changes (see src/dd.h) + - new copyright on core Mesa code + + +3.1 beta 3 September 17, 1999 + New: + - optimized glAccum function + - optimized 24bpp rendering in XMesa driver + - GLU 1.2 polygon tessellator + Bug Fixes: + - glGetTexLevelParameter wasn't fully implemented + - glXUseXFont now handles multi-byte fonts + - glIsEnabled(GL_TEXTURE_2D / 3D) returned wrong result + - alpha channel of blending points, lines was sometimes incorrect + Changes: + - New library names: "libGL" instead of "libMesaGL" + - New library numbering: libGL.so.1.2.310 + - New subdirectories: docs/ and bin/ + - New Makefile-system (autoconf,automake,libtool) + + +3.1 final December 14, 1999 + New: + - added demos/gloss.c + - added xdemos/glxdpyinfo.c + - added GLX_ARB_get_proc_address extension + - rewritten glTexImage code paths (faster, less memory, bug fixes) + Bug Fixes: + - several vertex array bug fixes + - overlapping glCopyPixels with pixel zooming now works + - glXUseXFont() bitmaps were vertically shifted by one pixel + - glCopyPixels with pixel zooming now works + + +3.2 final April 24, 2000 + Bug fixes: + - fixed memcpy bugs in span.c + - fixed missing glEnd problem in demos/tessdemo.c + - fixed bug when clearing 24bpp Ximages + - fixed clipping problem found in Unreal Tournament + - fixed Loki's "ice bug" and "crazy triangles" seen in Heretic2 + - fixed Loki's 3dfx RGB vs BGR bug + - fixed Loki's 3dfx smooth/flat shading bug in SoF + Changes: + - updated docs/README file + - use bcopy() optimizations on FreeBSD + - re-enabled the optimized persp_textured_triangle() function + + +3.2.1 July 19, 2000 + Bug fixes: + - gluBuild2DMipmaps() didn't accept GL_BGRA + - Fixed compile/makefile problems on IRIX + - fixed segfault in 3dfx driver when using GL selection/feedback + - no longer cull very, very tiny triangles + - blending w/ drawbuffer==GL_FRONT_BACK caused segfault (sw rendering) + - fixed Motif detection code in widgets-mesa/configure.in + - glColorMaterial and glMaterial updates to emissive and ambient + didn't always work right + - Specular highlights weren't always in the right place + - clipped GL_LINE mode polygons had interior lines appear + - blend term GL_ONE_MINUS_CONSTANT_ALPHA was broken + - GL_NICEST fog didn't always work with flat shading + - glRect commands in display lists were sometimes miscolored + - Line Z offset didn't always work + - fixed texgen normal vector problem (gloss's teapot) + - numerous GL conformance bugs fixed + Changes: + - glColorMask(false, false, false, false) handled better/faster + - reverted to old GLU polygon tessellator, GLU 1.1 + - updated Win32 build files + + +3.3 July 21, 2000 + New: + - antialiased triangles now implemented + - GL_EXT_texture_env_add texture mode extension + - GLX 1.3 API + - support for separate draw/read buffers (ie GL_SGI_make_current_read) + - thread-safe API dispath + - improved glxinfo program + - demos/texdown program to measure texture download performance + - glext.h header file + - demos/geartrain program + - GL_EXT_texture_lod_bias extension + - demos/lodbias program + - further optimized glRead/DrawPixels for 16-bit TrueColor X visuals + - GLX_EXT_visual_rating extension (a no-op, however) + - GL_HP_occlusion_test extension (for X and OS/Mesa drivers) + - demos/occlude program + - GL_SGIS_pixel_texture and GL_SGIX_pixel_texture extensions + - demos/pixeltex program + - GL_SGI_color_matrix extension + - GL_SGI_color_table extension + - GL_EXT_histogram extension + - GL_ARB_texture_cube_map extension + - added xdemos/glxheads and xdemos/manywin + - demos/texenv.c demo + - GL_EXT_texture_env_combine extension (by Holger Waechtler) + - Xlib driver is now thread-safe (see xdemos/glthreads) + Bug Fixes: + - various GL conformance failures fixed since 3.2.1 + Changes: + - gl.h now uses #defines instead of C enums for all tokens + - glu.h now uses #defines instead of C enums for all tokens + - moved programs from 3Dfx/demos/ into demos/ directory + + +3.4 November 3, 2000 + New: + - optimized glDrawPixels for glPixelZoom(1,-1) + Bug Fixes: + - widgets-mesa/src/*.c files were missing from 3.3 distro + - include/GL/mesa_wgl.h file was missing from 3.3 distro + - fixed some Win32 compile problems + - texture object priorities weren't getting initialized to 1.0 + - glAreTexturesResident return value was wrong when using hardware + - glXUseXFont segfaulted when using 3dfx driver (via MESA_GLX_FX) + - glReadPixels with GLushort packed types was broken + - fixed a few bugs in the GL_EXT_texture_env_combine texture code + - glPush/PopAttrib(GL_ENABLE_BIT) mishandled multi-texture enables + - fixed some typos/bugs in the VB code + - glDrawPixels(GL_COLOR_INDEX) to RGB window didn't work + - optimized glDrawPixels paths weren't being used + - per-fragment fog calculation didn't work without a Z buffer + - improved blending accuracy, fixes Glean blendFunc test failures + - glPixelStore(GL_PACK/UNPACK_SKIP_IMAGES) wasn't handled correctly + - glXGetProcAddressARB() didn't always return the right address + - gluBuild[12]DMipmaps() didn't grok the GL_BGR pixel format + - texture matrix changes weren't always detected (GLUT projtex demo) + - fixed random color problem in vertex fog code + - fixed Glide-related bug that let Quake get a 24-bit Z buffer + Changes: + - finished internal support for compressed textures for DRI + + +3.4.1 February 14, 2001 + New: + - fixed some Linux build problems + - fixed some Windows build problems + - GL_EXT_texture_env_dot3 extension (Gareth Hughes) + Bug fixes: + - added RENDER_START/RENDER_FINISH macros for glCopyTexImage in DRI + - various state-update code changes needed for DRI bugs + - disabled pixel transfer ops in glColorTable commands, not needed + - fixed bugs in glCopyConvolutionFilter1D/2D, glGetConvolutionFilter + - updated sources and fixed compile problems in widgets-mesa/ + - GLX_PBUFFER enum value was wrong in glx.h + - fixed a glColorMaterial lighting bug + - fixed bad args to Read/WriteStencilSpan in h/w stencil clear function + - glXCopySubBufferMESA() Y position was off by one + - Error checking of glTexSubImage3D() was broken (bug 128775) + - glPopAttrib() didn't restore all derived Mesa state correctly + - Better glReadPixels accuracy for 16bpp color - fixes lots of OpenGL + conformance problems at 16bpp. + - clearing depth buffer with scissoring was broken, would segfault + - OSMesaGetDepthBuffer() returned bad bytesPerValue value + - fixed a line clipping bug (reported by Craig McDaniel) + - fixed RGB color over/underflow bug for very tiny triangles + Known problems: + - NURBS or evaluator surfaces inside display lists don't always work + + +3.4.2 May 17, 2001 + Bug fixes: + - deleting the currently bound texture could cause bad problems + - using fog could result in random vertex alpha values + - AA triangle rendering could touch pixels outside right window bound + - fixed byteswapping problem in clear_32bit_ximage() function + - fixed bugs in wglUseFontBitmapsA(), by Frank Warmerdam + - fixed memory leak in glXUseXFont() + - fragment sampling in AA triangle function was off by 1/2 pixel + - Windows: reading pixels from framebuffer didn't always work + - glConvolutionFilter2D could segfault or cause FP exception + - fixed segfaults in FX and X drivers when using tex unit 1 but not 0 + - GL_NAND logicop didn't work right in RGBA mode + - fixed a memory corruption bug in vertex buffer reset code + - clearing the softwara alpha buffer with scissoring was broken + - fixed a few color index mode fog bugs + - fixed some bad assertions in color index mode + - fixed FX line 'stipple' bug #420091 + - fixed stencil buffer clear width/height typo + - fixed GL error glitches in gl[Client]ActiveTextureARB() + - fixed Windows compilation problem in texutil.c + - fixed 1/8-pixel AA triangle sampling error + Changes: + - optimized writing mono-colored pixel spans to X pixmaps + - increased max viewport size to 2048 x 2048 + + +3.5 June 21, 2001 + New: + - internals of Mesa divided into modular pieces (Keith Whitwell) + - 100% OpenGL 1.2 conformance (passes all conformance tests) + - new AA line algorithm + - GL_EXT_convolution extension + - GL_ARB_imaging subset + - OSMesaCreateContextExt() function + - GL_ARB_texture_env_add extension (same as GL_EXT_texture_env_add) + - GL_MAX_TEXTURE_UNITS_ARB now defaults to eight + - GL_EXT_fog_coord extension (Keith Whitwell) + - GL_EXT_secondary_color extension (Keith Whitwell) + - GL_ARB_texture_env_add extension (same as GL_EXT_texture_env_add) + - GL_SGIX_depth_texture extension + - GL_SGIX_shadow and GL_SGIX_shadow_ambient extensions + - demos/shadowtex.c demo of GL_SGIX_depth_texture and GL_SGIX_shadow + - GL_ARB_texture_env_combine extension + - GL_ARB_texture_env_dot3 extension + - GL_ARB_texture_border_clamp (aka GL_SGIS_texture_border_clamp) + - OSMesaCreateContextExt() function + - libOSMesa.so library, contains the OSMesa driver interface + - GL/glxext.h header file for GLX extensions + - somewhat faster software texturing, fogging, depth testing + - all color-index conformance tests now pass (only 8bpp tested) + - SPARC assembly language TCL optimizations (David Miller) + - GL_SGIS_generate_mipmap extension + Bug Fixes: + - fbiRev and tmuRev were unitialized when using Glide3 + - fixed a few color index mode conformance failures; all pass now + - now appling antialiasing coverage to alpha after texturing + - colors weren't getting clamped to [0,1] before color table lookup + - fixed RISC alignment errors caused by COPY_4UBV macro + - drawing wide, flat-shaded lines could cause a segfault + - vertices now snapped to 1/16 pixel to fix rendering of tiny triangles + Changes: + - SGI's Sample Implementation (SI) 1.3 GLU library replaces Mesa GLU + - new libOSMesa.so library, contains the OSMesa driver interface + + +4.0 October 22, 2001 + New: + - Mesa 4.0 implements the OpenGL 1.3 specification + - GL_IBM_rasterpos_clip extension + - GL_EXT_texture_edge_clamp extension (aka GL_SGIS_texture_edge_clamp) + - GL_ARB_texture_mirrored_repeat extension + - WindML UGL driver (Stephane Raimbault) + - added OSMESA_MAX_WIDTH/HEIGHT queries + - attempted compiliation fixes for Solaris 5, 7 and 8 + - updated glext.h and glxext.h files + - updated Windows driver (Karl Schultz) + Bug fixes: + - added some missing GLX 1.3 tokens to include/GL/glx.h + - GL_COLOR_MATRIX changes weren't recognized by teximage functions + - glCopyPixels with scale and bias was broken + - glRasterPos with lighting could segfault + - glDeleteTextures could leave a dangling pointer + - Proxy textures for cube maps didn't work + - fixed a number of 16-bit color channel bugs + - fixed a few minor memory leaks + - GLX context sharing was broken in 3.5 + - fixed state-update bugs in glPopClientAttrib() + - fixed glDrawRangeElements() bug + - fixed a glPush/PopAttrib() bug related to texture binding + - flat-shaded, textured lines were broken + - fixed a dangling pointer problem in the XMesa code (Chris Burghart) + - lighting didn't always produce the correct alpha value + - fixed 3DNow! code to not read past end of arrays (Andrew Lewycky) + + +4.0.1 December 17, 2001 + New: + - better sub-pixel sample positions for AA triangles (Ray Tice) + - slightly faster blending for (GL_ZERO, GL_ONE) and (GL_ONE, GL_ZERO) + Bug fixes: + - added missing break statements in glGet*() for multisample cases + - fixed uninitialized hash table mutex bug (display lists / texobjs) + - fixed bad teximage error check conditional (bug 476846) + - fixed demos readtex.c compilation problem on Windows (Karl Schultz) + - added missing glGet() query for GL_MAX_TEXTURE_LOD_BIAS_EXT + - silence some compiler warnings (gcc 2.96) + - enable the #define GL_VERSION_1_3 in GL/gl.h + - added GL 1.3 and GLX 1.4 entries to gl_mangle.h and glx_mangle.h + - fixed glu.h typedef problem found with MSDev 6.0 + - build libGL.so with -Bsymbolic (fixes bug found with Chromium) + - added missing 'const' to glXGetContextIDEXT() in glxext.h + - fixed a few glXGetProcAddress() errors (texture compression, etc) + - fixed start index bug in compiled vertex arrays (Keith) + - fixed compilation problems in src/SPARC/glapi_sparc.S + - fixed triangle strip "parity" bug found in VTK medical1 demo (Keith) + - use glXGetProcAddressARB in GLUT to avoid extension linking problems + - provoking vertex of flat-shaded, color-index triangles was wrong + - fixed a few display list bugs (GLUT walker, molecule, etc) (Keith) + - glTexParameter didn't flush the vertex buffer (Ray Tice) + - feedback attributes for glDraw/CopyPixels and glBitmap were wrong + - fixed bug in normal length caching (ParaView lighting bug) + - fixed separate_specular color bug found in Chimera (18 Dec 2001) + + +4.0.2 April 2, 2002 + New: + - New DOS (DJGPP) driver written by Daniel Borca + - New driver interface functions for TCL drivers (such as Radeon DRI) + - GL_RENDERER string returns "Mesa Offscreen16" or "Mesa Offscreen32" + if using deep color channels + - latest GL/glext.h and GL/glxext.h headers from SGI + Bug fixes: + - GL_BLEND with non-black texture env color wasn't always correct + - GL_REPLACE with GL_RGB texture format wasn't always correct (alpha) + - glTexEnviv( pname != GL_TEXTURE_ENV_COLOR ) was broken + - glReadPixels was sometimes mistakenly clipped by the scissor box + - glDraw/ReadPixels didn't catch all the errors that they should have + - Fixed 24bpp rendering problem in Windows driver (Karl Schultz) + - 16-bit GLchan mode fixes (m_trans_tmp.h, s_triangle.c) + - Fixed 1-bit float->int conversion bug in glDrawPixels(GL_DEPTH_COMP) + - glColorMask as sometimes effecting glXSwapBuffers() + - fixed a potential bug in XMesaGarbageCollect() + - N threads rendering into one window didn't work reliably + - glCopyPixels didn't work for deep color channels + - improved 8 -> 16bit/channel texture image conversion (Gerk Huisma) + - glPopAttrib() didn't correctly restore user clip planes + - user clip planes failed for some perspective projections (Chromium) + Known bugs: + - mipmap LOD computation + + +4.0.3 June 25, 2002 + New: + - updated GL/glext.h file (version 15) + - corrected MMX blend code (Jose Fonseca) + - support for software-based alpha planes in Windows driver + - updated GGI driver (Filip Spacek) + Bug fixes: + - glext.h had wrong values for GL_DOT3_RGB[A]_EXT tokens + - OSMesaMakeCurrent() didn't recognize buffer size changes + - assorted conformance fixes for 16-bit/channel rendering + - texcombine alpha subtraction mode was broken + - fixed lighting bug with non-uniform scaling and display lists + - fixed bug when deleting shared display lists + - disabled SPARC cliptest assembly code (Mesa bug 544665) + - fixed a couple Solaris compilation/link problems + - blending clipped glDrawPixels didn't always work + - glGetTexImage() didn't accept packed pixel types + - glPixelMapu[is]v() could explode given too large of pixelmap + - glGetTexParameter[if]v() didn't accept GL_TEXTURE_MAX_ANISOTROPY_EXT + - glXCopyContext() could lead to segfaults + - glCullFace(GL_FRONT_AND_BACK) didn't work (bug 572665) + Changes: + - lots of C++ (g++) code clean-ups + - lots of T&L updates for the Radeon DRI driver + Known bugs: + - mipmap LOD computation (fixed for Mesa 4.1) + + +4.0.4 October 3, 2002 + New: + - GL_NV_texture_rectangle extension + - updated glext.h header (version 17) + - updated DOS driver (Daniel Borca) + - updated BeOS R5 driver (Philippe Houdoin) + - added GL_IBM_texture_mirror_repeat + - glxinfo now takes -l option to print interesting OpenGL limits info + - GL_MESA_ycbcr_texture extension + - GL_APPLE_client_storage extension (for some DRI drivers only) + - GL_MESA_pack_invert extension + Bug fixes: + - fixed GL_LINEAR fog bug by adding clamping + - fixed FP exceptions found using Alpha CPU + - 3dfx MESA_GLX_FX=window (render to window) didn't work + - fixed memory leak in wglCreateContest (Karl Schultz) + - define GLAPIENTRY and GLAPI if undefined in glu.h + - wglGetProcAddress didn't handle all API functions + - when testing for OpenGL 1.2 vs 1.3, check for GL_ARB_texture_cube_map + - removed GL_MAX_CONVOLUTION_WIDTH/HEIGHT from glGetInteger/Float/etc() + - error checking in compressed tex image functions had some glitches + - fixed AIX compile problem in src/config.c + - glGetTexImage was using pixel unpacking instead of packing params + - auto-mipmap generation for cube maps was incorrect + Changes: + - max texture units reduced to six to accomodate texture rectangles + - removed unfinished GL_MESA_sprite_point extension code + + +4.1 October 29, 2002 + New: + - GL_NV_vertex_program extension + - GL_NV_vertex_program1_1 extension + - GL_ARB_window_pos extension + - GL_ARB_depth_texture extension + - GL_ARB_shadow extension + - GL_ARB_shadow_ambient extension + - GL_EXT_shadow_funcs extension + - GL_ARB_point_parameters extension + - GL_ARB_texture_env_crossbar + - GL_NV_point_sprite extension + - GL_NV_texture_rectangle extension + - GL_EXT_multi_draw_arrays extension + - GL_EXT_stencil_two_side extension + - GLX_SGIX_fbconfig and GLX_SGIX_pbuffer extensions + - GL_ATI_texture_mirror_once extension (Ian Romanick) + - massive overhaul/simplification of software rasterizer module, + many contributions from Klaus Niederkrueger + - faster software texturing in some cases (i.e. trilinear filtering) + - new OSMesaGetProcAddress() function + - more blend modes implemented with MMX code (Jose Fonseca) + - added glutGetProcAddress() to GLUT + - added GLUT_FPS env var to compute frames/second in glutSwapBuffers() + - pbinfo and pbdemo PBuffer programs + - glxinfo -v prints transprent pixel info (Gerd Sussner) + Bug fixes: + - better mipmap LOD computation (prevents excessive blurriness) + - OSMesaMakeCurrent() didn't recognize buffer size changes + - assorted conformance fixes for 16-bit/channel rendering + - texcombine alpha subtraction mode was broken + - fixed some blend problems when GLchan==GLfloat (Gerk Huisma) + - clamp colors to [0,inf] in OSMesa if GLchan==GLfloat (Gerk Huisma) + - fixed divide by zero error in NURBS tessellator (Jon Perry) + - fixed GL_LINEAR fog bug by adding clamping + - fixed FP exceptions found using Alpha CPU + - 3dfx/glide driver render-to-window feature was broken + - added missing GLX_TRANSPARENT_RGB token to glx.h + - fixed error checking related to paletted textures + - fixed reference count error in glDeleteTextures (Randy Fayan) + Changes: + - New spec file and Python code to generate some GL dispatch files + - Glide driver defaults to "no" with autoconf/automake + - updated demos/stex3d with new options + + +5.0 November 13, 2002 + New: + - OpenGL 1.4 support (glGetString(GL_VERSION) returns "1.4") + - removed some overlooked debugging code + - glxinfo updated to support GLX_ARB_multisample + - GLUT now support GLX_ARB_multisample + - updated DOS driver (Daniel Borca) + Bug fixes: + - GL_POINT and GL_LINE-mode polygons didn't obey cull state + - fixed potential bug in _mesa_align_malloc/calloc() + - fixed missing triangle bug when running vertex programs + - fixed a few HPUX compilation problems + - FX (Glide) driver didn't compile + - setting GL_TEXTURE_BORDER_COLOR with glTexParameteriv() didn't work + - a few EXT functions, like glGenTexturesEXT, were no-ops + - a few OpenGL 1.4 functions like glFogCoord*, glBlendFuncSeparate, + glMultiDrawArrays and glMultiDrawElements were missing + - glGet*(GL_ACTIVE_STENCIL_FACE_EXT) was broken + - Pentium 4 Mobile was mistakenly identified as having 3DNow! + - fixed one-bit error in point/line fragment Z calculation + - fixed potential segfault in fakeglx code + - fixed color overflow problem in DOT3 texture env mode + + +5.0.1 March 30, 2003 + New: + - DOS driver updates from Daniel Borca + - updated GL/gl_mangle.h file (Bill Hoffman) + Bug fixes: + - auto mipmap generation for cube maps was broken (bug 641363) + - writing/clearing software alpha channels was unreliable + - minor compilation fixes for OS/2 (Evgeny Kotsuba) + - fixed some bad assertions found with shadowtex demo + - fixed error checking bug in glCopyTexSubImage2D (bug 659020) + - glRotate(angle, -x, 0, 0) was incorrect (bug 659677) + - fixed potential segfault in texture object validation (bug 659012) + - fixed some bogus code in _mesa_test_os_sse_exception_support (Linus) + - fix fog stride bug in tnl code for h/w drivers (Michel Danzer) + - fixed glActiveTexture / glMatrixMode(GL_TEXTURE) bug (#669080) + - glGet(GL_CURRENT_SECONDARY_COLOR) should return 4 values, not 3 + - fixed compilation problem on Solaris7/x86 (bug 536406) + - fixed prefetch bug in 3DNow! code (Felix Kuhling) + - fixed NeXT build problem (FABSF macro) + - glDrawPixels Z values when glPixelZoom!=1 were invalid (bug 687811) + - zoomed glDraw/CopyPixels with clipping sometimes failed (bug 689964) + - AA line and triangle Z values are now rounded, not truncated + - fixed color interpolation bug when GLchan==GLfloat (bug 694461) + - glArePrograms/TexturesResident() wasn't 100% correct (Jose Fonseca) + - fixed a minor GL_COLOR_MATERIAL bug + - NV vertex program EXP instruction was broken + - glColorMask misbehaved with X window / pixmap rendering + - fix autoconf/libtool GLU C++ linker problem on Linux (a total hack) + - attempt to fix GGI compilation problem when MesaDemos not present + - NV vertex program ARL-relative fetches didn't work + Changes: + - use glPolygonOffset in gloss demo to avoid z-fighting artifacts + - updated winpos and pointblast demos to use ARB extensions + - disable SPARC normal transformation code (bug 673938) + - GLU fixes for OS/2 (Evgeny Kotsuba) + + +5.0.2 September 5, 2003 + Bug fixes: + - fixed texgen problem causing texcoord's Q to be zero (stex3d) + - default GL_TEXTURE_COMPARE_MODE_ARB was wrong + - GL_CURRENT_MATRIX_NV query was wrong + - GL_CURRENT_MATRIX_STACK_DEPTH_NV query was off by one + - GL_LIST_MODE query wasn't correct + - GL_FOG_COORDINATE_SOURCE_EXT query wasn't supported + - GL_SECONDARY_COLOR_ARRAY_SIZE_EXT query returned wrong value + - blended, wide lines didn't always work correctly (bug 711595) + - glVertexAttrib4svNV w component was always 1 + - fixed bug in GL_IBM_rasterpos_clip (missing return) + - GL_DEPTH_TEXTURE_MODE = GL_ALPHA didn't work correctly + - a few Solaris compilation fixes + - fixed glClear() problem for DRI drivers (non-existant stencil, etc) + - fixed int/REAL mixup in GLU NURBS curve evaluator (Eric Cazeaux) + - fixed delete [] bug in SI GLU (bug 721765) (Diego Santa Cruz) + - glFog() didn't clamp fog colors + - fixed bad float/int conversion for GL_TEXTURE_PRIORITY in the + gl[Get]TexParameteri[v] functions + - fixed invalid memory references in glTexGen functions (bug 781602) + - integer-valued color arrays weren't handled correctly + - glDrawPixels(GL_DEPTH_COMPONENT) with glPixelZoom didn't work + - GL_EXT_texture_lod_bias is part of 1.4, overlooked in 5.0.1 + Changes: + - build GLUT with -fexceptions so C++ apps propogate exceptions + + +5.1 December 17, 2003 + New: + - reorganized directory tree + - GL_ARB_vertex/fragment_program extensions (Michal Krol & Karl Rasche) + - GL_ATI_texture_env_combine3 extension (Ian Romanick) + - GL_SGI_texture_color_table extension (Eric Plante) + - GL_NV_fragment_program extension + - GL_NV_light_max_exponent extension + - GL_EXT_texture_rectangle (identical to GL_NV_texture_rectangle) + - GL_ARB_occlusion_query extension + - GL_ARB_point_sprite extension + - GL_ARB_texture_non_power_of_two extension + - GL_IBM_multimode_draw_arrays extension + - GL_EXT_texture_mirror_clamp extension (Ian Romanick) + - GL_ARB_vertex_buffer_object extension + - new X86 feature detection code (Petr Sebor) + - less memory used for display lists and vertex buffers + - demo of per-pixel lighting with a fragment program (demos/fplight.c) + - new version (18) of glext.h header + - new spriteblast.c demo of GL_ARB_point_sprite + - faster glDrawPixels in X11 driver in some cases (see RELNOTES-5.1) + - faster glCopyPixels in X11 driver in some cases (see RELNOTES-5.1) + Bug fixes: + - really enable OpenGL 1.4 features in DOS driver. + - fixed issues in glDrawPixels and glCopyPixels for very wide images + - glPixelMapf/ui/usv()'s size parameter is GLsizei, not GLint + - fixed some texgen bugs reported by Daniel Borca + - fixed wglMakeCurrent(NULL, NULL) bug (#835861) + - fixed glTexSubImage3D z-offset bug (Cedric Gautier) + - fixed RGBA blend enable bug (Ville Syrjala) + - glAccum is supposed to be a no-op in selection/feedback mode + - fixed texgen bug #597589 (John Popplewell) + Changes: + - dropped API trace feature (src/Trace/) + - documentation overhaul. merged with website content. more html. + - glxgears.c demo updated to use GLX swap rate extensions + - glTexImage1/2/3D now allows width/height/depth = 0 + - disable SPARC asm code on Linux (bug 852204) + + +6.0 January 16, 2004 + New: + - full OpenGL 1.5 support + - updated GL/glext.h file to version 21 + Changes: + - changed max framebuffer size to 4Kx4K (MAX_WIDTH/HEIGHT in config.h) + Bug fixes: + - fixed bug in UNCLAMPED_FLOAT_TO_UBYTE macro; solves a color + clamping issue + - updated suno5-gcc configs + - glColor3 functions sometimes resulted in undefined alpha values + - fixed FP divide by zero error seen on VMS with xlockmore, others + - fixed vertex/fragment program debug problem (bug 873011) + - building on AIX with gcc works now + - glDeleteProgramsARB failed for ARB fragment programs (bug 876160) + - glDrawRangeElements tried to modify potentially read-only storage + - updated files for building on Windows + + +6.0.1 April 2, 2004 + New: + - upgraded glext.h to version 22 + - new build targets (Dan Schikore) + - new linux-x86-opteron build target (Heath Feather) + Bug fixes: + - glBindProgramARB didn't update all necessary state + - fixed build problems on OpenBSD + - omit CVS directories from tarballs + - glGetTexImage(GL_COLOR_INDEX) was broken + - fixed an infinite loop in t&l module + - silenced some valgrind warnings about using unitialized memory + - fixed some compilation/link glitches on IRIX (Mike Stephens) + - glBindProgram wasn't getting compiled into display lists + - GLX_FBCONFIG_ID wasn't recognized in glXChooseFBConfig() (bug 888079) + - two-sided lighting and vertex program didn't work (bug 887330) + - stores to program parameter registers in vertex state programs + didn't work. + - fixed glOrtho bug found with gcc 3.2.2 (RH9) + - glXCreateWindow() wasn't fully implemented (bug 890894) + - generic vertex attribute arrays didn't work in display lists + - vertex buffer objects' default usage and access fields were wrong + - glDrawArrays with start!=0 was broken + - fragment program PK2H, UP2H, UP4B and UP4UB instructions were broken + - linux-osmesa16-static config didn't work + - fixed a few color index rendering problems (bug 910687) + - glInterleavedArrays didn't respect GL_CLIENT_ACTIVE_TEXTURE + - OSMesa RGB and BGR modes were broken + - glProgramStringARB mistakenly required a null-terminated string + - fragment program XPD instruction was incorrect + - glGetMaterial() didn't work reliably + - ARB_fragment_program KIL instruction was incorrect + + +6.1 August 18, 2004 + New: + - Revamped Makefile system + - glXUseRotatedXFont() utility (see xdemos/xuserotfont.c) + - internal driver interface changes related to texture object + allocation, vertex/fragment programs, BlendEquationSeparate, etc. + - option to walk triangle edges with double-precision floats + (Justin Novosad of Discreet) (see config.h file) + - support for AUX buffers in software GLX driver + - updated glext.h to version 24 and glxext.h to version 6 + - new MESA_GLX_FORCE_ALPHA and MESA_GLX_DEPTH_BITS env vars + - updated BeOS support (Philippe Houdoin) + Changes: + - fragment fog interpolation is perspective corrected now + - new glTexImage code, much cleaner, may be a bit faster + Bug fixes: + - glArrayElement in display lists didn't handle generic vertex attribs + - glFogCoord didn't always work properly + - ARB_fragment_program fog options didn't work + - frag prog TEX instruction no longer incorrectly divides s,t,r by q + - ARB frag prog TEX and TEXP instructions now use LOD=0 + - glTexEnviv in display lists didn't work + - glRasterPos didn't do texgen or apply texture matrix + - GL_DOUBLE-valued vertex arrays were broken in some cases + - fixed texture rectangle edge/border sampling bugs + - sampling an incomplete texture in a fragment program would segfault + - glTexImage was missing a few error checks + - fixed some minor glGetTexParameter glitches + - GL_INTENSITY was mistakenly accepted as a to glTexImage + - fragment program writes to RC/HC register were broken + - fixed a few glitches in GL_HP_occlusion_test extension + - glBeginQueryARB and glEndQueryARB didn't work inside display lists + - vertex program state references were broken + - fixed triangle color interpolation bug on AIX (Shane Blackett) + - fixed a number of minor memory leaks (bug #1002030) + + +6.2 October 2, 2004 + New: + - enabled GL_ARB_texture_rectangle (same as GL_NV_texture_rectangle) + - updated Doxygen support (Jose Fonseca) + Changes: + - some GGI driver updates (Christoph Egger, bug 1025977) + Bug fixes: + - Omit GL_ARB_texture_non_power_of_two from list of OpenGL 1.5 features + - fixed a few compilation issues on IRIX + - fixed a matrix classification bug (reported by Wes Bethel) + - we weren't reseting the vertex/fragment program error state + before parsing (Dave Reveman) + - adjust texcoords for sampling texture rectangles (Dave Reveman) + - glGet*(GL_MAX_VERTEX_ATTRIBS_ARB) wasn't implemented + - repeated calls to glDeleteTexture(t) could lead to a crash + - fixed potential ref count bugs in VBOs and vertex/fragment programs + - spriteblast demo didn't handle window size changes correctly + - glTexSubImage didn't handle pixels=NULL correctly for PBOs + - fixed color index mode glDrawPixels bug (Karl Schultz) + + +6.2.1 December 9, 2004 + Bug fixes: + - don't apply regular fog or color sum when using a fragment program + - glProgramEnvParameter4fARB always generated an error on + GL_FRAGMENT_PROGRAM_ARB (fdo bug 1645) + - glVertexAttrib3svNV and glVertexAttrib3svARB were broken + - fixed width/height mix-up in glSeparableFilter2D() + - fixed regression in glCopyPixels + convolution + - glReadPixels from a clipped front color buffer didn't always work + - glTexImage didn't accept GL_RED/GREEN/BLUE as the format + - Attempting queries/accesses of VBO 0 weren't detected as errors + - paletted textures failed if the palette had fewer that 256 entries + Changes: + - fixed a bunch of compiler warnings found with gcc 3.4 + - bug reports should to go bugzilla.freedesktop.org + + +6.2.2 Month day, 2005 + New: + - Updated GL/glext.h to version 28 + Bug fixes: + - fragment program texcoords were sometimes wrong for points and lines + - fixed problem with negative dot product in arbfplight, fplight demos + - fixed bug in perspective correction of antialiased, textured lines + - querying GL_POST_CONVOLUTION_ALPHA_BIAS_EXT returned wrong value + - fixed a couple per-pixel fog bugs (Soju Matsumoto) + - glGetBooleanv(GL_FRAGMENT_PROGRAM_BINDING_NV) was broken + - fixed float parsing bug in ARB frag/vert programs (bug 2520) + - XMesaGetDepthBuffer() returned incorrect value for bytesPerValue + - GL_COLOR_MATERIAL with glColor3 didn't properly set diffuse alpha + - glXChooseFBConfig() crashed if attribList pointer was NULL + - program state.light[n].spot.direction.w was wrong value (bug 3083) + - fragment program fog option required glEnable(GL_FOG) - wrong. + - glColorTable() could produce a Mesa implementation error (bug 3135) + - RasterPos could get corrupted by color index rendering path + - Removed bad XTranslateCoordinates call when rendering to Pixmaps + - glPopAttrib() didn't properly restore GL_TEXTURE_GEN enable state diff --git a/docs/banner.html b/docs/banner.html new file mode 100644 index 0000000..b6d1abb --- /dev/null +++ b/docs/banner.html @@ -0,0 +1,15 @@ + + +Banner + + + + +
+

+The Mesa 3D Graphics Library +

+
+ + + \ No newline at end of file diff --git a/docs/bugs.html b/docs/bugs.html new file mode 100644 index 0000000..0ace151 --- /dev/null +++ b/docs/bugs.html @@ -0,0 +1,47 @@ + + +Mesa Bug Reporting + + + +

Bug Database

+ +

+The Mesa bug database is now hosted on +freedesktop.org +instead of SourceForge. +

+ +

+To file a Mesa bug, go to + +Bugzilla on freedesktop.org +

+ +

+Please follow these bug reporting guidelines: +

+ +
    +
  • Make sure you're using the most recent version of Mesa +
  • Make sure your bug isn't already reported +
  • Include as much information as possible in the report +
  • Provide a simple GLUT-based test program if possible +
  • Check back for follow-ups to the report +
+ +

+Bug reports will automatically be forwarded to the Mesa developer's mailing +list. +

+ +

+The easier a bug is to reproduce, the sooner it will be fixed. +Please do everything you can to facilitate quickly fixing bugs. +If your bug report is vague or your test program doesn't compile +easily, the problem may not be fixed very quickly. +

+ + + diff --git a/docs/conform.html b/docs/conform.html new file mode 100644 index 0000000..eded6a7 --- /dev/null +++ b/docs/conform.html @@ -0,0 +1,693 @@ + + +Conformance + + + +

Conformance

+ +

+The SGI OpenGL conformance tests verify correct operation of OpenGL +implementations. I, Brian Paul, have been given a copy of the tests +for testing Mesa. The tests are not publically available. +

+

+This file has the latest results of testing Mesa with the OpenGL 1.2 +conformance tests. Testing with the preliminary OpenGL 1.3 tests has +also been done. Mesa passes all the 1.3 tests. +

+

+The tests were run using the software X11 device driver on 24-bpp +and 16-bpp displays. +

+

+Mesa 4.0 and later pass all conformance tests at all path levels. +Note that this says nothing about the conformance of hardware drivers +based upon Mesa. +

+ + +
+
+COVERAGE TESTS
+--------------
+
+Test that all API functions accept the legal parameters and reject
+illegal parameters.  The result of each test is either pass or fail.
+
+% covgl
+OpenGL Coverage Test.
+Version 1.2
+
+covgl passed.
+
+covgl passed at 1.1 level.
+
+covgl passed at 1.2 level.
+
+covgl passed for ARB_multitexture.
+
+
+% covglu
+OpenGL GLU Coverage Test.
+Version 1.3
+
+covglu passed.
+
+covglu passed at 1.1 level.
+
+
+% covglx
+OpenGL X Coverage Test.
+Version 1.1.1
+
+covglx passed.
+
+
+% primtest -v
+Open GL Primitives Test.
+Version 1.2
+
+[lots of output deleted]
+
+292159 Combinations.
+primtest passed.
+
+
+
+
+GL CONFORMANCE TEST
+===================
+
+Render test images, read them back, then test for expected results.
+
+
+----------------------------------------------------------------------
+% conform -v 2
+
+OpenGL Conformance Test
+Version 1.2
+
+Setup Report.
+    Verbose level = 2.
+    Random number seed = 1.
+    Path inactive.
+
+Visual Report.
+    Display ID = 35. Indirect Rendering.
+    Double Buffered.
+    RGBA (5, 6, 5, 0).
+    Stencil (8).
+    Depth (16).
+    Accumulation (16, 16, 16, 16).
+
+Epsilon Report.
+    zero error epsilon = 0.000122.
+    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
+    Depth buffer error epsilon = 0.000137.
+    Stencil plane error epsilon = 0.00404.
+    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
+
+Default State test passed.
+Must Pass test passed.
+Divide By Zero test passed.
+Viewport Clamp test passed.
+Matrix Stack test passed.
+Matrix Stack Mixing test passed.
+Vertex Order test passed.
+Transformations test passed.
+Transformation Normal test passed.
+Viewport Transformation test passed.
+Buffer Clear test passed.
+Buffer Corners test passed.
+Buffer Color test passed.
+Color Ramp test passed.
+Mask test passed.
+Buffer Invariance test passed.
+Accumulation Buffer test passed.
+Select test passed.
+Feedback test passed.
+Scissor test passed.
+Alpha Plane Function test passed.
+Stencil Plane Clear test passed.
+Stencil Plane Corners test passed.
+Stencil Plane Operation test passed.
+Stencil Plane Function test passed.
+Depth Buffer Clear test passed.
+Depth Buffer Function test passed.
+Blend test passed.
+Dither test passed.
+LogicOp Function test does not exist for an RGB visual.
+DrawPixels test passed.
+CopyPixels test passed.
+Bitmap Rasterization test passed.
+Point Rasterization test passed.
+Anti-aliased Point test passed.
+Line Rasterization test passed.
+Line Stipple test passed.
+Anti-aliased Line test passed.
+Horizontal and Vertical Line test passed.
+Triangle Rasterization test passed.
+Triangle Tile test passed.
+Triangle Stipple test passed.
+Anti-aliased Triangles test passed.
+Quad Rasterization test passed.
+Polygon Face test passed.
+Polygon Cull test passed.
+Polygon Stipple test passed.
+Polygon Edge test passed.
+Ambient Material test passed.
+Ambient Scene test passed.
+Attenuation Position test passed.
+Diffuse Light test passed.
+Diffuse Material test passed.
+Diffuse Material Normal test passed.
+Diffuse Material Positioning test passed.
+Emissive Material test passed.
+Specular Exponent test passed.
+Specular Exponent Normal test passed.
+Specular Local Eye Half Angle test passed.
+Specular Light test passed.
+Specular Material test passed.
+Specular Normal test passed.
+Spot Positioning test passed.
+Spot Exponent and Positioning test passed.
+Spot Exponent and Direction test passed.
+Fog Exponential test passed.
+Fog Linear test passed.
+Texture Decal test passed.
+Texture Border test passed.
+Mipmaps Selection test passed.
+Mipmaps Interpolation test passed.
+Display Lists test passed.
+Evaluator test passed.
+Evaluator Color test passed.
+Texture Edge Clamp test passed.
+Packed Pixels test passed.
+Texture LOD test passed.
+Rescale Normal test passed.
+Color Table test passed.
+Convolution test passed.
+Convolution Border test passed.
+Histogram test passed.
+MinMax test passed.
+MultiTexture test passed.
+
+Conform passed.
+
+----------------------------------------------------------------------
+% conform -v 2 -p 1
+
+OpenGL Conformance Test
+Version 1.2
+
+Setup Report.
+    Verbose level = 2.
+    Random number seed = 1.
+    Path level = 1.
+
+Visual Report.
+    Display ID = 35. Indirect Rendering.
+    Double Buffered.
+    RGBA (5, 6, 5, 0).
+    Stencil (8).
+    Depth (16).
+    Accumulation (16, 16, 16, 16).
+
+Epsilon Report.
+    zero error epsilon = 0.000122.
+    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
+    Depth buffer error epsilon = 0.000137.
+    Stencil plane error epsilon = 0.00404.
+    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
+
+Default State test passed.
+Must Pass test passed.
+Divide By Zero test passed.
+Viewport Clamp test passed.
+Matrix Stack test passed.
+Matrix Stack Mixing test passed.
+Vertex Order test passed.
+Transformations test passed.
+Transformation Normal test passed.
+Viewport Transformation test passed.
+Buffer Clear test passed.
+Buffer Corners test passed.
+Buffer Color test passed.
+Color Ramp test passed.
+Mask test passed.
+Buffer Invariance test passed.
+Accumulation Buffer test passed.
+Select test passed.
+Feedback test passed.
+Scissor test passed.
+Alpha Plane Function test passed.
+Stencil Plane Clear test passed.
+Stencil Plane Corners test passed.
+Stencil Plane Operation test passed.
+Stencil Plane Function test passed.
+Depth Buffer Clear test passed.
+Depth Buffer Function test passed.
+Blend test passed.
+Dither test passed.
+LogicOp Function test does not exist for an RGB visual.
+DrawPixels test passed.
+CopyPixels test passed.
+Bitmap Rasterization test passed.
+Point Rasterization test passed.
+Anti-aliased Point test passed.
+Line Rasterization test passed.
+Line Stipple test passed.
+Anti-aliased Line test passed.
+Horizontal and Vertical Line test passed.
+Triangle Rasterization test passed.
+Triangle Tile test passed.
+Triangle Stipple test passed.
+Anti-aliased Triangles test passed.
+Quad Rasterization test passed.
+Polygon Face test passed.
+Polygon Cull test passed.
+Polygon Stipple test passed.
+Polygon Edge test passed.
+Ambient Material test passed.
+Ambient Scene test passed.
+Attenuation Position test passed.
+Diffuse Light test passed.
+Diffuse Material test passed.
+Diffuse Material Normal test passed.
+Diffuse Material Positioning test passed.
+Emissive Material test passed.
+Specular Exponent test passed.
+Specular Exponent Normal test passed.
+Specular Local Eye Half Angle test passed.
+Specular Light test passed.
+Specular Material test passed.
+Specular Normal test passed.
+Spot Positioning test passed.
+Spot Exponent and Positioning test passed.
+Spot Exponent and Direction test passed.
+Fog Exponential test passed.
+Fog Linear test passed.
+Texture Decal test passed.
+Texture Border test passed.
+Mipmaps Selection test passed.
+Mipmaps Interpolation test passed.
+Display Lists test passed.
+Evaluator test passed.
+Evaluator Color test passed.
+Texture Edge Clamp test passed.
+Packed Pixels test passed.
+Texture LOD test passed.
+Rescale Normal test passed.
+Color Table test passed.
+Convolution test passed.
+Convolution Border test passed.
+Histogram test passed.
+MinMax test passed.
+MultiTexture test passed.
+
+Conform passed.
+
+----------------------------------------------------------------------
+% conform -v 2 -p 2
+
+OpenGL Conformance Test
+Version 1.2
+
+Setup Report.
+    Verbose level = 2.
+    Random number seed = 1.
+    Path level = 2.
+
+Visual Report.
+    Display ID = 35. Indirect Rendering.
+    Double Buffered.
+    RGBA (5, 6, 5, 0).
+    Stencil (8).
+    Depth (16).
+    Accumulation (16, 16, 16, 16).
+
+Epsilon Report.
+    zero error epsilon = 0.000122.
+    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
+    Depth buffer error epsilon = 0.000137.
+    Stencil plane error epsilon = 0.00404.
+    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
+
+Default State test passed.
+Must Pass test passed.
+Divide By Zero test passed.
+Viewport Clamp test passed.
+Matrix Stack test passed.
+Matrix Stack Mixing test passed.
+Vertex Order test passed.
+Transformations test passed.
+Transformation Normal test passed.
+Viewport Transformation test passed.
+Buffer Clear test passed.
+Buffer Corners test passed.
+Buffer Color test passed.
+Color Ramp test passed.
+Mask test passed.
+Buffer Invariance test passed.
+Accumulation Buffer test passed.
+Select test passed.
+Feedback test passed.
+Scissor test passed.
+Alpha Plane Function test passed.
+Stencil Plane Clear test passed.
+Stencil Plane Corners test passed.
+Stencil Plane Operation test passed.
+Stencil Plane Function test passed.
+Depth Buffer Clear test passed.
+Depth Buffer Function test passed.
+Blend test passed.
+Dither test passed.
+LogicOp Function test does not exist for an RGB visual.
+DrawPixels test passed.
+CopyPixels test passed.
+Bitmap Rasterization test passed.
+Point Rasterization test passed.
+Anti-aliased Point test passed.
+Line Rasterization test passed.
+Line Stipple test passed.
+Anti-aliased Line test passed.
+Horizontal and Vertical Line test passed.
+Triangle Rasterization test passed.
+Triangle Tile test passed.
+Triangle Stipple test passed.
+Anti-aliased Triangles test passed.
+Quad Rasterization test passed.
+Polygon Face test passed.
+Polygon Cull test passed.
+Polygon Stipple test passed.
+Polygon Edge test passed.
+Ambient Material test passed.
+Ambient Scene test passed.
+Attenuation Position test passed.
+Diffuse Light test passed.
+Diffuse Material test passed.
+Diffuse Material Normal test passed.
+Diffuse Material Positioning test passed.
+Emissive Material test passed.
+Specular Exponent test passed.
+Specular Exponent Normal test passed.
+Specular Local Eye Half Angle test passed.
+Specular Light test passed.
+Specular Material test passed.
+Specular Normal test passed.
+Spot Positioning test passed.
+Spot Exponent and Positioning test passed.
+Spot Exponent and Direction test passed.
+Fog Exponential test passed.
+Fog Linear test passed.
+Texture Decal test passed.
+Texture Border test passed.
+Mipmaps Selection test passed.
+Mipmaps Interpolation test passed.
+Display Lists test passed.
+Evaluator test passed.
+Evaluator Color test passed.
+Texture Edge Clamp test passed.
+Packed Pixels test passed.
+Texture LOD test passed.
+Rescale Normal test passed.
+Color Table test passed.
+Convolution test passed.
+Convolution Border test passed.
+Histogram test passed.
+MinMax test passed.
+MultiTexture test passed.
+
+Conform passed.
+
+----------------------------------------------------------------------
+% conform -v 2 -p 3
+
+OpenGL Conformance Test
+Version 1.2
+
+Setup Report.
+    Verbose level = 2.
+    Random number seed = 1.
+    Path level = 3.
+
+Visual Report.
+    Display ID = 35. Indirect Rendering.
+    Double Buffered.
+    RGBA (5, 6, 5, 0).
+    Stencil (8).
+    Depth (16).
+    Accumulation (16, 16, 16, 16).
+
+Epsilon Report.
+    zero error epsilon = 0.000122.
+    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
+    Depth buffer error epsilon = 0.000137.
+    Stencil plane error epsilon = 0.00404.
+    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
+
+Default State test passed.
+Must Pass test passed.
+Divide By Zero test passed.
+Viewport Clamp test passed.
+Matrix Stack test passed.
+Matrix Stack Mixing test passed.
+Vertex Order test passed.
+Transformations test passed.
+Transformation Normal test passed.
+Viewport Transformation test passed.
+Buffer Clear test passed.
+Buffer Corners test passed.
+Buffer Color test passed.
+Color Ramp test passed.
+Mask test passed.
+Buffer Invariance test passed.
+Accumulation Buffer test passed.
+Select test passed.
+Feedback test passed.
+Scissor test passed.
+Alpha Plane Function test passed.
+Stencil Plane Clear test passed.
+Stencil Plane Corners test passed.
+Stencil Plane Operation test passed.
+Stencil Plane Function test passed.
+Depth Buffer Clear test passed.
+Depth Buffer Function test passed.
+Blend test passed.
+Dither test passed.
+LogicOp Function test does not exist for an RGB visual.
+DrawPixels test passed.
+CopyPixels test passed.
+Bitmap Rasterization test passed.
+Point Rasterization test passed.
+Anti-aliased Point test passed.
+Line Rasterization test passed.
+Line Stipple test passed.
+Anti-aliased Line test passed.
+Horizontal and Vertical Line test passed.
+Triangle Rasterization test passed.
+Triangle Tile test passed.
+Triangle Stipple test passed.
+Anti-aliased Triangles test passed.
+Quad Rasterization test passed.
+Polygon Face test passed.
+Polygon Cull test passed.
+Polygon Stipple test passed.
+Polygon Edge test passed.
+Ambient Material test passed.
+Ambient Scene test passed.
+Attenuation Position test passed.
+Diffuse Light test passed.
+Diffuse Material test passed.
+Diffuse Material Normal test passed.
+Diffuse Material Positioning test passed.
+Emissive Material test passed.
+Specular Exponent test passed.
+Specular Exponent Normal test passed.
+Specular Local Eye Half Angle test passed.
+Specular Light test passed.
+Specular Material test passed.
+Specular Normal test passed.
+Spot Positioning test passed.
+Spot Exponent and Positioning test passed.
+Spot Exponent and Direction test passed.
+Fog Exponential test passed.
+Fog Linear test passed.
+Texture Decal test passed.
+Texture Border test passed.
+Mipmaps Selection test passed.
+Mipmaps Interpolation test passed.
+Display Lists test passed.
+Evaluator test passed.
+Evaluator Color test passed.
+Texture Edge Clamp test passed.
+Packed Pixels test passed.
+Texture LOD test passed.
+Rescale Normal test passed.
+Color Table test passed.
+Convolution test passed.
+Convolution Border test passed.
+Histogram test passed.
+MinMax test passed.
+MultiTexture test passed.
+
+Conform passed.
+
+----------------------------------------------------------------------
+% conform -v 2 -p 4
+
+OpenGL Conformance Test
+Version 1.2
+
+Setup Report.
+    Verbose level = 2.
+    Random number seed = 1.
+    Path level = 4.
+
+Visual Report.
+    Display ID = 35. Indirect Rendering.
+    Double Buffered.
+    RGBA (5, 6, 5, 0).
+    Stencil (8).
+    Depth (16).
+    Accumulation (16, 16, 16, 16).
+
+Epsilon Report.
+    zero error epsilon = 0.000122.
+    RGBA error epsilon = 0.0324, 0.016, 0.0324, 0.000122.
+    Depth buffer error epsilon = 0.000137.
+    Stencil plane error epsilon = 0.00404.
+    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
+
+Default State test passed.
+Must Pass test passed.
+Divide By Zero test passed.
+Viewport Clamp test passed.
+Matrix Stack test passed.
+Matrix Stack Mixing test passed.
+Vertex Order test passed.
+Transformations test passed.
+Transformation Normal test passed.
+Viewport Transformation test passed.
+Buffer Clear test passed.
+Buffer Corners test passed.
+Buffer Color test passed.
+Color Ramp test passed.
+Mask test passed.
+Buffer Invariance test passed.
+Accumulation Buffer test passed.
+Select test passed.
+Feedback test passed.
+Scissor test passed.
+Alpha Plane Function test passed.
+Stencil Plane Clear test passed.
+Stencil Plane Corners test passed.
+Stencil Plane Operation test passed.
+Stencil Plane Function test passed.
+Depth Buffer Clear test passed.
+Depth Buffer Function test passed.
+Blend test passed.
+Dither test passed.
+LogicOp Function test does not exist for an RGB visual.
+DrawPixels test passed.
+CopyPixels test passed.
+Bitmap Rasterization test passed.
+Point Rasterization test passed.
+Anti-aliased Point test passed.
+Line Rasterization test passed.
+Line Stipple test passed.
+Anti-aliased Line test passed.
+Horizontal and Vertical Line test passed.
+Triangle Rasterization test passed.
+Triangle Tile test passed.
+Triangle Stipple test passed.
+Anti-aliased Triangles test passed.
+Quad Rasterization test passed.
+Polygon Face test passed.
+Polygon Cull test passed.
+Polygon Stipple test passed.
+Polygon Edge test passed.
+Ambient Material test passed.
+Ambient Scene test passed.
+Attenuation Position test passed.
+Diffuse Light test passed.
+Diffuse Material test passed.
+Diffuse Material Normal test passed.
+Diffuse Material Positioning test passed.
+Emissive Material test passed.
+Specular Exponent test passed.
+Specular Exponent Normal test passed.
+Specular Local Eye Half Angle test passed.
+Specular Light test passed.
+Specular Material test passed.
+Specular Normal test passed.
+Spot Positioning test passed.
+Spot Exponent and Positioning test passed.
+Spot Exponent and Direction test passed.
+Fog Exponential test passed.
+Fog Linear test passed.
+Texture Decal test passed.
+Texture Border test passed.
+Mipmaps Selection test passed.
+Mipmaps Interpolation test passed.
+Display Lists test passed.
+Evaluator test passed.
+Evaluator Color test passed.
+Texture Edge Clamp test passed.
+Packed Pixels test passed.
+Texture LOD test passed.
+Rescale Normal test passed.
+Color Table test passed.
+Convolution test passed.
+Convolution Border test passed.
+Histogram test passed.
+MinMax test passed.
+MultiTexture test passed.
+
+Conform passed.
+
+
+
+GLX CONFORMANCE TEST
+====================
+
+% conformx -v 2
+
+OpenGL X Conformance Test
+Version 1.1.1
+
+Setup Report.
+    Verbose level = 2.
+    Random number seed = 1.
+    Path inactive.
+
+Visual Report.
+    Display ID = 34. Direct Rendering.
+    Double Buffered.
+    RGBA (8, 8, 8, 0).
+    Stencil (8).
+    Depth (16).
+    Accumulation (16, 16, 16, 16).
+
+Epsilon Report.
+    zero error epsilon = 0.000122.
+    RGBA error epsilon = 0.00404, 0.00404, 0.00404, 0.000122.
+    Depth buffer error epsilon = 0.000137.
+    Stencil plane error epsilon = 0.00404.
+    Accumulation error epsilon = 0.000137, 0.000137, 0.000137, 0.000137.
+
+Default State test passed.
+glReadPixels() test passed.
+Font test passed.
+
+Conformx passed.
+
+
+
+ +NOTE: conformx passes for all machine path levels (-p option). + + + + diff --git a/docs/contents.html b/docs/contents.html new file mode 100644 index 0000000..0551986 --- /dev/null +++ b/docs/contents.html @@ -0,0 +1,81 @@ + + +Contents + + + +Documentation + + +Download / Install + + +Resources + + +User Topics + + +Developer Topics + + +Links + + +Sourceforge.net + + + \ No newline at end of file diff --git a/docs/custom.html b/docs/custom.html new file mode 100644 index 0000000..a5cfdeb --- /dev/null +++ b/docs/custom.html @@ -0,0 +1,25 @@ + + +Custom Development + + + +

Custom Development

+ +

+Mesa is primarily developed and maintained on a volunteer basis. +Some Mesa development work has been done in conjuction with contracted +projects, such as the XFree86/DRI drivers. +

+ +

+

[Begin shameless plug]
+If you have a need for specific or custom Mesa development work, + +Tungsten Graphics, Inc. may be able to help you. +
[End shameless plug]
+

+ + + + diff --git a/docs/cvs_access.html b/docs/cvs_access.html new file mode 100644 index 0000000..be8e129 --- /dev/null +++ b/docs/cvs_access.html @@ -0,0 +1,102 @@ + + +CVS Access + + + +

CVS Access

+ +

+Mesa's CVS repository (code management system) is hosted on +freedesktop.org. +

+ +

+You may access the repository either as an +anonymous user (read-only) or as a +developer +(read/write). +

+ +

+You may also +browse the CVS repository. +

+ + + +

Anonymous CVS Access

+ +

+Anonymous, public, read-only access to the CVS repository is available. +Here are the basic instructions for Unix systems: +

+ +
    +
  1. Install CVS client software on your computer if needed. + Version 1.9.28 is known to work. +
  2. Login as an anonymous user: + 
    +    cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/mesa login
+
    + Just press Enter/Return when prompted for a password. +
    +
    +
  3. Check out the code: + 
    +    cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/mesa co Mesa
+
    +
+ + +

To update your Mesa CVS source to the latest CVS source:

+ +
    +
  1. cd Mesa +
  2. cvs -z3 -d:pserver:anonymous@pdx.freedesktop.org:/cvs/mesa update +
+ + + +

Developer CVS Access

+ +

+Mesa developers working with the Mesa CVS repository need to first +have an account on +freedesktop.org. +You can request an account from either +Daniel Stone or +Eric Anholt. +

+ +

+Once your account is established, you can check out the Mesa CVS tree +with: +

+   setenv CVS_RSH ssh        (if using a csh-like shell)
+
+OR +
+   export CVS_RSH=rsh        (if using a bash-like shell)
+
+followed by: +
+   cvs -d:ext:yourusername@pdx.freedesktop.org:/cvs/mesa co Mesa
+
+ +

+Of course, replace yourusername with your actual login name. +

+ +

+Subsequent updates should only require: +

+
+   cvs update
+
+ + + + + diff --git a/docs/cvs_branches.html b/docs/cvs_branches.html new file mode 100644 index 0000000..cc07c58 --- /dev/null +++ b/docs/cvs_branches.html @@ -0,0 +1,78 @@ + + +CVS Branches + + + +

CVS Branch Information

+ +

+At any given time, there may be several active branches in Mesa's +CVS repository. + +Generally, the CVS trunk contains the latest development (unstable) +code while a CVS branch has the latest stable code. +

+ +

+Currently (Oct 2004), the trunk is the Mesa 6.3 development code +while the mesa_6_2_branch branch has the stable Mesa 6.2.x code. +

+ +

+Mesa releases use an even/odd numbering scheme to represent stable/development +releases. + +For example, Mesa 6.2 (0 is considered even) is a stable release while +Mesa 6.3 is a development release. +

+ +

+To checkout a specific CVS branch pass -r and +the branch tag after your CVS command. + +For example cvs checkout -r mesa_6_2_branch Mesa will +checkout the 6.2 branch and cvs update -r +mesa_6_2_branch will convert your current CVS tree to the 6.2 +branch. + +Consult http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54 +for more on branching in CVS. +

+ +

+To see a list of all the CVS branches run cvs log README (or any +other file) and look for the section labeled symbolic names. +You'll see something like this: +

+ +
  symbolic names:
+        mesa_4_0: 1.3
+        mesa_4_0_branch: 1.3.0.6
+        mesa_3_5: 1.3
+        mesa_3_4_2: 1.3
+        mesa_3_4_1: 1.3
+        mesa_3_4: 1.3
+        mesa_3_4_branch: 1.3.0.4
+        mesa_3_3: 1.3
+        mesa_3_2_1: 1.1.1.1
+        mesa_3_3_texture_env_combine2: 1.3.0.2
+        mesa_3_2: 1.1.1.1
+        mesa_3_2_beta_1: 1.1.1.1
+        mesa_3_1: 1.1.1.1
+        mesa_3_2_dev: 1.1.1.1.0.2
+        mesa_3_1_beta_3: 1.1.1.1
+        start: 1.1.1.1
+        mesa: 1.1.1
+
+ +

+Most will be obsolete branches. Generally, the newer branches are at +the top. Ask on the mesa3d-dev mailing list to learn which branches +are active. +

+ + + + \ No newline at end of file diff --git a/docs/debugging.html b/docs/debugging.html new file mode 100644 index 0000000..cdefa7d --- /dev/null +++ b/docs/debugging.html @@ -0,0 +1,36 @@ + + +Debugging Tips + + + +

Debugging Tips

+ +

+ Normally Mesa (and OpenGL) records but does not notify the user of + errors. It is up to the application to call + glGetError to check for errors. Mesa supports an + environment variable, MESA_DEBUG, to help with debugging. If + MESA_DEBUG is defined, a message will be printed to stdout whenever + an error occurs. +

+ +

+ More extensive error checking is done when Mesa is compiled with the + DEBUG symbol defined. You'll have to edit the Make-config file and + add -DDEBUG to the CFLAGS line for your system configuration. You may + also want to replace any optimization flags with the -g flag so you can + use your debugger. After you've edited Make-config type 'make clean' + before recompiling. +

+

+ In your debugger you can set a breakpoint in _mesa_error() to trap Mesa + errors. +

+

+ There is a display list printing/debugging facility. See the end of + src/dlist.c for details. +

+ + + diff --git a/docs/demos.html b/docs/demos.html new file mode 100644 index 0000000..6e18945 --- /dev/null +++ b/docs/demos.html @@ -0,0 +1,16 @@ + + +Demos + + + +

Demos

+ + + + + + + \ No newline at end of file diff --git a/docs/devinfo.html b/docs/devinfo.html new file mode 100644 index 0000000..c1ddea3 --- /dev/null +++ b/docs/devinfo.html @@ -0,0 +1,240 @@ + + +Development Notes + + + +

Development Notes

+ + +

Adding Extentions

+ +

+To add a new GL extension to Mesa you have to do at least the following. + +

    +
  • + If glext.h doesn't define the extension, edit include/GL/gl.h and add + code like this: + 
    +     #ifndef GL_EXT_the_extension_name
+     #define GL_EXT_the_extension_name 1
+     /* declare the new enum tokens */
+     /* prototype the new functions */
+     /* TYPEDEFS for the new functions */
+     #endif
+
    +
    • +
  • + In the src/mesa/glapi/ directory, add the new extension functions and + enums to the gl_API.xml file. + Then, a bunch of source files must be regenerated by executing the + corresponding Python scripts. +
    • +
  • + Find an existing extension that's similar to the new one and search + the sources for code related to that extension. + Implement new code as needed. + In general, new state variables will be added to mtypes.h. If the + extension is rather large, try to implement it in a new source file. +
    • +
  • + If hew extension adds new GL state, the functions in get.c, enable.c + and attrib.c will most likely require new code. +
    • +
+ + + +

Coding Style

+ +

+Mesa's code style has changed over the years. Here's the latest. +

+ +

+Comment your code! It's extremely important that open-source code be +well documented. Also, strive to write clean, easily understandable code. +

+ +

+3-space indentation +

+ +

+If you use tabs, set them to 8 columns +

+ +

+Brace example: +

+
+	if (condition) {
+	   foo;
+	}
+	else {
+	   bar;
+	}
+
+ +

+Here's the GNU indent command which will best approximate my preferred style: +

+
+	indent -br -i3 -npcs infile.c -o outfile.c
+
+ + +

+Local variable name example: localVarName (no underscores) +

+ +

+Constants and macros are ALL_UPPERCASE, with _ between words +

+ +

+Global vars not allowed. +

+ +

+Function name examples: +

+
+	glFooBar()       - a public GL entry point (in dispatch.c)
+	_mesa_FooBar()   - the internal immediate mode function
+	save_FooBar()    - retained mode (display list) function in dlist.c
+	foo_bar()        - a static (private) function
+	_mesa_foo_bar()  - an internal non-static Mesa function
+
+ + +

Writing a Device Driver

+ +

+XXX to do +

+ + + +

Making a New Mesa Release

+ +

+These are the instructions for making a new Mesa release. +

+ +

+Prerequisites (later versions may work): +

+
    +
  • autoconf 2.50 +
  • automake 1.4-p2 +
  • libtool 1.4 +
+ +

+Be sure to do a "cvs update -d ." in the Mesa directory to +get all the latest files. +

+ +

+Update the version definitions in src/version.h +

+ +

+Create/edit the docs/RELNOTES-X.Y file to document what's new in the release. +Edit the docs/VERSIONS file too. +

+ +

+Edit Make-config and change the MESA_MAJOR and/or MESA_MINOR versions. +

+ +

+Edit the GNU configure stuff to change versions numbers as needed: +Update the version string (second argument) in the line +"AM_INIT_AUTOMAKE(Mesa, 3.3)" in the configure.in file. +

+ +

+Remove the leading `dnl' from the line "dnl AM_MAINTAINER_MODE". +

+ +

+Verify the version numbers near the top of configure.in +

+ +

+Run "fixam -f" to disable automatic dependency tracking. +

+ +

+Run the bootstrap script to generate the configure script. +

+ +

+Edit Makefile.X11 and verify DIRECTORY is set correctly. The Mesa +sources must be in that directory (or there must be a symbolic link). +

+ +

+Edit Makefile.X11 and verify that LIB_NAME and DEMO_NAME are correct. +If it's a beta release, be sure the bump up the beta release number. +

+ +

+cp Makefile.X11 to Makefile so that the old-style Mesa makefiles +still work. ./configure will overwrite it if that's what the user runs. +

+ +

+Make a symbolic link from $(DIRECTORY) to Mesa. For example, +ln -s Mesa Mesa-3.3 This is needed in order to make a correct +tar file in the next step. +

+ +

+Make the distribution files. From inside the Mesa directory: +

+	make -f Makefile.X11 lib_tar
+	make -f Makefile.X11 demo_tar
+	make -f Makefile.X11 lib_zip
+	make -f Makefile.X11 demo_zip
+
+ +

+Copy the distribution files to a temporary directory, unpack them, +compile everything, and run some demos to be sure everything works. +

+ +

+Upload the *.tar.gz and *.zip files to ftp.mesa3d.org +

+ +

+Update the web site. +

+ +

+Make an announcement on the mailing lists: +mesa3d-dev@lists.sf.net, +mesa3d-users@lists.sf.net +and +mesa3d-announce@lists.sf.net +

+ + +

Autoconf info

+ +

+In order to run the bootstrap script you'll need: +

+

+autoconf 2.50
+automake 1.4-p5
+libtool 1.4
+
+ + + + diff --git a/docs/download.html b/docs/download.html new file mode 100644 index 0000000..54c5d97 --- /dev/null +++ b/docs/download.html @@ -0,0 +1,104 @@ + + +Getting Mesa + + + +

Downloading / Unpacking

+ +

+Mesa can be downloaded from the + +SourceForge download area. +

+ +

+Since version 2.3, Mesa is distributed in two pieces: main library code +and demos. If you're upgrading from a previous version of Mesa or you're not +interested in the demos you can just download the core Mesa archive file. +

+ +

+Mesa is available in at least three archive formats: +

+ +
+1. GNU zip/tar
+
+	Download MesaLib-X.Y.tar.gz and optionally MesaDemos-X.Y.tar.gz
+	Unpack with:
+		gzcat MesaLib-X.Y.tar.gz | tar xf -
+		gzcat MesaDemos-X.Y.tar.gz | tar xf -
+	or
+		gunzip MesaLib-X.Y.tar.gz ; tar xf MesaLib-X.Y.tar
+		gunzip MesaDemos-X.Y.tar.gz ; tar xf MesaLib-X.Y.tar
+	or
+		tar zxf MesaLib-X.Y.tar.gz
+		tar zxf MesaDemos-X.Y.tar.gz
+
+	If you don't have gzcat try zcat instead.
+
+2. Unix compressed/tar
+
+	Download MesaLib-X.Y.tar.Z and optionally MesaDemos-X.Y.tar.Z
+	Unpack with:
+		zcat MesaLib-X.Y.tar.Z | tar xf -
+		zcat MesaDemos-X.Y.tar.Z | tar xf -
+
+3. ZIP format
+
+	Download MesaLib-X.Y.zip and optionally MesaDemos-X.Y.zip
+	Unpack with:
+		unzip MesaLib-X.Y.zip
+		unzip MesaDemos-X.Y.zip
+
+ +

+After unpacking you'll have these directories (and more): +

+
+Makefile.X11	- top-level Makefile for X11-based systems
+Make-config	- system configurations used by the Makefile.X11
+include/	- GL header (include) files
+bin/		- shell scripts for making shared libraries, etc
+lib/		- final client libraries, created during compilation
+docs/		- documentation
+src/		- source code for libraries
+src/mesa	- sources for the main Mesa library and device drivers
+src/glu		- libGLU source code
+src/glw		- Xt/Motif/OpenGL widget code
+
+
+and if you downloaded and unpacked the MesaDemos.X.Y archive:
+
+src/glut	- GLUT source code
+progs/		- OpenGL programs
+progs/demos	- original Mesa demos
+progs/xdemos	- GLX OpenGL/Mesa demos
+progs/redbook	- examples from the OpenGL Programming Guide
+progs/samples	- examples from SGI
+progs/images/	- image files
+
+
+ +

+Proceed to compilation and installation +instructions. +

+ +

GLUT

+ +

+Mesa 2.5 and later includes Mark Kilgard's GLUT library (GL Utility Toolkit). +GLUT is built automatically on systems which support it. +

+

+The GLUT tests, demos, examples, etc are not included, just the main library. +To obtain the latest complete release of GLUT please visit the +GLUT page on www.opengl.org. +

+ + + + diff --git a/docs/envvars.html b/docs/envvars.html new file mode 100644 index 0000000..12e44e2 --- /dev/null +++ b/docs/envvars.html @@ -0,0 +1,40 @@ + + +Environment Variables + + + +

Environment Variables

+ +

+Mesa supports the following environment variables: +

+
    +
  • MESA_NO_ASM - if set, disables all assembly language optimizations +
  • MESA_NO_MMX - if set, disables Intel MMX optimizations +
  • MESA_NO_3DNOW - if set, disables AMD 3DNow! optimizations +
  • MESA_NO_SSE - if set, disables Intel SSE optimizations +
  • MESA_DEBUG - if set, error messages are printed to stderr +
  • MESA_NO_DITHER - if set, disables dithering, overriding glEnable(GL_DITHER) +
+ +

+The following environment variables are only applicable to the Xlib/X11 +software driver: +

+
    +
  • MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only) +
  • MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only) +
  • MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only) +
  • MESA_GAMMA - gamma correction coefficients (X only) +
  • MESA_XSYNC - enable synchronous X behavior (for X debugging only) +
  • MESA_GLX_FORCE_CI - if set, force GLX to treak 8bpp visuals as CI visuals +
  • MESA_GLX_FX - set to either "fullscreen" for full-screen rendering, + "window" to render into a window, or "disable" to disable the Glide driver. +
  • MESA_GLX_FORCE_ALPHA - if set, forces RGB windows to have an alpha channel. +
  • MESA_GLX_DEPTH_BITS - specifies default number of bits for depth buffer. +
+ + + + diff --git a/docs/extensions.html b/docs/extensions.html new file mode 100644 index 0000000..b4906ec --- /dev/null +++ b/docs/extensions.html @@ -0,0 +1,32 @@ + + +Mesa Extensions + + + +

Mesa Extensions

+ +

+A number of extensions have been developed especially for Mesa. +The specifications follow. +

+ + + + + + + diff --git a/docs/faq.html b/docs/faq.html new file mode 100644 index 0000000..4825f9d --- /dev/null +++ b/docs/faq.html @@ -0,0 +1,383 @@ + + +Mesa FAQ + + + + +
+

Mesa Frequently Asked Questions

+Last updated: 27 April 2004 +
+ +
+
+

Index

+1. High-level Questions and Answers +
+2. Compilation and Installation Problems +
+3. Runtime / Rendering Problems +
+4. Developer Questions +
+
+
+ + + + +

1. High-level Questions and Answers

+ +

1.1 What is Mesa?

+

+Mesa is an open-source implementation of the OpenGL specification. +OpenGL is a programming library for writing interactive 3D applications. +See the OpenGL website for more +information. +

+

+Mesa 5.x supports the OpenGL 1.4 specification. +

+ + +

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. +

+ +

1.3 What purpose does Mesa (software-based rendering) serve today?

+

+Hardware-accelerated OpenGL implementations are available for most popular +operating systems today. +Still, Mesa serves at least these purposes: +

+
    +
  • Mesa is used as the core of the open-source XFree86/DRI hardware drivers. +
    • +
  • Mesa is quite portable and allows OpenGL to be used on systems + that have no other OpenGL solution. +
    • +
  • Software rendering with Mesa serves as a reference for validating the + hardware drivers. +
    • +
  • A software implementation of OpenGL is useful for experimentation, + such as testing new rendering techniques. +
    • +
  • Mesa can render images with deep color channels: 16-bit integer + and 32-bit floating point color channels are supported. + This capability is only now appearing in hardware. +
    • +
  • Mesa's internal limits (max lights, clip planes, texture size, etc) can be + changed for special needs (hardware limits are hard to overcome). +
    • +
+ +

1.4 How do I upgrade my DRI installation to use a new Mesa release?

+

+You don't! A copy of the Mesa source code lives inside the XFree86/DRI source +tree and gets compiled into the individual DRI driver modules. +If you try to install Mesa over an XFree86/DRI installation, you'll lose +hardware rendering (because stand-alone Mesa's libGL.so is different than +the XFree86 libGL.so). +

+

+The DRI developers will incorporate the latest release of Mesa into the +DRI drivers when the time is right. +

+

+To upgrade, either look for a new release of XFree86 or visit the +DRI website to see +if there's newer drivers. +

+ + +

1.5 Are there other open-source implementations of OpenGL?

+

+Yes, SGI's +OpenGL Sample Implemenation (SI) is available. +The SI was written during the time that OpenGL was originally designed. +Unfortunately, development of the SI has stagnated. +Mesa is much more up to date with modern features and extensions. +

+ +

+Vincent is +an open-source implementation of OpenGL ES for mobile devices. + +

+miniGL +is a subset of OpenGL for PalmOS devices. + +

+TinyGL is a subset of OpenGL. +

+ +

+SoftGL +is an OpenGL subset for mobile devices. +

+ +

+Chromium +isn't a conventional OpenGL implementation (it's layered upon OpenGL), +but it does export the OpenGL API. It allows tiled rendering, sort-last +rendering, etc. +

+ + +

+There may be other open OpenGL implementations, but Mesa is the most +popular and feature-complete. +

+ +
+
+ + + +

2. Compilation and Installation Problems

+ + +

2.1 What's the easiest way to install Mesa?

+

+If you're using a Linux-based system, your distro CD most likely already +has Mesa packages (like RPM or DEB) which you can easily install. +

+ + +

2.2 Running configure; make Doesn't Work

+

+Unfortunately, the GNU autoconf/automake/libtool system doesn't seem to work +too well on non GNU/Linux systems, even after installing gmake, gcc, etc. +For that reason, Mesa's old-style makefile system is still included. +The old-style system uses good old traditional Makefiles. Try the following: +

  cd Mesa-x.y.z
+  cp Makefile.X11 Makefile
+  make
+
+You'll see a list of system configurations from which to choose. +For example: +
  make linux-x86
+
+

+If you're experienced with GNU autoconf/automake/libtool and think you can help +with maintence, contact the Mesa developers. +FYI, the Mesa developers generally don't use the autoconf/automake system. +We're especially annoyed with the fact that a +5000-line script (libtool) +is needed to make shared libraries (ugh). +

+ +

2.3 Mesa still doesn't compile

+

+If the old-style Makefile system doesn't work either, make sure you have +the most recent version of Mesa. +Otherwise, file a bug report or post to the Mesa3d-users mailing list. +Give as much info as possible when describing your problem. +

+ + +

2.4 I get undefined symbols such as bgnpolygon, v3f, etc...

+

+You're application is written in IRIS GL, not OpenGL. +IRIS GL was the predecessor to OpenGL and is a different thing (almost) +entirely. +Mesa's not the solution. +

+ + +

2.5 Where is the GLUT library?

+

+GLUT (OpenGL Utility Toolkit) is in the separate MesaDemos-x.y.z.tar.gz file. +If you don't already have GLUT installed, you should grab the MesaDemos +package and unpack it before compiling Mesa. +

+ + + +

2.6 What's the proper place for the libraries and headers?

+

+On Linux-based systems you'll want to follow the +Linux ABI standard. +Basically you'll want the following: +

+
    +
  • /usr/include/GL/gl.h - the main OpenGL header +
  • /usr/include/GL/glu.h - the OpenGL GLU (utility) header +
  • /usr/include/GL/glx.h - the OpenGL GLX header +
  • /usr/include/GL/glext.h - the OpenGL extensions header +
  • /usr/include/GL/glxext.h - the OpenGL GLX extensions header +
  • /usr/include/GL/osmesa.h - the Mesa off-screen rendering header +
  • /usr/lib/libGL.so - a symlink to libGL.so.1 +
  • /usr/lib/libGL.so.1 - a symlink to libGL.so.1.xyz +
  • /usr/lib/libGL.so.xyz - the actual OpenGL/Mesa library. xyz denotes the +Mesa version number. +
  • /usr/lib/libGLU.so - a symlink to libGLU.so.1 +
  • /usr/lib/libGLU.so.1 - a symlink to libGLU.so.1.3.xyz +
  • /usr/lib/libGLU.so.xyz - the OpenGL Utility library. xyz denotes the Mesa +version number. +
+

+After installing XFree86 and the DRI drivers, some of these files +may be symlinks into the /usr/X11R6/ tree. +

+

+The old-style Makefile system doesn't install the Mesa libraries; it's +up to you to copy them (and the headers) to the right place. +

+

+The GLUT header and library should go in the same directories. +

+
+
+ + + +

3. Runtime / Rendering Problems

+ +

3.1 Rendering is slow / why isn't my graphics hardware being used?

+

+Stand-alone Mesa (downloaded as MesaLib-x.y.z.tar.gz) doesn't have any +support for hardware acceleration (with the exception of the 3DFX Voodoo +driver). +

+

+What you really want is a DRI or NVIDIA (or another vendor's OpenGL) driver +for your particular hardware. +

+

+You can run the glxinfo program to learn about your OpenGL +library. +Look for the GL_VENDOR and GL_RENDERER values. +That will identify who's OpenGL library you're using and what sort of +hardware it has detected. +

+

+If your DRI-based driver isn't working, go to the +DRI website for trouble-shooting information. +

+ + +

3.2 I'm seeing errors in depth (Z) buffering. Why?

+

+Make sure the ratio of the far to near clipping planes isn't too great. +Look + +here for details. +

+

+Mesa uses a 16-bit depth buffer by default which is smaller and faster +to clear than a 32-bit buffer but not as accurate. +If you need a deeper you can modify the parameters to + glXChooseVisual in your code. +

+ + +

3.3 Why Isn't depth buffering working at all?

+

+Be sure you're requesting a depth buffered-visual. If you set the MESA_DEBUG +environment variable it will warn you about trying to enable depth testing +when you don't have a depth buffer. +

+

Specifically, make sure glutInitDisplayMode is being called +with GLUT_DEPTH or glXChooseVisual is being +called with a non-zero value for GLX_DEPTH_SIZE. +

+

This discussion applies to stencil buffers, accumulation buffers and +alpha channels too. +

+ + +

3.4 Why does glGetString() always return NULL?

+

+Be sure you have an active/current OpenGL rendering context before +calling glGetString. +

+ + +

3.5 GL_POINTS and GL_LINES don't touch the right pixels

+

+If you're trying to draw a filled region by using GL_POINTS or GL_LINES +and seeing holes or gaps it's because of a float-to-int rounding problem. +But this is not a bug. +See Appendix H of the OpenGL Programming Guide - "OpenGL Correctness Tips". +Basically, applying a translation of (0.375, 0.375, 0.0) to your coordinates +will fix the problem. +

+ +
+
+ + + +

4. Developer Questions

+ +

4.1 How can I contribute?

+

+First, join the Mesa3d-dev mailing list. That's where Mesa development +is discussed. +

+

+The +OpenGL Specification is the bible for OpenGL implemention work. +You should read it. +

+

Most of the Mesa development work involves implementing new OpenGL +extensions, writing hardware drivers (for the DRI), and code optimization. +

+ +

4.2 How do I write a new device driver?

+

+Unfortunately, writing a device driver isn't easy. +It requires detailed understanding of OpenGL, the Mesa code, and your +target hardware/operating system. +3D graphics are not simple. +

+

+The best way to get started is to use an existing driver as your starting +point. +For a software driver, the X11 and OSMesa drivers are good examples. +For a hardware driver, the Radeon and R200 DRI drivers are good examples. +

+

The DRI website has more information about writing hardware drivers. +The process isn't well document because the Mesa driver interface changes +over time, and we seldome have spare time for writing documentation. +That being said, many people have managed to figure out the process. +

+

+Joining the appropriate mailing lists and asking questions (and searching +the archives) is a good way to get information. +

+ + +

4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa and/or the DRI drivers?

+

+The specification for the extension +indicates that there are intellectual property (IP) and/or patent issues +to be dealt with. +

+

We've been unsucessful in getting a response from S3 (or whoever owns +the IP nowadays) to indicate whether or not an open source project can +implement the extension (specifically the compression/decompression +algorithms). +

+

+Until we can get official permission to do so, this extension will not +be implemented in Mesa. +

+ + + + diff --git a/docs/fbdev-dri.html b/docs/fbdev-dri.html new file mode 100644 index 0000000..06277f5 --- /dev/null +++ b/docs/fbdev-dri.html @@ -0,0 +1,313 @@ + + +Mesa fbdev/DRI Environment + + + +

Mesa fbdev/DRI Drivers

+ + +

1. Introduction

+ +

+The fbdev/DRI sub-project within Mesa brings hardware accelerated OpenGL +rendering to the Linux fbdev environment. +The X Window System / XFree86 is not needed. +

+ +

+Basically, the DRI drivers for hardware +accelerated OpenGL for XFree86 have been ported to fbdev so that X is +not needed. +This means fbdev/DRI works in full-screen mode only. +

+ +

+DRI driver writers may find this simplified environment easier to work in, +compared to the full XFree86/DRI environment. +

+ +

+Much of the work for this project has been done by Jon Smirl and +Keith Whitwell. +

+ +

+To use fbdev/DRI, you'll need a Linux 2.4 or 2.6 kernel. +

+ +

Background Info

+ +

+The Mesa-based DRI drivers used to be hosted in the DRI tree (which is +basically a copy of the XFree86 tree). +Since the Mesa-based DRI drivers are moreso "Mesa drivers" than "XFree86 +drivers" and the fact that with some work, the drivers could be used +without X, the driver code was moved into the Mesa tree. +

+ +

+So now the DRI drivers can be compiled for two different environments: +fbdev and XFree86. +To build the drivers for XFree86, one has to download/build the DRI +source tree. +Eventually, we'd like to be able to build the drivers for XFree86 outside +of the XFree86/DRI trees. +

+ + + + +

2. Compilation

+ +

2.1 Compiling the DRM modules

+ +

+First, you'll need the DRM (Direct Rendering Manager) kernel module sources. +They're found in a module of the DRI CVS tree. +To obtain the code do the following: +

+
+   cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/dri login
+
+

+Press Enter/Return when prompted for a password. Then, +

+
+   cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/dri co drm
+
+ +

+Compile the DRM kernel modules: +

+
+  cd drm/linux
+  make
+
+ +

+Note: you may need to be root in order to make a few symlinks. +

+

+When compilation is done, you should have at least the following +kernel modules: +

+
+  gamma.o
+  i810.o
+  i830.o
+  mach64.o
+  mga.o
+  r128.o
+  radeon.o
+  savage.o
+  sis.o
+  tdfx.o
+  via.o
+
+

+You'll probably want to copy/move them into your kernel module directory +(for example: /lib/modules/2.4.18-14/kernel/drivers/char/drm/). +

+ + + +

2.2 Compiling the Mesa drivers

+ +

+Begin by editing the Mesa/configs/default file to set +the DRM_SOURCE_PATH variable. +Set it to the location where the DRM module sources are located. +For example, if your current directory in step 2.1 was /home/fred/ +set DRM_SOURCE_PATH to /home/fred/drm +

+ +

+Next, assuming you're starting with a fresh Mesa CVS checkout, +do the following: +

+
+   make linux-solo
+
+ +

+If you previously built the source tree, run make realclean +first to remove the old object files. +

+ +

+When this is finished, check the Mesa/lib/ directory +to verify that the following files were made: +

+ +
    +
  • libGL.so.1.2 - the client-side OpenGL library + (and a few symlinks to it). +
  • libGLU.so.1.1 - the GLU library (and a few symlinks to it). +
  • libglut.so.3.7 - the GLUT library (and a few symlinks to it). +
  • mga_dri.so - DRI driver for Matrox G200/G400 cards. +
  • r128_dri.so - DRI driver for ATI Rage 128 cards. +
  • r200_dri.so - DRI driver for ATI R200 Radeon cards. +
  • radeon_dri.so - DRI driver for original ATI Radeon cards. +
  • i810_dri.so - DRI driver for Intel i810/i815 chips. +
  • i830_dri.so - DRI driver for Intel i830/i845 chips. +
  • mga_dri.so - DRI driver for Matrox G200/G400 cards. +
  • sis_dri.so - DRI driver for SIS cards. +
  • tdfx_dri.so - DRI driver for 3dfx Voodoo 3/4/5 cards. +
  • gamma_dri.so - DRI driver for 3Dlabs gamma cards. +
  • fb_dri.so - software-only fbdev driver. +
  • miniglx.conf - configuration file for the MiniGLX interface +
+ + +

3. Using fbdev/DRI

+ +

+If XFree86 is currently running, exit/stop the X server so you're +working from the console. +

+ + +

3.1 Load Kernel Modules

+ +

+You'll need to load the kernel modules specific to your graphics hardware. +Typically, this consists of the agpgart module, an fbdev driver module +and the DRM kernel module (from step 2.1). +

+ + +

+If you have ATI Radeon/R200 hardware, run as root: +

+
+   modprobe agpgart            # the AGP GART module
+   modprobe radeonfb           # the Radeon fbdev driver
+   modprobe radeon             # the Radeon DRI kernel module
+
+ +

+If you have ATI Rage 128 hardware, run as root: +

+
+   modprobe agpgart            # the AGP GART module
+   modprobe aty128fb           # the Rage 128 fbdev driver
+   modprobe r128               # the Rage 128 DRI kernel module
+
+ +

+If you have Matrox G200/G400 hardware, run as root: +

+
+   modprobe agpgart            # the AGP GART module
+   modprobe mgafb              # the Matrox fbdev driver
+   modprobe mga                # the Matrox DRI kernel module
+
+ +

+Then run lsmod to be sure the modules are loaded. +For a Radeon card, you should see something like this: +

+
+Module                  Size  Used by    Not tainted
+radeon                110308   0  (unused)
+radeonfb               21900   0  (unused)
+agpgart                43072   1 
+
+ + + +

3.2 Configuration File

+ +

+The Mesa/lib/miniglx.conf file should be installed +in /etc/. +

+ +

+Edit /etc/miniglx.conf to be sure it's set up correctly +for your hardware. +Comments in the file explain the options. +

+ + +

3.3 Running fbdev/DRI Programs

+ +

+Make sure your LD_LIBRARY_PATH environment variable is set to the +Mesa/lib/ directory. +

+ +

+Change to the Mesa/progs/miniglx/ directory and +start the sample_server program in the background: +

+
+   ./sample_server &
+
+ +

+Then try running the miniglxtest program: +

+
+   ./miniglxtest
+
+

+You should see a rotating quadrilateral which changes color as it rotates. +It will exit automatically after a bit. +

+ +

+If you run other tests in the miniglx/ directory, you may want to run +them from a remote shell so that you can stop them with ctrl-C. +

+ + + +

4.0 Troubleshooting

+ +

+If you try to run miniglxtest and get the following: +

+
+   [miniglx] failed to probe chipset
+   connect: Connection refused
+   server connection lost
+
+

+It means that the sample_server process is not running. +

+ + + + +

5.0 Programming Information

+ +

+The full OpenGL API is available with fbdev/DRI. +

+ +

+OpenGL/Mesa is interfaced to fbdev via the MiniGLX +interface. +MiniGLX is a subset of Xlib and GLX API functions which provides just +enough functionality to setup OpenGL rendering and respond to simple +input events. +

+ +

+Since MiniGLX is a subset of the usual Xlib and GLX APIs, programs written +to the MiniGLX API can also be run on full Xlib/GLX implementations. +This allows some degree of flexibility for software development and testing. +

+ +

+However, the MiniGLX API is not binary-compatible with full Xlib/GLX. +Some of the structures are different and some macros/functions work +differently. +See the GL/miniglx.h header file for details. +

+ + + + diff --git a/docs/games.html b/docs/games.html new file mode 100644 index 0000000..5ed7998 --- /dev/null +++ b/docs/games.html @@ -0,0 +1,62 @@ + + +Games + + + +

Games

+ + + + + + \ No newline at end of file diff --git a/docs/glfbdev-driver.html b/docs/glfbdev-driver.html new file mode 100644 index 0000000..804b2c1 --- /dev/null +++ b/docs/glfbdev-driver.html @@ -0,0 +1,88 @@ + + +Mesa glFBDev Driver + + + +

Mesa glFBDev Driver

+ + +

1. Introduction

+ +

+The GLFBDev driver interface allows one to do OpenGL rendering into a +framebuffer managed with the Linux's fbdev interface. +

+ +

+Basically, the programmer uses the fbdev functions to initialize the +graphics hardware and setup the framebuffer. +Then, using a calls to Mesa's glFBDev API functions, one can render +into the framebuffer with the OpenGL API functions. +

+ +

+Note, only software rendering is supported; there is no hardware +acceleration. +

+ + +

+The GL/glfbdev.h header file defines the glFBDev interface. +

+ +

+The progs/fbdev/glfbdevtest.c demonstrates how to use the glFBDev interface. +

+ +

+For more information about fbdev, see the + +Framebuffer Howto +

+ + +

2. Compilation

+ +

+To compile Mesa with support for the glFBDev interface: +

+   XXX todo
+
+ +

+When compilation is finished look in progs/glfbdev/ for the glfbdevtest demo. +

+ +

+xxx todo +

+ + +

3. Compiling and linking glFBDev programs

+ +

+xxx todo +

+ + + +

4. Running glFBDev programs

+ +

+First, you need to have a working fbdev environment. +See the + +Framebuffer Howto for information. +

+ +

+Programs must be run with root permission. +

+ +

+ + + + + diff --git a/docs/glu.html b/docs/glu.html new file mode 100644 index 0000000..e3c9189 --- /dev/null +++ b/docs/glu.html @@ -0,0 +1,43 @@ + + +SGI GLU + + + +

SGI SI GLU

+ +(Silicon Graphics, Inc. Sample Implementation of the OpenGL Utility library) + +

+SGI open-sourced their OpenGL Sample Implementation (SI) in January, 2000. +This includes the GLU library. +

+ +

+The SI GLU library implements GLU version 1.3 whereas the original +Mesa GLU library only implemented version 1.2. +We recommend using the SI GLU library instead of Mesa's GLU library +since it's more up-to-date, complete and reliable. +We're no longer developing the original Mesa GLU library. +

+ +

+The new SI GLU library code is included in the Mesa package. +You don't have to download it separately. +

+ + +

+Olivier Michel has made Linux RPMs of GLU for i386 and PowerPC. +You can download them from the +download area under Miscellaneous. +

+ +

+Visit the +OpenGL Sample Implementation home page for more information about the SI. +

+ + + diff --git a/docs/helpwanted.html b/docs/helpwanted.html new file mode 100644 index 0000000..b9434d0 --- /dev/null +++ b/docs/helpwanted.html @@ -0,0 +1,62 @@ + + +Help Wanted + + + +

Help Wanted

+ +

+We can always use more help with the Mesa project. Here are some +specific areas. If you think you can help out, post to the mesa3d-dev +mailing list. +

+ +
    +
  • Windows 98/NT build/driver maintenance and testing (Karl Schultz has been + doing a great job of this lately) +
  • DOS/DJGPP build/driver maintenance and testing +
  • GGI driver/build maintenance and testing +
  • GNU autoconfig/libtool maintenance (esp. on non-Linux systems) +
  • x86, SSE, 3DNow! and SPARC assembly language programming +
  • Implement WGL font functions in the WGL interface code +
  • Implement off-screen bitmap rendering support in the WGL interface code +
  • Help with writing/testing the new NV_fragment_program extension code +
  • Implement the ARB_vertex/fragment extensions +
  • Download/compile/test Mesa and report any bugs found +
+ + +

+If you want to help with Mesa, first join the Mesa developer's +mailing list. Then post a message explaining what you might like +to help with. The Mesa web page has a list of a few work items +which you may consider. +

+ +

+Anyone is welcome to contribute code to the Mesa project, provided you +agree to the copyright terms of the relevant code. See the COPYRIGHT +file. +

+ +

+Unfortunately, all the easy work in Mesa was done years ago. Nowadays, the +work is rather complicated and not suited to beginners. +

+ +

+If you're contribution code to the Mesa library itself: +

+

    +
  1. Try to write clean code (uniform indentation, comments, meaningful + identifiers, etc). It must be readable and maintainable! + +
  2. Test your code. On several occations I've incorporated code from + users which later turned out to have bugs. Now, I'm pretty hesitant + to use code which doesn't look good. +
+ + + + diff --git a/docs/index.html b/docs/index.html new file mode 100644 index 0000000..0edf432 --- /dev/null +++ b/docs/index.html @@ -0,0 +1,23 @@ + + +Mesa Home Page + + + + + + + + + + + + +<BODY> + +<P> + +</body> + + + \ No newline at end of file diff --git a/docs/install.html b/docs/install.html new file mode 100644 index 0000000..d2ad3ea --- /dev/null +++ b/docs/install.html @@ -0,0 +1,265 @@ + + +Compilation and Installation + + + + +

Compilation and Installation

+ +
    +
  1. Unix / X11 +
  2. Windows +
  3. VMS +
  4. Other +
+ + + + +

1. Unix/X11 Compilation and Installation

+ +

+Mesa uses a rather conventional Makefile system. +A GNU autoconf/automake system used to be included, but was discarded +in Mesa 5.1 because: +

+
    +
  • It seldom worked on IRIX, Solaris, AIX, etc. +
  • It was very compilicated +
  • Nobody maintained it +
  • libtool was just too weird +
+

+If someone strongly feels that Mesa should have a autoconf/automake +system and wants to contribute one and maintain it, we'll consider +adding it again. +

+ +

+In Mesa 6.1 we modified the conventional Makefile system. +Instead of specifying all the various system configurations in the +Make-config file, there's a directory named configs/ which +has an individual file for each configuration. +One of the configs gets copied to configs/current, which +is then included by all Makefiles. +

+ + +

1.1 Compilation

+ +

+Note: if you've obtained Mesa through CVS, do this first: +

+
+    cd Mesa
+    chmod a+x bin/mklib
+
+ +

+Just type make in the top-level directory. +You'll see a list of supported system configurations. +Choose one from the list (such as linux-x86), and type: +

+
+    make linux-x86
+
+

+If you want to rebuild for a different configuration run +make realclean before rebuilding. +

+ + +

1.2 The libraries

+ +

+When compilation has finished, look in the top-level lib/ directory. +You'll see a set of library files similar to this: +

+
+lrwxrwxrwx    1 brian    users          10 Mar 26 07:53 libGL.so -> libGL.so.1*
+lrwxrwxrwx    1 brian    users          19 Mar 26 07:53 libGL.so.1 -> libGL.so.1.5.060100*
+-rwxr-xr-x    1 brian    users     3375861 Mar 26 07:53 libGL.so.1.5.060100*
+lrwxrwxrwx    1 brian    users          11 Mar 26 07:53 libGLU.so -> libGLU.so.1*
+lrwxrwxrwx    1 brian    users          20 Mar 26 07:53 libGLU.so.1 -> libGLU.so.1.3.060100*
+-rwxr-xr-x    1 brian    users      549269 Mar 26 07:53 libGLU.so.1.3.060100*
+lrwxrwxrwx    1 brian    users          12 Mar 26 07:53 libglut.so -> libglut.so.3*
+lrwxrwxrwx    1 brian    users          16 Mar 26 07:53 libglut.so.3 -> libglut.so.3.7.1*
+-rwxr-xr-x    1 brian    users      597754 Mar 26 07:53 libglut.so.3.7.1*
+lrwxrwxrwx    1 brian    users          11 Mar 26 08:04 libGLw.so -> libGLw.so.1*
+lrwxrwxrwx    1 brian    users          15 Mar 26 08:04 libGLw.so.1 -> libGLw.so.1.0.0*
+-rwxr-xr-x    1 brian    users       20750 Mar 26 08:04 libGLw.so.1.0.0*
+lrwxrwxrwx    1 brian    users          14 Mar 26 07:53 libOSMesa.so -> libOSMesa.so.6*
+lrwxrwxrwx    1 brian    users          23 Mar 26 07:53 libOSMesa.so.6 -> libOSMesa.so.6.1.060100*
+-rwxr-xr-x    1 brian    users       23871 Mar 26 07:53 libOSMesa.so.6.1.060100*
+
+ +

+libGL is the main OpenGL library (i.e. Mesa). +
+libGLU is the OpenGL Utility library. +
+libglut is the GLUT library. +
+libGLw is the Xt/Motif OpenGL drawing area widget library. +
+libOSMesa is the OSMesa (Off-Screen) interface library. +

+ + +

1.3 Running the demos

+ +

+If you downloaded/unpacked the MesaDemos-x.y.z.tar.gz archive or +obtained Mesa from CVS, the progs/ directory will contain a +bunch of demonstration programs. +

+ +

+Before running a demo, you may have to set an environment variable +(such as LD_LIBRARY_PATH on Linux) to indicate where the +libraries are located. For example: +

+

+cd into the Mesa lib/ directory. +
+setenv LD_LIBRARY_PATH ${cwd} (if using csh or tcsh shell) +
+or, +
+export LD_LIBRARY_PATH=${PWD} (if using bash or sh shell) +
+ +

+Next, change to the Mesa/demos/ directory: +

+
+cd ../progs/demos +
+ +

+Run a demo such as gears: +

+
+./gears +
+ +

+If this doesn't work, try the Mesa/progs/xdemos/glxinfo program +and see that it prints the expected Mesa version number. +

+ +

+If you're using Linux or a similar OS, verify that the demo program is +being linked with the proper library files: +

+
+ldd gears +
+ +

+You should see something like this: +

+
+        libglut.so.3 => /home/brian/Mesa/lib/libglut.so.3 (0x40013000)
+        libGLU.so.1 => /home/brian/Mesa/lib/libGLU.so.1 (0x40051000)
+        libGL.so.1 => /home/brian/Mesa/lib/libGL.so.1 (0x400e0000)
+        libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
+        libm.so.6 => /lib/i686/libm.so.6 (0x403da000)
+        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x403fc000)
+        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x404da000)
+        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x404f1000)
+        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40543000)
+        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4054b000)
+        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x405fd000)
+        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40605000)
+        libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40613000)
+        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+        libdl.so.2 => /lib/libdl.so.2 (0x40644000)
+        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40647000)
+        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40650000)
+
+ +

+Retrace your steps if this doesn't look right. +

+ + +

1.4 Installing the header and library files

+ +

+The standard location for the OpenGL header files on Unix-type systems is +in /usr/include/GL/. +The standard location for the libraries is /usr/lib/. +For more information see, the + +Linux/OpenGL ABI specification. +

+ +

+If you'd like Mesa to co-exist with another implementation of OpenGL that's +already installed, you'll have to choose different directories, like +/usr/local/include/GL/ and /usr/local/lib/. +

+ +

+To install Mesa's headers and libraries, run make install +You'll be prompted to enter alternative directories for the headers +and libraries. +

+ +

+Note: at runtime, you can set the LD_LIBRARY_PATH (on Linux) to switch +between the Mesa libs and another vendor libs whenever you want. +This is a handy way to compare multiple OpenGL implementations. +

+ + + + +

2. Windows Compilation and Installation

+ +

+Please see the README.WIN32 file. +

+ + + + + +

3. VMS Compilation and Installation

+ +

+Please see the README.VMS file. +

+ + + + + +

4. Other systems

+ +

+Documentation for other environments (some may be very out of date): +

+ + + + + + + + diff --git a/docs/intro.html b/docs/intro.html new file mode 100644 index 0000000..db8f25f --- /dev/null +++ b/docs/intro.html @@ -0,0 +1,302 @@ + + +Mesa Introduction + + + +

Introduction

+ +

+Mesa is a 3-D graphics library with an API which is very similar to +that of OpenGL.* +To the extent that Mesa utilizes the OpenGL command syntax or state +machine, it is being used with authorization from Silicon Graphics, +Inc.(SGI). However, the author does not possess an OpenGL license +from SGI, and makes no claim that Mesa is in any way a compatible +replacement for OpenGL or associated with SGI. Those who want a +licensed implementation of OpenGL should contact a licensed +vendor. +

+ +

+Please do not refer to the library as MesaGL (for legal +reasons). It's just Mesa or The Mesa 3-D graphics +library.
+

+ +

+* OpenGL is a trademark of Silicon Graphics Incorporated. +

+ + +

Project History

+ +

+The Mesa project was founded by me, Brian Paul. Here's a short history +of the project. +

+ +

+August, 1993: I begin working on Mesa in my spare time. The project +has no name at that point. I was simply interested in writing a simple +3D graphics library that used the then-new OpenGL API. I was partially +inspired by the VOGL library which emulated a subset of IRIS GL. +I had been programming with IRIS GL since 1991. +

+ +

+November 1994: I contact SGI to ask permission to distribute my OpenGL-like +graphics library on the internet. SGI was generally receptive to the +idea and after negotiations with SGI's legal department, I get permission +to release it. +

+ +

+February 1995: Mesa 1.0 is released on the internet. I expected that +a few people would be interested in it, but not thousands. +I was soon receiving patches, new features and thank-you notes on a +daily basis. That encouraged me to continue working on Mesa. The +name Mesa just popped into my head one day. SGI had asked me not to use +the terms "Open" or "GL" in the project name and I didn't +want to make up a new acronym. Later, I heard of the Mesa programming +language and the Mesa spreadsheet for NeXTStep. +

+ +

+In the early days, OpenGL wasn't available on too many systems. +It even took a while for SGI to support it across their product line. +Mesa filled a big hole during that time. +For a lot of people, Mesa was their first introduction to OpenGL. +I think SGI recognized that Mesa actually helped to promote +the OpenGL API, so they didn't feel threatened by the project. +

+ + +

+1995-1996: I continue working on Mesa both during my spare time and during +my work hours at the Space Science and Engineering Center at the University +of Wisconsin in Madison. My supervisor, Bill Hibbard, lets me do this because +Mesa is now being using for the Vis5D project. +

+October 1996: Mesa 2.0 is released. It implementes the OpenGL 1.1 specification. +

+ +

+March 1997: Mesa 2.2 is released. It supports the new 3dfx Voodoo graphics +card via the Glide library. It's the first really popular hardware OpenGL +implementation for Linux. +

+ +

+September 1998: Mesa 3.0 is released. It's the first publicly-available +implementation of the OpenGL 1.2 API. +

+ +

+March 1999: I attend my first OpenGL ARB meeting. I contribute to the +development of several official OpenGL extensions over the years. +

+ +

+September 1999: I'm hired by Precision Insight, Inc. Mesa is a key +component of 3D hardware acceleration in the new DRI project for XFree86. +Drivers for 3dfx, 3dLabs, Intel, Matrox and ATI hardware soon follow. +

+ +

+October 2001: Mesa 4.0 is released. +It implements the OpenGL 1.3 specification. +

+ + +

+November 2001: I cofound +Tungsten Graphics, Inc. with Keith Whitwell, Jens Owen, David Dawes and +Frank LaMonica. +I continue to develop Mesa as part of my resposibilities with Tungsten +Graphics and as a spare-time project. +

+ +

+November 2002: Mesa 5.0 is released. +It implements the OpenGL 1.4 specification. +

+ +

+January 2003: Mesa 6.0 is released. It implements the OpenGL 1.5 +specification as well as the GL_ARB_vertex_program and +GL_ARB_fragment_program extensions. +

+ + +

+Ongoing: Mesa is used as the core of many hardware OpenGL drivers for XFree86 +within the +DRI project. +I continue to enhance Mesa with new extensions and features. +

+ + + +

Major Versions

+ +

+This is a summary of the major versions of Mesa. Note that Mesa's major +version number tracks OpenGL's minor version number. +

+ + +

Version 6.x features

+

+Version 6.x of Mesa implements the OpenGL 1.5 API with the following +extensions incorporated as standard features: +

+
    +
  • GL_ARB_occlusion_query +
  • GL_ARB_vertex_buffer_object +
  • GL_EXT_shadow_funcs +
+

+Also note that several OpenGL tokens were renamed in OpenGL 1.5 +for the sake of consistency. The old names will still be valid. +

+
+New Name                    Old Name
+------------------------------------------------------------
+GL_FOG_COORD_SRC            GL_FOG_COORDINATE_SOURCE
+GL_FOG_COORD                GL_FOG_COORDINATE
+GL_CURRENT_FOG_COORD        GL_CURRENT_FOG_COORDINATE
+GL_FOG_COORD_ARRAY_TYPE     GL_FOG_COORDINATE_ARRAY_TYPE
+GL_FOG_COORD_ARRAY_STRIDE   GL_FOG_COORDINATE_ARRAY_STRIDE
+GL_FOG_COORD_ARRAY_POINTER  GL_FOG_COORDINATE_ARRAY_POINTER
+GL_FOG_COORD_ARRAY          GL_FOG_COORDINATE_ARRAY
+GL_SRC0_RGB                 GL_SOURCE0_RGB
+GL_SRC1_RGB                 GL_SOURCE1_RGB
+GL_SRC2_RGB                 GL_SOURCE2_RGB
+GL_SRC0_ALPHA               GL_SOURCE0_ALPHA
+GL_SRC1_ALPHA               GL_SOURCE1_ALPHA
+GL_SRC2_ALPHA               GL_SOURCE2_ALPHA
+
+

+See the + +OpenGL specification for more details. +

+ + + +

Version 5.x features

+

+Version 5.x of Mesa implements the OpenGL 1.4 API with the following +extensions incorporated as standard features: +

+
    +
  • GL_ARB_depth_texture +
  • GL_ARB_shadow +
  • GL_ARB_texture_env_crossbar +
  • GL_ARB_texture_mirror_repeat +
  • GL_ARB_window_pos +
  • GL_EXT_blend_color +
  • GL_EXT_blend_func_separate +
  • GL_EXT_blend_logic_op +
  • GL_EXT_blend_minmax +
  • GL_EXT_blend_subtract +
  • GL_EXT_fog_coord +
  • GL_EXT_multi_draw_arrays +
  • GL_EXT_point_parameters +
  • GL_EXT_secondary_color +
  • GL_EXT_stencil_wrap +
  • GL_EXT_texture_lod_bias (plus, a per-texture LOD bias parameter) +
  • GL_SGIS_generate_mipmap +
+ + +

Version 4.x features

+ +

+Version 4.x of Mesa implements the OpenGL 1.3 API with the following +extensions incorporated as standard features: +

+ +
    +
  • GL_ARB_multisample +
  • GL_ARB_multitexture +
  • GL_ARB_texture_border_clamp +
  • GL_ARB_texture_compression +
  • GL_ARB_texture_cube_map +
  • GL_ARB_texture_env_add +
  • GL_ARB_texture_env_combine +
  • GL_ARB_texture_env_dot3 +
  • GL_ARB_transpose_matrix +
+ +

Version 3.x features

+ +

+Version 3.x of Mesa implements the OpenGL 1.2 API with the following +features: +

+
    +
  • BGR, BGRA and packed pixel formats +
  • New texture border clamp mode +
  • glDrawRangeElements() +
  • standard 3-D texturing +
  • advanced MIPMAP control +
  • separate specular color interpolation +
+ + +

Version 2.x features

+

+Version 2.x of Mesa implements the OpenGL 1.1 API with the following +features. +

+
    +
  • Texture mapping: +
      +
    • glAreTexturesResident +
    • glBindTexture +
    • glCopyTexImage1D +
    • glCopyTexImage2D +
    • glCopyTexSubImage1D +
    • glCopyTexSubImage2D +
    • glDeleteTextures +
    • glGenTextures +
    • glIsTexture +
    • glPrioritizeTextures +
    • glTexSubImage1D +
    • glTexSubImage2D +
    +
  • Vertex Arrays: +
      +
    • glArrayElement +
    • glColorPointer +
    • glDrawElements +
    • glEdgeFlagPointer +
    • glIndexPointer +
    • glInterleavedArrays +
    • glNormalPointer +
    • glTexCoordPointer +
    • glVertexPointer +
    +
  • Client state management: +
      +
    • glDisableClientState +
    • glEnableClientState +
    • glPopClientAttrib +
    • glPushClientAttrib +
    +
  • Misc: +
      +
    • glGetPointer +
    • glIndexub +
    • glIndexubv +
    • glPolygonOffset +
    +
+ + + + diff --git a/docs/libraries.html b/docs/libraries.html new file mode 100644 index 0000000..a7faab6 --- /dev/null +++ b/docs/libraries.html @@ -0,0 +1,55 @@ + + +Libraries and Toolkits + + + +

Libraries and Toolkits

+ +
    +
  • Apprentice - free OpenInventor work-alike +
  • Coin - OSS Open Inventor clone +
  • Ch - OpenGL bindings for the Ch C/C++ interpreter +
  • FOX - GUI Library +
  • GL4Java - a Java wrapper for OpenGL +
  • GtkGLArea - OpenGL Gtk widget +
  • GtkGLArea-- - OpenGL Gtk-- widget for C++ +
  • GTKpas - OpenGL Gtk widget for FreePascal +
  • FreeGLUT - a GLUT work-alike +
  • Fortran77/90 bindings for OpenGL and Mesa - by William Mitchell +
  • GLOW - a GUI toolkit for GLUT and OpenGL +
  • Glt - an OpenGL C++ toolkit +
  • GLUT (GL Utility Toolkit) - by Mark Kilgard +
  • GuileGL - OpenGL and GtkGLArea language bindings for Guile +
  • IDL - Interactive Data Language +
  • JX - C++ application framework and GUI library +
  • MAM/VRS - object-oriented toolkit for 3D graphics +
  • MINOS - GUI library +
  • OglCLib - C++ wrapper for OpenGL +
  • Open Inventor - the Open Inventor toolkit from SGI +
  • Open Inventor - the Open Inventor toolkit from Template Graphics Software, Inc. +
  • OpenRM +- Open Source, multithreaded, parallel scene graph API +
  • +Open SG PLUS - a scene-graph library +
  • Open Scene Graph + - a scene-graph library +
  • OpenVRML +- a VRML parsing/display library with "lookat" - an example VRML browser +
  • PLIB - A collection of portable games libraries, including an OpenGL GUI and a simple Scene Graph API +
  • Pryan - an OpenInventor-like toolkit +
  • PyOpenGL - OpenGL interface for Python +
  • Quesa - QuickDraw3D-compatible library based on OpenGL, Mesa or Direct3D +
  • repGL - IRIS GL emulated with OpenGL +
  • SciTech MGL - A multiplatform (Windows, Linux, OS/2, DOS, QNX, SMX, RT-Target & more) graphics library +
  • SGL - a 3D Scene Graph Library +
  • SoFree - a free implementation of Open Inventor +
  • Togl - Tcl/Tk widget for OpenGL +
  • VLE - Virtual Reality Toolkit +
  • View3D Widget - 3-D GUI widget +
  • VTK - Visualization Toolkit +
  • YAJOGL - Yet Another Java GL Binding. +
+ + + \ No newline at end of file diff --git a/docs/license.html b/docs/license.html new file mode 100644 index 0000000..475baaa --- /dev/null +++ b/docs/license.html @@ -0,0 +1,115 @@ + + +License / Cppyright Information + + + +

License / Copyright Information

+ +

+The Mesa distribution consists of several components. Different copyrights +and licenses apply to different components. For example, GLUT is copyrighted +by Mark Kilgard, some demo programs are copyrighted by SGI, some of the Mesa +device drivers are copyrighted by their authors. See below for a list of +Mesa's components and the copyright/license for each. +

+

+The core Mesa library is licensed according to the terms of the XFree86 +copyright (an MIT-style license). This allows integration with the +XFree86/DRI project. Unless otherwise stated, the Mesa source code and +documentation is licensed as follows: +

+ +
+Copyright (C) 1999-2003  Brian Paul   All Rights Reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included
+in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+ + +

Attention, Contributors

+ +

+When contributing to the Mesa project you must agree to relinquish your +work to the holder of the copyright for the particular component you're +contributing to. That is, you can't put your own copyright on the code, +unless it's a modular piece that can be omitted from Mesa (like a new +device driver). If for example, you contribute a bug fix to Mesa's +texture mapping code, your code will become a part of the body of work +which is copyrighted by Brian Paul and licensed by the above terms. +

+ +
+Mesa Component Licenses:
+
+Component       Files                 Primary Author      License
+----------------------------------------------------------------------------
+core Mesa code  src/*.[ch]            Brian Paul          Mesa
+                include/GL/gl.h
+
+GLX driver      src/X/*               Brian Paul          Mesa
+                include/GL/glx.h
+                include/GL/xmesa.h
+
+OS/Mesa driver  src/OSmesa/*          Brian Paul          Mesa
+                include/GL/osmesa.h
+
+3Dfx driver     src/FX/*              David Bucciarelli   Mesa
+                include/GL/fxmesa.h
+
+BeOS R4 driver  src/BeOS/*            Brian Paul          Mesa
+
+MGL driver      src/MGL/*             SciTech, Inc        SciTech copyright
+                include/GL/mglmesa.h
+
+Windows driver  src/Windows/*         Li Wei              copyright by Li Wei
+                include/GL/wmesa.h
+
+SVGA driver     src/SVGA/*            Brian Paul          GNU-LGPL
+                include/GL/svgamesa.h
+
+DOS driver      src/DOS/*             Charlie Wallace     GNU-LGPL
+                include/GL/dosmesa.h
+
+GGI driver      src/GGI/*             Uwe Maurer          GNU-LGPL
+                include/GL/ggimesa.h
+
+S3 driver       src/S3/*              S3, Inc.            S3 copyright
+
+GLUT            src-glut/*            Mark Kilgard        Mark's copyright
+                include/GL/*glut*.h
+
+GLU library     src-glu/*             Brian Paul          GNU-LGPL
+
+SI GLU library  si-glu/*              SGI                 SGI Free B
+                include/GL/glu.h
+
+Ext registry    include/GL/glext.h    SGI                 SGI Free B
+                include/GL/glxext.h
+
+demo programs   demos/*               various             see source files
+
+X demos         xdemos/*              Brian Paul          see source files
+
+SGI demos       samples/*             SGI                 SGI copyright
+
+RedBook demos   book/*                SGI                 SGI copyright
+
+ + + diff --git a/docs/lists.html b/docs/lists.html new file mode 100644 index 0000000..2c97d88 --- /dev/null +++ b/docs/lists.html @@ -0,0 +1,51 @@ + + +Mesa Mailing Lists + + + +

Mailing Lists

+ + +

There are four Mesa mailing lists:

+
    +
  • mesa3d-users - intended for users of the Mesa library. +Newbie questions are appropriate, but please try reading the Mesa documentation first. +
  • mesa3d-dev - intended for developers of the Mesa library. +This is not for beginners. +
  • mesa3d-cvs - CVS check-in messages are sent to this list. +This is useful for tracking ongoing development changes. +
  • mesa3d-announce - announcements of new Mesa versions are sent to this list. +
+ +

+To subscribe or unsubscribe, go to the + +SourceForge lists page. +

+ +

The mailing lists are managed by SourceForge. If you're having trouble +with the mailing lists please contact the SourceForge administrators for help.

+ +

Archives of the old Mesa mailing list which was hosted by unicamp.br +are available here.

+ +

+Here are some other OpenGL-related forums you might find useful: +

+ +

+Usenet newsgroups: +

    +
  • comp.graphics.algorithms +
  • comp.graphics.api.opengl +
  • comp.os.linux.x +
+

+ +

+OpenGL discussion forums at www.opengl.org +

+ + + diff --git a/docs/mangling.html b/docs/mangling.html new file mode 100644 index 0000000..5aafcb2 --- /dev/null +++ b/docs/mangling.html @@ -0,0 +1,26 @@ + + +Function Name Mangling + + + +

Function Name Mangling

+ +

+If you want to use Mesa and native OpenGL in the same application at +the same time you may find it useful to compile Mesa with +name mangling. +This results in all the Mesa functions being prefixed with +mgl instead of gl. +

+ +

+To do this, recompile Mesa with the compiler flag -DUSE_MGL_NAMESPACE. +Add the flag to the other compiler flags in Make-config (if using the +old-style build system) or in src/Makefile if using GNU autoconf/ +automake to build Mesa. +

+ + + + diff --git a/docs/modelers.html b/docs/modelers.html new file mode 100644 index 0000000..db2c8c1 --- /dev/null +++ b/docs/modelers.html @@ -0,0 +1,68 @@ + + +Modelers, Renderers and Viewers + + + +

Modelers, Renderers and Viewers

+ + + + + diff --git a/docs/news.html b/docs/news.html new file mode 100644 index 0000000..f119d74 --- /dev/null +++ b/docs/news.html @@ -0,0 +1,963 @@ + + +Mesa News + + + +

News

+ + +

December 9, 2004

+

+Mesa 6.2.1 has been released. +This is a stable release which just fixes bugs since the 6.2 release. +

+
+    Bug fixes:
+	- don't apply regular fog or color sum when using a fragment program
+	- glProgramEnvParameter4fARB always generated an error on
+	  GL_FRAGMENT_PROGRAM_ARB (fdo bug 1645)
+	- glVertexAttrib3svNV and glVertexAttrib3svARB were broken
+	- fixed width/height mix-up in glSeparableFilter2D()
+	- fixed regression in glCopyPixels + convolution
+	- glReadPixels from a clipped front color buffer didn't always work
+	- glTexImage didn't accept GL_RED/GREEN/BLUE as the format
+	- Attempting queries/accesses of VBO 0 weren't detected as errors
+	- paletted textures failed if the palette had fewer that 256 entries
+    Changes:
+	- fixed a bunch of compiler warnings found with gcc 3.4
+	- bug reports should to go bugzilla.freedesktop.org
+
+

+The MD5 checksums are: +

+
+80008a92f6e055d3bfdde2cf331ec3fa  MesaLib-6.2.1.tar.gz
+f43228cd2bf70f583ef3275c1c545421  MesaLib-6.2.1.tar.bz2
+dec26cfd40116ad021020fea2d94f652  MesaLib-6.2.1.zip
+2c7af3c986a7571c8713c8bfee7e49e3  MesaDemos-6.2.1.tar.gz
+3cac74667b50bcbd4f67f594fb4224a2  MesaDemos-6.2.1.tar.bz2
+75b3edd12eb2b370caf05f29b99e508a  MesaDemos-6.2.1.zip
+
+ + +

October 2, 2004

+

+Mesa 6.2 has been released. +This is a stable release which just fixes bugs since the 6.1 release. +

+
+    New:
+	- enabled GL_ARB_texture_rectangle (same as GL_NV_texture_rectangle)
+	- updated Doxygen support (Jose Fonseca)
+    Changes:
+	- some GGI driver updates (Christoph Egger, bug 1025977)
+    Bug fixes:
+	- Omit GL_ARB_texture_non_power_of_two from list of OpenGL 1.5 features
+	- fixed a few compilation issues on IRIX
+	- fixed a matrix classification bug (reported by Wes Bethel)
+	- we weren't reseting the vertex/fragment program error state
+	  before parsing (Dave Reveman)
+	- adjust texcoords for sampling texture rectangles (Dave Reveman)
+	- glGet*(GL_MAX_VERTEX_ATTRIBS_ARB) wasn't implemented
+	- repeated calls to glDeleteTexture(t) could lead to a crash
+	- fixed potential ref count bugs in VBOs and vertex/fragment programs
+	- spriteblast demo didn't handle window size changes correctly
+	- glTexSubImage didn't handle pixels=NULL correctly for PBOs
+	- fixed color index mode glDrawPixels bug (Karl Schultz)
+
+

+The MD5 checksums are: +

+
+9e8f34b059272dbb8e1f2c968b33bbf0  MesaLib-6.2.tar.gz
+3d6a6362390b6a37d3cb2e615f3ac7db  MesaLib-6.2.tar.bz2
+6cfd7895d28e695c0dbbed9469564091  MesaLib-6.2.zip
+3e06e33b0809f09855cb60883b8bdfef  MesaDemos-6.2.tar.gz
+9d160009c3dfdb35fe7e4088c9ba8f85  MesaDemos-6.2.tar.bz2
+856f7ec947122eb3c8985ebc2f654dcd  MesaDemos-6.2.zip
+
+ + +

August 18, 2004

+

+Mesa 6.1 has been released. +This is a new development release (version 6.2 will be a stabilization +release). +

+
+    New:
+	- Revamped Makefile system
+	- glXUseRotatedXFont() utility (see xdemos/xuserotfont.c)
+	- internal driver interface changes related to texture object
+	  allocation, vertex/fragment programs, BlendEquationSeparate, etc.
+	- option to walk triangle edges with double-precision floats
+	  (Justin Novosad of Discreet) (see config.h file)
+	- support for AUX buffers in software GLX driver
+	- updated glext.h to version 24 and glxext.h to version 6
+	- new MESA_GLX_FORCE_ALPHA and MESA_GLX_DEPTH_BITS env vars
+	- updated BeOS support (Philippe Houdoin)
+    Changes:
+	- fragment fog interpolation is perspective corrected now
+	- new glTexImage code, much cleaner, may be a bit faster
+    Bug fixes:
+	- glArrayElement in display lists didn't handle generic vertex attribs
+	- glFogCoord didn't always work properly
+	- ARB_fragment_program fog options didn't work
+	- frag prog TEX instruction no longer incorrectly divides s,t,r by q
+	- ARB frag prog TEX and TEXP instructions now use LOD=0
+	- glTexEnviv in display lists didn't work
+	- glRasterPos didn't do texgen or apply texture matrix
+	- GL_DOUBLE-valued vertex arrays were broken in some cases
+	- fixed texture rectangle edge/border sampling bugs
+	- sampling an incomplete texture in a fragment program would segfault
+	- glTexImage was missing a few error checks
+	- fixed some minor glGetTexParameter glitches
+	- GL_INTENSITY was mistakenly accepted as a  to glTexImage
+	- fragment program writes to RC/HC register were broken
+	- fixed a few glitches in GL_HP_occlusion_test extension
+	- glBeginQueryARB and glEndQueryARB didn't work inside display lists
+	- vertex program state references were broken
+	- fixed triangle color interpolation bug on AIX (Shane Blackett)
+	- fixed a number of minor memory leaks (bug #1002030)
+
+The MD5 checksums are: +

+
+c9284d295ebcd2e0486cc3cd54e5863c  MesaLib-6.1.tar.gz
+5de1f53ec0709f60fc68fdfed57351f3  MesaLib-6.1.tar.bz2
+483e77cac4789a5d36c42f3c0136d6d8  MesaLib-6.1.zip
+8c46cfa6f9732acc6f6c25724aad0246  MesaDemos-6.1.tar.gz
+89bfe0f6c69b39fd0ebd9fff481a4e9b  MesaDemos-6.1.tar.bz2
+161268531fcc6f0c5a056430ee97e0c1  MesaDemos-6.1.zip
+
+ + + +

April 2, 2004

+ +

+Mesa 6.0.1 has been released. +This release basically just fixes bugs since the 6.0. release. +

+
+    New:
+	- upgraded glext.h to version 22
+	- new build targets (Dan Schikore)
+	- new linux-x86-opteron build target (Heath Feather)
+    Bug fixes:
+	- glBindProgramARB didn't update all necessary state
+	- fixed build problems on OpenBSD
+	- omit CVS directories from tarballs
+	- glGetTexImage(GL_COLOR_INDEX) was broken
+	- fixed an infinite loop in t&l module
+	- silenced some valgrind warnings about using unitialized memory
+	- fixed some compilation/link glitches on IRIX (Mike Stephens)
+	- glBindProgram wasn't getting compiled into display lists
+	- GLX_FBCONFIG_ID wasn't recognized in glXChooseFBConfig() (bug 888079)
+	- two-sided lighting and vertex program didn't work (bug 887330)
+	- stores to program parameter registers in vertex state programs
+	  didn't work.
+	- fixed glOrtho bug found with gcc 3.2.2 (RH9)
+	- glXCreateWindow() wasn't fully implemented (bug 890894)
+	- generic vertex attribute arrays didn't work in display lists
+	- vertex buffer objects' default usage and access fields were wrong
+	- glDrawArrays with start!=0 was broken
+	- fragment program PK2H, UP2H, UP4B and UP4UB instructions were broken
+	- linux-osmesa16-static config didn't work
+	- fixed a few color index rendering problems (bug 910687)
+	- glInterleavedArrays didn't respect GL_CLIENT_ACTIVE_TEXTURE
+	- OSMesa RGB and BGR modes were broken
+	- glProgramStringARB mistakenly required a null-terminated string
+	- fragment program XPD instruction was incorrect
+	- glGetMaterial() didn't work reliably
+
+The MD5 checksums are: +

+
+011be0e79666c7a6eb9693fbf9348653  MesaLib-6.0.1.tar.gz
+b7f14088c5c2f14490d2739a91102112  MesaLib-6.0.1.tar.bz2
+bf0510cf0a2b87d64cdd317eca3f1db1  MesaLib-6.0.1.zip
+b7b648599e0aaee1c4ffc554a2a9139e  MesaDemos-6.0.1.tar.gz
+dd6aadfd9ca8e1cfa90c6ee492bc6f43  MesaDemos-6.0.1.tar.bz2
+eff71d59c211825e949199852f5a2316  MesaDemos-6.0.1.zip
+
+ + + +

January 16, 2004

+ +

+Mesa 6.0 has been released. This is a stabilization of the 5.1 release +and primarily just incorporates bug fixes. +

+
+    New:
+	- full OpenGL 1.5 support
+	- updated GL/glext.h file to version 21
+    Changes:
+	- changed max framebuffer size to 4Kx4K (MAX_WIDTH/HEIGHT in config.h)
+    Bug fixes:
+	- fixed bug in UNCLAMPED_FLOAT_TO_UBYTE macro; solves a color
+	  clamping issue
+	- updated suno5-gcc configs
+	- glColor3 functions sometimes resulted in undefined alpha values
+	- fixed FP divide by zero error seen on VMS with xlockmore, others
+	- fixed vertex/fragment program debug problem (bug 873011)
+	- building on AIX with gcc works now
+	- glDeleteProgramsARB failed for ARB fragment programs (bug 876160)
+	- glDrawRangeElements tried to modify potentially read-only storage
+	- updated files for building on Windows
+
+ + + +

December 28, 2003

+ +

+The Mesa CVS server has been moved to +freedesktop.org because of problems with SourceForge's anonymous +CVS service. +

+ +

Please see the CVS access page for details. +

+ + +

December 17, 2003

+ +

+Mesa 5.1 has been released. This is a new development release. +Mesa 6.0 will be the next stable release and will support all +OpenGL 1.5 features. +

+
+    New features:
+	- reorganized directory tree
+	- GL_ARB_vertex/fragment_program extensions (Michal Krol & Karl Rasche)
+	- GL_ATI_texture_env_combine3 extension (Ian Romanick)
+	- GL_SGI_texture_color_table extension (Eric Plante)
+	- GL_NV_fragment_program extension
+	- GL_NV_light_max_exponent extension
+	- GL_EXT_texture_rectangle (identical to GL_NV_texture_rectangle)
+	- GL_ARB_occlusion_query extension
+	- GL_ARB_point_sprite extension
+	- GL_ARB_texture_non_power_of_two extension
+	- GL_IBM_multimode_draw_arrays extension
+	- GL_EXT_texture_mirror_clamp extension (Ian Romanick)
+	- GL_ARB_vertex_buffer_object extension
+	- new X86 feature detection code (Petr Sebor)
+	- less memory used for display lists and vertex buffers
+	- demo of per-pixel lighting with a fragment program (demos/fplight.c)
+	- new version (18) of glext.h header
+	- new spriteblast.c demo of GL_ARB_point_sprite
+	- faster glDrawPixels in X11 driver in some cases (see RELNOTES-5.1)
+	- faster glCopyPixels in X11 driver in some cases (see RELNOTES-5.1)
+    Bug fixes:
+	- really enable OpenGL 1.4 features in DOS driver.
+	- fixed issues in glDrawPixels and glCopyPixels for very wide images
+	- glPixelMapf/ui/usv()'s size parameter is GLsizei, not GLint
+	- fixed some texgen bugs reported by Daniel Borca
+	- fixed wglMakeCurrent(NULL, NULL) bug (#835861)
+	- fixed glTexSubImage3D z-offset bug (Cedric Gautier)
+	- fixed RGBA blend enable bug (Ville Syrjala)
+	- glAccum is supposed to be a no-op in selection/feedback mode
+	- fixed texgen bug #597589 (John Popplewell)
+    Changes:
+	- dropped API trace feature (src/Trace/)
+	- documentation overhaul.  merged with website content.  more html.
+	- glxgears.c demo updated to use GLX swap rate extensions
+	- glTexImage1/2/3D now allows width/height/depth = 0
+	- disable SPARC asm code on Linux (bug 852204)
+
+ +The MD5 checksums are: +

+
+78f452f6c55478471a744f07147612b5  MesaLib-5.1.tar.gz
+67b3b8d3f7f4c8c44904551b851d01af  MesaLib-5.1.tar.bz2
+6dd19ffa750ec7f634e370a987505c9d  MesaLib-5.1.zip
+e0214d4ebb22409dfa9262f2b52fd828  MesaDemos-5.1.tar.gz
+066c9aff4fd924405de1ae9bad5ec9a7  MesaDemos-5.1.tar.bz2
+d2b5ba32b53e0ad0576c637a4cc1fb41  MesaDemos-5.1.zip
+
+ + +

November 12, 2003

+ +

+New Mesa 5.0.2 tarballs have been uploaded to SourceForge which fix a +number of automake/libtool problems. +

+

+The new MD5 checksums are: +

+
+a9dcf3ff9ad1b7d6ce73a0df7cff8b5b  MesaLib-5.0.2.tar.gz
+7b4bf9261657c2fca03796d4955e6f50  MesaLib-5.0.2.tar.bz2
+79c141bddcbad557647535d02194f346  MesaLib-5.0.2.zip
+952d9dc823dd818981d1a648d7b2668a  MesaDemos-5.0.2.tar.gz
+b81fafff90995025d2f25ea02b786642  MesaDemos-5.0.2.tar.bz2
+a21be975589e8a2d1871b6bb7874fffa  MesaDemos-5.0.2.zip
+
+ + + +

September 5, 2003

+ +

+Mesa 5.0.2 has been released. This is a stable, bug-fix release. +

+
+    Bug fixes:
+	- fixed texgen problem causing texcoord's Q to be zero (stex3d)
+	- default GL_TEXTURE_COMPARE_MODE_ARB was wrong
+	- GL_CURRENT_MATRIX_NV query was wrong
+	- GL_CURRENT_MATRIX_STACK_DEPTH_NV query was off by one
+	- GL_LIST_MODE query wasn't correct
+	- GL_FOG_COORDINATE_SOURCE_EXT query wasn't supported
+	- GL_SECONDARY_COLOR_ARRAY_SIZE_EXT query returned wrong value
+	- blended, wide lines didn't always work correctly (bug 711595)
+	- glVertexAttrib4svNV w component was always 1
+	- fixed bug in GL_IBM_rasterpos_clip (missing return)
+	- GL_DEPTH_TEXTURE_MODE = GL_ALPHA didn't work correctly
+	- a few Solaris compilation fixes
+	- fixed glClear() problem for DRI drivers (non-existant stencil, etc)
+	- fixed int/REAL mixup in GLU NURBS curve evaluator (Eric Cazeaux)
+	- fixed delete [] bug in SI GLU (bug 721765) (Diego Santa Cruz)
+	- glFog() didn't clamp fog colors
+	- fixed bad float/int conversion for GL_TEXTURE_PRIORITY in the
+	  gl[Get]TexParameteri[v] functions
+	- fixed invalid memory references in glTexGen functions (bug 781602)
+	- integer-valued color arrays weren't handled correctly
+	- glDrawPixels(GL_DEPTH_COMPONENT) with glPixelZoom didn't work
+	- GL_EXT_texture_lod_bias is part of 1.4, overlooked in 5.0.1
+    Changes:
+	- build GLUT with -fexceptions so C++ apps propogate exceptions
+
+ + + +

June 2003

+ +

+Mesa's directory tree has been overhauled. +Things are better organized now with some thought toward future needs. +

+

+In CVS, the latest Mesa 5.1 development code is now rooted under the +Mesa-newtree/ directory. The old top-level Mesa/ directory +holds the Mesa 5.0.x code which will be abandoned at some point. +

+ + + +

March 30, 2003

+ +

+Mesa 5.0.1 has been released. This is a stable, bug-fix release. +

+
+    New:
+	- DOS driver updates from Daniel Borca
+	- updated GL/gl_mangle.h file (Bill Hoffman)
+    Bug fixes:
+	- auto mipmap generation for cube maps was broken (bug 641363)
+	- writing/clearing software alpha channels was unreliable
+	- minor compilation fixes for OS/2 (Evgeny Kotsuba)
+	- fixed some bad assertions found with shadowtex demo
+	- fixed error checking bug in glCopyTexSubImage2D (bug 659020)
+	- glRotate(angle, -x, 0, 0) was incorrect (bug 659677)
+	- fixed potential segfault in texture object validation (bug 659012)
+	- fixed some bogus code in _mesa_test_os_sse_exception_support (Linus)
+	- fix fog stride bug in tnl code for h/w drivers (Michel Danzer)
+	- fixed glActiveTexture / glMatrixMode(GL_TEXTURE) bug (#669080)
+	- glGet(GL_CURRENT_SECONDARY_COLOR) should return 4 values, not 3
+	- fixed compilation problem on Solaris7/x86 (bug 536406)
+	- fixed prefetch bug in 3DNow! code (Felix Kuhling)
+	- fixed NeXT build problem (FABSF macro)
+	- glDrawPixels Z values when glPixelZoom!=1 were invalid (bug 687811)
+	- zoomed glDraw/CopyPixels with clipping sometimes failed (bug 689964)
+	- AA line and triangle Z values are now rounded, not truncated
+	- fixed color interpolation bug when GLchan==GLfloat (bug 694461)
+	- glArePrograms/TexturesResident() wasn't 100% correct (Jose Fonseca)
+	- fixed a minor GL_COLOR_MATERIAL bug
+	- NV vertex program EXP instruction was broken
+	- glColorMask misbehaved with X window / pixmap rendering
+	- fix autoconf/libtool GLU C++ linker problem on Linux (a total hack)
+	- attempt to fix GGI compilation problem when MesaDemos not present
+	- NV vertex program ARL-relative fetches didn't work
+    Changes:
+	- use glPolygonOffset in gloss demo to avoid z-fighting artifacts
+	- updated winpos and pointblast demos to use ARB extensions
+	- disable SPARC normal transformation code (bug 673938)
+	- GLU fixes for OS/2 (Evgeny Kotsuba)
+
+

+MD5 checksums follow: +

+
+b80f8b5d53a3e9f19b9fde5af0c542f0  MesaLib-5.0.1.tar.gz
+513b4bbd7d38951f05027179063d876b  MesaLib-5.0.1.tar.bz2
+eebd395678f4520d33b267e5d5c22651  MesaLib-5.0.1.zip
+49d7feaec6dc1d2091d7c3cc72a9b320  MesaDemos-5.0.1.tar.gz
+37190374a98c3c892f0698be9ca3acf0  MesaDemos-5.0.1.tar.bz2
+becd8bf17f5791361b4a54ba2a78e5c9  MesaDemos-5.0.1.zip
+
+ + + +

March 7, 2003

+

+Website and documentation overhaul. +

+

+The website content and Mesa documentation (from the doc/ directory) have +been merged together. +All the documentation files have been entered into the CVS repository. +Many of the old plain-text files have been converted to html and modernized. +

+ + +

November 13, 2002

+

Mesa 5.0 has been released. This is a stable release which +implements the OpenGL 1.4 specification. +

New:
+    - OpenGL 1.4 support (glGetString(GL_VERSION) returns "1.4")
+    - removed some overlooked debugging code
+    - glxinfo updated to support GLX_ARB_multisample
+    - GLUT now support GLX_ARB_multisample
+    - updated DOS driver (Daniel Borca)
+Bug fixes:
+    - GL_POINT and GL_LINE-mode polygons didn't obey cull state
+    - fixed potential bug in _mesa_align_malloc/calloc()
+    - fixed missing triangle bug when running vertex programs
+    - fixed a few HPUX compilation problems
+    - FX (Glide) driver didn't compile
+    - setting GL_TEXTURE_BORDER_COLOR with glTexParameteriv() didn't work
+    - a few EXT functions, like glGenTexturesEXT, were no-ops
+    - a few OpenGL 1.4 functions like glFogCoord*, glBlendFuncSeparate,
+      glMultiDrawArrays and glMultiDrawElements were missing
+    - glGet*(GL_ACTIVE_STENCIL_FACE_EXT) was broken
+    - Pentium 4 Mobile was mistakenly identified as having 3DNow!
+    - fixed one-bit error in point/line fragment Z calculation
+    - fixed potential segfault in fakeglx code
+    - fixed color overflow problem in DOT3 texture env mode
+
+ + +

October 29, 2002

+

Mesa 4.1 has been released. This is a new development release. +For a stable release, get 4.0.4. +

New:
+    - GL_NV_vertex_program extension
+    - GL_NV_vertex_program1_1 extension
+    - GL_ARB_window_pos extension
+    - GL_ARB_depth_texture extension
+    - GL_ARB_shadow extension
+    - GL_ARB_shadow_ambient extension
+    - GL_EXT_shadow_funcs extension
+    - GL_ARB_point_parameters extension
+    - GL_ARB_texture_env_crossbar
+    - GL_NV_point_sprite extension
+    - GL_NV_texture_rectangle extension
+    - GL_EXT_multi_draw_arrays extension
+    - GL_EXT_stencil_two_side extension
+    - GLX_SGIX_fbconfig and GLX_SGIX_pbuffer extensions
+    - GL_ATI_texture_mirror_once extension (Ian Romanick)
+    - massive overhaul/simplification of software rasterizer module,
+      many contributions from Klaus Niederkrueger
+    - faster software texturing in some cases (i.e. trilinear filtering)
+    - new OSMesaGetProcAddress() function
+    - more blend modes implemented with MMX code (Jose Fonseca)
+    - added glutGetProcAddress() to GLUT
+    - added GLUT_FPS env var to compute frames/second in glutSwapBuffers()
+    - pbinfo and pbdemo PBuffer programs
+    - glxinfo -v prints transprent pixel info (Gerd Sussner)
+Bug fixes:
+    - better mipmap LOD computation (prevents excessive blurriness)
+    - OSMesaMakeCurrent() didn't recognize buffer size changes
+    - assorted conformance fixes for 16-bit/channel rendering
+    - texcombine alpha subtraction mode was broken
+    - fixed some blend problems when GLchan==GLfloat (Gerk Huisma)
+    - clamp colors to [0,1] in OSMesa if GLchan==GLfloat (Gerk Huisma)
+    - fixed divide by zero error in NURBS tessellator (Jon Perry)
+    - fixed GL_LINEAR fog bug by adding clamping
+    - fixed FP exceptions found using Alpha CPU
+    - 3dfx/glide driver render-to-window feature was broken
+    - added missing GLX_TRANSPARENT_RGB token to glx.h
+    - fixed error checking related to paletted textures
+    - fixed reference count error in glDeleteTextures (Randy Fayan)
+Changes:
+    - New spec file and Python code to generate some GL dispatch files
+    - Glide driver defaults to "no" with autoconf/automake
+    - floating point color channels now clamped to [0,inf)
+    - updated demos/stex3d with new options
+
+ + +

October 4, 2002

+

+The Mesa FAQ has been rewritten. +

+ +

October 3, 2002

+

Mesa 4.0.4 has been released. This is a stable bug-fix release. +

    New:
+	- GL_NV_texture_rectangle extension
+	- updated glext.h header (version 17)
+	- updated DOS driver (Daniel Borca)
+	- updated BeOS R5 driver (Philippe Houdoin)
+	- added GL_IBM_texture_mirror_repeat
+	- glxinfo now takes -l option to print interesting OpenGL limits info
+	- GL_MESA_ycbcr_texture extension
+	- GL_APPLE_client_storage extension (for some DRI drivers only)
+	- GL_MESA_pack_invert extension
+    Bug fixes:
+	- fixed GL_LINEAR fog bug by adding clamping
+	- fixed FP exceptions found using Alpha CPU
+	- 3dfx MESA_GLX_FX=window (render to window) didn't work
+	- fixed memory leak in wglCreateContest (Karl Schultz)
+	- define GLAPIENTRY and GLAPI if undefined in glu.h
+	- wglGetProcAddress didn't handle all API functions
+	- when testing for OpenGL 1.2 vs 1.3, check for GL_ARB_texture_cube_map
+	- removed GL_MAX_CONVOLUTION_WIDTH/HEIGHT from glGetInteger/Float/etc()
+	- error checking in compressed tex image functions had some glitches
+	- fixed AIX compile problem in src/config.c
+	- glGetTexImage was using pixel unpacking instead of packing params
+	- auto-mipmap generation for cube maps was incorrect
+    Changes:
+	- max texture units reduced to six to accomodate texture rectangles
+	- removed unfinished GL_MESA_sprite_point extension code
+
+ +

June 25, 2002

+

Mesa 4.0.3 has been released. This is a stable bug-fix release. +

    New:
+    - updated GL/glext.h file (version 15)
+    - corrected MMX blend code (Jose Fonseca)
+    - support for software-based alpha planes in Windows driver
+    - updated GGI driver (Filip Spacek)
+    Bug fixes:
+    - glext.h had wrong values for GL_DOT3_RGB[A]_EXT tokens
+    - OSMesaMakeCurrent() didn't recognize buffer size changes
+    - assorted conformance fixes for 16-bit/channel rendering
+    - texcombine alpha subtraction mode was broken
+    - fixed lighting bug with non-uniform scaling and display lists
+    - fixed bug when deleting shared display lists
+    - disabled SPARC cliptest assembly code (Mesa bug 544665)
+    - fixed a couple Solaris compilation/link problems
+    - blending clipped glDrawPixels didn't always work
+    - glGetTexImage() didn't accept packed pixel types
+    - glPixelMapu[is]v() could explode given too large of pixelmap
+    - glGetTexParameter[if]v() didn't accept GL_TEXTURE_MAX_ANISOTROPY_EXT
+    - glXCopyContext() could lead to segfaults
+    - glCullFace(GL_FRONT_AND_BACK) didn't work (bug 572665)
+    Changes:
+    - lots of C++ (g++) code clean-ups
+    - lots of T&L updates for the Radeon DRI driver
+    Known bugs:
+    - mipmap LOD computation (fixed for Mesa 4.1)
+
+ +

April 2, 2002

+

Mesa 4.0.2 has been released. This is a stable bug-fix release. +

    New:
+      - New DOS (DJGPP) driver written by Daniel Borca
+      - New driver interface functions for TCL drivers (such as Radeon DRI)
+      - GL_RENDERER string returns "Mesa Offscreen16" or "Mesa Offscreen32"
+        if using deep color channels
+      - latest GL/glext.h and GL/glxext.h headers from SGI
+    Bug fixes:
+      - GL_BLEND with non-black texture env color wasn't always correct
+      - GL_REPLACE with GL_RGB texture format wasn't always correct (alpha)
+      - glTexEnviv( pname != GL_TEXTURE_ENV_COLOR ) was broken
+      - glReadPixels was sometimes mistakenly clipped by the scissor box
+      - glDraw/ReadPixels didn't catch all the errors that they should have
+      - Fixed 24bpp rendering problem in Windows driver (Karl Schultz)
+      - 16-bit GLchan mode fixes (m_trans_tmp.h, s_triangle.c)
+      - Fixed 1-bit float->int conversion bug in glDrawPixels(GL_DEPTH_COMP)
+      - glColorMask as sometimes effecting glXSwapBuffers()
+      - fixed a potential bug in XMesaGarbageCollect()
+      - N threads rendering into one window didn't work reliably
+      - glCopyPixels didn't work for deep color channels
+      - improved 8 -> 16bit/channel texture image conversion (Gerk Huisma)
+      - glPopAttrib() didn't correctly restore user clip planes
+      - user clip planes failed for some perspective projections (Chromium)
+
+ +

December 17, 2001

+

Mesa 4.0.1 has been released. This is a stable bug-fix release. +

    New:
+      - better sub-pixel sample positions for AA triangles (Ray Tice)
+      - slightly faster blending for (GL_ZERO, GL_ONE) and (GL_ONE, GL_ZERO)
+    Bug fixes:
+      - added missing break statements in glGet*() for multisample cases
+      - fixed uninitialized hash table mutex bug (display lists / texobjs)
+      - fixed bad teximage error check conditional (bug 476846)
+      - fixed demos readtex.c compilation problem on Windows (Karl Schultz)
+      - added missing glGet() query for GL_MAX_TEXTURE_LOD_BIAS_EXT
+      - silence some compiler warnings (gcc 2.96)
+      - enable the #define GL_VERSION_1_3 in GL/gl.h
+      - added GL 1.3 and GLX 1.4 entries to gl_mangle.h and glx_mangle.h
+      - fixed glu.h typedef problem found with MSDev 6.0
+      - build libGL.so with -Bsymbolic (fixes bug found with Chromium)
+      - added missing 'const' to glXGetContextIDEXT() in glxext.h
+      - fixed a few glXGetProcAddress() errors (texture compression, etc)
+      - fixed start index bug in compiled vertex arrays (Keith)
+      - fixed compilation problems in src/SPARC/glapi_sparc.S
+      - fixed triangle strip "parity" bug found in VTK medical1 demo (Keith)
+      - use glXGetProcAddressARB in GLUT to avoid extension linking problems
+      - provoking vertex of flat-shaded, color-index triangles was wrong
+      - fixed a few display list bugs (GLUT walker, molecule, etc) (Keith)
+      - glTexParameter didn't flush the vertex buffer (Ray Tice)
+      - feedback attributes for glDraw/CopyPixels and glBitmap were wrong
+      - fixed bug in normal length caching (ParaView lighting bug)
+
+ +

October 22, 2001

+

Mesa 4.0 has been released. This is a stable release. +

    New:
+      - Mesa 4.0 implements the OpenGL 1.3 specification
+      - GL_IBM_rasterpos_clip extension
+      - GL_EXT_texture_edge_clamp extension (aka GL_SGIS_texture_edge_clamp)
+      - GL_ARB_texture_mirrored_repeat extension
+      - WindML UGL driver (Stephane Raimbault)
+      - added OSMESA_MAX_WIDTH/HEIGHT queries
+      - attempted compiliation fixes for Solaris 5, 7 and 8
+      - updated glext.h and glxext.h files
+      - updated Windows driver (Karl Schultz)
+    Bug fixes:
+      - added some missing GLX 1.3 tokens to include/GL/glx.h
+      - GL_COLOR_MATRIX changes weren't recognized by teximage functions
+      - glCopyPixels with scale and bias was broken
+      - glRasterPos with lighting could segfault
+      - glDeleteTextures could leave a dangling pointer
+      - Proxy textures for cube maps didn't work
+      - fixed a number of 16-bit color channel bugs
+      - fixed a few minor memory leaks
+      - GLX context sharing was broken in 3.5
+      - fixed state-update bugs in glPopClientAttrib()
+      - fixed glDrawRangeElements() bug
+      - fixed a glPush/PopAttrib() bug related to texture binding
+      - flat-shaded, textured lines were broken
+      - fixed a dangling pointer problem in the XMesa code (Chris Burghart)
+      - lighting didn't always produce the correct alpha value
+      - fixed 3DNow! code to not read past end of arrays (Andrew Lewycky)
+
+ + +

June 21, 2001

+

Mesa 3.5 has been released. This is a new development release. +

    New:
+	- internals of Mesa divided into modular pieces (Keith Whitwell)
+	- 100% OpenGL 1.2 conformance (passes all conformance tests)
+	- new AA line algorithm
+	- GL_EXT_convolution extension
+        - GL_ARB_imaging subset
+        - OSMesaCreateContextExt() function
+        - GL_ARB_texture_env_add extension (same as GL_EXT_texture_env_add)
+        - GL_MAX_TEXTURE_UNITS_ARB now defaults to eight
+        - GL_EXT_fog_coord extension (Keith Whitwell)
+        - GL_EXT_secondary_color extension (Keith Whitwell)
+        - GL_ARB_texture_env_add extension (same as GL_EXT_texture_env_add)
+        - GL_SGIX_depth_texture extension
+        - GL_SGIX_shadow and GL_SGIX_shadow_ambient extensions
+        - demos/shadowtex.c demo of GL_SGIX_depth_texture and GL_SGIX_shadow
+        - GL_ARB_texture_env_combine extension
+        - GL_ARB_texture_env_dot3 extension
+        - GL_ARB_texture_border_clamp (aka GL_SGIS_texture_border_clamp)
+        - OSMesaCreateContextExt() function
+        - libOSMesa.so library, contains the OSMesa driver interface
+        - GL/glxext.h header file for GLX extensions
+        - somewhat faster software texturing, fogging, depth testing
+        - all color-index conformance tests now pass (only 8bpp tested)
+        - SPARC assembly language TCL optimizations (David Miller)
+        - GL_SGIS_generate_mipmap extension
+    Bug Fixes:
+        - fbiRev and tmuRev were unitialized when using Glide3
+        - fixed a few color index mode conformance failures; all pass now
+        - now appling antialiasing coverage to alpha after texturing
+        - colors weren't getting clamped to [0,1] before color table lookup
+        - fixed RISC alignment errors caused by COPY_4UBV macro
+        - drawing wide, flat-shaded lines could cause a segfault
+        - vertices now snapped to 1/16 pixel to fix rendering of tiny triangles
+    Changes:
+        - SGI's Sample Implementation (SI) 1.3 GLU library replaces Mesa GLU
+        - new libOSMesa.so library, contains the OSMesa driver interface
+
+ + +

May 17, 2001

+

Mesa 3.4.2 has been released. This is basically just a bug-fix release. +Here's what's new:

+
    Bug fixes:
+        - deleting the currently bound texture could cause bad problems
+        - using fog could result in random vertex alpha values
+         - AA triangle rendering could touch pixels outside right window bound
+        - fixed byteswapping problem in clear_32bit_ximage() function
+        - fixed bugs in wglUseFontBitmapsA(), by Frank Warmerdam
+        - fixed memory leak in glXUseXFont()
+        - fragment sampling in AA triangle function was off by 1/2 pixel
+        - Windows: reading pixels from framebuffer didn't always work
+        - glConvolutionFilter2D could segfault or cause FP exception
+        - fixed segfaults in FX and X drivers when using tex unit 1 but not 0
+        - GL_NAND logicop didn't work right in RGBA mode
+        - fixed a memory corruption bug in vertex buffer reset code
+        - clearing the softwara alpha buffer with scissoring was broken
+        - fixed a few color index mode fog bugs
+        - fixed some bad assertions in color index mode
+        - fixed FX line 'stipple' bug #420091
+    Changes:
+        - optimized writing mono-colored pixel spans to X pixmaps
+        - increased max viewport size to 2048 x 2048
+
+ + +

April 29, 2001

+

New Mesa website

+

Mark Manning produced the new website.
Thanks, Mark!

+ + +

February 14, 2001

+

Mesa 3.4.1 has been released. Here's what's new:

+
    New:
+        - fixed some Linux build problems
+        - fixed some Windows build problems
+        - GL_EXT_texture_env_dot3 extension (Gareth Hughes)
+    Bug fixes:
+        - added RENDER_START/RENDER_FINISH macros for glCopyTexImage in DRI
+        - various state-update code changes needed for DRI bugs
+        - disabled pixel transfer ops in glColorTable commands, not needed
+        - fixed bugs in glCopyConvolutionFilter1D/2D, glGetConvolutionFilter
+        - updated sources and fixed compile problems in widgets-mesa/
+        - GLX_PBUFFER enum value was wrong in glx.h
+        - fixed a glColorMaterial lighting bug
+        - fixed bad args to Read/WriteStencilSpan in h/w stencil clear function
+        - glXCopySubBufferMESA() Y position was off by one
+        - Error checking of glTexSubImage3D() was broken (bug 128775)
+        - glPopAttrib() didn't restore all derived Mesa state correctly
+        - Better glReadPixels accuracy for 16bpp color - fixes lots of OpenGL
+          conformance problems at 16bpp.
+        - clearing depth buffer with scissoring was broken, would segfault
+        - OSMesaGetDepthBuffer() returned bad bytesPerValue value
+        - fixed a line clipping bug (reported by Craig McDaniel)
+        - fixed RGB color over/underflow bug for very tiny triangles
+    Known problems:
+        - NURBS or evaluator surfaces inside display lists don't always work
+
+

+

November 3, 2000

+

Mesa 3.4 has been released. Here's what's new since the 3.3 release:

+
    New:
+    - optimized glDrawPixels for glPixelZoom(1,-1)
+    Bug Fixes:
+    - widgets-mesa/src/*.c files were missing from 3.3 distro
+    - include/GL/mesa_wgl.h file was missing from 3.3 distro
+    - fixed some Win32 compile problems
+    - texture object priorities weren't getting initialized to 1.0
+    - glAreTexturesResident return value was wrong when using hardware
+    - glXUseXFont segfaulted when using 3dfx driver (via MESA_GLX_FX)
+    - glReadPixels with GLushort packed types was broken
+    - fixed a few bugs in the GL_EXT_texture_env_combine texture code
+    - glPush/PopAttrib(GL_ENABLE_BIT) mishandled multi-texture enables
+    - fixed some typos/bugs in the VB code
+    - glDrawPixels(GL_COLOR_INDEX) to RGB window didn't work
+    - optimized glDrawPixels paths weren't being used
+    - per-fragment fog calculation didn't work without a Z buffer
+    - improved blending accuracy, fixes Glean  blendFunc test failures
+    - glPixelStore(GL_PACK/UNPACK_SKIP_IMAGES) wasn't handled correctly
+    - glXGetProcAddressARB() didn't always return the right address
+    - gluBuild[12]DMipmaps() didn't grok the GL_BGR pixel format
+    - texture matrix changes weren't always detected (GLUT projtex demo)
+    - fixed random color problem in vertex fog code
+    - fixed Glide-related bug that let Quake get a 24-bit Z buffer
+    Changes:
+    - finished internal support for compressed textures for DRI
+
+

+

April 24, 2000

+

Mesa 3.2 has been released. Here's what's new since the beta release:

+
    Bug fixes:
+    - fixed memcpy bugs in span.c
+    - fixed missing glEnd problem in demos/tessdemo.c
+    - fixed bug when clearing 24bpp Ximages
+    - fixed clipping problem found in Unreal Tournament
+    - fixed Loki's "ice bug" and "crazy triangles" seen in Heretic2
+    - fixed Loki's 3dfx RGB vs BGR bug
+    - fixed Loki's 3dfx smooth/flat shading bug in SoF
+    Changes:
+    - updated docs/README file
+    - use bcopy() optimizations on FreeBSD
+    - re-enabled the optimized persp_textured_triangle() function
+
+

+

March 23, 2000

+

I've just upload the Mesa 3.2 beta 1 files to SourceForge at http://sourceforge.net/project/filelist.php?group_id=3

+

3.2 (note even number) is a stabilization release of Mesa 3.1 meaning it's mainly +just bug fixes.

+

Here's what's changed: + +

    + Bug fixes: +
      + - mixed drawing of lines and bitmaps sometimes had wrong colors
      + - added missing glHintPGI() function
      + - fixed a polygon culling bug
      + - fixed bugs in gluPartialDisk()
      + - Z values in selection mode were wrong
      + - added missing tokens: +
        + GL_SMOOTH_POINT_SIZE_RANGE
        + GL_SMOOTH_POINT_SIZE_GRANULARITY
        + GL_SMOOTH_LINE_WIDTH_RANGE
        + GL_SMOOTH_LINE_WIDTH_GRANULARITY
        + GL_ALIASED_POINT_SIZE_RANGE
        + GL_ALIASED_LINE_WIDTH_RANGE +
      + - fixed glCopyPixels when copying from back to front buffer
      + - GL_EXT_compiled_vertex_array tokens had _SGI suffix instead of _EXT
      + - glDrawRangeElements(GL_LINES, 0, 1, 2, type, indices) was broken
      + - glDeleteTextures() didn't decrement reference count correctly
      + - GL_SRCA_ALPHA_SATURATE blend mode didn't work correctly
      + - Actual depth of transformation matrix stacks was off by one
      + - 24bpp visuals didn't address pixels correctly
      + - mipmap level of detail (lambda) calculation simplified, more accurate
      + - 101691 - Polygon clipping and GL_LINE
      + - 101928 - Polygon clipping and GL_LINE (same fix as above)
      + - 101808 - Non-glVertexArrays tristrip bug
      + - 101971 - find_last_3f on Dec OSF (worked around)
      + - 102369 - segv on dec osf (possibly a duplicate of the above)
      + - 102893 - orientations of modelview cause segfault +
    + New: +
      + - updated SVGA Linux driver
      + - added the MESA_FX_NO_SIGNALS env var, see docs/README.3DFX
      + - build libGLw.a (Xt/OpenGL drawing area widget) library by default
      + - changed -O2 to -O3 for a number of gcc configs +
    + Changes: +
      + - glXCopyContext's mask parameter is now unsigned long, per GLX spec +
    +
+ +

Please report any problems with this release ASAP. Bugs should be filed on the +Mesa3D website at sourceforge.
+After 3.2 is wrapped up I hope to release 3.3 beta 1 soon afterward.

+

-- Brian

+

+

December 17, 1999

+

A Slashdot interview with Brian about Mesa (questions submitted by Slashdot readers) +can be found at http://slashdot.org/interviews/99/12/17/0927212.shtml.

+

+

December 14, 1999

+

Mesa 3.1 is released!

+

+

September 21, 1999

+

There appear to be two new files on the ftp site, MesaLib-3.1beta3.tar.gz +and MesaDemos-3.1beta3.tar.gz, +that seem to be... yes, I've just received confirmation from the beta center, they +are indeed the THIRD beta release of Mesa 3.1! Happy Days. Happy Days. Thanks +Keith Whitwell for preparing these for us during Brian's absence.

+

+

August 30, 1999

+

I'm pleased to announce that I've accepted a position with Precision Insight, +Inc. effective October, 1999. I'll be leaving Avid Technology in September.

+

I've been working on Mesa in my spare time for over five years. With Precision +Insight I now have the opportunity to devote my full attention to advancing Mesa +and OpenGL on Linux.

+

While I'll be focused on Linux, the X Window System, and hardware acceleration, +my work will continue to be open sourced and available to any other programmers who +may want to contribute to it, or use it for other projects or platforms

+

PS: I'm going to be traveling until Sep 6 and won't be reading email until then.

+

+

August 23, 1999

+

Anonymous CVS access is back online so suck up all the bandwidth you can afford. +Note that this is a new archive, so you will need to re-checkout the archive. That +means don't cvs update from a previous download.

+

+

August 17, 1999

+

A report from the SIGGRAPH '99 Linux/OpenGL +BOF meeting is now available.

+

-Brian

+

+

August 14, 1999

+

www.mesa3d.org is having technical problems due to hardware failures at VA Linux +systems. The Mac pages, ftp, and CVS services aren't fully restored yet. Please be +patient.

+

-Brian

+

+

June 7, 1999

+

RPMS of the nVidia RIVA server can be found at ftp://ftp.mesa3d.org/mesa/misc/nVidia/.

+

+

June 2, 1999

+

nVidia has released some Linux binaries for +xfree86 3.3.3.1, along with the full source, which includes GLX acceleration +based on Mesa 3.0. They can be downloaded from http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html.

+

+

May 24, 1999

+

Beta 2 of Mesa 3.1 has been make available at ftp://ftp.mesa3d.org/mesa/beta/. +If you are into the quake scene, you may want to try this out, as it contains some +optimizations specifically in the Q3A rendering path. +

+

May 13, 1999

+

For those interested in the integration of Mesa into XFree86 4.0, Precision Insight +has posted their lowlevel design documents at http://www.precisioninsight.com.

+

+

May 13, 1999

+
May 1999 - John Carmack of id Software, Inc. has made a donation of
+US$10,000 to the Mesa project to support its continuing development.
+Mesa is a free implementation of the OpenGL 3D graphics library and id's
+newest game, Quake 3 Arena, will use Mesa as the 3D renderer on Linux.
+
+The donation will go to Keith Whitwell, who has been optimizing Mesa to
+improve performance on 3d hardware.  Thanks to Keith's work, many
+applications using Mesa 3.1 will see a dramatic performance increase
+over Mesa 3.0.  The donation will allow Keith to continue working on
+Mesa full time for some time to come.
+
+For more information about Mesa see www.mesa3d.org.  For more
+information about id Software, Inc. see www.idsoftware.com.
+
+--------------------------------
+
+This donation from John/id is very generous.  Keith and I are very
+grateful.
+
+
+

+

May 1, 1999

+

John Carmack made an interesting .plan update yesterday: + +

    + "I put together a document on optimizing OpenGL drivers for Q3 that + should be helpful to the various Linux 3D teams.
    +     http://www.quake3arena.com/news/glopt.html" +
+ +

+

April 7, 1999

+

Updated the Mesa contributors section and added links to RPM Mesa packages.

+

+

March 18, 1999

+

The new webpages are now online. Enjoy, and let me know if you find any errors. +For an eye-candy free version you can use http://www.mesa3d.org/txt/.

+

+

February 16, 1999

+

SGI releases its GLX +source code.

+

+

January 22, 1999

+

www.mesa3d.org established

+ + +

+ + +
+$Id: news.html,v 3.15.2.4 2004/12/09 23:23:47 brianp Exp $ + + \ No newline at end of file diff --git a/docs/osmesa.html b/docs/osmesa.html new file mode 100644 index 0000000..6ed3c5e --- /dev/null +++ b/docs/osmesa.html @@ -0,0 +1,75 @@ + + +Off-screen Rendering + + + +

Off-screen Rendering

+ + +

+Mesa 1.2.4 introduced off-screen rendering, a facility for generating +3-D imagery without having to open a window on your display. Mesa's +simple off-screen rendering interface is completely operating system +and window system independent so programs which use off-screen +rendering should be very portable. This feature effectively +enables you to use Mesa as an off-line, batch-oriented renderer. +

+

+The "OSMesa" API provides 3 functions for making off-screen +renderings: OSMesaCreateContext(), OSMesaMakeCurrent(), and +OSMesaDestroyContext(). See the Mesa/include/GL/osmesa.h header for +more information. See the demos/osdemo.c file for an example program. +There is no facility for writing images to files. That's up to you. +

+

+If you want to generate large images (larger than 1280x1024) you'll +have to edit the src/config.h file to change MAX_WIDTH and MAX_HEIGHT +then recompile Mesa. Image size should only be limited by available +memory. +

+ + +

Deep color channels

+ +

+ For some applications 8-bit color channels don't have sufficient + accuracy (film and IBR, for example). If you're in this situation + you'll be happy to know that Mesa supports 16-bit and 32-bit color + channels through the OSMesa interface. When using 16-bit channels, + channels are GLushorts and RGBA pixels occupy 8 bytes. When using 32-bit + channels, channels are GLfloats and RGBA pixels occupy 16 bytes. +

+

+ To build Mesa/OSMesa with 16-bit color channels: +

+      make realclean
+      make linux-osmesa16
+
+ + For 32-bit channels: +
+      make realclean
+      make linux-osmesa32
+
+ +

+You'll wind up with a library named libOSMesa16.so or libOSMesa32.so. +

+ +

+If you need to compile on a non-Linux platform, copy Mesa/configs/linux-osmesa16 +to a new config file and edit it as needed. Then, add the new config name to +the top-level Makefile. Send a patch to the Mesa developers too, if you're +inclined. +

+ +

+BE WARNED: 16 and 32-bit channel support has not been exhaustively +tested and there may be some bugs. However, a number of people have +been using this feature successfully so it can't be too broken. +

+ + + + diff --git a/docs/pbuffers.html b/docs/pbuffers.html new file mode 100644 index 0000000..74af478 --- /dev/null +++ b/docs/pbuffers.html @@ -0,0 +1,51 @@ + + +PBuffer Rendering + + + +

PBuffer Rendering

+ +

+Basically, FBconfigs and PBuffers allow you to do off-screen rendering +with OpenGL. The OSMesa interface does basically the same thing, but +fbconfigs and pbuffers are supported by more vendors. +

+ +

+PBuffers are getting more use nowadays, though they've actually been +around for a long time on IRIX systems and other workstations. +

+ +

+The +GL_SGIX_fbconfig +and + +GL_SGIX_pbuffer extensions describe the functionality. +More recently, these extensions have been promoted to ARB extensions (on +Windows at least). +

+ +

+The Mesa/progs/xdemos/ directory has some useful code for working +with pbuffers: +

+ +
    +
  • pbinfo.c - like glxinfo, it prints a list of available + fbconfigs and whether each supports pbuffers. +
  • pbutil.c - a few utility functions for dealing with + fbconfigs and pbuffers. +
  • pbdemo.c - a demonstration of off-screen rendering with pbuffers. +
+ +

+Mesa 4.1 and later support GL_SGIX_fbconfig and GL_SGIX_pbuffer (software +rendering only). +

+ + + diff --git a/docs/perf.html b/docs/perf.html new file mode 100644 index 0000000..89f6eae --- /dev/null +++ b/docs/perf.html @@ -0,0 +1,66 @@ + + +Performance Tips + + + +

Performance Tips

+ +

+Performance tips for software rendering: +

+
    + +
  1. Turn off smooth shading when you don't need it (glShadeModel) +
  2. Turn off depth buffering when you don't need it. +
  3. Turn off dithering when not needed. +
  4. Use double buffering as it's often faster than single buffering +
  5. Compile in the X Shared Memory extension option if it's supported + on your system by adding -DSHM to CFLAGS and -lXext to XLIBS for + your system in the Make-config file. +
  6. Recompile Mesa with more optimization if possible. +
  7. Try to maximize the amount of drawing done between glBegin/glEnd pairs. +
  8. Use the MESA_BACK_BUFFER variable to find best performance in double + buffered mode. (X users only) +
  9. Optimized polygon rasterizers are employed when: + rendering into back buffer which is an XImage + RGB mode, not grayscale, not monochrome + depth buffering is GL_LESS, or disabled + flat or smooth shading + dithered or non-dithered + no other rasterization operations enabled (blending, stencil, etc) +
  10. Optimized line drawing is employed when: + rendering into back buffer which is an XImage + RGB mode, not grayscale, not monochrome + depth buffering is GL_LESS or disabled + flat shading + dithered or non-dithered + no other rasterization operations enabled (blending, stencil, etc) +
  11. Textured polygons are fastest when: + using a 3-component (RGB), 2-D texture + minification and magnification filters are GL_NEAREST + texture coordinate wrap modes for S and T are GL_REPEAT + GL_DECAL environment mode + glHint( GL_PERSPECTIVE_CORRECTION_HINT, GL_FASTEST ) + depth buffering is GL_LESS or disabled +
  12. Lighting is fastest when: + Two-sided lighting is disabled + GL_LIGHT_MODEL_LOCAL_VIEWER is false + GL_COLOR_MATERIAL is disabled + No spot lights are used (all GL_SPOT_CUTOFFs are 180.0) + No local lights are used (all position W's are 0.0) + All material and light coefficients are >= zero +
  13. XFree86 users: if you want to use 24-bit color try starting your + X server in 32-bit per pixel mode for better performance. That is, + start your X server with + startx -- -bpp 32 + instead of + startx -- -bpp 24 +
  14. Try disabling dithering with the MESA_NO_DITHER environment variable. + If this env var is defined Mesa will disable dithering and the + command glEnable(GL_DITHER) will be ignored. +
+ + + + diff --git a/docs/precompiled.html b/docs/precompiled.html new file mode 100644 index 0000000..9696a45 --- /dev/null +++ b/docs/precompiled.html @@ -0,0 +1,24 @@ + + +Precompiled libraries + + + +

Precompiled Libraries

+ +

+In general, precompiled libraries are not available. +However, people occasionally prepare packages of precompiled libraries +for some systems. +

+ +

Mesa-6.0 for Solaris

+ +

+Steve Christensen has submitted precompiled Mesa-6.0 libraries for +Solaris at +sunfreeware.com. +

+ + + diff --git a/docs/relnotes.html b/docs/relnotes.html new file mode 100644 index 0000000..0c64504 --- /dev/null +++ b/docs/relnotes.html @@ -0,0 +1,39 @@ + + +Mesa Release Notes + + + +

Release Notes

+ +

+The release notes summarize what's new or changed in each Mesa release. +

+ + + + + + diff --git a/docs/science.html b/docs/science.html new file mode 100644 index 0000000..6baac21 --- /dev/null +++ b/docs/science.html @@ -0,0 +1,70 @@ + + +Science and Technical + + + +

Science and Technical

+ +
    +
  • Ch - OpenGL bindings for the Ch C/C++ interpreter +
  • CLEO3D - event displayer for the CLEOIII detector +
  • DINO - Visualizing + Structural Biology +
  • General + Mesh Viewer (GMV) - scientific vis. +
  • GiD - finite element + analysis +
  • glpoisson - A finite + element analysis program that simulates wave in an arbitrary region. +
  • GLWaves - + Electromagnetic wave visualization +
  • Gmsh - + finite element mesh generator / viewer +
  • gOpenMol + - computational chemistry +
  • GPS 3D - GPS-based map visualization +
  • Hitchhiker + - virtual solar system +
  • Hydra - physics + and engineering pkg +
  • Light Speed + - a real-time, interactive relativistic simulator +
  • LinkWinds - scientific + vis +
  • MathGL3d - Mathematica viewer +
  • Mathworks + - mathematics and visualization +
  • Medit - 3D surface mesh viewer +
  • MOLMOL + - molecular modeling and analysis +
  • Molscript - molecular + modeling +
    • +
  • OpenDX - Data visualization + system +
    • +
  • ORSA - An interactive tool for Celestial Mechanics +
    • +
  • ParaView - Scientific visualization package +
    • +
  • PHLEX - Finite element vis +
  • ROOT - Object Oriented Data + Analysis Framework +
  • SLFFEA - GNU finite element + package +
  • Spock - molecular + modeling +
  • Ssystem - solar + system simulation +
  • SPARROW - robot simulation +
  • Vis5D + - atmospheric visualization +
  • VMD - molecular + modeling +
  • Webots - 3-D mobile + robot simulator +
+ + + \ No newline at end of file diff --git a/docs/sourcedocs.html b/docs/sourcedocs.html new file mode 100644 index 0000000..c388769 --- /dev/null +++ b/docs/sourcedocs.html @@ -0,0 +1,24 @@ + + +Source Code Documentation + + + +

Source Code Documentation

+ +

+Doxygen +is used to automatically +produce cross-referenced documentation from the Mesa sources. +This is not included in the normal Mesa distribution. +Download Mesa from CVS if interested. +

+ +

+If you're reading this page from your local copy of Mesa, and have +run the doxygen scripts, you can read the documentation +here +

+ + + diff --git a/docs/subset-A.html b/docs/subset-A.html new file mode 100644 index 0000000..dac66a6 --- /dev/null +++ b/docs/subset-A.html @@ -0,0 +1,3579 @@ + + + + Mini GLX Specification + + + +

+
Mesa Subset Specification
+

+

+
+

Tungsten Graphics, Inc.

+

February 26, 2003
+

+
+

+

Copyright © 2002-2003 by Tungsten Graphics, Inc., +Cedar Park, Texas. All Rights Reserved.
+
+Permission is granted to make and distribute verbatim copies of this +document provided the copyright notice and this permission notice are +preserved on all copies.
+

+

OpenGL is a trademark of Silicon +Graphics, Inc..

+

1. Introduction

+This document describes a subset of the Mesa implemented by Tungsten +Graphics, Inc. for embedded devices.  Prior to reading this +document the reader should be familiar with the OpenGL 1.2.1 +specification dated April 1, 1999 (available from http://www.opengl.org/developers/documentation/specs.html.) + Experience with OpenGL programming is highly advisable.
+
+Tungsten Graphics, Inc. is working with industry standards +organizations +in an attempt to standardize this Mesa subset and any +other possible subsets +as a result of this work.
+
+Appendix A contains a list of issues of which some may not be resolved.
+
+To summarize, the following major features of Mesa are omitted from the +subset:
+
    +
  • Vertex arrays
    • +
  • Texture coordinate generation
    • +
  • Lighting
    • +
  • Point size
    • +
  • Polygon stipple
    • +
  • DrawPixels, CopyPixels, PixelZoom
    • +
  • 1-D and 3-D textures
    • +
  • CopyTex[Sub]Image
    • +
  • Fog
    • +
  • Depth test
    • +
  • Color Index mode
    • +
  • Accumulation buffer
    • +
  • Feedback mode
    • +
  • Evaluators
    • +
  • Push/Pop attributes
    • +
  • Display lists
    +
    • +
+

Further reductions are made at a lower level of detail.
+

+

Mesa function names are printed in bold +face.  Function parameters are printed in italics.
+

+

The Tungsten Graphics, Inc. Mesa subset library is hereafter +referred to as the subset.
+
+

+

2. Primitive Specification

+

2.1 glBegin, glEnd and glVertex Commands

+The basic rendering primitives are points, lines and triangles. + Quadrilaterals and polygons are composed of triangles. + Primitives are drawn with the glBegin +and glEnd commands and a subset +of the glVertex commands:
+
+
void glBegin(GLenummode)
+void glEnd(void)
+
+void glVertex2f(GLfloat x, GLfloat y)
+void glVertex2fv(const GLfloat +*v)
+void glVertex3f(GLfloat x, GLfloat y, GLfloat z)
+void glVertex3fv(const GLfloat +*v)
+
+
+The mode parameter to glBegin may be one of the following
+
+
GL_POINTS - a series of individual +points
+GL_LINES - a series of disjoint line segments
+GL_LINE_STRIP - series of connected line segments
+GL_LINE_LOOP - a closed loop of line segments
+GL_TRIANGLES - a series of individual triangles
+GL_TRIANGLE_STRIP - a connected strip of triangles
+GL_TRIANGLE_FAN - a sequence of triangles all sharing a common vertex
+GL_QUADS - a sequence of individual quadrilaterals
+GL_QUAD_STRIP - a connected strip of quadrilaterals
+GL_POLYGON - a closed, convex polygon
+
+
+
+The glVertex commands take two +or three floating point coordinates, or a pointer to an array of two or +three floating point coordinates.  Vertices are actually 4-element +homogeneous coordinates.  The fourth component, unspecified by the +subset's glVertex commands, is +one.
+
+ +

2.2 Other Per-vertex Commands
+

+The glColor and glTexCoord commands may be used to +specify colors and texture coordinates for each vertex:
+
+
void glColor3f(GLfloatred, GLfloat green, GLfloat blue)
+void glColor3fv(const GLfloat *rgb)
+void glColor4f(GLfloat red, GLfloat green, GLfloat blue, GLfloat alpha)
+void glColor4fv(const GLfloat *rgba)
+void glTexCoord2f(GLfloat s, GLfloat t)
+void glTexCoord2fv(const +GLfloat *c)
+
+
+The glColor commands specify +the color and optionally, the alpha value, for subsequent vertices. + For the glColor3 commands, +alpha is set to one.
+
+The glTexCoord2 commands +specify the texture coordinate for subsequent vertices.  Texture +coordinates are actually four-component coordinates: (s, t, r, q). + The glTexCoord2 commands +set s and t explicitly.  The r and q components are zero and one, +respectively.
+
+Only glVertex, glColor and glTexCoord commands are allowed +between glBegin and glEnd.  Calling any other +command between glBegin and glEnd will result in the error +GL_INVALID_OPERATION.
+
+

2.3 Unsupported Commands

+None of the following commands related to primitive specification are +supported by the subset:
+
+
Per-Vertex commands:
+
+
+
glVertex2d, +glVertex2i, glVertex2s, glVertex3d, glVertex3i, glVertex3s, glVertex4d, +glVertex4i, glVertex4s, glVertex2dv, glVertex2iv, glVertex2sv, +glVertex3dv, glVertex3iv, glVertex3sv, glVertex4dv, glVertex4iv, +glVertex4sv,
+glNormal3b, glNormal3d, glNormal3f, glNormal3i, glNormal3s, glNormal3bv, glNormal3dv, glNormal3fv, +glNormal3iv, glNormal3sv,
+glIndexd, glIndexf, glIndexi, glIndexs, glIndexub, glIndexdv, +glIndexfv, glIndexiv, glIndexsv, glIndexubv,
+glColor3b, glColor3d, glColor3i, glColor3s, glColor3ub, glColor3ui, +glColor3us, glColor3bv, +glColor3dv, glColor3iv, glColor3sv, glColor3ubv, glColor3uiv, +glColor3usv, lColor4b, +glColor4d, glColor4i, glColor4s, glColor4ub, glColor4ui, glColor4us, glColor4bv, glColor4dv, glColor4iv, +glColor4sv, glColor4ubv, glColor4uiv, glColor4usv,
+glTexCoord1d, glTexCoord1f, +glTexCoord1i, glTexCoord1s, glTexCoord2d, glTexCoord2i, glTexCoord2s, +glTexCoord3d, glTexCoord3f, glTexCoord3i, glTexCoord3s, glTexCoord4d, +glTexCoord4f, glTexCoord4i, glTexCoord4s, glTexCoord1dv, glTexCoord1fv, +glTexCoord1iv, glTexCoord1sv, glTexCoord2dv, glTexCoord2iv, +glTexCoord2sv, glTexCoord3dv, glTexCoord3fv, glTexCoord3iv, +glTexCoord3sv, glTexCoord4dv, glTexCoord4fv, glTexCoord4iv, +glTexCoord4sv,
+glEdgeFlag, glEdgeFlagv
+
+
+Vertex array commands:
+
glVertexPointer, +glColorPointer, glIndexPointer, glTexCoordPointer, glEdgeFlagPointer, +glNormalPointer, glInterleavedArrays, glArrayElement, glDrawArrays, +glDrawElements, glDrawRangeElements, glEnableClientState, +glDisableClientState
+
+
+

+Rectangle commands:
+
glRects, +glRecti, glRectf, glRectd, glRectsv, glRectiv, glRectfv, glRectdv,
+
+
+
+
Lighting commands:
+
+
glMaterialf, +glMateriali, glMaterialfv, glMaterialiv
+
+
+
Evaluator commands:
+
glEvalCoord1d, +glEvalCoord1f, glEvalCoord1dv, glEvalCoord1fv, glEvalCoord2d, glEvalCoord2f, +glEvalCoord2dv, glEvalCoord2fv,
+glEvalPoint1, glEvalPoint2
+
+
+
+

3. Coordinate Transformation

+

3.1 Vertex Transformation

+Vertex coordinates are transformed by the current modelview and +projection matrices then mapped to window coordinates as specified by +the viewport.  The following coordinate transformation commands are +supported by the subset
+
+
glMatrixMode(GLenum mode)
+glLoadIdentity(void)
+glPushMatrix(void)
+glPopMatrix(void)
+glLoadMatrixf(const GLfloat *m)
+glMultMatrixf(const GLfloat *m)
+glRotatef(GLfloat angle, GLfloat x, GLfloat y, GLfloat z)
+glTranslatef(GLfloat x, GLfloat y, GLfloat z)
+glScalef(GLfloat x, GLfloat y, GLfloat z)
+glFrustum(GLdouble left, GLdouble right, GLdouble bottom, GLdouble top, GLdouble near, GLdouble far)
+glOrtho(GLdouble left, GLdouble right, GLdouble bottom, GLdouble top, GLdouble near, GLdouble far)
+glViewport(GLint x, GLint y, GLsize width, GLsizei height)
+
+
+The glMatrixMode command +specifies the current matrix. + The mode parameter may be GL_MODELVIEW or GL_PROJECTION to specify +the modelview matrix or projection matrix.  Subsequent matrix +commands will effect the current matrix.  Also associated with the +modelview and projection matrices are a modelview matrix stack and +projection matrix stack.
+
+The glLoadIdentity command +replaces the current matrix with the identity matrix.  The matrix +elements are specified in column-major order.
+
+The glPushMatrix command pushes +a copy of the current matrix onto either the modelview matrix stack or +the projection matrix stack.  The glPopMatrix +command replaces the current matrix with a copy of the top matrix off +the modelview matrix stack or projection matrix stack, the pops the +stack.  Matrix stacks are useful for traversing and rendering +hierarchical models.
+
+The glMultMatrixf command +post-multiplies the current matrix by the specified matrix.  The +matrix elements are specified in column-major order.
+
+The glRotatef command +post-multiplies the current matrix by a rotation matrix defined by the +angle and rotation axis defined by x, y and z.
+
+The glTranslatef command +post-multiplies the current matrix by a translation matrix defined by +the x, y and z translation parameters.
+
+The glScalef command +post-multiplies the current matrix by a scaling matrix defined by the x, y and z scale factors.
+
+The glFrustum command +post-multiplies the current matrix by a perspective projection matrix. + The near and far values specify the position of +the hither and yon Z-axis clipping planes.  The left, right, bottom and top parameters are the X and Y +extents at the near clipping plane.  glFrustum is normally used to modify +the projection matrix.
+
+The glOrtho command +post-multiplies the current matrix by an orthographic projection matrix. + The near and far values specify the position of +the hither and yon Z-axis clipping planes.  The left, right, bottom and top parameters specify the X and +Y-axis clipping planes.  glOrtho +is normally used to modify the projection matrix.
+
+The glViewport command +specifies the mapping of coordinates from normalized device coordinates +to window coordinates.  The x +and y parameters specify the +viewport's lower-left corner in the window and the width and height parameters specify the size +of the viewport.  glViewport +does not effect the current matrix.
+
+A coordinate transformed to window coordinates is hereafter known as (xw, +yw, zw).
+
+

3.2 Clipping

+View-volume clipping automatically discards or trims primitives which +lie completely or partially outside of the view volume specified by glFrustum and glOrtho.  Note that the glViewport command does not define a +clipping region.
+
+Clipping occurs in clip coordinate +space - the coordinates produced after applying the projection +matrix.
+
+

3.3 Current Raster Position

+The current raster position specifies the location for drawing images +with glBitmap.  The current +raster position is set with the commands:
+
+
void glRasterPos2f(GLfloatx, GLfloat y)
+void glRasterPos2fv(const +GLfloat *v)
+void glRasterPos2i(GLint x, GLint y)
+void glRasterPos2iv(const +GLint *v)
+
+
+glRasterPos specifies a +4-component coordinate (x, y, 0, 1).  The coordinate is processed +like a vertex; it is transformed by the modelview matrix, the projection +matrix and mapped to the viewport.  The resulting window coordinate +is stored as the current raster position.  The coordinate is +clipped-tested against the frustum like a vertex.  If the +coordinate is clipped, then the current raster position becomes invalid +and subsequent glBitmap commands +have no effect.
+
+glRasterPos also updates the +current raster color and current raster texture coordinates.  The +current raster color is updated (copied) from the current color (as +specified by glColor). + The current raster texture coordinate is updated (copied) from the +current texture coordinate (as specified by glTexCoord).
+
+

3.4 Unsupported Commands

+The following commands related to vertex transformation are not +supported by the subset:
+
+
User-defined clip plane commands:
+
glClipPlane
+
+
+
+
Lighting and material commands:
+
glLightModeli, +glLightModelf, glLightModeliv, +glLightModelfv, glLightf, +glLighti, glLightfv, glLightiv, glColorMaterial
+
+
+
Automatic texture coordinate generation +commands:
+
+
+
glTexGend, +glTexGenf, glTexGeni, glTexGendv, +glTexGenfv, glTexGeniv,
+
+
+Double-valued commands:
+
glLoadMatrixd, +glMultMatrixd, glRotated, glTranslated, glScaled
+
+
+Depth Range command:
+
glDepthRange +(the near value is always 0.0 and the far value is always 1.0)
+
+
+Extra RasterPos commands:
+
glRasterPos2d, +glRasterPos2s, glRasterPos3d, glRasterPos3f, glRasterPos3i, +glRasterPos3s, glRasterPos4d, glRasterPos4f, glRasterPos4i, +glRasterPos4s, glRasterPos2dv, glRasterPos2sv, glRasterPos3dv, +glRasterPos3fv, glRasterPos3iv, glRasterPos3sv, glRasterPos4dv, +glRasterPos4fv, glRasterPos4iv, glRasterPos4sv
+
+
+
+
+

4. Rasterization

+This section describes the commands and options for drawing points, +lines, triangles and bitmaps.  Rasterization +is the term for the process which produces fragments from the geometric +description of a primitive (a point, line, polygon or bitmap).  For +example, given the two coordinates for the end-points of a line segment, +rasterization determines which pixels in the frame buffer are modified +to draw the line.  A +fragment is a tuple which consists of a window coordinate, colors and +texture coordinates.  The fragments produced by rasterization are +subsequently processed by the per-fragment operations described later.
+
+

4.1 Point Rasterization

+Points are rendered with the command sequence glBegin(GL_POINTS), glVertex, ... glEnd.  The window coordinate (xw, +yw, zw) is truncated to rasterize the point. + The truncated coordinate with its associated color and texture +coordinate is sent as a single fragment to the per-fragment processing +stages.
+
+The glPointSize command is not +supported; only 1-pixel points are supported.
+
+Point smoothing (antialiasing) is also not supported.
+
+

4.2 Line Rasterization

+Lines are rendered with the command sequence glBegin(mode), glVertex, glVertex, ... glEnd where mode is one of GL_LINES, +GL_LINE_STRIP or GL_LINE_LOOP.  Lines are rasterized as described +in the OpenGL specification.  Note that OpenGL specifies the half-open convention for drawing +lines: the last fragment in a line segment is omitted so that endpoint +pixels shared by two line segments will only be drawn once instead of +twice.
+
+

4.2.1 Line Width

+The width of lines can be controlled by
+
+
void glLineWidth(GLfloatwidth)
+
+
+where width is the line width +in pixels.  The width defaults to 1.0.  Attempting to set the +width to a value less than or equal to zero will raise the error +GL_INVALID_VALUE.
+
+

4.2.2 Line Stipple
+

+Lines may be stippled (i.e. dashed) with the command
+
+
glLineStipple(GLintfactor, GLushort pattern)
+
+
+pattern describes an on/off +pattern for the fragments produced by rasterization and factor specifies how many subsequent +fragments are kept or culled for each pattern bit.  Line stippling +can be enabled or disabled by the commands glEnable(GL_LINE_STIPPLE) and glDisable(GL_LINE_STIPPLE).
+
+

4.2.3 Line Antialiasing

+Lines may be antialiased.  For antialiased lines, each fragment +produced by rasterization is assigned a coverage value which describes how +much of the fragment's area is considered to be inside the line.  Later, the +alpha value of each fragment is multiplied by the coverage value. + By blending the fragments into the frame buffer, the edges of +lines appear smoothed.
+
+Line antialiasing can be enabled or disabled with the commands glEnable(GL_LINE_SMOOTH) and glDisable(GL_LINE_SMOOTH).
+
+

4.3 Polygon Rasterization

+Polygons, quadrilaterals and triangles share the same polygon +rasterization options.
+
+Triangles are rendered by the command sequence glBegin(mode),glVertex, glVertex, ... glEnd where mode may be one of GL_TRIANGLES, +GL_TRIANGLE_STRIP or GL_TRIANGLE_FAN. + For GL_TRIANGLES mode, the number of vertices should be a multiple +of three - extra vertices will be ignored.  For GL_TRIANGLE_STRIP +and GL_TRIANGLE_FAN, at least three vertices should be specified. + If less than three are specified, nothing is drawn.  
+
+Quadrilaterals are rendered by +the command sequence glBegin(mode),glVertex, glVertex, ... glEnd where mode may be one of GL_QUADS or +GL_QUAD_STRIP.   For +GL_QUADS, the number of vertices should be a multiple of four - extra +vertices will be ignored.  For GL_QUAD_STRIP, the number of +vertices should be even and at least four.  Extra vertices (one) +will be ignored.
+
+Convex polygons are rendered +by the command sequence glBegin(GL_POLYGON),glVertex, glVertex, ... glEnd. + If less than three vertices are specified, nothing is drawn.
+
+

4.3.1 Polygon Orientation

+The winding order of vertices +(clockwise or counter-clockwise) is significant.  It is used to +determine the front-facing or back-facing orientation of polygons. + By default, a front-facing polygon's vertices are in +counter-clockwise order (in window coordinates).  Figures 2.4 and +2.5 of the OpenGL 1.2.1 specification illustrate the winding order for +front-facing triangles and quadrilaterals, respectively.
+
+The command
+
+
void glFrontFace(GLenum mode)
+
+
+specifies whether clockwise or counter-clockwise winding indicates a +front-facing polygon.  If mode +is GL_CW then polygons with clockwise winding are front-facing.  If mode is GL_CCW then polygons with +counter-clockwise winding are front-facing.  The default value is +GL_CCW.  If mode is not +GL_CCW or GL_CW then the error GL_INVALID_ENUM will be raised.
+
+

4.3.2 Polygon Culling

+Polygons may be culled (discarded) depending on whether they are +front-facing or back-facing.  The command
+
+
void +glCullFace(GLenum mode)
+
+
+specifies whether front-facing, back-facing or all polygons should be +culled.  If mode is +GL_FRONT then front-facing polygons will be culled.  If mode is GL_BACK then back-facing +polygons will be culled. Otherwise, if mode +is GL_FRONT_AND_BACK then all polygons will be culled.  Any other +value for mode will raise the +error GL_INVALID_ENUM.
+
+Polygon culling is enabled and disabled with the commands glEnable(GL_CULL_FACE) and glDisable(GL_CULL_FACE), +respectively.
+
+

4.3.3 Polygon Antialiasing

+Polygons may be antialiased in order to smooth their edges. + Polygon antialiasing is enabled and disabled with the commands glEnable(GL_POLYGON_SMOOTH) and glDisable(GL_POLYGON_SMOOTH).
+
+When polygon antialiasing is enabled each fragment produced by polygon, +triangle and quadrilateral rasterization will be given a coverage value which indicates how +much of the fragment is covered by the polygon.  Fragments +completely inside the polygon have coverage 1.0.  Fragments +completely outside the polygon have zero coverage (in theory). + Fragments which intersect the polygon's edge have a coverage value +in the range (0, 1).
+
+The fragment's alpha value is multiplied by the coverage value. + By enabling the appropriate blending mode, polygon edges will +appear smoothed.
+
+

4.4 Shading

+The command
+
+
void glShadeModel(GLenummode)
+
+
+determines whether colors are interpolated between vertices during +rasterization.  If mode is +GL_FLAT then vertex colors are not interpolated.  The color used +for drawing lines, triangles and quadrilaterals is that of the last +vertex used to specify each primitive.  For polygons, the color of +the first vertex specifies the color for the entire polygon.  If mode is GL_SMOOTH then vertex colors +are linearly interpolated to produce the fragment colors.
+
+

4.5 Bitmap Rasterization

+A bitmap is a monochromatic, binary image in which each image element +(or pixel) is represented by one bit.  Fragments are only generated +for the bits (pixels) which are set.  Bitmaps are commonly used to +draw text (glyphs) and markers.
+
+A bitmap is drawn with the command
+
+
void glBitmap(GLsizeiwidth, GLsizei height, GLfloat xOrig, GLfloat yOrig, GLfloat xMove, GLfloat yMove, const  GLubyte *image)
+
+
+width and height specify the image size in +pixels.  xOrig and yOrig specify the bitmap origin. + xMove and yMove are added to the current +raster position after the bitmap is rasterized.  image is a pointer to the bitmap +data.
+
+If the current raster position is not valid, glBitmap has no effect.
+
+

4.5.1 Bitmap Unpacking

+The first step in bitmap rendering is unpacking. + Unpacking is the process of extracting image data from +client memory subject to byte swapping, non-default row strides, etc. + The unpacking parameters are specified with the command
+
+
void +glPixelStorei(GLenum pname, GLint value)
+
+
+The following unpacking parameters may be set:
+
+ + + + + + + + + + + + + + + + + + +
Parameter (pname)
+ 		Value (value)
+ 		Default
+
GL_UNPACK_ROW_LENGTH
+ 		Width of the image in memory, in +pixels.
+ 		0
+
GL_UNPACK_LSB_FIRST
+ 		GL_FALSE indicates that the most +significant bit is unpacked first from each byte.  GL_TRUE +indicates that the least significant bit is unpacked first from each +byte.
+ 		GL_FALSE
+
+
+
+The GL_UNPACK_ROW_LENGTH specifies the stride (in pixels) for advancing +from one row of the image to the next.  If it's zero, the width parameter to glBitmap specifies the width of the +image in memory.
+
+GL_UNPACK_LSB_FIRST determines whether the least significant or most +significant bit in each byte is unpacked first.  Unpacking occurs +in left to right order (in image space).
+
+The value of bit (i, j) of the image (where i is the image row and j is +the image column) is found as follows:
+
+
rowLength = (GL_UNPACK_ROW_LENGTH != 0) +? GL_UNPACK_ROW_LENGTH : width;
+
+byte = image[((rowLength + 7) +/ 8) * i + j / 8];
+
+if (GL_UNPACK_LSB_FIRST != 0)
+    bitMask = 1 << (j % 8);
+else
+    bitMask = 128 >> (j % 8);
+
+if (byte & bitMask)
+    bit = 1;
+else
+    bit = 0;
+
+
+ +

4.5.2 Rasterization

+If the current raster position is (xrp, yrp, zrp, +wrp), then the bitmap is rasterized according to the +following algorithm:
+
+for (j = 0; j < height; +j++) {
+    for (i = 0; i < width; +i++) {
+        if (bit(i,j)) {
+            fragment.x = +floor(xrp - xOrig) ++ i;
+            fragment.y = +floor(yrp - yOrig) ++ j;
+            fragment.color += GL_CURRENT_RASTER_COLOR;
+            +fragment.texture = GL_CURRENT_RASTER_TEXTURE_COORDS;
+            +ProcessFragment(fragment)
+         }
+    }
+}
+
+After the bitmap has been rendered the current raster position is +updated as follows:
+
+
xrp = xrp + xMove
+yrp = yrp + yMove
+
+
+

4.5.3 Per-fragment Operations

+XXX supported?  See issue in appendix A.
+
+

4.6 Unsupported Commands

+The following commands related to rasterization are not supported by +the subset.
+
+
Point commands:
+
glPointSize
+
+
+Polygon commands:
+
glPolygonStipple
+glPolygonOffset
+glPolygonMode
+
+
+
+
Pixel storage commands:
+
+
glPixelStoref
+
+
+
+

5. Texture Mapping
+

+There are four elements to texture mapping: texture coordinate +specification, texture image specification, texture sampling and texture +application.
+
+Texture mapping is enabled and disabled with the commands glEnable(GL_TEXTURE_2D) and glDisable(GL_TEXTURE_2D).
+
+

5.1 Texture Image Specification

+A texture image is specified with the command:
+
+
void glTexImage2D(GLenum target, GLint level, GLint internalFormat, GLsizei width, GLsizei height, GLint border, GLenum format, GLenum type, const GLvoid *pixels )
+
+
+target must be GL_TEXTURE_2D. + level indicates the +mipmap level for mipmap textures.  internalFormat +is a hint to indicate the preferred internal storage format for the +texture.  width and height indicate the image size in +pixels (or texels).  border must +be zero.  format and type describe the pixel format and +data type for the incoming image.  pixels +points to the incoming texture image.  These parameters are +described in more detail below.
+
+

5.1.1 Texture Image Size and Mipmaps

+

+Texture images must have dimensions (width and height) that are powers +of two. For example: 256 x 256, 32 x 1024, 1 x 8, etc.  That is, it +must be the case that width = +2n and height = 2m +for some positive integers n and m.
+
+Mipmapping is a method of antialiasing or filtering textures to improve +their appearance.  A mipmap is a set of images consisting of a base +image and a set of filtered, reduced-resolution images.  If the +base image (level=0) is of +width 2n and height 2m then the level 1 image must +be of width 2n-1 and height 2m-1.  Each mipmap +level is half the width and height of the previous level, or at least +one.  The last mipmap level has a width and height of one.
+
+The following is an example of a mipmap's image levels:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
mipmap level
+ 		width
+ 		height
+
0
+ 		256
+ 		64
+
1
+ 		128
+ 		32
+
2
+ 		64
+ 		16
+
3
+ 		32
+ 		8
+
4
+ 		16
+ 		4
+
5
+ 		8
+ 		2
+
6
+ 		4
+ 		1
+
7
+ 		2
+ 		1
+
8
+ 		1
+ 		1
+
+
+If the width or height parameters are not powers of +two, the error GL_INVALID_VALUE is raised.  If the image levels in +a mipmap do not satisfy the restrictions listed above the texture is +considered to be inconsistent +and the system will behave as if the texturing is disabled.
+
+

5.1.2 Texture Image Formats and Unpacking

+The glTexImage2D command's format and type parameters describe the format +of the incoming texture image.  Accepted values for format are GL_INTENSITY, GL_RGB and +GL_RGBA.  The type +parameter must be GL_UNSIGNED_BYTE.  Pixel component values are +thus in the range 0 through 255.
+
+If format is GL_INTENSITY then +the image has one byte per pixel which specifies the pixel's red, green, +blue and alpha values.
+
+If format is GL_RGB then the +image has three bytes per pixel which specify the pixel's red, green and +blue values (in that order).  The alpha value defaults to 255.
+
+If format is GL_RGBA then the +image has four bytes per pixel which specify the pixel's red, green, +blue and alpha values (in that order).
+
+The command
+
+
void +glPixelStorei(GLenum pname, +GLint value)
+
+
+controls the unpacking of texture image data from client memory.  pname may be GL_UNPACK_ROW_LENGTH to +indicate the stride, in pixels, between subsequent rows of the image in +client memory.  If GL_UNPACK_ROW_LENGTH is zero (the default) then +the width parameter to glTexImage2D determines the stride.
+
+

5.1.3 Internal Texture Format

+glTexImage2D converts the incoming +texture image to one of the supported internal texture formats.
+
+The internalFormat parameter +indicates the desired internal format for the texture and may be either +GL_INTENSITY8, GL_RGB5 or GL_RGBA8.
+
+If internalFormat is +GL_INTENSITY8 then the texture has one byte per texel (texture element) +which indicates the texel's intensity (or brightness).  The +intensity is obtained from the incoming image's red channel.
+
+If internalFormat is GL_RGB5 +then the texture is stored with two bytes per texel:  5 bits per +red value, 5 bits per green value and 5 bits per blue value.
+
+If internalFormat is +GL_RGBA8 then the texture is stored with four bytes per texel:  8 +bits for each of the red, green,  blue and alpha values.
+
+The internal format is also significant to texture application (see +section 5.4).
+
+

5.2 Texture Coordinates

+Texture coordinates control the mapping from local polygon space to +texture image space.  Texture coordinates are set for each vertex +with the glTexCoord commands. + During line and polygon rasterization the vertex's texture +coordinates are interpolated across the primitive to produce a texture +coordinate for each fragment.  The fragment texture coordinates are +used to sample the current texture image.
+
+Texture coordinates are normally in the range [0, 1].  Values +outside that range are processed according to the texture wrap mode.  The +texture wrap mode is set with the command
+
+
void glTexParameteri(GLenum target, GLenum pname, GLint value)
+
+
+target must be GL_TEXTURE_2D. + If pname is +GL_TEXTURE_WRAP_S or GL_TEXTURE_WRAP_T then value must be either +GL_CLAMP_TO_EDGE or GL_REPEAT.
+
+For GL_CLAMP_TO_EDGE, texture coordinates are effectively clamped to +the interval [0, 1].
+
+For GL_REPEAT, the integer part of texture coordinates is ignored; only +the fractional part of the texture coordinates is used.  This +allows texture images to repeated or tiled across an object.
+
+

5.3 Texture Sampling

+Texture sampling is the process of using texture coordinates to extract +a color from the texture image.  Multiple, weighted samples may be +taken from the texture and combined during the filtering step.
+
+During texture coordinate interpolation a level of detail value (lambda) is +computed for each fragment.  For a mipmapped texture, lambda +determines which level (or levels) of the mipmap will be sampled to +obtain the texture color.
+
+If lambda indicates that multiple texels map to a single screen pixel, +then the texture minification +filter will be used.  Otherwise, if lambda indicates that a single +texel maps to multiple screen pixels, then the texture magnification filter will be used.
+
+

5.3.1 Texture Minification

+The texture minification filter is set with the glTexParameteri command by setting target to GL_TEXTURE_2D, setting pname to GL_TEXTURE_MIN_FILTER and +setting value to GL_NEAREST, +GL_LINEAR, GL_NEAREST_MIPMAP_NEAREST,  +GL_NEAREST_MIPMAP_LINEAR,   GL_LINEAR_MIPMAP_NEAREST or +GL_LINEAR_MIPMAP_LINEAR.
+
+GL_NEAREST samples the texel nearest the texture coordinate in the +level 0 texture image.
+
+GL_LINEAR samples the four texels around the texture coordinate in the +level 0 texture image.  The four texels are linearly weighted to +compute the final texel value.
+
+GL_NEAREST_MIPMAP_NEAREST samples the texel nearest the texture +coordinate in the level N texture image.  N is the level of detail +and is computed by the partial derivatives of the texture coordinates +with respect to the window coordinates.
+
+GL_NEAREST_MIPMAP_LINEAR samples two texels nearest the texture +coordinates in the level N and N+1 texture images.  The two texels +are linearly weighted to compute the final texel value.  N is the +level of detail and is computed by the partial derivatives of the +texture coordinates with respect to the window coordinates.
+
+GL_LINEAR_MIPMAP_NEAREST samples four texels around the texture +coordinate in the level N texture image.  The four texels are +linearly weighted to compute the final texel value.  N is the level +of detail and is computed by the partial derivatives of the texture +coordinates with respect to the window coordinates.
+
+GL_LINEAR_MIPMAP_LINEAR samples four texels around the texture +coordinate in the level N texture image and four texels around the +texture coordinate in the level N+1 texture image.  The eight +texels are linearly weighted to compute the final texel value.  N +is the level of detail and is computed by the partial derivatives of the +texture coordinates with respect to the window coordinates.
+
+Filter modes other than GL_LINEAR and GL_NEAREST requires that the +texture have a complete set of mipmaps.  If the mipmap is +incomplete, it is as if texturing is disabled.
+ 
+

5.3.2 Texture Magnification

+The texture magnification filter is set with the glTexParameteri command +by setting target to +GL_TEXTURE_2D, setting pname to +GL_TEXTURE_MAG_FILTER and setting value +to GL_NEAREST or GL_LINEAR.
+
+GL_NEAREST samples the texel nearest the texture coordinate in the +level 0 texture image.
+
+GL_LINEAR samples the four texels around the texture coordinate in the +level 0 texture image.  The four texels are linearly weighted to +compute the final texel value.
+
+

5.4 Texture Application

+The sampled texture value is combined with the incoming fragment color +to produce a new fragment color.  The fragment and texture colors +are combined according to the texture environment mode and the current +texture's base internal format.  The texture environment mode is +set with the command
+
+
void +glTexEnvi(GLenum target, +GLenum pname, GLint value)
+
+
+target must be GL_TEXTURE_ENV. + If pname is +GL_TEXTURE_ENV_MODE then value +must be one of GL_REPLACE, GL_MODULATE, GL_DECAL, or GL_BLEND.
+
+There is also a texture environment +color that can factor into texture application.  The texture +environment color can be set with the command
+
+
void +glTexEnvfv(GLenum target, +GLenum pname, const GLfloat *value)
+
+
+target must be GL_TEXTURE_ENV. + If pname is +GL_TEXTURE_ENV_COLOR then value must +point to an array of four values which specify the red, green, blue, +and alpha values of the texture environment color.  The values are +clamped to the range [0, 1].  The default color is (0, 0, 0, 0).
+
+The following table describes the arithmetic used for each combination +of environment mode and base internal format.  (Rf, Gf, Bf, Af) is +the incoming fragment color.  (Rt, Gt, Bt, At) is the sampled +texture color.  Lt is the sampled texture luminance.  'It' is the sampled texture +intensity.  (Rc, Gc, Bc, Ac) is the texture environment color. + (Rv, Gv, Bv, Av) is the resulting value.
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Base Internal Format
+ 		GL_REPLACE
+ 		GL_MODULATE
+ 		GL_DECAL
+ 		GL_BLEND
+
GL_INTENSITY
+ 		Rv = It
+Gv = It
+Bv = It
+Bf = It
+ 		Rv = Rf * It
+Gv = Gf * It
+Bv = Bf * It
+Av = Af * It		undefined
+ 		Rv = Rf*(1-It) + Rc*It
+Gv = Gf*(1-It) + Gc*It
+Bv = Bf*(1-It) + Bc*It
+Av = Af*(1-It) + Ac*It
GL_RGB
+ 		Rv = Rt
+Gv = Gt
+Bv = Bt
+Av = Af
+ 		Rv = Rf * Rt
+Gv = Gf * Gt
+Bv = Bf * Bt
+Av = Af
+ 		Rv = Rt
+Gv = Gt
+Bv = Bt
+Av = Af		Rv = Rf*(1-Rt) + Rc*Rt
+Gv = Gf*(1-Gt) + Gc*Gt
+Bv = Bf*(1-Bt) + Bc*Bt
+Av = Af
GL_RGBA
+ 		Rv = Rt
+Gv = Gt
+Bv = Bt
+Av = At
+ 		Rv = Rf * Rt
+Gv = Gf * Gt
+Bv = Bf * Bt
+Av = Af * At		Rv = Rf*(1-At) + Rt*At
+Gv = Gf*(1-At) + Gt*At
+Bv = Bf*(1-At) + Bt*At
+Av = Af
+ 		Rv = Rf*(1-Rt) + Rc*Rt
+Gv = Gf*(1-Gt) + Gc*Gt
+Bv = Bf*(1-Bt) + Bc*Bt
+Av = Af*At
+
+
+
+

5.5 Texture Objects

+Texture objects encapsulate a set of texture images (mipmap) and +related state into a named object.  This facilitates use of +multiple textures in an application.  Texture objects are named +with GLuints (unsigned integers).  There is a default texture +object with the name/identifier zero which can never be deleted.
+
+

5.5.1 Creating Texture Objects

+A texture object is created by binding a new GLuint identifier to the +GL_TEXTURE_2D target with the command:
+
+
void glBindTexture(GLenum target, GLuint textureID)
+
+
+target must be GL_TEXTURE_2D. + textureID may be any +unsigned integer.  If textureID +does not name an existing texture object, a new texture object with that +ID will be created, initialized to the default state.  Whether the +ID is new or existed previously, that named texture object is bound as +the current texture object. + Subsequent glTexParameter andglTexImage2D calls will effect the +current texture object.
+
+

5.5.2 Deleting Texture Objects

+One or more texture objects may be deleted with the command:
+
+
void glDeleteTextures(GLsizein, const GLuint *textureIDs)
+
+
+textureIDs is an array of n texture IDs.  The named +texture objects will be deleted.  If the current texture object is +deleted the default texture object (number 0) will be bound as the +current texture object.
+
+

5.5.3 Allocating Texture Object Identifiers

+A list of new, unused texture IDs can be obtained by calling the command
+
+
void glGenTextures(GLsizei n, GLuint *textureIDs)
+
+
+An array of n unused texture +IDs will be returned in the textureIDs +array.
+
+
+

6. Per-fragment Operations

+The fragments produced by rasterization are subjected to a number of +operations which either modify the fragment or test the fragment +(discarding the fragment if the test fails.)  This chapter +describes the per-fragment operations.  They are presented in the +order in which they're performed.  If a fragment fails a test it is +discarded and not subjected to subsequent tests or modifications.
+
+

6.1 Scissor Test

+The scissor test limits rendering to a 2-D rectangular region of the +framebuffer.  The command
+
+
void glScissor(GLintx, GLint y, GLsizei width, GLsizei height)
+
+
+defines a clipping region with the lower-left corner at (x, y) and the given width and height.  The scissor test is +enabled and disabled with the command glEnable(GL_SCISSOR_TEST) +and glDisable(GL_SCISSOR_TEST).
+
+If the incoming fragment's position is (xf, yf) +then the fragment will pass the test if x <= xf < x + width and y <= yf < y + height.  Otherwise, the +fragment is discarded.
+
+If width or height is less than zero the error +GL_INVALID_VALUE is raised.  The default scissor rectangle bounds +are (0, 0, w, h) where w is the initial window width and h is the +initial window height.  The scissor test is disabled by default.
+
+

6.2 Alpha Test

+The alpha test compares the fragment's alpha value against a reference +value and discards the fragment if the comparison fails.  The test +is specified by the command
+
+
void glAlphaFunc(GLenummode, GLclampf reference)
+
+
+mode specifies an inequality +and reference specifies a value +to compare against.  The following table lists all possible +modes and the +corresponding test:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Comparison mode
+ 		The test passes if
+
GL_LESS
+ 		alpha < reference
+
GL_LEQUAL
+ 		alpha <= reference
GL_GREATER
+ 		alpha > reference
GL_GEQUAL
+ 		alpha >= reference
GL_EQUAL
+ 		alpha == reference
GL_NOTEQUAL
+ 		alpha != reference
GL_NEVER
+ 		never pass
+
GL_ALWAYS
+ 		always passes
+
+
+The reference parameter is +clamped to the range [0, 1].
+
+The alpha test is enabled and disabled with the commands glEnable(GL_ALPHA_TEST) and glDisable(GL_ALPHA_TEST).
+
+The default mode is GL_ALWAYS and the default reference value is 0.
+
+

6.3 Stencil Test

+The stencil buffer stores an N-bit integer value for each pixel in the +frame buffer.  The stencil test compares the stencil buffer value +at the fragment's position to a reference value and possibly discards +the fragment based on the outcome.  Furthermore, the stencil buffer +value may be updated or modified depending on the outcome.  If +there is no stencil buffer the stencil test is bypassed.
+
+Stenciling is controlled by the commands
+
+
void glStencilFunc(GLenumfunc, GLint ref, GLuint mask)
+void glStencilOp(GLenum stencilFail, GLenum depthTestFail, GLenum depthTestPass)
+
+
+The glStencilFunc command controls the +stencil test while glStencilOp +command controls the how the stencil buffer is updated/modified after +the test.
+
+ref is clamped to the range [0, +2N-1] where N is the number of bits per stencil value in the +stencil buffer.
+
+The following table lists all possible values for the func parameter and when the stencil +test will pass.  Both the stencil buffer value and the stencil +reference value are bit-wise ANDed with the mask parameter before the test.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Stencil func value
+ 		Stencil test passes if
+
GL_LESS
+ 		(ref&mask) < (stencil buffer value +& mask)
+
GL_LEQUAL
+ 		(ref +& mask) <= (stencil +buffer value & mask)
GL_GREATER
+ 		(ref +& mask) > (stencil +buffer value & mask)
GL_GEQUAL
+ 		(ref +& mask) >= (stencil +buffer value & mask)
GL_EQUAL
+ 		(ref +& mask) == (stencil +buffer value & mask)
GL_NOTEQUAL
+ 		(ref +& mask) != (stencil +buffer value & mask)
GL_NEVER
+ 		never passes
+
GL_ALWAYS
+ 		always passes
+
+
+
+If the stencil test passes, the fragment is passed to the next +per-fragment operation.  Otherwise, if the stencil test fails, the +value in the stencil buffer is updated according to the value of the stencilFail parameter to glStencilOp.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
stencilFail +value
+ 		New stencil buffer value
+
GL_KEEP
+ 		originalValue
+
GL_ZERO
+ 		0
+
GL_INVERT
+ 		BitWiseInvert(originalValue) +i.e. ~originalValue
+
GL_REPLACE
+ 		ref
+
GL_INCR
+ 		originalValue + 1, clamped to +[0, 2N-1]
GL_DECR
+ 		originalValue - 1, clamped to +[0, 2N-1]
+
+
+The depthTestFail and depthTestPass parameters to glStencilOp are ignored.  Values +for func and stencilFail other than those listed +in the table will cause the error GL_INVALID_ENUM to be raised.
+
+The stencil test is enabled and disabled with the commands glEnable(GL_STENCIL_TEST) and glDisable(GL_STENCIL_TEST).
+
+The default stencil function is GL_ALWAYS.  The default stencil +reference value is 0.  The default stencil mask is ~0.  The +default stencil fail operation is GL_KEEP.
+
+Values written into the stencil buffer are masked with the command
+
+
void glStencilMask(GLuintmask)
+
+
+Only the bits which are set in mask +will be modified in the stencil buffer when written to.  If each +stencil buffer value has N bits, only the least significant N bits of mask are relevant.  The default +stencil mask is ~0.
+
+

6.4 Blending and Logicop

+Blending or a logic operation combines the incoming fragment color with +the destination frame buffer color according to a blending equation or +bit-wise Boolean logical operation.
+
+Blending is enabled and disabled with the commands glEnable(GL_BLEND) and glDisable(GL_BLEND).
+
+The logic operation is enabled and disabled with the commands glEnable(GL_LOGIC_OP) and glDisable(GL_LOGIC_OP).
+
+If both blending and the logic operation are enabled, the logic +operation has higher priority; blending is bypassed.
+
+

6.4.1 Logic Op

+The command
+
+
void glLogicop(GLenummode)
+
+
+Specifies the Boolean logic operation for combining the incoming +fragment color with the destination frame buffer color.  Both the +incoming fragment color and destination frame buffer colors are +interpreted as four-tuples of unsigned integer color components in the +range [0, 2N-1] where N is the number of bits per color +channel.  N may not be the same for all color channels.
+
+The following table lists all values for mode and the boolean arithmetic used +to combine the incoming fragment color value (src) with the destination framebuffer +color value (dst).  Standard ANSI C operators used.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LogicOp mode
+ 		Resulting channel value
+
GL_CLEAR
+ 		0
+
GL_SET
+ 		~0
+
GL_COPY
+ 		src
+
GL_COPY_INVERTED
+ 		~s
+
GL_NOOP
+ 		dst
+
GL_INVERT
+ 		~dst
+
GL_AND
+ 		src & dst
+
GL_NAND
+ 		~(src & dst)
+
GL_AND_REVERSE
+ 		src & ~dst
+
GL_AND_INVERTED
+ 		~src & dst
+
GL_OR
+ 		src | dst
+
GL_NOR
+ 		~(src | dst)
+
GL_OR_REVERSE
+ 		src | ~dst
+
GL_OR_INVERTED
+ 		~src | dst
+
GL_XOR
+ 		src ^ dst
+
GL_EQUIV
+ 		~(src ^ dst)
+
+
+The fragment's color is replaced by the result of the logic operation.
+
+Specifying any value for mode +other than those listed in the above table will cause the error +GL_INVALID_ENUM to be raised.
+
+The default value for mode is +GL_COPY.  The logic operation is disabled by default.
+
+

6.4.2 Blending

+The command
+
+
void glBlendFunc(GLenumsrcTerm, GLenum dstTerm)
+
+
+specifies the terms of the blending equation.  If Cf = (Rf, Gf, +Bf, Af) is the incoming fragment color and Cb = (Rb, Gb, Bb, Ab) is the +frame buffer color, then the resulting color Cv = (Rv, Gv, Bv, Av) is +computed by:
+
+
Cv = Cf * srcTerm + Cb * dstTerm
+
+
+All possible values for srcTerm +and the corresponding arithmetic term are listed in the following table:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
srcTerm
+ 		srcTermArithmetic
+
GL_ZERO
+ 		(0, 0, 0, 0)
+
GL_ONE
+ 		(1, 1, 1, 1)
+
GL_DST_COLOR
+ 		(Rb, Gb, Bb, Ab)
+
GL_ONE_MINUS_DST_COLOR
+ 		(1-Rb, 1-Gb, 1-Bb, 1-Ab)
+
GL_SRC_ALPHA
+ 		(Af, Af, Af, AF)
+
GL_ONE_MINUS_SRC_ALPHA
+ 		(1-Af, 1-Af, 1-Af, 1-Af)
+
GL_DST_ALPHA
+ 		(Ab, Ab, Ab, Ab)
+
GL_ONE_MINUS_DST_ALPHA
+ 		(1-Ab, 1-Ab, 1-Ab, 1-Ab)
+
GL_SRC_ALPHA_SATURATE
+ 		(m, m, m, 1) where m = MIN(Af, +1-Ab)
+
+
+All possible values for srcTerm +and the corresponding arithmetic term are listed in the following table:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
dstTerm
+ 		dstTermArithmetic
+
GL_ZERO
+ 		(0, 0, 0, 0)
+
GL_ONE
+ 		(1, 1, 1, 1)
+
GL_SRC_COLOR
+ 		(Rf, Gf, Bf, Af)
+
GL_ONE_MINUS_SRC_COLOR
+ 		(1-Rf, 1-Gf, 1-Bf, 1-Af)
+
GL_SRC_ALPHA
+ 		(Af, Af, Af, AF)
+
GL_ONE_MINUS_SRC_ALPHA
+ 		(1-Af, 1-Af, 1-Af, 1-Af)
+
GL_DST_ALPHA
+ 		(Ab, Ab, Ab, Ab)
+
GL_ONE_MINUS_DST_ALPHA
+ 		(1-Ab, 1-Ab, 1-Ab, 1-Ab)
+
+
+The fragment's color is replaced by the result of the blending equation.
+
+Values for srcTerm and dstTerm other than those listed in +the table will cause the error GL_INVALID_ENUM to be raised.
+
+The default value for srcTerm +is GL_ONE.  The default value for dstTerm +is GL_ZERO.  Blending is disabled by default.
+
+

6.5 Color Mask

+The final fragment color is written into the current color buffer at +the end of the per-fragment operations.  Normally, all color +channels in the frame buffer are replaced with the final fragment color. + However, the command
+
+
void glColorMask(GLbooleanredMask, GLboolean greenMask, GLboolean blueMask, GLboolean alphaMask)
+
+
+allows selective writing to individual color channels.  If redMask is GL_TRUE then writing to +the red color channel is enabled, otherwise it's disabled. + Similarly, the green, blue and alpha channels can also be masked.
+
+Initially all four mask values are GL_TRUE.
+
+Color masking is not enabled/disabled with the glEnable/glDisable commands.
+
+

7. Frame Buffer Operations

+The frame buffer is considered to be a two-dimensional array of pixels. + The frame buffer is also organized into layers or logical buffers. + There may be a front color buffer, back color buffer and stencil +buffer.  A double-buffered frame buffer has both a front color +buffer and back color buffer.  A single-buffered framebuffer only +has a front color buffer.  Each pixel in a color buffer has a red, +green and blue value and an optional alpha value.
+
+

7.1 Clearing Buffers

+Buffers are cleared (set to uniform values) with the command
+
+
void glClear(GLbitfieldbuffers)
+
+
+buffers is a bitmask for which +the value may be the bitwise-OR of the values GL_COLOR_BUFFER_BIT and +GL_STENCIL_BUFFER_BIT.  If the GL_COLOR_BUFFER_BIT bit is +specified, the current color buffer will be cleared.  If the +GL_STENCIL_BUFFER_BIT bit is specified, the stencil buffer will be +cleared.
+
+The current color buffer is specified with the command
+
+
void glDrawBuffer(GLenum buffer)
+
+
+buffer may be either GL_FRONT, +GL_BACK or GL_NONE.  GL_FRONT indicates that the front color buffer +will be modified by glClear and +any drawing command.  GL_BACK indicates that the back color buffer +will be modified by glClear and +any drawing command.  GL_NONE indicates that neither color buffer +will be modified by glClear or +any drawing command.  GL_BACK is only valid for double-buffered +frame buffers.
+
+The current scissor rectangle, set by the glScissor command, effects glClear, limiting +the clear to the scissor rectangle, if it's enabled.  Furthermore, only the color channels enabled by glColorMask will be effected by glClear(GL_COLOR_BUFFER_BIT). + Likewise, only the stencil bits enabled by glStencilMask will be effected by glClear(GL_STENCIL_BUFFER_BIT).
+
+The current clear color is set with the command
+
+
void glClearColor(GLclampfred, GLclampf green, GLclampf blue, GLclampf alpha)
+
+
+Subsequent calls to glClear +will use the color (red, green, blue, +alpha) to clear the front or back color buffers.
+
+The current stencil clear value is set with the command
+
+
void glClearStencil(GLintclearValue)
+
+
+If the stencil buffer is N bits deep, the least significant N bits of clearValue will be used to clear the +stencil buffer.
+
+
+

8. Other Features

+

8.1 Frame Buffer Readback

+A rectangular region of pixels can be read from the frame buffer and +placed in client memory with the command
+
+
void glReadPixels(GLintx, GLint y, GLsizei width, GLsizei height, GLenum format, GLenum type, GLvoid *data)
+
+
+x and y specify the coordinate of the +lower-left corner of the region to read and width and height specify the size of the +rectangular region to read.  format +specifies the format of image data and must be either GL_RGB or +GL_RGBA.  type specify the +data type of the image data and must be either GL_UNSIGNED_BYTE or +GL_FLOAT.  Other values for format +or type will cause the error +GL_INVALID_ENUM to be raised.
+
+The framebuffer may contain 3-component colors (red, green, blue) or +4-component colors (red, green, blue, alpha).  If an alpha channel +is not present, alpha values default to 1.0.
+
+The frame buffer color components (red, green, blue, alpha) are either +converted to 8-bit unsigned integers in the range[0, 255] if type is GL_UNSIGNED_BYTE or +converted to floating point values in the range [0, 1] if type is GL_FLOAT.  The (red, +green, blue, alpha) tuples are then stored as GL_RGB triplets (by +dropping the alpha component) or GL_RGBA quadruples in client memory.
+
+Image data is packed into +client memory according to the pixel packing parameters which are set by +the command
+
+
void glPixelStorei(GLenum pname, GLint value)
+
+
+pname must be +GL_PACK_ROW_LENGTH.  value +indicates the stride (in pixels) between subsequent rows in the +destination image.  If GL_PACK_ROW_LENGTH is zero (the default) +then the width parameter to glReadPixels indicates the row stride.
+
+Pixel readback takes place as follows:
+
+
if (GL_PACK_ROW_LENGTH == 0)
+    rowLength = width;
+else
+    rowLength = GL_PACK_ROW_LENGTH
+
+if (format == GL_RGB) {
+    for (i = 0; i < height; +i++) {
+        for (j = 0; j < width; j++) {
+            k = (i * +rowLength + j) * 3;
+            data[k+0] = FrameBuffer(x + j, y + i).red;
+            data[k+1] = FrameBuffer(x + j, y + i).green;
+            data[k+2] = FrameBuffer(x + j, y + i).blue;
+        }
+    }
+}
+else {
+    for (i = 0; i < height; +i++) {
+        for (j = 0; j < width; j++) {
+            k = (i * +rowLength + j) * 4;
+            data[k+0] = FrameBuffer(x + j, y + i).red;
+            data[k+1] = FrameBuffer(x + j, y + i).green;
+            data[k+2] = FrameBuffer(x + j, y + i).blue;
+            data[k+3] = FrameBuffer(x + j, y + i).alpha;
+        }
+    }
+}
+
+
+The function FrameBuffer(c, r) +returns the pixel in the frame buffer at column c of row r.  data is considered to be either a +GLubyte pointer or a GLfloat pointer, depending on the type parameter.  Similarly, the +FrameBuffer function returns either GLubyte values in the range [0, 255] +or GLfloat values in the range [0,1], depending on the type parameter.
+
+Pixels may be read from either the front or back color buffer. + The command
+
+
void glReadBuffer(GLenumbuffer)
+
+
+specifies the source for reading images with glReadPixels.  If buffer is GL_FRONT then front color +buffer is the source.  If buffer +is GL_BACK then the back color buffer is the source.  It is illegal +to specify GL_BACK when the color buffer is not double buffered. + Any invalid value for buffer +will raise the error GL_INVALID_ENUM.
+
+The default read source is GL_BACK if the frame buffer is double +buffered.  Otherwise, the default read source is GL_FRONT.
+
+

8.2 Selection Mode

+Selection mode is typically used to implement picking: determining which +primitive(s) are present at particular window positions.  The +command
+
+
GLint glRenderMode(GLenummode)
+
+
+is used to enable selection mode.  If mode is GL_SELECTION the graphics +library is put into selection mode.  If mode is GL_RENDER the graphic +library is put into normal rendering mode.  Any other value for mode will raise the error +GL_INVALID_ENUM.
+
+When in selection mode rendering commands will not effect the +framebuffer.  Instead, a record of the primitives that would have +been drawn is placed in the selection buffer.  The selection buffer +is specified with the command
+
+
void glSelectionBuffer(GLsizein, GLuint *buffer)
+
+
+buffer is an array of n +unsigned integers.  No more than n +values will be placed in the buffer.
+
+The name stack is a stack +(LIFO) of unsigned integer names.  The following commands +manipulate the name stack:
+
+
void glInitNames(void)
+void glPushName(GLuint name)
+void glPopName(void)
+void glLoadName(GLuint name)
+
+
+glInitNames resets the name +stack to an empty state.  glPushName pushes the given name value onto the stack.  glPopName pops the top name from the +stack.  glLoadName replaces the top value on +the stack with the specified name. + Stack underflow and overflow conditions cause the errors +GL_STACK_OVERFLOW and GL_STACK_UNDERFLOW to be raised.
+
+While in selection mode, primitives (points, lines, polygons) are +transformed and clip-tested normally.  Primitives which aren't +discarded by clipping cause the hit data to be updated.  The hit +data consists of three pieces of information: a hit flag, a minimum Z +value and a maximum Z value.  First, the hit flag is set. + Then, for each of the primitive's vertices, the vertex Z value is +compared to the minimum and maximum Z values.  The minimum Z value +is updated if the vertex's Z value is less than the minimum Z value. + The maximum Z value is updated if the vertex's Z value is greater +than the maximum Z value.
+
+When any of glInitNames, glPushName, glPopName, glLoadName or glRenderMode are called and the hit +flag is set, a hit record is +written to the selection buffer.
+
+A hit record consists of a sequence of unsigned integers.  The +first value is the size of the name stack.  The second value is the +minimum Z value multiplied by 232-1.  The third value is +the maximum Z value multiplied by 232-1.  The remaining +values are the values in the name stack, in bottom to top order. + The hit flag is cleared after a hit record is written to the +selection buffer.  Hit records are places sequentially into the +selection buffer until it is full or selection mode is terminated.
+
+Selection mode is terminated by calling glRenderMode(GL_RENDER).   The +return value of glRenderMode +will be -1 if the selection buffer overflowed.  Otherwise, the +return value will indicate the number of values written into the +selection buffer.
+
+

8.3 Synchronization

+The command
+
+
void glFlush(void)
+
+
+makes the graphics library to flush all pending graphics commands. + The command
+

+void glFinish(void)
+
+
+makes the graphics library flush the command queue and wait until those +commands are completed.  glFlush +will not return until all previous graphics commands have been fully +completed.
+
+These commands are typically used to force completion of rendering to +the front color buffer.  Otherwise, rendering to the front color +buffer may not appear.  The swapbuffers +command (part of the window system binding library) does an implicit +flush before swapping the front and back color buffers.  The glReadPixels command also does an +implicit flush before reading pixel data from the frame buffer.
+
+

9. State Queries

+The current value of nearly all library state variables can be queried. + This chapter describes the commands used for querying the value of +state variables.
+
+

9.1 General State Queries

+The command
+
+
void glGetFloatv(GLenumpname, GLfloat *values)
+
+
+returns the value(s) of the state variable specified by pname.  The following table +lists all accepted values for pname +and a description of the value(s).  Specifying any other value for pname causes the error +GL_INVALID_ENUM to be raised.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Variable (pname)
+ 		Number of values
+ 		Value(s) Description
+
GL_ALPHA_BITS
+ 		1
+ 		Number of bits per alpha value +in the frame buffer.
+
GL_ALPHA_TEST
+ 		1
+ 		Zero if the alpha test is +disabled.
+One if the alpha test is enabled.
+
GL_ALPHA_TEST_FUNC
+ 		1
+ 		The alpha test function.
+
GL_BLEND
+ 		1
+ 		Zero if blending is disabled.
+One if blending is enabled.
+
GL_BLEND_DST
+ 		1
+ 		Blend destination function/term.
+
GL_BLEND_SRC
+ 		1
+ 		Blend source function/term.
+
GL_BLUE_BITS
+ 		1
+ 		Number of bits per blue value in +the frame buffer.
+
GL_COLOR_CLEAR_VALUE
+ 		4
+ 		Clear color (red, green, blue, +alpha).
+
GL_COLOR_WRITE_MASK
+ 		4
+ 		Color buffer writemask (red, +green, blue, alpha).
+Zero if writing is disabled.
+One if writing is enabled.
+
GL_CULL_FACE
+ 		1
+ 		Zero if polygon culling is +disabled.
+One if polygon culling is enabled.
+
GL_CULL_FACE_MODE
+ 		1
+ 		Polygon cull mode: GL_FRONT, +GL_BACK or GL_FRONT_AND_BACK.
+
GL_CURRENT_COLOR
+ 		4
+ 		Current color (red, green, blue, +alpha).
+
GL_CURRENT_RASTER_COLOR
+ 		4
+ 		Current raster position color +(red, green, blue, alpha).
+
GL_CURRENT_RASTER_TEXTURE_COORDS
+ 		4
+ 		Current raster position texture +coordinates (s, t, r, q).
+
GL_CURRENT_RASTER_POSITION
+ 		4
+ 		Current raster position (x, y, +z, w).
+
GL_CURRENT_POSITION_VALID
+ 		1
+ 		Zero if current raster position +is invalid.
+One if current raster position is valid.
+
GL_CURRENT_TEXTURE_COORDS
+ 		4
+ 		Current texture coordinates (s, +t, r, q)
+
GL_DOUBLEBUFFER
+ 		1
+ 		Zero if color buffer is +single-buffered.
+One if color buffer is double-buffered.
+
GL_DRAW_BUFFER
+ 		1
+ 		Current color draw buffer: +GL_FRONT or GL_BACK.
+
GL_FRONT_FACE1
+ 		Polygon front-face winding: +GL_CW or GL_CCW.
+
GL_GREEN_BITS
+ 		1
+ 		Number of bits per green value +in the frame buffer.
+
GL_LINE_SMOOTH
+ 		1
+ 		Zero if line smoothing is +disabled.
+One if line smoothing is enabled.
+
GL_LINE_STIPPLE
+ 		1
+ 		Zero if line stippling is +disabled.
+One if line stippling is enabled.
+
GL_LINE_STIPPLE_PATTERN
+ 		1
+ 		Line stipple pattern.
+
GL_LINE_STIPPLE_REPEAT
+ 		1
+ 		Line stipple repeat factor.
+
GL_LINE_WIDTH
+ 		1
+ 		Line width in pixels.
+
GL_LINE_WIDTH_GRANULARITY
+ 		1
+ 		Aliased line width granularity.
+
GL_LINE_WIDTH_RANGE
+ 		2
+ 		Minimum and maximum aliased line +widths.
+
GL_ALIASED_LINE_WIDTH_RANGE
+ 		2
+ 		Minimum and maximum antialiased +line widths.
GL_COLOR_LOGIC_OP
+ 		1
+ 		Zero if logicop is disabled.
+One if logicop is enabled.
+
GL_LOGIC_OP_MODE
+ 		1
+ 		Logicop function.
+
GL_MATRIX_MODE
+ 		1
+ 		Matrix mode: GL_MODELVIEW or +GL_PROJECTION.
+
GL_MAX_MODELVIEW_STACK_DEPTH
+ 		1
+ 		Maximum size of the modelview +matrix stack.
+
GL_MAX_NAME_STACK_DEPTH
+ 		1
+ 		Maximum size of the selection +name stack.
+
GL_MAX_PROJECTION_STACK_DEPTH
+ 		1
+ 		Maximum size of the projection +matrix stack.
+
GL_MAX_TEXTURE_SIZE
+ 		1
+ 		Maximum 2D texture image width +and height.
+
GL_MAX_VIEWPORT_DIMS
+ 		2Maximum viewport width and +height in pixels.
+
GL_MODELVIEW_MATRIX
+ 		16
+ 		Current/top modelview matrix +values.
+
GL_MODELVIEW_MATRIX_STACK_DEPTH
+ 		1
+ 		Current size of the modelview +matrix stack.
+
GL_NAME_STACK_DEPTH
+ 		1
+ 		Current size of the selection +name stack.
+
GL_PACK_ROW_LENGTH
+ 		1
+ 		Pixel packing row length.
+
GL_POLYGON_SMOOTH
+ 		1
+ 		Zero if polygon smoothing is +disabled.
+One if polygon smoothing is enabled.
+
GL_PROJECTION_MATRIX
+ 		16
+ 		Current/top projection matrix +values.
+
GL_PROJECTION_STACK_DEPTH
+ 		1
+ 		Current size of projection +matrix stack.
+
GL_READ_BUFFER
+ 		1
+ 		Current read buffer: GL_FRONT or +GL_BACK.
+
GL_RED_BITS
+ 		1
+ 		Number of bits per red value in +the frame buffer.
+
GL_RENDER_MODE
+ 		1
+ 		Current rendering mode: +GL_RENDER or GL_SELECTION.
+
GL_RGBA_MODE
+ 		1
+ 		Always one.
+
GL_SCISSOR_BOX
+ 		4
+ 		Scissor box (x, y, width, +height).
+
GL_SCISSOR_TEST
+ 		1
+ 		Zero if scissor test is disabled.
+One if scissor test is enabled.
+
GL_SELECTION_BUFFER_SIZE
+ 		1
+ 		Size of selection buffer.
+
GL_SHADE_MODEL
+ 		1
+ 		Shade model: GL_FLAT or +GL_SMOOTH.
+
GL_STENCIL_BITS
+ 		1
+ 		Number of bits per stencil value +in the frame buffer.
+
GL_STENCIL_CLEAR_VALUE
+ 		1
+ 		Stencil buffer clear value.
+
GL_STENCIL_FAIL
+ 		1
+ 		Stencil fail operation.
+
GL_STENCIL_FUNC
+ 		1
+ 		Stencil function.
+
GL_STENCIL_REF
+ 		1
+ 		Stencil reference value.
+
GL_STENCIL_TEST
+ 		1
+ 		Zero if stencil test is disabled.
+One if stencil test is enabled.
+
GL_STENCIL_VALUE_MASK
+ 		1
+ 		Stencil mask value.
+
GL_STENCIL_WRITE_MASK
+ 		1
+ 		Stencil buffer write mask.
+
GL_TEXTURE_2D
+ 		1
+ 		Zero if 2D texture mapping is +disabled.
+One if 2D texture mapping is enabled.
+
GL_TEXTURE_BINDING_2D1
+ 		Name of currently bound 2D +texture object.
+
GL_TEXTURE_ENV_COLOR
+ 		4
+ 		Texture environment color (red, +green, blue, alpha).
+
GL_TEXTURE_ENV_MODE
+ 		1
+ 		Texture environment mode.
+
GL_UNPACK_ROW_LENGTH
+ 		1
+ 		Pixel unpacking row length.
+
GL_UNPACK_LSB_FIRST
+ 		1
+ 		Zero if most significant bit is +unpacked first for bitmaps.
+One if least significant bit is unpacked first for bitmaps.
+
GL_VIEWPORT
+ 		4
+ 		Current viewport (x, y, width, +height).
+
+
+
+

9.2 String Queries

+The command
+
+
const GLubyte *glGetString(GLenum name)
+
+
+is used to query string-valued values.  The legal values for name are described in the following +table:
+
+ + + + + + + + + + + + + + + + + + + + + + + +
name
+ 		Return value
+
GL_VERSION
+ 		The library version, such as +"1.2".
+
GL_RENDERER
+ 		The renderer, such as "Mesa DRI +Radeon".
+
GL_VENDOR
+ 		The vendor of this +implementation, such as "Tungsten Graphics, Inc."
+
GL_EXTENSIONS
+ 		A white-space separated list of +the supported extensions.
+
+

9.3 Error Queries

+The command
+
+
GLenum glGetError(void)
+
+
+returns the current error code.  The current error code will be +set by a GL command when an error condition has been detected.  If +the current error code is already set, subsequent errors will not be +recorded.  The error code is reset/cleared to GL_NO_ERROR when glGetError returns.  The +following error codes are possible:
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Error code
+ 		Meaning
+
GL_NO_ERROR
+ 		No error has been recorded.
+
GL_INVALID_ENUM
+ 		An enum parameter had an invalid +value.
+
GL_INVALID_VALUE
+ 		A numeric parameter had an +invalid value.
+
GL_INVALID_OPERATION
+ 		A function was called when not +legal to do so.
+
GL_STACK_OVERFLOW
+ 		The current transformation +matrix stack is full.
+
GL_STACK_UNDERFLOW
+ 		The current transformation +matrix stack is empty.
+
GL_OUT_OF_MEMORY
+ 		The system ran out of dynamic +memory.
+
+
+
+

10. Unsupported Features

+This section lists other features and functions which are not supported +and not previously discussed.
+
+

10.1 Feedback Mode

+Feedback mode and the following related functions are not supported.
+
+
glFeedbackBuffer
+glPassThrough
+
+
+

10.2 1D and 3D Textures
+

+Only 2D texture images are supported.  The following functions +used to specify 1D and 3D texture images are not supported:
+
+
glTexImage1D
+glTexImage3D
+glTexSubImage1D
+ glTexSubImage3D
+glCopyTexImage1D
+ glCopyTexSubImage1D
+ glCopyTexSubImage3D
+
+
+

10.3 Alternate Texture Image Commands
+

+Texture images may only be specified with glTexImage2D.  The following +alternate texture image commands are not supported:
+
+
glTexSubImage2D
+glCopyTexImage2D
+glCopyTexSubImage2D
+
+
+

10.4 Proxy Textures

+Proxy textures are not supported and the GL_PROXY_TEXTURE_2D token is +not supported by any function.
+
+
+

10.5 Other Texture Commands

+The following commands related to texture mapping are not supported by +the subset:
+
+
glPrioritizeTextures
+glAreTexturesResident
+glIsTexture
+glTexEnviv
+glTexEnvf
+glTexParameterf
+glTexParameteriv
+glTexParameterfv
+
+
+
+

10.6 Copy and Draw Pixels
+

+The following commands are not supported:
+
+
glDrawPixels
+glCopyPixels
+glPixelZoom
+
+
+

10.7 Color Index Mode
+

+Color index mode and the following related commands are not supported:
+
+ +
glIndexub
+glIndexi
+glIndexs
+glIndexf
+glIndexd
+glIndexubv
+glIndexiv
+glIndexsv
+glIndexfv
+glIndexdv
+glIndexMask
+glClearIndex
+glIndexPointer
+
+
+

10.8 Pixel Transfer Operations

+The pixel transfer operations (scale, bias, look-up table, etc) are not +supported and the following commands are omitted:
+
+
glPixelTransferf
+glPixelTransferi
+glPixelMapfv
+glPixelMapuiv
+glPixelMapusv
+glGetPixelMapfv
+glGetPixelMapuiv
+glGetPixelMapusv
+
+
+

10.9 Hints

+Hints and the following related command is not supported:
+
+
glHint
+
+
+

10.10 State Query Commands
+

+The following state query commands are not supported:
+
+
glGetBooleanv
+glGetIntegerv
+glGetDoublev
+glGetPointerv
+glGetTexEnvi
+glGetTexEnvf
+glGetTexParameteriv
+glGetTexParameterfv
+glGetTexLevelParameteriv
+glGetTexLevelParameterfv
+glGetTexImage
+glGetClipPlane
+
+
+

10.11 Attribute Stacks

+State attribute stacks and the following related commands are not +supported:
+
+
glPushAttrib
+glPopAtttrib
+
+
+

10.12 Double-Valued Functions

+All functions which take double-precision floating point values, but +for which there is an equivalent single-precision valued function, are +omitted.  This includes, but is not limited to:
+
+
glVertex2d
+glVertex2dv
+glVertex3d
+ glVertex3dv
+glVertex4d
+ glVertex4dv
+glColor3d
+glColor3dv
+glColor4d
+ glColor4dv
+glTexCoord1d
+glTexCoord1dv
+glTexCoord2d
+ glTexCoord2dv
+glTexCoord3d
+ glTexCoord3dv
+glTexCoord4d
+ glTexCoord4dv
+glRasterPos2d
+ glRasterPos2dv
+glRasterPos3d
+ glRasterPos3dv
+glRasterPos4d
+ glRasterPos4dv
+glLoadMatrixd
+glMultMatrixd
+glScaled
+glRotated
+glTranslated
+glRectd
+glRectdv
+
+
+

10.13 Evaluators

+Evaluators and the following related commands are not supported:
+
+
glMap1f
+glMap2d
+glMap2f
+glGetMapdv
+glGetMapfv
+glGetMapiv
+glEvalCoord1d
+glEvalCoord1f
+glEvalCoord1dv
+glEvalCoord1fv
+glEvalCoord2d
+glEvalCoord2f
+glEvalCoord2dv
+glEvalCoord2fv
+glMapGrid1d
+glMapGrid1f
+glMapGrid2d
+glMapGrid2f
+glEvalPoint1
+glEvalPoint2
+glEvalMesh1
+glEvalMesh2
+
+
+

10.14 Display Lists

+Display lists and the following related commands are not supported:
+
+
glIsList
+glDeleteLists
+glGenLists
+glNewList
+glEndList
+glCallList
+glCallLists
+glListBase
+
+
+

10.15 Accumulation Buffer

+The accumulation buffer and the following related commands are not +supported:
+
+
glAccum
+glClearAccum
+
+
+

10.16 Fog

+Fog and the following related commands are not supported:
+
+
glFogi
+glFogf
+glFogiv
+glFogfv
+
+
+

10.17 Depth Test

+Depth testing and the following related commands are not supported:
+
+
glDepthFunc
+glDepthMask
+glDepthRange
+glClearDepth
+
+
+

10.18 Imaging Subset

+The OpenGL imaging subset (which implements features such as +convolution, histogram, min/max recording, color matrix and color +tables) is not supported.
+
+
+

Appendix A: Issues

+This appendix lists documentation and subset issues with their current +status.  For items which are still open, the documentation (above) +follows the recommended solution.
+
+

A.1 Vertex Arrays

+Should vertex arrays be supported?  Is there a performance +advantage?
+
+RESOLUTION: No, there isn't enough of a performance advantage to +justify them.
+
+

A.2 Polygon Antialiasing and Edge Flags

+Should edge flags be supported for antialiasing?
+
+Edge flags don't effect antialiasing, at least not normally.  A +number of approaches to antialiasing have been summarized in email.
+
+RECOMMENDATION: don't support edge flags.  They don't effect +polygon antialiasing.
+
+RESOLUTION: closed, as of 26 Feb 2003.
+
+

A.3 glRasterPos vs. glWindowPos

+Should glRasterPos and/or glWindowPos commands be supported?
+
+RESOLUTION: Closed: implement glRasterPos commands, but not glWindowPos +commands.
+
+

A.4 GL_IBM_rasterpos_clip extension

+Should the GL_IBM_rasterpos_clip extension be implemented?
+
+RESOLUTION:  No.  It's not required.
+
+

A.5 Image Formats and Types

+Which image formats and types should be supported for glTexImage2D and glReadPixels?
+
+OpenGL specifies a large +variety of image formats and data types.  Only a few are commonly +used.
+
+RECOMMENDATION:  we propose a subset:
+
+For glTexImage2D only allow type=GL_UNSIGNED_BYTE and format=GL_RGBA, GL_RGB, +GL_INTENSITY.   Only allow internalFormat +to be GL_RGBA, GL_RGB or GL_INTENSITY as well.  Basically, only +support image formats/types that are directly supported by the Radeon +hardware.  This will allow glTexImage2D +to basically just use memcpy to +copy texture images.
+
+For glReadPixels, only allow type = GL_UNSIGNED_BYTE or GL_FLOAT. + Only allow format = +GL_RGB or GL_RGBA.  This is just enough to support the OpenGL +conformance tests.
+
+RESOLUTION: open
+
+

A.6 Texture Environment Modes

+Which texture environment modes should be supported?  OpenGL 1.2 +has GL_REPLACE, GL_MODULATE, GL_DECAL and GL_BLEND.  GL_DECAL isn't +defined for all base internal texture formats.  GL_ADD is another +useful mode.  Perhaps drop GL_DECAL mode and add GL_ADD mode.
+
+RECOMMENDATION: implement the standard modes GL_REPLACE, GL_MODULATE, +GL_DECAL and GL_BLEND.
+
+RESOLUTION: open
+
+

A.7 Truncated Mipmaps and LOD Control

+Should we support the GL_TEXTURE_BASE_LEVEL, GL_TEXTURE_MAX_LEVEL, +GL_TEXTURE_MIN_LOD and GL_TEXTURE_MAX_LOD texture parameters?
+
+RECOMMENDATION:  We propose omitting these features at this time, +in the interest of simplifying the driver.
+
+RESOLUTION: open
+
+

A.8 Texture Priorities and Residency

+Should the subset support texture priorities via glPrioritizeTextures and the glAreTexturesResident command?
+
+RECOMMENDATION:  Few applications use these features and +functions.  We propose omitting them to simplify the driver.
+
+RESOLUTION: open
+
+

A.9 Pixel Pack/Unpack Alignment Control

+Should we support the GL_PACK_ALIGNMENT and GL_UNPACK_ALIGNMENT options?
+
+These are used to align pixel data addresses to 1, 2 and 4-byte +multiples for glBitmap, glTexImage2D +and glReadPixels.  These +aren't strictly needed since the user can provide a 1, 2 or 4-byte +aligned address and appropriate GL_PACK_ROW_LENGTH or +GL_UNPACK_ROW_LENGTH values instead.
+
+RECOMMENDATION:  We recommend omitting them to simplify the driver.
+
+RESOLUTION: open
+
+

A.10 Pixel Pack/Unpack Skip Rows/Pixels Control

+Should we support the GL_UNPACK_SKIP_PIXELS, GL_UNPACK_SKIP_ROWS, +GL_PACK_SKIP_PIXELS and GL_PACK_SKIP_ROWS options for pixel +unpacking/packing?
+
+These options aren't really needed since the user can adjust the start +address and GL_PACK/UNPACK_ROW_LENGTH parameters to achieve the same +effect.
+
+RECOMMENDATION:  omit these parameters.
+
+RESOLUTION: open
+
+

A.11 Texture State Queries

+Should we support the command glGetTexEnvi/fv, +glGetTexParameteri/fv and glGetTexLevelParameteri/fv?
+
+RECOMMENDATION:  No. They're seldom needed and their +implementation is several hundred lines of code in length.
+
+RESOLUTION:  open
+
+

A.12 glGetIntegerv, glGetBooleanv and glGetDoublev

+Should we support the commands glGetIntegerv, +glGetBooleanv and glGetDoublev +in addition to glGetFloatv?
+
+RECOMMENDATION:  Omit the boolean, integer and double-valued +functions. All state values which can be queried by these commands can +be expressed as floating point values and queried with glGetFloatv.  The +implementation of the other three commands involves many lines of code.
+
+RESOLUTION:  open
+
+

A.13 glBitmap and Per-Fragment Operations

+Should bitmaps rendered with glBitmap +be subjected to the per-fragment operations?
+
+If bitmaps are implemented with points it will be easy to implement the +per-fragment operations.  Otherwise, it could be difficult.
+
+RECOMMENDATION:  Implement glBitmap by drawing points/pixels with +the hardware.  This will make supporting the per-fragments +trivially easy.  Also, it makes portrait-mode display relatively +easy.
+
+RESOLUTION:  open
+
+

A.14 Reduced gl.h Header File

+Should we produce a reduced gl.h header file which only defines the +tokens and functions which are implemented by the subset?
+
+RECOMMENDATION: yes.  It would be a useful reference to +programmers to quickly determine which functions and tokens are +supported.
+
+RESOLUTION: open
+
+

A.15 glPolygonMode

+Is glPolygonMode needed?
+
+RECOMMENDATION: No.  Omit it.
+
+RESOLUTION: closed, as of 26 Feb 2003
+
+
+

+ + diff --git a/docs/subset.html b/docs/subset.html new file mode 100644 index 0000000..487e721 --- /dev/null +++ b/docs/subset.html @@ -0,0 +1,31 @@ + + +Mesa Subset + + + +

Mesa Subset

+ +

+In 2002/2003 Tungsten Graphics was contracted to develop a subset Mesa/Radeon +driver for an embedded environment. The result is a reduced-size DRI driver +for the ATI R200 chip, for use with Linux fbdev rather than XFree86. +

+ +

+The specification for this subset can be found +here. +

+ +

+The MiniGLX specification describes the +interface between fbdev and Mesa. +

+ +

+More info to come... +

+ + + + diff --git a/docs/systems.html b/docs/systems.html new file mode 100644 index 0000000..46661d6 --- /dev/null +++ b/docs/systems.html @@ -0,0 +1,109 @@ + + +Supported Systems and Drivers + + + +

Supported Systems and Drivers

+ +

+Mesa was originally designed for Unix/X11 systems and is still best +supported on those systems. All you need is an ANSI C compiler and the +X development environment to use Mesa. +

+ +

Others have contributed drivers +for the Amiga, Apple Macintosh, BeOS, NeXT, OS/2, MS-DOS, VMS, Windows +9x/NT, and Direct3D. +

+ +

+The following files describe the details for various platforms. +Be warned, some of these files (and drivers) may be very out of date. +

+ + + + +

+The standard Mesa distribution only supports software-based rendering, with +the exception of the 3Dfx Glide driver. +Information about other hardware support follows. +

+ +
    +
  • DRI-based hardware support for 3dfx, Intel, Matrox, ATI with XFree86 +
    +

    The DRI architecture, + originally developed by Precision Insight, Inc. uses Mesa and + provides hardware acceleration for a number of popular chipsets.
    +
    + The DRI is part of XFree86 4.0 and later. +

    + If you download and install XFree86 4.x you do not need to + install Mesa separately. All the important parts of Mesa + will be installed with the rest of XFree86. +

    + + +
  • 3dfx Voodoo1, Voodoo2, Voodoo Rush, Voodoo Banshee, Voodoo3 +
    +

    All cards based on these chipsets should work with Linux and +Windows 95 via 3dfx's Glide library. +The Mesa/Glide driver is included with the Mesa distribution. +You'll need to install the Glide header files and runtime library. +

    +

    +David Bucciarelli wrote the original 3dfx driver for Mesa.
    +Daryll Strauss ported Glide to Linux. +

    +
    + + +
  • Matrox G200/G400, nVidia RIVA, ATI Rage Pro, Intel i810 on Linux +
    +

    The +Utah GLX project +(no longer active) developed drivers for these chipsets and others. +

    + +
  • Amiga Warp3D +
    +

    Amiga systems can support 3D hardware with the Warp3D API. +See here. +

    + +
  • Also see +
    +

    www.linux3d.org for +other 3D hardware info for Linux. +

    + +
+ +

+Note: +If you have NVIDIA hardware in your computer, +you should download and install NVIDIA's OpenGL library. You may +however, want to download Mesa in order to use its GLU and GLUT +libraries, or assorted demo programs.

+ + + + \ No newline at end of file diff --git a/docs/thanks.html b/docs/thanks.html new file mode 100644 index 0000000..8ed3dbc --- /dev/null +++ b/docs/thanks.html @@ -0,0 +1,124 @@ + + + +Acknowledgements + + + + +

Acknowledgments

+ + +The following individuals and groups are to be acknowledged for their +contributions to Mesa over the years. + + +
    +
  • Early Mesa development was done while Brian was part of the +SSEC Visualization Project at the University of +Wisconsin. He'd like to thank Bill Hibbard for letting him work on +Mesa as part of that project. +
    +
    +
  • John Carmack of id Software, Inc. funded Keith Whitwell in 1999 in +order to optimize Mesa's vertex transformation module. This is a very +substantial piece of work. +
    +
    +
  • Precision Insight, Inc., VA Linux Systems, Inc., and most recently, +Tungsten Graphics, Inc. have supported the ongoing development of Mesa. +
    +
    +
  • The Mesa +project is hosted bySourceforge.net +
    +
    + +
  • alt.software contributed the Direct3D driver. + +
  • Bernd Barsuhn wrote the evaluator code for (splines, +patches) in Mesa. + +
  • Bernhard Tschirren wrote the Allegro DJGPP driver. + +
  • Bogdan Sikorski wrote the GLU NURBS and polygon tessellator +in Mesa. + +
  • Charlie Wallace wrote the MS-DOS driver. + +
  • CJ Beyer was the www.mesa3d.org webmaster. + +
  • Darren Abbott provided the OS/2 driver. + +
  • David Bucciarelli wrote and maintained the 3Dfx Glide +driver. Thousands of Linux/Quake players thank David! + +
  • Gareth Hughes wrote new GLU 1.2 Polygon Tessellation code +(now superceded by SGI SI GLU). + +
  • Holger Waechtler contributed AMD 3DNow! assembly code which +accelerates vertex transformation in Mesa 3.1. Holger also implemented +the GL_EXT_texture_env_combine extension. + +
  • Jeroen van der Zijp and Thorsten Ohl contributed the +Xt/Motif widget code. + +
  • John Stone provided the multi-threading support in Mesa 3.0. + +
  • John Watson assisted with web page design. + +
  • Josh Vanderhoof contributed Intel x86 assembly code which +accelerates vertex transformation in Mesa 3.x. + +
  • Jouk Jansen contributed and continues to maintain the VMS +support. + +
  • Karl Schultz has been maintaining the Windows driver. + +
  • Keith Whitwell has made extension contributions to Mesa +since 1999. + +
  • Kendall Bennett wrote the SciTech MGL driver. + +
  • Klaus Niederkrueger contributed many improvements to Mesa's +software rasterizer. + +
  • Mark Kilgard contributed antialiased line improvements and +several extensions. + +
  • Michael Pichler contributed many bug fixes + +
  • Miklos Fazekas wrote and maintains the Macintosh driver. + +
  • Pascal Thibaudeau wrote the NeXT driver. + +
  • Pedro Vazquez setup and maintains the Mesa Mailing list. + +
  • Randy Frank contributed many bug fixes. + +
  • Stefan Zivkovic wrote the Amiga driver. + +
  • Stephane Rehel provided the Cygnus Win32 support + +
  • Ted Jump maintained the +makefiles and project files for Windows 95/98/NT compilation for some time. + +
  • Uwe Maurer wrote the LibGGI driver for Mesa-3.0. + +
  • Victor Ng-Thow-Hing wrote the Amiwin driver for the Amiga. + +
+ +

+Apologies to anyone who's been omitted. +Please send corrections and additions to Brian. +

+ + + + diff --git a/docs/utilities.html b/docs/utilities.html new file mode 100644 index 0000000..db2feba --- /dev/null +++ b/docs/utilities.html @@ -0,0 +1,24 @@ + + +Development Utilities + + + +

Development Utilities

+ +
    + +
  • The Mesa distribution includes several utility routines in the +progs/util/ directory + +
  • Allen Akin's glean is a framework for OpenGL testing. + +
  • Valgrind is a very useful tool for tracking down +memory-related problems in your code. + +
+ + + \ No newline at end of file diff --git a/docs/utility.html b/docs/utility.html new file mode 100644 index 0000000..3bbc2c7 --- /dev/null +++ b/docs/utility.html @@ -0,0 +1,42 @@ + + +Utilities + + + +

Utilities

+ + + + + + diff --git a/docs/webmaster.html b/docs/webmaster.html new file mode 100644 index 0000000..6ab101e --- /dev/null +++ b/docs/webmaster.html @@ -0,0 +1,22 @@ + + +Mesa Introduction + + + +

Webmaster

+ +

+If you have problems, edits or additions for this website send them +to Brian +(brian_e_paul@yahoo.com). +

+ +

+Mark Manning made the frame-based layout for the website. +Brian's modified it a lot since then. +

+ + + + \ No newline at end of file -- cgit