Re: [Mesa3d-dev] DRI interface changes

[Ian R. <id...@us...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kristian Høgsberg wrote:
> Hi,
> 
> I've been working on updating the DRI interface
> (GL/internal/dri_interface.h) the last few days and I though I'd post
> a heads up to the lists to get some feedback.  The work I've been
> doing starts out with the patches in bug 5714, implements Ians
> suggestions in comment #20, and quite a bit more.  I haven't added
> Alans frontbuffer mapping patches yet; I wanted to get this work done
> first before breaking DDX compatibility, but they're next.
> 
> The work is on the dri2 branch in git.freedesktop.org/~krh/mesa.git or
> browsable here:
> 
> http://people.freedesktop.org/krh-cgi/cgit?r=_home_krh_mesa.git&p=log&h=dri2
> 
> The changes are mostly a series of cleanup as described below, but
> there is a new concept in there: the DRI extension.  Much of the churn
> in the DRI interface structs is from adding and removing functions
> pertaining to GLX extensions, most recently GLX_MESA_copy_sub_buffer
> and probably soon GLX_EXT_texture_from_pixmap.  The DRI extension
> mechanism should allow us to add and remove support for extensions as
> they come and go, in a way that doesn't break ABI or API.
> 
> The idea here is that only the core GLX 1.4 features should be part of
> the __DRI{screen,context,drawable} structs and everything else must be
> exposed as a __DRIextension.  The list of __DRIextensions is available
> using __DRIscreen::getExtensions;
> 
>     const __DRIextension **(*getExtensions)(__DRIscreen *screen);
> 
> All extensions have a common "baseclass" that just is the name of the
> extension  (just a string):
> 
>     struct __DRIextensionRec {
>         const char *name;
>     };

We've had a couple cases over the years where the interface for a
particular bit of functionality has changed.  It might be worthwhile to
stick a version in here.

> If the name matches that of an extension known to the loader, the
> loader can cast the struct to a more specific extension struct that
> has the function pointers that provide access to the functionality.
> For example:
> 
>     #define __DRI_COPY_SUB_BUFFER "DRI_CopySubBuffer"
>     struct __DRIcopySubBufferExtensionRec {
>         __DRIextension base;
>         void (*copySubBuffer)(__DRIdrawable *drawable,
>                               int x, int y, int w, int h);
>     };
> 
> The presence of an extension means that the driver can provide some
> extra functionality.  Based of these extra hooks, the loader will be
> able to implement and advertise a number of GLX extensions.  The DRI
> extension name space is private to the DRI interface, and is
> orthogonal to the GLX extension name space.  The logic here is that
> one DRI extension can enable a number of GLX extensions, and the
> loader, since it has to implement the entry points, will know exactly
> which GLX extensions to enable.  For example, the DRI_SwapControl
> extension:

Is the implication that drivers won't have to explicitly enable GLX
extensions?  I like that.  Let the loader derive the information from
the information provided by the driver.

> #define __DRI_SWAP_CONTROL "DRI_SwapControl"
> struct __DRIswapControlExtensionRec {
>     __DRIextension base;
>     void (*setSwapInterval)(__DRIdrawable *drawable, unsigned int inteval);
>     unsigned int (*getSwapInterval)(__DRIdrawable *drawable);
> };
> 
> enables the loader to implement both GLX_SGI_swap_control and
> GLX_MESA_swap_control.
> 
> Aside from the new extension mechanism, the branch cleans up a number
> of things in the DRI interface:
> 
> 1) Move XIDs out of the interface and make libGL handle XID ->
> __DRIdrawable etc mapping.  I've pulled the hashtable from libdrm into
> mesa to do this, which should allow us to drop the hashtable and the
> skip list from drm eventually.
> 
> 2) Drop the display notion from the interface.  A DRI driver only
> handles one screen and
> 
> 3) Remove getProcAddress (only needed by the old extension mechanism),

Right...to get the function that enables GLX extensions.

> create/destroyContext, create/destroyDrawable (instead of calling back
> from the DRI driver, just have the loader create the context first and
> pass the drm_context_t into the driver).

I'll have to look at the code.  I'm not 100% sure how this would play out.

> 4) Remove variables from the __DRI* structs except the private
> pointer.  We should never share state across the DRI driver boundary,
> all access should go through functions.

How well is that working out in practice?

> 5) Misc cleanups: pull the createNewScreen out of the driver backends
> and into dri/common (more code sharing, simpler interface between
> dri/common and drivers), always use the __DRI* types instead of
> private void pointers (type safety, interface is more
> self-documenting), generate entry point name using macros instead of
> duplication the version number in a few places, drop now unused
> __DRIid typedef.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGTkaQX1gOwKyEAw8RAj8BAJ9bTYLzOUnF+wiJvC9u9zBYuoESrQCfXJIX
zDXqyCvFKbrAZR/KJA+9qRg=
=Z1uR
-----END PGP SIGNATURE-----