The principle change is to switch to the old Privates API and undo the
Region renames.
The downside is that this ignores the critical bugfixes made to the
xserver since xorg-1.6 - but I assume that whoever wants to run the
latest hardware on the old xservers is also backporting those stability
fixes...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The idea is to implement more fine-grained checks as we may want
different heuristics for desktops with GT1s than for mobile GT2s, etc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just a few lines earlier we already have the correct assertion that the
buffer was not in the GPU domain, so had these two been correct, they
would have still been redundant.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We may choose to operate inplace on a buffer last used by the CPU if we
are discarding all the existing damage.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Rather than arbitrarily disable the fallback paths for LLC, allow it to
utilise any available GTT buffers for inplace uploads. The best
explanation so far is that with the streaming is that we are trashing
the LLC. On other machines, the difference is in the noise.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On one particular machine, this operation is behaving as if it is
reading back UC memory during the explicit write-only composite.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having just allocated the handle, we need to free it if we then fail to
allocate memory for the buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The likely cause for a mmap failure is that we hold too many objects
open or have exhausted our address space. In both cases, we need to trim
our caches before continuing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The presumption was that if we had LLC we would have allocated the
buffer by that point - however, it was remotely possible to have fallen
through and so we need to handle those cases.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Not all paths request alloc pages, a few just request sufficient pages
for the original size. So we can only assert that condition is
satisfied.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After splitting the xvmc dependences into xcb and non-xcb, we then also
have to add the xcb CFLAGS to build libIntelXVmc.la
Reported-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libI810XvMC.so.1.0.0` does not need to be linked against
`libX11-xcb.so.1`, `libxcb-dri2.so.0`, `libxcb-util.so.0` or
`libxcb.so.1` [1].
$ debuild -b -us -uc
[…]
make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libX11-xcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libxcb-dri2.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libxcb-util.so.0 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
dpkg-shlibdeps: Warnung: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 sollte nicht gegen libxcb.so.1 gelinkt werden (es verwendet keines der Bibliotheks-Symbole)
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
[…]
Moving `x11-xcb`, `xcb-dri2` and `xcb-aux` from `XVMCLIBS` into `XCB`
and adding `XCB_LIBS` only to the `LIBADD` variables of `libIntelXvMC`
makes the warnings go away and the libraries are still built without any
issues.
make[1]: Entering directory `/src/xserver-xorg-video-intel'
dh_shlibdeps -- --warnings=6
make[1]: Leaving directory `/src/xserver-xorg-video-intel'
dh_installdeb -O--builddirectory=build/
dh_xsf_substvars -O--builddirectory=build/
dh_gencontrol -O--builddirectory=build/
dpkg-gencontrol: Warnung: Feld Depends von Paket xserver-xorg-video-intel-dbg: unbekannte Substitutionsvariable ${shlibs:Depends}
dh_md5sums -O--builddirectory=build/
dh_builddeb -O--builddirectory=build/
dpkg-deb: Paket »xserver-xorg-video-intel« wird in »../xserver-xorg-video-intel_2.19.0-6.1_i386.deb« gebaut.
dpkg-deb: Paket »xserver-xorg-video-intel-dbg« wird in »../xserver-xorg-video-intel-dbg_2.19.0-6.1_i386.deb« gebaut.
dpkg-genchanges -b >../xserver-xorg-video-intel_2.19.0-6.1_i386.changes
dpkg-genchanges: rein binärer Upload - es ist kein Quellcode hinzugefügt
dpkg-source --after-build xserver-xorg-video-intel
dpkg-buildpackage: Binärpaket(e) hochzuladen (keine Quellen enthalten)
Now running lintian...
W: xserver-xorg-video-intel: hardening-no-relro usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions usr/lib/libI810XvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-fortify-functions usr/lib/libIntelXvMC.so.1.0.0
W: xserver-xorg-video-intel: hardening-no-relro usr/lib/xorg/modules/drivers/intel_drv.so
W: xserver-xorg-video-intel: hardening-no-fortify-functions usr/lib/xorg/modules/drivers/intel_drv.so
N: 1 tag overridden (1 warning)
Finished running lintian.
The modules were originally added with the following commit present
since tag 2.10.0.
commit 3e8f2eae3a
Author: Eric Anholt <eric@anholt.net>
Date: Thu Oct 15 13:48:56 2009 -0700
XVMC: Use XCB DRI2 instead of cargo-culting our own copy of Xlib stuff. (v2)
[1] https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intel&arch=i386&ver=2%3A2.19.0-6&stamp=1347825458
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Rather than perilously update a local variable with the allocated size,
just use the size of the bo in the assertion that is large enough to
satisfy the allocation request.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This seems to be the primary victim of the render corruption, so disable
until the root cause is fixed.
References: https://bugs.freedesktop.org/show_bug.cgi?id=55500
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This way, when a new intel-gen4asm is available (because one just hacked
on it and has installed a new version for instance) the shaders will be
recompiled. This helps catching regressions, testing the latest changes
in the assembler haven't broken too many things.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When running autoreconf, it's possible to give flags to the underlying
aclocal by declaring a ACLOCAL_AMFLAGS variable in the top level
Makefile.am.
Putting ${ACLOCAL_FLAGS} there allows the user to set an environment
variable up before running autogen.sh and pull in the right directories
to look for m4 macros, say an up-to-date version of the xorg-util macros.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Building the package under Debian Sid/unstable, `dh_shlibdeps` informs
that `libIntelXvMC.so.1.0.0` does not need to be linked against
`libXext.so.6` or `libXfixes.so.3` [1].
$ debuild -b -us -uc
[…]
make[1]: Entering directory `/build/buildd-xserver-xorg-video-intel_2.19.0-6-i386-9thLfo/xserver-xorg-video-intel-2.19.0'
dh_shlibdeps -- --warnings=6
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 should not be linked against libXext.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 should not be linked against libXfixes.so.3 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be linked against libXext.so.6 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be linked against libXfixes.so.3 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be linked against libX11-xcb.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be linked against libxcb-dri2.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be linked against libxcb-util.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 should not be linked against libxcb.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 were not linked against libXext.so.6 (they use none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/xserver-xorg-video-intel/usr/lib/libIntelXvMC.so.1.0.0 debian/xserver-xorg-video-intel/usr/lib/libI810XvMC.so.1.0.0 were not linked against libXfixes.so.3 (they use none of the library's symbols)
make[1]: Leaving directory `/build/buildd-xserver-xorg-video-intel_2.19.0-6-i386-9thLfo/xserver-xorg-video-intel-2.19.0'
dh_installdeb -a -O--builddirectory=build/
[…]
Not populating `XVMCLIB` with `xext` and `xfixes` makes the warning go
away and the libraries are still built without any issues.
[1] https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-intel&arch=i386&ver=2%3A2.19.0-6&stamp=1347825458
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
As we may call it kgem_bo_sync(), during preparation of the upload
buffer which in turn may operate on an object straight out of the snoop
cache and hence not yet referenced (or in some cases, ever).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the caller is preparing to use the GPU to rendering into the CPU bo,
it will request an ASYNC migration. In those cases, we do not want to
substitute it with an INPLACE operation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to be careful not just when finishing the current vbo to
synchronize with the sharing threads, but also before we emit the batch
state that no other thread will try and do the same.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is essential to handle displays that are too large to be rendered
normally via the 3D pipeline and so that the bounds of the fixup region
are known.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60124
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we transfer a bo to the current batch, then subsequently discard it,
we lose the information about its current active state. Try to recover
this information, by querying the kernel and adding it to the flushing
list if necessary.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Paul Menzel
Damien Lespiau