Hi Jin,
Thanks for your reply.
I'm not familiar with MeeGo.
Is it possible to retrieve the graphic driver from MeeGo and put it to
generic linux for X.org server??
--
Kevin Kuei
On Fri, Feb 17, 2012 at 10:43 AM, Jin, Gordon wrote:
> > -Original Message-
> > From: intel-gfx-bounces+gord
> -Original Message-
> From: intel-gfx-bounces+gordon.jin=intel@lists.freedesktop.org
> [mailto:intel-gfx-bounces+gordon.jin=intel@lists.freedesktop.org] On
> Behalf Of Daniel Vetter
> Sent: Wednesday, February 15, 2012 8:54 PM
> To: Kevin Kuei
> Cc: intel-gfx@lists.freedesktop.org
On Thu, 16 Feb 2012 18:38:08 +0100, Daniel Vetter wrote:
> On Thu, Feb 16, 2012 at 08:48:07AM -0800, Eric Anholt wrote:
> > On Thu, 16 Feb 2012 13:11:31 +0100, Daniel Vetter
> > wrote:
> > > No longer needed.
> >
> > What this code was for: Before gtt mapping, we were doing software
> > fallbac
On Thu, 16 Feb 2012 18:38:08 +0100, Daniel Vetter wrote:
> If old mesa depends on sub-page reads/writes to tiled objects I need to
> create the respective tests and double-check the code, otherwise I think
> we're covered. Do you want me to adapt the tests to check correctness for
> sub-page reads
On Thu, 16 Feb 2012 14:58:59 +0100, Ben Widawsky wrote:
> On Thu, 16 Feb 2012 13:21:42 +0100
> Ben Widawsky wrote:
>
> > On Thu, 16 Feb 2012 13:04:14 +0100
> > Ben Widawsky wrote:
> >
> > > On Wed, 15 Feb 2012 12:33:38 -0800
> > > Eric Anholt wrote:
> > >
> > > > On Tue, 14 Feb 2012 22:09:07
On Thu, Feb 16, 2012 at 08:48:07AM -0800, Eric Anholt wrote:
> On Thu, 16 Feb 2012 13:11:31 +0100, Daniel Vetter
> wrote:
> > No longer needed.
>
> What this code was for: Before gtt mapping, we were doing software
> fallbacks in Mesa with pread/write on pages at a time (or worse) of the
> frame
Hi all,
Updated -next and -testing trees. I haven't merged in any of the patches
Jesse queued up because he hasn't yet pushed out his latest -fixes tree.
No cookies for Jesse today!
Highlights:
- interlaced support for i915. Again thanks a lot to all the ppl who help
out with testing, patches a
On Thu, 16 Feb 2012 13:11:31 +0100, Daniel Vetter
wrote:
> No longer needed.
What this code was for: Before gtt mapping, we were doing software
fallbacks in Mesa with pread/write on pages at a time (or worse) of the
framebuffer. It would regularly result in hitting the same page again,
since I
On Thu, Feb 16, 2012 at 09:32:08PM +0800, Hillf Danton wrote:
> On Thu, Feb 16, 2012 at 8:01 PM, Daniel Vetter wrote:
> > @@ -416,17 +417,20 @@ static inline int fault_in_pages_writeable(char
> > __user *uaddr, int size)
> > * Writing zeroes into userspace here is OK, because we know that
On Thu, 16 Feb 2012 13:21:42 +0100
Ben Widawsky wrote:
> On Thu, 16 Feb 2012 13:04:14 +0100
> Ben Widawsky wrote:
>
> > On Wed, 15 Feb 2012 12:33:38 -0800
> > Eric Anholt wrote:
> >
> > > On Tue, 14 Feb 2012 22:09:07 +0100, Ben Widawsky
> > > wrote:
> > > > These patches are a heavily revis
On Thu, Feb 16, 2012 at 11:44:46AM +, Daniel J Blueman wrote:
> When charging Dell E5420 laptops, I see the Sandy Bridge South Display
> Engine port C hotplug interrupt fire consistently at around 20Hz. Each
> scan on the connectors results in ~100ms hold time for the mode_config
> mutex which
On Thu, 16 Feb 2012 13:04:14 +0100
Ben Widawsky wrote:
> On Wed, 15 Feb 2012 12:33:38 -0800
> Eric Anholt wrote:
>
> > On Tue, 14 Feb 2012 22:09:07 +0100, Ben Widawsky wrote:
> > > These patches are a heavily revised version of the patches I wrote over
> > > a year ago. These patches have pass
While moving around things, this two functions slowly grew out of any
sane bounds. So extract a few lines that do the copying and
clflushing. Also add a few comments to explain what's going on.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 192 +++---
It's around 20% faster.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 48bef0b..9f49421 100644
--- a/drivers/gpu/drm/i915/i915_g
It's too expensive to move it around just for that pwrite, especially
when we're trashing on the mappable gtt part like crazy.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
In micro-benchmarking of the usual pwrite use-pattern of alternating
pwrites with gtt domain reads from the gpu, this yields around 30%
improvement of pwrite throughput across all buffers size. The trick is
that we can avoid clflush cachelines that we will overwrite completely
anyway.
Furthermore
The pagemap.h prefault helpers do the prefaulting by simply writing
some data into every page. Hence we should not prefault when we're not
yet commited to to actually writing data to userspace. The problem is
now that
- we can't prefault while holding dev->struct_mutex for we could
deadlock with
With the proper prefault, it's extremely unlikely that we fall back
to the gtt slowpath.
So just kill it and use the shmem_pwrite path as fallback.
To further clean up the code, move the preparatory gem calls into the
respective pwrite functions. This way the gtt_fast->shmem fallback
is much more
drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.
I've checked the callsites and they all already clamp size when
calling fault_in_pages_* to the same as for the subsequent
__copy_to|from_user and hence don't rely on the implicit
This speeds up pwrite and pread from ~120 µs ro ~100 µs for
reading/writing 1mb on my snb (if the backing storage pages
are already pinned, of course).
v2: Chris Wilson pointed out a claring page reference bug - I've
unconditionally dropped the reference. With that fixed (and the
associated reduct
~120 µs instead fo ~210 µs to write 1mb on my snb. I like this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d23d324..0446c4c 10064
No longer needed.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |7 --
drivers/gpu/drm/i915/i915_gem.c | 117 ---
2 files changed, 0 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i9
This is obviously gonna slow down pread. But for a half-way realistic
micro-benchmark, it doesn't matter: Non-broken userspace reads back
data from the gpu once before the gpu again dirties it.
So all this ranged clflush tracking is just a waste of time.
No pread performance change (neglecting th
Useful when the page is already mapped to copy date in/out.
For -stable because the next patch (fixing phys obj pwrite) needs this
little helper function.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_cache.c | 23 +++
include/drm
With the previous rewrite, they've become essential identical.
v2: Simplify the page_do_bit17_swizzling logic as suggested by Chris
Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 108 ++-
1 files changed, 27 insertions(+), 81 dele
With the previous rewrite, they've become essential identical.
v2: Simplify the page_do_bit17_swizzling logic as suggested by Chris
Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 126 ++
1 files changed, 33 insertions(+), 93 delet
Hi all,
So here we go with the scary patches ;-)
I've been beating in this up and down and we also now have a fairly
nice set of i-g-t tests to check corner-cases of the clflushing and
similar. The mm prefault helper patch is included here for context,
I've submitted that for inclusion through -m
On Wed, 15 Feb 2012 12:33:38 -0800
Eric Anholt wrote:
> On Tue, 14 Feb 2012 22:09:07 +0100, Ben Widawsky wrote:
> > These patches are a heavily revised version of the patches I wrote over
> > a year ago. These patches have passed basic tests on SNB, and IVB, and
> > older versions worked on ILK.
drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.
I've checked the callsites and they all already clamp size when
calling fault_in_pages_* to the same as for the subsequent
__copy_to|from_user and hence don't rely on the implicit
Hi all,
drm/i915 has write/read paths to upload/download data to/from gpu buffer
objects. For a bunch of reasons we have special fastpaths with decent setup
costs, so when we fall back to the slow-path we don't fully recover to the
fastest fast-path when grabbing our locks again. This is also in p
Keith, Eric,
When charging Dell E5420 laptops, I see the Sandy Bridge South Display
Engine port C hotplug interrupt fire consistently at around 20Hz. Each
scan on the connectors results in ~100ms hold time for the mode_config
mutex which blocks eg the cursor set ioctl (due to the I2C read
timeouts
On Wed, 15 Feb 2012 12:11:58 -0800
Eric Anholt wrote:
> On Tue, 14 Feb 2012 22:09:13 +0100, Ben Widawsky wrote:
> > This is the HW dependent context switch code.
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_drv.h |3 +
> > drivers/gpu/drm/i915/intel_ri
Am Donnerstag, den 16.02.2012, 11:03 +0100 schrieb Daniel Vetter:
> gcc seems to get uber-anal recently about these things.
which was introduced by the following commit.
96154f2faba5: "drm/i915: switch ring->id to be a real id"
> Reported-by: Dan Carpenter
The URL of the report is the
gcc seems to get uber-anal recently about these things.
Reported-by: Dan Carpenter
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b
34 matches
Mail list logo
