On Sat, Dec 25, 2010 at 9:58 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: > On Sat, Dec 25, 2010 at 3:04 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> On Saturday, December 25, 2010 00:47:22 Rob Clark wrote: >>> On Fri, Dec 24, 2010 at 5:32 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>> > On Friday, December 24, 2010 22:29:37 Rob Clark wrote: >>> >> Hi all, >>> >> >>> >> The request has come up on OMAP4 to support non-page-aligned v4l2 >>> >> buffers. (This is in context of v4l2 display, but the same reasons >>> >> would apply for a camera.) For most common resolutions, this would >>> >> help us get much better memory utilization for a range of memory (or >>> >> rather address space) used for YUV buffers. >>> > >>> > Can you explain this in more detail? I don't really see how non-page >>> > aligned buffers would lead to 'much better' memory usage. I would expect >>> > that the best savings you could achieve would be PAGE_SIZE-1 per buffer. >>> > >>> >>> Due to how the buffers are mapped, the savings is actually quite >>> substantial. What actually happens is the region of memory that the >>> buffers are allocated from has a stride of 16kb or 32kb. (For NV12, Y >>> has a 16kb stride, and UV is disjoint is a 32kb stride.) To keep >>> things somewhat sane for userspace, the Y followed by UV gets mmap'd >>> into consecutive 4kb pages. So we are actually loosing 1.5 * (4kb - >>> width) per buffer by forcing page alignment. With non page-aligned >>> buffers we can pack buffers next to each other, ie. so one buffer may >>> exist within the stride of another buffer. >> >> I understand. But what is the size of your buffers and how many are there? >> Fiddling with non-page aligned buffers will only make sense if the savings are >> substantial compared to the total size of the buffers. In my experience the >> buffers are so large that savings of 1-2 pages per buffer aren't worth it. >> > > The buffers can be, for example 1080p (2048x1156 once you add in codec > borders).. and for h264 there can be a lot.. it varies based on the > max_num_ref_frames of the clip you are decoding, but when you add up > the minimum # of buffers the codec requires, plus a few for a queue, > and a couple for the display to have enough to flip buffers, you could > end up with something with 10+ large buffers, which because of the way > the buffers are mapped are consuming 2x the amount of address space as > packed buffers will. With buffers this size we'd be saving 578 pages > per buffer, times 10 buffers. Add in concurrent use cases, like video > tele-conf where you are both encoding and decoding simultaneously and > it gets even more significant. oh, whoops.. was being a bit sloppy. That would actually be 867 pages per buffer: 0.5 page * (1156 lines of Y + 1156/2 lines of UV) -> 867 pages BR, -R > > So it isn't a matter of just saving a couple pages per buffer. It is > really a very significant savings. If it weren't, we wouldn't be > considering this ;-) > > BR, > -R > >> Regards, >> >> Hans >> >>> >>> >>> BR, >>> -R >>> >>> >>> > Regards, >>> > >>> > Hans >>> > >>> >> However it would require >>> >> a small change in the client application, since most (all) v4l2 apps >>> >> that I have seen are assuming the offsets they are given to mmap are >>> >> page aligned. >>> >> >>> >> I am curious if anyone has any suggestions about how to enable this. >>> >> Ideally it would be some sort of opt-in feature to avoid breaking apps >>> >> that are not aware the the offsets to mmap may not be page aligned. >>> >> >>> >> BR, >>> >> -R >>> >> -- >>> >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>> >> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >>> > >>> > -- >>> > Hans Verkuil - video4linux developer - sponsored by Cisco >>> > >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >> >> -- >> Hans Verkuil - video4linux developer - sponsored by Cisco >> > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
