Re: [Dri-devel] One driver binary for fbdev and XFree86 vs. internal interface changes

[Otto S. <so...@gu...>]

On Thu, Oct 09, 2003 at 04:06:04PM -0700, Ian Romanick wrote:
> Over the past few months there has been a lot of talk about having a 
> single client-side driver binary used both with and without XFree86.  A 
> number of stumbling blocks have been found to this.  I've pointed out a 
> couple times[1] that some of these same issues also block fbconfigs and 
> pbuffers.  Until recently, most of my research on this problem has 
> focused on the client-side.  Over the last couple weeks I've done a bit 
> more digging, and I've found that the rabbit hole goes much, much deeper 
> than I first thought.
> 
> The first obvious problem with a single binary is that the XFree86 build 
> of the driver makes a number of X-protocal calls in the bootstrap 
> process and whenever a context or a drawable is created or destroyed. 
> The biggest offender is __driUtilCreateScreen in dri_util.c.  This is 
> the routine that does the real work of bootstrapping the driver.  I 
> updated the driCreateNewScreen interface proposed in [1] to add 
> framebuffer, version, and DRM device handle data.  The net result is 
> that *ALL* of the XF86DRI and drm calls in __driUtilCreateScreen can be 
> done from within libGL *BEFORE* calling into the driver.
> 
> Once that change is made, a non-backwards compatable driver binary would 
> only have calls to XF86DRICreateDrawable, XF86DRIDestroyDrawable, 
> XF86DRICreateContext, XF86DRIDestroyContext, and XF86DRIGetDrawableInfo. 
>  I began looing at the create / destroy context routines next.
> 
> The context related routines, it turns out, are a big, BIG problem. 
> However, the problem is not on the client-side.  It's on the 
> server-side.  The routines in libdri.a that handle these protocol 
> requests start by looking up the visualID in the table of GLX visuals 
> (see programs/Xserver/GL/dri/xf86dri.c, line 310).  They then look-up 
> the visual ID in the table of X visuals, and make a call into the DDX 
> driver.  Therein lies the problem.  When fbconfigs are added, the 
> interface in the DDX driver is broken.  Because an fbconfig carries a 
> LOT more data than a classic GLX visual (look at the difference between 
> __GLcontextModes in glcore.h and _GLXvisualConfigRec in glxint.h), the 
> existing inteface cannot be used[2][3].
> 
> There are a couple other issues.  The current interface is not used. 
> Not even the gamma driver does any useful work in its createContext 
> handler (see glint_dri.c, line 825).  The same goes for the 
> destroyContext routines.  By reading the documentation and comments in 
> the code, I believe that these interfaces were created when DRI was in 
> its infancy for drivers that might do context specific work (i.e., a 
> per-context SAREA, etc.).  Here we are 4 years later and not a single 
> driver uses those interfaces.  We can ask around, but I doubt that any 
> of the closed-source drivers make any more use of these interfaces than 
> the open-source drivers.
> 
> My vote is that the *protocol* for XF86DRICreateContext, 
> XF86DRIDestroyContext, XF86DRIOpenFullScreen[4], and 
> XF86DRICloseFullScreen be removed.  That is, the client-side routines 
> should be no-ops (to maintain backwards compatability) and the 
> server-side routines should just return success (again, to maintain 
> backwards compatability).  The the best of my knowledge, no driver has 
> ever used the FullScreen functionality.  If a driver needs shared, 
> per-context state, it should use its DRM.
> 
> The drawable related protocol cannot and should not be removed. 
> However, I believe that libGL should export these interfaces to the 
> client-side driver via glXGetProcAddress.  This would allow the libGL 
> for DirectFB, for example, to do something different.
> 
> It *may* be possible to have libGL make the XF86DRICreateDrawable call 
> and pass the hHWDrawable into the drivers createNewDrawable routine.  If 
> createNewDrawable returns failure, libGL would call 
> XF86DRIDestroyDrawable.  The destroyDrawable would be changed (a new 
> interface called destroyNewDrawable, perhaps?) to return the hHWDrawable 
> value.  libGL would then call XF86DRIDestroyDrawable after returning 
> from the driver's destroyNewDrawable function.  I'm not sure this would 
> be worth the effort.  Perhaps someone interested in supporting DRI 
> outside of XFree86 can comment?
> 
> If all of the above changes and the other interface changes proposed in 
> [1] were made, the only XFree86-specific call made from within the 
> driver would be XF86DRIGetDrawableInfo.  That function really does have 
> to stay. :)  However, like I said before, it should be accessed via 
> glXGetProcAddress.
> 
> To maintain backwards compatability, we would need functions in 
> dri_util.c to adapt the old interfaces to the new.  In all the cases 
> that I have seen, this would be trivial.  We would want to wrap all of 
> these functions with something like "#ifndef DRI_NEW_API_ONLY".  That 
> would allow drivers to be built that would work with or without XFree86 
> or drivers that would work only with XFree86.
> 
> I can generate a fairly rough patch this weekend for dri_util.c, the 
> code in programs/Xserver/GL/, and the code in lib/GL/glx, but supporting 
> all the drivers will take more work.  I think that if we pursue this, it 
> should be done in a branch.
> 
> If we can get some agreement on how to handle this in dri-devel, I will 
> take the issue to devel@xfree86.  Perhaps this can make for some lively 
> discussion at next Monday's #dri-devel meeting? :)
> 
> [1] http://marc.theaimsgroup.com/?l=dri-devel&m=106210013822486&w=2
> [2] http://marc.theaimsgroup.com/?l=dri-devel&m=104862475709280&w=2
> [3] http://sourceforge.net/mailarchive/message.php?msg_id=5341553
> [4] http://marc.theaimsgroup.com/?l=dri-devel&m=105486181204323&w=2

It would be very interesting hear Keith Whitwell and Jon Smirl about this
proposal.

The part i dislike is that XF86DRIGetDrawableInfo has to stay and
backwards compatibility as this could be called DRI2 because it will have
different but cleaner and better client/server programming interfaces IMO.

-solca