-----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-----
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
