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 [EMAIL PROTECTED] 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 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
