On Mon, 10 May 2010 14:26:52 -0700 Jesse Barnes
wrote:
> Intel Core i3/5 platforms with integrated graphics support both CPU and
> GPU turbo mode. CPU turbo mode is opportunistic: the CPU will use any
> available power to increase core frequencies if thermal headroom is
> available. The GPU si
Hi,
I'm reading the book Beginning OpenGL Programming and running the
examples in GNU/Linux. When I come to lights I find that the Intel hw
has a very poor performance to deal with dynamic lights. I also run
the application in Windows to certify that wasn't a driver problem.
The application that
On Fri, 23 Apr 2010 00:28:29 +0200, Daniel Vetter
wrote:
> This avoids stalling on the gpu. With the preparation from the
> previous patch, this is really just a small change.
>
> Thanks to Owain Ainsworth for coming up
> with the idea for this patch and hashing out the implementation
> with me
Intel Core i3/5 platforms with integrated graphics support both CPU and
GPU turbo mode. CPU turbo mode is opportunistic: the CPU will use any
available power to increase core frequencies if thermal headroom is
available. The GPU side is more manual however; the graphics driver
must monitor GPU po
In some cases (for instance with kernel threads) it may be desireable to
use on-stack deferrable timers to get their power saving benefits. Add
interfaces to support this for the IPS driver.
Signed-off-by: Jesse Barnes
---
include/linux/timer.h | 15 +++
kernel/timer.c|
This patchset adds the core IPS driver to drivers/platform/x86, along
with some helper code in the timer subsystem to allow for deferrable
on-stack timers.
Note that this patchset doesn't include the i915 specific bits for
monitoring power consumption. We're doing final validation on those
now so
Just wondering what was bad about the patch reverted by this commit?
Revert "drm/i915: Configure the TV sense state correctly on GM45 to make TV
detection reliable"
Eric mentioned on irc this patch was bad, so revert it.
This reverts commit fb8b5a39b6310379d7b54c0c7113703a8
On Mon, 10 May 2010 17:59:16 +0100
Simon Farnsworth wrote:
> On Monday 10 May 2010, Simon Farnsworth wrote:
> > On Friday 7 May 2010, Simon Farnsworth wrote:
> > > I've attached my test program (it's based on our C++ OpenGL compositor,
> > > but cut down to just test OpenGL pageflipping) as per
On Mon, May 10, 2010 at 12:59 PM, Simon Farnsworth
wrote:
> On Monday 10 May 2010, Simon Farnsworth wrote:
>> On Friday 7 May 2010, Simon Farnsworth wrote:
>> > I've attached my test program (it's based on our C++ OpenGL compositor,
>> > but cut down to just test OpenGL pageflipping) as performa
On Monday 10 May 2010, Simon Farnsworth wrote:
> On Friday 7 May 2010, Simon Farnsworth wrote:
> > I've attached my test program (it's based on our C++ OpenGL compositor,
> > but cut down to just test OpenGL pageflipping) as performance.c, and my
> > test X stack's Xorg.0.log after one run of "pe
On Fri, 2010-05-07 at 14:41 -0700, Eric Anholt wrote:
> Applied those two.
>
> The fact that we're exposing 2 connectors for this situation is bogus in
> how the KMS architecture is supposed to work, right? I mean, we've got
> 2 "outputs" in this encoder going to one physical connector. The use
On Friday 7 May 2010, Simon Farnsworth wrote:
> I've attached my test program (it's based on our C++ OpenGL compositor, but
> cut down to just test OpenGL pageflipping) as performance.c, and my test X
> stack's Xorg.0.log after one run of "performance -indirect" (which ran for
> 573 frames). I'm u
12 matches
Mail list logo
