Re: Plans for merging DRI2 work

[Jerome G. <gl...@fr...>]

On Mon, 2008-02-04 at 15:26 -0500, Kristian Høgsberg wrote:
> Hi,
> 
> I'm getting ready to merge the DRI2 work and wanted to post a heads up
> to the lists.  First of all, I'd like to point out that I'm landing
> will be experimental and initially miss some parts (direct rendering
> and page flipping), but it will coexist with the existing XF86DRI
> infrastructure and be an opt-in feature.  In other words, if you don't
> explicitly enable DRI2 you shouldn't see any breakage.  I'm adding a
> DRI2 option to the intel driver, so that specifying
> 
>   Option "DRI2"
> 
> in the Device section will make the intel DDX driver initialize
> against the DRI2 module instead of the XF86DRI module, and that will
> then propagate through GLX to the DRI driver, switching the entire
> stack to DRI2.  Also, DRI2 is exclusively new API, so this shouldn't
> cause any^Wmore broken drivers.  The DRI2 design is unchanged from
> when I sent out this mail:
> 
>   http://marc.info/?l=dri-devel&m=119827435904164&w=2
> 
> I'll commit a couple of patches to the server, adding a new DRI2
> module and a new glxdri2 to GLX.  There's a couple of mesa patches,
> one to add the general infrastructure and one to hook up the i915
> driver.  There's a drm patch to teach the kernel to work with the DRI2
> sarea.  Finally there's a patch to the intel DDX driver to make it
> initialize against DRI2 if requested.  The DDX patch will be committed
> on the intel-batchbuffer branch of the intel driver, since it depends
> on those changes.  There's still work to be done, but I feel like it's
> minimally useful now, and I've been fidgeting with these patches for
> long enough.  It's disabled by default, but easy to enable and test
> for "early adopters", so I'm not too concerned about landing it in its
> current state.
> 
> I'll be cleaning up the patches a bit and trying to split them up into
> a series of independent commits today and expect to commit tomorrow.
> If there are any objections, please let me know.
> 
> cheers,
> Kristian

Great :)

Hopefully i will look into it and use it instead of my current hackish
dri things (even though this also require a proper ddx for kms). Btw it
would be nice if mesa bit could be separated of the old one so that
cherry picking this into gallium is easier. It seems that gallium dri
interface lag quit a bit behind what is in master and this is a little
pain full (for me at least :)).

Also what kind of sync are you thinking of for swap buffer ie a way to
avoid tearing while doing the swap from user space.

Anyway kudos to you for this.

Cheers,
Jerome Glisse