2011/6/22 Zou, Nanhai :
> map_gtt in current gem is super slow.
> I've tried map_gtt but it seems that the speed is unacceptable.
map_gtt should be pretty fast for large things on the upload side. For
the gpu->cpu download, have you tried pread? btw, the counterpart
(pwrite) also beat
>>-Original Message-
>>From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org
>>[mailto:intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org] On
>>Behalf Of Zou, Nanhai
>>Sent: 2011年6月22日 12:29
>>To: Keith Packard; intel-gfx@lists.freedesktop.org
>>Cc: Anholt, Eric
>>S
>>-Original Message-
>>From: Keith Packard [mailto:kei...@keithp.com]
>>Sent: 2011年6月22日 12:14
>>To: Zou, Nanhai; intel-gfx@lists.freedesktop.org
>>Cc: Anholt, Eric
>>Subject: Re: [Intel-gfx] gem clflush optimization for media encoding
>>
>>On Wed, 22 Jun 2011 11:13:09 +0800, "Zou, Nanhai
On Wed, 22 Jun 2011 11:13:09 +0800, "Zou, Nanhai" wrote:
> If I upload input buffer with movnti or movntdq (bypass cache) +
> sfence(clear write combine buffer) in the end, clflush should
> not be needed.
Alas, neither of these will flush existing cached data, so you must
still
Hi,
I have some questions about clflush usage in gem.
For our encoding driver, each frame's input is raw YUV data, copy from
CPU to GPU surface, output is encoded result, copy from GPU to CPU.
The buffers are huge, for 1080p file, input buffer size could be
1920x1080x1.5
The ring frequency scaling table tells the PCU to treat certain GPU
frequencies as if they were a given CPU frequency for purposes of
scaling the ring frequency. Normally the PCU will scale the ring
frequency based on the CPU P-state, but with the table present, it will
also take the GPU frequency
On Tue, 21 Jun 2011 15:16:27 -0400, Andrew Lutomirski wrote:
> Shouldn't sysrq-v switch even if X isn't cooperating, though?
That's what the theory says. In practice I find I ssh hostname echo >
/proc/sysrq-trigger... ;-)
If the GPU hung and took the machine with it, only the power switch will
r
On Tue, Jun 21, 2011 at 3:11 PM, Chris Wilson wrote:
> On Tue, 21 Jun 2011 20:38:51 +0200 (CEST), "Nicolas Kalkhof"
> wrote:
>> Thanks for bringing that up. Is there a bug report for this issue? I was
>> just about to file a report myself but I don't want to create any duplicates.
>>
>> @Chris:
On Tue, 21 Jun 2011 20:38:51 +0200 (CEST), "Nicolas Kalkhof"
wrote:
> Thanks for bringing that up. Is there a bug report for this issue? I was just
> about to file a report myself but I don't want to create any duplicates.
>
> @Chris: What do you mean with giving X a kick? Neither mouse nor key
Thanks for bringing that up. Is there a bug report for this issue? I was just
about to file a report myself but I don't want to create any duplicates.
@Chris: What do you mean with giving X a kick? Neither mouse nor keyboard are
responding anymore. Killing X from a remote ssh is the only option.
On Tue, Jun 21, 2011 at 2:18 PM, Chris Wilson wrote:
> On Tue, 21 Jun 2011 19:41:52 +0200 (CEST), "Nicolas Kalkhof"
> wrote:
>> However now it seems I'm unable to get my framebuffer console back after I
>> bailed out of X. The screen stays black but my system is still responsive
>> via ssh. Th
On Tue, 21 Jun 2011 19:41:52 +0200 (CEST), "Nicolas Kalkhof"
wrote:
> However now it seems I'm unable to get my framebuffer console back after I
> bailed out of X. The screen stays black but my system is still responsive via
> ssh. This happens without your patch. I'll do some more investigatio
On Sun, 19 Jun 2011 22:49:36 +0100, Chris Wilson
wrote:
> The patch closes a race condition. The essence of your complaint is that
> the kernel is not as fast as we need it to be, and that the initial upload
> to any object is slower than expected. I presume you also have a plan for
> fixing the
Hi Jesse,
I've tried your patch below. It locked up my machine a few seconds after X
startup :(.
I didn't use any boot parameter. I've changed the parameters during runtime by
echoing sysfs.
I've filed a bug under
https://bugs.freedesktop.org/show_bug.cgi?id=38529[../../jump.htm?goto=https%3A%
...we need to apply exactly the same workaround for missing interrupts
from BSD as for the BLT ring, apparently.
See also commit 498e720b96379d8ee9c294950a01534a73defcf3
(drm/i915: Fix gen6 (SNB) missed BLT ring interrupts).
Reported-and-tested-by: nkalk...@web.de
Bugzilla: https://bugs.freedeskt
On Tue, 21 Jun 2011 18:12:56 +0200 (CEST)
"Nicolas Kalkhof" wrote:
> Hi Jesse,
>
> thanks for the infiormation. I've switched rc6 off by
> echo 0 > /sys/module/i915/parameters/i915_enable_rc6
> this should do it, right?
> cat /sys/module/i915/parameters/i915_enable_rc6 yields "0"
>
> Are you re
On Tue, 21 Jun 2011 06:21:11 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
> >
> > I haven't changed the n
The PAT interval tree is only defined for non-RAM ranges, and is both a
shorter list and log-n lookup compared to the linear walk over the
resource ranges looking for "System RAM". In the case of heavy
vm_insert_pfn() users like the gpu drivers, which regularly modify the
contents of the AGP apertu
On a PAT system, inserting a pfn is quite expensive due to the query of
the protections for the page based on its physical location. A large
part of this overhead is due to the linear walk of resource regions and
the strcmp to find "System RAM". By restricting memory to use a global
string for its
Presuming that we lookup the memtype of an address far more often than
we modify the PAT ranges, favour the reader.
Signed-off-by: Chris Wilson
---
arch/x86/mm/pat.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.
Poking around in x86,pat I found one way of avoiding the linear walk for
pat_pagerange_is_ram() which appears to nullify the regression. I would
appreciate confirmation and some review before I go poking dragons.
-Chris
___
Intel-gfx mailing list
Intel-g
On Tue, 21 Jun 2011 10:55:39 +0200
Marcus Lorentzon wrote:
> On 06/20/2011 10:11 PM, Jesse Barnes wrote:
> > This version adds both source and dest rect params to the set_plane
> > ioctl, and makes the source fixed point to support hardware that needs
> > it.
> >
> > I haven't changed the name of
Hi Jesse,
thanks for the infiormation. I've switched rc6 off by
echo 0 > /sys/module/i915/parameters/i915_enable_rc6
this should do it, right?
cat /sys/module/i915/parameters/i915_enable_rc6 yields "0"
Are you referring to this patch? https://lkml.org/lkml/2011/6/17/371
It should be included in k
It's i915.i915_enable_rc6=0 for extra added redundancy. You might also
try Daniel Blueman's IRQ fix.
Jesse
On Tue, 21 Jun 2011 07:57:13 +0200 (CEST)
"Nicolas Kalkhof" wrote:
> Hi Folks, ok, I'll give it a try this evening. Just one more thing: Should I
> pass enable_rc6 as a boot parameter li
Hello!
sorry, setting i915.enable_rc6=0 didn't work for me. I've filed a bug:
https://bugs.freedesktop.org/show_bug.cgi?id=38529
thanks and regards
nico
-Ursprüngliche Nachricht-
Von: "Nicolas Kalkhof"
Gesendet: Jun 21, 2011 7:59:51 AM
An: intel-gfx@lists.freedesktop.org
Betreff: Re: [
On Tue, Jun 21, 2011 at 10:55, Marcus Lorentzon
wrote:
> And should it be possible to only define planes with no crtc framebuffer at
> all? Use case, for example letter boxed video on black background with small
> UI controls/subtitles. In this case it's not power efficient to have a
> fullscreen
26 matches
Mail list logo
