[Intel-gfx] [PATCH 3/3] drm/i915: fairness

We now have enough information to be able to block apps which are getting greedy. We don't have HW support for preempting batches, therefore the finest granularity for which we can schedule is the batch buffer. We can block clients at the time they submit if they've gone too many batches ahead . T

[Intel-gfx] [PATCH 2/3] drm/i915: Add waitq/wakeups for our per fd requests

With the previous patch we got counts of outstanding requests per i915 client. It's trivial now to add a waitqueue, and wakeup events for arbitrary thresholds. Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_dma.c |1 + drivers/gpu/drm/i915/i915_drv.c |3 +++ drivers/gpu/drm/i9

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

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 descriptor, however this may change in the future with new process APIs

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

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. These are simplified versions of some patches which I've been working on for an internal customer. These patches are designed to keep clie

[Intel-gfx] [PATCH 2/4] intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done.

--- intel/intel_bufmgr_gem.c | 30 +- 1 files changed, 21 insertions(+), 9 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 94549f8..cebf732 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -196,6 +196,9 @@ st

[Intel-gfx] [PATCH 4/4] configure: version bump for 2.4.27 release.

Push the new Intel API for use by mesa. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index cd3ac23..95d64a7 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,7 @@ AC_PREREQ([2.63]) AC_INIT([libdrm], -[2.4

[Intel-gfx] [PATCH 1/4] intel: Remove stale comment.

This used to be next to some map refcounting code, but that is long dead. --- intel/intel_bufmgr_gem.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 54433ea..94549f8 100644 --- a/intel/intel_bufmgr_gem.c +++ b/i

[Intel-gfx] [PATCH 3/4] intel: Share the implementation of BO unmap between CPU and GTT mappings.

Before this, consumers of the libdrm API that might map a buffer either way had to track which way was chosen at map time to call the appropriate unmap. This relaxes that requirement by making drm_intel_bo_unmap() always appropriate. --- intel/intel_bufmgr_gem.c | 20 +--- 1 fil

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

On Fri, 28 Oct 2011 10:56:29 -0700 Keith Packard 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 > Cc:

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

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 Cc: Ben Widawsky --- Here's a shorter patch which just elides the body of th

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

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 Cc: Ben Widawsky --- drivers/char/agp/intel-gtt.c |4 1 files chang

Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subsequest GPU lockup

Hi, good question. I don't use hibernate so I can't say anything to that. :-( Regards Nic -Ursprüngliche Nachricht- Von: "Bojan Smojver" Gesendet: Oct 28, 2011 4:45:31 PM An: nkalk...@web.de Betreff: Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subseq

Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subsequest GPU lockup

--- Original message --- From: Nicolas Kalkhof No Idea if all of these params are effective but this works for me on my lenovo t420 with a i7 2620M. Out of curiosity, unrelated to this problem and because you have similar hardware to mine - do repeated hibernate/thaw cycles cause th

Re: [Intel-gfx] Question about how to troubleshoot sandybridge kernel opps and subsequest GPU lockup

Hi, looks like a known issue with mobile snb chips when rc6 is enabled. Please try to disable rc6 with  i915.i915_enable_rc6=0 in your kernel cmd line. This should take care of the wakeup hangs but also causes the gpu to disregard power saving, draining approx 10 watts more from the system. If d

[Intel-gfx] gen6 System freezes When Starting Eclipse using latest xf86-video-intel git (SNA)

Hello, I'm experiencing a total system freeze when I try to start eclipse using the latest xf86-video-intel git with --enable-sna. Older GIT versions (approx 3 days ago) work fine. No debug/syslog output is being produced. Could anyone confirm this issue, please? Regards Nic __