> > 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 point.
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 hope. > > 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 managers. Dave. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
