diff options
Diffstat (limited to 'docs')
101 files changed, 18657 insertions, 0 deletions
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. + + <one line to give the library's name and a brief idea of what it does.> + Copyright (C) <year> <name of author> + + 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. + + <signature of Ty Coon>, 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. + + <x> and <y> indicates the lower-left corner of the region to copy and + <width> and <height> 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 <pname> parameter of PixelStorei and PixelStoref + and the <pname> 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 <format> parameter of ReadPixels and DrawPixels: + + GL_DEPTH_STENCIL_MESA 0x8750 + + Accepted by the <type> 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: + + <type> 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 <format> 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 <format> 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 <data> 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 <cap> parameter of Enable, Disable, IsEnabled, + GetBooleanv, GetDoublev, GetFloatv and GetIntegerv: + + FRAGMENT_PROGRAM_CALLBACK_MESA 0x8bb1 + VERTEX_PROGRAM_CALLBACK_MESA 0x8bb4 + + Accepted by the <pname> parameter GetBooleanv, GetDoublev, + GetFloatv and GetIntegerv: + + FRAGMENT_PROGRAM_POSITION_MESA 0x8bb0 + VERTEX_PROGRAM_POSITION_MESA 0x8bb4 + + Accepted by the <pname> 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. <target> + 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 <cap> + 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, <target> will either be + FRAGMENT_PROGRAM_ARB or VERTEX_PROGRAM_ARB to indicate which + program is currently executing and <data> 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. + + <registerName> and <len> 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 <v>. If <name> 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 <target> 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 <target> 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 <registerName> + 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 <d> 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 ); + + <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 <mode> is valid and the operation completed + normally. GL_FALSE is returned if <mode> 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 <pname> 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 <interval> is set to a value of 0, buffer swaps are not synchron- + ized to a video frame. The <interval> 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 <interval> 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 <usage> + 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 + <interval> 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 <swapCount> 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 <missedFrames> 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 + <lastMissedUsage>. + + 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 <mask> 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 <pname> parameter of GetIntegerv, GetBooleanv, + GetFloatv, and GetDoublev: + + TRACE_MASK_MESA 0x8755 + + Accepted by the <pname> 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 ) + + <mask> 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. + + <traceName> specifies a name or label for the trace. It is expected + that <traceName> 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. + <mask> 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 <comment> 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 <comment> with the texture object or display list specified + by <name>. Logged commands which reference the named texture object or + display list will be annotated with <comment>. 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 <comment> with the address specified by <pointer> or with + a range of addresses specified by <first> through <last>. + Any logged commands which reference <pointer> or an address between + <first> and <last> will be annotated with <comment>. + + 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. + + <attribMask> 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 <test>, <func>, <mask>, and <clear> respectively. + Statements equivalent to the following will then be logged: + + glEnable(GL_DEPTH_TEST); (if <test> is true) + glDisable(GL_DEPTH_TEST); (if <test> is false) + glDepthFunc(<func>); + glDepthMask(<mask>); + glClearDepth(<clear>); + + + 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 <test>, <func>, <mask>, and <clear> respectively. + The resulting trace might then look will like this: + + { + GLboolean b; + GLint i; + GLfloat f; + b = glIsEnabled(GL_DEPTH_TEST); + assert(b == <test>); + glGetIntegerv(GL_DEPTH_FUNC, &i); + assert(i == <func>); + glGetIntegerv(GL_DEPTH_MASK, &i); + assert(i == <mask>); + glGetFloatv(GL_DEPTH_CLEAR_VALUE, &f); + assert(f == <clear>); + } + + +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 <internalFormat> and <format> parameters of + TexImage2D and TexSubImage2D: + + YCBCR_MESA 0x8757 + + Accepted by the <type> 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 <internalFormat> is + MESA_YCBCR but <format> is not MESA_YCBCR. + + INVALID_ENUM is generated by TexImage2D if <format> is MESA_YCBCR but + <internalFormat> is not MESA_YCBCR. + + INVALID_VALUE is generated by TexImage2D if <format> is MESA_YCBCR and + <internalFormat> is MESA_YCBCR and <border> is not zero. + + INVALID_OPERATION is generated by TexSubImage2D if the internal image + format is YCBCR_MESA and <format> 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 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<head> + <title>Mini GLX Specification</title> +</head> +<body> +<h1> +<center>Mini GLX Specification</center> +</h1> +<h2> +<center>Tungsten Graphics, Inc.<br> +<br> +January 20, 2003<br> +<br> +</center> +</h2> +<p> Copyright © 2002-2003 by Tungsten Graphics, Inc., Cedar Park, +Texas. All Rights Reserved. <br> +<br> +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.<br> +<br> +</p> +<h1>1. Introduction</h1> +<p>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.</p> +<p>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.</p> +<p>This document serves as both the reference guide and programming +guide for Mini GLX.<br> +<br> +</p> +<h1>2. Mini GLX Concepts</h1> +<p>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.</p> +<p>There are three main datatypes or resources managed by Mini GLX. The +resources and their corresponding GLX or Xlib data types are:</p> +<table cellspacing="10" align="center"> + <tbody> + <tr> + <td><u>Resource</u></td> + <td><u>Data type</u></td> + </tr> + <tr> + <td>pixel formats</td> + <td>X Visual and XVisualInfo</td> + </tr> + <tr> + <td>drawing surfaces</td> + <td>X Window or GLXDrawable</td> + </tr> + <tr> + <td>rendering contexts</td> + <td>GLXContext</td> + </tr> + </tbody> +</table> +<p>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.</p> +<p>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.</p> +<p>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.</p> +<p>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.<br> +<br> +</p> +<h1>3. Using Mini GLX</h1> +<p>To use the Mini GLX interface in your application, include the +GL/miniglx.h header file at compile time:</p> +<blockquote><code> #include <GL/miniglx.h><br> + </code></blockquote> +<code></code>Applications should link with libGL.so (i.e. <code>gcc +myprogram.o -lGL -o myprogram</code>). libGL.so implements the +MiniGLX API functions and, in turn, loads a hardware-specific device +driver (such as <code>radeon_dri.so</code>) at runtime. The +environment variable <code>LIBGL_DRIVERS_PATH</code> should name the +directory where these modules are located.<br> +<br> +Prior to running a MiniGXL application, the following kernel modules +must be installed:<br> +<br> +<div style="margin-left: 40px;"> agpgart.o<br> +radeonfb.o (assuming Radeon hardware)<br> +radeon.o (assuming Radeon hardware)<br> +</div> +<code></code> <br> +Finally, MiniGLX reads a configuration file (by default,<code> +/etc/miniglx.conf</code>) to determine basic configuration information. + The configuration file may also be located in the directory +specified by the <code>MINIGLX_CONF</code> environment variable).<br> +<br> +The remainder of this section describes the MiniGLX API functions.<br> +<br> +<h2>3.1 Initialization</h2> +<p>The XOpenDisplay function is used to initialize the graphics system:</p> +<blockquote> + <pre>Display *XOpenDisplay(const char *displayname)<br></pre> +</blockquote> +<p>The <code>displayName</code> parameter is currently ignored in Mini +GLX. It is recommended that <code>NULL</code> be passed as the<code>displayName</code> +parameter.</p> +<p>If XOpenDisplay is able to initialize the graphics system a pointer +to a Display will be returned. Otherwise, NULL will be returned.</p> +<h2>3.2 Choosing a Visual</h2> +<p>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:</p> +<blockquote> + <pre>XVisualInfo *glXChooseVisual(Display *dpy, int screen, const int *attribList)<br></pre> +</blockquote> +<p><code>dpy</code> is a pointer to the display returned by +XOpenDisplay. </p> +<p><code>screen</code> is currently ignored by Mini GLX and should be +zero. </p> +<p><code>attribList</code> is a list of GLX attributes which describe +the desired pixel format. It is terminated by the token <code>None</code>. +The attributes are as follows:</p> +<blockquote> + <dl> + <dt><code>GLX_USE_GL</code></dt> + <dd>This attribute should always be present in order to maintain +compatibility with GLX.</dd> + <dt><code>GLX_RGBA</code></dt> + <dd>If present, only RGBA pixel formats will be considered. +Otherwise, only color index formats are considered.</dd> + <dt><code>GLX_DOUBLEBUFFER</code></dt> + <dd>if present, only double-buffered pixel formats will be chosen.</dd> + <dt><code>GLX_RED_SIZE n</code></dt> + <dd>Must be followed by a non-negative integer indicating the +minimum number of bits per red pixel component that is acceptable.</dd> + <dt><code>GLX_GREEN_SIZE n</code></dt> + <dd>Must be followed by a non-negative integer indicating the +minimum number of bits per green pixel component that is acceptable.</dd> + <dt><code>GLX_BLUE_SIZE n</code></dt> + <dd>Must be followed by a non-negative integer indicating the +minimum number of bits per blue pixel component that is acceptable.</dd> + <dt><code>GLX_ALPHA_SIZE n</code></dt> + <dd>Must be followed by a non-negative integer indicating the +minimum number of bits per alpha pixel component that is acceptable.</dd> + <dt><code>GLX_STENCIL_SIZE n</code></dt> + <dd>Must be followed by a non-negative integer indicating the +minimum number of bits per stencil value that is acceptable.</dd> + <dt><code>None</code></dt> + <dd>This token is used to terminate the attribute list.</dd> + </dl> +</blockquote> +<p>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.</p> +<p>Note that visuals with accumulation buffers and depth buffers are +not available.<br> +<br> +</p> +<h2>3.3 Creating a Drawing Surface</h2> +<p>Drawing surfaces are created as X windows. For Mini GLX, +windows are <i>full-screen</i>; 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.</p> +<h3>3.3.1 Window Creation</h3> +<p>The XCreateWindow function is used to create a drawing surface:</p> +<blockquote> + <pre>Window XCreateWindow( Display *display,<br> Window parent,<br> int x, int y,<br> unsigned int width, unsigned int height,<br> unsigned int borderWidth,<br> int depth,<br> unsigned int class,<br> Visual *visual,<br> unsigned long valuemask,<br> XSetWindowAttributes *attributes )<br></pre> +</blockquote> +<p>The parameters are as follows:</p> +<blockquote> + <dl> + <dt><code>display</code></dt> + <dd>A Display pointer, as returned by XOpenDisplay.</dd> + <dt><code>parent</code></dt> + <dd>The parent window for the new window. For Mini GLX, this +should be<code>RootWindow(dpy, 0)</code>.</dd> + <dt><code>x, y</code></dt> + <dd>The position of the window. For Mini GLX, both values should +be zero.</dd> + <dt><code>width, height</code></dt> + <dd>The size of the window. For Mini GLX, this specifies the +desired screen size such as 1024, 768 or 1280, 1024.</dd> + <dt><code>borderWidth</code></dt> + <dd>This parameter should be zero.</dd> + <dt><code>depth</code></dt> + <dd>The pixel depth for the window. For Mini GLX this should be +the depth found in the XVisualInfo object returned by <code>glxChooseVisual</code>.</dd> + <dt><code>class</code></dt> + <dd>The window class. For Mini GLX this value should be <code>InputOutput</code>.</dd> + <dt><code>visual</code></dt> + <dd>This parameter should be the <code>visual</code> field of the <code>XVisualInfo</code> +object returned by <code>glxChooseVisual</code>.</dd> + <dt><code>valuemask</code></dt> + <dd>This parameter indicates which fields of the <code>XSetWindowAttributes</code> +are to be used. For Mini GLX this is typically the bitmask<code>CWBackPixel +| CWBorderPixel | CWColormap</code>.</dd> + <dt><code>attributes</code></dt> + <dd>Initial window attributes. Of the fields in the <code>XSetWindowAttributes</code> +structure, the<code>background_pixel</code>, <code>border_pixel</code> +and <code>colormap</code> fields should be set. See the discussion +below regarding colormaps.</dd> + </dl> +</blockquote> +<p><code>XCreateWindow</code> will return a window handle if it succeeds +or zero if it fails.</p> +<h3>3.3.2 Window Mapping</h3> +<p>To display the window the XMapWindow function must be called:</p> +<blockquote> + <pre>void XMapWindow(Display *dpy, Window w)</pre> +</blockquote> +<p>This function does nothing in Mini GLX but is required for Xlib/GLX +compatibility</p> +<h3>3.3.3 Colormaps<br> +</h3> +<p>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:</p> +<blockquote><code>Colormap XCreateColormap(Display *dpy, Window window, +Visual *visual, int alloc)</code><br> + <code></code></blockquote> +<p>The parameters are as follows:<br> +</p> +<blockquote> + <dl> + <dt><code>dpy</code></dt> + <dd>The display handle as returned by XOpenDisplay.</dd> + <dt><code>window</code></dt> + <dd> This parameter is ignored by Mini GLX but should be the value +returned by the <code>RootWindow(dpy, 0)</code> macro.<br> + </dd> + <dt><code>visual</code></dt> + <dd>This parameter is ignored by Mini GLX but should be the visual +field of the XVisualInfo object returned by glXChooseVisual. </dd> + <dt><code>alloc</code></dt> + <dd>This parameter is ignored by Mini GLX but should be set to <code>AllocNone</code>.</dd> + </dl> +</blockquote> +<br> +<h2>3.4 Creating a Rendering Context</h2> +<p>An OpenGL rendering context is created with the <code>glXCreateContext</code> +function:</p> +<blockquote> + <pre>GLXContext glXCreateContext(Display *dpy, XVisualInfo *visInfo, GLXContext shareList, Bool direct)<br></pre> +</blockquote> +<p>The parameters are as follows:</p> +<blockquote> + <dl> + <dt><code>dpy</code></dt> + <dd>The display handle as returned by XOpenDisplay.</dd> + <dt><code>visInfo</code></dt> + <dd>The visual as returned by glXChooseVisual.</dd> + <dt><code>shareList</code></dt> + <dd>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.</dd> + <dt><code>direct</code></dt> + <dd>Specifies whether direct or indirect rendering is desired. For +Mini GLX this value is ignored but it should be set to <code>True</code>.</dd> + </dl> +</blockquote> +<p><code>glXCreateContext</code> will return a GLXContext handle if it +succeeds or zero if it fails due to invalid parameter or insufficient +resources.<br> +<br> +</p> +<h2>3.5 Binding a Rendering Context</h2> +<p>The final step before beginning OpenGL rendering is to bind (i.e. +activate) a rendering context and drawing surface with the +glXMakeCurrent function:</p> +<blockquote> + <pre>Bool glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)<br></pre> +</blockquote> +<p>The parameters are as follows:</p> +<blockquote> + <dl> + <dt><code>dpy</code></dt> + <dd>The display handle, as returned by XOpenDisplay.</dd> + <dt><code>drawable</code></dt> + <dd>The window or drawable to bind to the rendering context. This +should be the value returned by XCreateWindow.</dd> + <dt><code>ctx</code></dt> + <dd>The rendering context to bind, as returned by glXCreateContext.</dd> + </dl> +</blockquote> +<p>If glXMakeCurrent succeeds True is returned. Otherwise False is +returned to indicate an invalid display, window or context parameter.</p> +<p>After the rendering context has been bound to the drawing surface +OpenGL rendering can begin.</p> +<p>The current rendering context may be unbound by calling +glXMakeCurrent with the window and context parameters set to zero.</p> +<p>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.<br> +<br> +</p> +<h2>3.6 Color Buffer Swapping</h2> +<p>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.</p> +<p>The color buffers for a particular window (i.e. drawable) may be +swapped with the glXSwapBuffers command:</p> +<blockquote> + <pre>void glXSwapBuffers(Display *dpy, GLXDrawable drawable)<br></pre> +</blockquote> +Any pending rendering commands will be completed before the buffer swap +takes place.<br> +<br> +Calling glXSwapBuffers on a window which is single-buffered has no +effect.<br> +<br> +<h2>3.7 Releasing Resources</h2> +<h3>3.7.1 Releasing Rendering Contexts</h3> +<p>A rendering context may be destroyed by calling glXDestroyContext:</p> +<blockquote> + <pre>void glXDestroyContext(Display *dpy, GLXContext ctx)<br></pre> +</blockquote> +<h3>3.7.2 Releasing Windows</h3> +<p>A window may be destroyed by calling XDestroyWindow:</p> +<blockquote> + <pre>void XDestroyWindow(Display *dpy, Window window)<br></pre> +</blockquote> +<h3>3.7.3 Releasing Visuals</h3> +<p>An XVisualInfo object may be freed by calling XFree:</p> +<blockquote> + <pre>void XFree(void *data)<br></pre> +</blockquote> +<h3>3.7.4 Releasing Colormaps</h3> +<p>A colormap may be freed by calling XFreeColormap:</p> +<blockquote> + <pre>void XFreeColormap(Display *dpy, Colormap colormap)<br></pre> +</blockquote> +<h3>3.7.4 Releasing Display Resources</h3> +<p>When the application is about to exit, the resources associated with +the graphics system can be released by calling XCloseDisplay:</p> +<blockquote> + <pre>void XCloseDisplay(Display *dpy)<br></pre> +</blockquote> +<p>The display handle becomes invalid at this point.<br> +<br> +</p> +<h2>3.8 Query Functions</h2> +<h3>3.8.1 Querying Available Visuals</h3> +A list of all available visuals can be obtained with the XGetVisualInfo +function:<br> +<br> +<div style="margin-left: 40px;"><code>XVisualInfo +*XGetVisualInfo(Display *dpy, long vinfo_mask, XVisualInfo +*vinfo_template, int *nitems_return)<br> +</code></div> +<br> +The parameters are as follows:<br> +<blockquote> + <dl> + <dt><code>dpy</code></dt> + <dd>The display handle, as returned by XOpenDisplay.</dd> + <dt><code>vinfo_mask</code></dt> + <dd>A bitmask indicating which fields of the vinfo_template are to +be matched. The value must be VisualScreenMask.</dd> + <dt><code>vinfo_template</code></dt> + <dd>A template whose fields indicate which visual attributes must +be matched by the results. The screen field of this structure must +be zero.</dd> + <dt><code>nitems_return</code></dt> + <dd>Returns the number of visuals returned. </dd> + </dl> +</blockquote> +The return value is the address of an array of all available visuals.<br> +<br> +An example of using XGetVisualInfo to get all available visuals follows:<br> +<br> +<div style="margin-left: 40px;"><code>XVisualInfo visTemplate, *results;</code><br> +<code>int numVisuals;</code><br> +<code>Display *dpy = XOpenDisplay(NULL);</code><br> +<code>visTemplate.screen = 0;</code><br> +<code>results = XGetVisualInfo(dpy, VisualScreenMask, &visTemplate, +&numVisuals);</code><br> +<code></code></div> +<br> +<h3>3.8.2 Querying Visual Attributes</h3> +<p>The GLX attributes of an X visual may be queried with the +glXGetConfig function:</p> +<blockquote> + <pre>int glXGetConfig(Display *dpy, XVisualInfo *vis, int attribute, int *value)<br></pre> +</blockquote> +<p>The parameters are as follows:</p> +<blockquote> + <dl> + <dt><code>dpy</code></dt> + <dd>The display handle, as returned by XOpenDisplay.</dd> + <dt><code>vis</code></dt> + <dd>The visual, as returned by glXChooseVisual.</dd> + <dt><code>attribute</code></dt> + <dd>The attribute to query. The attributes are listed below.</dd> + <dt><code>value</code></dt> + <dd>Pointer to an integer in which the result of the query will be +stored. </dd> + </dl> +</blockquote> +<p>The return value will be zero if no error occurs.<code> + GLX_INVALID_ATTRIBUTE</code> will be returned if the attribute +parameter is invalid.<code> GLX_BAD_VISUAL</code> will be returned +if the XVisualInfo parameter is invalid.</p> +<p>The following attributes may be queried:</p> +<blockquote> + <dl> + <dt><code>GLX_USE_GL</code></dt> + <dd>The result will be <code>True</code> or <code>False</code> to +indicate if OpenGL rendering is supported with the visual. Mini GLX +always return <code>True</code>.</dd> + <dt><code>GLX_RGBA</code></dt> + <dd>The result will be <code>True</code> for RGBA visuals or <code>False</code> +for color index visuals.</dd> + <dt><code>GLX_DOUBLEBUFFER</code></dt> + <dd>The result will be <code>True</code> if the visual has two +color buffers or <code>False</code> if the visual has one color buffer.</dd> + <dt><code>GLX_RED_SIZE</code></dt> + <dd>The result will be the number of red bits per pixel.</dd> + <dt><code>GLX_GREEN_SIZE</code></dt> + <dd>The result will be the number of green bits per pixel.</dd> + <dt><code>GLX_BLUE_SIZE</code></dt> + <dd>The result will be the number of blue bits per pixel.</dd> + <dt><code>GLX_ALPHA_SIZE</code></dt> + <dd>The result will be the number of alpha bits per pixel.</dd> + <dt><code>GLX_DEPTH_SIZE</code></dt> + <dd>The result will be the number of bits per Z value.</dd> + <dt><code>GLX_STENCIL_SIZE</code></dt> + <dd>The result will be the number of bits per stencil value.<br> + <br> + </dd> + </dl> +</blockquote> +<h3>3.8.3 Querying the Current Rendering Context</h3> +<p>The current rendering context can be queried with +glXGetCurrentContext: </p> +<blockquote> + <pre>GLXContext glXGetCurrentContext(void)<br></pre> +</blockquote> +<p>Zero will be returned if no context is currently bound.<br> +<br> +</p> +<h3>3.8.4 Querying the Current Drawable</h3> +<p>The current drawable (i.e. window or drawing surface) can be queried +with glXGetCurrentDrawable:</p> +<blockquote> + <pre>GLXDrawable glXGetCurrentDrawable(void)<br></pre> +</blockquote> +<p>Zero will be returned if no drawable is currently bound.<br> +<br> +</p> +<h3>3.8.5 Function Address Queries</h3> +<p>The glXGetProcAddress function will return the address of any +available OpenGL or Mini GLX function:</p> +<blockquote> + <pre>void *glXGetProcAddress(const GLubyte *procName)<br></pre> +</blockquote> +<p>If <code>procName</code> is a valid function name, a pointer to that +function will be returned. Otherwise, NULL will be returned.</p> +<p>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.<br> +<br> +</p> +<h2>3.9 Versioning</h2> +The Mini GLX version can be queried at run time with glXQueryVersion: +<blockquote> + <pre>Bool glXQueryVersion(Display *dpy, int *major, int *minor)<br></pre> +</blockquote> +<p><code>major</code> will be set to the major version number and<code>minor</code> +will be set to the minor version number.<code>True</code> will be +returned if the function succeeds. <code>False</code> will be returned +if the function fails due to invalid parameters. The <code>dpy</code> +argument is currently ignored, but should be the value returned by +XOpenDisplay.</p> +<p>At compile time, the Mini GLX interface version can be tested with +the MINI_GLX_VERSION_1_<i>x</i> preprocessor tokens. For example, if +version 1.0 of Mini GLX is supported, then<code> MINI_GLX_VERSION_1_0</code> +will be defined. If version 1.1 of Mini GLX is supported, then<code> +MINI_GLX_VERSION_1_1</code> will be defined.</p> +<p>At the time of writing the current Mini GLX version is 1.0.<br> +<br> +</p> +<h1>4.0 Interoperability with GLX and Xlib</h1> +While Mini GLX strives to be compatible with GLX and Xlib there are +some unavoidable differences which must be taken into consideration.<br> +<h2>4.1 Public vs Private Structures</h2> +The structure of many X data types is public. For example, the <code>Display</code> +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 <code>miniglx.h</code>. Duplicating the Xlib +declaration for the <code>Display</code> data type in minigl.h would +require defining a large number of other superfluous Xlib datatypes.<br> +<br> +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 <code>XVisualInfo</code> and <code>XSetWindowAtttributes</code> +data types must be completely public. +<h2>4.2 Macros</h2> +In some cases, Xlib defines macros which are meant to be used instead +of direct structure accesses. For example, the <code>RootWindow(dpy, +screen)</code> 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.<br> +<br> +Mini GLX also defines a <code>RootWindow</code> macro since it's +essential for creating windows. But the implementation of this +macro by Xlib and Mini GLX is completely different.<br> +<h2>4.3 Summary</h2> +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.<br> +<br> +Nevertheless, the fact that Mini GLX programs can be recompiled for +Xlib and GLX increases portability and flexibility for testing and +prototyping.<br> +<br> +<h1>5.0 Example Program</h1> +<p>This section shows an example program which uses the Mini GLX +interface. The program simply draws several frames of a rotating square.<br> +</p> +<p>The program may be compiled for use with Xlib/GLX or Mini GLX by +setting the <code>USE_MINIGLX</code> token to 0 or 1, respectively. + Note that the only difference is the header files which are +included.<br> +</p> +<p> </p> +<pre><code><br></code>#define USE_MINIGLX 1 /* 1 = use Mini GLX, 0 = use Xlib/GLX */<br><br>#include <stdio.h><br>#include <stdlib.h><br>#include <GL/gl.h><br><br>#if USE_MINIGLX<br>#include <GL/miniglx.h><br>#else<br>#include <GL/glx.h><br>#include <X11/Xlib.h><br>#endif<br><br><code>/*<br> * Create a simple double-buffered RGBA window.<br> */<br>static Window<br>MakeWindow(Display * dpy, unsigned int width, unsigned int height)<br>{<br> int visAttributes[] = {<br> GLX_RGBA,<br> GLX_RED_SIZE, 1,<br> GLX_GREEN_SIZE, 1,<br> GLX_BLUE_SIZE, 1,<br> GLX_DOUBLEBUFFER,<br> None<br> };<br> XSetWindowAttributes attr;<br> unsigned long attrMask;<br> Window root;<br> Window win;<br> GLXContext ctx;<br> XVisualInfo *visinfo;<br><br> root = RootWindow(dpy, 0);<br><br> /* Choose GLX visual / pixel format */<br> visinfo = glXChooseVisual(dpy, 0, visAttributes);<br> if (!visinfo) {<br> printf("Error: couldn't get an RGB, Double-buffered visual\n");<br> exit(1);<br> }<br><br> /* Create the window */<br> attr.background_pixel = 0;<br> attr.border_pixel = 0;<br> attr.colormap = XCreateColormap(dpy, root, visinfo->visual, AllocNone);<br> attrMask = CWBackPixel | CWBorderPixel | CWColormap;<br> win = XCreateWindow(dpy, root, 0, 0, width, height,<br> 0, visinfo->depth, InputOutput,<br> visinfo->visual, attrMask, &attr);<br> if (!win) {<br> printf("Error: XCreateWindow failed\n");<br> exit(1);<br> }<br><br> /* Display the window */<br> XMapWindow(dpy, win);<br><br> /* Create GLX rendering context */<br> ctx = glXCreateContext(dpy, visinfo, NULL, True);<br> if (!ctx) {<br> printf("Error: glXCreateContext failed\n");<br> exit(1);<br> }<br><br> /* Bind the rendering context and window */<br> glXMakeCurrent(dpy, win, ctx);<br><br> return win;<br>}<br><br><br>/*<br> * Draw a few frames of a rotating square.<br> */<br>static void<br>DrawFrames(Display * dpy, Window win)<br>{<br> int angle;<br> glShadeModel(GL_FLAT);<br> glClearColor(0.5, 0.5, 0.5, 1.0);<br> for (angle = 0; angle < 360; angle += 10) {<br> glClear(GL_COLOR_BUFFER_BIT);<br> glColor3f(1.0, 1.0, 0.0);<br> glPushMatrix();<br> glRotatef(angle, 0, 0, 1);<br> glRectf(-0.8, -0.8, 0.8, 0.8);<br> glPopMatrix();<br> glXSwapBuffers(dpy, win);<br> }<br>}<br><br><br>int<br>main(int argc, char *argv[])<br>{<br> Display *dpy;<br> Window win;<br><br> dpy = XOpenDisplay(NULL);<br> if (!dpy) {<br> printf("Error: XOpenDisplay failed\n");<br> return 1;<br> }<br><br> win = MakeWindow(dpy, 300, 300);<br><br> DrawFrames(dpy, win);<br><br> return 0;<br>}<br></code></pre> +<br> +</body> +</html> 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 <dborca 'at' users 'dot' sourceforge 'dot' net> +Hiroshi Morii <koolsmoky 'at' users 'dot' sourceforge 'dot' net> + + + +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 <GL/xmesa.h> + + 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 <version> + <Voodoo_Graphics|Voodoo_Rush|UNKNOWN> <num> CARD/<num> FB/ + <num> TM/<num> TMU/<NOSLI|SLI>" + where: <num> CARD is the card used for the current context, + <num> FB is the number of MB for the framebuffer, + <num> TM is the number of MB for the texture memory, + <num> 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 <pragmas/xlib_pragmas.h> + 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 <sys/time.h> 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 <at> anobject <dot> com +Marcin Konicki ahwayakchih <at> neoni <dot> net +Francois Revol revol <at> free <dot> 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: <visual-class> <depth> + 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 <dborca@users.sourceforge.net> + + + +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 +<stephane.raimbault@windriver.com> +<stephane.raimbault@deesse.univ-lemans.fr> + +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 <config>'. 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: <visual-class> <depth> + 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 + <none> 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 <format> 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 @@ +<HTML> + +<title>Banner</title> + + +<body text="#ffffff" bgcolor="#aa4444"> + +<center> +<p> +<font size="5">The Mesa 3D Graphics Library</font> +</p> +</center> + +</body> +</html>
\ 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 @@ +<HTML> + +<TITLE>Mesa Bug Reporting</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Bug Database</H1> + +<p> +The Mesa bug database is now hosted on +<a href="http://freedesktop.org" target="_parent">freedesktop.org</a> +instead of SourceForge. +</p> + +<p> +To file a Mesa bug, go to +<a href="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa" +target="_parent"> +Bugzilla on freedesktop.org</a> +</p> + +<p> +Please follow these bug reporting guidelines: +</p> + +<ul> +<li>Make sure you're using the most recent version of Mesa +<li>Make sure your bug isn't already reported +<li>Include as much information as possible in the report +<li>Provide a simple GLUT-based test program if possible +<li>Check back for follow-ups to the report +</ul> + +<p> +Bug reports will automatically be forwarded to the Mesa developer's mailing +list. +</p> + +<p> +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. +</p> + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Conformance</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Conformance</H1> + +<p> +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. +</p> +<p> +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. +</p> +<p> +The tests were run using the software X11 device driver on 24-bpp +and 16-bpp displays. +</p> +<p> +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. +</p> + + +<pre> + +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. + + +</pre> + +NOTE: conformx passes for all machine path levels (-p option). + + +</body> +</html> 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 @@ +<html> + +<title>Contents</title> + +<body text="#ffffff" bgcolor="#119955" link="#ffffff" vlink="#dddddd" alink="#ffffff"> + +<b>Documentation</b> +<ul> +<li><a href="intro.html" target="MainFrame">Introduction</a> +<li><a href="news.html" target="MainFrame">News</a> +<li><a href="systems.html" target="MainFrame">Platforms and Drivers</a> +<li><a href="license.html" target="MainFrame">License & Copyright</a> +<li><a href="faq.html" target="MainFrame">FAQ</a> +<li><a href="VERSIONS" target="MainFrame">Version History</a> +<li><a href="relnotes.html" target="MainFrame">Release Notes</a> +<li><a href="thanks.html" target="MainFrame">Acknowledgements</a> +<li><a href="conform.html" target="MainFrame">Conformance Testing</a> +<li>more docs below... +</ul> + +<b>Download / Install</b> +<ul> +<li><a href="http://www.sourceforge.net/projects/mesa3d" target="_parent">Stable Release (6.2)</a> +<li><a href="download.html" target="MainFrame">Downloading/Unpacking</a> +<li><a href="install.html" target="MainFrame">Compilation/Installation</a> +<li><a href="glu.html" target="MainFrame">SGI's GLU</a> +<li><a href="precompiled.html" target="MainFrame">Precompiled Libraries</a> +</ul> + +<b>Resources</b> +<ul> +<li><a href="lists.html" target="MainFrame">Mailing Lists</a> +<li><a href="bugs.html" target="MainFrame">Bug Database</a> +<li><a href="webmaster.html" target="MainFrame">Webmaster</a> +</ul> + +<b>User Topics</b> +<ul> +<LI><A HREF="envvars.html" target="MainFrame">Environment Variables</A> +<LI><A HREF="osmesa.html" target="MainFrame">Off-Screen Rendering</A> +<LI><A HREF="pbuffers.html" target="MainFrame">Pbuffer Rendering</A> +<LI><A HREF="debugging.html" target="MainFrame">Debugging Tips</A> +<LI><A HREF="perf.html" target="MainFrame">Performance Tips</A> +<LI><A HREF="extensions.html" target="MainFrame">Mesa Extensions</A> +<LI><A HREF="mangling.html" target="MainFrame">Function Name Mangling</A> +</ul> + +<b>Developer Topics</b> +<ul> +<li><a href="http://sourceforge.net/projects/mesa3d" target="_parent">SourceForge homepage</a> +<li><a href="cvs_access.html" target="MainFrame">CVS Access</a> +<li><a href="cvs_branches.html" target="MainFrame">CVS Branch Info</a> +<li><a href="utilities.html" target="MainFrame">Utilities</a> +<li><a href="helpwanted.html" target="MainFrame">Help Wanted</a> +<li><a href="devinfo.html" target="MainFrame">Development Notes</a> +<li><a href="drivers.html" target="MainFrame">Writing Device Drivers</a> +<li><a href="sourcedocs.html" target="MainFrame">Source Documentation</a> +<li><a href="subset.html" target="MainFrame">Subset Information</a> +<li><a href="fbdev-dri.html" target="MainFrame">fbdev/DRI Environment</a> +<li><a href="glfbdev-driver.html" target="MainFrame">glFBDev Driver</a> +<LI><A HREF="custom.html" target="MainFrame">Custom Development</A> +</ul> + +<b>Links</b> +<ul> +<li><a href="http://www.opengl.org" target="_parent">OpenGL website</a> +<li><a href="http://dri.sourceforge.net" target="_parent">DRI website</a> +<li><a href="games.html" target="MainFrame">Games and Entertainment</a> +<li><a href="libraries.html" target="MainFrame">Libraries and Toolkits</a> +<li><a href="modelers.html" target="MainFrame">Modeling and Rendering</a> +<li><a href="science.html" target="MainFrame">Science and Technical</a> +<li><a href="utility.html" target="MainFrame">Utilities</a> +<li><a href="demos.html" target="MainFrame">Demos / other</a> +</ul> + +<A HREF="http://sourceforge.net" +target="_parent"><IMG SRC="http://sourceforge.net/sflogo.php?group_id=3&type=1" +WIDTH="88" HEIGHT="31" ALIGN="BOTTOM" ALT="Sourceforge.net" BORDER="0"></A> + +</body> +</html>
\ 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 @@ +<HTML> + +<TITLE>Custom Development</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Custom Development</H1> + +<p> +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. +</p> + +<p> +<pre>[Begin shameless plug]</pre> +If you have a need for specific or custom Mesa development work, +<a href="http://www.tungstengraphics.com/" target="_parent"> +Tungsten Graphics, Inc.</a> may be able to help you. +<pre>[End shameless plug]</pre> +</p> + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>CVS Access</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<h1>CVS Access</h1> + +<p> +Mesa's CVS repository (code management system) is hosted on +<a href="http://www.freedesktop.org" target="_parent">freedesktop.org</a>. +</p> + +<p> +You may access the repository either as an +<a href="#anonymous">anonymous user</a> (read-only) or as a +<a href="#developer">developer</a> +(read/write). +</p> + +<p> +You may also +<a href="http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/" +target="_parent">browse the CVS repository</a>. +</p> + + +<a name="anonymous"> +<H2>Anonymous CVS Access</H2> + +<p> +Anonymous, public, read-only access to the CVS repository is available. +Here are the basic instructions for Unix systems: +</p> + +<ol> +<li>Install CVS client software on your computer if needed. + Version 1.9.28 is known to work. +<li>Login as an anonymous user: + <pre> + cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/mesa login + </pre> + Just press Enter/Return when prompted for a password. + <br> + <br> +<li>Check out the code: + <pre> + cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/mesa co Mesa + </pre> +</ol> + + +<p>To update your Mesa CVS source to the latest CVS source:</p> + +<ol> +<li><code>cd Mesa</code> +<li><code>cvs -z3 -d:pserver:anonymous@pdx.freedesktop.org:/cvs/mesa update</code> +</ol> + + +<a name="developer"> +<H2>Developer CVS Access</H2> + +<p> +Mesa developers working with the Mesa CVS repository need to first +have an account on <a href="http://www.freedesktop.org" target="_parent"> +freedesktop.org</a>. +You can request an account from either +<a href="mailto:dstone@trinity.unimelb.edu.au">Daniel Stone</a> or +<a href="mailto:eta@lclark.edu">Eric Anholt</a>. +</p> + +<p> +Once your account is established, you can check out the Mesa CVS tree +with: +<pre> + setenv CVS_RSH ssh (if using a csh-like shell) +</pre> +<em>OR</em> +<pre> + export CVS_RSH=rsh (if using a bash-like shell) +</pre> +followed by: +<pre> + cvs -d:ext:yourusername@pdx.freedesktop.org:/cvs/mesa co Mesa +</pre> + +<p> +Of course, replace <em>yourusername</em> with your actual login name. +</p> + +<p> +Subsequent updates should only require: +</p> +<pre> + cvs update +</pre> + + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>CVS Branches</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>CVS Branch Information</H1> + +<p> +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. +</p> + +<p> +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. +</p> + +<p> +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. +</p> + +<p> +To checkout a specific CVS branch pass <code>-r</code> and +the branch tag after your CVS command. + +For example <code>cvs checkout -r mesa_6_2_branch Mesa</code> will +checkout the 6.2 branch and <code>cvs update -r +mesa_6_2_branch</code> will convert your current CVS tree to the 6.2 +branch. + +Consult <a href="http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54" +target="_parent">http://www.durak.org/cvswebsites/doc/cvs_5.php3#SEC54</a> +for more on branching in CVS. +</p> + +<p> +To see a list of all the CVS branches run <code>cvs log README</code> (or any +other file) and look for the section labeled <code>symbolic names</code>. +You'll see something like this: +</p> + +<pre> 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 +</pre> + +<p> +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. +</p> + + +</body> +</html>
\ 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 @@ +<HTML> + +<TITLE>Debugging Tips</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Debugging Tips</H1> + +<p> + Normally Mesa (and OpenGL) records but does not notify the user of + errors. It is up to the application to call + <code>glGetError</code> 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. +</p> + +<p> + 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. +</p> +<p> + In your debugger you can set a breakpoint in _mesa_error() to trap Mesa + errors. +</p> +<p> + There is a display list printing/debugging facility. See the end of + src/dlist.c for details. +</p> + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Demos</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Demos</H1> + + +<ul> +<li><a href="http://www.geocities.com/shobhand/homepage.html">Shobhan Dutta's Geartrain and Walkthrough Demos</a> +</li></ul> + + +</body> +</html>
\ 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 @@ +<HTML> + +<TITLE>Development Notes</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Development Notes</H1> + + +<H2>Adding Extentions</H2> + +<p> +To add a new GL extension to Mesa you have to do at least the following. + +<ul> +<li> + If glext.h doesn't define the extension, edit include/GL/gl.h and add + code like this: + <pre> + #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 + </pre> +</li> +<li> + 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. +</li> +<li> + 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. +</li> +<li> + If hew extension adds new GL state, the functions in get.c, enable.c + and attrib.c will most likely require new code. +</li> +</ul> + + + +<H2>Coding Style</H2> + +<p> +Mesa's code style has changed over the years. Here's the latest. +</p> + +<p> +Comment your code! It's extremely important that open-source code be +well documented. Also, strive to write clean, easily understandable code. +</p> + +<p> +3-space indentation +</p> + +<p> +If you use tabs, set them to 8 columns +</p> + +<p> +Brace example: +</p> +<pre> + if (condition) { + foo; + } + else { + bar; + } +</pre> + +<p> +Here's the GNU indent command which will best approximate my preferred style: +</p> +<pre> + indent -br -i3 -npcs infile.c -o outfile.c +</pre> + + +<p> +Local variable name example: localVarName (no underscores) +</p> + +<p> +Constants and macros are ALL_UPPERCASE, with _ between words +</p> + +<p> +Global vars not allowed. +</p> + +<p> +Function name examples: +</p> +<pre> + 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 +</pre> + + +<H2>Writing a Device Driver</H2> + +<p> +XXX to do +</p> + + + +<H2>Making a New Mesa Release</H2> + +<p> +These are the instructions for making a new Mesa release. +</p> + +<p> +Prerequisites (later versions may work): +</p> +<ul> +<li> autoconf 2.50 +<li> automake 1.4-p2 +<li> libtool 1.4 +</ul> + +<p> +Be sure to do a "cvs update -d ." in the Mesa directory to +get all the latest files. +</p> + +<p> +Update the version definitions in src/version.h +</p> + +<p> +Create/edit the docs/RELNOTES-X.Y file to document what's new in the release. +Edit the docs/VERSIONS file too. +</p> + +<p> +Edit Make-config and change the MESA_MAJOR and/or MESA_MINOR versions. +</p> + +<p> +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. +</p> + +<p> +Remove the leading `dnl' from the line "dnl AM_MAINTAINER_MODE". +</p> + +<p> +Verify the version numbers near the top of configure.in +</p> + +<p> +Run "fixam -f" to disable automatic dependency tracking. +</p> + +<p> +Run the bootstrap script to generate the configure script. +</p> + +<p> +Edit Makefile.X11 and verify DIRECTORY is set correctly. The Mesa +sources must be in that directory (or there must be a symbolic link). +</p> + +<p> +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. +</p> + +<p> +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. +</p> + +<p> +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. +</p> + +<p> +Make the distribution files. From inside the Mesa directory: +<pre> + make -f Makefile.X11 lib_tar + make -f Makefile.X11 demo_tar + make -f Makefile.X11 lib_zip + make -f Makefile.X11 demo_zip +</pre> + +<p> +Copy the distribution files to a temporary directory, unpack them, +compile everything, and run some demos to be sure everything works. +</p> + +<p> +Upload the *.tar.gz and *.zip files to ftp.mesa3d.org +</p> + +<p> +Update the web site. +</p> + +<p> +Make an announcement on the mailing lists: +<em>m</em><em>e</em><em>s</em><em>a</em><em>3</em><em>d</em><em>-</em><em>d</em><em>e</em><em>v</em><em>@</em><em>l</em><em>i</em><em>s</em><em>t</em><em>s</em><em>.</em><em>s</em><em>f</em><em>.</em><em>n</em><em>e</em><em>t</em>, +<em>m</em><em>e</em><em>s</em><em>a</em><em>3</em><em>d</em><em>-</em><em>u</em><em>s</em><em>e</em><em>r</em><em>s</em><em>@</em><em>l</em><em>i</em><em>s</em><em>t</em><em>s</em><em>.</em><em>s</em><em>f</em><em>.</em><em>n</em><em>e</em><em>t</em> +and +<em>m</em><em>e</em><em>s</em><em>a</em><em>3</em><em>d</em><em>-</em><em>a</em><em>n</em><em>n</em><em>o</em><em>u</em><em>n</em><em>c</em><em>e</em><em>@</em><em>l</em><em>i</em><em>s</em><em>t</em><em>s</em><em>.</em><em>s</em><em>f</em><em>.</em><em>n</em><em>e</em><em>t</em> +</p> + + +<H2>Autoconf info</H2> + +<p> +In order to run the bootstrap script you'll need: +<p> +<pre> +autoconf 2.50 +automake 1.4-p5 +libtool 1.4 +</pre> + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Getting Mesa</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Downloading / Unpacking</H1> + +<p> +Mesa can be downloaded from the +<a href="http://www.sourceforge.net/projects/mesa3d" target="_parent"> +SourceForge download area</A>. +</p> + +<p> +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. +</p> + +<p> +Mesa is available in at least three archive formats: +</p> + +<pre> +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 +</pre> + +<p> +After unpacking you'll have these directories (and more): +</p> +<pre> +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 + +</pre> + +<p> +Proceed to <a href="install.html">compilation and installation +instructions</a>. +</p> + +<H1>GLUT</H1> + +<p> +Mesa 2.5 and later includes Mark Kilgard's GLUT library (GL Utility Toolkit). +GLUT is built automatically on systems which support it. +</p> +<p> +The GLUT tests, demos, examples, etc are not included, just the main library. +To obtain the latest complete release of GLUT please visit the +<a href="http://www.opengl.org/resources/libraries/glut.html" +target ="_parent">GLUT page</a> on www.opengl.org. +</p> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Environment Variables</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Environment Variables</H1> + +<p> +Mesa supports the following environment variables: +</p> +<ul> +<li>MESA_NO_ASM - if set, disables all assembly language optimizations +<li>MESA_NO_MMX - if set, disables Intel MMX optimizations +<li>MESA_NO_3DNOW - if set, disables AMD 3DNow! optimizations +<li>MESA_NO_SSE - if set, disables Intel SSE optimizations +<li>MESA_DEBUG - if set, error messages are printed to stderr +<li>MESA_NO_DITHER - if set, disables dithering, overriding glEnable(GL_DITHER) +</ul> + +<p> +The following environment variables are only applicable to the Xlib/X11 +software driver: +</p> +<ul> +<li>MESA_RGB_VISUAL - specifies the X visual and depth for RGB mode (X only) +<li>MESA_CI_VISUAL - specifies the X visual and depth for CI mode (X only) +<li>MESA_BACK_BUFFER - specifies how to implement the back color buffer (X only) +<li>MESA_GAMMA - gamma correction coefficients (X only) +<li>MESA_XSYNC - enable synchronous X behavior (for X debugging only) +<li>MESA_GLX_FORCE_CI - if set, force GLX to treak 8bpp visuals as CI visuals +<li>MESA_GLX_FX - set to either "fullscreen" for full-screen rendering, + "window" to render into a window, or "disable" to disable the Glide driver. +<li>MESA_GLX_FORCE_ALPHA - if set, forces RGB windows to have an alpha channel. +<li>MESA_GLX_DEPTH_BITS - specifies default number of bits for depth buffer. +</ul> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Mesa Extensions</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Mesa Extensions</H1> + +<p> +A number of extensions have been developed especially for Mesa. +The specifications follow. +</p> + + +<UL> +<LI><A HREF="MESA_agp_offset.spec">MESA_agp_offset.spec</A> +<LI><A HREF="MESA_copy_sub_buffer.spec">MESA_copy_sub_buffer.spec</A> +<LI><A HREF="MESA_packed_depth_stencil.spec">MESA_packed_depth_stencil.spec</A> +<LI><A HREF="MESA_pack_invert.spec">MESA_pack_invert.spec</A> +<LI><A HREF="MESA_pixmap_colormap.spec">MESA_pixmap_colormap.spec</A> +<LI><A HREF="MESA_release_buffers.spec">MESA_release_buffers.spec</A> +<LI><A HREF="MESA_resize_buffers.spec">MESA_resize_buffers.spec</A> +<LI><A HREF="MESA_set_3dfx_mode.spec">MESA_set_3dfx_mode.spec</A> +<LI><A HREF="MESA_sprite_point.spec">MESA_sprite_point.spec</A> (obsolete) +<LI><A HREF="MESA_trace.spec">MESA_trace.spec</A> (obsolete) +<LI><A HREF="MESA_window_pos.spec">MESA_window_pos.spec</A> +<LI><A HREF="MESA_ycbcr_texture.spec">MESA_ycbcr_texture.spec</A> +</UL> + + +</BODY> +</HTML> 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 @@ +<html> + +<head><title>Mesa FAQ</title></head> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + + +<center> +<h1>Mesa Frequently Asked Questions</h1> +Last updated: 27 April 2004 +</center> + +<br> +<br> +<h2>Index</h2> +<a href="#part1">1. High-level Questions and Answers</a> +<br> +<a href="#part2">2. Compilation and Installation Problems</a> +<br> +<a href="#part3">3. Runtime / Rendering Problems</a> +<br> +<a href="#part4">4. Developer Questions</a> +<br> +<br> +<br> + + + +<a name="part1"> +</a><h1><a name="part1">1. High-level Questions and Answers</a></h1> + +<h2><a name="part1">1.1 What is Mesa?</a></h2> +<p> +<a name="part1">Mesa is an open-source implementation of the OpenGL specification. +OpenGL is a programming library for writing interactive 3D applications. +See the </a><a href="http://www.opengl.org/">OpenGL website</a> for more +information. +</p> +<p> +Mesa 5.x supports the OpenGL 1.4 specification. +</p> + + +<h2>1.2 Does Mesa support/use graphics hardware?</h2> +<p> +Yes. Specifically, Mesa serves as the OpenGL core for the open-source +XFree86/DRI OpenGL drivers. See the <a href="http://dri.sf.net/">DRI +website</a> for more information. +</p> +<p> +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. +</p> + +<h2>1.3 What purpose does Mesa (software-based rendering) serve today?</h2> +<p> +Hardware-accelerated OpenGL implementations are available for most popular +operating systems today. +Still, Mesa serves at least these purposes: +</p> +<ul> +<li>Mesa is used as the core of the open-source XFree86/DRI hardware drivers. +</li> +<li>Mesa is quite portable and allows OpenGL to be used on systems + that have no other OpenGL solution. +</li> +<li>Software rendering with Mesa serves as a reference for validating the + hardware drivers. +</li> +<li>A software implementation of OpenGL is useful for experimentation, + such as testing new rendering techniques. +</li> +<li>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. +</li> +<li>Mesa's internal limits (max lights, clip planes, texture size, etc) can be + changed for special needs (hardware limits are hard to overcome). +</li> +</ul> + +<h2>1.4 How do I upgrade my DRI installation to use a new Mesa release?</h2> +<p> +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). +</p> +<p> +The DRI developers will incorporate the latest release of Mesa into the +DRI drivers when the time is right. +</p> +<p> +To upgrade, either look for a new release of <a href="http://www.xfree86.org" +target="_parent">XFree86</a> or visit the +<a href="http://dri.sf.net" target="_parent">DRI website</a> to see +if there's newer drivers. +</p> + + +<h2>1.5 Are there other open-source implementations of OpenGL?</h2> +<p> +Yes, SGI's <a href="http://oss.sgi.com/projects/ogl-sample/index.html" +target="_parent"> +OpenGL Sample Implemenation (SI)</a> 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. +</p> + +<p> +<a href="http://ogl-es.sourceforge.net" target="_parent">Vincent</a> is +an open-source implementation of OpenGL ES for mobile devices. + +<p> +<a href="http://www.dsbox.com/minigl.html" target="_parent">miniGL</a> +is a subset of OpenGL for PalmOS devices. + +<p> +<a href="http://fabrice.bellard.free.fr/TinyGL/" +target="_parent">TinyGL</a> is a subset of OpenGL. +</p> + +<p> +<a href="http://softgl.studierstube.org/" target="_parent">SoftGL</a> +is an OpenGL subset for mobile devices. +</p> + +<p> +<a href="http://chromium.sourceforge.net/" target="_parent">Chromium</a> +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. +</p> + + +<p> +There may be other open OpenGL implementations, but Mesa is the most +popular and feature-complete. +</p> + +<br> +<br> + + +<a name="part2"> +</a><h1><a name="part2">2. Compilation and Installation Problems</a></h1> + + +<h2><a name="part2">2.1 What's the easiest way to install Mesa?</a></h2> +<p> +<a name="part2">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. +</a></p> + + +<h2><a name="part2">2.2 Running <code>configure; make</code> Doesn't Work</a></h2> +<p> +<a name="part2">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 <b>old-style</b> makefile system is still included. +The old-style system uses good old traditional Makefiles. Try the following: +</a></p><pre><a name="part2"> cd Mesa-x.y.z + cp Makefile.X11 Makefile + make +</a></pre> +<a name="part2">You'll see a list of system configurations from which to choose. +For example: +</a><pre><a name="part2"> make linux-x86 +</a></pre> +<p> +<a name="part2">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). +</a></p> + +<h2><a name="part2">2.3 Mesa still doesn't compile</a></h2> +<p> +<a name="part2">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. +</a></p> + + +<h2><a name="part2">2.4 I get undefined symbols such as bgnpolygon, v3f, etc...</a></h2> +<p> +<a name="part2">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. +</a></p> + + +<h2><a name="part2">2.5 Where is the GLUT library?</a></h2> +<p> +<a name="part2">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. +</a></p> + + + +<h2><a name="part2">2.6 What's the proper place for the libraries and headers?</a></h2> +<p> +<a name="part2">On Linux-based systems you'll want to follow the +</a><a href="http://oss.sgi.com/projects/ogl-sample/ABI/index.html" +target="_parent">Linux ABI</a> standard. +Basically you'll want the following: +</p> +<ul> +<li>/usr/include/GL/gl.h - the main OpenGL header +</li><li>/usr/include/GL/glu.h - the OpenGL GLU (utility) header +</li><li>/usr/include/GL/glx.h - the OpenGL GLX header +</li><li>/usr/include/GL/glext.h - the OpenGL extensions header +</li><li>/usr/include/GL/glxext.h - the OpenGL GLX extensions header +</li><li>/usr/include/GL/osmesa.h - the Mesa off-screen rendering header +</li><li>/usr/lib/libGL.so - a symlink to libGL.so.1 +</li><li>/usr/lib/libGL.so.1 - a symlink to libGL.so.1.xyz +</li><li>/usr/lib/libGL.so.xyz - the actual OpenGL/Mesa library. xyz denotes the +Mesa version number. +</li><li>/usr/lib/libGLU.so - a symlink to libGLU.so.1 +</li><li>/usr/lib/libGLU.so.1 - a symlink to libGLU.so.1.3.xyz +</li><li>/usr/lib/libGLU.so.xyz - the OpenGL Utility library. xyz denotes the Mesa +version number. +</li></ul> +<p> +After installing XFree86 and the DRI drivers, some of these files +may be symlinks into the /usr/X11R6/ tree. +</p> +<p> +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. +</p> +<p> +The GLUT header and library should go in the same directories. +</p> +<br> +<br> + + +<a name="part3"> +</a><h1><a name="part3">3. Runtime / Rendering Problems</a></h1> + +<h2><a name="part3">3.1 Rendering is slow / why isn't my graphics hardware being used?</a></h2> +<p> +<a name="part3">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). +</a></p> +<p> +<a name="part3">What you really want is a DRI or NVIDIA (or another vendor's OpenGL) driver +for your particular hardware. +</a></p> +<p> +<a name="part3">You can run the <code>glxinfo</code> 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. +</a></p> +<p> +<a name="part3">If your DRI-based driver isn't working, go to the +</a><a href="http://dri.sf.net/" target="_parent">DRI website</a> for trouble-shooting information. +</p> + + +<h2>3.2 I'm seeing errors in depth (Z) buffering. Why?</h2> +<p> +Make sure the ratio of the far to near clipping planes isn't too great. +Look +<a href="http://www.sgi.com/software/opengl/advanced97/notes/node18.html" +target="_parent"> +here</a> for details. +</p> +<p> +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 +<code> glXChooseVisual</code> in your code. +</p> + + +<h2>3.3 Why Isn't depth buffering working at all?</h2> +<p> +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. +</p> +<p>Specifically, make sure <code>glutInitDisplayMode</code> is being called +with <code>GLUT_DEPTH</code> or <code>glXChooseVisual</code> is being +called with a non-zero value for GLX_DEPTH_SIZE. +</p> +<p>This discussion applies to stencil buffers, accumulation buffers and +alpha channels too. +</p> + + +<h2>3.4 Why does glGetString() always return NULL?</h2> +<p> +Be sure you have an active/current OpenGL rendering context before +calling glGetString. +</p> + + +<h2>3.5 GL_POINTS and GL_LINES don't touch the right pixels</h2> +<p> +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. +</p> + +<br> +<br> + + +<a name="part4"> +</a><h1><a name="part4">4. Developer Questions</a></h1> + +<h2><a name="part4">4.1 How can I contribute?</a></h2> +<p> +<a name="part4">First, join the Mesa3d-dev mailing list. That's where Mesa development +is discussed. +</a></p> +<p> +<a name="part4">The </a><a href="http://www.opengl.org/developers/documentation/specs.html" target="_parent"> +OpenGL Specification</a> is the bible for OpenGL implemention work. +You should read it. +</p> +<p>Most of the Mesa development work involves implementing new OpenGL +extensions, writing hardware drivers (for the DRI), and code optimization. +</p> + +<h2>4.2 How do I write a new device driver?</h2> +<p> +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. +</p> +<p> +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. +</p> +<p>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. +</p> +<p> +Joining the appropriate mailing lists and asking questions (and searching +the archives) is a good way to get information. +</p> + + +<h2>4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa and/or the DRI drivers?</h2> +<p> +The <a href="http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt" target="_parent">specification for the extension</a> +indicates that there are intellectual property (IP) and/or patent issues +to be dealt with. +</p> +<p>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). +</p> +<p> +Until we can get official permission to do so, this extension will not +be implemented in Mesa. +</p> + + +</body> +</html> 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 @@ +<html> + +<TITLE>Mesa fbdev/DRI Environment</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<center><H1>Mesa fbdev/DRI Drivers</H1></center> + + +<H1>1. Introduction</H1> + +<p> +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. +</p> + +<p> +Basically, the <a href="http://dri.sf.net/">DRI</a> 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. +</p> + +<p> +DRI driver writers may find this simplified environment easier to work in, +compared to the full XFree86/DRI environment. +</p> + +<p> +Much of the work for this project has been done by Jon Smirl and +Keith Whitwell. +</p> + +<p> +To use fbdev/DRI, you'll need a Linux 2.4 or 2.6 kernel. +</p> + +<h3>Background Info</h3> + +<p> +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. +</p> + +<p> +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. +</p> + + + + +<h1>2. Compilation</h1> + +<h2>2.1 Compiling the DRM modules</h2> + +<p> +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: +</p> +<pre> + cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/dri login +</pre> +<p> +Press Enter/Return when prompted for a password. Then, +</p> +<pre> + cvs -d:pserver:anonymous@pdx.freedesktop.org:/cvs/dri co drm +</pre> + +<p> +Compile the DRM kernel modules: +</p> +<pre> + cd drm/linux + make +</pre> + +<p> +Note: you may need to be root in order to make a few symlinks. +</p> +<p> +When compilation is done, you should have at least the following +kernel modules: +</p> +<pre> + gamma.o + i810.o + i830.o + mach64.o + mga.o + r128.o + radeon.o + savage.o + sis.o + tdfx.o + via.o +</pre> +<p> +You'll probably want to copy/move them into your kernel module directory +(for example: <code>/lib/modules/2.4.18-14/kernel/drivers/char/drm/</code>). +</p> + + + +<h2>2.2 Compiling the Mesa drivers</h2> + +<p> +Begin by editing the <code>Mesa/configs/default</code> file to set +the <code>DRM_SOURCE_PATH</code> variable. +Set it to the location where the DRM module sources are located. +For example, if your current directory in step 2.1 was <code>/home/fred/</code> +set DRM_SOURCE_PATH to <code>/home/fred/drm</code> +</p> + +<p> +Next, assuming you're starting with a fresh Mesa CVS checkout, +do the following: +</p> +<pre> + make linux-solo +</pre> + +<p> +If you previously built the source tree, run <code>make realclean</code> +first to remove the old object files. +</p> + +<p> +When this is finished, check the <code>Mesa/lib/</code> directory +to verify that the following files were made: +</p> + +<ul> +<li><code>libGL.so.1.2</code> - the client-side OpenGL library + (and a few symlinks to it). +<li><code>libGLU.so.1.1</code> - the GLU library (and a few symlinks to it). +<li><code>libglut.so.3.7</code> - the GLUT library (and a few symlinks to it). +<li><code>mga_dri.so</code> - DRI driver for Matrox G200/G400 cards. +<li><code>r128_dri.so</code> - DRI driver for ATI Rage 128 cards. +<li><code>r200_dri.so</code> - DRI driver for ATI R200 Radeon cards. +<li><code>radeon_dri.so</code> - DRI driver for original ATI Radeon cards. +<li><code>i810_dri.so</code> - DRI driver for Intel i810/i815 chips. +<li><code>i830_dri.so</code> - DRI driver for Intel i830/i845 chips. +<li><code>mga_dri.so</code> - DRI driver for Matrox G200/G400 cards. +<li><code>sis_dri.so</code> - DRI driver for SIS cards. +<li><code>tdfx_dri.so</code> - DRI driver for 3dfx Voodoo 3/4/5 cards. +<li><code>gamma_dri.so</code> - DRI driver for 3Dlabs gamma cards. +<li><code>fb_dri.so</code> - software-only fbdev driver. +<li><code>miniglx.conf</code> - configuration file for the MiniGLX interface +</ul> + + +<h1>3. Using fbdev/DRI</h1> + +<p> +If XFree86 is currently running, exit/stop the X server so you're +working from the console. +</p> + + +<h2>3.1 Load Kernel Modules</h2> + +<p> +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). +</p> + + +<p> +If you have ATI Radeon/R200 hardware, run as root: +</p> +<pre> + modprobe agpgart # the AGP GART module + modprobe radeonfb # the Radeon fbdev driver + modprobe radeon # the Radeon DRI kernel module +</pre> + +<p> +If you have ATI Rage 128 hardware, run as root: +</p> +<pre> + modprobe agpgart # the AGP GART module + modprobe aty128fb # the Rage 128 fbdev driver + modprobe r128 # the Rage 128 DRI kernel module +</pre> + +<p> +If you have Matrox G200/G400 hardware, run as root: +</p> +<pre> + modprobe agpgart # the AGP GART module + modprobe mgafb # the Matrox fbdev driver + modprobe mga # the Matrox DRI kernel module +</pre> + +<p> +Then run <code>lsmod</code> to be sure the modules are loaded. +For a Radeon card, you should see something like this: +</p> +<pre> +Module Size Used by Not tainted +radeon 110308 0 (unused) +radeonfb 21900 0 (unused) +agpgart 43072 1 +</pre> + + + +<h2>3.2 Configuration File</h2> + +<p> +The <code>Mesa/lib/miniglx.conf</code> file should be installed +in <code>/etc/</code>. +</p> + +<p> +Edit <code>/etc/miniglx.conf</code> to be sure it's set up correctly +for your hardware. +Comments in the file explain the options. +</p> + + +<h2>3.3 Running fbdev/DRI Programs</h2> + +<p> +Make sure your LD_LIBRARY_PATH environment variable is set to the +<code>Mesa/lib/</code> directory. +</p> + +<p> +Change to the <code>Mesa/progs/miniglx/</code> directory and +start the sample_server program in the background: +</p> +<pre> + ./sample_server & +</pre> + +<p> +Then try running the <code>miniglxtest</code> program: +</p> +<pre> + ./miniglxtest +</pre> +<p> +You should see a rotating quadrilateral which changes color as it rotates. +It will exit automatically after a bit. +</p> + +<p> +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. +</p> + + + +<h1>4.0 Troubleshooting</h1> + +<p> +If you try to run miniglxtest and get the following: +</p> +<pre> + [miniglx] failed to probe chipset + connect: Connection refused + server connection lost +</pre> +<p> +It means that the sample_server process is not running. +</p> + + + + +<h1>5.0 Programming Information</h1> + +<p> +The full OpenGL API is available with fbdev/DRI. +</p> + +<p> +OpenGL/Mesa is interfaced to fbdev via the <a href="MiniGLX.html">MiniGLX</a> +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. +</p> + +<p> +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. +</p> + +<p> +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 <code>GL/miniglx.h</code> header file for details. +</p> + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Games</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Games</H1> + + +<ul> + <li><a href="http://www.psc.edu/%7Esmp/a3d/">Asteroids3D</a> - 3D asteroids game + </li><li><a href="http://evlweb.eecs.uic.edu/aej/AndyBattalion.html" target="_parent">Battalion</a> + - battle game + </li><li><a href="http://bzflag.sourceforge.net/" target="_parent">BZFLAG</a> - 3-D tank + battle game + </li><li><a href="http://www.speakeasy.org/%7Emorse/copter-commander">Copter Commander</a> - 2d multiplayer side scroller + </li><li><a href="http://www.crystalspace.org/" target="_parent">CrystalSpace</a> - Free + 3d game engine + </li><li><a href="http://www.afn.org/%7Ecthugha/" target="_parent">Cthugha</a> - music-sync'ed + graphical effects + </li><li><a href="http://www.sics.se/dive/" target="_parent">DIVE</a> - Distributed Interactive + Virtual Environment + </li><li><a href="http://www.newdoom.com/doomlegacy/" target="_parent">Doom Legacy</a> + - an OpenGL port of id software's popular game, Doom + </li><li><a href="http://www.asimov.de/intern_dropit.html" target="_parent">DropIt</a> - 3-D tetris game + </li><li><a href="http://www.flightgear.org/" target="_parent">Flight Gear</a> - Flight + simulator + </li><li><a href="http://freetrek.linuxgames.com/" target="_parent">Free Trek</a> - Star + Trek battle simulator + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">Gepetto</a> - Dance Choreography + </li><li><a href="http://glchess.sourceforge.net/" target="_parent">GLChess</a> - chess game + </li><li><a href="http://heretic.linuxgames.com/" target="_parent">GLHeretic</a> - Heretic + for Linux + </li><li><a href="http://glider3d.free.fr/" target="_parent">Glider3D</a> - flight simulator + </li><li><a href="http://www.gltron.org/" target="_parent">glTron</a> - Tron lightcycles + game + </li><li><a href="http://gracer.sourceforge.net/" target="_parent">GRacer</a> - 3D Motor + Sports Simulator + </li><li><a href="http://jongl.home.pages.de/" target="_parent">JONGL</a> - Juggling simulator + </li><li><a href="http://samba.anu.edu.au/KnightCap/" target="_parent">KnightCap</a> - + chess game + </li><li><a href="http://www.hackcraft.de/games/linwarrior_3d/">LinWarrior 3D</a> - A Battle Mech Simulator + </li><li><a href="http://www.nada.kth.se/%7Ef96-lfo/lunar/" target="_parent">Lunar Lander + 2000</a> - 3D version of the classis lunar lander game + </li><li><a href="http://www.majik3d.org/" target="_parent">Majik 3D</a> - an online role-playing + world + </li><li><a href="http://www.pobox.com/%7Eshankel/opentrek.html" target="_parent">OpenTrek</a> + - Super Star Trek + </li><li><a href="http://www.idsoftware.com/" target="_parent">Quake(2,3)</a> - the popular + games from id software + </li><li><a href="http://torcs.free.fr/indexm.html" target="_parent">TORCS</a> - car racing + simulator + </li><li><a href="http://www.woodsoup.org/projs/tux_aqfh" target="_parent">TUX-AQFH</a> + - Tux the Penguin - a Quest for Herring + </li><li><a href="http://mordred.8m.com/voidrunner/" target="_parent">Void Runner</a> + - freeware arcade style game + </li><li><a href="http://xracer.annexia.org/" target="_parent">XRacer</a> - Free spaceship + racing game, similar to Wipeout +</li></ul> + + +</body></html>
\ 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 @@ +<HTML> + +<TITLE>Mesa glFBDev Driver</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<center><H1>Mesa glFBDev Driver</H1></center> + + +<H1>1. Introduction</H1> + +<p> +The GLFBDev driver interface allows one to do OpenGL rendering into a +framebuffer managed with the Linux's fbdev interface. +</p> + +<p> +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. +</p> + +<p> +Note, only software rendering is supported; there is no hardware +acceleration. +</p> + + +<p> +The GL/glfbdev.h header file defines the glFBDev interface. +</p> + +<p> +The progs/fbdev/glfbdevtest.c demonstrates how to use the glFBDev interface. +</p> + +<p> +For more information about fbdev, see the +<a href="http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html" target="_parent"> +Framebuffer Howto</a> +</p> + + +<h1>2. Compilation</h1> + +<p> +To compile Mesa with support for the glFBDev interface: +<pre> + XXX todo +</pre> + +<p> +When compilation is finished look in progs/glfbdev/ for the glfbdevtest demo. +</p> + +</p> +xxx todo +</p> + + +<h1>3. Compiling and linking glFBDev programs</h1> + +<p> +xxx todo +</p> + + + +<h1>4. Running glFBDev programs</h1> + +<p> +First, you need to have a working fbdev environment. +See the +<a href="http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html" target="_parent"> +Framebuffer Howto</a> for information. +</p> + +<p> +Programs must be run with root permission. +</p> + +</p> + + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>SGI GLU</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>SGI SI GLU</H1> + +(Silicon Graphics, Inc. Sample Implementation of the OpenGL Utility library) + +<p> +SGI open-sourced their OpenGL Sample Implementation (SI) in January, 2000. +This includes the GLU library. +</p> + +<p> +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. +</p> + +<p> +The new SI GLU library code is included in the Mesa package. +You don't have to download it separately. +</p> + + +<p> +<b>Olivier Michel</b> has made Linux RPMs of GLU for i386 and PowerPC. +You can download them from the +<a href="http://www.sourceforge.net/project/showfiles.php?group_id=3" +target="_parent">download area</a> under <b>Miscellaneous</b>. +</p> + +<p> +Visit the <a href="http://oss.sgi.com/projects/ogl-sample/" target="_parent"> +OpenGL Sample Implementation home page</a> for more information about the SI. +</p> + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Help Wanted</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Help Wanted</H1> + +<p> +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. +</p> + +<ul> +<li>Windows 98/NT build/driver maintenance and testing (Karl Schultz has been + doing a great job of this lately) +<li>DOS/DJGPP build/driver maintenance and testing +<li>GGI driver/build maintenance and testing +<li>GNU autoconfig/libtool maintenance (esp. on non-Linux systems) +<li>x86, SSE, 3DNow! and SPARC assembly language programming +<li>Implement WGL font functions in the WGL interface code +<li>Implement off-screen bitmap rendering support in the WGL interface code +<li>Help with writing/testing the new NV_fragment_program extension code +<li>Implement the ARB_vertex/fragment extensions +<li>Download/compile/test Mesa and report any bugs found +</ul> + + +<p> +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. +</p> + +</p> +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. +</p> + +<p> +Unfortunately, all the easy work in Mesa was done years ago. Nowadays, the +work is rather complicated and not suited to beginners. +</p> + +<p> +If you're contribution code to the Mesa library itself: +<p> +<ol> +<li>Try to write clean code (uniform indentation, comments, meaningful + identifiers, etc). It must be readable and maintainable! + +<li>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. +</ol> + + +</BODY> +</HTML> 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 @@ +<html> + +<title>Mesa Home Page</title></head> + + +<frameset rows="50,100% " border="1" framespacing="1" frameborder="yes"> +<frame src="banner.html" name="BannerFrame" scrolling="no" marginwidth="1" marginheight="1" resize=""> +<frameset cols="28%,72% " border="1" framespacing="1" frameborder="yes"> +<frame src="contents.html" name="ContentsFrame" marginwidth="2" marginheight="1" resize=""> +<frame src="news.html" name="MainFrame" marginwidth="3" marginheight="1" resize=""> +</frameset> +</frameset> + +<noframes> + +<BODY> + +<P> + +</body> + +</noframes> +</html>
\ 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 @@ +<HTML> + +<TITLE>Compilation and Installation</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + + +<H1>Compilation and Installation</H1> + +<ol> +<li><a href="#unix-x11">Unix / X11</a> +<li><a href="#windows">Windows</a> +<li><a href="#vms">VMS</a> +<li><a href="#other">Other</a> +</ol> + + + +<a name="unix-x11"> +<H2>1. Unix/X11 Compilation and Installation</H1> + +<p> +Mesa uses a rather conventional Makefile system. +A GNU autoconf/automake system used to be included, but was discarded +in Mesa 5.1 because: +</p> +<ul> +<li>It seldom worked on IRIX, Solaris, AIX, etc. +<li>It was very compilicated +<li>Nobody maintained it +<li>libtool was just too weird +</ul> +<p> +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. +</p> + +<p> +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 <code>configs/</code> which +has an individual file for each configuration. +One of the configs gets copied to <code>configs/current</code>, which +is then included by all Makefiles. +</p> + + +<h3>1.1 Compilation</h3> + +<p> +Note: if you've obtained Mesa through CVS, do this first: +</p> +<pre> + cd Mesa + chmod a+x bin/mklib +</pre> + +<p> +Just type <b>make</b> 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: +</p> +<pre> + make linux-x86 +</pre> +<p> +If you want to rebuild for a different configuration run +<code>make realclean</code> before rebuilding. +</p> + + +<h3>1.2 The libraries</h3> + +<p> +When compilation has finished, look in the top-level <b>lib/</b> directory. +You'll see a set of library files similar to this: +</p> +<pre> +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* +</pre> + +<p> +<b>libGL</b> is the main OpenGL library (i.e. Mesa). +<br> +<b>libGLU</b> is the OpenGL Utility library. +<br> +<b>libglut</b> is the GLUT library. +<br> +<b>libGLw</b> is the Xt/Motif OpenGL drawing area widget library. +<br> +<b>libOSMesa</b> is the OSMesa (Off-Screen) interface library. +</p> + + +<h3>1.3 Running the demos</h3> + +<p> +If you downloaded/unpacked the MesaDemos-x.y.z.tar.gz archive or +obtained Mesa from CVS, the <b>progs/</b> directory will contain a +bunch of demonstration programs. +</p> + +<p> +Before running a demo, you may have to set an environment variable +(such as <b>LD_LIBRARY_PATH</b> on Linux) to indicate where the +libraries are located. For example: +<p> +<blockquote> +<b>cd</b> into the Mesa <b>lib/</b> directory. +<br> +<b>setenv LD_LIBRARY_PATH ${cwd}</b> (if using csh or tcsh shell) +<br> +or, +<br> +<b>export LD_LIBRARY_PATH=${PWD}</b> (if using bash or sh shell) +</blockquote> + +<p> +Next, change to the Mesa/demos/ directory: +</p> +<blockquote> +<b>cd ../progs/demos</b> +</blockquote> + +<p> +Run a demo such as gears: +</p> +<blockquote> +<b>./gears</b> +</blockquote> + +<p> +If this doesn't work, try the <b>Mesa/progs/xdemos/glxinfo</b> program +and see that it prints the expected Mesa version number. +</p> + +<p> +If you're using Linux or a similar OS, verify that the demo program is +being linked with the proper library files: +</p> +<blockquote> +<b>ldd gears</b> +</blockquote> + +<p> +You should see something like this: +</p> +<pre> + 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) +</pre> + +<p> +Retrace your steps if this doesn't look right. +</p> + + +<H3>1.4 Installing the header and library files</H3> + +<p> +The standard location for the OpenGL header files on Unix-type systems is +in <code>/usr/include/GL/</code>. +The standard location for the libraries is <code>/usr/lib/</code>. +For more information see, the +<a href="http://oss.sgi.com/projects/ogl-sample/ABI/" target="_parent"> +Linux/OpenGL ABI specification</a>. +</p> + +<p> +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 +<code>/usr/local/include/GL/</code> and <code>/usr/local/lib/</code>. +</p> + +<p> +To install Mesa's headers and libraries, run <code>make install</code> +You'll be prompted to enter alternative directories for the headers +and libraries. +</p> + +<p> +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. +</p> + + + +<a name="windows"> +<H2>2. Windows Compilation and Installation</H1> + +<p> +Please see the <a href="README.WIN32">README.WIN32</a> file. +</p> + + + + +<a name="vms"> +<H2>3. VMS Compilation and Installation</H1> + +<p> +Please see the <a href="README.VMS">README.VMS</a> file. +</p> + + + + +<a name="other"> +<H2>4. Other systems</H1> + +<p> +Documentation for other environments (some may be very out of date): +</p> + +<UL> +<LI><A HREF="README.GGI">README.GGI</A> - GGI +<LI><A HREF="README.3DFX">README.3DFX</A> - 3Dfx/Glide driver +<LI><A HREF="README.AMIWIN">README.AMIWIN</A> - Amiga Amiwin +<LI><A HREF="README.BEOS">README.BEOS</A> - BeOS +<LI><A HREF="README.D3D">README.D3D</A> - Direct3D driver +<LI><A HREF="README.DJ">README.DJ</A> - DJGPP +<LI><A HREF="README.LYNXOS">README.LYNXOS</A> - LynxOS +<LI><A HREF="README.MINGW32">README.MINGW32</A> - Mingw32 +<LI><A HREF="README.NeXT">README.NeXT</A> - NeXT +<LI><A HREF="README.OpenStep">README.OpenStep</A> - OpenStep +<LI><A HREF="README.OS2">README.OS2</A> - OS/2 +<LI><A HREF="README.WINDML">README.WINDML</A> - WindML +</UL> + + + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Mesa Introduction</TITLE> + +<BODY text="#000000" bgcolor="#55bbff"> + +<H1>Introduction</H1> + +<p> +Mesa is a 3-D graphics library with an API which is very similar to +that of <a href="http://www.opengl.org/" target="_parent">OpenGL</a>.* +To the extent that Mesa utilizes the OpenGL command syntax or state +machine, it is being used with authorization from <a +href="http://www.sgi.com/" target="_parent">Silicon Graphics, +Inc.</a>(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. +</p> + +<p> +Please do not refer to the library as <em>MesaGL</em> (for legal +reasons). It's just <em>Mesa</em> or <em>The Mesa 3-D graphics +library</em>. <br> +</p> + +<p> +* OpenGL is a trademark of <a href="http://www.sgi.com/" +target="_parent">Silicon Graphics Incorporated</a>. +</p> + + +<H1>Project History</H1> + +<p> +The Mesa project was founded by me, Brian Paul. Here's a short history +of the project. +</p> + +<p> +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 <em>VOGL</em> library which emulated a subset of IRIS GL. +I had been programming with IRIS GL since 1991. +</p> + +<p> +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. +</p> + +<p> +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 <em>"Open"</em> or <em>"GL"</em> 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. +</p> + +<p> +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. +</p> + + +<p> +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 <a href="http://www.ssec.wisc.edu/%7Ebillh/vis.html" target="_parent">Vis5D</a> project. +</p><p> +October 1996: Mesa 2.0 is released. It implementes the OpenGL 1.1 specification. +</p> + +<p> +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. +</p> + +<p> +September 1998: Mesa 3.0 is released. It's the first publicly-available +implementation of the OpenGL 1.2 API. +</p> + +<p> +March 1999: I attend my first OpenGL ARB meeting. I contribute to the +development of several official OpenGL extensions over the years. +</p> + +<p> +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. +</p> + +<p> +October 2001: Mesa 4.0 is released. +It implements the OpenGL 1.3 specification. +</p> + + +<p> +November 2001: I cofound <a href="http://www.tungstengraphics.com" target="_parent"> +Tungsten Graphics, Inc.</a> 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. +</p> + +<p> +November 2002: Mesa 5.0 is released. +It implements the OpenGL 1.4 specification. +</p> + +<p> +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. +</p> + + +<p> +Ongoing: Mesa is used as the core of many hardware OpenGL drivers for XFree86 +within the +<A href="http://dri.sourceforge.net/" target="_parent">DRI project</A>. +I continue to enhance Mesa with new extensions and features. +</p> + + + +<H1>Major Versions</H1> + +<p> +This is a summary of the major versions of Mesa. Note that Mesa's major +version number tracks OpenGL's minor version number. +</p> + + +<H2>Version 6.x features</H2> +<p> +Version 6.x of Mesa implements the OpenGL 1.5 API with the following +extensions incorporated as standard features: +</p> +<ul> +<li>GL_ARB_occlusion_query +<li>GL_ARB_vertex_buffer_object +<li>GL_EXT_shadow_funcs +</ul> +<p> +Also note that several OpenGL tokens were renamed in OpenGL 1.5 +for the sake of consistency. The old names will still be valid. +</p> +<pre> +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 +</pre> +<p> +See the +<a href="http://www.opengl.org/documentation/spec.html" target="_parent"> +OpenGL specification</a> for more details. +</p> + + + +<H2>Version 5.x features</H2> +<p> +Version 5.x of Mesa implements the OpenGL 1.4 API with the following +extensions incorporated as standard features: +</p> +<ul> +<li>GL_ARB_depth_texture +<li>GL_ARB_shadow +<li>GL_ARB_texture_env_crossbar +<li>GL_ARB_texture_mirror_repeat +<li>GL_ARB_window_pos +<li>GL_EXT_blend_color +<li>GL_EXT_blend_func_separate +<li>GL_EXT_blend_logic_op +<li>GL_EXT_blend_minmax +<li>GL_EXT_blend_subtract +<li>GL_EXT_fog_coord +<li>GL_EXT_multi_draw_arrays +<li>GL_EXT_point_parameters +<li>GL_EXT_secondary_color +<li>GL_EXT_stencil_wrap +<li>GL_EXT_texture_lod_bias (plus, a per-texture LOD bias parameter) +<li>GL_SGIS_generate_mipmap +</ul> + + +<H2>Version 4.x features</H2> + +<p> +Version 4.x of Mesa implements the OpenGL 1.3 API with the following +extensions incorporated as standard features: +</p> + +<ul> +<li>GL_ARB_multisample +<li>GL_ARB_multitexture +<li>GL_ARB_texture_border_clamp +<li>GL_ARB_texture_compression +<li>GL_ARB_texture_cube_map +<li>GL_ARB_texture_env_add +<li>GL_ARB_texture_env_combine +<li>GL_ARB_texture_env_dot3 +<li>GL_ARB_transpose_matrix +</ul> + +<H2>Version 3.x features</H2> + +<p> +Version 3.x of Mesa implements the OpenGL 1.2 API with the following +features: +</p> +<ul> +<li>BGR, BGRA and packed pixel formats +<li>New texture border clamp mode +<li>glDrawRangeElements() +<li>standard 3-D texturing +<li>advanced MIPMAP control +<li>separate specular color interpolation +</ul> + + +<H2>Version 2.x features</H2> +<p> +Version 2.x of Mesa implements the OpenGL 1.1 API with the following +features. +</p> +<ul> +<li>Texture mapping: + <ul> + <li>glAreTexturesResident + <li>glBindTexture + <li>glCopyTexImage1D + <li>glCopyTexImage2D + <li>glCopyTexSubImage1D + <li>glCopyTexSubImage2D + <li>glDeleteTextures + <li>glGenTextures + <li>glIsTexture + <li>glPrioritizeTextures + <li>glTexSubImage1D + <li>glTexSubImage2D + </ul> +<li>Vertex Arrays: + <ul> + <li>glArrayElement + <li>glColorPointer + <li>glDrawElements + <li>glEdgeFlagPointer + <li>glIndexPointer + <li>glInterleavedArrays + <li>glNormalPointer + <li>glTexCoordPointer + <li>glVertexPointer + </ul> +<li>Client state management: + <ul> + <li>glDisableClientState + <li>glEnableClientState + <li>glPopClientAttrib + <li>glPushClientAttrib + </ul> +<li>Misc: + <ul> + <li>glGetPointer + <li>glIndexub + <li>glIndexubv + <li>glPolygonOffset + </ul> +</ul> + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Libraries and Toolkits</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Libraries and Toolkits</H1> + +<ul> +<li><a href="http://mrpowers.com/Apprentice/">Apprentice</a> - free OpenInventor work-alike +<li><a href="http://www.coin3d.org/coin.html" target="_parent">Coin</a> - OSS Open Inventor clone +<li><a href="http://www.softintegration.com/products/toolkit/opengl/" target="_parent">Ch</a> - OpenGL bindings for the Ch C/C++ interpreter +<li><a href="http://www.cfdrc.com/FOX/fox.html" target="_parent">FOX</a> - GUI Library +<li><a href="http://www.jausoft.com/gl4java.html" target="_parent">GL4Java</a> - a Java wrapper for OpenGL +<li><a href="http://www.student.oulu.fi/%7Ejlof/gtkglarea/" target="_parent">GtkGLArea</a> - OpenGL Gtk widget +<li><a href="http://www.ece.ucdavis.edu/%7Ekenelson/gtk-glarea/" target="_parent">GtkGLArea--</a> - OpenGL Gtk-- widget for C++ +<li><a href="http://gtkpas.sourceforge.net/" target="_parent">GTKpas</a> - OpenGL Gtk widget for <a href="http://www.freepascal.org/" target="_parent">FreePascal</a> +<li><a href="http://freeglut.sourceforge.net/" target="_parent">FreeGLUT</a> - a GLUT work-alike +<li><a href="http://math.nist.gov/f90gl" target="_parent">Fortran77/90 bindings for OpenGL and Mesa</a> - by William Mitchell +<li><a href="http://glow.sourceforge.net/" target="_parent">GLOW</a> - a GUI toolkit for GLUT and OpenGL +<li><a href="http://www.nigels.com/glt/">Glt</a> - an OpenGL C++ toolkit +<li><a href="http://www.opengl.org/developers/documentation/glut/" target="_parent">GLUT (GL Utility Toolkit)</a> - by Mark Kilgard +<li><a href="http://atrey.karlin.mff.cuni.cz/%7E0rfelyus/guileGL/" target="_parent">GuileGL</a> - OpenGL and GtkGLArea language bindings for Guile +<li><a href="http://www.rsinc.com/" target="_parent">IDL</a> - Interactive Data Language +<li><a href="http://www.newplanetsoftware.com/jx/" target="_parent">JX</a> - C++ application framework and GUI library +<li><a href="http://www.vrs3d.org/" target="_parent">MAM/VRS</a> - object-oriented toolkit for 3D graphics +<li><a href="http://www.jwdt.com/%7Epaysan/bigforth.html" target="_parent">MINOS</a> - GUI library +<li><a href="http://sourceforge.net/project/?group_id=2795" target="_parent">OglCLib</a> - C++ wrapper for OpenGL +<li><a href="http://oss.sgi.com/projects/inventor" target="_parent"> Open Inventor</a> - the Open Inventor toolkit from SGI +<li><a href="http://www.tgs.com/" target="_parent">Open Inventor</a> - the Open Inventor toolkit from Template Graphics Software, Inc. +<li><a href="http://openrm.sourceforge.net/" target="_parent">OpenRM</a> +- Open Source, multithreaded, parallel scene graph API +<li><a href="http://www.opensg.org/OpenSGPLUS/index.EN.html" target="_parent"> +Open SG PLUS</a> - a scene-graph library +<li><a href="http://www.openscenegraph.org/" target="_parent">Open Scene Graph +</a> - a scene-graph library +<li><a href="http://www.openvrml.org/" target="_parent">OpenVRML</a> +- a VRML parsing/display library with "lookat" - an example VRML browser +<li><a href="http://plib.sourceforge.net/" target="_parent">PLIB</a> - A collection of portable games libraries, including an OpenGL GUI and a simple Scene Graph API +<li><a href="ftp://ftp.troll.no/contest/Pryan-1.2.tar.gz" target="_parent">Pryan</a> - an OpenInventor-like toolkit +<li><a href="http://starship.python.net:9673/crew/da/Code/PyOpenGL" target="_parent">PyOpenGL</a> - OpenGL interface for Python +<li><a href="http://www.quesa.org/" target="_parent">Quesa</a> - QuickDraw3D-compatible library based on OpenGL, Mesa or Direct3D +<li><a href="http://www.mesa3d.org/brianp/repgl.txt" target="_parent">repGL</a> - IRIS GL emulated with OpenGL +<li><a href="http://www.scitechsoft.com/dp_mgl.html" target="_parent">SciTech MGL</a> - A multiplatform (Windows, Linux, OS/2, DOS, QNX, SMX, RT-Target & more) graphics library +<li><a href="http://sgl.sourceforge.net/" target="_parent">SGL</a> - a 3D Scene Graph Library +<li><a href="http://www.lal.in2p3.fr/SI/SoFree/" target="_parent">SoFree</a> - a free implementation of Open Inventor +<li><a href="http://togl.sourceforge.net/" target="_parent">Togl</a> - Tcl/Tk widget for OpenGL +<li><a href="http://mesa3d.sourceforge.net/notfound.html">VLE</a> - Virtual Reality Toolkit +<li><a href="http://www.int.com/" target="_parent">View3D Widget</a> - 3-D GUI widget +<li><a href="http://www.vtk.org/" target="_parent">VTK</a> - Visualization Toolkit +<li><a href="http://home.earthlink.net/%7Erzeh/YAJOGLB/doc/YAJOGLB.html" target="_parent">YAJOGL</a> - Yet Another Java GL Binding. +</ul> + + +</body></html>
\ 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 @@ +<HTML> + +<TITLE>License / Cppyright Information</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>License / Copyright Information</H1> + +<p> +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. +</p> +<p> +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: +</p> + +<pre> +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. +</pre> + + +<H1>Attention, Contributors</H1> + +<p> +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. +</p> + +<pre> +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 +</pre> + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Mesa Mailing Lists</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Mailing Lists</H1> + + +<p>There are four Mesa mailing lists:</p> +<ul> +<li><b>mesa3d-users</b> - intended for users of the Mesa library. +Newbie questions are appropriate, but please try reading the Mesa documentation first. +</li><li><b>mesa3d-dev</b> - intended for developers of the Mesa library. +This is not for beginners. +</li><li><b>mesa3d-cvs</b> - CVS check-in messages are sent to this list. +This is useful for tracking ongoing development changes. +</li><li><b>mesa3d-announce</b> - announcements of new Mesa versions are sent to this list. +</li></ul> + +<p> +To subscribe or unsubscribe, go to the +<a href="http://www.sourceforge.net/mail/?group_id=3" target="_parent"> +SourceForge lists page.</a> +</p> + +<p>The mailing lists are managed by SourceForge. If you're having trouble +with the mailing lists please contact the SourceForge administrators for help.</p> + +<p>Archives of the old Mesa mailing list which was hosted by unicamp.br +are available <a href="http://groups.yahoo.com/group/mesa/messages/">here</a>.</p> + +<p> +Here are some other OpenGL-related forums you might find useful: +</p> + +<p> +Usenet newsgroups: +<ul> +<li>comp.graphics.algorithms +<li>comp.graphics.api.opengl +<li>comp.os.linux.x +</ul> +</p> + +<p> +<a href="http://www.opengl.org/">OpenGL discussion forums</A> at www.opengl.org +</p> + +</HTML> +</BODY> 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 @@ +<HTML> + +<TITLE>Function Name Mangling</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Function Name Mangling</H1> + +<p> +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 +<i>name mangling</i>. +This results in all the Mesa functions being prefixed with +<b>mgl</b> instead of <b>gl</b>. +</p> + +<p> +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. +</p> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Modelers, Renderers and Viewers</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Modelers, Renderers and Viewers</H1> + +<ul> + <li><a href="http://www.aqsis.com/" target="_parent">Aqsis</a> - a RenderMan compatible renderer</li> + <li><a href="http://www.ac3d.org/" target="_parent">AC3D</a> - 3-D modeler + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">ARCAD</a> - CAD program + </li><li><a href="http://www.mediascape.com/" target="_parent">Artstream</a> - provides + functionality like Corel Draw and Illustrator + </li><li><a href="http://www.blender.nl/" target="_parent">Blender</a> - 3-D animation + software + </li><li><a href="http://www.arq.net/%7Ekasten/demtools/" target="_parent">Demtools</a> + - Map viewer + </li><li><a href="http://www.holometric.de/dimension/" target="_parent">DIMENSION</a> + - freeform surface reconstruction + </li><li><a href="http://www.vectaport.com/vhclmaps/demviewer.html" target="_parent">demviewer</a> + - interactive terrain viewer + </li><li><a href="http://www.crc.ca/FreeWRL" target="_parent">FreeWRL</a> - VRML browser + </li><li><a href="http://www.geomview.org/" target="_parent">Geomview</a> - 3-D geometry + exploration + </li><li><a href="http://innovation3d.sourceforge.net/" target="_parent">Innovation3D</a> + - 3D modeling program + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html" target="_parent">KWRL</a> - VRML browser + </li><li><a href="http://www.vermontel.com/%7Ecmorley/vrml.html" target="_parent">LibVRML97/Lookat</a> + - VRML viewer + </li><li><a href="http://aig.cs.man.ac.uk/systems/Maverik/" target="_parent">Maverik</a> + - VR graphics and interaction system + </li><li><a href="http://www.swissquake.ch/chumb.alum-soft" target="_parent">MD2 Viewer</a> + - View .MD2 files + </li><li><a href="http://www.megacads.dlr.de/" target="_parent">MegaCads</a> + - Multiblock-Elliptic-Grid-Generation-And-CAD-System + </li><li><a href="http://www.swissquake.ch/chumbalum-soft/" target="_parent">MilkShape + 3D</a> - 3D modeler/animator + </li><li><a href="http://mindseye.sourceforge.net/" target="_parent">Mindseye</a> - Rendering/Modeling + Package + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">Moonlight Atelier</a> - modeling and rendering package + </li><li><a href="http://www.neuralvr.com/" target="_parent">Pansophica</a> - Virtual Reality web organizer + </li><li><a href="http://www.sim.no/reducer.html" target="_parent">Rational Reducer</a> + - polygon reduction tool + </li><li><a href="http://www.cs.kuleuven.ac.be/cwis/research/graphics/RENDERPARK/" target="_parent">RenderPark</a> + - photorealistic rendering + </li><li><a href="http://www.hardgeus.com/revolution" target="_parent">Revolution 3D Engine</a> + - .3ds rendering engine + </li><li><a href="http://www.dgp.toronto.edu/%7Emjmcguff/eversion/" target="_parent">sphereEversion</a> + - inside-out sphere visualization + </li><li><a href="http://www.cs.kuleuven.ac.be/cwis/research/graphics/3DOM/" target="_parent">3Dom</a> + - 3-D modeler + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">3D Studio file viewer</a> - by David Farrell + </li><li><a href="http://www.microform.se/" target="_parent">VARKON</a> - product engineering, + design, modeling + </li><li><a href="http://www.sim.no/vrmlview.html" target="_parent">VRMLview</a> - VRML + model viewer + </li><li><a href="http://www.iicm.edu/vrwave/" target="_parent">VRWave</a> - a VRML 2.0 + browser + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">VRweb</a> - VRML browser + </li><li><a href="http://www.csv.ica.uni-stuttgart.de/vrml/dune/" target="_parent">white_dune</a> + - graphical VRML97 Editor and animation tool + </li><li><a href="http://www.wings3d.org/" target="_parent">Wings 3D</a> - static 3D modeller + with VRML export. Uses SDL library. +</li></ul> + + +</body></html> 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 @@ +<HTML> + +<TITLE>Mesa News</TITLE> + +<BODY text="#000000" bgcolor="#55bbff"> + +<H1>News</H1> + + +<h2>December 9, 2004</h2> +<p> +Mesa 6.2.1 has been released. +This is a stable release which just fixes bugs since the 6.2 release. +</p> +<pre> + 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 +</pre> +<p> +The MD5 checksums are: +</p> +<pre> +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 +</pre> + + +<h2>October 2, 2004</h2> +<p> +Mesa 6.2 has been released. +This is a stable release which just fixes bugs since the 6.1 release. +</p> +<pre> + 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) +</pre> +<p> +The MD5 checksums are: +</p> +<pre> +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 +</pre> + + +<h2>August 18, 2004</h2> +<p> +Mesa 6.1 has been released. +This is a new development release (version 6.2 will be a stabilization +release). +</p> +<pre> + 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 <format> 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) +</pre> +The MD5 checksums are: +</p> +<pre> +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 +</pre> + + + +<h2>April 2, 2004</h2> + +<p> +Mesa 6.0.1 has been released. +This release basically just fixes bugs since the 6.0. release. +</p> +<pre> + 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 +</pre> +The MD5 checksums are: +</p> +<pre> +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 +</pre> + + + +<h2>January 16, 2004</h2> + +<p> +Mesa 6.0 has been released. This is a stabilization of the 5.1 release +and primarily just incorporates bug fixes. +</p> +<pre> + 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 +</pre> + + + +<h2>December 28, 2003</h2> + +<p> +The Mesa CVS server has been moved to <a href="http://www.freedesktop.org" +target="_parent"> +freedesktop.org</a> because of problems with SourceForge's anonymous +CVS service. +</p> + +<p>Please see the <a href="cvs_access.html">CVS access page</a> for details. +</p> + + +<h2>December 17, 2003</h2> + +<p> +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. +</p> +<pre> + 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) +</pre> + +The MD5 checksums are: +</p> +<pre> +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 +</pre> + + +<H2>November 12, 2003</H2> + +<p> +New Mesa 5.0.2 tarballs have been uploaded to SourceForge which fix a +number of automake/libtool problems. +</p> +<p> +The new MD5 checksums are: +</p> +<pre> +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 +</pre> + + + +<h2>September 5, 2003</h2> + +<p> +Mesa 5.0.2 has been released. This is a stable, bug-fix release. +</p> +<pre> + 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 +</pre> + + + +<h2>June 2003</h2> + +<p> +Mesa's directory tree has been overhauled. +Things are better organized now with some thought toward future needs. +</p> +<p> +In CVS, the latest Mesa 5.1 development code is now rooted under the +<b>Mesa-newtree/</b> directory. The old top-level <b>Mesa/</b> directory +holds the Mesa 5.0.x code which will be abandoned at some point. +</p> + + + +<h2>March 30, 2003</h2> + +<p> +Mesa 5.0.1 has been released. This is a stable, bug-fix release. +</p> +<pre> + 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) +</pre> +<p> +MD5 checksums follow: +</p> +<pre> +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 +</pre> + + + +<h2>March 7, 2003</h2> +<p> +Website and documentation overhaul. +</p> +<p> +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. +</p> + + +<h2>November 13, 2002</h2> +<p>Mesa 5.0 has been released. This is a stable release which +implements the OpenGL 1.4 specification. +</p><pre>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 +</pre> + + +<h2>October 29, 2002</h2> +<p>Mesa 4.1 has been released. This is a new development release. +For a stable release, get 4.0.4. +</p><pre>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 +</pre> + + +<h2>October 4, 2002</h2> +<p> +The <a href="http://mesa3d.sourceforge.net/docs/MesaFAQ.html">Mesa FAQ</a> has been rewritten. +</p> + +<h2>October 3, 2002</h2> +<p>Mesa 4.0.4 has been released. This is a stable bug-fix release. +</p><pre> 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 +</pre> + +<h2>June 25, 2002</h2> +<p>Mesa 4.0.3 has been released. This is a stable bug-fix release. +</p><pre> 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) +</pre> + +<h2>April 2, 2002</h2> +<p>Mesa 4.0.2 has been released. This is a stable bug-fix release. +</p><pre> 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) +</pre> + +<h2>December 17, 2001</h2> +<p>Mesa 4.0.1 has been released. This is a stable bug-fix release. +</p><pre> 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) +</pre> + +<h2>October 22, 2001</h2> +<p>Mesa 4.0 has been released. This is a stable release. +</p><pre> 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) +</pre> + + +<h2>June 21, 2001</h2> +<p>Mesa 3.5 has been released. This is a new development release. +</p><pre> 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 +</pre> + + +<h2>May 17, 2001</h2> +<p>Mesa 3.4.2 has been released. This is basically just a bug-fix release. +Here's what's new:</p> +<pre> 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 +</pre> + + +<h2>April 29, 2001</h2> +<p>New Mesa website</p> +<p>Mark Manning produced the new website.<br>Thanks, Mark!</p> + + +<h2>February 14, 2001</h2> +<p>Mesa 3.4.1 has been released. Here's what's new:</p> +<pre> 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 +</pre> +<p> +</p><h2>November 3, 2000</h2> +<p>Mesa 3.4 has been released. Here's what's new since the 3.3 release:</p> +<pre> 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 +</pre> +<p> +</p><h2>April 24, 2000</h2> +<p>Mesa 3.2 has been released. Here's what's new since the beta release:</p> +<pre> 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 +</pre> +<p> +</p><h2>March 23, 2000</h2> +<p>I've just upload the Mesa 3.2 beta 1 files to SourceForge at <a href="http://sourceforge.net/project/showfiles.php?group_id=3" target="_parent">http://sourceforge.net/project/filelist.php?group_id=3</a><a href="http://sourceforge.net/project/showfiles.php?group_id=3"></a></p> +<p>3.2 (note even number) is a stabilization release of Mesa 3.1 meaning it's mainly +just bug fixes.</p> +<p>Here's what's changed: + +</p><ul> + Bug fixes: + <ul> + - mixed drawing of lines and bitmaps sometimes had wrong colors<br> + - added missing glHintPGI() function<br> + - fixed a polygon culling bug<br> + - fixed bugs in gluPartialDisk()<br> + - Z values in selection mode were wrong<br> + - added missing tokens: + <ul> + GL_SMOOTH_POINT_SIZE_RANGE<br> + GL_SMOOTH_POINT_SIZE_GRANULARITY<br> + GL_SMOOTH_LINE_WIDTH_RANGE<br> + GL_SMOOTH_LINE_WIDTH_GRANULARITY<br> + GL_ALIASED_POINT_SIZE_RANGE<br> + GL_ALIASED_LINE_WIDTH_RANGE + </ul> + - fixed glCopyPixels when copying from back to front buffer<br> + - GL_EXT_compiled_vertex_array tokens had _SGI suffix instead of _EXT<br> + - glDrawRangeElements(GL_LINES, 0, 1, 2, type, indices) was broken<br> + - glDeleteTextures() didn't decrement reference count correctly<br> + - GL_SRCA_ALPHA_SATURATE blend mode didn't work correctly<br> + - Actual depth of transformation matrix stacks was off by one<br> + - 24bpp visuals didn't address pixels correctly<br> + - mipmap level of detail (lambda) calculation simplified, more accurate<br> + - 101691 - Polygon clipping and GL_LINE<br> + - 101928 - Polygon clipping and GL_LINE (same fix as above)<br> + - 101808 - Non-glVertexArrays tristrip bug<br> + - 101971 - find_last_3f on Dec OSF (worked around)<br> + - 102369 - segv on dec osf (possibly a duplicate of the above)<br> + - 102893 - orientations of modelview cause segfault + </ul> + New: + <ul> + - updated SVGA Linux driver<br> + - added the MESA_FX_NO_SIGNALS env var, see docs/README.3DFX<br> + - build libGLw.a (Xt/OpenGL drawing area widget) library by default<br> + - changed -O2 to -O3 for a number of gcc configs + </ul> + Changes: + <ul> + - glXCopyContext's mask parameter is now unsigned long, per GLX spec + </ul> +</ul> + +<p>Please report any problems with this release ASAP. Bugs should be filed on the +Mesa3D website at sourceforge.<br> +After 3.2 is wrapped up I hope to release 3.3 beta 1 soon afterward.</p> +<p>-- Brian</p> +<p> +</p><h2>December 17, 1999</h2> +<p>A Slashdot interview with Brian about Mesa (questions submitted by Slashdot readers) +can be found at <a href="http://slashdot.org/interviews/99/12/17/0927212.shtml" target="_parent">http://slashdot.org/interviews/99/12/17/0927212.shtml</a>.</p> +<p> +</p><h2>December 14, 1999</h2> +<p>Mesa 3.1 is released!</p> +<p> +</p><h2>September 21, 1999</h2> +<p>There appear to be two new files on the ftp site, <a href="ftp://ftp.mesa3d.org/mesa/beta/MesaLib-3.1beta3.tar.gz">MesaLib-3.1beta3.tar.gz</a> +and <a href="ftp://ftp.mesa3d.org/mesa/beta/MesaDemos-3.1beta3.tar.gz">MesaDemos-3.1beta3.tar.gz</a>, +that seem to be... yes, I've just received confirmation from the beta center, they +are indeed the <b>THIRD</b> beta release of Mesa 3.1! Happy Days. Happy Days. Thanks +Keith Whitwell for preparing these for us during Brian's absence.</p> +<p> +</p><h2>August 30, 1999</h2> +<p>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.</p> +<p>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.</p> +<p>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</p> +<p>PS: I'm going to be traveling until Sep 6 and won't be reading email until then.</p> +<p> +</p><h2>August 23, 1999</h2> +<p>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 <i>cvs update</i> from a previous download.</p> +<p> +</p><h2>August 17, 1999</h2> +<p>A report from the SIGGRAPH '99 Linux/OpenGL +BOF meeting is now available.</p> +<p>-Brian</p> +<p> +</p><h2>August 14, 1999</h2> +<p>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.</p> +<p>-Brian</p> +<p> +</p><h2>June 7, 1999</h2> +<p>RPMS of the nVidia RIVA server can be found at <a href="ftp://ftp.mesa3d.org/mesa/misc/nVidia/">ftp://ftp.mesa3d.org/mesa/misc/nVidia/</a>.</p> +<p> +</p><h2>June 2, 1999</h2> +<p><a href="http://www.nvidia.com/">nVidia</a> has released some Linux binaries for +xfree86 3.3.3.1, along with the <b>full source</b>, which includes GLX acceleration +based on Mesa 3.0. They can be downloaded from <a href="http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html">http://www.nvidia.com/Products.nsf/htmlmedia/software_drivers.html</a>.</p> +<p> +</p><h2>May 24, 1999</h2> +<p>Beta 2 of Mesa 3.1 has been make available at <a href="ftp://ftp.mesa3d.org/mesa/beta/">ftp://ftp.mesa3d.org/mesa/beta/</a>. +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. +<p> +</p><h2>May 13, 1999</h2> +<p>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.</p> +<p> +</p><h2>May 13, 1999</h2> +<pre>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. + +</pre> +<p> +</p><h2>May 1, 1999</h2> +<p>John Carmack made an interesting .plan update yesterday: + +</p><ul> + <i>"I put together a document on optimizing OpenGL drivers for Q3 that + should be helpful to the various Linux 3D teams. <br> + </i>http://www.quake3arena.com/news/glopt.html</i>" +</ul> + +<p> +</p><h2>April 7, 1999</h2> +<p>Updated the Mesa contributors section and added links to RPM Mesa packages.</p> +<p> +</p><h2>March 18, 1999</h2> +<p>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 <a href="http://www.mesa3d.org/txt/">http://www.mesa3d.org/txt/</a>.</p> +<p> +</p><h2>February 16, 1999</h2> +<p><a href="http://www.sgi.com/">SGI</a> releases its <a href="http://www.sgi.com/software/opensource/glx/">GLX +source code</a>.</p> +<p> +</p><h2>January 22, 1999</h2> +<p>www.mesa3d.org established</p> + + +</p> + + +<hr> +$Id: news.html,v 3.15.2.4 2004/12/09 23:23:47 brianp Exp $ +</body> +</html>
\ 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 @@ +<HTML> + +<TITLE>Off-screen Rendering</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Off-screen Rendering</H1> + + +<p> +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. +</p> +<p> +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. +</p> +<p> +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. +</p> + + +<H2>Deep color channels</H2> + +<p> + 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. +</p> +<p> + To build Mesa/OSMesa with 16-bit color channels: +<pre> + make realclean + make linux-osmesa16 +</pre> + + For 32-bit channels: +<pre> + make realclean + make linux-osmesa32 +</pre> + +<p> +You'll wind up with a library named libOSMesa16.so or libOSMesa32.so. +</p> + +<p> +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. +</p> + +<p> +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. +</p> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>PBuffer Rendering</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>PBuffer Rendering</H1> + +<p> +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. +</p> + +<p> +PBuffers are getting more use nowadays, though they've actually been +around for a long time on IRIX systems and other workstations. +</p> + +<p> +The +<a href="http://oss.sgi.com/projects/ogl-sample/registry/SGIX/fbconfig.txt" +target="_parent">GL_SGIX_fbconfig</a> +and +<a href="http://oss.sgi.com/projects/ogl-sample/registry/SGIX/pbuffer.txt" +target="_parent"> +GL_SGIX_pbuffer</a> extensions describe the functionality. +More recently, these extensions have been promoted to ARB extensions (on +Windows at least). +</p> + +<p> +The Mesa/progs/xdemos/ directory has some useful code for working +with pbuffers: +</p> + +<ul> +<li><b>pbinfo.c</b> - like glxinfo, it prints a list of available + fbconfigs and whether each supports pbuffers. +<li><b>pbutil.c</b> - a few utility functions for dealing with + fbconfigs and pbuffers. +<li><b>pbdemo.c</b> - a demonstration of off-screen rendering with pbuffers. +</ul> + +<p> +Mesa 4.1 and later support GL_SGIX_fbconfig and GL_SGIX_pbuffer (software +rendering only). +</p> + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Performance Tips</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Performance Tips</H1> + +<p> +Performance tips for software rendering: +</P> +<ol> + +<li> Turn off smooth shading when you don't need it (glShadeModel) +<li> Turn off depth buffering when you don't need it. +<li> Turn off dithering when not needed. +<li> Use double buffering as it's often faster than single buffering +<li> 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. +<li> Recompile Mesa with more optimization if possible. +<li> Try to maximize the amount of drawing done between glBegin/glEnd pairs. +<li> Use the MESA_BACK_BUFFER variable to find best performance in double + buffered mode. (X users only) +<li> 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) +<li> 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) +<li> 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 +<li> 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 +<li> 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 +<li> 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. +</ol> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Precompiled libraries</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Precompiled Libraries</H1> + +<p> +In general, precompiled libraries are not available. +However, people occasionally prepare packages of precompiled libraries +for some systems. +</p> + +<H2>Mesa-6.0 for Solaris</H2> + +<p> +Steve Christensen has submitted precompiled Mesa-6.0 libraries for +Solaris at <a href="http://sunfreeware.com/" target="_parent"> +sunfreeware.com</a>. +</p> + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Mesa Release Notes</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Release Notes</H1> + +<p> +The release notes summarize what's new or changed in each Mesa release. +</p> + +<UL> +<LI><A HREF="RELNOTES-6.2.1">RELNOTES-6.2.1</A> +<LI><A HREF="RELNOTES-6.2">RELNOTES-6.2</A> +<LI><A HREF="RELNOTES-6.1">RELNOTES-6.1</A> +<LI><A HREF="RELNOTES-6.0">RELNOTES-6.0</A> +<LI><A HREF="RELNOTES-5.1">RELNOTES-5.1</A> +<LI><A HREF="RELNOTES-5.0.2">RELNOTES-5.0.2</A> +<LI><A HREF="RELNOTES-5.0.1">RELNOTES-5.0.1</A> +<LI><A HREF="RELNOTES-5.0">RELNOTES-5.0</A> +<LI><A HREF="RELNOTES-4.1">RELNOTES-4.1</A> +<LI><A HREF="RELNOTES-4.0.3">RELNOTES-4.0.3</A> +<LI><A HREF="RELNOTES-4.0.2">RELNOTES-4.0.2</A> +<LI><A HREF="RELNOTES-4.0.1">RELNOTES-4.0.1</A> +<LI><A HREF="RELNOTES-4.0">RELNOTES-4.0</A> +<LI><A HREF="RELNOTES-3.5">RELNOTES-3.5</A> +<LI><A HREF="RELNOTES-3.4.2">RELNOTES-3.4.2</A> +<LI><A HREF="RELNOTES-3.4.1">RELNOTES-3.4.1</A> +<LI><A HREF="RELNOTES-3.4">RELNOTES-3.4</A> +<LI><A HREF="RELNOTES-3.3">RELNOTES-3.3</A> +<LI><A HREF="RELNOTES-3.2.1">RELNOTES-3.2.1</A> +<LI><A HREF="RELNOTES-3.2">RELNOTES-3.2</A> +<LI><A HREF="RELNOTES-3.1">RELNOTES-3.1</A> +</UL> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Science and Technical</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Science and Technical</H1> + +<ul> + <li><a href="http://www.softintegration.com/products/toolkit/opengl/" target="_parent">Ch</a> - OpenGL bindings for the Ch C/C++ interpreter + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">CLEO3D</a> - event displayer for the CLEOIII detector + </li><li><a href="http://www.bioz.unibas.ch/%7Exray/dino/" target="_parent">DINO</a> - Visualizing + Structural Biology + </li><li><a href="http://www-xdiv.lanl.gov/XCM/gmv/GMVHome.html" target="_parent">General + Mesh Viewer (GMV)</a> - scientific vis. + </li><li><a href="http://gid.cimne.upc.es/" target="_parent">GiD</a> - finite element + analysis + </li><li><a href="http://sig.co.za/download.htm" target="_parent">glpoisson</a> - A finite + element analysis program that simulates wave in an arbitrary region. + </li><li><a href="http://glwaves.sourceforge.net/" target="_parent">GLWaves</a> - + Electromagnetic wave visualization + </li><li><a href="http://www.geuz.org/gmsh/" target="_parent">Gmsh</a> - + finite element mesh generator / viewer + </li><li><a href="http://laaksonen.csc.fi/gopenmol/gopenmol.htmls" target="_parent">gOpenMol</a> + - computational chemistry + </li><li><a href="http://www.mgix.com/gps3d/" target="_parent">GPS 3D</a> - GPS-based map visualization + </li><li><a href="http://hirame.hiram.edu/%7Eworleyam/" target="_parent">Hitchhiker</a> + - virtual solar system + </li><li><a href="http://www-xdiv.lanl.gov/XCM/Hydra/" target="_parent">Hydra</a> - physics + and engineering pkg + </li><li><a href="http://fox.mit.edu/skunk/soft/lightspeed/" target="_parent">Light Speed</a> + - a real-time, interactive relativistic simulator + </li><li><a href="http://linkwinds.jpl.nasa.gov/" target="_parent">LinkWinds</a> - scientific + vis + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html" target="_parent">MathGL3d</a> - Mathematica viewer + </li><li><a href="http://www.mathworks.com/products/matlab" target="_parent">Mathworks</a> + - mathematics and visualization + </li><li><a href="http://www-rocq.inria.fr/gamma/medit/medit.html" target="_parent">Medit</a> - 3D surface mesh viewer + </li><li><a href="http://www.mol.biol.ethz.ch/wuthrich/software/molmol/" target="_parent">MOLMOL</a> + - molecular modeling and analysis + </li><li><a href="http://www.avatar.se/molscript/" target="_parent">Molscript</a> - molecular + modeling + </li> + <li><a href="http://www.opendx.org/" target="_parent">OpenDX</a> - Data visualization + system + </li> + <li><a href="http://orsa.sourceforge.net/" target="_parent">ORSA</a> - An interactive tool for Celestial Mechanics + </li> + <li><a href="http://www.paraview.org/" target="_parent">ParaView</a> - Scientific visualization package + </li> + <li><a href="http://mesa3d.sourceforge.net/notfound.html">PHLEX</a> - Finite element vis + </li><li><a href="http://root.cern.ch/" target="_parent">ROOT</a> - Object Oriented Data + Analysis Framework + </li><li><a href="http://www.slffea.com/" target="_parent">SLFFEA</a> - GNU finite element + package + </li><li><a href="http://quorum.tamu.edu/jon/spock" target="_parent">Spock</a> - molecular + modeling + </li><li><a href="http://www1.las.es/%7Eamil/ssystem" target="_parent">Ssystem</a> - solar + system simulation + </li><li><a href="http://mesa3d.sourceforge.net/notfound.html">SPARROW</a> - robot simulation + </li><li><a href="http://www.ssec.wisc.edu/%7Ebillh/vis5d.html" target="_parent">Vis5D</a> + - atmospheric visualization + </li><li><a href="http://www.ks.uiuc.edu/Research/vmd/" target="_parent">VMD</a> - molecular + modeling + </li><li><a href="http://www.cyberbotics.com/" target="_parent">Webots</a> - 3-D mobile + robot simulator +</li></ul> + + +</body></html>
\ 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 @@ +<HTML> + +<TITLE>Source Code Documentation</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Source Code Documentation</H1> + +<p> +<A HREF="http://www.doxygen.org" target="_parent">Doxygen</A> +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. +</P> + +<P> +If you're reading this page from your local copy of Mesa, and have +run the doxygen scripts, you can read the documentation +<A HREF="../doxygen/main/index.html" target="_parent">here</A> +</P> + +</BODY> +</HTML> 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 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<head> + <title>Mini GLX Specification</title> +</head> +<body> +<span style="font-style: italic;"></span><span + style="font-weight: bold;"></span> +<h1> +<center>Mesa Subset Specification</center> +</h1> +<h2> +<center> +<h3>Tungsten Graphics, Inc.</h3> +<h3>February 26, 2003<br> +</h3> +</center> +</h2> +<p> Copyright © 2002-2003 by <a + href="http://www.tungstengraphics.com/">Tungsten Graphics, Inc.</a>, +Cedar Park, Texas. All Rights Reserved. <br> +<br> +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.<br> +</p> +<p> OpenGL is a trademark of <a href="http://www.sgi.com">Silicon +Graphics, Inc.</a>.</p> +<h1>1. Introduction</h1> +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 <a + href="http://www.opengl.org/developers/documentation/specs.html">http://www.opengl.org/developers/documentation/specs.html</a>.) + Experience with OpenGL programming is highly advisable.<a + href="http://www.opengl.org/developers/documentation/specs.html"><br> +</a><br> +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. <br> +<br> +Appendix A contains a list of issues of which some may not be resolved.<br> +<br> +To summarize, the following major features of Mesa are omitted from the +subset:<br> +<ul> + <li>Vertex arrays</li> + <li>Texture coordinate generation</li> + <li>Lighting</li> + <li>Point size</li> + <li>Polygon stipple</li> + <li>DrawPixels, CopyPixels, PixelZoom</li> + <li>1-D and 3-D textures</li> + <li>CopyTex[Sub]Image</li> + <li>Fog</li> + <li>Depth test</li> + <li>Color Index mode</li> + <li>Accumulation buffer</li> + <li>Feedback mode</li> + <li>Evaluators</li> + <li>Push/Pop attributes</li> + <li>Display lists<br> + </li> +</ul> +<p>Further reductions are made at a lower level of detail.<br> +</p> +<p>Mesa function names are printed in <span style="font-weight: bold;">bold +face</span>. Function parameters are printed in <span + style="font-style: italic;">italics</span>.<br> +</p> +<p>The Tungsten Graphics, Inc. Mesa subset library is hereafter +referred to as <span style="font-style: italic;">the subset.</span><br> +<br> +</p> +<h1>2. Primitive Specification</h1> +<h2>2.1 glBegin, glEnd and glVertex Commands</h2> +The basic rendering primitives are points, lines and triangles. + Quadrilaterals and polygons are composed of triangles. + Primitives are drawn with the <span style="font-weight: bold;">glBegin</span> +and <span style="font-weight: bold;">glEnd</span> commands and a subset +of the <span style="font-weight: bold;">glVertex</span> commands:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glBegin</span>(GLenum<span + style="font-style: italic;">mode</span>)<br> +void <span style="font-weight: bold;">glEnd</span>(void)<br> +<br> +void <span style="font-weight: bold;">glVertex2f</span>(GLfloat <span + style="font-style: italic;">x</span>, GLfloat <span + style="font-style: italic;">y</span>)<br> +void <span style="font-weight: bold;">glVertex2fv</span>(const GLfloat +*<span style="font-style: italic;">v</span>)<br> +void <span style="font-weight: bold;">glVertex3f</span>(GLfloat <span + style="font-style: italic;">x</span>, GLfloat <span + style="font-style: italic;">y</span>, GLfloat <span + style="font-style: italic;">z</span>)<br> +void <span style="font-weight: bold;">glVertex3fv</span>(const GLfloat +*<span style="font-style: italic;">v</span>)<br> +</div> +<br> +The <span style="font-style: italic;">mode</span> parameter to <span + style="font-weight: bold;">glBegin</span> may be one of the following<br> +<br> +<div style="margin-left: 40px;">GL_POINTS - a series of individual +points<br> +GL_LINES - a series of disjoint line segments<br> +GL_LINE_STRIP - series of connected line segments<br> +GL_LINE_LOOP - a closed loop of line segments<br> +GL_TRIANGLES - a series of individual triangles<br> +GL_TRIANGLE_STRIP - a connected strip of triangles<br> +GL_TRIANGLE_FAN - a sequence of triangles all sharing a common vertex<br> +GL_QUADS - a sequence of individual quadrilaterals<br> +GL_QUAD_STRIP - a connected strip of quadrilaterals<br> +GL_POLYGON - a closed, convex polygon<br> +<br> +</div> +<br> +The <span style="font-weight: bold;">glVertex</span> 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 <span style="font-weight: bold;">glVertex</span> commands, is +one.<br> +<br> +<span style="font-weight: bold;"></span> +<h2>2.2 Other Per-vertex Commands<br> +</h2> +The <span style="font-weight: bold;">glColor</span> and <span + style="font-weight: bold;">glTexCoord</span> commands may be used to +specify colors and texture coordinates for each vertex:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glColor3f</span>(GLfloat<span + style="font-style: italic;">red</span>, GLfloat <span + style="font-style: italic;">green</span>, GLfloat <span + style="font-style: italic;">blue</span>)<br> +void <span style="font-weight: bold;">glColor3fv</span>(const GLfloat *<span + style="font-style: italic;">rgb</span>)<br> +void <span style="font-weight: bold;">glColor4f</span>(GLfloat <span + style="font-style: italic;">red,</span> GLfloat <span + style="font-style: italic;">green,</span> GLfloat <span + style="font-style: italic;">blue,</span> GLfloat <span + style="font-style: italic;">alpha</span>)<br> +void <span style="font-weight: bold;">glColor4fv</span>(const GLfloat *<span + style="font-style: italic;">rgba</span>)<br> +void <span style="font-weight: bold;">glTexCoord2f</span>(GLfloat <span + style="font-style: italic;">s</span>, GLfloat<span + style="font-style: italic;"> t</span>)<br> +void <span style="font-weight: bold;">glTexCoord2fv</span>(const +GLfloat *<span style="font-style: italic;">c</span>)<br> +<br> +</div> +The <span style="font-weight: bold;">glColor</span> commands specify +the color and optionally, the alpha value, for subsequent vertices. + For the <span style="font-weight: bold;">glColor3</span> commands, +alpha is set to one.<br> +<br> +The <span style="font-weight: bold;">glTexCoord2</span> commands +specify the texture coordinate for subsequent vertices. Texture +coordinates are actually four-component coordinates: (s, t, r, q). + The <span style="font-weight: bold;">glTexCoord2</span> commands +set s and t explicitly. The r and q components are zero and one, +respectively.<br> +<br> +<span style="font-weight: bold;"></span>Only <span + style="font-weight: bold;">glVertex, glColor</span> and <span + style="font-weight: bold;">glTexCoord</span> commands are allowed +between <span style="font-weight: bold;">glBegin</span> and <span + style="font-weight: bold;">glEnd.</span> Calling any other +command between <span style="font-weight: bold;">glBegin</span> and <span + style="font-weight: bold;">glEnd</span> will result in the error +GL_INVALID_OPERATION.<br> +<br> +<h2>2.3 Unsupported Commands</h2> +None of the following commands related to primitive specification are +supported by the subset:<br> +<br> +<div style="margin-left: 40px;">Per-Vertex commands:<br> +</div> +<div style="margin-left: 40px;"> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glVertex2d, +glVertex2i, glVertex2s, glVertex3d, glVertex3i, glVertex3s, glVertex4d, +glVertex4i, glVertex4s, glVertex2dv, glVertex2iv, glVertex2sv, +glVertex3dv, glVertex3iv, glVertex3sv, glVertex4dv, glVertex4iv, +glVertex4sv,<br> +glNormal3b, glNormal3d, glNormal3f, glNormal3i, glNormal3s, </span><span + style="font-weight: bold;">glNormal3bv, glNormal3dv, glNormal3fv, +glNormal3iv, glNormal3sv,<br> +glIndexd, glIndexf, glIndexi, glIndexs, glIndexub, glIndexdv, +glIndexfv, glIndexiv, glIndexsv, glIndexubv,<br> +glColor3b, glColor3d, glColor3i, glColor3s, glColor3ub, glColor3ui, +glColor3us, </span><span style="font-weight: bold;">glColor3bv, +glColor3dv, glColor3iv, glColor3sv, glColor3ubv, glColor3uiv, +glColor3usv,</span><span style="font-weight: bold;"> lColor4b, +glColor4d, glColor4i, glColor4s, glColor4ub, glColor4ui, glColor4us, </span><span + style="font-weight: bold;">glColor4bv, glColor4dv, glColor4iv, +glColor4sv, glColor4ubv, glColor4uiv, glColor4usv,<br> +</span><span style="font-weight: bold;">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,<br> +glEdgeFlag, glEdgeFlagv</span><br style="font-weight: bold;"> +<br> +</div> +Vertex array commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glVertexPointer, +glColorPointer, glIndexPointer, glTexCoordPointer, glEdgeFlagPointer, +glNormalPointer, glInterleavedArrays, glArrayElement, glDrawArrays, +glDrawElements, glDrawRangeElements, glEnableClientState, +glDisableClientState</span><br> +</div> +</div> +<div style="margin-left: 40px;"><br> +Rectangle commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glRects, +glRecti, glRectf, glRectd, glRectsv, glRectiv, glRectfv, glRectdv,<br> +<br> +</span></div> +</div> +<div style="margin-left: 40px;">Lighting commands:<br> +</div> +<div style="margin-left: 80px;"><span style="font-weight: bold;">glMaterialf, +glMateriali, glMaterialfv, glMaterialiv<br> +</span><br> +</div> +<div style="margin-left: 40px;"> Evaluator commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glEvalCoord1d, +glEvalCoord1f, glEvalCoord1dv, glEvalCoord1fv, </span><span + style="font-weight: bold;">glEvalCoord2d, glEvalCoord2f, +glEvalCoord2dv, glEvalCoord2fv,<br> +</span><span style="font-weight: bold;">glEvalPoint1, glEvalPoint2</span><br> +<br> +</div> +</div> +<h1>3. Coordinate Transformation</h1> +<h2>3.1 Vertex Transformation</h2> +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<br> +<br> +<div style="margin-left: 40px; font-weight: bold;">glMatrixMode<span + style="font-weight: normal;">(GLenum <span style="font-style: italic;">mode</span>)</span><br> +glLoadIdentity<span style="font-weight: normal;">(void)</span><br> +glPushMatrix<span style="font-weight: normal;">(void)</span><br> +glPopMatrix<span style="font-weight: normal;">(void)</span><br> +glLoadMatrixf<span style="font-weight: normal;">(const GLfloat *<span + style="font-style: italic;">m</span>)</span><br> +glMultMatrixf<span style="font-weight: normal;">(const GLfloat *<span + style="font-style: italic;">m</span>)</span><br> +glRotatef<span style="font-weight: normal;">(GLfloat <span + style="font-style: italic;">angle</span>, GLfloat <span + style="font-style: italic;">x</span>, GLfloat <span + style="font-style: italic;">y</span>, GLfloat <span + style="font-style: italic;">z</span>)</span><br> +glTranslatef<span style="font-weight: normal;">(GLfloat <span + style="font-style: italic;">x</span>, GLfloat <span + style="font-style: italic;">y</span>, GLfloat <span + style="font-style: italic;">z</span>)</span><br> +glScalef<span style="font-weight: normal;">(GLfloat <span + style="font-style: italic;">x</span>, GLfloat <span + style="font-style: italic;">y</span>, GLfloat <span + style="font-style: italic;">z</span>)<br> +<span style="font-weight: bold;">glFrustum(</span>GLdouble <span + style="font-style: italic;">left,</span> GLdouble <span + style="font-style: italic;">right,</span> GLdouble <span + style="font-style: italic;">bottom,</span> GLdouble <span + style="font-style: italic;">top,</span> GLdouble <span + style="font-style: italic;">near,</span> GLdouble <span + style="font-style: italic;">far</span>)</span><br> +<span style="font-weight: normal;"><span style="font-weight: bold;">glOrtho(</span>GLdouble<span + style="font-style: italic;"> left,</span> GLdouble <span + style="font-style: italic;">right,</span> GLdouble <span + style="font-style: italic;">bottom,</span> GLdouble <span + style="font-style: italic;">top,</span> GLdouble <span + style="font-style: italic;">near,</span> GLdouble <span + style="font-style: italic;">far</span>)</span><br> +glViewport<span style="font-weight: normal;">(GLint <span + style="font-style: italic;">x</span>, GLint <span + style="font-style: italic;">y</span>, GLsize <span + style="font-style: italic;">width,</span> GLsizei <span + style="font-style: italic;">height</span>)</span><br> +</div> +<br> +The <span style="font-weight: bold;">glMatrixMode</span> command +specifies the <span style="font-style: italic;">current matrix.</span> + 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.<br> +<br> +The <span style="font-weight: bold;">glLoadIdentity</span> command +replaces the current matrix with the identity matrix. The matrix +elements are specified in column-major order.<br> +<br> +The <span style="font-weight: bold;">glPushMatrix</span> command pushes +a copy of the current matrix onto either the modelview matrix stack or +the projection matrix stack. The <span style="font-weight: bold;">glPopMatrix</span> +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.<br> +<br> +The <span style="font-weight: bold;">glMultMatrixf</span> command +post-multiplies the current matrix by the specified matrix. The +matrix elements are specified in column-major order.<br> +<br> +The <span style="font-weight: bold;">glRotatef</span> command +post-multiplies the current matrix by a rotation matrix defined by the +angle and rotation axis defined by x, y and z.<br> +<br> +The <span style="font-weight: bold;">glTranslatef</span> command +post-multiplies the current matrix by a translation matrix defined by +the <span style="font-style: italic;">x</span>, <span + style="font-style: italic;">y</span> and <span + style="font-style: italic;">z</span> translation parameters.<br> +<span style="font-weight: bold;"></span><br> +The <span style="font-weight: bold;">glScalef</span> command +post-multiplies the current matrix by a scaling matrix defined by the <span + style="font-style: italic;">x</span>, <span + style="font-style: italic;">y</span> and <span + style="font-style: italic;">z</span> scale factors.<br> +<span style="font-weight: bold;"></span><br> +The <span style="font-weight: bold;">glFrustum</span> command +post-multiplies the current matrix by a perspective projection matrix. + The <span style="font-style: italic;">near</span> and <span + style="font-style: italic;">far</span> values specify the position of +the hither and yon Z-axis clipping planes. The <span + style="font-style: italic;">left, right, bottom</span> and <span + style="font-style: italic;">top</span> parameters are the X and Y +extents at the near clipping plane. <span + style="font-weight: bold;">glFrustum</span> is normally used to modify +the projection matrix.<br> +<br> +The <span style="font-weight: bold;">glOrtho</span> command +post-multiplies the current matrix by an orthographic projection matrix. + The <span style="font-style: italic;">near</span> and <span + style="font-style: italic;">far</span> values specify the position of +the hither and yon Z-axis clipping planes. The <span + style="font-style: italic;">left, right, bottom</span> and <span + style="font-style: italic;">top</span> parameters specify the X and +Y-axis clipping planes. <span style="font-weight: bold;">glOrtho</span> +is normally used to modify the projection matrix.<br> +<br> +The <span style="font-weight: bold;">glViewport</span> command +specifies the mapping of coordinates from normalized device coordinates +to window coordinates. The <span style="font-style: italic;">x</span> +and <span style="font-style: italic;">y</span> parameters specify the +viewport's lower-left corner in the window and the <span + style="font-style: italic;">width</span> and <span + style="font-style: italic;">height</span> parameters specify the size +of the viewport. <span style="font-weight: bold;">glViewport</span> +does not effect the current matrix.<br> +<br> +A coordinate transformed to window coordinates is hereafter known as (x<sub>w</sub>, +y<sub>w</sub>, z<sub>w</sub>).<br> +<br> +<h2>3.2 Clipping</h2> +View-volume clipping automatically discards or trims primitives which +lie completely or partially outside of the view volume specified by <span + style="font-weight: bold;">glFrustum</span> and <span + style="font-weight: bold;">glOrtho</span>. Note that the <span + style="font-weight: bold;">glViewport</span> command does not define a +clipping region.<br> +<br> +Clipping occurs in <span style="font-style: italic;">clip coordinate +space - </span>the coordinates produced after applying the projection +matrix.<br> +<br> +<h2>3.3 Current Raster Position</h2> +The current raster position specifies the location for drawing images +with <span style="font-weight: bold;">glBitmap.</span> The current +raster position is set with the commands:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glRasterPos2f</span>(GLfloat<span + style="font-style: italic;">x</span>, GLfloat <span + style="font-style: italic;">y</span>)<br> +void <span style="font-weight: bold;">glRasterPos2fv</span>(const +GLfloat *<span style="font-style: italic;">v</span>)<br> +void <span style="font-weight: bold;">glRasterPos2i</span>(GLint <span + style="font-style: italic;">x</span>, GLint <span + style="font-style: italic;">y</span>)<br> +void <span style="font-weight: bold;">glRasterPos2iv</span>(const +GLint *<span style="font-style: italic;">v</span>)<br> +</div> +<br> +<span style="font-weight: bold;">glRasterPos</span> 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 <span style="font-weight: bold;">glBitmap</span> commands +have no effect.<br> +<br> +<span style="font-weight: bold;">glRasterPos</span> 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 <span style="font-weight: bold;">glColor</span>). + The current raster texture coordinate is updated (copied) from the +current texture coordinate (as specified by <span + style="font-weight: bold;">glTexCoord</span>).<br> +<br> +<h2>3.4 Unsupported Commands</h2> +The following commands related to vertex transformation are not +supported by the subset:<br> +<br> +<div style="margin-left: 40px;">User-defined clip plane commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glClipPlane</span><br> +</div> +<span style="font-weight: bold;"></span></div> +<br> +<div style="margin-left: 40px;">Lighting and material commands:</div> +<div style="margin-left: 80px;"><span style="font-weight: bold;">glLightModeli, +glLightModelf, </span><span style="font-weight: bold;">glLightModeliv, +glLightModelfv,</span><span style="font-weight: bold;"> glLightf, +glLighti, glLightfv, glLightiv, glColorMaterial</span><br> +</div> +<br> +<div style="margin-left: 40px;">Automatic texture coordinate generation +commands:<br> +</div> +<div style="margin-left: 40px;"> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glTexGend, +glTexGenf, glTexGeni, </span><span style="font-weight: bold;">glTexGendv, +glTexGenfv, glTexGeniv, </span><br> +<br style="font-weight: bold;"> +</div> +Double-valued commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glLoadMatrixd, +glMultMatrixd, glRotated, glTranslated, glScaled</span><br + style="font-weight: bold;"> +</div> +<br> +Depth Range command:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glDepthRange</span> +(the near value is always 0.0 and the far value is always 1.0)<br> +</div> +<br> +Extra RasterPos commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glRasterPos2d, +glRasterPos2s, glRasterPos3d, glRasterPos3f, glRasterPos3i, +glRasterPos3s, glRasterPos4d, glRasterPos4f, glRasterPos4i, +glRasterPos4s, glRasterPos2dv, glRasterPos2sv, glRasterPos3dv, +glRasterPos3fv, glRasterPos3iv, glRasterPos3sv, glRasterPos4dv, +glRasterPos4fv, glRasterPos4iv, glRasterPos4sv</span><br> +</div> +<br> +<br> +</div> +<h1>4. Rasterization</h1> +This section describes the commands and options for drawing points, +lines, triangles and bitmaps. <span style="font-style: italic;">Rasterization</span> +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 <span style="font-style: italic;">draw</span> 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.<br> +<br> +<h2>4.1 Point Rasterization</h2> +Points are rendered with the command sequence <span + style="font-weight: bold;">glBegin</span>(GL_POINTS), <span + style="font-weight: bold;">glVertex</span>, ... <span + style="font-weight: bold;">glEnd</span>. The window coordinate (x<sub>w</sub>, +y<sub>w</sub>, z<sub>w</sub>) 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.<br> +<br> +The <span style="font-weight: bold;">glPointSize</span> command is not +supported; only 1-pixel points are supported.<br> +<br> +Point smoothing (antialiasing) is also not supported.<br> +<br> +<h2>4.2 Line Rasterization</h2> +Lines are rendered with the command sequence <span + style="font-weight: bold;">glBegin</span>(<span + style="font-style: italic;">mode</span>), <span + style="font-weight: bold;">glVertex</span>, <span + style="font-weight: bold;">glVertex</span>, ... <span + style="font-weight: bold;">glEnd</span> where <span + style="font-style: italic;">mode</span> 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 <span + style="font-style: italic;">half-open</span> 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.<br> +<br> +<h3>4.2.1 Line Width</h3> +The width of lines can be controlled by<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glLineWidth</span>(GLfloat<span + style="font-style: italic;">width</span>)<br> +</div> +<br> +where <span style="font-style: italic;">width</span> 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.<br> +<br> +<h3>4.2.2 Line Stipple<br> +</h3> +Lines may be stippled (i.e. dashed) with the command<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glLineStipple</span>(GLint<span + style="font-style: italic;">factor</span>, GLushort <span + style="font-style: italic;">pattern</span>)<br> +</div> +<br> +<span style="font-style: italic;">pattern</span> describes an on/off +pattern for the fragments produced by rasterization and <span + style="font-style: italic;">factor</span> specifies how many subsequent +fragments are kept or culled for each pattern bit. Line stippling +can be enabled or disabled by the commands <span + style="font-weight: bold;">glEnable</span>(GL_LINE_STIPPLE) and <span + style="font-weight: bold;">glDisable</span>(GL_LINE_STIPPLE).<br> +<br> +<h3>4.2.3 Line Antialiasing</h3> +Lines may be antialiased. For antialiased lines, each fragment +produced by rasterization is assigned a <span + style="font-style: italic;">coverage value</span> which describes how +much of the fragment's area is considered to be <span + style="font-style: italic;">inside</span> 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.<br> +<br> +Line antialiasing can be enabled or disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_LINE_SMOOTH) and <span + style="font-weight: bold;">glDisable</span>(GL_LINE_SMOOTH).<br> +<br> +<h2>4.3 Polygon Rasterization</h2> +Polygons, quadrilaterals and triangles share the same polygon +rasterization options. <br> +<br> +Triangles are rendered by the command sequence <span + style="font-weight: bold;">glBegin</span><span + style="font-style: italic;"><span style="font-style: italic;">(mode</span></span>),<span + style="font-weight: bold;">glVertex</span>, <span + style="font-weight: bold;">glVertex</span>, ... <span + style="font-weight: bold;">glEnd</span> where <span + style="font-style: italic;">mode</span> may be one of GL_TRIANGLES, +GL_TRIANGLE_STRIP or GL_TRIANGLE_FAN.<span style="font-weight: bold;"></span> + 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. <br> +<br> +Quadrilaterals are <span style="font-weight: bold;"></span>rendered by +the command sequence <span style="font-weight: bold;">glBegin</span>(<span + style="font-style: italic;"><span style="font-style: italic;">mode</span></span>),<span + style="font-weight: bold;">glVertex</span>, <span + style="font-weight: bold;">glVertex</span>, ... <span + style="font-weight: bold;">glEnd</span> where <span + style="font-style: italic;">mode</span> may be one of GL_QUADS or +GL_QUAD_STRIP.<span style="font-weight: bold;"></span> 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.<br> +<br> +Convex polygons are <span style="font-weight: bold;"></span>rendered +by the command sequence <span style="font-weight: bold;">glBegin</span><span + style="font-style: italic;"><span style="font-style: italic;"></span></span>(GL_POLYGON),<span + style="font-weight: bold;">glVertex</span>, <span + style="font-weight: bold;">glVertex</span>, ... <span + style="font-weight: bold;">glEnd</span>.<span + style="font-style: italic;"></span><span style="font-weight: bold;"></span> + If less than three vertices are specified, nothing is drawn.<br> +<br> +<h3>4.3.1 Polygon Orientation</h3> +The <span style="font-style: italic;">winding order</span> of vertices +(clockwise or counter-clockwise) is significant. It is used to +determine the <span style="font-style: italic;">front-facing</span> or <span + style="font-style: italic;">back-facing</span> 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.<br> +<br> +The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glFrontFace</span>(GLenum<span + style="font-style: italic;"> mode</span>)<br> +</div> +<br> +specifies whether clockwise or counter-clockwise winding indicates a +front-facing polygon. If <span style="font-style: italic;">mode</span> +is GL_CW then polygons with clockwise winding are front-facing. If <span + style="font-style: italic;">mode</span> is GL_CCW then polygons with +counter-clockwise winding are front-facing. The default value is +GL_CCW. If <span style="font-style: italic;">mode</span> is not +GL_CCW or GL_CW then the error GL_INVALID_ENUM will be raised.<span + style="font-style: italic;"></span><span style="font-style: italic;"></span><br> +<br> +<h3>4.3.2 Polygon Culling</h3> +Polygons may be culled (discarded) depending on whether they are +front-facing or back-facing. The command<br> +<br> +<div style="margin-left: 40px;">void<span style="font-weight: bold;"> +glCullFace</span>(GLenum <span style="font-style: italic;">mode</span>)<br> +</div> +<br> +specifies whether front-facing, back-facing or all polygons should be +culled. If <span style="font-style: italic;">mode</span> is +GL_FRONT then front-facing polygons will be culled. If <span + style="font-style: italic;">mode</span> is GL_BACK then back-facing +polygons will be culled. Otherwise, if <span style="font-style: italic;">mode</span> +is GL_FRONT_AND_BACK then all polygons will be culled. Any other +value for <span style="font-style: italic;">mode</span> will raise the +error GL_INVALID_ENUM.<br> +<br> +Polygon culling is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_CULL_FACE) and <span + style="font-weight: bold;">glDisable</span>(GL_CULL_FACE), +respectively.<br> +<br> +<h3>4.3.3 Polygon Antialiasing</h3> +Polygons may be antialiased in order to smooth their edges. + Polygon antialiasing is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_POLYGON_SMOOTH) and <span + style="font-weight: bold;">glDisable</span>(GL_POLYGON_SMOOTH).<br> +<br> +When polygon antialiasing is enabled each fragment produced by polygon, +triangle and quadrilateral rasterization will be given a <span + style="font-style: italic;">coverage</span> 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).<br> +<br> +The fragment's alpha value is multiplied by the coverage value. + By enabling the appropriate blending mode, polygon edges will +appear smoothed.<br> +<br> +<h2>4.4 Shading</h2> +The command<br> +<br> +<div style="margin-left: 40px;"> void <span style="font-weight: bold;">glShadeModel</span>(GLenum<span + style="font-style: italic;">mode</span>)<br> +</div> +<br> +determines whether colors are interpolated between vertices during +rasterization. If <span style="font-style: italic;">mode</span> 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 <span + style="font-style: italic;">mode</span> is GL_SMOOTH then vertex colors +are linearly interpolated to produce the fragment colors.<br> +<br> +<h2>4.5 Bitmap Rasterization</h2> +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.<br> +<br> +A bitmap is drawn with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glBitmap</span>(GLsizei<span + style="font-style: italic;">width</span>, GLsizei <span + style="font-style: italic;">height</span>, GLfloat <span + style="font-style: italic;">xOrig</span>, GLfloat <span + style="font-style: italic;">yOrig</span>, GLfloat <span + style="font-style: italic;">xMove</span>, GLfloat <span + style="font-style: italic;">yMove</span>, const GLubyte *<span + style="font-style: italic;">image</span>)<br> +</div> +<br> +<span style="font-style: italic;">width </span>and <span + style="font-style: italic;">height</span> specify the image size in +pixels. <span style="font-style: italic;">xOrig</span> and <span + style="font-style: italic;">yOrig</span> specify the bitmap origin. + <span style="font-style: italic;">xMove</span> and <span + style="font-style: italic;">yMove</span> are added to the current +raster position after the bitmap is rasterized. <span + style="font-style: italic;">image</span> is a pointer to the bitmap +data.<br> +<br> +If the current raster position is not valid, <span + style="font-weight: bold;">glBitmap</span> has no effect.<br> +<br> +<h3>4.5.1 Bitmap Unpacking</h3> +The first step in bitmap rendering is <span style="font-style: italic;">unpacking. + </span>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<br> +<br> +<div style="margin-left: 40px;">void<span style="font-weight: bold;"> +glPixelStorei</span>(GLenum pname, GLint value)<br> +</div> +<span style="font-style: italic;"></span><br> +The following unpacking parameters may be set:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 90%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">Parameter (<span + style="font-style: italic;">pname</span>)<br> + </td> + <td style="vertical-align: top;">Value (<span + style="font-style: italic;">value</span>)<br> + </td> + <td style="vertical-align: top;">Default<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_UNPACK_ROW_LENGTH<br> + </td> + <td style="vertical-align: top;">Width of the image in memory, in +pixels.<br> + </td> + <td style="vertical-align: top;">0<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_UNPACK_LSB_FIRST<br> + </td> + <td style="vertical-align: top;">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. <br> + </td> + <td style="vertical-align: top;">GL_FALSE<br> + </td> + </tr> + </tbody> +</table> +<br> +<br> +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 <span + style="font-style: italic;">width</span> parameter to <span + style="font-weight: bold;">glBitmap</span> specifies the width of the +image in memory.<br> +<br> +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).<br> +<br> +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:<br> +<br> +<div style="margin-left: 40px;">rowLength = (GL_UNPACK_ROW_LENGTH != 0) +? GL_UNPACK_ROW_LENGTH : <span style="font-style: italic;">width</span>;<br> +<br> +byte = <span style="font-style: italic;">image</span>[((rowLength + 7) +/ 8) * i + j / 8];<br> +<br> +if (GL_UNPACK_LSB_FIRST != 0)<br> + bitMask = 1 << (j % 8);<br> +else<br> + bitMask = 128 >> (j % 8);<br> +<br> +if (byte & bitMask)<br> + bit = 1;<br> +else<br> + bit = 0;<br> +<br> +</div> +<span style="font-style: italic;"><span style="font-style: italic;"></span></span> +<h3>4.5.2 Rasterization</h3> +If the current raster position is (x<sub>rp</sub>, y<sub>rp</sub>, z<sub>rp</sub>, +w<sub>rp</sub>), then the bitmap is rasterized according to the +following algorithm:<br> +<br> +for (j = 0; j < <span style="font-style: italic;">height</span>; +j++) {<br> + for (i = 0; i < <span style="font-style: italic;">width</span>; +i++) {<br> + if (bit(i,j)) {<br> + fragment.x = +floor(x<sub>rp</sub> - <span style="font-style: italic;">xOrig</span>) ++ i;<br> + fragment.y = +floor(y<sub>rp</sub> - <span style="font-style: italic;">yOrig</span>) ++ j;<br> + fragment.color += GL_CURRENT_RASTER_COLOR;<br> + +fragment.texture = GL_CURRENT_RASTER_TEXTURE_COORDS;<br> + +ProcessFragment(fragment)<br> + }<br> + }<br> +}<br> +<br> +After the bitmap has been rendered the current raster position is +updated as follows:<br> +<br> +<div style="margin-left: 40px;">x<sub>rp</sub> = x<sub>rp</sub> + <span + style="font-style: italic;">xMove</span><br> +y<sub>rp</sub> = y<sub>rp</sub> + <span style="font-style: italic;">yMove</span><br> +</div> +<br> +<h3>4.5.3 Per-fragment Operations</h3> +XXX supported? See issue in appendix A.<br> +<br> +<h2>4.6 Unsupported Commands</h2> +The following commands related to rasterization are not supported by +the subset.<br> +<br> +<div style="margin-left: 40px;">Point commands:<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glPointSize</span><br> +</div> +<br> +Polygon commands:<br> +<div style="margin-left: 40px; font-weight: bold;">glPolygonStipple<br> +glPolygonOffset<br> +glPolygonMode<br> +<br> +</div> +</div> +<div style="margin-left: 40px;">Pixel storage commands:<br> +</div> +<div style="font-weight: bold; margin-left: 80px;">glPixelStoref<br> +</div> +<br> +<br> +<h1>5. Texture Mapping<br> +</h1> +There are four elements to texture mapping: texture coordinate +specification, texture image specification, texture sampling and texture +application.<br> +<br> +Texture mapping is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_TEXTURE_2D) and <span + style="font-weight: bold;">glDisable</span>(GL_TEXTURE_2D).<br> +<br> +<h2>5.1 Texture Image Specification</h2> +A texture image is specified with the command:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glTexImage2D</span>(GLenum<span + style="font-style: italic;"> target</span>, GLint <span + style="font-style: italic;">level</span>, GLint <span + style="font-style: italic;">internalFormat,</span> GLsizei <span + style="font-style: italic;">width,</span> GLsizei <span + style="font-style: italic;">height,</span> GLint <span + style="font-style: italic;">border,</span> GLenum <span + style="font-style: italic;">format,</span> GLenum <span + style="font-style: italic;">type,</span> const GLvoid *<span + style="font-style: italic;">pixels</span> )<br> +</div> +<br> +<span style="font-style: italic;">target</span> must be GL_TEXTURE_2D. + <span style="font-style: italic;">level </span>indicates the +mipmap level for mipmap textures. <span style="font-style: italic;">internalFormat</span> +is a hint to indicate the preferred internal storage format for the +texture. <span style="font-style: italic;">width</span> and <span + style="font-style: italic;">height </span>indicate the image size in +pixels (or texels). <span style="font-style: italic;">border </span>must +be zero. <span style="font-style: italic;">format</span> and <span + style="font-style: italic;">type</span> describe the pixel format and +data type for the incoming image. <span style="font-style: italic;">pixels</span> +points to the incoming texture image. These parameters are +described in more detail below.<br> +<br> +<h3>5.1.1 Texture Image Size and Mipmaps</h3> +<h3><span style="font-style: italic;"></span></h3> +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 <span style="font-style: italic;">width </span>= +2<sup>n</sup> and <span style="font-style: italic;">height</span> = 2<sup>m</sup> +for some positive integers n and m.<br> +<br> +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 (<span style="font-style: italic;">level</span>=0) is of +width 2<sup>n</sup> and height 2<sup>m</sup> then the level 1 image must +be of width 2<sup>n-1</sup> and height 2<sup>m-1</sup>. 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.<br> +<br> +The following is an example of a mipmap's image levels:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 50%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">mipmap level<br> + </td> + <td style="vertical-align: top;">width<br> + </td> + <td style="vertical-align: top;">height<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">0<br> + </td> + <td style="vertical-align: top;">256<br> + </td> + <td style="vertical-align: top;">64<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">128<br> + </td> + <td style="vertical-align: top;">32<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">2<br> + </td> + <td style="vertical-align: top;">64<br> + </td> + <td style="vertical-align: top;">16<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">3<br> + </td> + <td style="vertical-align: top;">32<br> + </td> + <td style="vertical-align: top;">8<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">16<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">5<br> + </td> + <td style="vertical-align: top;">8<br> + </td> + <td style="vertical-align: top;">2<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">6<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">7<br> + </td> + <td style="vertical-align: top;">2<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">8<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + </tr> + </tbody> +</table> +<br> +If the <span style="font-style: italic;">width</span> or <span + style="font-style: italic;">height</span> 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 <span style="font-style: italic;">inconsistent</span> +and the system will behave as if the texturing is disabled.<br> +<br> +<h3>5.1.2 Texture Image Formats and Unpacking</h3> +The <span style="font-weight: bold;">glTexImage2D</span> command's <span + style="font-style: italic;"><span style="font-weight: bold;"></span></span><span + style="font-style: italic;">format</span> and <span + style="font-style: italic;">type</span> parameters describe the format +of the incoming texture image. Accepted values for <span + style="font-style: italic;">format</span> are GL_INTENSITY, GL_RGB and +GL_RGBA. The <span style="font-style: italic;">type</span> +parameter must be GL_UNSIGNED_BYTE. Pixel component values are +thus in the range 0 through 255.<br> +<br> +If <span style="font-style: italic;">format</span> is GL_INTENSITY then +the image has one byte per pixel which specifies the pixel's red, green, +blue and alpha values.<span style="font-style: italic;"></span><br> +<br> +If <span style="font-style: italic;">format</span> 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.<br> +<br> +If <span style="font-style: italic;">format</span> 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).<br> +<br> +The command<br> +<br> +<div style="margin-left: 40px;">void<span style="font-weight: bold;"> +glPixelStorei</span>(GLenum <span style="font-style: italic;">pname</span>, +GLint <span style="font-style: italic;">value</span>)<br> +</div> +<br> +controls the unpacking of texture image data from client memory. <span + style="font-style: italic;">pname</span> 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 <span style="font-style: italic;">width</span> parameter to <span + style="font-weight: bold;">glTexImage2D </span>determines the stride.<span + style="font-style: italic;"></span><br> +<br> +<h3>5.1.3 Internal Texture Format</h3> +<span style="font-weight: bold;">glTexImage2D<span + style="font-style: italic;"> </span></span>converts the incoming +texture image to one of the supported internal texture formats.<br> +<br> +The <span style="font-style: italic;">internalFormat</span> parameter +indicates the desired internal format for the texture and may be either +GL_INTENSITY8, GL_RGB5 or GL_RGBA8.<br> +<br> +If <span style="font-style: italic;">internalFormat</span> 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.<br> +<br> +If <span style="font-style: italic;">internalFormat</span> 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.<br> +<br> +If <span style="font-style: italic;">internalFormat </span>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.<br> +<br> +The internal format is also significant to texture application (see +section 5.4).<br> +<br> +<h2>5.2 Texture Coordinates</h2> +Texture coordinates control the mapping from local polygon space to +texture image space. Texture coordinates are set for each vertex +with the <span style="font-weight: bold;">glTexCoord</span> 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.<br> +<br> +Texture coordinates are normally in the range [0, 1]. Values +outside that range are processed according to the <span + style="font-style: italic;">texture wrap mode</span>. The +texture wrap mode is set with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glTexParameteri</span>(GLenum<span + style="font-style: italic;"> target</span>, GLenum <span + style="font-style: italic;">pname</span>, GLint <span + style="font-style: italic;">value</span>)<br> +<br> +</div> +<span style="font-style: italic;">target</span> must be GL_TEXTURE_2D. + If <span style="font-style: italic;">pname</span> is +GL_TEXTURE_WRAP_S or GL_TEXTURE_WRAP_T then <span + style="font-style: italic;">value</span> must be either +GL_CLAMP_TO_EDGE or GL_REPEAT.<br> +<br> +For GL_CLAMP_TO_EDGE, texture coordinates are effectively clamped to +the interval [0, 1].<br> +<br> +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.<br> +<br> +<h2>5.3 Texture Sampling</h2> +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.<br> +<br> +During texture coordinate interpolation a <span + style="font-style: italic;">level of detail</span> 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.<br> +<br> +If lambda indicates that multiple texels map to a single screen pixel, +then the texture <span style="font-style: italic;">minification</span> +filter will be used. Otherwise, if lambda indicates that a single +texel maps to multiple screen pixels, then the texture <span + style="font-style: italic;">magnification</span> filter will be used.<br> +<span style="font-weight: bold;"></span><span + style="font-style: italic;"></span><br> +<h3>5.3.1 Texture Minification</h3> +The texture minification filter is set with the <span + style="font-weight: bold;">glTexParameteri </span><span + style="font-style: italic;"></span><span style="font-weight: bold;"></span><span + style="font-style: italic;"></span> command by setting <span + style="font-style: italic;">target</span> to GL_TEXTURE_2D, setting <span + style="font-style: italic;">pname</span> to GL_TEXTURE_MIN_FILTER and +setting <span style="font-style: italic;">value</span> to GL_NEAREST, +GL_LINEAR, GL_NEAREST_MIPMAP_NEAREST, +GL_NEAREST_MIPMAP_LINEAR, GL_LINEAR_MIPMAP_NEAREST or +GL_LINEAR_MIPMAP_LINEAR.<br> +<br> +GL_NEAREST samples the texel nearest the texture coordinate in the +level 0 texture image.<br> +<br> +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.<br> +<br> +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.<br> +<br> +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.<br> +<br> +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.<br> +<br> +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.<br> +<br> +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.<br> + <br> +<h3>5.3.2 Texture Magnification</h3> +The texture magnification filter is set with the <span + style="font-weight: bold;">glTexParameteri </span><span + style="font-style: italic;"></span><span style="font-weight: bold;"></span>command +by setting <span style="font-style: italic;">target</span> to +GL_TEXTURE_2D, setting <span style="font-style: italic;">pname</span> to +GL_TEXTURE_MAG_FILTER and setting <span style="font-style: italic;">value</span> +to GL_NEAREST or GL_LINEAR.<br> +<br> +GL_NEAREST samples the texel nearest the texture coordinate in the +level 0 texture image.<br> +<br> +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.<br> +<br> +<h2>5.4 Texture Application</h2> +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<br> +<br> +<div style="margin-left: 40px;">void<span style="font-weight: bold;"> +glTexEnvi</span>(GLenum <span style="font-style: italic;">target</span>, +GLenum <span style="font-style: italic;">pname</span>, GLint <span + style="font-style: italic;">value</span>)<br> +</div> +<br> +<span style="font-style: italic;">target</span> must be GL_TEXTURE_ENV. + If <span style="font-style: italic;">pname</span> is +GL_TEXTURE_ENV_MODE then <span style="font-style: italic;">value</span> +must be one of GL_REPLACE, GL_MODULATE, GL_DECAL, or GL_BLEND.<br> +<br> +There is also a <span style="font-style: italic;">texture environment +color</span> that can factor into texture application. The texture +environment color can be set with the command<br> +<br> +<div style="margin-left: 40px;">void<span style="font-weight: bold;"> +glTexEnvfv</span>(GLenum <span style="font-style: italic;">target</span>, +GLenum <span style="font-style: italic;">pname</span>, const GLfloat *<span + style="font-style: italic;">value</span>)<br> +</div> +<span style="font-style: italic;"></span><br> +<span style="font-style: italic;">target</span> must be GL_TEXTURE_ENV. + If <span style="font-style: italic;">pname</span> is +GL_TEXTURE_ENV_COLOR then <span style="font-style: italic;">value </span>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).<br> +<span style="font-style: italic;"></span><br> +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. <span + style="font-style: italic;"></span>'It' is the sampled texture +intensity. (Rc, Gc, Bc, Ac) is the texture environment color. + (Rv, Gv, Bv, Av) is the resulting value.<br> +<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 90%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">Base Internal Format<br> + </td> + <td style="vertical-align: top;">GL_REPLACE<br> + </td> + <td style="vertical-align: top;">GL_MODULATE<br> + </td> + <td style="vertical-align: top;">GL_DECAL<br> + </td> + <td style="vertical-align: top;">GL_BLEND<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INTENSITY<br> + </td> + <td style="vertical-align: top;">Rv = It<br> +Gv = It<br> +Bv = It<br> +Bf = It<br> + </td> + <td style="vertical-align: top;">Rv = Rf * It<br> +Gv = Gf * It<br> +Bv = Bf * It<br> +Av = Af * It</td> + <td style="vertical-align: top;">undefined<br> + </td> + <td style="vertical-align: top;">Rv = Rf*(1-It) + Rc*It<br> +Gv = Gf*(1-It) + Gc*It<br> +Bv = Bf*(1-It) + Bc*It<br> +Av = Af*(1-It) + Ac*It</td> + </tr> + <tr> + <td style="vertical-align: top;">GL_RGB<br> + </td> + <td style="vertical-align: top;">Rv = Rt<br> +Gv = Gt<br> +Bv = Bt<br> +Av = Af<br> + </td> + <td style="vertical-align: top;">Rv = Rf * Rt<br> +Gv = Gf * Gt<br> +Bv = Bf * Bt<br> +Av = Af<br> + </td> + <td style="vertical-align: top;">Rv = Rt<br> +Gv = Gt<br> +Bv = Bt<br> +Av = Af</td> + <td style="vertical-align: top;">Rv = Rf*(1-Rt) + Rc*Rt<br> +Gv = Gf*(1-Gt) + Gc*Gt<br> +Bv = Bf*(1-Bt) + Bc*Bt<br> +Av = Af</td> + </tr> + <tr> + <td style="vertical-align: top;">GL_RGBA<br> + </td> + <td style="vertical-align: top;">Rv = Rt<br> +Gv = Gt<br> +Bv = Bt<br> +Av = At<br> + </td> + <td style="vertical-align: top;">Rv = Rf * Rt<br> +Gv = Gf * Gt<br> +Bv = Bf * Bt<br> +Av = Af * At</td> + <td style="vertical-align: top;">Rv = Rf*(1-At) + Rt*At<br> +Gv = Gf*(1-At) + Gt*At<br> +Bv = Bf*(1-At) + Bt*At<br> +Av = Af<br> + </td> + <td style="vertical-align: top;">Rv = Rf*(1-Rt) + Rc*Rt<br> +Gv = Gf*(1-Gt) + Gc*Gt<br> +Bv = Bf*(1-Bt) + Bc*Bt<br> +Av = Af*At</td> + </tr> + </tbody> +</table> +<br> +<br> +<br> +<h2>5.5 Texture Objects</h2> +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.<br> +<br> +<h3>5.5.1 Creating Texture Objects</h3> +A texture object is created by binding a new GLuint identifier to the +GL_TEXTURE_2D target with the command:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glBindTexture</span>(GLenum<span + style="font-style: italic;"> target</span>, GLuint <span + style="font-style: italic;">textureID</span>)<br> +</div> +<br> +<span style="font-style: italic;">target</span> must be GL_TEXTURE_2D. + <span style="font-style: italic;">textureID</span> may be any +unsigned integer. If <span style="font-style: italic;">textureID</span> +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 <span style="font-style: italic;">current texture object</span>. + Subsequent <span style="font-weight: bold;">glTexParameter </span>and<span + style="font-weight: bold;">glTexImage2D<span + style="font-style: italic;"> </span></span>calls will effect the +current texture object.<br> +<span style="font-style: italic;"></span><span + style="font-weight: bold;"><span style="font-style: italic;"> </span></span><br> +<h3>5.5.2 Deleting Texture Objects</h3> +One or more texture objects may be deleted with the command:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glDeleteTextures</span>(GLsizei<span + style="font-style: italic;">n</span>, const GLuint *<span + style="font-style: italic;">textureIDs</span>)<br> +</div> +<br> +<span style="font-style: italic;">textureIDs</span> is an array of <span + style="font-style: italic;">n</span> 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.<br> +<br> +<h3>5.5.3 Allocating Texture Object Identifiers</h3> +A list of new, unused texture IDs can be obtained by calling the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glGenTextures</span>(GLsizei<span + style="font-style: italic;"> n</span>, GLuint *<span + style="font-style: italic;">textureIDs</span>)<br> +</div> +<br> +An array of <span style="font-style: italic;">n</span> unused texture +IDs will be returned in the <span style="font-style: italic;">textureIDs</span> +array.<br> +<br> +<br> +<h1>6. Per-fragment Operations</h1> +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.<br> +<br> +<h2>6.1 Scissor Test</h2> +The scissor test limits rendering to a 2-D rectangular region of the +framebuffer. The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glScissor</span>(GLint<span + style="font-style: italic;">x</span>, GLint <span + style="font-style: italic;">y</span>, GLsizei <span + style="font-style: italic;">width</span>, GLsizei<span + style="font-style: italic;"> height</span>)<br> +</div> +<br> +defines a clipping region with the lower-left corner at (<span + style="font-style: italic;">x, y</span>) and the given <span + style="font-style: italic;">width</span> and <span + style="font-style: italic;">height</span>. The scissor test is +enabled and disabled with the command <span style="font-weight: bold;">glEnable</span>(GL_SCISSOR_TEST) +and <span style="font-weight: bold;">glDisable</span>(GL_SCISSOR_TEST).<br> +<br> +If the incoming fragment's position is (x<sub>f</sub>, y<sub>f</sub>) +then the fragment will pass the test if <span + style="font-style: italic;">x</span> <= x<sub>f</sub> < <span + style="font-style: italic;">x</span> + <span + style="font-style: italic;">width</span> and <span + style="font-style: italic;">y</span> <= y<sub>f</sub> < <span + style="font-style: italic;">y</span> + <span + style="font-style: italic;">height. </span>Otherwise, the +fragment is discarded.<br> +<br> +If <span style="font-style: italic;">width</span> or <span + style="font-style: italic;">height</span> 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.<br> +<br> +<h2>6.2 Alpha Test</h2> +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<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glAlphaFunc</span>(GLenum<span + style="font-style: italic;">mode</span>, GLclampf <span + style="font-style: italic;">reference</span>)<br> +</div> +<br> +<span style="font-style: italic;">mode</span> specifies an inequality +and <span style="font-style: italic;">reference</span> specifies a value +to compare against. The following table lists all possible +modes <span style="font-style: italic;"></span>and the +corresponding test:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 50%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">Comparison mode<br> + </td> + <td style="vertical-align: top;">The test passes if<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LESS<br> + </td> + <td style="vertical-align: top;">alpha < <span + style="font-style: italic;">reference</span><br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LEQUAL<br> + </td> + <td style="vertical-align: top;">alpha <= <span + style="font-style: italic;">reference</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_GREATER<br> + </td> + <td style="vertical-align: top;">alpha > <span + style="font-style: italic;">reference</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_GEQUAL<br> + </td> + <td style="vertical-align: top;">alpha >= <span + style="font-style: italic;">reference</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_EQUAL<br> + </td> + <td style="vertical-align: top;">alpha == <span + style="font-style: italic;">reference</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NOTEQUAL<br> + </td> + <td style="vertical-align: top;">alpha != <span + style="font-style: italic;">reference</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NEVER<br> + </td> + <td style="vertical-align: top;">never pass<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ALWAYS<br> + </td> + <td style="vertical-align: top;">always passes<br> + </td> + </tr> + </tbody> +</table> +<br> +The <span style="font-style: italic;">reference</span> parameter is +clamped to the range [0, 1].<br> +<br> +The alpha test is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_ALPHA_TEST) and <span + style="font-weight: bold;">glDisable</span>(GL_ALPHA_TEST).<br> +<br> +The default mode is GL_ALWAYS and the default reference value is 0.<br> +<br> +<h2>6.3 Stencil Test</h2> +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.<br> +<br> +Stenciling is controlled by the commands<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glStencilFunc</span>(GLenum<span + style="font-style: italic;">func</span>, GLint <span + style="font-style: italic;">ref</span>, GLuint <span + style="font-style: italic;">mask</span>)<br> +void <span style="font-weight: bold;">glStencilOp</span>(GLenum <span + style="font-style: italic;">stencilFail</span>, GLenum <span + style="font-style: italic;">depthTestFail</span>, GLenum <span + style="font-style: italic;">depthTestPass</span>)<br> +</div> +<br> +The <span style="font-weight: bold;">glStencilFunc<span + style="font-style: italic;"> </span></span>command controls the +stencil test while <span style="font-weight: bold;">glStencilOp</span> +command controls the how the stencil buffer is updated/modified after +the test.<br> +<br> +<span style="font-style: italic;">ref</span> is clamped to the range [0, +2<sup>N</sup>-1] where N is the number of bits per stencil value in the +stencil buffer.<span style="font-style: italic;"></span><br> +<br> +The following table lists all possible values for the <span + style="font-style: italic;">func</span> parameter and when the stencil +test will pass. Both the stencil buffer value and the stencil +reference value are bit-wise ANDed with the <span + style="font-style: italic;">mask</span> parameter before the test.<br> +<br> +<span style="font-style: italic;"></span><span + style="font-style: italic;"></span><span style="font-style: italic;"></span> +<table + style="text-align: left; margin-left: auto; margin-right: auto; width: 70%;" + border="1" cellspacing="2" cellpadding="2"> + <tbody> + <tr> + <td style="vertical-align: top;">Stencil <span + style="font-style: italic;">func</span> value<br> + </td> + <td style="vertical-align: top;">Stencil test passes if<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LESS<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">(ref</span>&<span + style="font-style: italic;">mask)</span> < (stencil buffer value +& <span style="font-style: italic;">mask)</span><br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LEQUAL<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">(ref</span> +& <span style="font-style: italic;">mask) </span><= (stencil +buffer value & <span style="font-style: italic;">mask)</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_GREATER<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">(ref</span> +& <span style="font-style: italic;">mask) </span>> (stencil +buffer value & <span style="font-style: italic;">mask)</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_GEQUAL<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">(ref</span> +& <span style="font-style: italic;">mask) </span>>= (stencil +buffer value & <span style="font-style: italic;">mask)</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_EQUAL<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">(ref</span> +& <span style="font-style: italic;">mask) </span>== (stencil +buffer value & <span style="font-style: italic;">mask)</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NOTEQUAL<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">(ref</span> +& <span style="font-style: italic;">mask) </span>!= (stencil +buffer value & <span style="font-style: italic;">mask)</span></td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NEVER<br> + </td> + <td style="vertical-align: top;">never passes<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ALWAYS<br> + </td> + <td style="vertical-align: top;">always passes<br> + </td> + </tr> + </tbody> +</table> +<br> +<span style="font-style: italic;"></span><br> +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 <span + style="font-style: italic;">stencilFail</span> parameter to <span + style="font-weight: bold;">glStencilOp</span>.<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 70%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;"><span style="font-style: italic;">stencilFail</span> +value<br> + </td> + <td style="vertical-align: top;">New stencil buffer value<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_KEEP<br> + </td> + <td style="vertical-align: top;">originalValue<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ZERO<br> + </td> + <td style="vertical-align: top;">0<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INVERT<br> + </td> + <td style="vertical-align: top;">BitWiseInvert(originalValue) +i.e. ~originalValue<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_REPLACE<br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">ref</span><br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INCR<br> + </td> + <td style="vertical-align: top;">originalValue + 1, clamped to +[0, 2<sup>N</sup>-1]</td> + </tr> + <tr> + <td style="vertical-align: top;">GL_DECR<br> + </td> + <td style="vertical-align: top;">originalValue - 1, clamped to +[0, 2<sup>N</sup>-1]</td> + </tr> + </tbody> +</table> +<span style="font-style: italic;"></span><span + style="font-style: italic;"></span><br> +<br> +The <span style="font-style: italic;">depthTestFail</span> and <span + style="font-style: italic;">depthTestPass</span> parameters to <span + style="font-weight: bold;">glStencilOp</span> are ignored. Values +for <span style="font-style: italic;">func</span> and <span + style="font-style: italic;">stencilFail</span> other than those listed +in the table will cause the error GL_INVALID_ENUM to be raised.<br> +<br> +The stencil test is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_STENCIL_TEST) and <span + style="font-weight: bold;">glDisable</span>(GL_STENCIL_TEST).<br> +<br> +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.<br> +<br> +Values written into the stencil buffer are masked with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glStencilMask</span>(GLuint<span + style="font-style: italic;">mask</span>)<br> +</div> +<br> +Only the bits which are set in <span style="font-style: italic;">mask</span> +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 <span + style="font-style: italic;">mask</span> are relevant. The default +stencil mask is ~0.<br> +<br> +<h2>6.4 Blending and Logicop</h2> +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.<br> +<br> +Blending is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_BLEND) and <span + style="font-weight: bold;">glDisable</span>(GL_BLEND).<br> +<br> +The logic operation is enabled and disabled with the commands <span + style="font-weight: bold;">glEnable</span>(GL_LOGIC_OP) and <span + style="font-weight: bold;">glDisable</span>(GL_LOGIC_OP).<br> +<br> +If both blending and the logic operation are enabled, the logic +operation has higher priority; blending is bypassed.<br> +<br> +<h3>6.4.1 Logic Op</h3> +The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glLogicop</span>(GLenum<span + style="font-style: italic;">mode</span>)<br> +<br> +</div> +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, 2<sup>N</sup>-1] where N is the number of bits per color +channel. N may not be the same for all color channels.<br> +<br> +The following table lists all values for <span + style="font-style: italic;">mode</span> and the boolean arithmetic used +to combine the incoming fragment color value (src)<span + style="font-style: italic;"></span><span style="font-style: italic;"></span><span + style="font-style: italic;"></span><span style="font-style: italic;"></span><span + style="font-style: italic;"></span> with the destination framebuffer +color value (dst). Standard ANSI C operators used.<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 50%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">LogicOp <span + style="font-style: italic;">mode</span><br> + </td> + <td style="vertical-align: top;">Resulting channel value<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CLEAR<br> + </td> + <td style="vertical-align: top;">0<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SET<br> + </td> + <td style="vertical-align: top;">~0<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_COPY<br> + </td> + <td style="vertical-align: top;">src<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_COPY_INVERTED<br> + </td> + <td style="vertical-align: top;">~s<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NOOP<br> + </td> + <td style="vertical-align: top;">dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INVERT<br> + </td> + <td style="vertical-align: top;">~dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_AND<br> + </td> + <td style="vertical-align: top;">src & dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NAND<br> + </td> + <td style="vertical-align: top;">~(src & dst)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_AND_REVERSE<br> + </td> + <td style="vertical-align: top;">src & ~dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_AND_INVERTED<br> + </td> + <td style="vertical-align: top;">~src & dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_OR<br> + </td> + <td style="vertical-align: top;">src | dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NOR<br> + </td> + <td style="vertical-align: top;">~(src | dst)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_OR_REVERSE<br> + </td> + <td style="vertical-align: top;">src | ~dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_OR_INVERTED<br> + </td> + <td style="vertical-align: top;">~src | dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_XOR<br> + </td> + <td style="vertical-align: top;">src ^ dst<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_EQUIV<br> + </td> + <td style="vertical-align: top;">~(src ^ dst)<br> + </td> + </tr> + </tbody> +</table> +<br> +The fragment's color is replaced by the result of the logic operation.<br> +<br> +Specifying any value for <span style="font-style: italic;">mode</span> +other than those listed in the above table will cause the error +GL_INVALID_ENUM to be raised.<br> +<br> +The default value for <span style="font-style: italic;">mode</span> is +GL_COPY. The logic operation is disabled by default.<br> +<br> +<h3>6.4.2 Blending</h3> +The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glBlendFunc</span>(GLenum<span + style="font-style: italic;">srcTerm</span>, GLenum <span + style="font-style: italic;">dstTerm</span>)<br> +</div> +<br> +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:<br> +<br> +<div style="margin-left: 40px;">Cv = Cf * <span + style="font-style: italic;">srcTerm</span> + Cb * <span + style="font-style: italic;">dstTerm</span><br> +<span style="font-style: italic;"></span></div> +<span style="font-style: italic;"> </span><br> +All possible values for <span style="font-style: italic;">srcTerm</span> +and the corresponding arithmetic term are listed in the following table:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 70%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;"><span style="font-style: italic;">srcTerm</span><br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">srcTerm</span>Arithmetic<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ZERO<br> + </td> + <td style="vertical-align: top;">(0, 0, 0, 0)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE<br> + </td> + <td style="vertical-align: top;">(1, 1, 1, 1)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_DST_COLOR<br> + </td> + <td style="vertical-align: top;">(Rb, Gb, Bb, Ab)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE_MINUS_DST_COLOR<br> + </td> + <td style="vertical-align: top;">(1-Rb, 1-Gb, 1-Bb, 1-Ab)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SRC_ALPHA<br> + </td> + <td style="vertical-align: top;">(Af, Af, Af, AF)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE_MINUS_SRC_ALPHA<br> + </td> + <td style="vertical-align: top;">(1-Af, 1-Af, 1-Af, 1-Af)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_DST_ALPHA<br> + </td> + <td style="vertical-align: top;">(Ab, Ab, Ab, Ab)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE_MINUS_DST_ALPHA<br> + </td> + <td style="vertical-align: top;">(1-Ab, 1-Ab, 1-Ab, 1-Ab)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SRC_ALPHA_SATURATE<br> + </td> + <td style="vertical-align: top;">(m, m, m, 1) where m = MIN(Af, +1-Ab)<br> + </td> + </tr> + </tbody> +</table> +<br> +All possible values for <span style="font-style: italic;">srcTerm</span> +and the corresponding arithmetic term are listed in the following table:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 70%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;"><span style="font-style: italic;">dstTerm</span><br> + </td> + <td style="vertical-align: top;"><span style="font-style: italic;">dstTerm</span>Arithmetic<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ZERO<br> + </td> + <td style="vertical-align: top;">(0, 0, 0, 0)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE<br> + </td> + <td style="vertical-align: top;">(1, 1, 1, 1)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SRC_COLOR<br> + </td> + <td style="vertical-align: top;">(Rf, Gf, Bf, Af)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE_MINUS_SRC_COLOR<br> + </td> + <td style="vertical-align: top;">(1-Rf, 1-Gf, 1-Bf, 1-Af)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SRC_ALPHA<br> + </td> + <td style="vertical-align: top;">(Af, Af, Af, AF)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE_MINUS_SRC_ALPHA<br> + </td> + <td style="vertical-align: top;">(1-Af, 1-Af, 1-Af, 1-Af)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_DST_ALPHA<br> + </td> + <td style="vertical-align: top;">(Ab, Ab, Ab, Ab)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ONE_MINUS_DST_ALPHA<br> + </td> + <td style="vertical-align: top;">(1-Ab, 1-Ab, 1-Ab, 1-Ab)<br> + </td> + </tr> + </tbody> +</table> +<br> +The fragment's color is replaced by the result of the blending equation.<br> +<br> +Values for <span style="font-style: italic;">srcTerm</span> and <span + style="font-style: italic;">dstTerm</span> other than those listed in +the table will cause the error GL_INVALID_ENUM to be raised.<br> +<br> +The default value for <span style="font-style: italic;">srcTerm</span> +is GL_ONE. The default value for <span style="font-style: italic;">dstTerm</span> +is GL_ZERO. Blending is disabled by default.<br> +<br> +<h2>6.5 Color Mask</h2> +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<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glColorMask</span>(GLboolean<span + style="font-style: italic;">redMask</span>, GLboolean <span + style="font-style: italic;">greenMask</span>, GLboolean <span + style="font-style: italic;">blueMask</span>, GLboolean <span + style="font-style: italic;">alphaMask</span>)<br> +</div> +<br> +allows selective writing to individual color channels. If <span + style="font-style: italic;">redMask</span> 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.<br> +<br> +Initially all four mask values are GL_TRUE.<br> +<br> +Color masking is not enabled/disabled with the <span + style="font-weight: bold;">glEnable</span>/<span + style="font-weight: bold;">glDisable</span> commands.<br> +<br> +<h1>7. Frame Buffer Operations</h1> +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.<br> +<br> +<h2>7.1 Clearing Buffers</h2> +Buffers are cleared (set to uniform values) with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glClear</span>(GLbitfield<span + style="font-style: italic;">buffers</span>)<br> +</div> +<br> +<span style="font-style: italic;">buffers</span> 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.<br> +<br> +The current color buffer is specified with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glDrawBuffer</span>(GLenum<span + style="font-style: italic;"> buffer</span>)<br> +</div> +<br> +<span style="font-style: italic;">buffer</span> may be either GL_FRONT, +GL_BACK or GL_NONE. GL_FRONT indicates that the front color buffer +will be modified by <span style="font-weight: bold;">glClear</span> and +any drawing command. GL_BACK indicates that the back color buffer +will be modified by <span style="font-weight: bold;">glClear</span> and +any drawing command. GL_NONE indicates that neither color buffer +will be modified by <span style="font-weight: bold;">glClear</span> or +any drawing command. GL_BACK is only valid for double-buffered +frame buffers.<br> +<br> +The current scissor rectangle, set by the <span + style="font-weight: bold;">glScissor</span> command, effects <span + style="font-weight: bold;">glClear</span><span + style="font-style: italic;">,</span><span style="font-style: italic;"> </span>limiting +the clear to the scissor rectangle, if it's enabled. Furthermore, <span + style="font-weight: bold;"></span>only the color channels enabled by <span + style="font-weight: bold;">glColorMask</span> will be effected by <span + style="font-weight: bold;">glClear</span>(GL_COLOR_BUFFER_BIT). + Likewise, only the stencil bits enabled by <span + style="font-weight: bold;">glStencilMask</span> will be effected by <span + style="font-weight: bold;">glClear</span>(GL_STENCIL_BUFFER_BIT).<br> +<br> +The current clear color is set with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glClearColor</span>(GLclampf<span + style="font-style: italic;">red</span>, GLclampf <span + style="font-style: italic;">green</span>, GLclampf <span + style="font-style: italic;">blue</span>, GLclampf <span + style="font-style: italic;">alpha</span>)<br> +</div> +<br> +Subsequent calls to <span style="font-weight: bold;">glClear</span> +will use the color (<span style="font-style: italic;">red, green, blue, +alpha</span>) to clear the front or back color buffers.<br> +<span style="font-style: italic;"></span><br> +The current stencil clear value is set with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glClearStencil</span>(GLint<span + style="font-style: italic;">clearValue</span>)<br> +</div> +<br> +If the stencil buffer is N bits deep, the least significant N bits of <span + style="font-style: italic;">clearValue</span> will be used to clear the +stencil buffer.<br> +<br> +<br> +<h1>8. Other Features</h1> +<h2>8.1 Frame Buffer Readback</h2> +A rectangular region of pixels can be read from the frame buffer and +placed in client memory with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glReadPixels</span>(GLint<span + style="font-style: italic;">x</span>, GLint <span + style="font-style: italic;">y</span>, GLsizei <span + style="font-style: italic;">width</span>, GLsizei <span + style="font-style: italic;">height</span>, GLenum <span + style="font-style: italic;">format</span>, GLenum <span + style="font-style: italic;">type</span>, GLvoid *<span + style="font-style: italic;">data</span>)<br> +</div> +<br> +<span style="font-style: italic;">x</span> and <span + style="font-style: italic;">y</span> specify the coordinate of the +lower-left corner of the region to read and <span + style="font-style: italic;">width</span> and <span + style="font-style: italic;">height</span> specify the size of the +rectangular region to read. <span style="font-style: italic;">format</span> +specifies the format of image data and must be either GL_RGB or +GL_RGBA. <span style="font-style: italic;">type</span> specify the +data type of the image data and must be either GL_UNSIGNED_BYTE or +GL_FLOAT. Other values for <span style="font-style: italic;">format</span> +or <span style="font-style: italic;">type</span> will cause the error +GL_INVALID_ENUM to be raised.<br> +<br> +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.<br> +<br> +The frame buffer color components (red, green, blue, alpha) are either +converted to 8-bit unsigned integers in the range[0, 255] if <span + style="font-style: italic;">type </span>is GL_UNSIGNED_BYTE or +converted to floating point values in the range [0, 1] if <span + style="font-style: italic;">type</span> 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.<br> +<br> +Image data is <span style="font-style: italic;">packed</span> into +client memory according to the pixel packing parameters which are set by +the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glPixelStorei</span>(GLenum<span + style="font-style: italic;"> pname</span>, GLint <span + style="font-style: italic;">value</span>)<br> +</div> +<br> +<span style="font-style: italic;">pname</span> must be +GL_PACK_ROW_LENGTH. <span style="font-style: italic;">value</span> +indicates the stride (in pixels) between subsequent rows in the +destination image. If GL_PACK_ROW_LENGTH is zero (the default) +then the <span style="font-style: italic;">width</span> parameter to <span + style="font-weight: bold;">glReadPixels</span> indicates the row stride.<br> +<br> +Pixel readback takes place as follows:<br> +<br> +<div style="margin-left: 40px;">if (GL_PACK_ROW_LENGTH == 0)<br> + rowLength = <span style="font-style: italic;">width</span>;<br> +else<br> + rowLength = GL_PACK_ROW_LENGTH<br> +<br> +if (<span style="font-style: italic;">format</span> == GL_RGB) {<br> + for (i = 0; i < <span style="font-style: italic;">height</span>; +i++) {<br> + for (j = 0; j < <span + style="font-style: italic;">width</span>; j++) {<br> + k = (i * +rowLength + j) * 3;<br> + <span + style="font-style: italic;">data</span>[k+0] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).red;<br> + <span + style="font-style: italic;">data</span>[k+1] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).green;<br> + <span + style="font-style: italic;">data</span>[k+2] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).blue;<span + style="font-style: italic;"></span><br> + }<br> + }<br> +}<br> +else {<br> + for (i = 0; i < <span style="font-style: italic;">height</span>; +i++) {<br> + for (j = 0; j < <span + style="font-style: italic;">width</span>; j++) {<br> + k = (i * +rowLength + j) * 4;<br> + <span + style="font-style: italic;">data</span>[k+0] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).red;<br> + <span + style="font-style: italic;">data</span>[k+1] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).green;<br> + <span + style="font-style: italic;">data</span>[k+2] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).blue;<span + style="font-style: italic;"></span><br> + <span + style="font-style: italic;">data</span>[k+3] = FrameBuffer(<span + style="font-style: italic;">x</span> + j, <span + style="font-style: italic;">y</span> + i).alpha;<span + style="font-style: italic;"></span><br> + }<br> + }<br> +}<br> +</div> +<br> +The function FrameBuffer(<span style="font-style: italic;">c, r</span>) +returns the pixel in the frame buffer at column <span + style="font-style: italic;">c</span> of row <span + style="font-style: italic;">r. </span><span + style="font-style: italic;">data</span> is considered to be either a +GLubyte pointer or a GLfloat pointer, depending on the <span + style="font-style: italic;">type</span> 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 <span + style="font-style: italic;">type</span> parameter.<br> +<br> +Pixels may be read from either the front or back color buffer. + The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glReadBuffer</span>(GLenum<span + style="font-style: italic;">buffer</span>)<br> +</div> +<br> +specifies the source for reading images with <span + style="font-weight: bold;">glReadPixels</span>. If <span + style="font-style: italic;">buffer</span> is GL_FRONT then front color +buffer is the source. If <span style="font-style: italic;">buffer</span> +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 <span style="font-style: italic;">buffer</span> +will raise the error GL_INVALID_ENUM.<br> +<br> +The default read source is GL_BACK if the frame buffer is double +buffered. Otherwise, the default read source is GL_FRONT.<br> +<br> +<h2>8.2 Selection Mode</h2> +Selection mode is typically used to implement <span + style="font-style: italic;">picking</span>: determining which +primitive(s) are present at particular window positions. The +command<br> +<br> +<div style="margin-left: 40px;">GLint <span style="font-weight: bold;">glRenderMode</span>(GLenum<span + style="font-style: italic;">mode</span>)<br> +</div> +<br> +is used to enable selection mode. If <span + style="font-style: italic;">mode</span> is GL_SELECTION the graphics +library is put into selection mode. If <span + style="font-style: italic;">mode</span> is GL_RENDER the graphic +library is put into normal rendering mode. Any other value for <span + style="font-style: italic;">mode</span> will raise the error +GL_INVALID_ENUM.<br> +<br> +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 <span style="font-style: italic;">selection</span> <span + style="font-style: italic;">buffer</span>. The selection buffer +is specified with the command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glSelectionBuffer</span>(GLsizei<span + style="font-style: italic;">n</span>, GLuint *<span + style="font-style: italic;">buffer</span>)<br> +</div> +<span style="font-style: italic;"></span><span + style="font-style: italic;"><br> +buffer</span> is an array of <span style="font-style: italic;">n</span> +unsigned integers. No more than <span style="font-style: italic;">n</span> +values will be placed in the buffer.<br> +<br> +The <span style="font-style: italic;">name stack</span> is a stack +(LIFO) of unsigned integer names. The following commands +manipulate the name stack:<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glInitNames</span>(void)<br> +void <span style="font-weight: bold;">glPushName</span>(GLuint <span + style="font-style: italic;">name</span>)<br> +void <span style="font-weight: bold;">glPopName</span>(void)<br> +void <span style="font-weight: bold;">glLoadName</span>(GLuint <span + style="font-style: italic;">name</span>)<br> +</div> +<br> +<span style="font-weight: bold;">glInitNames</span> resets the name +stack to an empty state. <span style="font-weight: bold;">glPushName<span + style="font-style: italic;"> </span></span>pushes the given <span + style="font-style: italic;">name</span> value onto the stack. <span + style="font-weight: bold;">glPopName</span> pops the top name from the +stack. <span style="font-weight: bold;">glLoadName<span + style="font-style: italic;"> </span></span>replaces the top value on +the stack with the specified <span style="font-style: italic;">name</span>. + Stack underflow and overflow conditions cause the errors +GL_STACK_OVERFLOW and GL_STACK_UNDERFLOW to be raised.<br> +<br> +While in selection mode, primitives (points, lines, polygons) are +transformed and clip-tested normally. Primitives which aren't +discarded by clipping cause the <span style="font-style: italic;">hit</span> <span + style="font-style: italic;">data</span> 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.<br> +<br> +When any of <span style="font-weight: bold;">glInitNames</span><span + style="font-style: italic;"><span style="font-style: italic;">, </span></span><span + style="font-weight: bold;">glPushName</span>, <span + style="font-weight: bold;">glPopName</span>, <span + style="font-weight: bold;">glLoadName</span> or <span + style="font-weight: bold;">glRenderMode</span> are called and the hit +flag is set, a <span style="font-style: italic;">hit record</span> is +written to the selection buffer.<br> +<br> +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 2<sup>32</sup>-1. The third value is +the maximum Z value multiplied by 2<sup>32</sup>-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.<br> +<br> +Selection mode is terminated by calling <span + style="font-weight: bold;">glRenderMode</span>(GL_RENDER). The +return value of <span style="font-weight: bold;">glRenderMode</span> +will be -1 if the selection buffer overflowed. Otherwise, the +return value will indicate the number of values written into the +selection buffer.<br> +<br> +<h2>8.3 Synchronization</h2> +The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glFlush</span>(void)<br> +</div> +<br> +makes the graphics library to flush all pending graphics commands. + The command<br> +<div style="margin-left: 40px;"><br> +void <span style="font-weight: bold;">glFinish</span>(void)<br> +</div> +<br> +makes the graphics library flush the command queue and wait until those +commands are completed. <span style="font-weight: bold;">glFlush</span> +will not return until all previous graphics commands have been fully +completed.<br> +<br> +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 <span style="font-style: italic;">swapbuffers</span> +command (part of the window system binding library) does an implicit +flush before swapping the front and back color buffers. The <span + style="font-weight: bold;">glReadPixels</span> command also does an +implicit flush before reading pixel data from the frame buffer.<br> +<br> +<h1>9. State Queries</h1> +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.<br> +<br> +<h2>9.1 General State Queries</h2> +The command<br> +<br> +<div style="margin-left: 40px;">void <span style="font-weight: bold;">glGetFloatv</span>(GLenum<span + style="font-style: italic;">pname</span>, GLfloat *<span + style="font-style: italic;">values</span>)<br> +</div> +<br> +returns the value(s) of the state variable specified by <span + style="font-style: italic;">pname</span>. The following table +lists all accepted values for <span style="font-style: italic;">pname</span> +and a description of the value(s). Specifying any other value for <span + style="font-style: italic;">pname</span> causes the error +GL_INVALID_ENUM to be raised.<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 90%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">Variable (<span + style="font-style: italic;">pname)</span><br> + </td> + <td style="vertical-align: top;">Number of values<br> + </td> + <td style="vertical-align: top;">Value(s) Description<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ALPHA_BITS<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Number of bits per alpha value +in the frame buffer.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ALPHA_TEST<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if the alpha test is +disabled.<br> +One if the alpha test is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ALPHA_TEST_FUNC<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">The alpha test function.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_BLEND<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if blending is disabled.<br> +One if blending is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_BLEND_DST<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Blend destination function/term.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_BLEND_SRC<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Blend source function/term.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_BLUE_BITS<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Number of bits per blue value in +the frame buffer.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_COLOR_CLEAR_VALUE<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Clear color (red, green, blue, +alpha).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_COLOR_WRITE_MASK<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Color buffer writemask (red, +green, blue, alpha).<br> +Zero if writing is disabled.<br> +One if writing is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CULL_FACE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if polygon culling is +disabled.<br> +One if polygon culling is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CULL_FACE_MODE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Polygon cull mode: GL_FRONT, +GL_BACK or GL_FRONT_AND_BACK.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CURRENT_COLOR<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Current color (red, green, blue, +alpha).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CURRENT_RASTER_COLOR<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Current raster position color +(red, green, blue, alpha).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CURRENT_RASTER_TEXTURE_COORDS<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Current raster position texture +coordinates (s, t, r, q).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CURRENT_RASTER_POSITION<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Current raster position (x, y, +z, w).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CURRENT_POSITION_VALID<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if current raster position +is invalid.<br> +One if current raster position is valid.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_CURRENT_TEXTURE_COORDS<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Current texture coordinates (s, +t, r, q)<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_DOUBLEBUFFER<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if color buffer is +single-buffered.<br> +One if color buffer is double-buffered.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_DRAW_BUFFER<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Current color draw buffer: +GL_FRONT or GL_BACK.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_FRONT_FACE</td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Polygon front-face winding: +GL_CW or GL_CCW.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_GREEN_BITS<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Number of bits per green value +in the frame buffer.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_SMOOTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if line smoothing is +disabled.<br> +One if line smoothing is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_STIPPLE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if line stippling is +disabled.<br> +One if line stippling is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_STIPPLE_PATTERN<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Line stipple pattern.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_STIPPLE_REPEAT<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Line stipple repeat factor.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_WIDTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Line width in pixels.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_WIDTH_GRANULARITY<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Aliased line width granularity.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LINE_WIDTH_RANGE<br> + </td> + <td style="vertical-align: top;">2<br> + </td> + <td style="vertical-align: top;">Minimum and maximum aliased line +widths.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_ALIASED_LINE_WIDTH_RANGE<br> + </td> + <td style="vertical-align: top;">2<br> + </td> + <td style="vertical-align: top;">Minimum and maximum antialiased +line widths.</td> + </tr> + <tr> + <td style="vertical-align: top;">GL_COLOR_LOGIC_OP<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if logicop is disabled.<br> +One if logicop is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_LOGIC_OP_MODE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Logicop function.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MATRIX_MODE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Matrix mode: GL_MODELVIEW or +GL_PROJECTION.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MAX_MODELVIEW_STACK_DEPTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Maximum size of the modelview +matrix stack.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MAX_NAME_STACK_DEPTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Maximum size of the selection +name stack.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MAX_PROJECTION_STACK_DEPTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Maximum size of the projection +matrix stack.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MAX_TEXTURE_SIZE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Maximum 2D texture image width +and height.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MAX_VIEWPORT_DIMS<br> + </td> + <td style="vertical-align: top;">2</td> + <td style="vertical-align: top;">Maximum viewport width and +height in pixels.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MODELVIEW_MATRIX<br> + </td> + <td style="vertical-align: top;">16<br> + </td> + <td style="vertical-align: top;">Current/top modelview matrix +values.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_MODELVIEW_MATRIX_STACK_DEPTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Current size of the modelview +matrix stack.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NAME_STACK_DEPTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Current size of the selection +name stack.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_PACK_ROW_LENGTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Pixel packing row length.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_POLYGON_SMOOTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if polygon smoothing is +disabled.<br> +One if polygon smoothing is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_PROJECTION_MATRIX<br> + </td> + <td style="vertical-align: top;">16<br> + </td> + <td style="vertical-align: top;">Current/top projection matrix +values.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_PROJECTION_STACK_DEPTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Current size of projection +matrix stack.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_READ_BUFFER<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Current read buffer: GL_FRONT or +GL_BACK.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_RED_BITS<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Number of bits per red value in +the frame buffer.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_RENDER_MODE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Current rendering mode: +GL_RENDER or GL_SELECTION.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_RGBA_MODE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Always one.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SCISSOR_BOX<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Scissor box (x, y, width, +height).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SCISSOR_TEST<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if scissor test is disabled.<br> +One if scissor test is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SELECTION_BUFFER_SIZE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Size of selection buffer.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_SHADE_MODEL<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Shade model: GL_FLAT or +GL_SMOOTH.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_BITS<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Number of bits per stencil value +in the frame buffer.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_CLEAR_VALUE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Stencil buffer clear value.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_FAIL<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Stencil fail operation.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_FUNC<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Stencil function.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_REF<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Stencil reference value.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_TEST<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if stencil test is disabled.<br> +One if stencil test is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_VALUE_MASK<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Stencil mask value.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STENCIL_WRITE_MASK<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Stencil buffer write mask.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_TEXTURE_2D<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if 2D texture mapping is +disabled.<br> +One if 2D texture mapping is enabled.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_TEXTURE_BINDING_2D</td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Name of currently bound 2D +texture object.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_TEXTURE_ENV_COLOR<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Texture environment color (red, +green, blue, alpha).<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_TEXTURE_ENV_MODE<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Texture environment mode.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_UNPACK_ROW_LENGTH<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Pixel unpacking row length.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_UNPACK_LSB_FIRST<br> + </td> + <td style="vertical-align: top;">1<br> + </td> + <td style="vertical-align: top;">Zero if most significant bit is +unpacked first for bitmaps.<br> +One if least significant bit is unpacked first for bitmaps.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_VIEWPORT<br> + </td> + <td style="vertical-align: top;">4<br> + </td> + <td style="vertical-align: top;">Current viewport (x, y, width, +height).<br> + </td> + </tr> + </tbody> +</table> +<br> +<br> +<h2>9.2 String Queries</h2> +The command<br> +<br> +<div style="margin-left: 40px;">const GLubyte *<span + style="font-weight: bold;">glGetString</span>(GLenum <span + style="font-style: italic;">name</span>)<br> +</div> +<br> +is used to query string-valued values. The legal values for <span + style="font-style: italic;">name</span> are described in the following +table:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 80%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;"><span style="font-style: italic;">name</span><br> + </td> + <td style="vertical-align: top;">Return value<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_VERSION<br> + </td> + <td style="vertical-align: top;">The library version, such as +"1.2".<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_RENDERER<br> + </td> + <td style="vertical-align: top;">The renderer, such as "Mesa DRI +Radeon".<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_VENDOR<br> + </td> + <td style="vertical-align: top;">The vendor of this +implementation, such as "Tungsten Graphics, Inc."<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_EXTENSIONS<br> + </td> + <td style="vertical-align: top;">A white-space separated list of +the supported extensions. </td> + </tr> + </tbody> +</table> +<br> +<h2>9.3 Error Queries</h2> +The command<br> +<br> +<div style="margin-left: 40px;">GLenum <span style="font-weight: bold;">glGetError</span>(void)<br> +</div> +<br> +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 <span + style="font-weight: bold;">glGetError</span> returns. The +following error codes are possible:<br> +<br> +<table cellpadding="2" cellspacing="2" border="1" + style="text-align: left; width: 80%; margin-left: auto; margin-right: auto;"> + <tbody> + <tr> + <td style="vertical-align: top;">Error code<br> + </td> + <td style="vertical-align: top;">Meaning<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_NO_ERROR<br> + </td> + <td style="vertical-align: top;">No error has been recorded.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INVALID_ENUM<br> + </td> + <td style="vertical-align: top;">An enum parameter had an invalid +value.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INVALID_VALUE<br> + </td> + <td style="vertical-align: top;">A numeric parameter had an +invalid value.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_INVALID_OPERATION<br> + </td> + <td style="vertical-align: top;">A function was called when not +legal to do so.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STACK_OVERFLOW<br> + </td> + <td style="vertical-align: top;">The current transformation +matrix stack is full.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_STACK_UNDERFLOW<br> + </td> + <td style="vertical-align: top;">The current transformation +matrix stack is empty.<br> + </td> + </tr> + <tr> + <td style="vertical-align: top;">GL_OUT_OF_MEMORY<br> + </td> + <td style="vertical-align: top;">The system ran out of dynamic +memory.<br> + </td> + </tr> + </tbody> +</table> +<br> +<br> +<h1>10. Unsupported Features</h1> +This section lists other features and functions which are not supported +and not previously discussed.<br> +<br> +<h2>10.1 Feedback Mode</h2> +Feedback mode and the following related functions are not supported.<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glFeedbackBuffer</span><br> +<span style="font-weight: bold;">glPassThrough</span><br> +</div> +<br> +<h2>10.2 1D and 3D Textures<br> +</h2> +Only 2D texture images are supported. The following functions +used to specify 1D and 3D texture images are not supported:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glTexImage1D</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTexImage3D</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTexSubImage1D</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glTexSubImage3D</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glCopyTexImage1D</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glCopyTexSubImage1D</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glCopyTexSubImage3D</span><br> +</div> +<br> +<h2>10.3 Alternate Texture Image Commands<br> +</h2> +Texture images may only be specified with <span + style="font-weight: bold;">glTexImage2D</span>. The following +alternate texture image commands are not supported:<br> +<br> +<div style="margin-left: 40px; font-weight: bold;">glTexSubImage2D<br> +glCopyTexImage2D<br> +glCopyTexSubImage2D<br> +</div> +<br> +<h2>10.4 Proxy Textures</h2> +Proxy textures are not supported and the GL_PROXY_TEXTURE_2D token is +not supported by any function.<br> +<br> +<br> +<h2>10.5 Other Texture Commands</h2> +The following commands related to texture mapping are not supported by +the subset:<br> +<br> +<div style="margin-left: 40px; font-weight: bold;"> glPrioritizeTextures<br> +glAreTexturesResident<br> +glIsTexture<br> +glTexEnviv<br> +glTexEnvf<br> +glTexParameterf<br> +glTexParameteriv<br> +glTexParameterfv<br> +</div> +<br> +<br> +<h2>10.6 Copy and Draw Pixels<br> +</h2> +The following commands are not supported:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glDrawPixels<br> +glCopyPixels<br> +glPixelZoom<br> +<br> +</span></div> +<h2>10.7 Color Index Mode<br> +</h2> +Color index mode and the following related commands are not supported:<br> +<br> +<span style="font-weight: bold;"></span> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glIndexub<br> +</span><span style="font-weight: bold;">glIndexi</span><br> +<span style="font-weight: bold;">glIndexs<br> +glIndexf<br> +glIndexd<br> +</span><span style="font-weight: bold;">glIndexubv<br> +</span><span style="font-weight: bold;">glIndexiv</span><br> +<span style="font-weight: bold;">glIndexsv<br> +glIndexfv<br> +glIndexdv</span><span style="font-weight: bold;"><br> +glIndexMask<br> +</span><span style="font-weight: bold;">glClearIndex<br> +glIndexPointer</span><br style="font-weight: bold;"> +<br> +</div> +<h2>10.8 Pixel Transfer Operations</h2> +The pixel transfer operations (scale, bias, look-up table, etc) are not +supported and the following commands are omitted:<br> +<br style="font-weight: bold;"> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glPixelTransferf</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glPixelTransferi</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glPixelMapfv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glPixelMapuiv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glPixelMapusv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glGetPixelMapfv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glGetPixelMapuiv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glGetPixelMapusv</span><br> +</div> +<br> +<h2>10.9 Hints</h2> +Hints and the following related command is not supported:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glHint<br> +</span><br> +</div> +<h2>10.10 State Query Commands<br> +</h2> +The following state query commands are not supported:<br> +<br> +<div style="margin-left: 40px; font-weight: bold;">glGetBooleanv<br> +glGetIntegerv<br> +glGetDoublev<br> +glGetPointerv<br> +glGetTexEnvi<br> +glGetTexEnvf<br> +glGetTexParameteriv<br> +glGetTexParameterfv<br> +glGetTexLevelParameteriv<br> +glGetTexLevelParameterfv<br> +glGetTexImage<br> +glGetClipPlane<br> +</div> +<br> +<h2>10.11 Attribute Stacks</h2> +State attribute stacks and the following related commands are not +supported:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glPushAttrib</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glPopAtttrib</span><br> +<br style="font-weight: bold;"> +</div> +<h2>10.12 Double-Valued Functions</h2> +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:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glVertex2d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glVertex2dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glVertex3d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glVertex3dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glVertex4d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glVertex4dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glColor3d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glColor3d</span><span + style="font-weight: bold;">v</span><br style="font-weight: bold;"> +<span style="font-weight: bold;">glColor4d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glColor4dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTexCoord1d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTexCoord1d</span><span + style="font-weight: bold;">v</span><br style="font-weight: bold;"> +<span style="font-weight: bold;">glTexCoord2d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glTexCoord2dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTexCoord3d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glTexCoord3dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTexCoord4d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glTexCoord4dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glRasterPos2d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glRasterPos2dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glRasterPos3d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glRasterPos3dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glRasterPos4d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;"> glRasterPos4dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glLoadMatrixd</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMultMatrixd</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glScaled</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glRotated</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glTranslated<br> +glRectd<br> +glRectdv<br> +</span> <span style="font-weight: bold;"><br> +</span> </div> +<h2>10.13 Evaluators</h2> +Evaluators and the following related commands are not supported:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glMap1f</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMap2d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMap2f</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glGetMapdv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glGetMapfv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glGetMapiv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord1d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord1f</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord1dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord1fv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord2d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord2f</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord2dv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalCoord2fv</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMapGrid1d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMapGrid1f</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMapGrid2d</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glMapGrid2f</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalPoint1</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalPoint2</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalMesh1</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glEvalMesh2</span><br + style="font-weight: bold;"> +</div> +<br> +<h2>10.14 Display Lists</h2> +Display lists and the following related commands are not supported:<br> +<br> +<div style="margin-left: 40px; font-weight: bold;">glIsList<br> +glDeleteLists<br> +glGenLists<br> +glNewList<br> +glEndList<br> +glCallList<br> +glCallLists<br> +glListBase<br> +</div> +<br> +<h2>10.15 Accumulation Buffer</h2> +The accumulation buffer and the following related commands are not +supported:<br> +<br style="font-weight: bold;"> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glAccum</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glClearAccum</span><br> +</div> +<br> +<h2>10.16 Fog</h2> +Fog and the following related commands are not supported:<br> +<br> +<div style="margin-left: 40px; font-weight: bold;"> glFogi<br> +glFogf<br> +glFogiv<br> +glFogfv<br> +</div> +<br> +<h2>10.17 Depth Test</h2> +Depth testing and the following related commands are not supported:<br> +<br> +<div style="margin-left: 40px;"><span style="font-weight: bold;">glDepthFunc</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glDepthMask</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glDepthRange</span><br + style="font-weight: bold;"> +<span style="font-weight: bold;">glClearDepth</span><br> +</div> +<br> +<h2>10.18 Imaging Subset</h2> +The OpenGL imaging subset (which implements features such as +convolution, histogram, min/max recording, color matrix and color +tables) is not supported.<br> +<br> +<br> +<h1>Appendix A: Issues</h1> +This appendix lists documentation and subset issues with their current +status. For items which are still open, the documentation (above) +follows the recommended solution.<br> +<br> +<h2>A.1 Vertex Arrays</h2> +Should vertex arrays be supported? Is there a performance +advantage?<br> +<br> +RESOLUTION: No, there isn't enough of a performance advantage to +justify them.<br> +<br> +<h2>A.2 Polygon Antialiasing and Edge Flags</h2> +Should edge flags be supported for antialiasing?<br> +<br> +Edge flags don't effect antialiasing, at least not normally. A +number of approaches to antialiasing have been summarized in email.<br> +<br> +RECOMMENDATION: don't support edge flags. They don't effect +polygon antialiasing.<br> +<br> +RESOLUTION: closed, as of 26 Feb 2003.<br> +<br> +<h2>A.3 glRasterPos vs. glWindowPos</h2> +Should glRasterPos and/or glWindowPos commands be supported?<br> +<br> +RESOLUTION: Closed: implement glRasterPos commands, but not glWindowPos +commands.<br> +<br> +<h2>A.4 GL_IBM_rasterpos_clip extension</h2> +Should the GL_IBM_rasterpos_clip extension be implemented?<br> +<br> +RESOLUTION: No. It's not required.<br> +<br> +<h2>A.5 Image Formats and Types</h2> +Which image formats and types should be supported for <span + style="font-weight: bold;">glTexImage2D</span> and <span + style="font-weight: bold;">glReadPixels</span>?<br> +<br> +OpenGL specifies a <span style="font-weight: bold;">large</span> +variety of image formats and data types. Only a few are commonly +used.<br> +<br> +RECOMMENDATION: we propose a subset:<br> +<br> +For <span style="font-weight: bold;">glTexImage2D</span> only allow <span + style="font-style: italic;">type</span>=GL_UNSIGNED_BYTE and <span + style="font-style: italic;">format</span>=GL_RGBA, GL_RGB, +GL_INTENSITY. Only allow <span style="font-style: italic;">internalFormat</span> +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 <span style="font-weight: bold;">glTexImage2D</span> +to basically just use <span style="font-weight: bold;">memcpy</span> to +copy texture images.<br> +<br> +For <span style="font-weight: bold;">glReadPixels</span>, only allow <span + style="font-style: italic;">type</span> = GL_UNSIGNED_BYTE or GL_FLOAT. + Only allow <span style="font-style: italic;">format</span> = +GL_RGB or GL_RGBA. This is just enough to support the OpenGL +conformance tests.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.6 Texture Environment Modes</h2> +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.<br> +<br> +RECOMMENDATION: implement the standard modes GL_REPLACE, GL_MODULATE, +GL_DECAL and GL_BLEND.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.7 Truncated Mipmaps and LOD Control</h2> +Should we support the GL_TEXTURE_BASE_LEVEL, GL_TEXTURE_MAX_LEVEL, +GL_TEXTURE_MIN_LOD and GL_TEXTURE_MAX_LOD texture parameters?<br> +<br> +RECOMMENDATION: We propose omitting these features at this time, +in the interest of simplifying the driver.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.8 Texture Priorities and Residency</h2> +Should the subset support texture priorities via <span + style="font-weight: bold;">glPrioritizeTextures</span> and the <span + style="font-weight: bold;">glAreTexturesResident</span> command?<br> +<br> +RECOMMENDATION: Few applications use these features and +functions. We propose omitting them to simplify the driver.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.9 Pixel Pack/Unpack Alignment Control</h2> +Should we support the GL_PACK_ALIGNMENT and GL_UNPACK_ALIGNMENT options?<br> +<br> +These are used to align pixel data addresses to 1, 2 and 4-byte +multiples for <span style="font-weight: bold;">glBitmap, glTexImage2D</span> +and <span style="font-weight: bold;">glReadPixels</span>. 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.<br> +<br> +RECOMMENDATION: We recommend omitting them to simplify the driver.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.10 Pixel Pack/Unpack Skip Rows/Pixels Control</h2> +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?<br> +<br> +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.<br> +<br> +RECOMMENDATION: omit these parameters.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.11 Texture State Queries</h2> +Should we support the command <span style="font-weight: bold;">glGetTexEnvi/fv, +glGetTexParameteri/fv</span> and <span style="font-weight: bold;">glGetTexLevelParameteri/fv</span>?<br> +<br> +RECOMMENDATION: No. They're seldom needed and their +implementation is several hundred lines of code in length.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.12 glGetIntegerv, glGetBooleanv and glGetDoublev</h2> +Should we support the commands <span style="font-weight: bold;">glGetIntegerv, +glGetBooleanv </span>and <span style="font-weight: bold;">glGetDoublev</span> +in addition to <span style="font-weight: bold;">glGetFloatv</span>?<br> +<br> +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 <span + style="font-weight: bold;">glGetFloatv</span>. The +implementation of the other three commands involves many lines of code.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.13 glBitmap and Per-Fragment Operations</h2> +Should bitmaps rendered with <span style="font-weight: bold;">glBitmap</span> +be subjected to the per-fragment operations?<br> +<br> +If bitmaps are implemented with points it will be easy to implement the +per-fragment operations. Otherwise, it could be difficult.<br> +<br> +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.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.14 Reduced gl.h Header File</h2> +Should we produce a reduced gl.h header file which only defines the +tokens and functions which are implemented by the subset?<br> +<br> +RECOMMENDATION: yes. It would be a useful reference to +programmers to quickly determine which functions and tokens are +supported.<br> +<br> +RESOLUTION: open<br> +<br> +<h2>A.15 glPolygonMode</h2> +Is <span style="font-weight: bold;">glPolygonMode</span> needed?<br> +<br> +RECOMMENDATION: No. Omit it.<br> +<br> +RESOLUTION: closed, as of 26 Feb 2003<br> +<br> +<br> +<p> </p> +</body> +</html> 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 @@ +<HTML> + +<TITLE>Mesa Subset</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Mesa Subset</H1> + +<p> +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. +</p> + +<p> +The specification for this subset can be found +<a href="subset-A.html">here</a>. +</p> + +<p> +The <a href="MiniGLX.html">MiniGLX specification</a> describes the +interface between fbdev and Mesa. +</p> + +<p> +More info to come... +</p> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Supported Systems and Drivers</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Supported Systems and Drivers</H1> + +<p> +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. +</p> + +<p>Others have contributed drivers +for the Amiga, Apple Macintosh, BeOS, NeXT, OS/2, MS-DOS, VMS, Windows +9x/NT, and Direct3D. +</p> + +<p> +The following files describe the details for various platforms. +Be warned, some of these files (and drivers) may be very out of date. +</p> + +<UL> +<LI><A HREF="README.X11">README.X11</A> - X Window System / Unix / Linux +<LI><A HREF="README.WIN32">README.WIN32</A> - Microsoft Windows +<LI><A HREF="README.VMS">README.VMS</A> - DEC VMS +<LI><A HREF="README.GGI">README.GGI</A> - GGI +<LI><A HREF="README.3DFX">README.3DFX</A> - 3Dfx/Glide driver +<LI><A HREF="README.AMIWIN">README.AMIWIN</A> - Amiga Amiwin +<LI><A HREF="README.BEOS">README.BEOS</A> - BeOS +<LI><A HREF="README.D3D">README.D3D</A> - Direct3D driver +<LI><A HREF="README.DJ">README.DJ</A> - DJGPP +<LI><A HREF="README.LYNXOS">README.LYNXOS</A> - LynxOS +<LI><A HREF="README.MINGW32">README.MINGW32</A> - Mingw32 +<LI><A HREF="README.NeXT">README.NeXT</A> - NeXT +<LI><A HREF="README.OpenStep">README.OpenStep</A> - OpenStep +<LI><A HREF="README.OS2">README.OS2</A> - OS/2 +<LI><A HREF="README.WINDML">README.WINDML</A> - WindML +</UL> + + +<p> +The standard Mesa distribution only supports software-based rendering, with +the exception of the 3Dfx Glide driver. +Information about other hardware support follows. +</p> + +<ul> +<li>DRI-based hardware support for 3dfx, Intel, Matrox, ATI with XFree86 +<blockquote> + <p>The <a href="http://dri.sourceforge.net/" target="_parent">DRI architecture</a>, + originally developed by Precision Insight, Inc. uses Mesa and + provides hardware acceleration for a number of popular chipsets.<br> + <br> + The DRI is part of XFree86 4.0 and later. + <br><br> + 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. +</blockquote> + + +<li>3dfx Voodoo1, Voodoo2, Voodoo Rush, Voodoo Banshee, Voodoo3 +<blockquote> +<p>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. +</p> +<p> +David Bucciarelli wrote the original 3dfx driver for Mesa.<br> +Daryll Strauss ported Glide to Linux. +</p> +</blockquote> + + +<li>Matrox G200/G400, nVidia RIVA, ATI Rage Pro, Intel i810 on Linux +<blockquote> +<p>The <a href="http://utah-glx.sourceforge.net/" target="_parent"> +Utah GLX project</a> +(no longer active) developed drivers for these chipsets and others. +</blockquote> + +<li>Amiga Warp3D +<blockquote> +<p>Amiga systems can support 3D hardware with the Warp3D API. +See <a href="http://www.haage-partner.com/3dworld" target="_parent">here</a>. +</blockquote> + +<li>Also see +<blockquote> +<p><a href="http://www.linux3d.org/" target="_parent">www.linux3d.org</a> for +other 3D hardware info for Linux. +</blockquote> + +</ul> + +<p> +<b><em>Note:</em></b> +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.</p> + + +</body> +</html>
\ 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 @@ +<HTML> + +<HEAD> +<TITLE>Acknowledgements</TITLE> +</HEAD> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Acknowledgments</H1> + + +The following individuals and groups are to be acknowledged for their +contributions to Mesa over the years. + + +<ul> +<li>Early Mesa development was done while Brian was part of the +<A HREF="http://www.ssec.wisc.edu/~billh/vis.html" +target="_parent">SSEC Visualization Project</A> at the University of +Wisconsin. He'd like to thank Bill Hibbard for letting him work on +Mesa as part of that project. +<br> +<br> +<li>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. +<br> +<br> +<li>Precision Insight, Inc., VA Linux Systems, Inc., and most recently, +Tungsten Graphics, Inc. have supported the ongoing development of Mesa. +<br> +<br> +<li>The <A HREF="http://sourceforge.net/projects/mesa3d" +target="_parent">Mesa</A> +project is hosted by<A HREF="http://sourceforge.net" +target="_parent"><IMG SRC="http://sourceforge.net/sflogo.php?group_id=3&type=1" +WIDTH="88" HEIGHT="31" ALIGN="BOTTOM" ALT="Sourceforge.net" BORDER="0"></A> +<br> +<br> + +<li><a href="http://www.altsoftware.com/" +target="_parent">alt.software</a> contributed the Direct3D driver. + +<li><b>Bernd Barsuhn</b> wrote the evaluator code for (splines, +patches) in Mesa. + +<li><b>Bernhard Tschirren</b> wrote the Allegro DJGPP driver. + +<li><b>Bogdan Sikorski</b> wrote the GLU NURBS and polygon tessellator +in Mesa. + +<li><b>Charlie Wallace</b> wrote the MS-DOS driver. + +<li><b>CJ Beyer</b> was the www.mesa3d.org webmaster. + +<li><b>Darren Abbott</b> provided the OS/2 driver. + +<li><b>David Bucciarelli</b> wrote and maintained the 3Dfx Glide +driver. Thousands of Linux/Quake players thank David! + +<li><b>Gareth Hughes</b> wrote new GLU 1.2 Polygon Tessellation code +(now superceded by SGI SI GLU). + +<li><b>Holger Waechtler</b> contributed AMD 3DNow! assembly code which +accelerates vertex transformation in Mesa 3.1. Holger also implemented +the GL_EXT_texture_env_combine extension. + +<li><b>Jeroen van der Zijp</b> and <b>Thorsten Ohl</b> contributed the +Xt/Motif widget code. + +<li><b>John Stone</b> provided the multi-threading support in Mesa 3.0. + +<li><b>John Watson</b> assisted with web page design. + +<li><b>Josh Vanderhoof</b> contributed Intel x86 assembly code which +accelerates vertex transformation in Mesa 3.x. + +<li><b>Jouk Jansen</b> contributed and continues to maintain the VMS +support. + +<li><b>Karl Schultz</b> has been maintaining the Windows driver. + +<li><b>Keith Whitwell</b> has made extension contributions to Mesa +since 1999. + +<li><b>Kendall Bennett</b> wrote the SciTech MGL driver. + +<li><b>Klaus Niederkrueger</b> contributed many improvements to Mesa's +software rasterizer. + +<li><b>Mark Kilgard</b> contributed antialiased line improvements and +several extensions. + +<li><b>Michael Pichler</b> contributed <em>many</em> bug fixes + +<li><b>Miklos Fazekas</b> wrote and maintains the Macintosh driver. + +<li><b>Pascal Thibaudeau</b> wrote the NeXT driver. + +<li><b>Pedro Vazquez</b> setup and maintains the Mesa Mailing list. + +<li><b>Randy Frank</b> contributed <em>many</em> bug fixes. + +<li><b>Stefan Zivkovic</b> wrote the Amiga driver. + +<li><b>Stephane Rehel</b> provided the Cygnus Win32 support + +<li><b>Ted Jump</b> maintained the +makefiles and project files for Windows 95/98/NT compilation for some time. + +<li><b>Uwe Maurer</b> wrote the LibGGI driver for Mesa-3.0. + +<li><b>Victor Ng-Thow-Hing</b> wrote the Amiwin driver for the Amiga. + +</ul> + +<p> +Apologies to anyone who's been omitted. +Please send corrections and additions to Brian. +</p> + + +</BODY> +</HTML> 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 @@ +<HTML> + +<TITLE>Development Utilities</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Development Utilities</H1> + +<ul> + +<li>The Mesa distribution includes several utility routines in the +progs/util/ directory + +<li>Allen Akin's <a href="http://glean.sourceforge.net/" +target="_parent">glean</a> is a framework for OpenGL testing. + +<li><a href="http://developer.kde.org/~sewardj/" +target="_parent">Valgrind</a> is a very useful tool for tracking down +memory-related problems in your code. + +</ul> + +</body> +</html>
\ 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 @@ +<HTML> + +<TITLE>Utilities</TITLE> + +<BODY text="#000000" bgcolor="#55bbff" link="#111188"> + +<H1>Utilities</H1> + +<ul> +<li><a href="http://fox.mit.edu/skunk/soft/fsv/" + target="_parent">fvs</a> - 3D file system visualizer + +<li><a href="http://www.dgp.utoronto.ca/%7Emac/projects/glbiff.html" + target="_parent">glbiff</a> - GL version of xbiff + +<li><a href="http://glload.netpedia.net/" target="_parent">glload</a> + - CPU load meter + +<li><a href="http://www.scitechsoft.com/gldirect.html" + target="_parent">SciTech GLDirect</a> - Driver to run OpenGL + apps using Direct3D under Windows + +<li><a href="http://threedsia.sourceforge.net/" + target="_parent">3Dsia</a> - 3D user interface + +<li><a href="http://mesa3d.sourceforge.net/notfound.html">VRML Site +Map</a> - 3D GUI + +<li><a href="http://www.vros.com/" target="_parent">VR/OS</a> - VR +user interface + +<li><a href="http://wauug.erols.com/%7Ebagleyd/" +target="_parent">xlockmore</a> - an X screen saver + +<li><a href="http://www.jwz.org/xscreensaver" +target="_parent">xscreensaver</a> - X screen saver + +</ul> + + +</body> +</html> 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 @@ +<HTML> + +<TITLE>Mesa Introduction</TITLE> + +<BODY text="#000000" bgcolor="#55bbff"> + +<H1>Webmaster</font></H1> + +<p> +If you have problems, edits or additions for this website send them +to Brian +(<em>b</em><em>r</em><em>i</em><em>a</em><em>n</em><em>_</em><em>e</em><em>_</em><em>p</em><em>a</em><em>u</em><em>l</em><em>@</em><em>y</em><em>a</em><em>h</em><em>o</em><em>o</em><em>.</em><em>c</em><em>o</em><em>m</em>)</a>. +</p> + +<p> +Mark Manning made the frame-based layout for the website. +Brian's modified it a lot since then. +</p> + + +</body> +</html>
\ No newline at end of file |