fdo-mirrors/mesa
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2025-12-21 05:00:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
mesa/src/mesa/drivers/dri/common/dri_util.c

939 lines
25 KiB
C
Raw Normal View History

First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* $XFree86: xc/lib/GL/dri/dri_util.c,v 1.7 2003/04/28 17:01:25 dawes Exp $ */
/**
* \file dri_util.c
* DRI utility functions.
*
* This module acts as glue between GLX and the actual hardware driver. A DRI
* driver doesn't really \e have to use any of this - it's optional. But, some
* useful stuff is done here that otherwise would have to be duplicated in most
* drivers.
*
* Basically, these utility functions take care of some of the dirty details of
* screen initialization, context creation, context binding, DRM setup, etc.
*
* These functions are compiled into each DRI driver so libGL.so knows nothing
* about them.
*/
#include <assert.h>
#include <stdarg.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdio.h>
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
uint*t -> u_int*t changes
2004-12-14 09:11:52 +00:00
#ifndef MAP_FAILED
#define MAP_FAILED ((void *)-1)
#endif
mesa: added "main/" prefix to includes, remove some -I paths from Makefile.template
2008-09-18 15:17:05 -06:00
#include "main/imports.h"
All elements of pre-DRI_NEW_INTERFACE_ONLY are removed. This allows 1,402 lines of code to be removed from Mesa (drivers and libGL). The big winner is dri_util.c. Primary changes are: 1. Remove all "deprecated" entry-points from the various structures in dri_interface.h. 2. Rename the remaining fields to removed "version numbers." So, bindContext3 becomes bindContext. Functions with "New" in the name (e.g., CreateNewContext) were *not* changed, but that is an option. Having "New" in the name is less annoying to me than having "3" in the name. 3. Remove all compatibility code that handles cases where the driver or the loader is too old to support the latest interfaces. 4. Append the API version to the __driCreateNewScreen function name. This is currently done by hand. In the future (i.e., the next time we make an incompatible change to the interface) we'll want to come up with a better way to do this. This prevents old loaders from being able to load new (incompatible) drivers. 5. Bump the API version to 20050722. All drivers (by way of dri_util.c) require this version. 6. All drivers are *required* to expose GLX_SGIX_fbconfig and GLX_OML_swap_method (or the moral equivalents). Support for these functions in implicit in the use of the "new" interface. 7. Some cases still exist that need to be compiled differently in a loader or core Mesa versus in a driver. These are identified by the define IN_DRI_DRIVER.
2005-07-24 06:29:14 +00:00
#define None 0
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
#include "dri_util.h"
Removed need for sarea.h, various touch ups to get rid of type mismatches.
2004-06-02 22:45:00 +00:00
#include "drm_sarea.h"
Make utils.h self-contained. Move stuff with drm dependencies to dri_util.h, and move a couple of types without drm dependencies to utils.h.
2008-05-11 14:43:22 +03:00
#include "utils.h"
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
Revert revision 1.13. This allows server-side libGLcore (in X.org) to build with Mesa CVS. This change was wrong in the first place, and the issue that necessitated it has been resolved. For more background on the problem see: http://marc.theaimsgroup.com/?l=mesa3d-dev&m=111333880529935&w=2
2005-04-13 18:41:33 +00:00
#ifndef GLX_OML_sync_control
Drop __DRInativeDisplay and pass in __DRIscreen pointers instead. Many DRI entry points took a __DRInativeDisplay pointer and a screen index as arguments. The only use for the native display pointer was to pass it back to the loader when looking up the __DRIscreen for the given screen index. Instead, let's just pass in the __DRIscreen pointer directly, which let's drop the __DRInativeDisplay type and the getScreen function. The assumption is now that the loader will be able to retrieve context from the __DRIscreen pointer when necessary.
2007-05-10 15:52:22 -04:00
typedef GLboolean ( * PFNGLXGETMSCRATEOMLPROC) (__DRIdrawable *drawable, int32_t *numerator, int32_t *denominator);
Define PFNGLXGETMSCRATEOMLPROC so that DRI will build without including glxext.h.
2004-05-27 22:49:12 +00:00
#endif
Add a DRI_ReadDrawable marker extension to signal read drawable capability.
2007-05-17 14:39:06 -04:00
/**
* This is just a token extension used to signal that the driver
* supports setting a read drawable.
*/
const __DRIextension driReadDrawableExtension = {
Add a version field to __DRIextension.
2007-06-07 19:35:54 -04:00
__DRI_READ_DRAWABLE, __DRI_READ_DRAWABLE_VERSION
Add a DRI_ReadDrawable marker extension to signal read drawable capability.
2007-05-17 14:39:06 -04:00
};
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/**
* Print message to \c stderr if the \c LIBGL_DEBUG environment variable
* is set.
*
* Is called from the drivers.
*
* \param f \c printf like format string.
*/
void
__driUtilMessage(const char *f, ...)
{
va_list args;
if (getenv("LIBGL_DEBUG")) {
fprintf(stderr, "libGL error: \n");
va_start(args, f);
vfprintf(stderr, f, args);
va_end(args);
fprintf(stderr, "\n");
}
}
Make utils.h self-contained. Move stuff with drm dependencies to dri_util.h, and move a couple of types without drm dependencies to utils.h.
2008-05-11 14:43:22 +03:00
GLint
driIntersectArea( drm_clip_rect_t rect1, drm_clip_rect_t rect2 )
{
if (rect2.x1 > rect1.x1) rect1.x1 = rect2.x1;
if (rect2.x2 < rect1.x2) rect1.x2 = rect2.x2;
if (rect2.y1 > rect1.y1) rect1.y1 = rect2.y1;
if (rect2.y2 < rect1.y2) rect1.y2 = rect2.y2;
if (rect1.x1 > rect1.x2 || rect1.y1 > rect1.y2) return 0;
return (rect1.x2 - rect1.x1) * (rect1.y2 - rect1.y1);
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/*****************************************************************/
/** \name Context (un)binding functions */
/*****************************************************************/
/*@{*/
/**
* Unbind context.
*
Drop __DRInativeDisplay and pass in __DRIscreen pointers instead. Many DRI entry points took a __DRInativeDisplay pointer and a screen index as arguments. The only use for the native display pointer was to pass it back to the loader when looking up the __DRIscreen for the given screen index. Instead, let's just pass in the __DRIscreen pointer directly, which let's drop the __DRInativeDisplay type and the getScreen function. The assumption is now that the loader will be able to retrieve context from the __DRIscreen pointer when necessary.
2007-05-10 15:52:22 -04:00
* \param scrn the screen.
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
* \param gc context.
*
* \return \c GL_TRUE on success, or \c GL_FALSE on failure.
*
* \internal
* This function calls __DriverAPIRec::UnbindContext, and then decrements
* __DRIdrawablePrivateRec::refcount which must be non-zero for a successful
* return.
*
* While casting the opaque private pointers associated with the parameters
* into their respective real types it also assures they are not \c NULL.
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static int driUnbindContext(__DRIcontext *pcp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
__DRIscreen *psp;
__DRIdrawable *pdp;
__DRIdrawable *prp;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/*
** Assume error checking is done properly in glXMakeCurrent before
All elements of pre-DRI_NEW_INTERFACE_ONLY are removed. This allows 1,402 lines of code to be removed from Mesa (drivers and libGL). The big winner is dri_util.c. Primary changes are: 1. Remove all "deprecated" entry-points from the various structures in dri_interface.h. 2. Rename the remaining fields to removed "version numbers." So, bindContext3 becomes bindContext. Functions with "New" in the name (e.g., CreateNewContext) were *not* changed, but that is an option. Having "New" in the name is less annoying to me than having "3" in the name. 3. Remove all compatibility code that handles cases where the driver or the loader is too old to support the latest interfaces. 4. Append the API version to the __driCreateNewScreen function name. This is currently done by hand. In the future (i.e., the next time we make an incompatible change to the interface) we'll want to come up with a better way to do this. This prevents old loaders from being able to load new (incompatible) drivers. 5. Bump the API version to 20050722. All drivers (by way of dri_util.c) require this version. 6. All drivers are *required* to expose GLX_SGIX_fbconfig and GLX_OML_swap_method (or the moral equivalents). Support for these functions in implicit in the use of the "new" interface. 7. Some cases still exist that need to be compiled differently in a loader or core Mesa versus in a driver. These are identified by the define IN_DRI_DRIVER.
2005-07-24 06:29:14 +00:00
** calling driUnbindContext.
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
if (pcp == NULL)
Drop __DRInativeDisplay and pass in __DRIscreen pointers instead. Many DRI entry points took a __DRInativeDisplay pointer and a screen index as arguments. The only use for the native display pointer was to pass it back to the loader when looking up the __DRIscreen for the given screen index. Instead, let's just pass in the __DRIscreen pointer directly, which let's drop the __DRInativeDisplay type and the getScreen function. The assumption is now that the loader will be able to retrieve context from the __DRIscreen pointer when necessary.
2007-05-10 15:52:22 -04:00
return GL_FALSE;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
psp = pcp->driScreenPriv;
pdp = pcp->driDrawablePriv;
prp = pcp->driReadablePriv;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* Let driver unbind drawable from context */
(*psp->DriverAPI.UnbindContext)(pcp);
if (pdp->refcount == 0) {
/* ERROR!!! */
return GL_FALSE;
}
pdp->refcount--;
if (prp != pdp) {
if (prp->refcount == 0) {
/* ERROR!!! */
return GL_FALSE;
}
prp->refcount--;
}
/* XXX this is disabled so that if we call SwapBuffers on an unbound
* window we can determine the last context bound to the window and
* use that context's lock. (BrianP, 2-Dec-2000)
*/
#if 0
/* Unbind the drawable */
pcp->driDrawablePriv = NULL;
pdp->driContextPriv = &psp->dummyContextPriv;
#endif
return GL_TRUE;
}
/**
* This function takes both a read buffer and a draw buffer. This is needed
* for \c glXMakeCurrentReadSGI or GLX 1.3's \c glXMakeContextCurrent
* function.
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static int driBindContext(__DRIcontext *pcp,
__DRIdrawable *pdp,
__DRIdrawable *prp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
Drop __DRInativeDisplay and pass in __DRIscreen pointers instead. Many DRI entry points took a __DRInativeDisplay pointer and a screen index as arguments. The only use for the native display pointer was to pass it back to the loader when looking up the __DRIscreen for the given screen index. Instead, let's just pass in the __DRIscreen pointer directly, which let's drop the __DRInativeDisplay type and the getScreen function. The assumption is now that the loader will be able to retrieve context from the __DRIscreen pointer when necessary.
2007-05-10 15:52:22 -04:00
__DRIscreenPrivate *psp = pcp->driScreenPriv;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* Bind the drawable to the context */
dri glx: Fix dri_util::driBindContext 1) Don't error-check here. It's done in glx makeCurrent. 2) Allow ctx and the dri drawables to be NULL for future use. This is currently blocked in glx makeCurrent. 3) Avoid updating dri drawables unless they are completely uninitialized. Since the updating was done outside of the lock, the driver need to verify and redo it anyway. Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
2009-04-02 10:36:40 +02:00
if (pcp) {
pcp->driDrawablePriv = pdp;
pcp->driReadablePriv = prp;
if (pdp) {
pdp->driContextPriv = pcp;
pdp->refcount++;
}
if ( prp && pdp != prp ) {
prp->refcount++;
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
/*
** Now that we have a context associated with this drawable, we can
** initialize the drawable information if has not been done before.
*/
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
if (!psp->dri2.enabled) {
dri glx: Fix dri_util::driBindContext 1) Don't error-check here. It's done in glx makeCurrent. 2) Allow ctx and the dri drawables to be NULL for future use. This is currently blocked in glx makeCurrent. 3) Avoid updating dri drawables unless they are completely uninitialized. Since the updating was done outside of the lock, the driver need to verify and redo it anyway. Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
2009-04-02 10:36:40 +02:00
if (pdp && !pdp->pStamp) {
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
__driUtilUpdateDrawableInfo(pdp);
DRM_SPINUNLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
}
dri glx: Fix dri_util::driBindContext 1) Don't error-check here. It's done in glx makeCurrent. 2) Allow ctx and the dri drawables to be NULL for future use. This is currently blocked in glx makeCurrent. 3) Avoid updating dri drawables unless they are completely uninitialized. Since the updating was done outside of the lock, the driver need to verify and redo it anyway. Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
2009-04-02 10:36:40 +02:00
if (prp && pdp != prp && !prp->pStamp) {
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
__driUtilUpdateDrawableInfo(prp);
DRM_SPINUNLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
dri glx: Fix dri_util::driBindContext 1) Don't error-check here. It's done in glx makeCurrent. 2) Allow ctx and the dri drawables to be NULL for future use. This is currently blocked in glx makeCurrent. 3) Avoid updating dri drawables unless they are completely uninitialized. Since the updating was done outside of the lock, the driver need to verify and redo it anyway. Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
2009-04-02 10:36:40 +02:00
}
Track the currently bound read drawable and make sure its info is up to date.
2006-10-16 20:59:53 +00:00
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* Call device-specific MakeCurrent */
dri glx: Propagate driver MakeCurrent errors. Signed-off-by: Thomas Hellstrom <thellstrom-at-vmware-dot-com>
2009-04-02 10:30:30 +02:00
return (*psp->DriverAPI.MakeCurrent)(pcp, pdp, prp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
/*@}*/
/*****************************************************************/
/** \name Drawable handling functions */
/*****************************************************************/
/*@{*/
/**
* Update private drawable information.
*
* \param pdp pointer to the private drawable information to update.
*
* This function basically updates the __DRIdrawablePrivate struct's
Fixes the glXGetProcAddress portion of the interface. Most of the functions that are currently obtained via glXGetProcAddress and all of the XF86DRI functions are replaced with a funciton table. This table will be passed to __driCreateNewScreen. One of the functions in the table is getProcAddress. This allows some loaders to expose functionality not in all loaders. This will be immediatly used for glxEnableExtension (formerly known to drivers as __glXScrEnableExtension). libGL (and in the future libglx) expose this function so that drivers can enable GLX extensions. libEGL should exposed eglEnableExtension to enable EGL extensions. The same function cannot be used for both because the extensions have different names and (possibly) different semantics. Drivers can optionally use one, both, or neither. The key parts are in the __DRIinterfaceMethodsRec structure in dri_interface.h. A pointer to one of these structures is passed into __driCreateNewScreen. Because of this, the version of the API is bumped to 20050725. Since the previous version(s) were never in a release, their existance is erased. I was actually a little surprised by how much code this cuts from the drivers. A lot of glXGetProcAddress calls disappear, and a lot of version checks go with them. Nice. The one thing I'm not sure of is removing __glXInitialize. For some reason that function was in the glXGetProcAddress table, but *nothing* in the Mesa tree used it. Did something with DRI conf. use this function? It seems odd...
2005-07-26 02:44:01 +00:00
* cliprect information by calling \c __DRIinterfaceMethods::getDrawableInfo.
* This is usually called by the DRI_VALIDATE_DRAWABLE_INFO macro which
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
* compares the __DRIdrwablePrivate pStamp and lastStamp values. If
* the values are different that means we have to update the clipping
* info.
*/
void
__driUtilUpdateDrawableInfo(__DRIdrawablePrivate *pdp)
{
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
__DRIscreenPrivate *psp = pdp->driScreenPriv;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
__DRIcontextPrivate *pcp = pdp->driContextPriv;
Track the currently bound read drawable and make sure its info is up to date.
2006-10-16 20:59:53 +00:00
if (!pcp
|| ((pdp != pcp->driDrawablePriv) && (pdp != pcp->driReadablePriv))) {
Fix an infinite loop error that may occur when many contexts are bound to the same drawable in a multithreading environment. This one slipped out of the texman merge.
2006-12-01 12:41:43 +00:00
/* ERROR!!!
* ...but we must ignore it. There can be many contexts bound to a
* drawable.
*/
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
if (pdp->pClipRects) {
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pdp->pClipRects);
Clear pointers to freed cliprects. Not doing this could lead to double frees under rare circumstances.
2007-07-10 10:49:28 +02:00
pdp->pClipRects = NULL;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
if (pdp->pBackClipRects) {
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pdp->pBackClipRects);
Clear pointers to freed cliprects. Not doing this could lead to double frees under rare circumstances.
2007-07-10 10:49:28 +02:00
pdp->pBackClipRects = NULL;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
DRM_SPINUNLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
if (! (*psp->getDrawableInfo->getDrawableInfo)(pdp,
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
&pdp->index, &pdp->lastStamp,
&pdp->x, &pdp->y, &pdp->w, &pdp->h,
&pdp->numClipRects, &pdp->pClipRects,
&pdp->backX,
&pdp->backY,
&pdp->numBackClipRects,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
&pdp->pBackClipRects,
pdp->loaderPrivate)) {
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* Error -- eg the window may have been destroyed. Keep going
* with no cliprects.
*/
pdp->pStamp = &pdp->lastStamp; /* prevent endless loop */
pdp->numClipRects = 0;
pdp->pClipRects = NULL;
pdp->numBackClipRects = 0;
pdp->pBackClipRects = NULL;
}
else
pdp->pStamp = &(psp->pSAREA->drawableTable[pdp->index].stamp);
DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID);
}
/*@}*/
/*****************************************************************/
/** \name GLX callbacks */
/*****************************************************************/
/*@{*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static void driReportDamage(__DRIdrawable *pdp,
struct drm_clip_rect *pClipRects, int numClipRects)
{
__DRIscreen *psp = pdp->driScreenPriv;
/* Check that we actually have the new damage report method */
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
if (psp->damage) {
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
/* Report the damage. Currently, all our drivers draw
* directly to the front buffer, so we report the damage there
* rather than to the backing storein (if any).
*/
(*psp->damage->reportDamage)(pdp,
pdp->x, pdp->y,
pClipRects, numClipRects,
GL_TRUE, pdp->loaderPrivate);
}
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/**
* Swap buffers.
*
* \param drawablePrivate opaque pointer to the per-drawable private info.
*
* \internal
* This function calls __DRIdrawablePrivate::swapBuffers.
*
* Is called directly from glXSwapBuffers().
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static void driSwapBuffers(__DRIdrawable *dPriv)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
__DRIscreen *psp = dPriv->driScreenPriv;
dri: correct the damage. Fixes bug #17234
2009-01-06 11:22:19 +08:00
drm_clip_rect_t *rects;
int i;
Don't Swap buffer if a DRIDrawable is entirely obscured by another window.
2007-12-05 10:31:35 +08:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
psp->DriverAPI.SwapBuffers(dPriv);
Add reporting of damage by DRI drivers when the extension support is available. With this, tools like ximagesrc in gstreamer correctly see updates from GL rendering. Support requires that the Xdamage library be current (but will be disabled if not present) plus a new X Server with support for the new XDamagePost request. libGL now has a new interface version, and also links against libXdamage and libXfixes to support it, but backwards compatibility is retained. Currently, all drivers report damage at SwapBuffers time through common code -- front buffer rendering doesn't result in damage being reported. Also, the damage is against the root window, as our drivers don't yet render to backing store when they should (composited environments).
2007-01-05 18:19:58 -08:00
dri glx: Swap before checking for cliprects. We don't update drawables anymore unless they are completely uninitialized, so we need to swap even if we don't have cliprects yet, otherwise we never end up calling the driver's SwapBuffers(). The driver should update the drawable in its SwapBuffers() anyway. See 8e753d04045a82062ac34d3b2622eb9dba8af374, "dri glx: Fix dri_util::driBindContext" for the change that exposed it.
2009-04-13 21:24:44 -04:00
if (!dPriv->numClipRects)
return;
dri: correct the damage. Fixes bug #17234
2009-01-06 11:22:19 +08:00
rects = _mesa_malloc(sizeof(*rects) * dPriv->numClipRects);
if (!rects)
return;
for (i = 0; i < dPriv->numClipRects; i++) {
rects[i].x1 = dPriv->pClipRects[i].x1 - dPriv->x;
rects[i].y1 = dPriv->pClipRects[i].y1 - dPriv->y;
rects[i].x2 = dPriv->pClipRects[i].x2 - dPriv->x;
rects[i].y2 = dPriv->pClipRects[i].y2 - dPriv->y;
}
driReportDamage(dPriv, rects, dPriv->numClipRects);
_mesa_free(rects);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static int driDrawableGetMSC( __DRIscreen *sPriv, __DRIdrawable *dPriv,
Refactor and fix core vblank support Consolidate support for synchronizing to and retrieving vblank counters. Also fix the core vblank code to return monotonic MSC counters, which are required by some GLX extensions. Adding support for multiple pipes to a low level driver is fairly easy, the Intel 965 driver provides simple example code (see intel_buffers.c:intelWindowMoved()). The new code bumps the media stream counter extension version to 2 and adds a new getDrawableMSC callback. This callback takes a drawablePrivate pointer, which is used to calculate the MSC value seen by clients based on the actual vblank counter(s) returned from the kernel. The new drawable private fields are as follows: - vblSeq - used for tracking vblank counts for buffer swapping - vblFlags - flags (e.g. current pipe), updated by low level driver - msc_base - MSC counter from the last time the current pipe changed - vblank_base - kernel DRM vblank counter from the last time the pipe changed Using the above variables, the core vblank code (in vblank.c) can calculate a monotonic MSC value. The low level DRI drivers are responsible for updating the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags) along with msc_base and vblank_base whenever the pipe associated with a given drawable changes (again, see intelWindowMoved for an example of this). Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to driDrawableGetMSC32 and add code for pipe switching as outlined above to fully support the new scheme.
2007-10-29 11:56:31 -07:00
int64_t *msc )
{
Remove GetMSC DriverAPI function. The DriverAPI is internal to the DRI drivers and GetDrawableMSC obsoletes GetMSC. Also, since the DRI driver interface has not yet been released, just drop the getMSC function from the DRI interface instead using the ABI preserving version mechanism. Finally, using void pointer privates in the DRI interface is not allowed, always pass the actual types around (__DRIdrawable in this case) to enhance type safety and readability of the code.
2008-02-25 16:14:37 -05:00
return sPriv->DriverAPI.GetDrawableMSC(sPriv, dPriv, msc);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static int driWaitForMSC(__DRIdrawable *dPriv, int64_t target_msc,
Convert all DRI entrypoints to take pointers to __DRI* types. The entrypoints take a mix of __DRIscreen * and void * (screen private) arguments (similarly for contexts and drawables). This patch does away with passing the private void pointer and always only passes the fully typed __DRIscreen pointer and always as the first argument. This makes the interface more consistent and increases type safety, and catches a bug where we would pass a screen private to DRIdrawable::getSBC.
2007-05-11 16:43:20 -04:00
int64_t divisor, int64_t remainder,
int64_t * msc, int64_t * sbc)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
__DRIswapInfo sInfo;
int status;
status = dPriv->driScreenPriv->DriverAPI.WaitForMSC( dPriv, target_msc,
divisor, remainder,
msc );
/* GetSwapInfo() may not be provided by the driver if GLX_SGI_video_sync
* is supported but GLX_OML_sync_control is not. Therefore, don't return
* an error value if GetSwapInfo() is not implemented.
*/
if ( status == 0
&& dPriv->driScreenPriv->DriverAPI.GetSwapInfo ) {
status = dPriv->driScreenPriv->DriverAPI.GetSwapInfo( dPriv, & sInfo );
*sbc = sInfo.swap_count;
}
return status;
}
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
Move media stream counter entry points to new extension.
2007-05-16 18:13:41 -04:00
const __DRImediaStreamCounterExtension driMediaStreamCounterExtension = {
Add a version field to __DRIextension.
2007-06-07 19:35:54 -04:00
{ __DRI_MEDIA_STREAM_COUNTER, __DRI_MEDIA_STREAM_COUNTER_VERSION },
Move media stream counter entry points to new extension.
2007-05-16 18:13:41 -04:00
driWaitForMSC,
Refactor and fix core vblank support Consolidate support for synchronizing to and retrieving vblank counters. Also fix the core vblank code to return monotonic MSC counters, which are required by some GLX extensions. Adding support for multiple pipes to a low level driver is fairly easy, the Intel 965 driver provides simple example code (see intel_buffers.c:intelWindowMoved()). The new code bumps the media stream counter extension version to 2 and adds a new getDrawableMSC callback. This callback takes a drawablePrivate pointer, which is used to calculate the MSC value seen by clients based on the actual vblank counter(s) returned from the kernel. The new drawable private fields are as follows: - vblSeq - used for tracking vblank counts for buffer swapping - vblFlags - flags (e.g. current pipe), updated by low level driver - msc_base - MSC counter from the last time the current pipe changed - vblank_base - kernel DRM vblank counter from the last time the pipe changed Using the above variables, the core vblank code (in vblank.c) can calculate a monotonic MSC value. The low level DRI drivers are responsible for updating the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags) along with msc_base and vblank_base whenever the pipe associated with a given drawable changes (again, see intelWindowMoved for an example of this). Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to driDrawableGetMSC32 and add code for pipe switching as outlined above to fully support the new scheme.
2007-10-29 11:56:31 -07:00
driDrawableGetMSC,
Move media stream counter entry points to new extension.
2007-05-16 18:13:41 -04:00
};
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static void driCopySubBuffer(__DRIdrawable *dPriv,
Dave Reveman's patch for GLX_MESA_copy_sub_buffer support
2006-03-31 15:48:04 +00:00
int x, int y, int w, int h)
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
drm_clip_rect_t rect;
rect.x1 = x;
Report correct damage rectangle in CopySubBuffer.
2008-05-29 11:24:16 +02:00
rect.y1 = dPriv->h - y - h;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
rect.x2 = x + w;
Report correct damage rectangle in CopySubBuffer.
2008-05-29 11:24:16 +02:00
rect.y2 = rect.y1 + h;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driReportDamage(dPriv, &rect, 1);
Report damage before modifying the area, not after. If we copy the area before reporting the damage in this area, the server may restore buffered data over the new data, leading to artefacts on the screen. Reproducable with two cursors (second of which is SW rendered) and moving windows around in compiz. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=16384 .
2008-08-21 11:22:40 +02:00
dPriv->driScreenPriv->DriverAPI.CopySubBuffer(dPriv, x, y, w, h);
Dave Reveman's patch for GLX_MESA_copy_sub_buffer support
2006-03-31 15:48:04 +00:00
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
Move the copySubBuffer extension over to the new mechanism.
2007-05-15 15:17:30 -04:00
const __DRIcopySubBufferExtension driCopySubBufferExtension = {
Add a version field to __DRIextension.
2007-06-07 19:35:54 -04:00
{ __DRI_COPY_SUB_BUFFER, __DRI_COPY_SUB_BUFFER_VERSION },
driCopySubBuffer
Move the copySubBuffer extension over to the new mechanism.
2007-05-15 15:17:30 -04:00
};
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static void driSetSwapInterval(__DRIdrawable *dPriv, unsigned int interval)
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
dPriv->swap_interval = interval;
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static unsigned int driGetSwapInterval(__DRIdrawable *dPriv)
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
return dPriv->swap_interval;
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
}
const __DRIswapControlExtension driSwapControlExtension = {
Add a version field to __DRIextension.
2007-06-07 19:35:54 -04:00
{ __DRI_SWAP_CONTROL, __DRI_SWAP_CONTROL_VERSION },
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
driSetSwapInterval,
driGetSwapInterval
};
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/**
* This is called via __DRIscreenRec's createNewDrawable pointer.
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static __DRIdrawable *
driCreateNewDrawable(__DRIscreen *psp, const __DRIconfig *config,
drm_drawable_t hwDrawable, int renderType,
const int *attrs, void *data)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
__DRIdrawable *pdp;
Require libGL API version 20040602, which actually exports __glXGetDrawableInfo. Make sure driCreateNewDrawable sets pdraw->private to NULL for all failure paths.
2004-06-02 22:24:00 +00:00
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* Since pbuffers are not yet supported, no drawable attributes are
* supported either.
*/
(void) attrs;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
pdp = _mesa_malloc(sizeof *pdp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
if (!pdp) {
return NULL;
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
pdp->loaderPrivate = data;
Drop createDrawable and destroyDrawable fron DRIinterfaceMethods. All the DRI driver did was call the createDrawable callback immediately upon entry to DRIscreen::createNewDrawable to get the drm_drawable_t. We can just call that before calling into the DRI driver and pass the returned drm_drawable_t as an argument to the DRI entry point. Likewise for destroyDrawable. Also, DRIdrawablePrivate::draw isn't used anywhere, and since the driver no longer needs the XID of the drawable we can now drop that.
2007-05-10 17:14:38 -04:00
pdp->hHWDrawable = hwDrawable;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
pdp->refcount = 0;
pdp->pStamp = NULL;
pdp->lastStamp = 0;
pdp->index = 0;
pdp->x = 0;
pdp->y = 0;
pdp->w = 0;
pdp->h = 0;
pdp->numClipRects = 0;
pdp->numBackClipRects = 0;
pdp->pClipRects = NULL;
pdp->pBackClipRects = NULL;
Refactor and fix core vblank support Consolidate support for synchronizing to and retrieving vblank counters. Also fix the core vblank code to return monotonic MSC counters, which are required by some GLX extensions. Adding support for multiple pipes to a low level driver is fairly easy, the Intel 965 driver provides simple example code (see intel_buffers.c:intelWindowMoved()). The new code bumps the media stream counter extension version to 2 and adds a new getDrawableMSC callback. This callback takes a drawablePrivate pointer, which is used to calculate the MSC value seen by clients based on the actual vblank counter(s) returned from the kernel. The new drawable private fields are as follows: - vblSeq - used for tracking vblank counts for buffer swapping - vblFlags - flags (e.g. current pipe), updated by low level driver - msc_base - MSC counter from the last time the current pipe changed - vblank_base - kernel DRM vblank counter from the last time the pipe changed Using the above variables, the core vblank code (in vblank.c) can calculate a monotonic MSC value. The low level DRI drivers are responsible for updating the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags) along with msc_base and vblank_base whenever the pipe associated with a given drawable changes (again, see intelWindowMoved for an example of this). Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to driDrawableGetMSC32 and add code for pipe switching as outlined above to fully support the new scheme.
2007-10-29 11:56:31 -07:00
pdp->vblSeq = 0;
pdp->vblFlags = 0;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
pdp->driScreenPriv = psp;
pdp->driContextPriv = &psp->dummyContextPriv;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
if (!(*psp->DriverAPI.CreateBuffer)(psp, pdp, &config->modes,
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
renderType == GLX_PIXMAP_BIT)) {
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pdp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
return NULL;
}
Refactor and fix core vblank support Consolidate support for synchronizing to and retrieving vblank counters. Also fix the core vblank code to return monotonic MSC counters, which are required by some GLX extensions. Adding support for multiple pipes to a low level driver is fairly easy, the Intel 965 driver provides simple example code (see intel_buffers.c:intelWindowMoved()). The new code bumps the media stream counter extension version to 2 and adds a new getDrawableMSC callback. This callback takes a drawablePrivate pointer, which is used to calculate the MSC value seen by clients based on the actual vblank counter(s) returned from the kernel. The new drawable private fields are as follows: - vblSeq - used for tracking vblank counts for buffer swapping - vblFlags - flags (e.g. current pipe), updated by low level driver - msc_base - MSC counter from the last time the current pipe changed - vblank_base - kernel DRM vblank counter from the last time the pipe changed Using the above variables, the core vblank code (in vblank.c) can calculate a monotonic MSC value. The low level DRI drivers are responsible for updating the current pipe (by setting VBLANK_FLAG_SECONDARY for example in vblFlags) along with msc_base and vblank_base whenever the pipe associated with a given drawable changes (again, see intelWindowMoved for an example of this). Drivers should fill in the GetDrawableMSC DriverAPIRec field to point to driDrawableGetMSC32 and add code for pipe switching as outlined above to fully support the new scheme.
2007-10-29 11:56:31 -07:00
pdp->msc_base = 0;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
All elements of pre-DRI_NEW_INTERFACE_ONLY are removed. This allows 1,402 lines of code to be removed from Mesa (drivers and libGL). The big winner is dri_util.c. Primary changes are: 1. Remove all "deprecated" entry-points from the various structures in dri_interface.h. 2. Rename the remaining fields to removed "version numbers." So, bindContext3 becomes bindContext. Functions with "New" in the name (e.g., CreateNewContext) were *not* changed, but that is an option. Having "New" in the name is less annoying to me than having "3" in the name. 3. Remove all compatibility code that handles cases where the driver or the loader is too old to support the latest interfaces. 4. Append the API version to the __driCreateNewScreen function name. This is currently done by hand. In the future (i.e., the next time we make an incompatible change to the interface) we'll want to come up with a better way to do this. This prevents old loaders from being able to load new (incompatible) drivers. 5. Bump the API version to 20050722. All drivers (by way of dri_util.c) require this version. 6. All drivers are *required* to expose GLX_SGIX_fbconfig and GLX_OML_swap_method (or the moral equivalents). Support for these functions in implicit in the use of the "new" interface. 7. Some cases still exist that need to be compiled differently in a loader or core Mesa versus in a driver. These are identified by the define IN_DRI_DRIVER.
2005-07-24 06:29:14 +00:00
/* This special default value is replaced with the configured
* default value when the drawable is first bound to a direct
* rendering context.
*/
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
pdp->swap_interval = (unsigned)-1;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
return pdp;
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static __DRIdrawable *
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
dri2CreateNewDrawable(__DRIscreen *screen,
const __DRIconfig *config,
void *loaderPrivate)
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
{
__DRIdrawable *pdraw;
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
pdraw = driCreateNewDrawable(screen, config, 0, 0, NULL, loaderPrivate);
Check for NULL pointer
2008-06-09 16:24:15 +01:00
if (!pdraw)
return NULL;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
pdraw->pClipRects = _mesa_malloc(sizeof *pdraw->pBackClipRects);
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
pdraw->pBackClipRects = _mesa_malloc(sizeof *pdraw->pBackClipRects);
return pdraw;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
just formatting clean-ups
2005-09-04 22:55:57 +00:00
static void
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driDestroyDrawable(__DRIdrawable *pdp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
fix coverity 926: use before NULL check
2006-03-23 04:13:37 +00:00
__DRIscreenPrivate *psp;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
if (pdp) {
fix coverity 926: use before NULL check
2006-03-23 04:13:37 +00:00
psp = pdp->driScreenPriv;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
(*psp->DriverAPI.DestroyBuffer)(pdp);
if (pdp->pClipRects) {
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pdp->pClipRects);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
pdp->pClipRects = NULL;
}
if (pdp->pBackClipRects) {
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pdp->pBackClipRects);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
pdp->pBackClipRects = NULL;
}
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pdp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
}
/*@}*/
/*****************************************************************/
/** \name Context handling functions */
/*****************************************************************/
/*@{*/
/**
* Destroy the per-context private information.
*
* \internal
* This function calls __DriverAPIRec::DestroyContext on \p contextPrivate, calls
* drmDestroyContext(), and finally frees \p contextPrivate.
*/
just formatting clean-ups
2005-09-04 22:55:57 +00:00
static void
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driDestroyContext(__DRIcontext *pcp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
if (pcp) {
(*pcp->driScreenPriv->DriverAPI.DestroyContext)(pcp);
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pcp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
}
/**
* Create the per-drawable private driver information.
*
* \param render_type Type of rendering target. \c GLX_RGBA is the only
* type likely to ever be supported for direct-rendering.
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
* \param shared Context with which to share textures, etc. or NULL
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
*
* \returns An opaque pointer to the per-context private information on
* success, or \c NULL on failure.
*
* \internal
* This function allocates and fills a __DRIcontextPrivateRec structure. It
* performs some device independent initialization and passes all the
* relevent information to __DriverAPIRec::CreateContext to create the
* context.
*
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static __DRIcontext *
driCreateNewContext(__DRIscreen *psp, const __DRIconfig *config,
Convert a left-over private void * to __DRIcontext *.
2007-05-17 16:11:19 -04:00
int render_type, __DRIcontext *shared,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
drm_context_t hwContext, void *data)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
__DRIcontext *pcp;
void * const shareCtx = (shared != NULL) ? shared->driverPrivate : NULL;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
pcp = _mesa_malloc(sizeof *pcp);
if (!pcp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
return NULL;
pcp->driScreenPriv = psp;
pcp->driDrawablePriv = NULL;
/* When the first context is created for a screen, initialize a "dummy"
* context.
*/
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
if (!psp->dri2.enabled && !psp->dummyContextPriv.driScreenPriv) {
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
psp->dummyContextPriv.hHWContext = psp->pSAREA->dummy_context;
psp->dummyContextPriv.driScreenPriv = psp;
psp->dummyContextPriv.driDrawablePriv = NULL;
psp->dummyContextPriv.driverPrivate = NULL;
/* No other fields should be used! */
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
pcp->hHWContext = hwContext;
Allow *_dri.so to build in Mesa tree with the 'linux-dri' target.
2004-04-29 12:23:39 +00:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
if ( !(*psp->DriverAPI.CreateContext)(&config->modes, pcp, shareCtx) ) {
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(pcp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
return NULL;
}
return pcp;
}
Move the copySubBuffer extension over to the new mechanism.
2007-05-15 15:17:30 -04:00
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static __DRIcontext *
dri2CreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
__DRIcontext *shared, void *data)
Implement new screen extension API. This new API lets the loader examine DRI level extensions provided by the driver in a forward compatible manner. Much of the churn in the DRI interface is adding support for new extensions or removing old, unused extensions. This new extension mechanism lets the loader query the extensions provided by the driver and implement the extensions it knows about. Deprecating extensions is done by not exporting that extension in the list, which doesn't require keeping old function pointers around to preserve ABI.
2007-05-15 12:31:31 -04:00
{
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
return driCreateNewContext(screen, config, 0, shared, 0, data);
Implement new screen extension API. This new API lets the loader examine DRI level extensions provided by the driver in a forward compatible manner. Much of the churn in the DRI interface is adding support for new extensions or removing old, unused extensions. This new extension mechanism lets the loader query the extensions provided by the driver and implement the extensions it knows about. Deprecating extensions is done by not exporting that extension in the list, which doesn't require keeping old function pointers around to preserve ABI.
2007-05-15 12:31:31 -04:00
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static int
driCopyContext(__DRIcontext *dest, __DRIcontext *src, unsigned long mask)
{
return GL_FALSE;
}
/*@}*/
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/*****************************************************************/
/** \name Screen handling functions */
/*****************************************************************/
/*@{*/
/**
* Destroy the per-screen private information.
*
* \internal
* This function calls __DriverAPIRec::DestroyScreen on \p screenPrivate, calls
* drmClose(), and finally frees \p screenPrivate.
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static void driDestroyScreen(__DRIscreen *psp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
if (psp) {
/* No interaction with the X-server is possible at this point. This
* routine is called after XCloseDisplay, so there is no protocol
* stream open to the X-server anymore.
*/
if (psp->DriverAPI.DestroyScreen)
(*psp->DriverAPI.DestroyScreen)(psp);
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
if (!psp->dri2.enabled) {
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
(void)drmUnmap((drmAddress)psp->pSAREA, SAREA_MAX);
(void)drmUnmap((drmAddress)psp->pFB, psp->fbSize);
(void)drmCloseOnce(psp->fd);
}
fix another memleak
2006-07-12 17:06:49 +00:00
Fix up some remaining include issues. Replace Xmalloc / Xfree with _mesa_malloc / _mesa_free. Replace Bool with GLboolean.
2004-06-07 21:23:12 +00:00
_mesa_free(psp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
}
}
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
static void
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
setupLoaderExtensions(__DRIscreen *psp,
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
const __DRIextension **extensions)
{
int i;
for (i = 0; extensions[i]; i++) {
if (strcmp(extensions[i]->name, __DRI_GET_DRAWABLE_INFO) == 0)
psp->getDrawableInfo = (__DRIgetDrawableInfoExtension *) extensions[i];
if (strcmp(extensions[i]->name, __DRI_DAMAGE) == 0)
psp->damage = (__DRIdamageExtension *) extensions[i];
if (strcmp(extensions[i]->name, __DRI_SYSTEM_TIME) == 0)
psp->systemTime = (__DRIsystemTimeExtension *) extensions[i];
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
if (strcmp(extensions[i]->name, __DRI_DRI2_LOADER) == 0)
psp->dri2.loader = (__DRIdri2LoaderExtension *) extensions[i];
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
}
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/**
Pull createNewScreen entry point into dri_util.c. This pulls the top level createNewScreen entry point out of the drivers and rewrites __driUtilCreateNewScreen in dri_util.c to be the new entry point. The change moves more logic into the common/ layer and changes the createNewScreen entry point to only be defined in one place.
2007-05-14 16:58:37 -04:00
* This is the bootstrap function for the driver. libGL supplies all of the
* requisite information about the system, and the driver initializes itself.
* This routine also fills in the linked list pointed to by \c driver_modes
* with the \c __GLcontextModes that the driver can support for windows or
* pbuffers.
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
*
* For legacy DRI.
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
*
* \param scrn Index of the screen
* \param ddx_version Version of the 2D DDX. This may not be meaningful for
* all drivers.
* \param dri_version Version of the "server-side" DRI.
* \param drm_version Version of the kernel DRM.
* \param frame_buffer Data describing the location and layout of the
* framebuffer.
* \param pSAREA Pointer the the SAREA.
* \param fd Device handle for the DRM.
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
* \param extensions ??
* \param driver_modes Returns modes suppoted by the driver
* \param loaderPrivate ??
All elements of pre-DRI_NEW_INTERFACE_ONLY are removed. This allows 1,402 lines of code to be removed from Mesa (drivers and libGL). The big winner is dri_util.c. Primary changes are: 1. Remove all "deprecated" entry-points from the various structures in dri_interface.h. 2. Rename the remaining fields to removed "version numbers." So, bindContext3 becomes bindContext. Functions with "New" in the name (e.g., CreateNewContext) were *not* changed, but that is an option. Having "New" in the name is less annoying to me than having "3" in the name. 3. Remove all compatibility code that handles cases where the driver or the loader is too old to support the latest interfaces. 4. Append the API version to the __driCreateNewScreen function name. This is currently done by hand. In the future (i.e., the next time we make an incompatible change to the interface) we'll want to come up with a better way to do this. This prevents old loaders from being able to load new (incompatible) drivers. 5. Bump the API version to 20050722. All drivers (by way of dri_util.c) require this version. 6. All drivers are *required* to expose GLX_SGIX_fbconfig and GLX_OML_swap_method (or the moral equivalents). Support for these functions in implicit in the use of the "new" interface. 7. Some cases still exist that need to be compiled differently in a loader or core Mesa versus in a driver. These are identified by the define IN_DRI_DRIVER.
2005-07-24 06:29:14 +00:00
*
Pull createNewScreen entry point into dri_util.c. This pulls the top level createNewScreen entry point out of the drivers and rewrites __driUtilCreateNewScreen in dri_util.c to be the new entry point. The change moves more logic into the common/ layer and changes the createNewScreen entry point to only be defined in one place.
2007-05-14 16:58:37 -04:00
* \note There is no need to check the minimum API version in this
* function. Since the name of this function is versioned, it is
* impossible for a loader that is too old to even load this driver.
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static __DRIscreen *
driCreateNewScreen(int scrn,
const __DRIversion *ddx_version,
const __DRIversion *dri_version,
const __DRIversion *drm_version,
const __DRIframebuffer *frame_buffer,
drmAddress pSAREA, int fd,
const __DRIextension **extensions,
const __DRIconfig ***driver_modes,
void *loaderPrivate)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
static const __DRIextension *emptyExtensionList[] = { NULL };
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
__DRIscreen *psp;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
dri: alloc __DRIscreen object with calloc()
2008-11-10 12:37:08 -07:00
psp = _mesa_calloc(sizeof *psp);
Pull createNewScreen entry point into dri_util.c. This pulls the top level createNewScreen entry point out of the drivers and rewrites __driUtilCreateNewScreen in dri_util.c to be the new entry point. The change moves more logic into the common/ layer and changes the createNewScreen entry point to only be defined in one place.
2007-05-14 16:58:37 -04:00
if (!psp)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
return NULL;
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
setupLoaderExtensions(psp, extensions);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/*
** NOT_DONE: This is used by the X server to detect when the client
** has died while holding the drawable lock. The client sets the
** drawable lock to this value.
*/
psp->drawLockID = 1;
Replace open-coded major, minor, and patch version fields with __DRIversionRec.
2007-05-14 16:37:19 -04:00
psp->drm_version = *drm_version;
psp->ddx_version = *ddx_version;
psp->dri_version = *dri_version;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
psp->pSAREA = pSAREA;
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
psp->lock = (drmLock *) &psp->pSAREA->lock;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
psp->pFB = frame_buffer->base;
psp->fbSize = frame_buffer->size;
psp->fbStride = frame_buffer->stride;
psp->fbWidth = frame_buffer->width;
psp->fbHeight = frame_buffer->height;
psp->devPrivSize = frame_buffer->dev_priv_size;
psp->pDevPriv = frame_buffer->dev_priv;
Fix up origin in dri/fb driver Calculated fbBPP
2005-05-05 05:50:19 +00:00
psp->fbBPP = psp->fbStride * 8 / frame_buffer->width;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
Move the copySubBuffer extension over to the new mechanism.
2007-05-15 15:17:30 -04:00
psp->extensions = emptyExtensionList;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
psp->fd = fd;
Pull createNewScreen entry point into dri_util.c. This pulls the top level createNewScreen entry point out of the drivers and rewrites __driUtilCreateNewScreen in dri_util.c to be the new entry point. The change moves more logic into the common/ layer and changes the createNewScreen entry point to only be defined in one place.
2007-05-14 16:58:37 -04:00
psp->myNum = scrn;
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
psp->dri2.enabled = GL_FALSE;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/*
** Do not init dummy context here; actual initialization will be
** done when the first DRI context is created. Init screen priv ptr
** to NULL to let CreateContext routine that it needs to be inited.
*/
psp->dummyContextPriv.driScreenPriv = NULL;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
psp->DriverAPI = driDriverAPI;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
*driver_modes = driDriverAPI.InitScreen(psp);
Pull createNewScreen entry point into dri_util.c. This pulls the top level createNewScreen entry point out of the drivers and rewrites __driUtilCreateNewScreen in dri_util.c to be the new entry point. The change moves more logic into the common/ layer and changes the createNewScreen entry point to only be defined in one place.
2007-05-14 16:58:37 -04:00
if (*driver_modes == NULL) {
_mesa_free(psp);
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
return NULL;
}
return psp;
}
remove obsoleted doxygen \param comments Someone changed the function parameters but didn't bother to update the comments. Also, whitespace changes, clean-ups.
2008-06-11 19:33:30 -06:00
/**
* DRI2
*/
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static __DRIscreen *
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
dri2CreateNewScreen(int scrn, int fd,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
const __DRIextension **extensions,
const __DRIconfig ***driver_configs, void *data)
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
{
static const __DRIextension *emptyExtensionList[] = { NULL };
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
__DRIscreen *psp;
Reduce the versioning madness required to create a DRI2 screen. Right now the DRI2 screen constructor takes 3 different versions: DRI, DDX and DRM. This is mostly useless, though: DRI: The DRI driver doesn't actually care about the DRI protocol, it only talks to the loader, which in turn speaks DRI protocol. Thus, the DRI protocol version is of not interest to the DRI driver, but it needs to know what functionality the loader provides. At this point that's reflected in the __DRIinterfaceMethods struct and the internal_version integer. DDX: The DDX version number is essentially used to track extensions to the SAREA. With DRI2 the SAREA consists of a number of versioned, self-describing blocks, so the DDX version is no longer interesting. DRM: We have the fd, lets just ask the kernel ourselves.
2008-02-25 23:37:23 -05:00
drmVersionPtr version;
Use dlsym() to avoid referencing __dri2DriverInitScreen. Sort-of a stop-gap workaround. There are a couple of nicer ways to do this that doesn't require dlfcn.h, but they're more invasive.
2008-02-25 20:02:25 -05:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
if (driDriverAPI.InitScreen2 == NULL)
Use dlsym() to avoid referencing __dri2DriverInitScreen. Sort-of a stop-gap workaround. There are a couple of nicer ways to do this that doesn't require dlfcn.h, but they're more invasive.
2008-02-25 20:02:25 -05:00
return NULL;
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
psp = _mesa_malloc(sizeof(*psp));
if (!psp)
return NULL;
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
setupLoaderExtensions(psp, extensions);
Reduce the versioning madness required to create a DRI2 screen. Right now the DRI2 screen constructor takes 3 different versions: DRI, DDX and DRM. This is mostly useless, though: DRI: The DRI driver doesn't actually care about the DRI protocol, it only talks to the loader, which in turn speaks DRI protocol. Thus, the DRI protocol version is of not interest to the DRI driver, but it needs to know what functionality the loader provides. At this point that's reflected in the __DRIinterfaceMethods struct and the internal_version integer. DDX: The DDX version number is essentially used to track extensions to the SAREA. With DRI2 the SAREA consists of a number of versioned, self-describing blocks, so the DDX version is no longer interesting. DRM: We have the fd, lets just ask the kernel ourselves.
2008-02-25 23:37:23 -05:00
version = drmGetVersion(fd);
if (version) {
psp->drm_version.major = version->version_major;
psp->drm_version.minor = version->version_minor;
psp->drm_version.patch = version->version_patchlevel;
drmFreeVersion(version);
}
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
psp->extensions = emptyExtensionList;
psp->fd = fd;
psp->myNum = scrn;
psp->dri2.enabled = GL_TRUE;
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
psp->DriverAPI = driDriverAPI;
*driver_configs = driDriverAPI.InitScreen2(psp);
if (*driver_configs == NULL) {
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
_mesa_free(psp);
return NULL;
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
psp->DriverAPI = driDriverAPI;
Add new DRI2 infrastructure.
2008-01-14 18:31:05 -05:00
return psp;
}
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
static const __DRIextension **driGetExtensions(__DRIscreen *psp)
{
return psp->extensions;
}
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
/** Core interface */
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
const __DRIcoreExtension driCoreExtension = {
{ __DRI_CORE, __DRI_CORE_VERSION },
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
NULL,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driDestroyScreen,
driGetExtensions,
driGetConfigAttrib,
driIndexConfigAttrib,
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
NULL,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driDestroyDrawable,
driSwapBuffers,
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
NULL,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driCopyContext,
driDestroyContext,
driBindContext,
driUnbindContext
};
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
/** Legacy DRI interface */
const __DRIlegacyExtension driLegacyExtension = {
{ __DRI_LEGACY, __DRI_LEGACY_VERSION },
driCreateNewScreen,
driCreateNewDrawable,
driCreateNewContext,
};
/** Legacy DRI interface */
const __DRIdri2Extension driDRI2Extension = {
{ __DRI_DRI2, __DRI_DRI2_VERSION },
dri2CreateNewScreen,
dri2CreateNewDrawable,
dri2CreateNewContext,
};
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
/* This is the table of extensions that the loader will dlsym() for. */
PUBLIC const __DRIextension *__driDriverExtensions[] = {
&driCoreExtension.base,
&driLegacyExtension.base,
DRI2: Drop sarea, implement swap buffers in the X server.
2008-08-13 11:46:25 -04:00
&driDRI2Extension.base,
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
NULL
};
Move GLX_MESA_swap_frame_usage DRI entry points to the new mechanism.
2007-05-16 15:50:40 -04:00
static int
driFrameTracking(__DRIdrawable *drawable, GLboolean enable)
{
return GLX_BAD_CONTEXT;
}
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
static int
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
driQueryFrameTracking(__DRIdrawable *dpriv,
Convert all DRI entrypoints to take pointers to __DRI* types. The entrypoints take a mix of __DRIscreen * and void * (screen private) arguments (similarly for contexts and drawables). This patch does away with passing the private void pointer and always only passes the fully typed __DRIscreen pointer and always as the first argument. This makes the interface more consistent and increases type safety, and catches a bug where we would pass a screen private to DRIdrawable::getSBC.
2007-05-11 16:43:20 -04:00
int64_t * sbc, int64_t * missedFrames,
float * lastMissedUsage, float * usage)
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
{
__DRIswapInfo sInfo;
int status;
int64_t ust;
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
__DRIscreenPrivate *psp = dpriv->driScreenPriv;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
status = dpriv->driScreenPriv->DriverAPI.GetSwapInfo( dpriv, & sInfo );
if ( status == 0 ) {
*sbc = sInfo.swap_count;
*missedFrames = sInfo.swap_missed_count;
*lastMissedUsage = sInfo.swap_missed_usage;
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
(*psp->systemTime->getUST)( & ust );
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
*usage = driCalculateSwapUsage( dpriv, sInfo.swap_ust, ust );
}
return status;
}
Move GLX_MESA_swap_frame_usage DRI entry points to the new mechanism.
2007-05-16 15:50:40 -04:00
const __DRIframeTrackingExtension driFrameTrackingExtension = {
Add a version field to __DRIextension.
2007-06-07 19:35:54 -04:00
{ __DRI_FRAME_TRACKING, __DRI_FRAME_TRACKING_VERSION },
Move GLX_MESA_swap_frame_usage DRI entry points to the new mechanism.
2007-05-16 15:50:40 -04:00
driFrameTracking,
driQueryFrameTracking
};
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/**
* Calculate amount of swap interval used between GLX buffer swaps.
*
* The usage value, on the range [0,max], is the fraction of total swap
* interval time used between GLX buffer swaps is calculated.
*
* \f$p = t_d / (i * t_r)\f$
*
* Where \f$t_d\f$ is the time since the last GLX buffer swap, \f$i\f$ is the
* swap interval (as set by \c glXSwapIntervalSGI), and \f$t_r\f$ time
* required for a single vertical refresh period (as returned by \c
* glXGetMscRateOML).
*
* See the documentation for the GLX_MESA_swap_frame_usage extension for more
* details.
*
* \param dPriv Pointer to the private drawable structure.
* \return If less than a single swap interval time period was required
* between GLX buffer swaps, a number greater than 0 and less than
* 1.0 is returned. If exactly one swap interval time period is
* required, 1.0 is returned, and if more than one is required then
* a number greater than 1.0 will be returned.
*
* \sa glXSwapIntervalSGI glXGetMscRateOML
*
* \todo Instead of caching the \c glXGetMscRateOML function pointer, would it
* be possible to cache the sync rate?
*/
float
driCalculateSwapUsage( __DRIdrawablePrivate *dPriv, int64_t last_swap_ust,
int64_t current_ust )
{
int32_t n;
int32_t d;
int interval;
float usage = 1.0;
Use __DRIextension mechanism providing loader functionality to the driver. Instead of passing in a fixed struct, the loader now passes in a list of __DRIextension structs, to advertise the functionality it can provide to the driver. Each extension is individually versioned and can be extended or phased out as the interface develops.
2008-02-28 10:32:28 -05:00
__DRIscreenPrivate *psp = dPriv->driScreenPriv;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
DRI interface changes and DRI2 direct rendering support. 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.
2008-03-26 19:26:59 -04:00
if ( (*psp->systemTime->getMSCRate)(dPriv, &n, &d, dPriv->loaderPrivate) ) {
Move swap_interval to new extension mechanism.
2007-05-15 16:09:44 -04:00
interval = (dPriv->swap_interval != 0) ? dPriv->swap_interval : 1;
First pass at support for building DRI drivers in mesa tree.
2004-04-14 12:39:58 +00:00
/* We want to calculate
* (current_UST - last_swap_UST) / (interval * us_per_refresh). We get
* current_UST by calling __glXGetUST. last_swap_UST is stored in
* dPriv->swap_ust. interval has already been calculated.
*
* The only tricky part is us_per_refresh. us_per_refresh is
* 1000000 / MSC_rate. We know the MSC_rate is n / d. We can flip it
* around and say us_per_refresh = 1000000 * d / n. Since this goes in
* the denominator of the final calculation, we calculate
* (interval * 1000000 * d) and move n into the numerator.
*/
usage = (current_ust - last_swap_ust);
usage *= n;
usage /= (interval * d);
usage /= 1000000.0;
}
return usage;
}
/*@}*/
Reference in a new issue Copy permalink