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>
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>
The single-threaded code used the pre-computed width/height and only
required the origin from the bounds. However, the threads need to
allocate memory for themselves based on the computed bounds, and so it
helps if those bounds are then correct (rather than only the top-left
being in local space with the bottom-right in global coordinates).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the kernel replies that a bo is still busy, stage its retirement
through the flushing list to be certain that we never stall on a
subsequent write.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Currently if the dst is wholly contained within the CPU, then we try to
continue to operate on the GPU. However, if we have FORCE_GPU set, it
means that one of the sources for the operation resides on the GPU, and
that would require a readback in order to perform the operation on the
CPU. Hence, if we try to use a CPU bo and fail, convert back to using
the GPU bo if forced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we encounter a delayed flip with a different back buffer than the
current, simply update the info rather than bug out.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As scanouts are uncached, they need to be treated carefully and
decontaminated before being placed in the general cache. So double check
that no bo in those caches are still marked as a scanout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having relaxed the earlier assertion because the kernel is wrong, we can
now retire for READ-READ optimisations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
All the callers have explicitly changed the domain upon the bo before
calling kgem_bo_retire(), so we still get the occasional sporadic
failure as kgem_busy() reports true. Kill the assertion for now.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to submit a batchbuffer, the driver is broken and likely to
continue to fail to render. Give up, and fallback to swrast so that the
session remains usable.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59771
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we are trying to find the best coverage, then by definition if the
drawable is an exact match for one CRTC, we can stop looking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the GPU bo is currently mapped to the Pixmap, we need to be sure to
invalidate that mapping if we swap the GPU bo (for SwapBuffers). If we
forget, we leave a dangling pointer to chase.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60042
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Modify the presumption that if we are using a core operation on a shadow
pixmap, then we are likely to continue migrating that pixmap back and
forth.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we need to synchronize that bo before the next reply, we need to keep
track of it whenever it is active on the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When completing a batch mid-operation, we need to wait upon the other
threads to complete their writes so that memory is coherent before
submitting the work to the GPU. This was achieved by forcing the finish,
but all that from that is the wait, which makes the handling of threads
much explicit and removes the unnecessary vbo refresh.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson
Paul Menzel
Damien Lespiau