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 on irc.
v2: Reset obj_priv->fence_invalid in put_fence. No functional
On Thu, 22 Apr 2010 22:38:42 +0100, "Owain G. Ainsworth"
wrote:
> It really won't affect faulting speed at all, and in rare cases may do
> more than we needed in the first place. If we do need to map and we
> aren't bound it will take *just as long* when the mmap happens as it
> would on the ioct
On Thu, 22 Apr 2010 22:38:41 +0100, "Owain G. Ainsworth"
wrote:
> Before, we were waiting until we knew the batch object's gtt offset
> before we checked for validity. However, since this is purely an
> alignment check (it is impossible for the batch object to get to
> execbuffer stage without be
It really won't affect faulting speed at all, and in rare cases may do
more than we needed in the first place. If we do need to map and we
aren't bound it will take *just as long* when the mmap happens as it
would on the ioctl being called.
Discussed with danvet and jbarnes.
Signed-Off-By: Owain
Before, we were waiting until we knew the batch object's gtt offset
before we checked for validity. However, since this is purely an
alignment check (it is impossible for the batch object to get to
execbuffer stage without being pinned and bound) we can check alignment
before we do any other expens
This tells libdrm to not take fence registers into account. Instead
it checks for fence register availability for the current batchbuffer
in the various uxa_prepare_* hooks where it's known how many fences
are needed _exactly_.
Signed-off-by: Daniel Vetter
---
src/i830.h | 13 +
libdrm just doesn't know enough to do this precisely. Therefore allow
this to be disabled and put the burden on the client where enough
information is available.
Signed-off-by: Daniel Vetter
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_gem.c | 25 -
2 files
Hi all,
Currently libdrm pessimistically assumes that every tiled bo needs a fence
on 2nd and 3rd gen hw on _every_ aperture space checks. Especially with
execbuf2 this results in needlessly small batchbuffers.
My libdrm patch solves this problem by adding a function to libdrm to
disable all fenc
Pipelining tiling changes will complicate all places that need
a correct fence register to be set up. So hide this complexity
behind a small helper function.
i915_gem_object_get_fence loses all it's external callers by these
changes, so convert it into a static function
Signed-off-by: Daniel Vett
Reporting objects that are not currently used by the gpu but are
dirty and not yet flushed creates havoc to libdrm's bo reuse:
The usually immediatly following gtt_map afterwards will stall
until the gpu has executed the writeback.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c
Makes no sense and complicates matters for pipelined tiling changes.
So don't allow it and return -EBUSY.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_tiling.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/d
Hi all,
This patch-set prevents stalls due to bo reuse in libdrm. After having
tried to fix the set_tiling stall both in libdrm and the kernel, I think
fixing this in the kernel is the better option: This way gem nicely
abstracts away the execution semantics. The only place where the
asynchronous
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 on irc.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_
Here is a patch for some graphics corruption issues I discovered since
this commit:
commit 1cc2c2c44ac72460cf1c4e6bdc13c612235809c9
Author: Chris Wilson
Date: Wed Apr 14 11:18:25 2010 +0100
i830: Use pixman_blt directly for performing the in-memory copy
In order to avoid an infini
This just splits the device list into two and moves the gtt related stuff
to intel-gtt.c. The two new devices lists also lose the not longer needed
fields. There where only about 5 cases anyway with both a gmch and a
possible agp port, so the duplication of entries is rather small.
v2
Signed-off-
Now that the disentangling is complete, stop including intel-gtt.c
from intel-agp.c.
The linux build system _really_ doesn't allow .c source files with the
same name as the module. It fails with the following message when trying
to build such a bugger:
make[3]: Circular drivers/char/agp/intel-agp
Hi all,
These are the last two patches of my original series. I've re-rechecked,
and contrary to what I've said on irc, the linux build system can't cope
with a module that consists of multiple source files, one of which is named
identical (minus suffix) to the module. I nicely barfs while compili
Hi,
i'm trying the new 2.11 driver in fedora 13 64bit. I have noticed many
dramatic problems:
1) with 3d games (i've tried OpenArena) i have video flickering
with non native resolution. Only if i use 1280x800 i don't have the problem.
2) Very often i have X crashes when i use 3d applicat
18 matches
Mail list logo
