On Sat, Jul 09, 2011 at 09:38:50AM +0100, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 4fc9738..2fce620 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -503,6 +503,19 @@ out:
> return r
On Sat, 09 Jul 2011 22:23:28 +0100, Chris Wilson
wrote:
> On Sat, 09 Jul 2011 14:06:23 -0700, Keith Packard wrote:
> > On Sat, 09 Jul 2011 21:50:26 +0100, Chris Wilson
> > wrote:
> > Sure, it's permitted, so ideally we'd detect this abuse and fall back to
> > the slow path, but we need a cheap
On Sat, 09 Jul 2011 14:06:23 -0700, Keith Packard wrote:
> On Sat, 09 Jul 2011 21:50:26 +0100, Chris Wilson
> wrote:
> Sure, it's permitted, so ideally we'd detect this abuse and fall back to
> the slow path, but we need a cheap check which takes the slow path,
> perhaps pessimistically.
If we
On Sat, 09 Jul 2011 21:50:26 +0100, Chris Wilson
wrote:
>
> I think would do, find_vma() is not necessary cheap though, and there are a
> couple of optimisations that we haven't done for pwrite/pread yet to speed
> up the transition to the slow path.
Yeah, find_vma is a rb tree walk over the wh
On Sat, 09 Jul 2011 13:24:02 -0700, Keith Packard wrote:
> On Sat, 9 Jul 2011 09:38:51 +0100, Chris Wilson
> wrote:
>
> > + /* We have to disable faulting here in case the user address
> > +* is really a GTT mapping and so we can not enter
> > +* i915_gem_faul
On Sat, 09 Jul 2011 13:21:48 -0700, Keith Packard wrote:
> On Sat, 9 Jul 2011 09:38:50 +0100, Chris Wilson
> wrote:
>
> > +static int prefault_writeable(unsigned long uaddr, unsigned long len)
>
> > +static int prefault_readable(unsigned long uaddr, unsigned long len)
>
> These seems like a
On Sat, 9 Jul 2011 09:38:51 +0100, Chris Wilson
wrote:
> + /* We have to disable faulting here in case the user address
> + * is really a GTT mapping and so we can not enter
> + * i915_gem_fault() whilst already holding struct_mutex.
> + */
I
On Sat, 9 Jul 2011 09:38:50 +0100, Chris Wilson
wrote:
> +static int prefault_writeable(unsigned long uaddr, unsigned long len)
> +static int prefault_readable(unsigned long uaddr, unsigned long len)
These seems like a functions which belongs alongside (or in place of) the
existing fault_in_p
On Sat, 09 Jul 2011 07:41:57 -0700, Eric Anholt wrote:
> On Sat, 9 Jul 2011 09:38:51 +0100, Chris Wilson
> wrote:
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
>
> > - vaddr = kmap_atomic(page, KM_USER0);
> > + vaddr = kmap_atomic(page)
On Sat, 9 Jul 2011 09:38:51 +0100, Chris Wilson
wrote:
> These paths hold onto the struct mutex whilst accessing pages. In
> order, to prevent a recursive dead-lock should we fault-in a GTT mapped
> page we need to return -EFAULT and fallback to the slow path.
>
> Lockdep has complained before
On Sat, 9 Jul 2011 13:19:57 +0200 (CEST), "Nicolas Kalkhof"
wrote:
> Hi Chris,
>
> Applications:
> Oxygen XML Editor 12.2 using latest jdk 1.6.0 (get the trial here:
> http://www.oxygenxml.com/)
> Squirrel SQL Editor 3.2.1 (get it here: http://squirrel-sql.sourceforge.net/)
> Desktop: XFCE 4.8
Which application, which desktop? And can it be captured in a screenshot?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,it seems that the xf86-video-intel driver has problems refreshing window content with several java applications like squirrel sql or the oxygen xml editor when SNA is enabled. The window content sometimes does not refresh while scrolling - especially when inline-tooltips are opened. Is this a kn
On Sat, 09 Jul 2011 12:23:02 +0200, Paul Menzel
wrote:
> Am Samstag, den 09.07.2011, 09:25 +0100 schrieb Chris Wilson:
>
> Whoever pushes this, please correct
>
> s/Seperate/Separate/
>
> in the commit summary.
Yes, I forgot to fix the typo again.
>
> > In order to correctly account for res
Am Samstag, den 09.07.2011, 09:25 +0100 schrieb Chris Wilson:
Whoever pushes this, please correct
s/Seperate/Separate/
in the commit summary.
> In order to correctly account for reserving space in the GTT and fences
> for a batch buffer, we need to independently track whether the fence is
> pin
These paths hold onto the struct mutex whilst accessing pages. In
order, to prevent a recursive dead-lock should we fault-in a GTT mapped
page we need to return -EFAULT and fallback to the slow path.
Lockdep has complained before about the potential dead-lock, but rvis is
the first application fou
When using a GTT mapping as a source or destination for the pwrite or
pread command respectively, unless the PTEs for the GTT vma had been
prepopulated then get_user_pages() would fail with EFAULT. Usually, we
only write small amounts of data with pwrite that happened to be
conveniently prefaulted
Align unfenced buffers on older hardware to the power-of-two object size.
The docs suggest that it should be possible to align only to a power-of-two
tile height, but using the already computed fence size is easier and
always correct. We also have to make sure that we unbind misaligned buffers
upon
In order to correctly account for reserving space in the GTT and fences
for a batch buffer, we need to independently track whether the fence is
pinned due to a fenced GPU access in the batch from from whether the
buffer is pinned in the aperture. Currently we count the fenced as
pinned if the buffe
19 matches
Mail list logo
