Hi Linus,
Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next
This branch has a merge in it, due to conflicts with the Intel drm tree
you already pulled. I've asked Eric to not send you direct pulls, he
mentioned you said he
On Sun, 29 Mar 2009, Dave Airlie wrote:
This branch has a merge in it, due to conflicts with the Intel drm tree
you already pulled. I've asked Eric to not send you direct pulls, he
mentioned you said he should, but it really screws over my tree. I don't
mind direct pulls outside the
This branch has a merge in it, due to conflicts with the Intel drm tree
you already pulled. I've asked Eric to not send you direct pulls, he
mentioned you said he should, but it really screws over my tree. I don't
mind direct pulls outside the merge window as it usually smaller bug
On Sun, 29 Mar 2009, Dave Airlie wrote:
My plans from now on are just to send you non-linear trees, whenever I
merge a patch into my next tree thats when it stays in there, I'll pull
Eric's tree directly into my tree and then I'll send the results, I
thought we cared about a clean merge
http://bugs.freedesktop.org/show_bug.cgi?id=20935
Summary: Perfomance regresion in r300_dri version 7.3 (7.2 is
twice faster)
Product: Mesa
Version: unspecified
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
I want clean history, but that really means (a) clean and (b) history.
People can (and probably should) rebase their _private_ trees (their own
work). That's a _cleanup_. But never other peoples code. That's a destroy
history
So the history part is fairly easy. There's only one major
On Mon, 30 Mar 2009, Dave Airlie wrote:
- Don't merge upstream code at random points.
You should _never_ pull my tree at random points (this was my biggest
issue with early git users - many developers would just pull my current
random tree-of-the-day into their
http://www.botchco.com/alex/xorg/r6xx_drm/0001-RS780-load-the-right-microcode.patch
From 4299cc7ee205006851a7a791602efa8512613f16 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Sun, 29 Mar 2009 20:40:34 -0400
Subject: [PATCH] RS780: load the right microcode
Copy/paste
Does anyone remember why we've only done macro tiling on the radeon
for the color buffer so far?
I've been playing with tiling under KMS and I've added back macro
tiling for the front/back buffers and it seems to run fine, however
micro tiling the front buffer gives me corrupt pixmaps from X on
On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie airl...@gmail.com wrote:
Does anyone remember why we've only done macro tiling on the radeon
for the color buffer so far?
/me discovers the reason ouch.
So the 2D engine can't deal with a microtiled surface as a source,
so short of using the 3D
On Sun, 2009-03-29 at 14:07 +0100, Sitsofe Wheeler wrote:
(CC'ing dri-devel, Eric Anholt and Jesse Barnes)
On Sun, Mar 29, 2009 at 12:34:01PM +0200, Soeren Sonnenburg wrote:
Dear all,
I am not sure if this is just a user error/ too old userspace problem,
[User stated that 2.6.3 intel
(CC'ing dri-devel, Eric Anholt and Jesse Barnes)
On Sun, Mar 29, 2009 at 12:34:01PM +0200, Soeren Sonnenburg wrote:
Dear all,
I am not sure if this is just a user error/ too old userspace problem,
[User stated that 2.6.3 intel driver is being used in another email]
but I recognized that
12 matches
Mail list logo
