On Sun, 2009-08-02 at 17:31 +0200, Jerome Glisse wrote: > 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<[email protected]> 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.
That would preclude userspace from being able to use them in VRAM at all. Please not. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
