-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Airlie wrote: |> I honestly don't see a problem with having multiple memory managers. We |> have different hardware with different functionality and different |> performance characteristics. The probability of one memory manager |> fitting everywhere is nil. Quite frankly, the fact that it has take |> this long to get *anything* upstream is already failure. |> |> This is open source. Release early, release often. If something gets |> implemented and doesn't work out, you redo it. You don't spend forever |> trying to get it perfect before you release anything. :( | | I didn't want one memory manager,as much as I wanted one common API for a | memory manager, with driver specific functions ala superioctl. Ideally | this meant a buffer object and a fence meant and operated the same way to | everyone... so that writing drivers was at least using the same naming | etc.. and that userspace API was supportable. I quite understood that | underneath may end up with just ioctl into driver back into common code or | into driver specifc code for some cases and this is fine, but I believe | the API to userspace to create and manipulate objects should be common and | sane. | | Ian, quoting open-source mantras may work in some places, but you really | need to understand you cannot upstream unsupportable kernel APIs, and drop | them alter. I still maintain the internals of the drm to support i810 and | i830 drivers. I can probably drop them in 5-10 years maybe. Userspace APIs | cannot die once released, so in this case release early and often doesn't | apply. There are many kernel mailing list and lwn articles on this topic | if you'd like to get past the mantra...
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. 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. 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. 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. It seems like the real problem here isn't that we may want have N memory 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). OpenGL provides a good model here. When we don't know what the best answer is there, we expose it as an extension. That gives us and our users some experience with it and provides additional data. That additional data and experience feeds back into the loop and guides the design of what ends up in the core. For the memory manager situation, replace "extension" with "device specific interface" and "core" with "generic kernel/usermode interface." This is solvable. We're smart enough to fix this. How do we move forward? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFIMO8rX1gOwKyEAw8RAr54AJwMl/UrRPrZyuHkZRhWJr7QtOLI4ACdH80h yBQfyoCzTXwe5euXYRzupwE= =N0kg -----END PGP SIGNATURE----- ------------------------------------------------------------------------- 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
