Attachment 28587 Details for Bug 20901 – patch for ddx

[patch] patch for ddx

drmmode_overlay.patch (text/plain), 9.25 KB, created by Daniel Vetter on 2009-08-13 03:23:28 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Daniel Vetter

Created: 2009-08-13 03:23:28 UTC

Size: 9.25 KB

patch

obsolete

>commit 6946914c42ba2bb0f6f7b6d1351f33af53a145fd
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Tue Aug 11 13:12:06 2009 +0200
>
>    Implement drmmode overlay
>    
>    This does not restore the overlay on EnterVT/disable it on LeaveVT.
>    Does not look like this is necessary.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 361705901f128de9afac9b43d386abf0be87a5b3
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Tue Jun 30 11:19:05 2009 +0200
>
>    Xv: introduce an overlay hal
>    
>    This is the last preparatory step for overlay support with drmmode.
>    Safe two (specially marked) function calls in the setup code, all
>    hw accessing code goes now through these three new functions with
>    the ums_overlay prefix.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 3f8b26f517d6bea6dc326136b6e9ea9d210e9a5a
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Tue Aug 11 15:56:34 2009 +0200
>
>    Xv: rework overlay buffer management
>    
>    The basic idea is to only pin the buffer into the gtt when
>    the overlay hw is actually using it. This results in a few changes:
>    
>    - Unify data copied/buffer handling with textured video. Now offsets
>      are always buffer relative and we just use drm_bo_map to access a
>      buffer.
>    - Implement double buffering using two bo's. This is necessary because
>      we can't pin the same buffer to the gtt and map it as normal memory.
>    - Kill XV_DOUBLE_BUFFER. With the above changes, overlay video is always
>      doubel buffered.
>    
>    There is still the XvMC passthrough case, which makes the code slightly
>    ugly. Unfortunately we can't get at the bo behind this buffer.
>    
>    Changes since the last review-round:
>    - Don't overallocate by a factor of 2.
>    - Prevent possible use-after-free issue.
>
>commit 06188abbed359c266f2033d8b3b28aa0aaf8aada
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Mon Jun 29 11:32:54 2009 +0200
>
>    Xv: create xvmc_passthrough helper
>    
>    This way all thes strange special cases make much more sense.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit a7f820dc61efe4aa77b22dd4aaefd08ca97213a6
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Mon Jun 29 10:25:07 2009 +0200
>
>    Xv: scrap overlay offscreen pixmap support
>    
>    The code looks like it's been bitrotting since being copied over
>    from the i810 driver. Furthermore painting rgb pixmaps with the overlay
>    engine is in these days of modern compositing X an absolute no-go. And
>    textured video doesn't support it neither, so its likely never ever
>    used by applications.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 3a4e39fa527e6f1bec9306a0c9d7b69b222532a6
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 13:50:09 2009 +0200
>
>    Xv: small cleanups in I830PutImage
>    
>    - scrap unused variable overlay
>    - scrap an superflous if and attach the code to the preceeding else
>    - tiny layout fix.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit b8bdd7f6ec3ac9aa7406ec92c86c3652e1044e42
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 13:45:05 2009 +0200
>
>    Xv I830PutImage splitup: extract i830_wait_for scanline
>    
>    Also scrap the unecessary variable sync in I830PutImage and the
>    accompanying obfuscated logic.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 52250eeaf73398c9c1f91ca7b2317f785f8eba56
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 13:34:20 2009 +0200
>
>    Xv I830PutImage splitup: extract i830_copy_video_data
>    
>    Just moves the code and passes back allocation failures.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit c90e5dfcd7d5789ff41d69c60accb4bd59190337
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 13:28:38 2009 +0200
>
>    Xv I830PutImage splitup: extract i830_setup_video_buffer
>    
>    Just move the code and pass back allocation failures.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 3e0435569d2d7f58d58eb2f7c8a6952cc29b6934
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 13:19:53 2009 +0200
>
>    Xv I830PutImage splitup: extract i830_dst_pitch_and_size
>    
>    Just moves the code.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 8a3ddc0d78dcb40a14f8037b81cf202eaa40c301
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Sat Jun 27 23:08:58 2009 +0200
>
>    Xv: kill destId in I830PutImage
>    
>    It's only used to remember that XvMC has á»²V12 as output. is_planar_fourcc
>    already takes care of that in all necessary cases.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 2096013512e0099bfbb89439943c1b70cccabc92
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Tue Aug 11 13:54:23 2009 +0200
>
>    Xv: kill hw double buffering logic
>    
>    The idea for the hw double buffering support is to program two fixed
>    buffers and then only switch buffers in the OCMD register. But the driver
>    as-is always programs the new buffer address (in both register sets
>    when double buffered). Therefore we gain nothing by using this hw
>    capability. Scrap the software support for it.
>    
>    When double buffered, we now allocate just a buffer of size 2*size and
>    switch between the two parts purely in software.
>    
>    To make reviewing this easier, I'll shortly explain the differences of how
>    double-buffering (i.e. tear-free video) is achieved before and after this
>    change:
>    
>    - When double buffer, allocate a buffer twice the size (unchanged).
>    - Depending upon the currently shown buffer-half, copy the new frame into
>      the other buffer-half. In the old code this is done by using the right
>      set of buffer offsets, either *Buf0Offset or *Buf1Offset. The new code
>      simply programs the offset for the right buffer-half into the single set
>      of offsets. The end-result is unchanged.
>    
>    Now the big difference in hw-programming:
>    
>    Old: Programm new buffer offset into both sets of _hw_ buffer offset
>    registers. Depending upon the current _sw_ buffer, select the _hw_ buffer
>    and program this into the OCMD register. This just complicates matters
>    unnecessarly.
>    
>    New: Just always use the hw buffer 0.
>    
>    And then it's again the same story in both old and new code:
>    
>    - Execute an overlay flip (MI_OVERLAY_FLIP) to read in the contents of the
>      hw registers into the shadow hw registers (which are actually being used
>      by the overlay, not the ones we write stuff into). This is synchronized
>      with the respective crtc vblank by the hw.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 891b387c6b31972a3e339508e57bd660b2991a17
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Fri Jul 3 09:59:40 2009 +0200
>
>    Xv: use is_planar_fourcc helper some more
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit f09d9543216d129f2abd0d3ad871519d0cee2eba
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Fri Jul 3 09:57:33 2009 +0200
>
>    Xv: introduce planar memcpy helper
>    
>    Reduced 3 copies of the same code to one.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 10614c7dd4ecbb1b4d3dd6a15b949cb389053f1f
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 12:32:53 2009 +0200
>
>    Xv: rename i830_display_video to i830_display_overlay
>    
>    This function only programs the overlay and is never called for textured
>    video. Make this obvious.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit c10db56e09177cfc2192dc632aa5df8f1d791139
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Thu Jul 2 12:31:37 2009 +0200
>
>    Xv i830_display_video splitup: extract i830_overlay_cmd
>    
>    This slightly moves around (and simplifies) the OSTRIDE reg programming,
>    too.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
>commit 0328734a90544a6cd72d9eaf64015db9d3462921
>Author: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date:   Tue Aug 11 13:51:51 2009 +0200
>
>    Xv i830_display_video splitup: extract i830_calc_src_regs
>    
>    Also introduce an is_planar_fourcc helper. I'll use that one later.
>    
>    In i830_display_video this changeset moves the XVMC case (previously
>    obscured as the default case) around. I've figured this default case
>    does not make sense, here's why:
>    
>    XvMC is everywhere else handled as a planar format (e.g. in the register
>    programming a few lines down). Furthermore the id variable gets mapped
>    to FOURCC_YV12 if IS_I915(pI830) is true in I830PutImage. There's a
>    second caller in the offscreen overlay support code.  But I think that
>    code is bitrotten and not reliable as an information source.
>    
>    So we have a different behaviour only for id=FOURCC_XVMC and i965 class
>    hw (i830 class doesn't have xvmc). I've crawled through various
>    sources/intel documentations. Finally in the textured video implemention
>    for i965 class hw (src/i965_video.c) I've found a switch statement that
>    puts XVMC into the same case as I420 and YV12. So also in i965 class hw
>    xvmc uses a planar format.
>    
>    In conclusion I claim that this code was bogus and XvMC on i965 class hw
>    over Xv overlay was most likely broken.
>    
>    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Actions: View | Splinter Review

Attachments on bug 20901: 28587 | 28588 | 28589 | 28615 | 29397 | 29518

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.