Hi Hans, On Tue, 2011-03-08 at 18:23 +0100, Hans Verkuil wrote: > > > > "Single" might be making the problem impossibly hard to solve well. > > One-size-fits-all solutions have a tendency to fall short on meeting > > someone's critical requirement. I will agree that "less than n", for > > some small n, is certainly desirable. > > Actually, I think we really need one solution. I don't see how you can have > it any other way without requiring e.g. gstreamer to support multiple > 'solutions'. Thanks. Laurent's explanation sorted that out for me. > > The memory allocators and managers are ideally satisfying the > > requirements imposed by device hardware, what userspace applications are > > expected to do with the buffers, and system performance. (And maybe the > > platform architecture, I/O bus, and dedicated video memory?) > > > > We discussed this before at the V4L2 brainstorm meeting in Oslo. The idea > was to have opaque buffer IDs (more like cookies) that both kernel and > userspace can use. Sounds like System V Shared Memory IPC. It may be worth looking at the issues one can get with SYS V Shared Memory: obtaining the resource identifier, exhaustion of global resources, etc. > You have some standard operations you can do with that > and tied to the buffer is the knowledge (probably a set of function pointers > in practice) of how to do each operation. So a buffer referring to video > memory might have different code to e.g. obtain the virtual address compared > to a buffer residing in regular memory. That is interesting. > > This way you would hide all these details while still have enough flexibility. > It also allows you to support 'hidden' memory. It is my understanding that on > some platforms (particular those used for set-top boxes) the video buffers are > on memory that is not accessible from the CPU (rights management related). But > apparently you still have to be able to refer to it. I can see that's something one would need to do with key material stored inside any decent cryptographic engine (key material should not be extractable from the engine, ever). I guess it's needed for the video ciphertext and video plaintext in STB DRM to impede someone with physical access to the device from doing differential analysis on the buffers to extract the key. > I may be wrong, it's > something I was told. > > > > > > > > I am currently aware of the following solutions floating around the net > > > that all solve different parts of the problem: > > > > > > In the kernel: GEM and TTM. > > > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM. > > > > Prior to a meeting one would probably want to capture for each > > allocator: > > > > 1. What are the attributes of the memory allocated by this allocator? > > > > 2. For what domain was this allocator designed: GPU, video capture, > > video decoder, etc. > > > > 3. How are applications expected to use objects from this allocator? > > > > 4. What are the estimated sizes and lifetimes of objects that would be > > allocated this allocator? > > > > 5. Beyond memory allocation, what other functionality is built into this > > allocator: buffer queue management, event notification, etc.? > > > > 6. Of the requirements that this allocator satisfies, what are the > > performance critical requirements? > > > > > > Maybe there are better question to ask. > > It's a big topic with many competing and overlapping solutions. That really > needs to change. It also seems that the existing providers have different objectives. >From what I read, GEM could swap out buffers under system low memory conditions, so the system still runs at the expense of video performance. IIRC, TTM locks pages into memory. With the per buffer type operations you mentioned, I guess the requirements that drive those sort of conflicting design decisions can be satisfied by one mechanism? Regards, Andy -- 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
