Age | Commit message (Collapse) | Author |
|
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>
|
|
Yes, this breaks binary compat of the struct passed around between
X ddx and the client libXvMC. But we always ship both, so they should
not get out of sync.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Carl Worth <cworth@cworth.org>
|
|
The only user left of this stuff is the xvmc support.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Yet another user of i830_memory gone for good.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Minus one user of i830_memory, some more to go.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Totally unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Use the one in the drm bo instead.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Totally unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Kill the corresponding !bo path in i830_free_memory.
Also kill another remnant of the pre-kms era in the same file, while I
was looking at the code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
It doesn't bind anything anymore, but does a few random things.
Give it a hopefully vague enough name to cover all cases ;)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Besides the debug stuff the went away in the previous patch,
this stuff was totally unused ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Totally useless debug function from the pre-gem era. No point
to occasionally spam Xorg.log with a bogus "No memory allocations"
message.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Use the one in the drm bo instead.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
It's a left-over from the non-gem era and no longer used at all.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
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>
|
|
I've accidentally broken i915 xvmc due to alignment constrains that
break my assumption that Y-pitch == UV-pitch*2. Fix this up by consistenly
using dstPitch2 for the Y-pitch. This also unifies the dst pitch
computation slightly, now that the i915 xvmc special case is gone.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=25949
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(Minor edit to support compilation without INTEL_XVMC defined by
Carl Worth <cworth@cworth.org>)
|
|
In my previous cleanup I've inadvertedly dropped the offset adjustment
code for the xvmc passthrough case. Fix this up.
Also reimplement that ugly hack I've accidently killed to keep i915 class
xvmc a tad bit longer on life support.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: xunx.fang@intel.com
|
|
In order to make a new snapshot.
|
|
From skimming the git lot since 2.10.0.
|
|
All callers of this function were recently removed, so it can join
them in the bit bucket.
|
|
Rather than mangle the EDID block and hope the server does the right
thing, just build a sensible mode list up front. Do this for LVDS where
there is no EDID or where it does not claim to be continuous-frequency
(since in the latter case, the server will add reasonable modes for us).
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
Sigh. Every version number that must be typed manually will eventually
be typed incorrectly at some release. (I think that's Owne Taylor's
Law)
|
|
Windows aren't refcounted, so if the event came in after the window
was destroyed, we'd dereference garbage and segfault.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We'd want to put something like it in sysfs or something if we wanted
this tool to exist again.
|
|
Things that used it are now either in the kernel or stashed off in
gpu_tools.
|
|
|
|
|
|
|
|
|
|
|
|
Quiets clang warnings about garbage variable usage.
|
|
|
|
|
|
|
|
|
|
Move the unused function into the #if DRI2INFOREC_VERSION >= 4 block.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
On 965 and up, if we detect a full height blit, we should just wait for
vblank, rather than try to do a scanline wait for the whole display.
On pre-965, doing a scanline wait followed by a blit works, but in the
full height case we need to give the blitter time to start up, so we
wait until the bottom line of the blit minus 2 padding scanlines to
accommodate.
Fixes FDO bug #22475.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|