Features Download
From: Dave Airlie <airlied <at> linux.ie>
Subject: Re: TTM vs GEM discussion questions
Newsgroups: gmane.comp.video.dri.devel
Date: Monday 19th May 2008 03:38:02 UTC (over 9 years ago)
> All the good that's done us and our users.  After more than *5 years* of
> various memory manager efforts we can't support basic OpenGL 1.0 (yes,
> 1.0) functionality in a performant manner (i.e., glCopyTexImage and
> friends).  We have to get over this "it has to be perfect or it will
> never get in" crap.  Our 3D drivers are entirely irrelevant at this

Except on Intel hardware, who's relevance may or may not be relevant.

> To say that "userspace APIs cannot die once released" is not a relevant
> counterpoint.  We're not talking about a userspace API for general
> application use.  This isn't futexs, sysfs, or anything that
> applications will directly depend upon.  This is an interface between a
> kernel portion of a driver and a usermode portion of a driver.  If we
> can't be allowed to change or deprecate those interfaces, we have no
> Note that the closed source guys don't have this artificial handicap.

Ian, fine you can take this up with Linus and Andrew Morton, I'm not 
making this up just to stop you from putting 50 unsupportable memory 
managers in the kernel. If you define any interface to userspace from the 
kernel (ioctls, syscalls), you cannot just make it go away. The rule is 
simple and is that if you install a distro with a kernel 2.6.x.distro, and 
it has Mesa 7.0 drivers on it, upgrading the kernel to kernel 2.6.x+n 
without touching userspace shouldn't break userspace ever. If we can't 
follow this rule we can't put out code into Linus's kernel. So don't argue 
about it, deal with it, this isn't going to change.

and yes I've heard this crap about closed source guys, but we can't follow 
their route and be distributed by vendors. How many vendors ship the 
closed drivers?

> This is also a completely orthogonal issue to maintaining any particular
> driver.  Drivers are removed from the kernel just the same as they are
> removed from X.org.  Assume we upstreamed either TTM or GEM "today."
> Clearly that memory manager would continue to exist as long as some
> other driver continued to depend on it.  I don't see how this is
> different from cfb or any of the other interfaces within the X server
> that we've gutted recently.

Drivers and pieces of the kernel aren't removed like you think. I think we 
nuked gamma (didn't have a working userspcae anymore) and ffb (it sucked 
and couldn't  be fixed). Someone is bound to bring up OSS->ALSA, but that 
doesn't count as ALSA had OSS emulation layer so userspace apps didn't 
just stop working. Removing chunks of X is vastly different to removing an 
exposed kernel userspace interface. Please talk to any IBM kernel person 
and clarify how this stuff works. (Maybe benh could chime in...??)

> If you want to remove a piece of infrastructure, you have three choices.
> ~ If nothing uses it, you gut it.  If something uses it, you either fix
> that "something" to use different infrastructure (which puts you in the
> "nothing uses it" state) or you leave things as they are.  In spite of
> all the fussing the kernel guys do in this respect, the kernel isn't
> different in this respect from any other large, complex piece of
> infrastructure.

So you are going to go around and fix the userspaces on machines that are 
already deployed? how? e.g. Andrew Morton has a Fedora Core 1 install on a 
laptop booting 2.6.x-mm kernels, when 3D stops working on that laptop we 
get to hear about it. So yes you can redesign and move around the kernel 
internals as much as you like, but you damn well better expose the old 
interface and keep it working.

> managers or that we may want to have N memory managers now that will be
> gutted later.  It seems that the real problem is that the memory
> managers have been exposed as a generic, directly usable, device
> independent piece of infrastructure.  Maybe the right answer is to punt
> on the entire concept of a general memory manager.  At best we'll have
> some shared, optional use infrastructure, and all of the interfaces that
> anything in userspace can ever see are driver dependent.  That limits
> the exposure of the interfaces and lets us solve todays problems today.
> As is trivially apparent, we don't know what the "best" (for whatever
> definition of best we choose) answer is for a memory manager interface.
> ~ We're probably not going to know that answer in the near future.  To
> not let our users have anything until we can give them the best thing is
> an incredible disservice to them, and it makes us look silly (at best).

Well the thing is I can't believe we don't know enough to do this in some 
way generically, but maybe the TTM vs GEM thing proves its not possible. 
So we can then punt to having one memory manager per driver, but I suspect 
this will be a maintenance nightmare, so if people decide this is the way 
forward, I'm happy to see it happen. However the person submitting the 
memory manager n+1 must damn well be willing to stand behind the interface 
until time ends, and explain why they couldn't re-use 1..n memory 


This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
CD: 11ms