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
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
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
On Thu, 22 Apr 2010 22:38:41 +0100, Owain G. Ainsworth
zer...@googlemail.com 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
On Thu, 22 Apr 2010 22:38:42 +0100, Owain G. Ainsworth
zer...@googlemail.com 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
This avoids stalling on the gpu. With the preparation from the
previous patch, this is really just a small change.
Thanks to Owain Ainsworth zer...@googlemail.com 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