| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit b611bced15c30f7bcd03106ce90668b684c1ada6)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 68df6b2790891683ee2e58daaad34ef17ae344f5)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 5c663ce8442bd3b69c96e29061c57cc565fca91d)
Conflicts:
src/Makefile.am
src/drmmode_display.c
src/intel.h
src/intel_batchbuffer.c
src/intel_dri.c
src/intel_driver.c
src/intel_memory.c
src/intel_video.c
src/xvmc/intel_xvmc.h
OGA: adapted for ums
|
|
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>
(cherry picked from commit 797d173a9af12055ba2609293182b616dd673ef4)
Conflicts:
configure.ac
src/Makefile.am
src/common.h
src/i830.h
src/i830_accel.c
src/i830_batchbuffer.c
src/i830_driver.c
src/legacy/i810/i810_driver.c
OGA: had to make abunch of changes due to ums still existing, but this
was more sensible that having to modify every single cherry-picked patch
from now on.
|
|
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>
(cherry picked from commit 6ea8ce640fbc7e5054b521a6f70b303945d0e849)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Almost totatlly unused, but surely totally useless.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit f6cb28e909c8685474e69e8bd8600f146d3a74e9)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 676028ec0cbd4fadded92feefc8371e075abcc12)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 3f590a4577f554313e7577205e471757a39129b6)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
... 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>
(cherry picked from commit 8a31dacb067f813a5b0eafc16d265434e48ec5fc)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 16e5edde4d97e1818e0dbfbc165bd8199f697336)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 5f64122551f2d8d41d745351b2e4e68208aa6084)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
The private surface struct now adds nothing. Drop it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 6c44ce9e127e531224bac825da7918800a3e6a1a)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 583ec1f2f7ed32bb42c98baa1ca0fc3735b69b11)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit c9aaaed829731cda22d057d6ac6424c587770973)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 4edff6c972311df2370a8323e346eeabd49ced35)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
... 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>
(cherry picked from commit 9eeabf876d1f70f5525bbac438414557dd2d4335)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit a0058369bbdfb49f8df5ee1e50671115927d3565)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Like for the i915. With this create_context is now also shared.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit b666e3e29f22894f43a8e9f7f3d1b950d431c42d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit e0068b1e63bc914940dbeb52de46657fcf5da1ea)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 036cd4bb82131c08b79f596667f00b19a0c8ab79)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
(cherry picked from commit 318aa9ed799197810e2039dbe3ec51559dcc888c)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
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>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 47ae1181f6cfd2ab64cd5c8535289fdaa2a9fd9c)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 9bba123c5f0f081562306c152e70221fc5041a3b)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit b11623f20e303ae1d90d4a6bf0d5d73970b4e9bf)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit b7f79bfd40db3ed17d7a79750d007b57d7ed157a)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Like for the static indirect state buffer.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
(cherry picked from commit 62846d88d41f1bbbd16a6e700ca611656fa20f61)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit d27955c697e1768559957da8d61087644befd285)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 3203c66fbf04c55adba760e97c9fa1feb9e55f8d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Like with the sampler state buffer.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
(cherry picked from commit d30decae6a9db585f2d2589ae2c3d9e1f9acd33d)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Like with the sampler state buffer.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
(cherry picked from commit b543c355f4fdcb64deb198765d9b8b86f7c234c2)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 18c364084ce5495ffdfea38c17c1297d555c6c54)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit fc9e44f01910eb9fd43def9b2ac531b0742d8b4e)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 04aa38a639fefcd00acb485f36ab18c2083ed1bb)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 24d787335a0c319b8d9243ea1f2726575cf73b2b)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.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>
(cherry picked from commit 5018fd3097d77a5f31af4cb27e39daa37557b64e)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
(oga: note that while we use UMS still, we can trust kernel_exec_fencing
to always be one because we have had modern GEM right from the start.)
|
|
Bug #24396.
(cherry picked from commit 751e0a3e4576bbf4bffa56bbd6d4de28f10db98e)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
v2: Incorporate comments from Jamey on device name handling and extension
detection.
(cherry picked from commit 3e8f2eae3a586aa29be4858698e666e0ec778cea)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Apparently Debian packages were having to manually add these files
back in. Distribute them in the first place like we meant to.
(cherry picked from commit eda2bb26783f7e9ef1ae659265930308378206e1)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Using common defaults will reduce errors and maintenance.
Only the very small or inexistent custom section need periodic maintenance
when the structure of the component changes. Do not edit defaults.
(cherry picked from commit bb994ce018ae6c3e3c5548ae7439cfc5e9aa4554)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
Signed-off-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 3c0a43b24cc7540cc139beca0ec2e4c202ff5593)
Signed-off-by: Owain G. Ainsworth <oga@openbsd.org>
|
|
We've talked about doing this since the start of the project, putting it off
until "some convenient time". Just after removing a third of the driver seems
like a convenient time, when backporting's probably not happening much anyway.
(cherry picked from 8ae0e44e42db645abe6d385f561260d2ae4a1960 commit)
|
|
|
|
is not acting like what bspec told on 965gm.
G45+ follow bspec, but we have to set it to a large value for 965gm.
|
|
|
|
|
|
|
|
If we don't find xext.pc, disable xvmc instead of failing configure
Also add dependencies on xfixes and dri2proto (src/xvmc/dri2.h includes
<X11/extensions/Xfixes.h> and <X11/extensions/dri2tokens.h>).
|
