[Intel-gfx] [PATCH 00/18] rip out i830_memory, part 2: xvmc
Carl Worth
cworth at cworth.org
Thu Mar 4 01:44:25 CET 2010
On Tue, 2 Mar 2010 21:53:10 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> By popular request, here's the second patch pile to kill of the old
> allocator.
Fantastic. Thanks for contributing!
> 14 files changed, 336 insertions(+), 2389 deletions(-)
Woo-hoo! That's a diffstat to make any of us happy.
My one question in a quick reading is this hunk ([PATCH 12/18] i915
XvMC: switch surfaces to drm_intel_bo):
diff --git a/src/i915_hwmc.c b/src/i915_hwmc.c
index 4395cdc..c0b0bb8 100644
--- a/src/i915_hwmc.c
+++ b/src/i915_hwmc.c
@@ -797,6 +797,7 @@ static int i915_xvmc_put_image(ScrnInfoPtr scrn,
int ret;
if (FOURCC_XVMC == id) {
+#if 0
switch (xvmc_cmd->command) {
case INTEL_XVMC_COMMAND_DISPLAY:
if ((xvmc_cmd->srfNo >= I915_XVMC_MAX_SURFACES) ||
@@ -815,6 +816,9 @@ static int i915_xvmc_put_image(ScrnInfoPtr scrn,
default:
return 0;
}
+#endif
+ /* Pass the GEM object name through the pointer arg. */
+ buf = (void *)(uintptr_t)xvmc_cmd->handle;
}
ret =
Why are we adding an #if 0 instead of just deleting the code here?
We could eliminate the code, replace the condition with some named
variable, or at the very least add a comment explaining what's going on
here.
Other than that, I'm ready to merge this. The series does depend on the
XvMC fixup and I had a compilation problem with that, (which I'll
describe in a separate post in that thread).
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20100303/0cd4bd02/attachment.sig>
More information about the Intel-gfx
mailing list