| Age | Commit message (Collapse) | Author |
|---|
|
Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.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>
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
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>
|
|
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
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>
|
|
Fixes:
Bug 27352 - RPMLINT error causes build breakage
https://bugs.freedesktop.org/show_bug.cgi?id=27352
Reported-by: Johannes Obermayr <johannesobermayr@gmx.de>
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>
|
|
Almost totatlly unused, but surely totally useless.
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>
|
|
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>
|
|
Surface bo's can be freed by the common code, then there's nothing
driver specific left.
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>
|
|
The private surface struct now adds nothing. Drop it.
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>
|
|
Now that the drm bo is in the common structure, do the PutImage
handling in common code, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
i965 lost the last field in it's private surface struct. Kill it
and any associated headers.
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>
|
|
Like for the i915. With this create_context is now also shared.
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>
|
|
Like for the static indirect state buffer.
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>
|
|
Like with the sampler state buffer.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
|
|
Like with the sampler state buffer.
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>
|
|
Seems to be a remnant from i810 XvMC support. last_flip is always 0,
so serves no real purpose anymore. Kill it and the associated code.
With last_flip gone, last_render also lost its purpose. Kill it, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
|
|
This is in preparation for real relocatable drm_bo's instead
of memory at a fixed address. By switching to the batchbuffer
macros (like i965 xvmc) we can use the nice OUT_RELOC macro.
Also align the code more with coding-style elsewhere, i.e. bitops
instead of bitfield structures. The bitfield structures are
quite a mess to work with the batchbuffer macros, so they were
getting in the way, anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
|
|
WIP code that hasn't changed for over two years is unlikely to
suddenly start progressing. Drop it. After all, git can easily
resurect it in cases it's needed.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
|
|
On i965 class hw, kernel_exec_fencing was 1 always, anyway. And on
i945, this patch kills a memory leak (dunno how, but it does).
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
