The EXT spec has been updated to:
- logically combine the es2_profile and es_profile exts
- allow any legal version to be requested
dEQP tests request a specific ES version when using GLX, so this allows
dEQP upstream to run against GLX with the appropriate X server patch
(which had similar disabling logic).
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v3)
v1 -> v2:
- distinguish between DRI_API_GLES{,2,3}
- add GLX_EXT_create_context_es_profile client-side support
v2 -> v3:
- fix error in computing mask
Without this this extension basically can't work in indirect contexts,
TexImage2D will compute the image size as 0 and we'll send no image data
to the server.
v2: Add EXT_texture_integer to the client extension list too (Ian)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
In response to another patch, Emil asked for some clarification how this
stuff works. Rather than just reply to the e-mail, I decided to update
the exlanation in the code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Previously GLX_EXT_create_context_es2_profile was marked as "direct
only" so that it would not depend on server support. Since the
extension required functions that are part of
GLX_ARB_create_context_profile, support for the EXT was disabled if the
ARB was not supported.
This was complete rubbish. If the server supported the ARB but not the
EXT, sending a request with GLX_CONTEXT_ES2_PROFILE_BIT_EXT would result
in GLXBadProfileARB.
Instead of the misguided hack, make GLX_EXT_create_context_es2_profile
properly depend on server support by not marking it as "direct only."
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Acked-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Previously GLX_EXT_buffer_age has always been advertised as supported because
both client_glx_support and client_glx_only where set. So it did not matter
that direct_support is only set when running dri3 and we ended up always
advertising it.
Fix that by not setting client_glx_only for buffer_age in known_glx_extensions.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
v2: Indent according to Mesa style, reuse sbc instead of making a new
swap_count field, and actually get a usable back before returning the
age of the back (fixing updated piglit tests). Changes by anholt.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Reviewed-by: Robert Bragg <robert@sixbynine.org> (v1)
Reviewed-by: Adel Gadllah <adel.gadllah@gmail.com> (v2)
Reviewed-by: Eric Anholt <eric@anholt.net>
From the GLX perspective, the ARB and EXT extensions are identical. Use
a single bit for both.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: Maciej Wieczorek <maciej.t.wieczorek@intel.com>
These calls allowed Xlib to use a custom memory allocator, but Xlib has
used the standard C library functions since at least its initial import
into git in 2003. It seems unlikely that it will grow a custom memory
allocator. The functions now just add extra overhead. Replacing them
will make future Coccinelle patches simpler.
This patch has been generated by the following Coccinelle semantic
patch:
// Remove Xcalloc/Xmalloc/Xfree calls
@@ expression E1, E2; @@
- Xcalloc (E1, E2)
+ calloc (E1, E2)
@@ expression E; @@
- Xmalloc (E)
+ malloc (E)
@@ expression E; @@
- Xfree (E)
+ free (E)
@@ expression E; @@
- XFree (E)
+ free (E)
Reviewed-by: Brian Paul <brianp@vmware.com>
Without that, people with buggy apps that looked at just the server
string for GLX_ARB_create_context would call this function that just
threw an error when you tried to make a context. Google shows plenty
of complaints about this.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Add the infrastructure required for this extension. There is no
xserver support and no driver support yet. Drivers can enable this be
advertising DRI2 version 4 and accepting the
__DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS flag and the
__DRI_CTX_ATTRIB_RESET_STRATEGY attribute in create context.
Some additional Mesa infrastructure is needed before drivers can do
this. The GL_ARB_robustness spec, which all Mesa drivers already
advertise, requires:
"If the behavior is LOSE_CONTEXT_ON_RESET_ARB, a graphics reset
will result in the loss of all context state, requiring the
recreation of all associated objects."
It is necessary to land this infrastructure now so that the related
infrastructure can land in the xserver. The xserver has very long
release schedules, and the remaining Mesa parts should land long, long
before the next xserver merge window opens.
v2: Expose robustness as a DRI2 extension rather than bumping
__DRI_DRI2_VERSION.
v3: Add a comment explaining why dri2->base.version >= 3 is also
required for GLX_ARB_create_context_robustness.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Detect whether a new enough version of XCB is installed at configure
time. If it is not, don't enable the extension and don't build the
unit tests.
v2: Move the AM_CONDIATION outside the case-statement so that it is
invoked even for non-GLX builds. This prevents build failures with
osmesa, for example.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Robert Hooker <robert.hooker@canonical.com>
A lot of tests in 'make check' will fail under these circumstances,
but at least the build should work.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This extension is only enabled if the underlying driver advertises
support for OpenGL ES 2.0. This happens either through the getAPIMask
function in version 2 of the DRI2 extension or implicity through
version 2 of the DRISW extension.
Since there is no OpenGL ES 2.0 protocol, this extension is marked as
only available with direct-rendering.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Note that these extensions are not automatically enabled for screens
capable of direct-rendering.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
All of the extensions require that both libGL and either the server or
the direct rendering driver (or both) enable the extension before it's
advertised. It seems safe to assume that none of the other components
on OS X will enable these extensions, so all the #ifdef blocks here
just clutter the code.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Jeremy Huddleston <jeremyhu@apple.com>
There are a few unsupported extensions (e.g., the ATI and NV float
extensions) that are still in the list. There is some small chance
that these may be supported some day.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
DRI2 supports this now - and already enables it explicitly - but drisw
does not and should not. Otherwise toolkits like clutter will only ever
SwapBuffers once and wait forever for an event that's not coming.
Signed-off-by: Adam Jackson <ajax@redhat.com>
this doesn't bind to drivers yet, just enough to in theory make indirect
work against other servers.
I'm really not sure what the rules for adding extensions to the known_gl_extensions list as it looks to be missing a few. are these GL extensions that have GLX
protocol??
Signed-off-by: Dave Airlie <airlied@redhat.com>
This extension allows a client to bind one context in multiple threads
simultaneously. It is then up to the client to manage synchronization of
access to the GL, just as normal multithreaded GL from multiple contexts
requires synchronization management to shared objects.
