Abstract:
A visual display is provided on a data processing apparatus by storing and retrieving display information. The display information is stored by receiving write access addresses ( 33 ), translating the write access addresses into write memory addresses ( 15 ) and using the write memory addresses to store the display information ( 11 ). The read operation includes providing read access addresses ( 37 ), translating the read access addresses into memory read addresses ( 19 ) and using the memory read addresses to retrieve the display information ( 11 ).

Description:
FIELD OF THE INVENTION  
       [0001]     The invention relates generally to data processing and, more particularly, to processing data for visual display.  
       BACKGROUND OF THE INVENTION  
       [0002]     Almost all desktop systems employ a landscape orientation of their displays. This is characterized by a display that is wider than it is tall. Video monitors and televisions also utilize landscape orientations. However, handheld device orientations vary based on the desired form factors of the products themselves. Often, the device uses a portrait orientation instead, which is characterized by a display that is taller than it is wide.  
         [0003]     Due to the prevalence of systems that employ landscape orientations, there is a corresponding prevalence of displays that are designed for landscape orientations. Eventually, as there is more demand for portrait oriented images, portrait oriented displays will become available. But portrait displays are currently more expensive than their landscape counterparts.  
         [0004]     It should be noted that in the long run, it is in the best interest of the product developers to eventually migrate to a natively portrait display for use with portrait oriented images. This will provide the maximum power efficiency and highest performance for the display. However, the lack of availability and/or higher cost of natively portrait displays can outweigh the power and performance advantages. Moreover, even when natively portrait displays do become available, there will be devices which need to switch between landscape and portrait orientations.  
         [0005]     The invention provides a hardware solution that rotates a landscape oriented image to a portrait orientation for display on a landscape display, and vice-versa.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0006]      FIG. 1  diagrammatically illustrates exemplary embodiments of a data processing apparatus according to the invention.  
         [0007]      FIG. 1A  diagrammatically illustrates exemplary embodiments of the translator logic of  FIG. 1 .  
         [0008]      FIG. 2  conceptually illustrates conventional flat memory organization.  
         [0009]      FIG. 3  conceptually illustrates conventional rectangular memory organization.  
         [0010]      FIG. 4  conceptually illustrates a conventional example of a rectangular memory organization.  
         [0011]      FIG. 4A  conceptually illustrates a conventional 90° rotation of the rectangular memory organization of  FIG. 4 .  
         [0012]      FIG. 5  conceptually illustrates a conventional memory page arrangement.  
         [0013]      FIG. 6  conceptually illustrates a tiled arrangement of the memory pages of  FIG. 5  according to the invention.  
         [0014]      FIG. 7  conceptually illustrates a rotated version of the tiled memory page arrangement of  FIG. 6  according to the invention.  
         [0015]      FIG. 8  illustrates address translation equations which can be implemented by exemplary embodiments of the invention to translate from the memory page arrangement of  FIG. 5  to the tiled memory page arrangement of  FIG. 6 .  
         [0016]      FIGS. 9-11  illustrate address translation equations which can be implemented by exemplary embodiments of the invention to translate the memory page arrangement of  FIG. 5  into a rotated version of the tiled memory page arrangement of  FIG. 6 , such as the rotated version illustrated in  FIG. 7 .  
         [0017]      FIGS. 12-15  illustrate equations which specify parameter values that can be utilized by exemplary embodiments of the invention to implement the address translation equations of  FIGS. 8-11 .  
     
    
     DETAILED DESCRIPTION  
       [0018]     Display systems typically consist of a section of memory that is dedicated for graphics. Data from this section of memory is repeatedly rastered out to the display as it is refreshed. Applications and the operating system draw their graphics into this region of memory so that it shows up on the display. Normally, the operating system and applications assume that this memory is organized the same way as that memory on desktop systems. This orientation turns the one-dimensional memory ( FIG. 2 ) into a two-dimensional framebuffer ( FIG. 3 ) by conceptualizing the memory as being broken into lines of a specified width, creating a rectangular organization of the memory. The operating system or application uses the rectangular information to render two-dimensional images into the graphics memory.  
         [0019]     Since memory was designed to be read sequentially for greatest efficiency, the normal method of refreshing the display also proceeds sequentially, in order to take advantage of this design. If the orientation of this memory matches the orientation of the display, which would be the case for the normal orientations outlined above, then both the software and hardware are working at the most efficient level possible, and there is no need for any rotation.  
         [0020]     However, when the software and display must view the memory differently, there must be some rotation to provide each part with its desired orientation (see  FIGS. 4 and 4 A). This can be approached via software or hardware. One method of handling rotation of the display using hardware is to modify the display access to the framebuffer and have the memory accesses for the display subsystem read the data in the rotated format shown in the 90-degree view of  FIG. 4A . In this case, the operating system and applications access the framebuffer as shown in the non-rotated view in  FIG. 4 . One problem with this method is that the accesses to the framebuffer for display refresh are non sequential and become effectively random accesses to the memory. These accesses fail to take advantage of the sequential nature of the memory (bursting, pixel-packing, etc.). The overhead of display refreshing therefore increases significantly. Such a design would require substantially more power, severely limit system performance by monopolizing memory bandwidth, and put strict limitations on the resolutions that could be supported.  
         [0021]     In a second hardware approach, the display subsystem accesses memory as seen in the non-rotated view of  FIG. 4 , while the operating system (OS) and applications see the rotated view. This is accomplished by intercepting the memory accesses and providing an address translation to the actual memory access. The software is provided with a “virtual” window into the framebuffer, also referred to herein as an aperture. Whenever the software accesses this aperture, the access address is translated to a corresponding actual address in the framebuffer. In most cases, this method results in better efficiency than the modified display access method above, because OS and applications generally do not access the framebuffer as often as the display. However, graphics performance is degraded for the same reasons given above, because the non-sequential accesses to the framebuffer cause each access to have a high overhead.  
         [0022]     If the underlying graphics code can be modified or replaced, the rotation of the display can be accomplished via software. Many operations will suffer no appreciable performance degradation, because only the coordinates of the desired operation are rotated, and the operation proceeds in almost the same manner as its non-rotated counterpart. Nevertheless, there will be many operations that are impacted, because almost all external data (fonts, bitmaps, video, etc.) will need to be explicitly rotated. Unfortunately, in most systems, this level of access to underlying graphics code is either not possible or extremely impractical. For example, one conventional library of graphics functions performs over 128,000 different graphics operations, and replacing it for purposes of rotation would require several man-years of effort in development, debugging, and testing. Also, applications which run on top of such a library routinely make certain assumptions about the orientation of the memory with respect to the display, and unless every application can also be modified to add rotation support, they will not be compatible with this modified graphics code approach.  
         [0023]     When the underlying graphics code cannot be modified or modifying it is impractical, the rotation of the display can often still be accomplished via software which operates outside of the baseline graphics code. In this scheme, an intermediate graphics buffer is allocated. This intermediate graphics buffer is oriented as needed by the operating system and applications. But the separate framebuffer that is actually displayed is oriented as necessary for the efficient feeding of data to the display. Then, once the software has completed a given graphics operation into the intermediate buffer (or at a specified interval) the data in this intermediate buffer (or better still, only the portion that was changed) is copied through a software rotation to the framebuffer. This approach is less efficient than the aforementioned graphics code modification, but it is more realistic in some cases where modifying the baseline operating system is impractical and where access to application source code is not possible.  
         [0024]     The intermediate buffer approach can also be used with some hardware assistance. The data is copied and rotated to the framebuffer via a BLTer (Block Transfer engine) in place of software. This removes the software overhead of the rotation operation, but still leaves significant overhead.  
         [0025]     In exemplary embodiments of the invention, the framebuffer itself is oriented neither for display nor for (OS or application) software, but instead in an intermediate, tiled format that is conducive to efficient software and display accesses simultaneously. Two separate apertures can be provided through which the display and software respectively access the framebuffer. These apertures provide the memory translation necessary to support the rotation.  
         [0026]     The framebuffer is broken into tiles that consist of one memory page each. Example memory pages are shown at  0 - 7  in  FIG. 5 . Tiles are conceptually rectangular constructs (see  FIGS. 6 and 7 ). Since the memory pages are always a power of two, the tiles&#39; width and height in some embodiments are also powers of two. In some embodiments, the sequential display accesses map to the horizontal orientation of the framebuffer tiles, and the width of the tiles is generally at least the width of one burst, for maximum display efficiency. The tile-based design also allows successive accesses from the operating system or application to be from the same memory page.  
         [0027]     Some embodiments provide apertures through which software will access the tiled framebuffer. One aperture represents a non-rotated access, as shown generally in  FIG. 6 . Some embodiments use this aperture for the display subsystem, and another aperture provides the operating system and applications with a rotated view of the same framebuffer, as shown generally in  FIG. 7 . For both apertures, the access address provided thereto will be translated appropriately before the actual memory access occurs.  
         [0028]     The memory translation for a given aperture is accomplished via a four-part memory offset equation, examples of which are shown in  FIGS. 8-11 . One part accomplishes the translation of the access address to the tile&#39;s column. A second part translates the access address to the tile&#39;s row. The third part determines the proper line within the tile, and the fourth part specifies the byte within the line. Since the size of the display can vary, the baseline equations of  FIGS. 8-11  are designed to allow for any display width, display height, page size, tile width and tile height. In these equations, all variables and intermediate values are integers. The percent symbol (%) indicates a modulo operator (the remainder after a division), and the symbol “|” designates a logical OR operation.  
         [0029]     For 16-bit and 32-bit accesses, the least significant bits (one for 16-bit and two for 32-bit) are masked off before the equation (one of  FIGS. 8-11 ) is applied, and are replaced after the translation is complete.  
         [0030]     For the equations of  FIGS. 8-11 , the following are defined: 
        Page size—defined by memory architecture (bytes)     Display depth—defined by application (bytes)     Display width—defined by display hardware (pixels*display depth)     Display height—defined by display hardware (lines)     Tile width—normally the width of a burst (bytes)     Tile height=page size/tile width     Horizontal strip=display width*tile height     Vertical strip=display height*tile width     Tile rows=display height/tile height     Tile columns=display width/tile width        
 
         [0041]     In order to implement the memory offset equations of  FIGS. 8-11 , it is desirable to reduce them to operations that can be accomplished within the address cycle of the bus. For example, division and multiplication operations can be replaced with shifts, and modulo operations can be replaced with masks when these operations are limited to powers of two. Replacement of subtraction and addition with logical OR and XOR operations can also be helpful. Therefore, some embodiments constrain the constant values to be powers of two. This is already true for the page size, so the tile width and height follow suit. The only real limit is placed on the display width and height, which is rounded up to the nearest power of two.  
         [0042]     By performing the above simplifications, each part of each memory offset equation of  FIGS. 8-11  can be converted into the following group of operations: 
 
((aperture offset&gt;&gt;shift {circumflex over ( )}minuend) &amp; mask 
 
         [0043]     The shift operation (“&gt;&gt;”) is actually bi-directional, where a left shift is indicated by a negative value of the “shift” parameter. The “{circumflex over ( )}” character represents an exclusive or (XOR) operation.  
         [0044]     Using four of these groups of operations for each memory offset equation (see also  FIGS. 8-11 ) creates the following general equation for the memory offset: 
 
Memory offset=(((aperture offset&gt;&gt; shift 0){circumflex over ( )} minuend 0) &amp;  mask 0)|(((aperture offset&gt;&gt; shift 1){circumflex over ( )} minuend 1) &amp;  mask 1)|(((aperture offset&gt;&gt; shift 2){circumflex over ( )} minuend 2) &amp;  mask 2)|(((aperture offset&gt;&gt;shift3){circumflex over ( )} minuend 3) &amp;  mask 3 
 
 When combined with all of the other portions of  FIGS. 8-11  (and assuming that the aperture base address is a power-of-two so that the aperture offset is simply the least significant bits of the access address), the entire memory address equation for each aperture becomes 
 
Memory address=memory base address+(((((aperture offset &amp; depth mask)&gt;&gt; shift 0){circumflex over ( )} minuend 0) &amp;  mask 0)|((((aperture offset &amp; depth mask)&gt;&gt; shift 1){circumflex over ( )} minuend 1) &amp;  mask 1)|((((aperture offset &amp; depth mask)&gt;&gt; shift 2){circumflex over ( )} minuend 2) &amp;  mask 2)|((((aperture offset &amp; depth mask)&gt;&gt; shift 3){circumflex over ( )} minuend 3) &amp;  mask 3)|(aperture offset &amp; ˜depth mask)) 
 
         [0045]     The “˜” character represents a logical complement or not operation.  
         [0046]     Such an equation will, in some embodiments, require approximately 10K gates. As mentioned above, at least two apertures are needed, one for the display subsystem, and one for software access.  
         [0047]     The values of the programmable parameters in the memory offset and memory address equations shown above are derived from the equations for the different rotations (see  FIGS. 8-11 ). The parameter values are specified in  FIGS. 12-15 . For the equations of  FIGS. 12-15 , the following are defined: 
 
Tile width power= log   2 (Tile width) 
 
Tile height power= log   2 (Tile height) 
 
Page size power= log   2 (Page size) 
 
Display width power= log   2 (Display width) 
 
Display height power= log   2 (Display height) 
 
Display depth power= log   2 (Display depth) 
 
Horizontal strip power= log   2 (Horizontal strip) 
 
Vertical strip power= log   2 (Vertical strip). 
 
Display size=(Display width*Display height) is also defined for FIGS.  12 - 15 . 
 
         [0048]     Some embodiments implement the two address translations using two reserved regions of physical memory and two sets of  14  registers. The reserved regions of physical memory are the apertures through which the memory will be accessed. Whenever these regions of memory are accessed by the access address of  FIGS. 8-11 , the associated address translation occurs, and the memory access actually occurs to/from the physical memory location specified by the output of the address translation operation, namely the location specified by “memory address” as defined above.  
         [0049]     In some embodiments, the apertures are of sufficient size to hold any conceivable resolution and color depth, are aligned on a power-of-two boundary, and are a power-of-two in size. An example high-end assumption would be a 2048×2048×32 bpp display. This requires apertures of 16 MB, which means that the aperture offset can be contained in 24 bits. Since there is no actual memory associated with these apertures, the exemplary 16 MB requirement simply represents physical regions of memory space that are reserved.  
         [0050]     The aforementioned 14 registers are:  
         [0051]     Memory Base Address: 32-bits (32-bits populated; unsigned)—The base address of the physical memory area that is actually accessed. This value is added to the result of the address offset translation to obtain “memory address”.  
         [0052]     Depth Mask: 32-bits (2-bits populated; unsigned)—The bit mask used to remove the least significant bits of an address before an address translation, and to restore the same bits after the translation. This is done to provide single byte accesses to multi-byte pixel formats. The register will be programmed with a value of 0xFFFFFFFF for 8-bit pixels, 0xFFFFFFFE for 16-bit pixels, and 0xFFFFFFFC for 32-bit pixels.  
         [0053]     (Four) Shift: 16-bits (6-bits populated; signed)—The values (shift0, shift1, shift2 and shift3) in these registers specify the right shift for the first step of each of the four portions of the address translation. If the value is negative, the shift is to the left. Bits shifted out of the value are lost. Bits shifted into the value are set to 0.  
         [0054]     (Four) Minuend: 32-bits (24-bits populated; unsigned)—YThe values (minuend0, minuend1, minuend2 and minuend3) in these registers are used to invert selected bits in the second step of each of the four portions of the address translation.  
         [0055]     (Four) Mask: 32-bits (24-bits populated; unsigned)—The values (mask0, mask1, mask2 and mask3) in these registers are used to mask off selected bits in the third step of each of the four portions of the address translation.  
         [0056]     Some embodiments complete the address translations in a single memory access cycle, implementing the translations with combinational logic. The translations in such embodiments can be accomplished through parallelization of the four portions of the memory offset equations so that each translation occurs quickly enough to avoid the addition of any extra cycles to a memory access.  
         [0057]     Combinational logic can reduce power efficiency due to unnecessary changes in intermediate states. Some embodiments address power efficiency as follows. First, the address translations are active only when the associated aperture is being accessed. Second, intermediate values within the latter stages of the translation can be eliminated while the early changes are processing. A suitable internal propagation compensation can prohibit changes in later stages until the earlier stages have settled.  
         [0058]      FIG. 1  diagrammatically illustrates exemplary embodiments of a data processing apparatus according to the invention. The apparatus of  FIG. 1  can be, for example, a palmtop computer, a personal digital assistant, a laptop computer, a notebook computer, or a desktop computer. As illustrated in  FIG. 1 , both the operating system/user applications and the display controller access the memory  11  directly or through translation logic ( 15 ,  19 ) which implements the address translation operations described in detail above. Aperture logic  13  receives the access address from the operating system/applications and determines whether the access address should be translated by the translator  15  or applied directly to the memory  11 . Similarly, aperture logic  17  determines whether the access address provided by the display controller should be translated by translator  19  or applied directly to the memory  11 . A user interface  18  permits a user to communicate (e.g., by keyboard, mouse, etc.) with the operating system/user applications, which can run, for example, on a microprocessor, microcontroller or digital signal processor. The display controller drives a display  20  which provides a visual display to the user. A bus  40  supports data transfers to/from the memory  11 .  
         [0059]     The aperture logic  13  controls a switch  23  to invoke the translator  15  whenever the access address on the bus  33  falls within the aperture implemented by aperture logic  13 . Similarly, the aperture logic  17  controls a switch  27  to invoke translator  19  whenever the access address on bus  37  is within the aperture implemented by aperture logic  17 .  
         [0060]      FIG. 1A  diagrammatically illustrates exemplary embodiments of the translator logic ( 15  or  19 ) of  FIG. 1 . As illustrated in  FIG. 1A , logic  111 , (for example combinational logic) receives inputs from the registers described above, and also receives the access address. The logic  111  combines this input information, for example in the manner described in detail above, to produce the desired memory address for accessing memory  11 .  
         [0061]     Although exemplary embodiments of the invention are described above in detail, this does not limit the scope of the invention, which can be practiced in a variety of embodiments.