On Mon, Nov 14, 2011 at 08:16:35 +0100, tino.keitel+x...@tikei.de wrote:
> On Sun, Nov 13, 2011 at 11:27:29 +, Chris Wilson wrote:
> > This is the second release candidate in preparation for the upcoming
> > 2.17.0 release. We will appreciate any feedback we can get from
>
> Hi,
>
> this does
On Mon, 14 Nov 2011 13:01:36 +0800, "Zhigang Gong"
wrote:
>
>
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Friday, November 11, 2011 9:13 PM
> > To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> > Subject: RE: [Intel-gfx] [PATCH 2/3] glamor
At Sat, 12 Nov 2011 10:27:26 +0800,
Wu Fengguang wrote:
>
> (snip)
> > > > > > And I'm not sure whether HDMI audio is played
> > > > > > while DPMS is off. I haven't tested it.
> > > > >
> > > > > It will go silence on DPMS. I noticed this while doing long term HDMI
> > > > > audio playback test
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, November 14, 2011 5:07 PM
> To: Zhigang Gong; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
>
> On Mon, 14 Nov 2011 13:01:36 +0800, "Zhigang Gong"
>
Added two new flags UXA_USE_GLAMOR and UXA_USE_GLAMOR_ONLY.
When UXA_USE_GLAMOR or UXA_USE_GLAMOR_ONLY is set, then it
will use GLAMOR to perform rendering operations by default.
If GLAMOR failed to accelerate the operation and UXA_USE_GLAMOR
is set, it then continue to the normal UXA code path to
As uxa_driver may be released before the last call to freeScreen
and destroy the last pixmap, we have to introduce a new flag in
intel structure to indicate whether we are using GLAMOR. This
intel->uxa_flag is a clone of intel->uxa_driver->flags element.
Signed-off-by: Zhigang Gong
---
src/intel
According to Chris's comments, this commit try to
elminate #ifdef from the body of the code if possible.
We check the flags to determine whether enable GLAMOR
at runtime, rather than check the MACRO during the compile
time.
Signed-off-by: Zhigang Gong
---
src/intel_driver.c | 12 ++--
As we removed those #ifdef from the body of the code, some
functions are referenced even we haven't defined the GLAMOR
though those functions are never be called at run time. We
still need to inclue those prototypes or make a fake function
to silcent the compilation warnings.
Signed-off-by: Zhigan
On Mon, Nov 14, 2011 at 05:45:12PM +0800, Takashi Iwai wrote:
> At Sat, 12 Nov 2011 10:27:26 +0800,
> Wu Fengguang wrote:
> >
> > (snip)
> > > > > > > And I'm not sure whether HDMI audio is played
> > > > > > > while DPMS is off. I haven't tested it.
> > > > > >
> > > > > > It will go silence on
On Mon, 14 Nov 2011 20:09:03 +0800, Zhigang Gong
wrote:
> According to Chris's comments, this commit try to
> elminate #ifdef from the body of the code if possible.
> We check the flags to determine whether enable GLAMOR
> at runtime, rather than check the MACRO during the compile
> time.
I was
On Fri, 11 Nov 2011 21:18:31 +0100, Daniel Vetter wrote:
> On Fri, Nov 11, 2011 at 20:58, Eric Anholt wrote:
> > Oh, yeah, swap. Good point, sounds like a plan. If you manage to get
> > reliable swapping of tiled data on 945g, I'll owe you all the beers.
>
> If you mean i945G as in desktop var
To save power when the sprite is full screen, we can disable the primary
plane on the same pipe. Track the sprite status and enable/disable the
primary opportunistically.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|3 ++
drivers/gpu/drm/i915/intel_sprite.c | 67 +++
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
sprite support functions.
v2: use drm specific fourcc header and defines
v3: address Daniel's comments:
- don't take struct mutex around register acces
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/g
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/g
To save power when the sprite is full screen, we can disable the primary
plane on the same pipe. Track the sprite status and enable/disable the
primary opportunistically.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|3 ++
drivers/gpu/drm/i915/intel_sprite.c | 67 +++
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
sprite support functions.
v2: use drm specific fourcc header and defines
v3: address Daniel's comments:
- don't take struct mutex around register acces
Semaphores seem to fix most of the hangs on SNB and IVB, and do not cause
any known regressions as of now.
Let's re-enable them by default to provide a wider testing and coverage.
Acked-by: Keith Packard
CC: Jesse Barnes
CC: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=
Most of the rc6-related hangs and major issues were addressed for the past
months.
Let's re-enable it by default to provide a more wider testing, and catch
the remaining problems.
According to tests, enablement of rc6 results in up to +50% improvements
in power usage and battery life, so it certa
On Mon, 14 Nov 2011 18:39:15 -0200
Eugeni Dodonov wrote:
> Most of the rc6-related hangs and major issues were addressed for the past
> months.
>
> Let's re-enable it by default to provide a more wider testing, and catch
> the remaining problems.
>
> According to tests, enablement of rc6 result
On Mon, 14 Nov 2011 18:39:14 -0200
Eugeni Dodonov wrote:
> Semaphores seem to fix most of the hangs on SNB and IVB, and do not cause
> any known regressions as of now.
>
> Let's re-enable them by default to provide a wider testing and coverage.
>
> Acked-by: Keith Packard
> CC: Jesse Barnes
>
Hi,
On Mon, Nov 14, 2011 at 06:39:15PM -0200, Eugeni Dodonov wrote:
> Most of the rc6-related hangs and major issues were addressed for the past
> months.
which commits should I try to check whether rc6 issue is gone? As of 3.1
kernel, I'm still getting huge screen corruption.
--
Lukáš Hejtmáne
2011/11/14 Lukas Hejtmanek
> Hi,
>
> On Mon, Nov 14, 2011 at 06:39:15PM -0200, Eugeni Dodonov wrote:
> > Most of the rc6-related hangs and major issues were addressed for the
> past
> > months.
>
> which commits should I try to check whether rc6 issue is gone? As of 3.1
> kernel, I'm still gettin
2011/11/14 Lukas Hejtmanek
> > I am unable to reproduce any rc6-related corruptions on my machine(s)
> > though. So it looks like this is yet another case in which we'll need to
> > use Sherlock Holmes methods to get to them...
>
> are you using SNA? I do on my SNB system.
>
Are the issues SNA-s
On Mon, Nov 14, 2011 at 09:04:37PM -0200, Eugeni Dodonov wrote:
> The rc6 issue which are gone are the ones which was causing hard system
> hangs and gpu hangs.
>
> Corruptions are still out there, if they don't go away when using
> intel_iommu=off then we'll have to investigate them more in-depth
On Mon, Nov 14, 2011 at 09:17:39PM -0200, Eugeni Dodonov wrote:
> Are the issues SNA-specific, or they happen with UXA as well?
>
> I do use both SNA and UXA actually (thanks to
> http://cgit.freedesktop.org/~eugeni/xf86-video-intel/ :)).
I believe they happen with both but with SNA I got regular
26 matches
Mail list logo
