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 the subpicture stuff, share the "do-nothing" functions ...
And fix function name spelling, too.
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>
The XvMC driver api in the server is insane. Even for optional stuff
like subpicture support it doesn't check for NULL-pointers. So we
have to retain some dummy functions.
Wonder how many copies of these things exist on fdo ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both xvmc are handing in the bo in the exact same way. So move the code
to src/i830_video.c and kill this great oeuvre of spaghetti-code.
The xvmc driver ini and fini also lost their last use, kill them, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After unifying i915 and i965, not much will be left of these files.
Therefore merge them to make the following changes easier.
This creates some warnings about some redefined macros, but when this
is all cleaned up they'll all be gone.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pauli pointed out that we take a ref on the front buffer when exchanging
but forget to release it. The ref is necessary since the set functions
will drop refs as necessary, but once we set the front buffer to point
at the back pixmap, we ned to release our private ref again, or we'll
leak buffers.
Reported-by: Pauli Nieminen <suokkos@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
After reports of segmentation faults caused by
d6b7f96fde and vmware, the most obvious
cause would be illegally writing to the src data when performing the alpha
fill inline. So force the image upload to go via a fresh buffer whenever
we need to modify the incoming data.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
On memory constrained hardware, tiling is vital for good performance as
it minimizes cache misses. The downside is that for older hardware
(which often suffers from the lack of bandwidth) requires the use of
fences for many operations, which are in short supply and so may cause
shorter batchbuffers. However our batch buffers are typically short and
so this is unlikely to be a concern and not affect the performance wins.
A quick bit of testing suggests the effect is inconclusive on
firefox/i945:
linear tiled
xcb 205.470 206.219
xcb-render-0.0 404.704 388.413
xlib 166.410 170.805
A secondary effect of the patch is to workaround a G31 specific hang
when attempting to use linear 2048x2048 surfaces. Bonus!
Fixes:
Bug 25375 - Performance issue using texture from pixmap (tfp) glx extension on 945
http://bugs.freedesktop.org/show_bug.cgi?id=25375
Bug 27100 - GPU Hung copying a 2048x1152 pixmap
http://bugs.freedesktop.org/show_bug.cgi?id=27100
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: John <jvinla@gmail.com>
Include the names from the current kernel driver along with accurate
descriptions of each. Indicate how to use the values with:
xrandr --output output --set property value
and point the user to "xrandr --prop" for an accurate list of
currently available values.
Closes bug:
xf86-video-intel manpage needs update for KMS xrandr properties
http://bugs.freedesktop.org/show_bug.cgi?id=25606
Otherwise it would be a random value and drmmode_page_flip_handler()
won't have a chance to call I830DRI2FlipEventHandler() and indicate
a full page flip is complete.
Signed-off-by: Li Peng <peng.li@intel.com>
Fixes:
http://bugs.freedesktop.org/show_bug.cgi?id=27123
Fatal server error:
i915_emit_composite_setup: ADVANCE_BATCH: under-used allocation 100/104
Introduced with commit d6b7f96fde.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Do not try to fixup the alpha in the ff/shaders as this has the
side-effect of overriding the alpha value of the border color, causing
images to be padded with black rather than transparent. This can
generate large and obnoxious visual artefacts.
Fixes:
Bug 17933 - x8r8g8b8 doesn't sample alpha=0 outside surface bounds
http://bugs.freedesktop.org/show_bug.cgi?id=17933
and many related cairo test suite failures.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes a number of cairo test suite failures.
Also affects:
Bug 16917 - Blur on y-axis also when only x-axis is scaled bilinear
http://bugs.freedesktop.org/show_bug.cgi?id=16917
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
Just make it mirror ScheduleSwap: complete the wait on any error
condition so as not to crash the client if the kernel is misbehaving.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We can only handle 32 bit values unless we totally virtualize the count,
since the kernel only handles 32 bits itself. Rather than adding all
that overhead, just tolerate the occasional missed event everytime the
counter runs over.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
A couple more niggles: make sure we return a target_msc that at least
matches the current count; this is a little more friendly to clients
that missed an event. Also check for >= when calculating the remainder
so we'll catch the *next* vblank event when the calculation is
satisfied, rather than the current one as might happen at times.
Reported-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>