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 ------------------------------------------------------------------------- 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
