On Fri, 16 May 2008 09:28:31 +0200 Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi. > > I have a couple of question w r t the TTM vs GEM discussion: > > 1) How does pwrite() avoid clflush()es or wbinvd()s in the i915 gem case? > > 2) Some people have stated that GPU page faults could not be implemented > with TTM. > We've certainly dealt with that type of hardware, but found no obvious > reason to use that feature. > > Could someone tell me why this feature can't be used with TTM (or is it > that it can't be used with the current TTM driver interface?) and also > a typical use-case where it might be beneficial within either the GEM or > TTM context? > > /Thomas > For GPU page my concern with ttm was the obligation of having a user mapping of the VRAM. In GEM i am not forced to map vram (i could do that too in TTM but i have the feeling that this would need a quite big amount of code). Note that GEM can do VRAM mapping if you want as stated by Keith and Eric, sorry if i did give the impression that GEM could not. Here are assumption i do on hw virtual address space, i don't have information on this for radeon hw so this might not be what the current hw is capable of. That being said, i have the feeling that we will eventualy get to this technology. 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 view of vram management is what is motivating my reluctance to map vram in userspace vma. I do agree that on current hw mapping vram is the easiest path but once such things popup in hw, pread, pwrite will be a better approach to update & read. Cheers, Jerome Glisse ------------------------------------------------------------------------- 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
