On Tue, Jun 8, 2010 at 6:55 AM, Eric Anholt wrote:
> For whatever libdrm knock-it-off-with-the-overallocation patch we settle
> on, it's going to trigger the bug with the 2D driver underallocating
> framebuffer memory on my 1440x900 laptop. I've pushed tested patches to
> both branches, and my pl
For whatever libdrm knock-it-off-with-the-overallocation patch we settle
on, it's going to trigger the bug with the 2D driver underallocating
framebuffer memory on my 1440x900 laptop. I've pushed tested patches to
both branches, and my plan is to roll point releases of those, and
mention in the li
On Mon, Jun 7, 2010 at 12:29 PM, Xavier de Almeida
wrote:
> Here is the right link:
> https://bugs.freedesktop.org/show_bug.cgi?id=11220
> id 11220
>
> I found in the motherboard documentation that 5.1 is not supported over HDMI
> (you can still have DTS-HD/True-HD on 2.0).
> I assume that SPDIF s
On Mon, 7 Jun 2010 13:54:05 +1000 (EST), "Robert Lowery"
wrote:
> > We had two cases recently where the rounding to powers of two hurt
> > badly: 4:2:0 YUV HD video frames would round up from 2.2MB to 4MB,
> > Urban Terror was hitting aperture size limitations. Mipmap trees for
> > power of two
Here is the right link:
https://bugs.freedesktop.org/show_bug.cgi?id=11220
id 11220
I found in the motherboard documentation that 5.1 is not supported over HDMI
(you can still have DTS-HD/True-HD on 2.0).
I assume that SPDIF should allow to have 5.1 True/DTS-HD.
It looks like there is no much in
On Mon, 2010-06-07 at 16:41 +, bob schulman wrote:
> Use of this function seems central for server-space use of DRI (as
> this function sets up the DRIScreenPrivKey for use by dixLookupPrivate
> by way of dixSetPrivate()). Yet this func is only called by
> I810DRIScreenInit() which is only call
Use of this function seems central for server-space use of DRI (as this
function sets up the DRIScreenPrivKey for use by dixLookupPrivate by way of
dixSetPrivate()). Yet this func is only called by I810DRIScreenInit() which is
only called by I810ScreenInit(); and this is only invoked only for va
On Sun, 6 Jun 2010 23:49:09 -0700, Eric Anholt wrote:
> When I made libdrm stop overallocating so much memory for the purpose
> + front_buffer = drm_intel_bo_alloc_tiled(intel->bufmgr, "front buffer",
> + scrn->displayWidth,
> +
On Sun, 6 Jun 2010 23:49:09 -0700, Eric Anholt wrote:
> When I made libdrm stop overallocating so much memory for the purpose
> of bo caching, things started scribbling on the bottom of my
> frontbuffer (and vice versa, leading to GPU hangs). We had the usual
> mistake of size = tiled_pitch * he
On Sun, 6 Jun 2010 23:52:59 -0700, Eric Anholt wrote:
> This is the patch I'm testing on my desktop currently to deal with the
> couple of reports we've had recently of our overallocation for the BO
> cache seriously hurting some interesting workloads (HD video playback
> and UrbanTerror on gen3)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c | 43 -
drivers/gpu/drm/i915/intel_display.c |4 ++-
3 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 35 -
1 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bee7512..9a257c9 100644
--- a/drivers/
Simple fix for error propagation along the old UMS path.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9ded3da..bd859b2 1
On Mon, 2010-06-07 at 10:28 +0800, Xiang, Haihao wrote:
> On Sat, 2010-06-05 at 08:16 +0800, Eric Anholt wrote:
> > We had two cases recently where the rounding to powers of two hurt
> > badly: 4:2:0 YUV HD video frames would round up from 2.2MB to 4MB,
> > Urban Terror was hitting aperture size li
On Sun, 6 Jun 2010 23:52:59 -0700, Eric Anholt wrote:
> Theory being that we don't keep *that* many buffers around, and the
> pain of trying to find the right size in the list is less than the
> pain of using gratuitous amounts of system memory for our BOs.
And, if you sorted the list in size or
15 matches
Mail list logo
