Re: [Intel-gfx] Increased latency from removal of GEM_THROTTLE in 2D driver

2010-11-07 Thread Eric Anholt
On Sat, 06 Nov 2010 01:44:59 +, Peter Clifton wrote: > I've been playing with my app again, and whilst it seems a tiny bit > faster in benchmarks, since the 2D driver change: > > commit 8ff37667bf864b771d16a58fc5041cb48408b6a8 > Author: Eric Anholt > Date: Tue Nov 2 10:36:03 2010 -0700 >

[Intel-gfx] Video acceleration for GM45

2010-11-07 Thread Blitzmerker
Hi, I'd like to know if future driver releases will support HD video acceleration for the GM45 chipset. mfg Blitzmerker ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

2010-11-07 Thread Chris Wilson
Oh my, this turns out to be quite hacky indeed... if (i915_trace_on_load) { const struct ftrace_event_call enable_list[] = { #define EVENT(name) event_call_##name &EVENT(i915_reg), NULL, }, *call = enable_list; do { if ((*call

Re: [Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

2010-11-07 Thread Liu Aleaxander
On Sun, Nov 7, 2010 at 11:33 PM, Chris Wilson wrote: > > The hacky approach is a module parameter (i915.trace_load=1) that we parse > in i915_init() and enable the trace points manually. I remember this being > possible, once upon a time... Yes, I will check if it is possible tomorrow(night here).

Re: [Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

2010-11-07 Thread Chris Wilson
On Sun, 7 Nov 2010 23:04:40 +0800, Liu Aleaxander wrote: > But back to that issue again, how can we get the data of register > read/write at the KMS phase. i195:* trace event does exist only when > i915 module is loaded. Meanwhile, the KMS phase is passed by when you > are trying to enable i915_re

Re: [Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

2010-11-07 Thread Liu Aleaxander
On Sun, Nov 7, 2010 at 10:23 PM, Chris Wilson wrote: > On Sun, 7 Nov 2010 22:08:00 +0800, Liu Aleaxander > wrote: >> I wrote a new patch(no post-processing yet). >> Chris, is this what you want? > > Yes, that looks good. Thanks:) >The compiler should be able to do its job and reduce > that code

Re: [Intel-gfx] [PATCH] intel: initialize bufmgr.bo_mrb_exec unconditionally

2010-11-07 Thread Chris Wilson
On Sun, 07 Nov 2010 15:54:32 +0100, Albert Damen wrote: > Attached patch against libdrm solves the problem for me. It seems safe > to me to set bo_mrb_exec unconditionally as drm_intel_gem_bo_mrb_exec2 > will still check if BSD and BLT rings can be used. I had it my head that we used bo_mrb_exec

[Intel-gfx] [PATCH] intel: initialize bufmgr.bo_mrb_exec unconditionally

2010-11-07 Thread Albert Damen
After upgrading xf86-video-intel to git master X didn't work anymore (black screen, only mouse cursor visible and moving). Xorg.0.log shows many errors: (EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: No such device. This seems to be caused by co

Re: [Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

2010-11-07 Thread Chris Wilson
On Sun, 7 Nov 2010 22:08:00 +0800, Liu Aleaxander wrote: > I wrote a new patch(no post-processing yet). > Chris, is this what you want? Yes, that looks good. The compiler should be able to do its job and reduce that code nicely. I think you want, in addition, a pair of I915_READ_NOTRACE and I915

Re: [Intel-gfx] [PATCH] drm/i915: Add aub debug support for kernel

2010-11-07 Thread Liu Aleaxander
On 11/6/10, Chris Wilson wrote: > > Right. If we want to ask the user to gather some debug info, it > essentially has to be from within X and be as simple as run > 'intel-gpu-trace myapp'. Using ftrace is the simplest way to achieve > that. Having to rmmod i915.ko rules out mmiotrace as a viable c

Re: [Intel-gfx] [bisected] commit 176f28eb breaks my Sandybridge

2010-11-07 Thread Chris Wilson
On Sun, 7 Nov 2010 21:09:16 +0800, Zhenyu Wang wrote: > On 2010.11.04 16:52:51 -0700, Carl Worth wrote: > > > Having the error there was to make sure people noticed and I > > > could find out just how many SNB revisions failed. I presume you have a > > > rev 8? > > > > Yes, rev 8 here. > > > >

Re: [Intel-gfx] [bisected] commit 176f28eb breaks my Sandybridge

2010-11-07 Thread Zhenyu Wang
On 2010.11.04 16:52:51 -0700, Carl Worth wrote: > > Having the error there was to make sure people noticed and I > > could find out just how many SNB revisions failed. I presume you have a > > rev 8? > > Yes, rev 8 here. > FYI, rev 9 desktop sandybridge doesn't show this issue so far. It just re

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Apply display workaround required according to the B-Spec.

2010-11-07 Thread Chris Wilson
On Sat, 6 Nov 2010 14:53:33 -0700, Eric Anholt wrote: > Not known to fix any current bugs. If the specs warn us that dragons lie beneath, we should respect them. Both applied to -fixes and cc'ed stable. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre __

Re: [Intel-gfx] [PATCH 15/15] drm/i915: no more agp for gem

2010-11-07 Thread Chris Wilson
On Sun, 7 Nov 2010 11:20:26 +0100, Daniel Vetter wrote: > Wrt future plans: My idea behind separating the dmar mapping and the gtt > pte writing was to be able to keep around the dmar mapping even when the > bo is not bound to the gtt. Together with a phys_memory domain to avoid > cflush on rebind

Re: [Intel-gfx] [PATCH] intel: Fix emit_linear_blit to use DWORD aligned width blits

2010-11-07 Thread Chris Wilson
On Sat, 06 Nov 2010 10:04:31 +, Peter Clifton wrote: > Fixes corruption with glBufferSubData on my machine, > > Can someone review and push? Oddly, the pitch for BLT is in bytes and it should be sufficient to be a multiple of element-size. Or two element-size depending on circumstances. Ju

Re: [Intel-gfx] [PATCH 15/15] drm/i915: no more agp for gem

2010-11-07 Thread Daniel Vetter
On Sat, Nov 06, 2010 at 10:20:07PM +, Chris Wilson wrote: > Woohoo, we kill agp_memory. I'm in favour! > > Do we need to keep the sg_table around, or can we just temporary allocate > it? I've strolled around in the pci_map implementation and it looks like we need to hand in the same sg_table