On Thu, 2009-09-24 at 15:25 +1000, Dave Airlie wrote: > On Thu, Sep 24, 2009 at 3:16 PM, Dave Airlie <airl...@gmail.com> wrote: > > From: Dave Airlie <airl...@redhat.com> > > > > This avoids needing to do a kmalloc > PAGE_SIZE for the main > > indirect buffer chunk, it adds an accessor for all reads from > > the chunk and caches a single page at a time for subsequent > > reads. > > > > changes since v1: > > Use a two page pool which should be the most common case > > a single packet spanning > PAGE_SIZE will be hit, but I'm > > having trouble seeing anywhere we currently generate anything like that. > > r600: untested conversion > > hopefully proper short page copying at end > > added parser_error flag to set deep errors instead of having to test > > every ib value fetch. > > I've left one bug in here see if you can see it :-) > > the extra pages copy starts one page too soon, but its probably not > a greatly hit path as it relies on a packet > 4096 also.
FWIW, I've been working on merging several Composite operations into a single draw packet in RadeonCompositeTile in the X driver, to decrease the CS checking overhead. That should quite easily generate a single packet > 4096 bytes (e.g. rendering more than about 40 characters in one go, if my math is right). -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
