On 5/18/07, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -----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
...
> > 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.
Yes, I think that's a good idea. I think what makes sense is to just
have a single integer counting the number of backwards compatible
bumps of an extension. It doesn't make sense to have a major verion
number to indicate backwards compatibility breaks, since we'd just
define a new extension instead. So the rule is that an extension can
grow new entry points over time, if it makes sense, but we never break
ABI. Also, I don't see a case for a patch-level version number, so I
think a simple, incrementing integer will suffice.
> > 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.
Exactly, that's basically what I was trying to say. Here's an example
from glxextensions.c:
#ifdef __DRI_MEDIA_STREAM_COUNTER
if (strcmp(extensions[i]->name, __DRI_MEDIA_STREAM_COUNTER) == 0) {
psc->msc = (__DRImediaStreamCounterExtension *) extensions[i];
SET_BIT(psc->direct_support, SGI_video_sync_bit);
}
#endif
The media stream counter extension provide entry points that let us
implement the GLX_SGI_video_sync extension. The loader stores a
pointer to the extension struct so we don't have to look it up later
on and sets the bit that enables the GLX extension.
If the DRI drivers implemented a swap buffer counter extension, libGL
could implement GLX_OML_sync_control in terms of the msc extension and
the sbc extension.
Similarly, the changes Michel proposed to accelerate
GLX_texture_from_pixmap, should be exported as a DRI_TextureOffset
extension, which will let the X server implement tfp for now. Later
on, we can add a new extension that lets us do the same thing with a
memory manager handle, and phase out the DRI_TextureOffset extension.
So the DRI extensions provide small chunks of functionality with a
name and a version. How those extensions are used by the loader and
how they map the GLX extensions is up to the loader.
...
> > 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.
As far as I can see, the only reason to do this with callouts from the
DRI driver is that it used to implicitly create DRI drawables when you
bind an X window to a GLX context. With the changes I've done this
never happens: we always explicity create the DRI drawable in libGL or
AIGLX. Either when an X window is bound to a context or when the user
call glXGCreateWindow/Pixmap.
> > 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?
Pretty well. The two fields I removed was DRIscreen::screenConfigs,
which you can get from the __DRIscreen pointer, and
DRIdrawable::swap_interval, which you now get and set through function
pointers in the DRI_SwapControl extension.
cheers,
Kristian
-------------------------------------------------------------------------
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/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
