[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