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>
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 use pkg-config to determine whether to use intel-gen4asm, we
should also use it to locate the right version of intel-gen4asm to use.
This allows the user to install the assembler in a non-standard path for
cross-builds and similar.
Reported-by: Josh Tripplet <josh@freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55646
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The make rules to compile shaders with intel-gen4asm referenced the .g4a
source files without using $(srcdir), which broke out-of-tree builds.
Reference .g4a source files via $(srcdir), and add $(srcdir) to m4's
include path, fixing out-of-tree builds.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55645
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Removes 17 instances of:
warning: comparison of unsigned expression >= 0 is always true
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since, with GPU-on-package, it's hard to talk about a model number for
a specific chipset like 855GM, just use the platform names.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The actual code was removed in 5f64122551, where the get_surface_status
driver callback was dropped. Just return Success if there were no issues
with the parameter.
Get rid of the following with CFLAGS="-Wall -Werror":
| CC intel_xvmc.lo
| cc1: warnings being treated as errors
| intel_xvmc.c: In function ‘XvMCSyncSurface’:
| intel_xvmc.c:677: error: ‘ret’ may be used uninitialized in this function
| intel_xvmc.c:672: note: ‘ret’ was declared here
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both exported XvMCPutSlice/XvMCPutSlice2 functions have a prototype with a
parameter whose signedness differs from the one in the put_slice/put_slice2
functions they call. Make it unsigned through a cast.
Get rid of this accordingly with CFLAGS="-Wall -Werror":
| CC intel_xvmc.lo
| cc1: warnings being treated as errors
| intel_xvmc.c: In function ‘XvMCSyncSurface’:
| intel_xvmc.c:677: error: ‘ret’ may be used uninitialized in this function
| intel_xvmc.c:672: note: ‘ret’ was declared here
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Get rid of those accordingly with CFLAGS="-Wall -Werror":
| CC i915_xvmc.lo
| cc1: warnings being treated as errors
| i915_xvmc.c: In function ‘i915_mc_one_time_state_emit’:
| i915_xvmc.c:369: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c:374: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c:379: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c: In function ‘i915_mc_load_indirect_render_emit’:
| i915_xvmc.c:708: error: suggest parentheses around arithmetic in operand of ‘|’
| i915_xvmc.c:713: error: suggest parentheses around arithmetic in operand of ‘|’
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Get rid of the following with CFLAGS="-Wall -Werror":
| CC intel_xvmc_dump.lo
| cc1: warnings being treated as errors
| intel_xvmc_dump.c: In function ‘intel_xvmc_dump_open’:
| intel_xvmc_dump.c:41: error: suggest parentheses around assignment used as truth value
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Per-target compilation flags (libIntelXvMC_la_CFLAGS) are required
when multiple targets which require different compiler flags,
are build in the same makefile.
Automake issues a command with -c and -o flags which not all compilers
support. The object fles are prefixed with libIntelXvMC_la.
The macro AM_PROG_CC_C_O must then be used to provide this feature
on compilers that do not have it. If not, a warning is issued at make time.
This macros checks for compiler support and if missing, uses a "compile"
script it generates in the package root directory.
Currently the driver uses per-target flags but the macro is missing.
Rather than adding the macro, this patch stops using per-target flags
by using the AM_CFLAGS variable for all targets in the makefile, as
there is only one.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
After splitting out the i810 driver into its own legacy directory, we
can identify the common routines not as i830 but as intel. This
clarifies the code which *is* i830 specific.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The driver is still built but is no longer under active development so
move it and supporting files to a new directory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is some fallout from my xvmc cleanup.
Original-Patch-by: Rico Tzschichholz <ricotz@t-online.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simply store the desired bo size in intel_xvmc_context and initialize
it in the driver's create_context function.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... by putting struct intel_xvmc_surface at the beginning. Also kill
the common context handling code and simply keep a pointer in the
surface private to the context.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's unused. Also drop all related generic code that tries to do
clever stuff with this callback. These are all remnants from a
pre-gem world.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All of these are also stored in the context. Also kill the context
reference counting. Doesn't serve a purpose besides occupying a
pointer to the context in the private surface struct.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... by putting struct intel_xvmc_surface at the beginning. This
will allow to consolidate surface and bo handling.
Also kill some now dead code used to handle the common surface
structure.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only passed around and actually used the gem handle. Don't
need a struct for one field alone ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And kill all the static structures. This way it's clearer what's
common and what's specific. And the code is shorter too.
Also clean up src/i830_hwmc.c - kill the nonstandard surface types
for i915 and the associated code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doing the same with the i965 code will allow us to share the
create_context function.
src/i915_hwmc.h is now almost empty. Move the last #defines to
src/xvmv/i915_xvmc.c where they are actually used and delete the
file.
Also rename the ddx context struct to something sane.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like for i915. Also drop that now totally superflous limit on the
available surfaces.
Move the surface struct into the userspace library header now that
the ddx doesn't use it anymore.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My cleanup accidently created a inconsistency in the YUV plane ordering.
I think we can safely assume that I'm colorblind ;)
As Carl Worth rightly pointed out, this change deserves a more elaborate
explanation:
For Xv planar formats, the three planes are stored consecutively in
memory, ordered Y U V. Now for some totally odd reason (= none at all),
i915 xvmc stored it in Y V U order. Right after the release of 2.10, with
commit "Xv: consolidate xmvc passthrough handling" I've inadvertently
broken xvmc support (which started this whole odyssey into xvmc). When
fixing stuff up, I neglected this special plane ordering and simply
assumed it to be the same as Xv and dropped that special case for i915 in
src/i830_video.c. This patch completes the change to standard YUV plane
ordering by making the corresponding change in src/xvmc/i915_xvmc.c.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Like with the per context stuff, also drop the now artificial limit
on surfaces. Again, with that gone, a lot of code can be deleted.
Reviewed-by: Carl Worth <cworth@cworth.org>
There's now not a reason anymore to limit the number of active contexts.
So kill this accounting, too.
With that all gone, per-context state in the ddx is nil, so rip out
all associated code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Proper bo management ensures that the cpu doesn't step on buffers
used by the gpu. Drop the now unnecessary synchronization.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Cache coherency is now fully under the control of gem.
For lack of hw documentation, I had to find out the correct cache
placements by trial and error:
Backward and forward surfaces: I915_GEM_DOMAIN_RENDER
Correlation data: I915_GEM_DOMAIN_SAMPLER
Changing any of them leads to visual corruptions, so I think these
are the correct ones.
Reviewed-by: Carl Worth <cworth@cworth.org>
Now the last user of the fixed buffers provided by the ddx is gone!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
It works!
v2: Correlation data needs to be in the render cache!
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
I've decided to allocate a new buffer for every render command, to
prevent stalling for the gpu. libdrm bo reuse should take care of
not wasting memory in case the buffer is not busy.
Also always emit the full state, it's not worth it to complicate
the code over a few stores to wc memory.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Like with one_time_state_emit, this preps for relocatable bo's.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
This also starts to kill the last remnants of the support for
physical addresses for the indirect state buffers. With gem this
would need kernel support (in the form of a new reloc type in
execbuf2).
This does not change the ABI between ddx and client libIntelXvMC.
I've decided to do this in one swoop when all the buffer rework is
done.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
Chris Wilson
Paul Menzel
Damien Lespiau
Josh Triplett
Jeremy Huddleston
Paulo Zanoni
Adam Jackson
Cyril Brulebois
Matt Turner
Gaetan Nadon
Daniel Vetter