It may be possible to trim the list of extensions futher. These are
just the obvious extensions that add functionality that the core context
explicitly forbids. Apple's core-context extension list is *just* the
extensions on top of the core GL version. I'm not sure we want to go
that far, but removing some things that have been in core since 2.1 may
be okay.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
To allow meta acceleration operations to use sampler objects the
ARB_sampler_objects extension needs to be mandatory for all drivers.
Because the extension doesn't have any hardware dependencies it is
trivial to implement.
Signed-off-by: Pauli Nieminen <pauli.nieminen@linux.intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This lets us select the front buffer for reading under GLES2.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
That adds support for activating the extension. It doesn't actually
*do* anything yet, of course.
Signed-off-by: Olivier Galibert <galibert@pobox.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This extension just permits GL_UNPACK_ROW_LENGTH, GL_UNPACK_SKIP_ROWS
and GL_UNPACK_SKIP_PIXELS to be passed to glPixelStore on GLES2 so it
is trivial to implement.
Also fixes the usage of GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES,
which may be set to a BGRA format e.g. for a MESA_FORMAT_ARGB8888 fb.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Add support for GL_OES_compressed_ETC1_RGB8_texture to core mesa. There is no
driver support yet.
Unlike desktop GL compressed texture formats, GLES compressed texture formats
usually can only be used with glCompressedTexImage2D. All other gl*Tex*Image*
functions are updated to check for that.
Reviewed-by: Brian Paul <brianp@vmware.com>
All drivers in Mesa have supported this extension for eons. This
extension is an optional features in desktop OpenGL (via
GL_ARB_draw_buffers) and OpenGL ES 2.x (via GL_NV_draw_buffers).
The extension is not usable in OpenGL ES 1.x. There is no
glDrawBuffers* entry point in OpenGL ES 1.x contexts, and glGet*v
generate errors when MAX_DRAW_BUFFERS or DRAW_BUFFERi is queried.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on mach64, mga, and savage
(Savage3D and other pre-Savage4).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on i810, mach64, mga,
savage, sis, and tdfx (Voodoo Banshee and Voodoo3).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on mach64.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
This extension was previously not supported on mach64, mga, or r128.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x. The existing support is already partially
broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x).
This patch does not change the situation in any way.
It looks like the only hardware supported by Mesa that cannot do
ARB_texture_env_combine is pre-NV10 NVIDA chips. It appears that
these chips cannot do the GL_SUBTRACT mode. Based on looking at older
copies of nvOpenGLspecs.pdf found on the net, NVIDIA never supported
ARB_texture_env_combine on those chips either.
This extension was previously not supported on mach64, mga (G200),
r128, savage, sis, and tdfx (Voodoo Banshee and Voodoo3).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x. The existing support is already partially
broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x).
This patch does not change the situation in any way.
This extension was previously not supported on mach64, mga (G200),
savage (Savage3D and other pre-Savage4), sis, and tdfx (Voodoo
Banshee).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x. The existing support is already partially
broken in Mesa (e.g., querying GL_CLIENT_ACTIVE_TEXTURE in OpenGL ES
2.x). This patch does not change the situation in any way.
This extension was previously not supported on i810, mga (G200), or
tdfx (Voodoo Banshee).
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is required in desktop OpenGL. The existing support is already partially
broken in Mesa (e.g., using format=GL_ABGR for glTexImage2D in OpenGL ES 2.x).
This patch does not change the situation in any way.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
All drivers remaining in Mesa support this extension. This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.
EXT_texture_format_BGRA8888 is mostly a subset of EXT_bgra. The only
difference seems to be that EXT_texture_format_BGRA8888 allows GL_BGRA
as an internal format to glTexImage2D and friends.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This extension is always enabled, and drivers do not have
to option to disable it.
I kept this one separate from the others because I was a little
uncertain about the changes to get.c.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Mesa has never any portion of this extension, and neither has any
other vendor.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The year 2006 apparently came from the "Last Modified Date" in the
spec header. however, the revision history at the bottom say "2/22/00
mjk - added NVIDIA Implementation Details." From that we can safely
infer that the spec is from at least 2000, and it may even be older.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
The following extensions are always enabled, and drivers do not have
to option to disable them:
GL_ARB_multisample
GL_ARB_texture_compression
GL_ARB_vertex_buffer_object / GL_OES_mapbuffer
GL_EXT_copy_texture
GL_EXT_multi_draw_arrays / GL_SUN_multi_draw_arrays
GL_EXT_polygon_offset
GL_EXT_subtexture
GL_EXT_texture_edge_clamp / GL_SGIS_texture_edge_clamp
GL_EXT_vertex_array
GL_SGIS_generate_mipmap
This set was picked because the are all either required or optional
features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. The
existing support for some is already partially broken in Mesa (e.g.,
proxy texture targets in OpenGL ES). This patch does not change the
situation in any way.
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
AFAIK, there are few users of this extension and I can see a couple
reasons why this is probably broken in Mesa anyway.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Support is removed for four reasons:
1. The implementation was broken with respect to separate blend
equations. The GL_EXT_blend_equation_separate spec says:
"If EXT_blend_logic_op and EXT_blend_equation_separate are both
supported, the logic op blend equation should be supported separately
for RGB and alpha as with the other blend equation modes."
But Mesa's implementation of GL_LOGIC_OP specifically forbids this.
2. No hardware supported by Mesa can support separate blend equations
involving GL_LOGIC_OP.
3. No applications could be found that use this extension.
4. No other Linux OpenGL drivers support this extension.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Cc: Brian Paul <brianp@vmware.com>
The last user of this function was driInitExtensions, and that function
was removed in a previous commit.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
==27540== Invalid read of size 4
==27540== at 0x96277B7: _mesa_make_extension_string (string3.h:144)
==27540== by 0x9604E78: _mesa_make_current (context.c:1514)
==27540== by 0x9602A8B: st_api_make_current (st_manager.c:789)
==27540== by 0x45406E7: ???
==27540== Address 0xad35b30 is 3,688 bytes inside a block of size 3,691 alloc'd
==27540== at 0x4025315: calloc (vg_replace_malloc.c:467)
==27540== by 0x9627641: _mesa_make_extension_string (extensions.c:910)
==27540== by 0x9604E78: _mesa_make_current (context.c:1514)
==27540== by 0x9602A8B: st_api_make_current (st_manager.c:789)
==27540== by 0x45406E7: ???
And:
==28351== Invalid write of size 2
==28351== at 0x4C087CC: _mesa_make_extension_string (string3.h:144)
==28351== by 0x4BE6198: _mesa_make_current (context.c:1514)
==28351== by 0x4BD4CAB: st_api_make_current (st_manager.c:789)
==28351== Address 0x48dd1f3 is 19 bytes inside a block of size 20 alloc'd
==28351== at 0x4025315: calloc (vg_replace_malloc.c:467)
==28351== by 0x4C08711: _mesa_make_extension_string (extensions.c:778)
==28351== by 0x4BE6198: _mesa_make_current (context.c:1514)
==28351== by 0x4BD4CAB: st_api_make_current (st_manager.c:789)
==28351==
==28351== Invalid read of size 4
==28351== at 0x4C087EC: _mesa_make_extension_string (extensions.c:806)
==28351== by 0x4BE6198: _mesa_make_current (context.c:1514)
==28351== by 0x4BD4CAB: st_api_make_current (st_manager.c:789)
==28351== Address 0x48dd1f4 is 0 bytes after a block of size 20 alloc'd
==28351== at 0x4025315: calloc (vg_replace_malloc.c:467)
==28351== by 0x4C08711: _mesa_make_extension_string (extensions.c:778)
==28351== by 0x4BE6198: _mesa_make_current (context.c:1514)
==28351== by 0x4BD4CAB: st_api_make_current (st_manager.c:789)
The first part adds 2, because ' ' and '\0' may be written at the end
of the buffer.
