Dave Airlie wrote: >>> 1) I feel there hasn't been enough open driver coverage to prove it. So far >>> we have done an Intel IGD, we have a lot of code that isn't required for >>> these devices, so the question of how much code exists purely to support >>> poulsbo closed source userspace there is and why we need to live with it. >>> Both radeon and nouveau developers have expressed frustration about the >>> fencing internals being really hard to work with which doesn't bode well for >>> maintainability in the future. >>> >>> >> OK. So basically what I'm asking is that when we have full-feathered open >> source drivers available that >> utilize TTM, either as part of DRM core, or, if needed, as part of >> driver-specific code, do you see anything >> else that prevents that from being pushed? That would be very valuable to >> know >> for anyone starting porting work. ? >> > > I was hoping that by now, one of the radeon or nouveau drivers would have > adopted TTM, or at least demoed something working using it, this hasn't > happened which worries me, perhaps glisse or darktama could fill in on > what limited them from doing it. The fencing internals are very very scary > and seem to be a major stumbling block. > Yes, it would be good to get some details here. Exactly what parts are scary? It seems Ian Romanick has made it work fine with xgi. 122 locs including license headers. I915 fencing can be made equally short if all sample (flushing) code is removed. > I do worry that TTM is not Linux enough, it seems you have decided that we > can never do in-kernel allocations at any useable speed and punted the > work into userspace, which makes life easier for Gallium as its more like > what Windows does, but I'm not sure this is a good solution for Linux. > > In-kernel allocations should be really fast unless they involve changing caching policy. If they are not, it's not a design issue but an implementation one which should be fixable. Trying to make mmap(anonymous) lightning fast when there is malloc() doesn't really make sense to me.
> The real question is whether TTM suits the driver writers for use in Linux > desktop and embedded environments, and I think so far I'm not seeing > enough positive feedback from the desktop side. > I actually haven't seen much feedback at all. At least not on the mailing lists. Anyway we need to look at the alternatives which currently is GEM. GEM, while still in development basically brings us back to the functionality of TTM 0.1, with added paging support but without fine-grained locking and caching policy support. I might have misunderstood things but quickly browsing the code raises some obvious questions: 1) Some AGP chipsets don't support page addresses > 32bits. GEM objects use GFP_HIGHUSER, and it's hardcoded into the linux swap code. 2) How will user-space mapping of IO memory (AGP apertures) work? Eviction and associated killing / refaulting of IO memory mappings? 3) How do we avoid illegal physical page aliasing with non-Intel hardware? And how are we going to get the kernel purists to accept it when they already complain about WC - UC aliasing? 4) How is VRAM incoporated in the GEM design? How do we map it and keep the mapping during eviction? 5) What's protecting i915 GEM object privates and lists in a multi-threaded environment? 6) Isn't do_mmap() strictly forbidden in new drivers? I remember seeing some severe ranting about it on the lkml? TTM is designed to cope with most hardware quirks I've come across with different chipsets so far, including Intel UMA, Unichrome, Poulsbo, and some other ones. GEM basically leaves it up to the driver writer to reinvent the wheel.. > Also wrt the i915 driver it has too many experiments in it, the i915 users > need to group together and remove the codepaths that make no sense and > come up with a ssuitable userspace driver for it, remove all unused > fencing mechanisms etc.. > Agreed, but back to the real and to me very important question: If I embark on a new OS driver today and want to use advanced memory manager stuff. Have VRAM and multiple advanced syncing mechanisms. What's my best option to get it into the kernel? Can I hook up driver specific TTM and get it in? /Thomas > Dave. > > > > >> /Thomas >> >> >> >> >> >> >> ------------------------------------------------------------------------- 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
