On Sun, 2009-08-02 at 16:08 +0200, Michel Dänzer wrote: > On Sun, 2009-08-02 at 15:56 +0200, Jerome Glisse wrote: > > On Sun, 2009-08-02 at 08:53 +1000, Dave Airlie wrote: > > > On Sun, Aug 2, 2009 at 12:48 AM, Jerome Glisse<gli...@freedesktop.org> > > > wrote: > > > > > > > > Corollary the TTM priority stuff is i believe a wrong idea > > > > for radeon (could be usefull for others GPU but i don't have > > > > such feeling). So i would like to be able to disable it and > > > > move the knowledge in radeon kernel driver, here is my thinking > > > > on that : > > > > > > > > domain provided by userspace is a tip given to the kernel > > > > Then the kernel driver will be the one to choose where to > > > > put the buffer. For instance userspace can create an object > > > > in GTT space because this object will routinely accessed > > > > by the CPU, but at one point the GPU might need to write to > > > > it and most of the time we really want to put all buffer > > > > the GPU write to into VRAM. So kernel could move the object > > > > to VRAM for doing the rendering. > > > > > > > > Any thoughts on that ? > > > > > > The whole problem with aperture sizing and when to flush > > > optimally is quite messy when things are just hints. Maybe > > > you need to redesign CS with stream break points, I think > > > Thomas did or was thinking about this for Openchrome. > > > > Nothings change for counting how memory a cs needs, it makes > > the code simpler as there is only one domain and its up to > > ddx to properly ask for vram on object which are dst. So > > accounting for gtt/vram use is the same, code is just simpler. > > The way it's done now, the kernel can transparently put a source BO in > GTT if there's no space in VRAM. How would that be handled with your > idea?
Same, kernel can decide to put things in vram or gtt, domain given by userspace is just a hint, moreover i added creation time stamp while adding statistics stuff to kms and i think kernel could use that to decide wether it's worth it or not to put a bo in vram, also kernel could use others informations for that such as if the buffer is a render buffer, ... Well given enough informations (object life time, is it a render buffer, hint given by userspace, ...) kernel could make a good guess on where it's best to put a bo. > > Also while testing, it seems current code space checking > > fails hard with 16M vram, 16M gtt > > VRAM usage: > > 7M for fbcon, 7M for front buffer, so pretty much no vram left > > I'm working on fixing the fbcon BO always being pinned in VRAM, almost > done. :) Thanks a lot for looking into that :) Cheers, Jerome ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
