On Tue, Sep 04, 2012 at 09:02:58PM +0100, Chris Wilson wrote:
> By providing a callback for when we need to bind the pages, and then
> release them again later, we can shorten the amount of time we hold the
> foreign pages mapped and pinned, and importantly the dmabuf objects then
> behave as any o
On Thu, Sep 13, 2012 at 01:42:01PM -0700, Jesse Barnes wrote:
> On Thu, 6 Sep 2012 22:08:35 +0200
> Daniel Vetter wrote:
>
> > Hopefully this makes userspace slightly less confused about us
> > frobbing the dpms state behind its back. Yeah, it would be better
> > to be more careful with not chan
On Fri, Sep 14, 2012 at 11:50:30AM -0700, Ben Widawsky wrote:
> On Fri, 14 Sep 2012 11:57:46 +0100
> Chris Wilson wrote:
>
> > In the future we may like to experiment with using a WC map of the GTT
> > portion. However, that will conflict with i915.ko mapping the entire bar
> > as UC in order to
Hi
2012/9/14 Daniel Vetter :
> On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote:
>> This tree gives me recursive dependency problems, which ends up
>> removing a big (& important) part of my .config:
>>
>> [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09
>> HEAD is now
On Fri, 14 Sep 2012 11:57:46 +0100
Chris Wilson wrote:
> In the future we may like to experiment with using a WC map of the GTT
> portion. However, that will conflict with i915.ko mapping the entire bar
> as UC in order to access the GPU registers. Instead we can shrink the
> register ioremap to
On Fri, Sep 07, 2012 at 07:43:45PM -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
One small improvement would be nice:
[snip]
> +static void writeval(FILE *filp, int val)
> +{
> + rewind(filp);
> + fprintf(filp, "%d", val);
> + fflush(filp);
> +}
Adding some assert
On Fri, 14 Sep 2012 11:02:02 -0700, Ben Widawsky wrote:
> On Tue, 4 Sep 2012 21:02:58 +0100
> Chris Wilson wrote:
> > @@ -3731,9 +3731,6 @@ void i915_gem_free_object(struct drm_gem_object
> > *gem_obj)
> >
> > trace_i915_gem_object_destroy(obj);
> >
> > - if (gem_obj->import_attach)
>
Hi Daniel,ok fixing cpu freq static to max (2700MHz) on both cores does increase performance a little bit however gpu freq reported by /sys/class/drm/card0/gt_cur_freq_mhz stays fixed at 650 MHz.
-Nic
Gesendet: Freitag, 14. September 2012 um 18:44 Uhr
Von: "Daniel Vetter"
On Tue, 4 Sep 2012 21:02:58 +0100
Chris Wilson wrote:
> By providing a callback for when we need to bind the pages, and then
> release them again later, we can shorten the amount of time we hold the
> foreign pages mapped and pinned, and importantly the dmabuf objects then
> behave as any other
On Fri, Sep 07, 2012 at 07:43:44PM -0700, Ben Widawsky wrote:
> This is useful for userspace utilities which wish to use the previous
> interface, specifically for micromanaging the increase/decrease steps by
> setting min == max.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Ben Widawsky
I've
On Fri, Sep 14, 2012 at 06:23:59PM +0200, Nicolas Kalkhof wrote:
> Hello,
>
> the patchset from ~danvet/drm-intel git from earlier september concerning
> forcewake and gpu frequency made my SNB much calmer during idle times. However
> the GPU won't hit the turbo throttle when the load goes up res
On Thu, Sep 13, 2012 at 07:17:55PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/9/9 Daniel Vetter :
> > This has been tons of fun to figure out with git blame. The first
> > notion of this code block goes back to the original cpu edp enabling
> > for ilk in
> >
> > commit 32f9d658aee5be09ebdd28fc73063
On Fri, Sep 14, 2012 at 04:24:46PM +0300, Jani Nikula wrote:
> On Fri, 14 Sep 2012, Chris Wilson wrote:
> > The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
> > a drm_i915_gem_relocation_entry is very confusing!
>
> Reviewed-by: Jani Nikula
Queued for -next, thanks for the
Hello,the patchset from ~danvet/drm-intel git from earlier september concerning forcewake and gpu frequency made my SNB much calmer during idle times. However the GPU won't hit the turbo throttle when the load goes up resulting in very low framerates during gameplay. Most times the frequency read
On Fri, Sep 14, 2012 at 09:55:58AM -0400, Bobby Powers wrote:
> This tree gives me recursive dependency problems, which ends up
> removing a big (& important) part of my .config:
>
> [bpowers@fina linux]$ git reset --hard drm-intel-next-2012-09-09
> HEAD is now at e04190e drm/fb helper: don't call
On 9/14/12 10:19 AM, Takashi Iwai wrote:
Hi,
we've got a machine showing a ghost DP2 output on a docking station.
The docking station has only one DP port and it's connected to DP1.
As a result, we get an DP2 active output containing the bogus VESA
standard modes 1024x768, 800x600, 640x480 altho
Hello,
I get an issue with mac book pro retina with git snapshot of kernel[1].
the screen flickering like this http://www.youtube.com/watch?v=Oq0l-bHmSYE
anyone has an idea where the issue can come ?
if not this could be a bug report ^^
the flickering is more visible on screen update, like refr
Hi,
we've got a machine showing a ghost DP2 output on a docking station.
The docking station has only one DP port and it's connected to DP1.
As a result, we get an DP2 active output containing the bogus VESA
standard modes 1024x768, 800x600, 640x480 although it's not connected
at all.
Looking a b
On Fri, 14 Sep 2012, Chris Wilson wrote:
> The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
> a drm_i915_gem_relocation_entry is very confusing!
Reviewed-by: Jani Nikula
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |9 +++--
On Fri, 14 Sep 2012 11:57:47 +0100, Chris Wilson
wrote:
> v2: Limit the WC mapping to older generations as we should the TLB
> invalidation on SandyBridge+ unreliable.
/me fires his editor and proof-reader
v2: Limit the WC mapping to older generations as we have observed that
the TLB invalidati
Rewriting the PTE entries using an WC mapping is roughly an order of
magnitude faster than through the uncached mapping. This makes an
observable difference on workloads that cycle through large numbers of
buffers, for example Chromium using ShmPixmaps where virtually all the
CPU time is currently
In the future we may like to experiment with using a WC map of the GTT
portion. However, that will conflict with i915.ko mapping the entire bar
as UC in order to access the GPU registers. Instead we can shrink the
register ioremap to only map the register block.
Signed-off-by: Chris Wilson
---
d
The exec_list is of type drm_i915_gem_exec_object2 and so casting it to
a drm_i915_gem_relocation_entry is very confusing!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i9
23 matches
Mail list logo
