US20050128206A1 - Method and apparatus for reducing frame buffer size in graphics systems - Google Patents

Method and apparatus for reducing frame buffer size in graphics systems Download PDF

Info

Publication number
US20050128206A1
US20050128206A1 US10/732,083 US73208303A US2005128206A1 US 20050128206 A1 US20050128206 A1 US 20050128206A1 US 73208303 A US73208303 A US 73208303A US 2005128206 A1 US2005128206 A1 US 2005128206A1
Authority
US
United States
Prior art keywords
screen
section
rendering command
command list
polygons
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/732,083
Other versions
US6911985B1 (en
Inventor
Shinya Fujimoto
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Avago Technologies International Sales Pte Ltd
Original Assignee
LSI Logic Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LSI Logic Corp filed Critical LSI Logic Corp
Priority to US10/732,083 priority Critical patent/US6911985B1/en
Assigned to LSI LOGIC CORPORATION reassignment LSI LOGIC CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FUJIMOTO, SHINYA
Publication of US20050128206A1 publication Critical patent/US20050128206A1/en
Application granted granted Critical
Publication of US6911985B1 publication Critical patent/US6911985B1/en
Assigned to DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT reassignment DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: AGERE SYSTEMS LLC, LSI CORPORATION
Assigned to LSI CORPORATION reassignment LSI CORPORATION CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: LSI LOGIC CORPORATION
Assigned to AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. reassignment AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LSI CORPORATION
Assigned to LSI CORPORATION, AGERE SYSTEMS LLC reassignment LSI CORPORATION TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031) Assignors: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT PATENT SECURITY AGREEMENT Assignors: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.
Assigned to AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. reassignment AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD. TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS Assignors: BANK OF AMERICA, N.A., AS COLLATERAL AGENT
Assigned to AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITED reassignment AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITED MERGER (SEE DOCUMENT FOR DETAILS). Assignors: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.
Assigned to AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITED reassignment AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITED CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE PREVIOUSLY RECORDED AT REEL: 047196 FRAME: 0097. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER. Assignors: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/003D [Three Dimensional] image rendering
    • G06T15/005General purpose rendering architectures
    • GPHYSICS
    • G09EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09GARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/36Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of a graphic pattern, e.g. using an all-points-addressable [APA] memory
    • G09G5/39Control of the bit-mapped memory
    • G09G5/393Arrangements for updating the contents of the bit-mapped memory

Definitions

  • This invention relates generally to graphics systems, and particularly to a method and apparatus for reducing the frame buffer size in a graphics system.
  • a large amount of memory is required to hold the display information for what is currently being displayed on the screen and separate information for the next frame.
  • the frame buffer size is critical for the performance of a 3D graphics system as loading and unloading textures from the main memory may take a very long time. Therefore, it is desirable to provide as much free space in the frame buffer as possible in order to store textures and CLUTs (color lookup tables).
  • a large frame buffer may directly affect the cost and power consumption of the system which are both critical factors to consider in a mobile electronics system such as PDAs (personal digital assistants), cell phones, mobile gaming systems, and the like.
  • CLUTs are used to reduce the size of textures. Instead of using the full 16 bits to represent the texture pixel data, a look up table may be used to assign colors that are going to be used for textures. This may reduce the maximum number of colors that can be used in a single texture and may also dramatically reduce the amount of memory needed for textures. However, CLUTs may not change the fact that there need be separate memory space for display and drawing regions in a frame buffer.
  • Tile based algorithms may also be used in some graphics systems to reduce the display and drawing region size. This method divides the screen into multiple tiles and draws only the pixels that fall into the working tile. Although tile based algorithms work well to reduce the memory size, it may also introduce a lot of inefficiencies because the GPU (graphics processing unit) may need to traverse through the list of drawing commands for the whole screen as many times as the number of tiles defined.
  • the present invention is directed to a method and apparatus for reducing the frame buffer size in a 3D graphics system.
  • sorting and limiting the polygons such as triangles and the like that get processed at a given time may reduce the size of the frame buffer required in a graphics system. This may allow the system to process only those polygons that fall in one section of the screen. As a result, the system may not need to double buffer the whole screen.
  • the location of the screen that gets processed may be arbitrary but should be preferably chosen so it is easy to sort the polygons and time-manage the process as the system needs to know when to swap from one location to another.
  • FIG. 1 is a schematic block diagram illustrating an exemplary 3 D graphics system in which the present invention may be implemented
  • FIG. 2 shows the content of an exemplary frame buffer
  • FIG. 3 shows a flow chart illustrating an exemplary method for reducing the frame buffer size in a graphics system in accordance with the present invention
  • FIG. 4 shows an exemplary sequence of steps involved in the method shown in FIG. 3 , where a first section of the screen is the top half of the screen and a second section of the screen is the bottom half of the screen;
  • FIG. 5 shows the content of an exemplary frame buffer with a reduced memory size in accordance with an exemplary embodiment of the present invention.
  • FIG. 1 is a schematic block diagram illustrating an exemplary 3 D graphics system 100 in which the present invention may be implemented.
  • the graphics system 100 includes media 102 , a central processing unit (CPU) 104 communicatively coupled to a main memory 106 , a graphics processing unit (GPU) 108 communicatively coupled to a frame buffer 110 residing in a dedicated video memory, and a display controller or display processor 112 communicatively coupled to both the frame buffer 110 and a display device 114 such as a TV, LCD (liquid crystal display), and the like.
  • the graphics system 100 may read data from the media 102 and display the corresponding 3 D graphics on the display device 114 .
  • an object is typically drawn using numerous polygons such as triangles, and the like.
  • a basic flow of operations in the graphics system 100 is shown as follows.
  • the CPU 104 prepares a list of GPU rendering commands (or rendering commands) in the main memory 106 .
  • the GPU 108 reads the rendering commands from the main memory 106 .
  • the GPU 108 then decodes the rendering commands and draws pixel data to the frame buffer 110 .
  • the display controller 112 reads pixel data that gets displayed on the screen from the frame buffer 110 . After each line gets drawn, a typical implementation of the display controller 112 generates a status signal allowing the CPU 104 or GPU 108 to synchronize its processing with the display controller 112 .
  • This status signal is commonly referred to as horizontal synchronization (HSYNC) signal.
  • HSYNC horizontal synchronization
  • VSYNC vertical synchronization
  • This VSYNC signal allows the CPU 104 and GPU 108 to know when to start drawing the next frame data.
  • the GPU 108 When the GPU 108 processes the rendering commands and generates the pixels to be drawn, the GPU 108 stores the pixel data in the frame buffer 110 which typically resides in a dedicated video memory. In order for the GPU 108 to store pixel data for the next frame while the display controller 112 reads data out from the frame buffer 110 , a technique called double buffering is used.
  • the double buffering mechanism reserves two frames worth of memory space in the frame buffer 110 so that the data that are displayed on the screen through the display controller 112 may be held mutual exclusive to the memory location used by the GPU 108 to store the calculated results.
  • the memory region that is read by the display controller 112 is often called a display region, and the region that the GPU 108 used to store the data for the next frame is referred to as a drawing region (see, e.g., FIGS. 2 and 5 ).
  • the VSYNC signal from the display processor 112 is used to trigger both the CPU 104 and GPU 108 to swap the display and drawing regions.
  • FIG. 2 shows the content of a typical frame buffer 200 .
  • the frame buffer 200 may include a texture area 202 for storing texture, a display region 204 for displaying a current frame, a drawing region 206 for drawing the next frame, and a CLUT area 208 for storing CLUTs.
  • the frame buffer size is roughly 1 MB (megabytes).
  • the following calculations show a typical memory usage of the frame buffer in this system:
  • the frame buffer size is critical for the performance of a 3D graphics system as loading and unloading textures from the main memory usually takes a very long time. Therefore, it is desirable to have as much free space in the frame buffer as possible to store textures and CLUTs. On the other hand, a large frame buffer may directly affect the cost and power consumption of the system, which are both critical factors to consider in a mobile electronics system such as PDAs, cell phones, mobile gaming systems, and the like.
  • the present invention may reduce the size of the frame buffer required in a 3D graphics system by eliminating the need of storing two full frame worth of data in the frame buffer to perform double buffering.
  • the graphics system only needs to process those triangles that fall in particular section of the screen.
  • the location of the screen that gets processed should be chosen so that it is easy to manage the sorting and processing of the rendering commands.
  • the rendering commands may be sorted based on whether the polygon falls in the top half or the bottom half of the screen. Once the rendering commands are sorted, the GPU may draw half of the screen while the display controller reads and displays the other half of the screen. Presorting triangles to sub-frame level and restricting which of them gets drawn based on the current display activity is an advantageous feature compared to a typical 3D graphics system known in the art.
  • FIG. 3 shows a flow chart illustrating an exemplary method 300 for reducing the frame buffer size in a graphics system in accordance with the present invention.
  • the method or process 300 may be implemented in the graphics system 100 shown in FIG. 1 .
  • the method or process 300 may start with a step 302 in which a CPU generates two lists of GPU rendering commands (or rendering commands) in the main memory for the next frame to be drawn: a first rendering command list (or a first list) is for a first section of the screen, and a second rendering command list (or a second list) is for a second section of the screen.
  • the first section may be the top half of the screen
  • the second section may be the bottom half of the screen.
  • the first section may be the bottom half of the screen, and the second section may be the top half of the screen.
  • the first section may be the top 1 ⁇ 3 of the screen, and the second section may be the rest of the screen. It is understood that the location of the section on the screen may be selected as contemplated by a person of ordinary skill in the art without departing from the scope and spirit of the present invention.
  • the CPU may also sort polygons such as triangles and the like of next frame based upon the location of the polygons on the screen.
  • the CPU may check whether the polygon's top and bottom vertices fall in the first section of the screen or the second section of the screen and may then add the command to a corresponding list. For example, if a triangle's top and bottom vertices fall in the first section of the screen, the CPU may add the corresponding rendering command to the first list. If the polygon crosses the boundary between the first section and the second section of the screen, the CPU may add the corresponding rendering command to both the first list and the second list.
  • a third rendering command list for the second section of the screen of the current frame may be provided.
  • the third list may be saved from the previous iteration (see step 312 below).
  • step 306 when the display controller asserts the vertical synchronization (VSYNC) signal, the display controller may read the pixel data from the display region of the frame buffer to display the first section of the screen of the current frame, and, preferably simultaneously, GPU may fetch rendering commands from the third rendering command list and draw the pixels for the second section of the screen in the frame buffer to complete the full picture of the current frame.
  • VSYNC vertical synchronization
  • step 308 when the display controller completes displaying the first section of the screen of the current frame, the display controller may signal GPU to swap the display and drawing regions. Then, in step 310 , the CPU may discard the third list and initiate the GPU to start processing the rendering commands in the first list to draw pixels for the first section of the next frame into the frame buffer, and, preferably simultaneously, the display controller may start reading pixel data for the second section of the screen for the current frame. In a preferred embodiment, the CPU needs to complete creating the first and second rendering command lists for the next frame before the steps 308 and 310 in order to be able to process all rendering commands properly.
  • step 312 when the GPU completes drawing all polygons in the first list, the CPU may discard the first list and rename the second list as the third list, and the process 300 may then return to the step 302 .
  • the CPU may discard the first list and rename the second list as the third list, and the process 300 may then return to the step 302 .
  • renaming the second list as the third list does not physically have to take place.
  • the first list may be processed by the GPU and is thrown away as it is finished. Then the GPU moves on to process the next list.
  • the CPU may add more lists to the FIFO as the FIFO becomes ready.
  • the process 300 may return to the step 302 for the CPU to start generating rendering command lists for the next frame without waiting for the GPU to complete drawing all polygons in the first list.
  • the CPU may not corrupt the first list that GPU is working on and need save the third list that the GPU has not worked on yet.
  • FIG. 4 shows an exemplary sequence of steps involved in the process 300 shown in FIG. 3 , where a first section of the screen is the top half of the screen and a second section of the screen is the bottom half of the screen.
  • FIG. 5 shows the content of an exemplary frame buffer 500 with a reduced memory size in accordance with an exemplary embodiment of the present invention.
  • the frame buffer 500 may include a texture area 502 for storing texture, a display region 504 for displaying a current frame Frame X, a drawing region 506 for drawing the next frame Frame X+1, and a CLUT area 508 for storing a CLUT.
  • the size of the frame buffer 400 is reduced to one half ( ⁇ fraction (1/2) ⁇ ). It is understood that although the bottom half of the screen is used for displaying a current frame and the top half of the screen is used for drawing the next frame, they are not necessarily so.
  • the top half of the screen may be used to display the current frame and the bottom half of the screen may be used to draw the next frame.
  • the section of the screen used to display the current frame and the section of the screen used to draw the next frame may be selected as contemplated by a person of ordinary skill in the art without departing from the scope and spirit of the present invention.
  • Such a software package may be a computer program product which employs a storage medium including stored computer code which is used to program a computer to perform the disclosed function and process of the present invention.
  • the storage medium may include, but is not limited to, any type of conventional floppy disks, optical disks, CD-ROMS, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any other suitable media for storing electronic instructions.

Abstract

The present invention is directed to a method and apparatus for reducing the frame buffer size in a 3D graphics system. According to an exemplary aspect of the present invention, sorting and limiting the polygons that get processed at a given time may reduce the size of the frame buffer required in a graphics system. This may allow the system to process only those polygons that fall in one section of the screen. As a result, the system may not need to double buffer the whole screen. In a preferred embodiment, the location of the screen that gets processed may be arbitrary but should be preferably chosen so it is easy to sort the polygons and time-manage the process as the system needs to know when to swap from one location to another.

Description

    FIELD OF THE INVENTION
  • This invention relates generally to graphics systems, and particularly to a method and apparatus for reducing the frame buffer size in a graphics system.
  • BACKGROUND OF THE INVENTION
  • In a 3D graphics system, typically a large amount of memory is required to hold the display information for what is currently being displayed on the screen and separate information for the next frame. For example, in a system with graphics resolution of 320×240 at 16 bits/pixel, at least 153 KB of memory is required to hold the current frame and another 153 KB of memory is required for the next frame that gets processed while the current screen is being displayed. The frame buffer size is critical for the performance of a 3D graphics system as loading and unloading textures from the main memory may take a very long time. Therefore, it is desirable to provide as much free space in the frame buffer as possible in order to store textures and CLUTs (color lookup tables). On the other hand, a large frame buffer may directly affect the cost and power consumption of the system which are both critical factors to consider in a mobile electronics system such as PDAs (personal digital assistants), cell phones, mobile gaming systems, and the like.
  • Conventionally, CLUTs are used to reduce the size of textures. Instead of using the full 16 bits to represent the texture pixel data, a look up table may be used to assign colors that are going to be used for textures. This may reduce the maximum number of colors that can be used in a single texture and may also dramatically reduce the amount of memory needed for textures. However, CLUTs may not change the fact that there need be separate memory space for display and drawing regions in a frame buffer.
  • Tile based algorithms may also be used in some graphics systems to reduce the display and drawing region size. This method divides the screen into multiple tiles and draws only the pixels that fall into the working tile. Although tile based algorithms work well to reduce the memory size, it may also introduce a lot of inefficiencies because the GPU (graphics processing unit) may need to traverse through the list of drawing commands for the whole screen as many times as the number of tiles defined.
  • Thus, it would be desirable to provide a method and apparatus for efficiently reducing the frame buffer size in a graphics system.
  • SUMMARY OF THE INVENTION
  • The present invention is directed to a method and apparatus for reducing the frame buffer size in a 3D graphics system. According to an exemplary aspect of the present invention, sorting and limiting the polygons such as triangles and the like that get processed at a given time may reduce the size of the frame buffer required in a graphics system. This may allow the system to process only those polygons that fall in one section of the screen. As a result, the system may not need to double buffer the whole screen.
  • In a preferred embodiment, the location of the screen that gets processed may be arbitrary but should be preferably chosen so it is easy to sort the polygons and time-manage the process as the system needs to know when to swap from one location to another.
  • It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed. The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate an embodiment of the invention and together with the general description, serve to explain the principles of the invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The numerous advantages of the present invention may be better understood by those skilled in the art by reference to the accompanying figures in which:
  • FIG. 1 is a schematic block diagram illustrating an exemplary 3D graphics system in which the present invention may be implemented;
  • FIG. 2 shows the content of an exemplary frame buffer;
  • FIG. 3 shows a flow chart illustrating an exemplary method for reducing the frame buffer size in a graphics system in accordance with the present invention;
  • FIG. 4 shows an exemplary sequence of steps involved in the method shown in FIG. 3, where a first section of the screen is the top half of the screen and a second section of the screen is the bottom half of the screen; and
  • FIG. 5 shows the content of an exemplary frame buffer with a reduced memory size in accordance with an exemplary embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • Reference will now be made in detail to the presently preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings.
  • FIG. 1 is a schematic block diagram illustrating an exemplary 3 D graphics system 100 in which the present invention may be implemented. The graphics system 100 includes media 102, a central processing unit (CPU) 104 communicatively coupled to a main memory 106, a graphics processing unit (GPU) 108 communicatively coupled to a frame buffer 110 residing in a dedicated video memory, and a display controller or display processor 112 communicatively coupled to both the frame buffer 110 and a display device 114 such as a TV, LCD (liquid crystal display), and the like. The graphics system 100 may read data from the media 102 and display the corresponding 3D graphics on the display device 114.
  • In the 3D graphics systems, an object is typically drawn using numerous polygons such as triangles, and the like. A basic flow of operations in the graphics system 100 is shown as follows. The CPU 104 prepares a list of GPU rendering commands (or rendering commands) in the main memory 106. The GPU 108 reads the rendering commands from the main memory 106. The GPU 108 then decodes the rendering commands and draws pixel data to the frame buffer 110. The display controller 112 reads pixel data that gets displayed on the screen from the frame buffer 110. After each line gets drawn, a typical implementation of the display controller 112 generates a status signal allowing the CPU 104 or GPU 108 to synchronize its processing with the display controller 112. This status signal is commonly referred to as horizontal synchronization (HSYNC) signal. Similarly, there is a vertical synchronization (VSYNC) signal that the display controller 112 asserts when the display controller 112 has finished displaying the full screen. This VSYNC signal allows the CPU 104 and GPU 108 to know when to start drawing the next frame data.
  • When the GPU 108 processes the rendering commands and generates the pixels to be drawn, the GPU 108 stores the pixel data in the frame buffer 110 which typically resides in a dedicated video memory. In order for the GPU 108 to store pixel data for the next frame while the display controller 112 reads data out from the frame buffer 110, a technique called double buffering is used. The double buffering mechanism reserves two frames worth of memory space in the frame buffer 110 so that the data that are displayed on the screen through the display controller 112 may be held mutual exclusive to the memory location used by the GPU 108 to store the calculated results. The memory region that is read by the display controller 112 is often called a display region, and the region that the GPU 108 used to store the data for the next frame is referred to as a drawing region (see, e.g., FIGS. 2 and 5). The VSYNC signal from the display processor 112 is used to trigger both the CPU 104 and GPU 108 to swap the display and drawing regions.
  • FIG. 2 shows the content of a typical frame buffer 200. As shown, the frame buffer 200 may include a texture area 202 for storing texture, a display region 204 for displaying a current frame, a drawing region 206 for drawing the next frame, and a CLUT area 208 for storing CLUTs.
  • In a typical 32-bit generation game system such as Sony's PlayStation and the like, the frame buffer size is roughly 1 MB (megabytes). The following calculations show a typical memory usage of the frame buffer in this system:
      • 320×240 display resolution @ 16 bits per pixel=320×240×16 bits=1,228,800 bits=153,600 bytes=153 KB/frame
      • 2 frames stored in the frame buffer, so 153 KB×2≅300 KB out of 1 MB used for display and drawing regions
      • so 700 KB is left for CLUTs and textures
  • The frame buffer size is critical for the performance of a 3D graphics system as loading and unloading textures from the main memory usually takes a very long time. Therefore, it is desirable to have as much free space in the frame buffer as possible to store textures and CLUTs. On the other hand, a large frame buffer may directly affect the cost and power consumption of the system, which are both critical factors to consider in a mobile electronics system such as PDAs, cell phones, mobile gaming systems, and the like.
  • The present invention may reduce the size of the frame buffer required in a 3D graphics system by eliminating the need of storing two full frame worth of data in the frame buffer to perform double buffering. By sorting the rendering commands based upon the location of a triangle ahead of time, the graphics system only needs to process those triangles that fall in particular section of the screen. In a preferred embodiment, the location of the screen that gets processed should be chosen so that it is easy to manage the sorting and processing of the rendering commands. For example, the rendering commands may be sorted based on whether the polygon falls in the top half or the bottom half of the screen. Once the rendering commands are sorted, the GPU may draw half of the screen while the display controller reads and displays the other half of the screen. Presorting triangles to sub-frame level and restricting which of them gets drawn based on the current display activity is an advantageous feature compared to a typical 3D graphics system known in the art.
  • FIG. 3 shows a flow chart illustrating an exemplary method 300 for reducing the frame buffer size in a graphics system in accordance with the present invention. The method or process 300 may be implemented in the graphics system 100 shown in FIG. 1. As shown in FIG. 3, the method or process 300 may start with a step 302 in which a CPU generates two lists of GPU rendering commands (or rendering commands) in the main memory for the next frame to be drawn: a first rendering command list (or a first list) is for a first section of the screen, and a second rendering command list (or a second list) is for a second section of the screen. In a preferred embodiment, the first section may be the top half of the screen, and the second section may be the bottom half of the screen. Alternatively, the first section may be the bottom half of the screen, and the second section may be the top half of the screen. In a further embodiment, the first section may be the top ⅓ of the screen, and the second section may be the rest of the screen. It is understood that the location of the section on the screen may be selected as contemplated by a person of ordinary skill in the art without departing from the scope and spirit of the present invention. In the step 302, the CPU may also sort polygons such as triangles and the like of next frame based upon the location of the polygons on the screen. In a preferred embodiment, for each rendering command that the CPU generates, the CPU may check whether the polygon's top and bottom vertices fall in the first section of the screen or the second section of the screen and may then add the command to a corresponding list. For example, if a triangle's top and bottom vertices fall in the first section of the screen, the CPU may add the corresponding rendering command to the first list. If the polygon crosses the boundary between the first section and the second section of the screen, the CPU may add the corresponding rendering command to both the first list and the second list.
  • In step 304, a third rendering command list for the second section of the screen of the current frame may be provided. For example, the third list may be saved from the previous iteration (see step 312 below).
  • In step 306, when the display controller asserts the vertical synchronization (VSYNC) signal, the display controller may read the pixel data from the display region of the frame buffer to display the first section of the screen of the current frame, and, preferably simultaneously, GPU may fetch rendering commands from the third rendering command list and draw the pixels for the second section of the screen in the frame buffer to complete the full picture of the current frame.
  • Next, in step 308, when the display controller completes displaying the first section of the screen of the current frame, the display controller may signal GPU to swap the display and drawing regions. Then, in step 310, the CPU may discard the third list and initiate the GPU to start processing the rendering commands in the first list to draw pixels for the first section of the next frame into the frame buffer, and, preferably simultaneously, the display controller may start reading pixel data for the second section of the screen for the current frame. In a preferred embodiment, the CPU needs to complete creating the first and second rendering command lists for the next frame before the steps 308 and 310 in order to be able to process all rendering commands properly.
  • Next, in step 312, when the GPU completes drawing all polygons in the first list, the CPU may discard the first list and rename the second list as the third list, and the process 300 may then return to the step 302. Those of ordinary skill in the art will understand that renaming the second list as the third list does not physically have to take place. In other words, in a preferred embodiment, there are always three lists in FIFO. The first list may be processed by the GPU and is thrown away as it is finished. Then the GPU moves on to process the next list. The CPU may add more lists to the FIFO as the FIFO becomes ready. Alternatively, in the step 312, the process 300 may return to the step 302 for the CPU to start generating rendering command lists for the next frame without waiting for the GPU to complete drawing all polygons in the first list. In this case, preferably, the CPU may not corrupt the first list that GPU is working on and need save the third list that the GPU has not worked on yet.
  • FIG. 4 shows an exemplary sequence of steps involved in the process 300 shown in FIG. 3, where a first section of the screen is the top half of the screen and a second section of the screen is the bottom half of the screen.
  • FIG. 5 shows the content of an exemplary frame buffer 500 with a reduced memory size in accordance with an exemplary embodiment of the present invention. As shown, the frame buffer 500 may include a texture area 502 for storing texture, a display region 504 for displaying a current frame Frame X, a drawing region 506 for drawing the next frame Frame X+1, and a CLUT area 508 for storing a CLUT. In comparison with the frame buffer 202 shown in FIG. 2, the size of the frame buffer 400 is reduced to one half ({fraction (1/2)}). It is understood that although the bottom half of the screen is used for displaying a current frame and the top half of the screen is used for drawing the next frame, they are not necessarily so. For example, the top half of the screen may be used to display the current frame and the bottom half of the screen may be used to draw the next frame. The section of the screen used to display the current frame and the section of the screen used to draw the next frame may be selected as contemplated by a person of ordinary skill in the art without departing from the scope and spirit of the present invention.
  • It is to be noted that the foregoing described embodiments according to the present invention may be conveniently implemented using conventional general purpose digital computers programmed according to the teachings of the present specification, as will be apparent to those skilled in the computer art. Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
  • It is to be understood that the present invention may be conveniently implemented in forms of software package. Such a software package may be a computer program product which employs a storage medium including stored computer code which is used to program a computer to perform the disclosed function and process of the present invention. The storage medium may include, but is not limited to, any type of conventional floppy disks, optical disks, CD-ROMS, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any other suitable media for storing electronic instructions.
  • It is understood that the specific order or hierarchy of steps in the processes disclosed is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present invention. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
  • It is believed that the present invention and many of its attendant advantages will be understood by the foregoing description. It is also believed that it will be apparent that various changes may be made in the form, construction and arrangement of the components thereof without departing from the scope and spirit of the invention or without sacrificing all of its material advantages. The form herein before described being merely an explanatory embodiment thereof, it is the intention of the following claims to encompass and include such changes.

Claims (22)

1. A method for reducing a frame buffer size in a graphics system, comprising steps of:
(a) generating a first rendering command list and a second rendering command list for a next frame, said first rendering command list for a first section of a screen and said second rendering command list for a second section of said screen;
(b) sorting polygons of said next frame based upon locations of said polygons on said screen;
(c) providing a third rendering command list for said second section of said screen for a current frame;
(d) when a VSYNC signal is asserted, reading pixel data from a display region of a frame buffer to display said first section of said screen for said current frame, fetching rendering commands from said third rendering command list, and drawing pixels for said second section of said screen in said frame buffer to complete a full picture of said current frame;
(e) when said displaying said first section of said screen for said current frame is completed, signaling a GPU to swap said display region and a drawing region of said frame buffer; and
(f) discarding said third rendering command list, processing rendering commands in said first rendering command list to draw pixels for said first section of said screen for said next frame into said frame buffer, and reading pixel data for said second section of said screen for said current frame.
2. The method of claim 1, wherein said first section of said screen is a top half of said screen and said second section of said screen is a bottom half of said screen.
3. The method of claim 1, wherein said first section of said screen is a bottom half of said screen and said second section of said screen is a top half of said screen.
4. The method of claim 1, wherein said step (b) comprising when top and bottom vertices of one of said polygons fall in one of said first section and said second section, adding a rendering command corresponding to said one of said polygons to a corresponding list for said one of said first section and said second section.
5. The method of claim 1, wherein said step (b) comprising when one of said polygons crosses a boundary between said first section and said second section, adding a rendering command corresponding to said one of said polygons to both said first rendering command list and said second rendering command list.
6. The method of claim 1, further comprising:
when said GPU completes drawing all polygons in said first rendering command list, discarding said first rendering command list, renaming said second rendering command list as said third rendering command list, and returning to said step (a).
7. The method of claim 1, further comprising:
returning to said step (a) without waiting for said GPU to complete drawing all polygons in said first rendering command list.
8. The method of claim 7, further comprising keeping integrity of said first rendering command list that said GPU is working on and saving said third rendering command list that said GPU has not worked on yet.
9. An apparatus for reducing a frame buffer size in a graphics system, comprising:
(a) means for generating a first rendering command list and a second rendering command list for a next frame, said first rendering command list for a first section of a screen and said second rendering command list for a second section of said screen;
(b) means for sorting polygons of said next frame based upon locations of said polygons on said screen;
(c) means for providing a third rendering command list for said second section of said screen for a current frame;
(d) when a VSYNC signal is asserted, means for reading pixel data from a display region of a frame buffer to display said first section of said screen for said current frame, means for fetching rendering commands from said third rendering command list, and means for drawing pixels for said second section of said screen in said frame buffer to complete a full picture of said current frame;
(e) when said displaying said first section of said screen for said current frame is completed, means for signaling a GPU to swap said display region and a drawing region of said frame buffer; and
(f) means for discarding said third rendering command list, means for processing rendering commands in said first rendering command list to draw pixels for said first section of said screen for said next frame into said frame buffer, and means for reading pixel data for said second section of said screen for said current frame.
10. The apparatus of claim 9, wherein said first section of said screen is a top half of said screen and said second section of said screen is a bottom half of said screen.
11. The apparatus of claim 9, wherein said first section of said screen is a bottom half of said screen and said second section of said screen is a top half of said screen.
12. The apparatus of claim 9, wherein said means for sorting (b) comprising when top and bottom vertices of one of said polygons fall in one of said first section and said second section, means for adding a rendering command corresponding to said one of said polygons to a corresponding list for said one of said first section and said second section.
13. The apparatus of claim 9, wherein said means for sorting (b) comprising when one of said polygons crosses a boundary between said first section and said second section, means for adding a rendering command corresponding to said one of said polygons to both said first rendering command list and said second rendering command list.
14. The apparatus of claim 9, further comprising:
when said GPU completes drawing all polygons in said first rendering command list, means for discarding said first rendering command list and means for renaming said second rendering command list as said third rendering command list.
15. A computer-readable medium having computer-executable instructions for performing a method for reducing a frame buffer size in a graphics system, said method comprising steps of:
(a) generating a first rendering command list and a second rendering command list for a next frame, said first rendering command list for a first section of a screen and said second rendering command list for a second section of said screen;
(b) sorting polygons of said next frame based upon locations of said polygons on said screen;
(c) providing a third rendering command list for said second section of said screen for a current frame;
(d) when a VSYNC signal is asserted, reading pixel data from a display region of a frame buffer to display said first section of said screen for said current frame, fetching rendering commands from said third rendering command list, and drawing pixels for said second section of said screen in said frame buffer to complete a full picture of said current frame;
(e) when said displaying said first section of said screen for said current frame is completed, signaling a GPU to swap said display region and a drawing region of said frame buffer; and
(f) discarding said third rendering command list, processing rendering commands in said first rendering command list to draw pixels for said first section of said screen for said next frame into said frame buffer, and reading pixel data for said second section of said screen for said current frame.
16. The computer-readable medium of claim 15, wherein said first section of said screen is a top half of said screen and said second section of said screen is a bottom half of said screen.
17. The computer-readable medium of claim 15, wherein said first section of said screen is a bottom half of said screen and said second section of said screen is a top half of said screen.
18. The computer-readable medium of claim 15, wherein said step (b) comprising when top and bottom vertices of one of said polygons fall in one of said first section and said second section, adding a rendering command corresponding to said one of said polygons to a corresponding list for said one of said first section and said second section.
19. The computer-readable medium of claim 15, wherein said step (b) comprising when one of said polygons crosses a boundary between said first section and said second section, adding a rendering command corresponding to said one of said polygons to both said first rendering command list and said second rendering command list.
20. The computer-readable medium of claim 15, wherein said method further comprising:
when said GPU completes drawing all polygons in said first rendering command list, discarding said first rendering command list, renaming said second rendering command list as said third rendering command list, and returning to said step (a).
21. The computer-readable medium of claim 15, wherein said method further comprising:
returning to said step (a) without waiting for said GPU to complete drawing all polygons in said first rendering command list.
22. The computer-readable medium of claim 21, wherein said method further comprising keeping integrity of said first rendering command list that said GPU is working on and saving said third rendering command list that said GPU has not worked on yet.
US10/732,083 2003-12-10 2003-12-10 Method and apparatus for reducing frame buffer size in graphics systems Expired - Lifetime US6911985B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/732,083 US6911985B1 (en) 2003-12-10 2003-12-10 Method and apparatus for reducing frame buffer size in graphics systems

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/732,083 US6911985B1 (en) 2003-12-10 2003-12-10 Method and apparatus for reducing frame buffer size in graphics systems

Publications (2)

Publication Number Publication Date
US20050128206A1 true US20050128206A1 (en) 2005-06-16
US6911985B1 US6911985B1 (en) 2005-06-28

Family

ID=34652810

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/732,083 Expired - Lifetime US6911985B1 (en) 2003-12-10 2003-12-10 Method and apparatus for reducing frame buffer size in graphics systems

Country Status (1)

Country Link
US (1) US6911985B1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070115290A1 (en) * 2005-11-23 2007-05-24 Advanced Micro Devices, Inc. Integrating display controller into low power processor
US20100079445A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Method for reducing graphics rendering failures
US20120206461A1 (en) * 2011-02-10 2012-08-16 David Wyatt Method and apparatus for controlling a self-refreshing display device coupled to a graphics controller
US20150235341A1 (en) * 2014-02-18 2015-08-20 Qualcomm Incorporated Shader pipeline with shared data channels
CN109887065A (en) * 2019-02-11 2019-06-14 京东方科技集团股份有限公司 Image rendering method and its device

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0524804D0 (en) 2005-12-05 2006-01-11 Falanx Microsystems As Method of and apparatus for processing graphics
US9965886B2 (en) * 2006-12-04 2018-05-08 Arm Norway As Method of and apparatus for processing graphics
GB0900700D0 (en) * 2009-01-15 2009-03-04 Advanced Risc Mach Ltd Methods of and apparatus for processing graphics
US8823719B2 (en) * 2010-05-13 2014-09-02 Mediatek Inc. Graphics processing method applied to a plurality of buffers and graphics processing apparatus thereof
US9317948B2 (en) 2012-11-16 2016-04-19 Arm Limited Method of and apparatus for processing graphics
US10204391B2 (en) 2013-06-04 2019-02-12 Arm Limited Method of and apparatus for processing graphics
GB2553744B (en) 2016-04-29 2018-09-05 Advanced Risc Mach Ltd Graphics processing systems
KR20180067220A (en) * 2016-12-12 2018-06-20 삼성전자주식회사 Method and apparatus for processing motion based image

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5450544A (en) * 1992-06-19 1995-09-12 Intel Corporation Method and apparatus for data buffering and queue management of digital motion video signals
US5617113A (en) * 1994-09-29 1997-04-01 In Focus Systems, Inc. Memory configuration for display information
US6498606B1 (en) * 1999-06-29 2002-12-24 Koninklijke Philips Electronics N.V. Z-buffering graphics system
US6734873B1 (en) * 2000-07-21 2004-05-11 Viewpoint Corporation Method and system for displaying a composited image

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5450544A (en) * 1992-06-19 1995-09-12 Intel Corporation Method and apparatus for data buffering and queue management of digital motion video signals
US5617113A (en) * 1994-09-29 1997-04-01 In Focus Systems, Inc. Memory configuration for display information
US6498606B1 (en) * 1999-06-29 2002-12-24 Koninklijke Philips Electronics N.V. Z-buffering graphics system
US6734873B1 (en) * 2000-07-21 2004-05-11 Viewpoint Corporation Method and system for displaying a composited image

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070115290A1 (en) * 2005-11-23 2007-05-24 Advanced Micro Devices, Inc. Integrating display controller into low power processor
WO2007061597A1 (en) * 2005-11-23 2007-05-31 Advanced Micro Devices, Inc. Integrating display controller into low power processor
GB2445905A (en) * 2005-11-23 2008-07-23 Advanced Micro Devices Inc Integrating display controller into low power prosessor
US7750912B2 (en) 2005-11-23 2010-07-06 Advanced Micro Devices, Inc. Integrating display controller into low power processor
GB2445905B (en) * 2005-11-23 2011-01-05 Advanced Micro Devices Inc Integrating display controller into low power processor
US20100079445A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Method for reducing graphics rendering failures
US8310494B2 (en) * 2008-09-30 2012-11-13 Apple Inc. Method for reducing graphics rendering failures
US9257101B2 (en) * 2008-09-30 2016-02-09 Apple Inc. Method for reducing graphics rendering failures
US20120206461A1 (en) * 2011-02-10 2012-08-16 David Wyatt Method and apparatus for controlling a self-refreshing display device coupled to a graphics controller
US20150235341A1 (en) * 2014-02-18 2015-08-20 Qualcomm Incorporated Shader pipeline with shared data channels
US9679347B2 (en) * 2014-02-18 2017-06-13 Qualcomm Incorporated Shader pipeline with shared data channels
CN109887065A (en) * 2019-02-11 2019-06-14 京东方科技集团股份有限公司 Image rendering method and its device

Also Published As

Publication number Publication date
US6911985B1 (en) 2005-06-28

Similar Documents

Publication Publication Date Title
CN101176119B (en) Tiled prefetched and cached depth buffer
US6911985B1 (en) Method and apparatus for reducing frame buffer size in graphics systems
US5805868A (en) Graphics subsystem with fast clear capability
KR100478767B1 (en) Graphic processing with deferred shading
EP2756481B1 (en) System and method for layering using tile-based renderers
US20150123993A1 (en) Image processing device and image processing method
US10553024B2 (en) Tile-based rendering method and apparatus
US6288722B1 (en) Frame buffer reconfiguration during graphics processing based upon image attributes
US6424345B1 (en) Binsorter triangle insertion optimization
CN101896941A (en) Unified compression/decompression graphics architecture
WO2011013263A1 (en) Image file generation device, image processing device, image file generation method, and image processing method
WO2003046836A1 (en) Image processing apparatus and constituent parts thereof, rendering method
JP2003515766A (en) Method and apparatus for displaying high color resolution on a handheld LCD device
EP1255227A1 (en) Vertices index processor
US6492987B1 (en) Method and apparatus for processing object elements that are being rendered
JP4696067B2 (en) 3D shape drawing apparatus and 3D shape drawing method
EP1269418A1 (en) Tiled graphics architecture
EP0887768A2 (en) A graphic processor and a graphic processing method
US20120026179A1 (en) Image processing division
US20080055286A1 (en) Method And Apparatus For Displaying Bitmap Images
US6448967B1 (en) Z-Buffer pre-test for 3D graphics performance enhancement
JP3422453B2 (en) Image display processing device
KR0145709B1 (en) Computer graphic system
US20090058864A1 (en) Method and system for graphics processing
JP2005300974A (en) Device and method for image processing

Legal Events

Date Code Title Description
AS Assignment

Owner name: LSI LOGIC CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FUJIMOTO, SHINYA;REEL/FRAME:014785/0713

Effective date: 20031210

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AG

Free format text: PATENT SECURITY AGREEMENT;ASSIGNORS:LSI CORPORATION;AGERE SYSTEMS LLC;REEL/FRAME:032856/0031

Effective date: 20140506

AS Assignment

Owner name: LSI CORPORATION, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:LSI LOGIC CORPORATION;REEL/FRAME:033102/0270

Effective date: 20070406

AS Assignment

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LSI CORPORATION;REEL/FRAME:035390/0388

Effective date: 20140814

AS Assignment

Owner name: AGERE SYSTEMS LLC, PENNSYLVANIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039

Effective date: 20160201

Owner name: LSI CORPORATION, CALIFORNIA

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS (RELEASES RF 032856-0031);ASSIGNOR:DEUTSCHE BANK AG NEW YORK BRANCH, AS COLLATERAL AGENT;REEL/FRAME:037684/0039

Effective date: 20160201

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001

Effective date: 20160201

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH

Free format text: PATENT SECURITY AGREEMENT;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:037808/0001

Effective date: 20160201

FPAY Fee payment

Year of fee payment: 12

AS Assignment

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD., SINGAPORE

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001

Effective date: 20170119

Owner name: AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENTS;ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:041710/0001

Effective date: 20170119

AS Assignment

Owner name: AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITE

Free format text: MERGER;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:047196/0097

Effective date: 20180509

AS Assignment

Owner name: AVAGO TECHNOLOGIES INTERNATIONAL SALES PTE. LIMITE

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE EXECUTION DATE PREVIOUSLY RECORDED AT REEL: 047196 FRAME: 0097. ASSIGNOR(S) HEREBY CONFIRMS THE MERGER;ASSIGNOR:AVAGO TECHNOLOGIES GENERAL IP (SINGAPORE) PTE. LTD.;REEL/FRAME:048555/0510

Effective date: 20180905