Jerome Glisse wrote: > On Fri, 16 May 2008 12:20:29 +0200 > Thomas Hellström <[EMAIL PROTECTED]> wrote: > >> Cache coherency and caching policy is a non-issue with user-space VRAM >> mappings. >> I think with the pwrite approach you will run into severe performance >> problems if used for >> long-lived buffers. >> >> Think EXA, vertical lines, perhaps no tiling. >> > > If i feel the need to map vram then i will do it. What i am stating > is that i find painfull to map object in vma (tlb flush) and to have > to deal with limited vram access (how should i handle such things ? > split the vram into one mappable the other not ? then what to do > when one object might fit in ram only if a part of it is mappable > while another not ?) So to sumup i find object mapping in vma > painfull and cumberstone, i am well aware that in the software > rendering case this was the fastest path but i am expecting that > current hw and future hw will be able to support all rendering > primitive we use. > > So in the end what i like in GEM is freedom on that kind of > choice, no complexe fencing, and the code size which enable > you to understand most of it in 5min of code reading while > for TTM despite numerous question i ask and hour i spend > starring at the code i still fill unconfortable with the > code and i have hard time to figure out by which path goes > most of my use. >
Jerome, This last section is a valid argument against TTM, and one that I accept, However I do not really like arguments against TTM based on misunderstandings and simplifications that express unawareness of performance problems and other issues that have been solved once and that will appear again later. If the GEM API is what's needed to have a common approach to memory management upstream in the kernel, we're prepared to accept that. This is the #1 priority for us, but I fear it may lead to a lot of extra work in the future. /Thomas > Cheers, > Jerome Glisse <[EMAIL PROTECTED]> > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
