[Intel-gfx] Flicker-free boot in DRM

2011-10-29 Thread Keith Packard
Steve Langasek came over today and we hacked on the i915 driver initialization code to try and avoid the initial mode set. I thought I'd summarize what we found out. * Ubuntu has hacked up grub2 so that it gets the boot monitor running in a reasonable configuration using VBE calls if

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Chris Wilson
On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky b...@bwidawsk.net wrote: These patches are pretty raw as I'm hoping to get some comments before working to hard too clean them up. The goal is GPU fairness for clients running on i915. The biggest danger I see is that num_outstanding is only

Re: [Intel-gfx] Flicker-free boot in DRM

2011-10-29 Thread Chris Wilson
On Sat, 29 Oct 2011 00:05:22 -0700, Keith Packard kei...@keithp.com wrote: * Constructing a fake drm_framebuffer is a pain; there are a million places that assume all kinds of things about the frame buffer on a crtc. This is vital as we need to capture the current GATT and stolen

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Keep track of request counts

2011-10-29 Thread Daniel Vetter
On Fri, Oct 28, 2011 at 10:55:27PM -0700, Ben Widawsky wrote: There is already a list of requests outstanding for a given client. Keeping a count is easy, and will give some information necessary to enable a more fair throttling scheme. For now a client is uniquely identified by its file

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Eric Anholt
On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky b...@bwidawsk.net wrote: These patches are pretty raw as I'm hoping to get some comments before working to hard too clean them up. The goal is GPU fairness for

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Ben Widawsky
On Sat, 29 Oct 2011 11:45:34 -0700 Eric Anholt e...@anholt.net wrote: On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky b...@bwidawsk.net wrote: These patches are pretty raw as I'm hoping to get some comments

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Ben Widawsky
On Sat, 29 Oct 2011 09:07:35 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky b...@bwidawsk.net wrote: These patches are pretty raw as I'm hoping to get some comments before working to hard too clean them up. The goal is GPU fairness for

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Keep track of request counts

2011-10-29 Thread Ben Widawsky
On Sat, 29 Oct 2011 11:35:13 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Fri, Oct 28, 2011 at 10:55:27PM -0700, Ben Widawsky wrote: There is already a list of requests outstanding for a given client. Keeping a count is easy, and will give some information necessary to enable a more fair

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Daniel Vetter
On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote: On Sat, 29 Oct 2011 11:45:34 -0700 Eric Anholt e...@anholt.net wrote: On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky b...@bwidawsk.net

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Daniel Vetter
On Sat, Oct 29, 2011 at 09:40:57PM +0200, Daniel Vetter wrote: On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote: On Sat, 29 Oct 2011 11:45:34 -0700 Eric Anholt e...@anholt.net wrote: On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On

Re: [Intel-gfx] [PATCH 0/3] RFC: force throttling/fairness

2011-10-29 Thread Ben Widawsky
On Sat, 29 Oct 2011 21:47:04 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sat, Oct 29, 2011 at 09:40:57PM +0200, Daniel Vetter wrote: On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote: On Sat, 29 Oct 2011 11:45:34 -0700 Eric Anholt e...@anholt.net wrote: On Sat, 29

Re: [Intel-gfx] [PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set

2011-10-29 Thread Eugeni Dodonov
On Fri, Oct 28, 2011 at 15:56, Keith Packard kei...@keithp.com wrote: Kernels with no iommu support cannot ever need the Ironlake work-around, so never enable it in that case. Might be better to completely remove the work-around from the kernel in this case? Signed-off-by: Keith Packard

Re: [Intel-gfx] Flicker-free boot in DRM

2011-10-29 Thread Keith Packard
On Sat, 29 Oct 2011 09:12:13 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sat, 29 Oct 2011 00:05:22 -0700, Keith Packard kei...@keithp.com wrote: * Constructing a fake drm_framebuffer is a pain; there are a million places that assume all kinds of things about the frame buffer

[Intel-gfx] [PATCH] drm/i915: Fix recursive calls to unmap

2011-10-29 Thread Ben Widawsky
After the ILK vt-d workaround patches it became clear that we had introduced a bug. Chris tracked down the issue to recursive calls to unmap. This happens because we try to optimize waiting on requests by calling retire requests after the wait, which may drop the last reference on an object and

Re: [Intel-gfx] [PATCH] drm/i915: Fix recursive calls to unmap

2011-10-29 Thread Keith Packard
On Sat, 29 Oct 2011 19:07:23 -0700, Ben Widawsky b...@bwidawsk.net wrote: + /** + * Flag if GTT ptes shouldn't be modified. + * + * This is set when graphics virtual address space + * should not be changed. It's currently only

Re: [Intel-gfx] [PATCH] drm/i915: Fix recursive calls to unmap

2011-10-29 Thread Keith Packard
On Sat, 29 Oct 2011 19:56:43 -0700, Ben Widawsky b...@bwidawsk.net wrote: Sigh. I started down that path, but it was becoming tedious with only one case where we actually want to not retire (I think), so I thought I'd see how this went down on the mailing list. I don't even want to think

Re: [Intel-gfx] Flicker-free boot in DRM

2011-10-29 Thread Keith Packard
On Sat, 29 Oct 2011 00:05:22 -0700, Keith Packard kei...@keithp.com wrote: * I've got LVDS pulling the current mode out of the hardware With a machine that has a native VBE mode for the panel, the problem is that clock computed from the hardware settings is not quite the same as the clock