On 5/18/08, Thomas Hellström <[EMAIL PROTECTED]> wrote: > > Yes, that was really my point. If the memory manager we use (whatever > > it is) does not allow this kind of behaviour, that'll force all cards > > to use a kernel-validated command submission model, which might not be > > too fast, and more difficult to implement on such hardware. > > > > I'm not in favor of having multiple memory managers, but if the chosen > > one is both slower and more complex to support in the future, that'll > > be a loss for everyone. Unless we want to have another memory manager > > implementation in 2 years from now... > > > > Stephane > > > > First, TTM does not enforce kernel command submission, but it forces you > to tell the kernel about command completion status in order for the > kernel to be able to move and delete buffers.
Yes, emitting the moves from the kernel is not a necessity. If your card can do memory protection, you can setup the protection bits in the kernel and ask user space to do the moves. Doing so means in-order execution in the current context, which means that in the normal case rendering does not need to synchronize with fences at all. > > I'm not sure how you could avoid that with ANY kernel based memory > manager, but I would be interested to know how you expect to solve that > problem. See above, if the kernel controls the memory protection bits, it can pretty much enforce things on use space anyway. > > As for speed, the TTM-based i915tex driver is still substantially more > CPU-efficient (which translates to faster for CPU-bound apps), than > _any_ of the intel-modified drivers. Well, this is on intel hardware. If you had the ability to avoid most of the kernel trips and relocation thanks to your hw, you would be even less CPU-bound. > Among other things, the texsubimage throughput is about 5x that of the > Intel drivers, GEM included. > I'm not arguing against TTM or against GEM right now... What we're discussing is something that wouldn't work in either case I think. Stephane ------------------------------------------------------------------------- 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
