I'm trying to formalize the process for merging code into the drm/i915
driver. Here's a first draft, please send along your comments.
-keith
Right now, I'm merging patches destined for the 3.0 release
in a kernel.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
(yes
On Sat, 04 Jun 2011 19:31:27 +0100, Chris Wilson
wrote:
> Yes, we can't apply the EDEADLK patch until we fix the accounting.
Ok, I'll rearrange drm-intel-next then so that the EDEADLK patch occurs
after this fix.
> Speedups on q35 (or equally because I finally noticed the regression of):
> mi
... and bump version to 2.6.
Signed-off-by: Chad Versace
---
configure.ac |2 +-
dri2proto.txt |6 +-
dri2tokens.h |1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 297be0e..d671f5a 100644
--- a/configure.ac
+++ b/configure.a
Before this commit, if a client were to request a stencil or hiz buffer, then
I830DRI2CreateBuffer() allocated and returned an X-tiled buffer by
accident. (DRI2BufferStencil and DRI2BufferHiz were unintentionally caught
by the default case of a switch statement.)
Now, I830DRI2CreateBuffer() correc
These patches belong to my effort to enable hiz and separate stencil for IVB.
Patch 1 belongs to dri2proto.
Patch 2 belongs to xf86-video-intel.
There is a related patch series on the mesa-dev list that uses this
functionality. See the thread with subject:
i965: Implement hiz and separate st
On Sat, 04 Jun 2011 10:38:07 -0700, Keith Packard wrote:
> On Sat, 4 Jun 2011 09:55:43 +0100, Chris Wilson
> wrote:
> I'm afraid you've completely lost me here. Can you provide a small
> example (libdrm?) program which exhibits the failure so I can follow
> what the problem is?
See intel-gpu-t
On Sat, 04 Jun 2011 10:38:07 -0700, Keith Packard wrote:
> On Sat, 4 Jun 2011 09:55:43 +0100, Chris Wilson
> wrote:
> I'm afraid you've completely lost me here. Can you provide a small
> example (libdrm?) program which exhibits the failure so I can follow
> what the problem is?
The outline of
On Sat, 4 Jun 2011 09:55:43 +0100, Chris Wilson
wrote:
> In order to correctly account for reserving space in the GTT and fences
> for a batch buffer, we need to independently track whether the fence is
> pinned due to a fenced GPU access in the batch from from whether the
> buffer is pinned in
Hi,
Could anyone pay attention to
https://bugs.freedesktop.org/show_bug.cgi?id=37686 and help to find correct
persons in Intel to ask about the feature which is ambigously described in
the specs and actually doesn't work?
___
Intel-gfx mailing list
Intel
In order to correctly account for reserving space in the GTT and fences
for a batch buffer, we need to independently track whether the fence is
pinned due to a fenced GPU access in the batch from from whether the
buffer is pinned in the aperture. Currently we count the fenced as
pinned if the buffe
10 matches
Mail list logo
