After that commit, some dri2 protocol symbols were being checked from
places that weren't including dri2proto.h, effectively disabling some
valuable SwapBuffers codepaths.
I'd like to be able to build mesa on current distro releases without
having to upgrade from the standard dri2proto and glproto headers. With
this change I'm able to build on ancient releases such as Ubuntu 9-10...
In general, it would be nice to be able to build-test mesa to check for
unintended breakages without having to follow the external dependencies
of every group working on the codebase.
Seems to introduce no changes to the build of libglapi.a when tested against
new versions of the headers.
At init time, NULL out the hooks that send the server new requests.
DRI2 never supported these extensions, so this preserves old behavior on
old servers with new Mesa.
Add support for the DRI2SwapInterval protocol request. This allows
direct rendered clients to control their swap interval per the
SGI_swap_control extension.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Add OML_sync_control support, along with a simple program for testing
it. This means adding support for the DRI2GetMSC, DRI2WaitMSC and
DRI2WaitSBC requests.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Support the new DRI2 protocol request, DRI2SwapBuffers, in both direct
and indirect rendering context. This request allows the display server
to optimize back->front swaps (e.g. through page flipping) and allows us
to more easily support other GLX features like swap interval and the OML
sync extension in DRI2.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Assume that the front-buffer exists even if the server didn't tell the
client that it exists.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
This scheme breaks when the display connection doesn't receive ConfigureNotify
events. This caused reporoducible problems (cropped / misplaced output) when
starting a 3D application in a guest operating system in VMware Workstation.
This reverts commit dd1c68f151.
Conflicts:
src/glx/x11/dri2_glx.c
We only wanted to request when asked for the same set of buffers when a resize
has happened. We can just watch the protocol stream for a ConfigureNotify
and flag to do it then.
This is about a 5% win from doing two glViewport()s per frame in openarena.
Add DRI2 direct rendering support to libGL and add DRI2 client side
protocol code. Extend the GLX 1.3 create drawable functions in
glx_pbuffer.c to call into the DRI driver when possible.
Introduce __DRIconfig, opaque struct that represents a DRI driver
configuration. Get's rid of the open coded __GLcontextModes in the
DRI driver interface and the context modes create and destroy
functions that the loader was requires to provide. glcore.h is no
longer part of the DRI driver interface. The DRI config is GL binding
agnostic, that is, not specific to GLX, EGL or other bindings.
The core API is now also an extension, and the driver exports a list
of extensions as the symbol __driDriverExtensions, which the loader
must dlsym() for. The list of extension will always include the DRI
core extension, which allows creating and manipulating DRI screens,
drawables and contexts. The DRI legacy extension, when available,
provides alternative entry points for creating the DRI objects that
work with the XF86DRI infrastructure.
Change DRI2 client code to not use drm drawables or contexts. We
never used drm_drawable_t's and the only use for drm_context_t was as
a unique identifier when taking the lock. We now just allocate a
unique lock ID out of the DRILock sarea block. Once we get rid of the
lock entirely, we can drop this hack.
Change the interface between dri_util.c and the drivers, so that the
drivers now export the DriverAPI struct as driDriverAPI instead of the
InitScreen entry point. This lets us avoid dlsym()'ing for the DRI2
init screen function to see if DRI2 is supported by the driver.