Just a quite note to say that drm-intel-next-proposed has been updated
with all the feedback received yesterday. Get testing!
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
From: Eric Anholt
The simplest and common method for ensuring scanout coherency on all
chipsets is to mark the scanout buffers as uncached (and for
userspace to remember to flush the render cache every so often).
We can improve upon this for later generations by marking scanout
objects as GFDT a
We need to perform a few operations in order to move the object into the
display plane (where it can be accessed coherently by the display
engine) that are important for future safety to forbid whilst pinned. As a
result, we want to need to perform some of operations before pinning,
but some are re
Hi,
We'd like to announce Intel 2011Q1 graphics package, with bug fixes as usual,
and improved support for Sandy Bridge.
Please check http://intellinuxgraphics.org/2011Q1.html for the recommended
stack, new features and known issues.
Thanks community for helping improving the drivers. If you
On Wed, Apr 13, 2011 at 08:56:26PM +0100, Chris Wilson wrote:
> On Wed, 13 Apr 2011 21:26:24 +0200, Daniel Vetter wrote:
> > On Tue, Apr 12, 2011 at 09:31:52PM +0100, Chris Wilson wrote:
> > > Replace the three nearly identical copies of the code with a single
> > > function. And take advantage of
On Thu, 14 Apr 2011 19:34:17 +0200, Daniel Vetter wrote:
> After the movement all three code-paths suffer from
> if (ret)
> goto foo_unpin;
> before anything is actually pinned. With that fixed, it's
My only defense was that was about the third or fifth variation that I
tried
... to clarify just how we use it inside the driver and remove the
confusion of the poorly matching agp_type names. We still need to
translate through agp_type for interface into the fake AGP driver.
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
---
drivers/
On Thu, 14 Apr 2011 19:43:35 +0200, Daniel Vetter wrote:
> On Thu, Apr 14, 2011 at 10:03:46AM +0100, Chris Wilson wrote:
> > + if (INTEL_INFO(dev)->gen < 6 &&
> > + args->tiling_mode != I915_TILING_NONE &&
> > + obj->cache_level != I915_CACHE_NONE) {
> > + DRM_DEBUG("can't
On Thu, 14 Apr 2011 18:12:13 +0200, Daniel Vetter wrote:
> But every time I bang my head against this particular wall, the only thing
> I can come up with is some abomination from hell. And I've been tossing
> around ideas for the better part of a year already with no luck.
Hear, hear. My feeling
On Thu, 14 Apr 2011 12:15:54 -0700, Jesse Barnes
wrote:
> On Wed, 13 Apr 2011 09:15:29 +0100
> I'd rather keep flips in the nowait case, but use async flips instead,
> but that requires a kernel change (I thought we had a flip flag for
> this but I guess it got lost on its way upstream).
I alway
Dear Ben,
Am Donnerstag, den 14.04.2011, 11:13 -0700 schrieb Ben Widawsky:
> userspace to the forcewake reference count via debugfs.
>
> v2:
> use new spin_locks instead of struct_mutex
in my opinion these remarks should not go into the commit message.
Reading the commit log the reader is not i
On Wed, 13 Apr 2011 09:15:29 +0100
Chris Wilson wrote:
> As fullscreen swaps were going via a different path to the swapping of
> ordinary windows, we were no longer honouring the xorg.conf option to
> disable swapbuffer waiting.
>
> This changes the code to only use pageflipping if the Option
>
userspace to the forcewake reference count via debugfs.
v2:
use new spin_locks instead of struct_mutex
v3:
spin locks are acquired by the get/put functions now
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 73 +++
1 files changed, 73 in
Provide a reference count to track the forcewake state of the GPU. The
savings is up to 1 UC read if the unit is already awake, but the main
goal is to give userspace some mechanism to wake the GPU.
v2:
Added a spin_lock for synchronizing access to forcewake. The lock
should not be heavily contest
userspace to the forcewake reference count via debugfs.
v2:
use new spin_locks instead of struct_mutex
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 77 +++
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/
Provide a reference count to track the forcewake state of the GPU. The
savings is up to 1 UC read if the unit is already awake, but the main
goal is to give userspace some mechanism to wake the GPU.
v2:
Added a spin_lock for synchronizing access to forcewake. The lock
should not be heavily contest
Moved the macros around to properly do reads and writes for the given
gpu. This is to address special requirements for gen6 (SNB) reads and
writes.
v2:
no change
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 56 ++
drivers/gpu/drm/i915/i
As the patches say, I don't think adding this spinlock will have too
much of a performance impact (I couldn't notice anything in my limited
testing), because the serializing locks are already held when acquiring
this lock. I suppose it now serializes access between stuct_mutex and
config.lock, but
GIT: [Intel-gfx] [PATCH 1/3] drm/i915: proper use of forcewake
GIT: [Intel-gfx] [PATCH 2/3] drm/i915: refcounts for forcewake
GIT: [Intel-gfx] [PATCH 3/3] drm/i915: userspace interface to the forcewake
refcount
___
Intel-gfx mailing list
Intel-gfx@lists.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
You need the latest release of the kernel, libdrm, xf86-video-intel and
mesa. If you're uneasy with installing all that from source please ask on
ubuntu channels for help. They have awesome support for this with
precompiled packages in ppa's of all the latest stuff.
Yours, Daniel
On Thu, Apr
On Thu, Apr 14, 2011 at 10:03:46AM +0100, Chris Wilson wrote:
> Older chipsets do not support snooping (i.e. cache sharing between the
> CPU and GPU) on tiled surfaces. So prevent userspace from being silly
> should we one day expose the ability to change cache levels from
> userspace.
>
> It does
On Thu, Apr 14, 2011 at 10:03:44AM +0100, Chris Wilson wrote:
> The docs warn us to be particularly careful not to write to a snooped
> page through the GTT. Fortunately, this ties in very well with the
> existing pwrite infrastucture to use the CPU domain where preferable and
> the API already imp
On Thu, Apr 14, 2011 at 10:03:42AM +0100, Chris Wilson wrote:
> A few operations we do in order to move the object into the display
> plane it is important for future safety to forbid whilst pinned. As a
> result, we want to pin afterwards. At the moment, setting to the display
> plane of an unboun
Reviewed-by: Daniel Vetter
--
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
It's great when I can just throw an idea over the wall and Chris checks
whether it actually sticks ;-)
Reviewed-by: Daniel-Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
On Thu, Apr 14, 2011 at 10:03:38AM +0100, Chris Wilson wrote:
> Like its siblings finish_gpu(), this function clears the object from the
> GTT domain forcing it to be trigger a domain invalidation should we ever
> need to use via the GTT again.
>
> Note that the most important side-effect of finis
On Thu, Apr 14, 2011 at 10:03:37AM +0100, Chris Wilson wrote:
> ... reincarnated from i915_gem_object_flush_gpu(). The semantic
> difference is that after calling finish_gpu() the object no longer
> resides in any GPU domain, and so will cause the GPU caches to be
> invalidated if it is ever used a
Hi,
I would like to know if you could tell me where I can find information on how
to
install drivers for an Core i3 2100 integrated graphics?
I am using Ubuntu 10.10 and it does not seem to detect the HW even when I
update
things like mesa etc.
Thanks
Habeeb_
On Thu, 14 Apr 2011 10:03:35 +0100, Chris Wilson
wrote:
> ... to clarify just how we use it inside the driver. We still need to
> translate through agp_type for interface into the fake AGP driver.
agp_type has some really confusing semantics...
> - obj->agp_type = AGP_USER_MEMORY;
> + o
After a quiet couple of days, I want to get the bug fixes we have
accumulated shipped. Thank you everybody for your invaluable testing and
feedback.
-Chris
We are pleased to announce this major release of the xf86-video-intel
driver, roughly on schedule at 3 months since 2.14.0. With the many bug
... to clarify just how we use it inside the driver. We still need to
translate through agp_type for interface into the fake AGP driver.
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
drivers/gpu
Rely on the GPU snooping into the CPU cache for appropriately bound
objects on MI_FLUSH. Or perhaps one day we will have a cache-coherent
CPU/GPU package...
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 11 +++
... reincarnated from i915_gem_object_flush_gpu(). The semantic
difference is that after calling finish_gpu() the object no longer
resides in any GPU domain, and so will cause the GPU caches to be
invalidated if it is ever used again.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv
From: Eric Anholt
Improves full-screen openarena on my laptop 20.3% +/- 4.0% (n=3)
Improves 800x600 nexuiz on my laptop 12.3% +/- 0.1% (n=3)
We have more room to improve with doing LLC caching for display using
GFDT, and in doing LLC+MLC caching, but this was an easy performance
win and incremen
Older chipsets do not support snooping (i.e. cache sharing between the
CPU and GPU) on tiled surfaces. So prevent userspace from being silly
should we one day expose the ability to change cache levels from
userspace.
It does enforce a strict ordering for mode changing though. So in order
to change
... in preparation for changing the cache level (and thus the flags upon
the PTEs) dynamically.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 41 +-
1 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
[anholt v2: Don't forget that when going from cached to uncached, we
haven't been tracking the write domain from the CPU perspective, since
we haven't needed it for GPU coherency.]
[ickle v3: We also need to make sure we relinquish any fences on older
chipsets and clear the GTT for sane domain tra
A few operations we do in order to move the object into the display
plane it is important for future safety to forbid whilst pinned. As a
result, we want to pin afterwards. At the moment, setting to the display
plane of an unbound object is simply to bind it, so
set_to_display_plane() becomes a no-
The docs warn us to be particularly careful not to write to a snooped
page through the GTT. Fortunately, this ties in very well with the
existing pwrite infrastucture to use the CPU domain where preferable and
the API already implies that the write is CPU linear..
Signed-off-by: Chris Wilson
---
The docs have a dire warning not to attempt to access snooped (the old
style of cache sharing on pre-SandyBridge chipsets) pages through the GTT.
Prevent userspace from doing so by sending them a SIGBUS if they try.
[Now it is possible with a bit of extra complexity to map the snooped
CPU page int
From: Eric Anholt
The simplest and common method for ensuring scanout coherency on all
chipsets is to mark the scanout buffers as uncached (and for
userspace to remember to flush the render cache every so often).
We can improve upon this for later generations by marking scanout
objects as GFDT a
Signed-off-by: Chris Wilson
Signed-off-by: Eric Anholt
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gp
Like its siblings finish_gpu(), this function clears the object from the
GTT domain forcing it to be trigger a domain invalidation should we ever
need to use via the GTT again.
Note that the most important side-effect of finishing the GTT domain
(aside from clearing the tracking read/write domains
As nobody objected to, as expected, the modesetting refactor and the
fixes Ben did for rc6 on Ironlake, I've pushed those on to the
drm-intel-next branch.
This patchset just contains the LLC material as it has seen a lot of
changes yesterday and I'd like to review the new material in context.
Tha
45 matches
Mail list logo