For older extensions, there is an explanation first and the extension
name in brackets, like that:
Clamping controls (GL_ARB_color_buffer_float)
I inverted that so we have the extension first and then the explanation
in brackets, like that:
GL_ARB_color_buffer_float (Clamping controls)
It will help me later to parse the few extensions that use this syntax:
all drivers that support <GL_extension>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This fixes some exceptions I have to deal with in mesamatrix.net.
The extensions GL_ARB_texture_buffer_object had a comment between "DONE"
and the brackets.
And the extension GL_KHR_robustness (in GL 4.5 and GLES 3.1) was using
"90% done" instead of "in progress". The "90% done" is still here
though, but as an extension comment.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The "Status" column was misaligned in some GL sections.
This is a lot of diffs, but it's only spaces in the end.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Added a small guide on how to read and edit GL3.txt.
I think this would help as much the devs as the users reading this file.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Support in Mesa main and i965 has just been added.
v2: Include note in 'New Features' of docs/relnotes/11.3.0.html.
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Dead since commit d8a366200 in 2010.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: Brian Paul <brianp@vmware.com>
The two extensions are identical, and are largely taking bits of already
existing desktop functionality. We continue to do a poor job of
supporting the 'precise' keyword, just like we do on desktop.
This passes the relevant dEQP tests that I could find.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Only minor differences to the existing ARB_texture_border_clamp support.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
It's basically the same thing as GL_ARB_texture_stencil8 except that
glCopyTexImage isn't supported, so add STENCIL_INDEX to the list of
invalid GLES formats for glCopyTexImage.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eduardo Lima Mitev <elima@igalia.com>
When set to a truish value, this globally disables the minmax cache for all
buffer objects.
No #ifdef DEBUG guards because this option can be interesting for
benchmarking.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The freedesktop.org blog feeds aren't mentioned on either mesa3d.org or
any of the graphics project wikis (including the DRI wiki) on
freedeskop.org. Fix that by linking to it from the sidebar.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
We now support all Intel GPUs which can do tessellation.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Was enabled for i965 and nvc0 by following commits:
c875e3cdd239f51ec96f
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Fixes the following Lintian (Debian package checker) error:
privacy-breach-logo
usr/share/doc/mesa-common-dev/contents.html
(http://sourceforge.net/sflogo.php?group_id=3&type=1)
usr/share/doc/mesa-common-dev/thanks.html
(http://sourceforge.net/sflogo.php?group_id=3&type=1)
The extended description of this tag is:
This package creates a potential privacy breach by fetching a logo
at runtime.
Before using a local copy you should check that the logo is suitable
for main. You can get help with determining this by posting a link to
the logo and a copy of, or a link to, the logo copyright and license
information to the debian-legal mailing list.
Please replace any scripts, images, or other remote resources with
non-remote resources. It is preferable to replace them with text and
links but local copies of the remote resources are also acceptable as
long as they don't also make calls to remote services. Please ensure
that the remote resources are suitable for Debian main before making
local copies of them.
Severity: serious, Certainty: possible
Check: files, Type: binary, udeb
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Juan A. Suarez Romero
Romain Failliot
Ilia Mirkin
Timothy Arceri
Eduardo Lima Mitev
Matt Turner
Francisco Jerez
Rhys Kidd
Alejandro Piñeiro
Brian Paul
Emil Velikov
Dave Airlie
Marek Olšák
Nicolai Hähnle
Sarah Sharp
Kenneth Graunke
Tapani Pälli
Andreas Boll