Xorg 7.4 release plan

[Eric Anholt]

On Thu, 2008-02-28 at 06:08 +1000, Dave Airlie wrote:
> >
> >  I wasn't planning on a Mesa 7.1 (trunk code) release for a while, but I
> >  could finish up 7.0.3 at any moment.  I have to admit that I haven't
> >  actually tested Mesa 7.0.3 with current X code in quite a while though.
> >
> >  Before Mesa 7.1 I'd like to see a new, official DRM release.  Otherwise,
> >  it's hard to identify a snapshot of DRM that works with Mesa.  I know I
> >  always have trouble with DRM versioning otherwise.
> >
> >  Is there any kind of roadmap for a new DRM release?
> 
> When TTM hits the kernel, I'll release a libdrm to work with that and
> solidify the API,
> 
> however people keep finding apparently valid reasons to pick holes in
> the TTM API, however I haven't seen the discussion brought up in the
> few weeks since.

http://cgit.freedesktop.org/~anholt/drm/log/?h=drm-ttm-cleanup-2

has some I believe obvious cleanups to the API, removing many sharp
edges.  At that point the BO parts of the API are more or less tolerable
to me.  The fencing code I don't understand and am very scared by still,
but most of it has left the user <-> kernel API at least.

DRM_BO_FLAG_BUSY in replies is broken, which keeps me from doing
userland buffer object caching right.  This is a major performance hack
primarily to deal with the fact that kernel page allocation is so slow,
though the kernel folks tell me that that's just our fault for refusing
to allow highmem pages.  If we fixed highmem allocation, userland buffer
object caching might just be a tradeoff of memory for avoiding page
fault overhead, at which point I may not care to do that at all.

Also, the info ioctl calls drm_bo_busy() -> drm_fence_object_flush() ->
WTF, instead of just allowing drm_bo_fill_rep_arg() ->
drm_bo_quick_busy() to fill in the busy flag.  This doesn't directly
touch the API, but it should probably be noted that the info ioctl has
side effects besides just returning the current buffer info, if this is
in fact intended behavior.

> Either that or we just turn off TTM parts of the i915 driver in Mesa
> and release a libdrm with no TTM API for now.

At this point that should be relatively easy if we just want to get a
Mesa release out, and I'd be cool with that if it helped get a release
of all the other new hotness out the door.

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080227/e9f6b5ce/attachment.pgp>