On Sun, 2008-05-18 at 17:55 +0200, Thomas Hellström wrote: > 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. We haven't touched the texsubimage path, having not found it in a profile yet. It'll probably be doing map/write/unmap, which (as noted elsewhere in the thread) is pretty much the worst thing you can do. If you have a relevant application where texsubimage is showing up in the profile, I'd enjoy playing with it. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
