Re: [Intel-gfx] [PATCH] agp/intel, drm/i915: Use a write-combining map for updating PTEs
On Sun, Aug 12, 2012 at 08:12:02PM +0100, Chris Wilson wrote: On Sun, 12 Aug 2012 17:01:08 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, 12 Aug 2012 17:47:46 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 12, 2012 at 12:04:39PM +0100, Chris Wilson wrote: In order to be able to ioremap_wc the GTT space, we need to remove the conflicting pci_iomap from drm/i915, so we limit the register map in drm/i915 to the suitable range for each generation. The benefit of doing this is an order of magnitude reduction in time spent rewriting the GTT entries when inserting and removing objects. For example, this halves the CPU time spent in X when pushing pixels for chromium through a userptr (chromium has a bug where it likes to recreate its ShmPixmap on every draw). Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk How well does this work with ums? I guess if it blows up, we could ioremap uncached, but when kms initializes drop that uc mapping and try to remap wc. But I fear that ums will map the entire bar and hence we can't just unconditionally map the gatt wc. It will work equisitely with ums. It will fail to do as it wishes and fallback to VESA and everybody will be much happier... So having rediscovered the hard truth that i915.modeset=1 and xf86-video-2.6.0 results in nasty hangs, setting the GTT table to WC has no effect upon the ancient UMS module - it shows the retro background and appears to function. We struck lucky. \o/ Ok, let's them the wrath of the abi gods. Merged to -queued, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] agp/intel, drm/i915: Use a write-combining map for updating PTEs
On Sun, Aug 12, 2012 at 12:04:39PM +0100, Chris Wilson wrote: In order to be able to ioremap_wc the GTT space, we need to remove the conflicting pci_iomap from drm/i915, so we limit the register map in drm/i915 to the suitable range for each generation. The benefit of doing this is an order of magnitude reduction in time spent rewriting the GTT entries when inserting and removing objects. For example, this halves the CPU time spent in X when pushing pixels for chromium through a userptr (chromium has a bug where it likes to recreate its ShmPixmap on every draw). Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk How well does this work with ums? I guess if it blows up, we could ioremap uncached, but when kms initializes drop that uc mapping and try to remap wc. But I fear that ums will map the entire bar and hence we can't just unconditionally map the gatt wc. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] agp/intel, drm/i915: Use a write-combining map for updating PTEs
On Sun, 12 Aug 2012 17:47:46 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 12, 2012 at 12:04:39PM +0100, Chris Wilson wrote: In order to be able to ioremap_wc the GTT space, we need to remove the conflicting pci_iomap from drm/i915, so we limit the register map in drm/i915 to the suitable range for each generation. The benefit of doing this is an order of magnitude reduction in time spent rewriting the GTT entries when inserting and removing objects. For example, this halves the CPU time spent in X when pushing pixels for chromium through a userptr (chromium has a bug where it likes to recreate its ShmPixmap on every draw). Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk How well does this work with ums? I guess if it blows up, we could ioremap uncached, but when kms initializes drop that uc mapping and try to remap wc. But I fear that ums will map the entire bar and hence we can't just unconditionally map the gatt wc. It will work equisitely with ums. It will fail to do as it wishes and fallback to VESA and everybody will be much happier... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] agp/intel, drm/i915: Use a write-combining map for updating PTEs
On Sun, 12 Aug 2012 17:01:08 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, 12 Aug 2012 17:47:46 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 12, 2012 at 12:04:39PM +0100, Chris Wilson wrote: In order to be able to ioremap_wc the GTT space, we need to remove the conflicting pci_iomap from drm/i915, so we limit the register map in drm/i915 to the suitable range for each generation. The benefit of doing this is an order of magnitude reduction in time spent rewriting the GTT entries when inserting and removing objects. For example, this halves the CPU time spent in X when pushing pixels for chromium through a userptr (chromium has a bug where it likes to recreate its ShmPixmap on every draw). Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk How well does this work with ums? I guess if it blows up, we could ioremap uncached, but when kms initializes drop that uc mapping and try to remap wc. But I fear that ums will map the entire bar and hence we can't just unconditionally map the gatt wc. It will work equisitely with ums. It will fail to do as it wishes and fallback to VESA and everybody will be much happier... So having rediscovered the hard truth that i915.modeset=1 and xf86-video-2.6.0 results in nasty hangs, setting the GTT table to WC has no effect upon the ancient UMS module - it shows the retro background and appears to function. We struck lucky. \o/ -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
