> 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. >
I have no idea where this set of ideas come from, and it's a little disturbing to me. On a couple of levels, it's clearly bogus. Firstly, TTM and its libdrm interfaces predate gallium by years. Secondly, the windows work we've done with gallium to date has been on XP and _entirely_ in kernel space, so the whole issue of user/kernel allocation strategies never came up. Thirdly, Gallium's backend interfaces are all about abstracting away from the OS, so that drivers can be picked up and dumped down in multiple places. It's ludicrous to suggest that the act of abstracting away from TTM has in itself skewed TTM -- the point is that the driver has been made independent of TTM. The point of Gallium is that it should work on top of *anything* -- if we had had to skew TTM in some way to achieve that, then we would have already failed right at the starting point... Lastly, and most importantly, I believe that using TTM kernel allocations to back a user space sub-allocator *is the right strategy*. This has nothing to do with Gallium. No matter how fast you make a kernel allocator (and I applaud efforts to make it fast), it is always going to be quicker to do allocations locally. This is the reason we have malloc() and not just mmap() or brk/sbrk. Also, sub-allocation doesn't imply massive preallocation. That bug is well fixed by Thomas' user-space slab allocator code. Keith ------------------------------------------------------------------------- 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
