On Wed, 2009-08-05 at 01:39 -0400, Alex Deucher wrote: > 2009/8/4 Michel Dänzer <[email protected]>: > > On Tue, 2009-08-04 at 11:54 +1000, Dave Airlie wrote: > >> On Tue, 2009-08-04 at 09:49 +0800, Joel Feiner wrote: > >> > 2009/8/4 Michel Dänzer <[email protected]> > >> > <snip> > >> > > >> > I wonder if maybe the slowdown I'm seeing is because the > >> > radeon driver > >> > is temporarily lacking UploadToScreen and DownloadFromScreen > >> > hooks with > >> > KMS, though I'm not sure what those would be used for with > >> > text > >> > rendering. > >> > > >> > Off-topic, but if I may enquire out of intellectual curiosity: why > >> > doesn't the KMS version of Radeon have UTS and DFS acceleration? > >> > >> The code is in the branch, but its really ugly, I was hoping to actual > >> do it cleaner which might involve a new kernel interface to ask for the > >> current placement of a buffer object so we can decide whether to just > >> memcpy or we need to blit for DFS. I'm not sure I saw a good reason for > >> UTS, doing Host data blits isn't really useful with BOs at least with > >> the current code. > > > > One potential benefit of UTS is pipelining. But I agree that DFS is > > probably more important. > > FWIW... untested. > http://www.botchco.com/alex/xorg/radeon_kms_uts.diff
You want to avoid any explicit flushes or even waits for destination BO idle, those would defeat any potential pipelining benefits. Otherwise looks like it could work though. :) -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
