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
>
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
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
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).
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
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
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
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
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
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
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.
> >
>
>
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
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
__
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
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
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
16 matches
Mail list logo
