On Sun, 2009-08-02 at 17:05 +0200, Jerome Glisse wrote: > 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,
That could be a problem for vertex/index buffers on big endian, as the VAP_CNTL_STATUS byte-swapping bits are ineffective for buffers in VRAM. > 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. I do suspect we'll need something like that in the long run, but due to the above I think userspace will at least need to be able to restrict the eligible domain(s). -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ 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
