Stephane Marchesin wrote: > On 5/16/08, Pekka Paalanen <[EMAIL PROTECTED]> wrote: > >> On Fri, 16 May 2008 10:05:18 +0200 >> Jerome Glisse <[EMAIL PROTECTED]> wrote: >> >> > My current understanding is that on newer GPU each client got its >> > own memory address space on the GPU. I can manage this space >> > transparently based on hint from userspace, ie i can place page >> > either in ram or vram and i can do migration when necessary. As >> > a result i think i have no obligation that page in VRAM to be >> > adjacent each to the other. Of course mapping such thing in >> > userspace vma become cumberstone. >> >> >> This sounds like a feature that could be used to avoid applying >> any relocations into commands streams, and completely get rid of >> kernel validation of a command stream beforehand, allowing direct >> unobstructed command submission from user space to the card. >> It would just be like "applying relocations in hardware", using >> page tables instead of rewriting addresses in certain spots in a >> command stream. >> >> Or have I misunderstood something? >> (Oh, in a later email Glisse writes the same idea.) >> >> This sounds interesting, since it would promote command submission >> that does not go through the kernel at all, which is what Nouveau >> is already interested in. >> >> Somehow I have a recollection that TTM would force the command >> stream through the kernel, but then again, I'm very new to all this. >> >> > > 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.
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. 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. Among other things, the texsubimage throughput is about 5x that of the Intel drivers, GEM included. /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 > ------------------------------------------------------------------------- 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
