On Monday 06 December 2010, David Sin wrote:
Tiling and Isometric Lightweight Engine for Rotation (TILER) driver
Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. Within the DMM exists at least one TILER hardware component. Its purpose is to organize video/image memory in a 2-dimensional fashion to limit memory bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the TILER container(s). It also facilitates rotating and mirroring the allocated blocks or its rectangular subsections.
How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality.
I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there.
Arnd
On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote:
On Monday 06 December 2010, David Sin wrote:
Tiling and Isometric Lightweight Engine for Rotation (TILER) driver
Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. Within the DMM exists at least one TILER hardware component. Its purpose is to organize video/image memory in a 2-dimensional fashion to limit memory bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the TILER container(s). It also facilitates rotating and mirroring the allocated blocks or its rectangular subsections.
How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality.
I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there.
Arnd
Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) for x86? I'm trying to understand the differences and make a case that it's not the same as DMM/TILER.
thanks,
On Thu, Dec 16, 2010 at 11:25:31AM -0600, David Sin wrote:
On Thu, Dec 16, 2010 at 02:34:05PM +0100, Arnd Bergmann wrote:
On Monday 06 December 2010, David Sin wrote:
Tiling and Isometric Lightweight Engine for Rotation (TILER) driver
Dynamic Memory Manager (DMM) is a hardware block made by Texas Instruments. Within the DMM exists at least one TILER hardware component. Its purpose is to organize video/image memory in a 2-dimensional fashion to limit memory bandwidth and facilitate 0 effort rotation and mirroring. The TILER driver facilitates allocating, freeing, as well as mapping 2D blocks (areas) in the TILER container(s). It also facilitates rotating and mirroring the allocated blocks or its rectangular subsections.
How does this relate to DRM/GEM? I don't understand too much about graphics drivers, but it does sound like there is some overlap in functionality.
I guess at the very least the DMM should live in drivers/gpu/ instead of drivers/misc, but perhaps it could be integrated more closely with the existing code there.
Arnd
Do you know if anyone on your team is familiar with DRM/GEM (grap ext mgr) for x86? I'm trying to understand the differences and make a case that it's not the same as DMM/TILER.
thanks,
David Sin
Hi Arnd, I'm not sure exactly how DRM/GEM works.. What functionality do you think is overlapping? The main feature, aside from reduced page accesses, of the DMM hw block is to provide physically contiguous 2 dimensional memory blocks for image and video processing. This hw sits between the interconnect and the ext memory interface in the OMAP, and contains an MMU-like address traslator for "virtually" physically contiguous memory and sdram pages.
thank you for your comments.
BR,
On Thursday 16 December 2010 18:37:38 David Sin wrote:
I'm not sure exactly how DRM/GEM works.. What functionality do you think is overlapping? The main feature, aside from reduced page accesses, of the DMM hw block is to provide physically contiguous 2 dimensional memory blocks for image and video processing. This hw sits between the interconnect and the ext memory interface in the OMAP, and contains an MMU-like address traslator for "virtually" physically contiguous memory and sdram pages.
As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory.
I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need.
Arnd
On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote:
As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory.
I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need.
Arnd
Thanks for the pointer, Arnd. I also found a nice readme file in the gpu/drm directory, which points to a wiki and source code. I'll read into this and get back to you.
BR,
On Fri, Dec 17, 2010 at 5:02 AM, David Sin davidsin@ti.com wrote:
On Thu, Dec 16, 2010 at 06:43:48PM +0100, Arnd Bergmann wrote:
As far as I can tell, both DMM and GEM at a high level manage objects in video memory. The IOMMU that you have on the Omap hardware seems to resemble the GART that sits between PC-style video cards and main memory.
I don't know any details, but google quickly finds http://lwn.net/Articles/283798/ with a description of the initial GEM design. My main thought when looking over the DMM code was that this should not be tied too closely to a specific hardware, and GEM seems to be an existing abstraction that may fit what you need.
Arnd
Thanks for the pointer, Arnd. I also found a nice readme file in the gpu/drm directory, which points to a wiki and source code. I'll read into this and get back to you.
I get the impression with the ARM graphics, that you just have a lot of separate drivers for separate IP blocks all providing some misc random interfaces to userspace where some binary driver binds all the functionality together into a useful whole, which seems like a really bad design.
Generally on x86, the tiling hw is part of the GPU and is exposed as part of a coherent GPU driver.
I'm just wonder what the use-cases for this tiler are and what open apps can use it for?
Dave.
On Fri, Dec 17, 2010 at 09:28:07AM +1000, Dave Airlie wrote:
On Fri, Dec 17, 2010 at 5:02 AM, David Sin davidsin@ti.com wrote: I get the impression with the ARM graphics, that you just have a lot of separate drivers for separate IP blocks all providing some misc random interfaces to userspace where some binary driver binds all the functionality together into a useful whole, which seems like a really bad design.
Generally on x86, the tiling hw is part of the GPU and is exposed as part of a coherent GPU driver.
I'm just wonder what the use-cases for this tiler are and what open apps can use it for?
Dave.
Yes -- on the omap4 soc, the dmm-tiler hw block is separate from the gpu. I've had some, but not much, past discusions on hw designs where graphics/video related ip blocks are part of the same core. It's a good point that you bring up and it certainly makes sense to me. I will bring it up with some omap hw folks that I know, and see if something that can be considered in future omap versions.
Some of the use-cases are HD video decoding and encoding. Also, hi-res image capture -- I believe 12MP or greater. OpenMax IL components and other multimedia frameworks can allocate video memory through a user space tiler library. Thanks for your comments, Dave.
dri-devel@lists.freedesktop.org