On Sun, 2009-08-02 at 17:12 +0200, Michel Dänzer wrote: > 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.
Kernel does know it's on ppc and it can force vertex/index buffer to be in GTT. > > 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). Kernel know as much as userspace on hw limitation (i think kernel might even know more things about limitation than userspace) what kernel does always know is how one object will be use by userspace (used one time, multiple time, always as a render buffer, always as a texture ...) and i think userspace can give sensible hint on this through domain. 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
