Line-based rendering for graphics rendering system, method, and device

Abstract

To perform graphics rendering for efficiently using resources such as an internal memory.SOLUTION: A method includes the steps of: receiving a command for identifying a plurality of pixel mapping operations to be implemented on a plurality of data objects included in graphical data; determining a plurality of rendering parameters, the plurality of rendering parameters identifying a partitioning of the graphical data into a plurality of portion, and further identifying a pixel mapping operation for each of the plurality of portions; generating a plurality of sub-commands based, at least in part, on the plurality of rendering parameters and the command, the plurality of sub-commands identifying a processing operation for each data object included in each of the plurality of portions of the graphical data; and implementing a processing operation for at least one portion based on at least some of the plurality of sub-commands.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates generally to graphic rendering, and more specifically to techniques used to perform such graphic rendering.

Background Art

[0002] Computing devices and systems can include hardware and software configured to execute one or more software applications and display information related to such software applications on a display device. For example, a computer system can include a host processor and a hard drive used to execute a software application, and can display data related to the software application on a monitor of the computer system. To display on a display device, such graphic data can be rendered by one or more components of the computer system. However, in conventional systems, there are still limitations in the ability of those conventional systems to efficiently use resources such as internal memory when rendering and displaying such graphic data.

Brief Description of the Drawings

[0003] [Figure 1] FIG. 1 shows an example of a system for line-based rendering configured according to some embodiments. [Figure 2] FIG. 2 shows another example of a system for line-based rendering configured according to some embodiments. [Figure 3] FIG. 3 shows a flowchart of an example of a method for line-based rendering implemented according to some embodiments. [Figure 4]This figure shows a flowchart of another embodiment of a method for line-based rendering, implemented according to several embodiments. [Figure 5] This figure shows a flowchart of yet another embodiment of a method for line-based rendering, implemented according to several embodiments. [Figure 6] This figure shows one embodiment of an image processed by line-based rendering according to several embodiments. [Figure 7] This figure shows one embodiment of the components of a processing apparatus configured according to several embodiments. [Modes for carrying out the invention]

[0004] The following explanation includes numerous specific details to ensure a complete understanding of the presented concepts. These concepts may be implemented without using some or all of these specific details. As an alternative, well-known process operations have not been described in detail to avoid unnecessarily obscuring the concepts being discussed. Some concepts will be explained in conjunction with specific embodiments, but it should be understood that these embodiments are not intended to be limiting.

[0005] A computer system can be configured to render and display graphic data on one or more target display devices. Rendering and displaying such graphic data may involve performing one or more transformation operations on the graphic data itself. For example, the rendering process may include resizing or rescaling an image. According to various embodiments, a processing operation related to a specific element of an image or frame, such as an object or image layer, is a pixel mapping operation, sometimes referred to as a blit operation. Thus, a pixel mapping operation can be a numerical operation, which maps one or more input pixels to one or more output pixels according to a specified mapping function. A pixel mapping operation can process multiple output pixels using the same numerical operation.

[0006] Each pixel mapping operation requires read operations from memory such as video random access memory (VRAM) and source buffers, as well as write operations back to VRAM, which still limits the conventional techniques. Therefore, a single image or frame containing multiple image layers may have multiple pixel mapping operations associated with that image or frame, as each layer may be processed by a single pixel mapping operation. Thus, processing multiple pixel mapping operations for a single image or frame requires numerous VRAM accesses for each operation.

[0007] The embodiments disclosed herein provide parallelization of processing operations and "line-by-line" rendering, thereby reducing VRAM access and improving the overall efficiency and latency of the rendering system. More specifically, according to the embodiments disclosed herein, a pixel mapping command can be divided into multiple subcommands, and these subcommands can then be used to configure the pipeline of the graphics processing unit. In this way, the rendering of an image or frame can be divided into various parts or ranges of lines, and each pixel mapping operation contained in each part can be performed in parallel by different pipelines. In this way, extra access to VRAM for intermediate results is not required, and the bandwidth overhead associated with such processing operations is reduced.

[0008] Figure 1 shows one embodiment of a system for line-based rendering, configured according to several embodiments. As will be discussed in more detail later, a system like system 100 can be configured to perform line-based rendering on graphic data that will ultimately be displayed on a display device. More specifically, it can render graphic data that may include multiple layers of graphic information, and processing operations such as pixel operations can be performed line by line. As will be discussed in more detail later, such line-by-line rendering allows such processing operations to be performed in a manner that reduces memory access and internal bandwidth usage within system 100, thereby increasing the overall efficiency of system 100.

[0009] According to various embodiments, the system 100 includes a source 101 configured to supply data that will ultimately be displayed on a display device, as will be described in more detail later. More specifically, the source 101 can be configured to run one or more software applications configured to generate graphic data that should be displayed on a display device, for example, which can be included in a user interface generated for a particular software application. Further details regarding such software applications and graphic data will be described in more detail later with reference to Figure 2.

[0010] According to various embodiments, the source 101 is communicatively coupled to a memory device such as memory 102. According to various embodiments, memory 102 is a memory device such as random access memory (RAM). According to one embodiment, memory 102 is a video random access memory (VRAM) device. Furthermore, memory 102 can be communicatively coupled to source 101, and memory 102 may also include one or more buffers configured to store graphic data from source 101. Thus, buffers can be used to store images or frames contained in the graphic data.

[0011] The system 100 further includes a processing unit 104, which can be communicatively coupled to a memory 102 and configured to perform one or more processing operations on images and / or frames stored in the memory 102. According to various embodiments, such processing operations may include one or more pixel mapping operations. More specifically, processing operations may include resampling operations such as image rotation, orientation change, and perspective correction. According to various embodiments, such processing operations may include any appropriate transformation of pixels or rearrangement of pixels. Moreover, processing operations may include mapping multiple input pixels to a single output pixel. Thus, a single output pixel can be generated based on a mixture of multiple input pixels. Further details regarding processing operations will be described in more detail later.

[0012] According to various embodiments, the processing unit 104 is configured to perform such processing operations on a line-by-line basis in graphic data. Thus, the processing operations initially identified for rendering a single frame or image are not executed as sequential, object-by-object operations; instead, such object-by-object operations are divided into sub-operations that can be executed in scanline order. In this way, the processing operations underlying the rendering process can be executed at once using a dedicated static random access memory (SRAM) buffer for a specified number of lines, thereby eliminating the need to use internal traffic bandwidth associated with memory 102 to store and retrieve intermediate results. Furthermore, such line-by-line processing operation implementation allows for the generation of content for a video stream "on the fly" without requiring any storage of the resulting frames.

[0013] In addition, system 100 includes a display 106 configured to display the results of rendering operations. Therefore, the display 106 can be a display device such as a liquid crystal display (LCD) screen. As will be described in more detail later, the display 106 may include various components configured to receive and display rendered graphic data.

[0014] Figure 2 shows another embodiment of a system for line-based rendering, configured according to several embodiments. As previously described, a system such as System 200 can be configured to perform line-based rendering on graphic data that will ultimately be displayed on a display device. According to various embodiments, the processing operations underlying line-by-line rendering can reduce memory access and internal bandwidth usage within System 200. Moreover, as will be discussed in more detail later, the overall efficiency of System 200 can be further increased by parallelizing such processing operations.

[0015] According to various embodiments, the system 200 includes a source 202 configured to generate graphic data for display on a display device, as will be described in more detail later. As previously mentioned, the source 202 can be configured to run one or more software applications configured to generate such graphic data. More specifically, the source 202 may include application software 204 configured to run a software application that generates video data. For example, the software application may generate a user interface screen to be displayed on a display. According to another embodiment, the software application may generate video data to be displayed on a display. According to various embodiments, the graphic data may include one or more images or frames, each of which may contain one or more graphic objects to be rendered. As will be described in more detail later, such objects may be represented as various layers within this image or frame. Thus, such definitions of layers and objects within each image or frame may be defined based on one or more data values ​​within the image or frame itself and may be included in the graphic data transmitted from the source 202. According to various embodiments, the source 202 also includes a graphics driver 206 configured to manage hardware compatibility between the components of the system 200. Therefore, the graphics driver 206 can ensure that the transmitted graphics data is supported by the target display device.

[0016] According to various embodiments, the system 200 further includes a memory device such as a VRAM 208. Thus, as shown in Figure 2, the VRAM 208 can be communicatively coupled to the source 202, and the VRAM 208 is further configured to receive graphic data transmitted from the source 202. According to various embodiments, the VRAM 208 includes one or more buffers, such as a buffer 220, configured to store graphic data from the source 202. Therefore, the buffer 220 can be configured to provide a temporary storage location for frames and images received from the source 202. According to various embodiments, the VRAM 208 further includes a storage location configured to store commands associated with such frames and images. Thus, rendering operations associated with objects contained in the frames and images can be stored in such storage location and then retrieved when needed for rendering.

[0017] The system 200 also includes a processing unit 210, which can be connected to the VRAM 208 in a communicative manner and configured to perform one or more processing operations on images and / or frames stored in the VRAM 208. As previously mentioned, such processing operations may include resampling operations such as image rotation, orientation change, and perspective correction. Moreover, such processing operations may include any appropriate transformation of pixels or rearrangement of pixels.

[0018] According to various embodiments, the processing unit 210 is implemented as a graphics processing unit (GPU) and is configured to include various components capable of performing the processing operations described above. More specifically, the processing unit 210 may include components configurable to handle fetch and store operations related to memory locations in VRAM 208. For example, the processing unit 210 may include a fetch module 212 configured to retrieve graphic data from storage locations in VRAM 208. Thus, the fetch module 212 can be configured to identify and retrieve graphic data for a specified number of lines and for specific pixel mapping operations. More specifically, the specified number of lines can be predetermined during an initialization operation or by an entity such as a user or administrator. The specified number of lines may correspond to the number of pixels along the vertical axis of a single image or frame to be rendered. Thus, this image or frame can be segmented into a number of sections or slices, each defined by the number of lines. Further details regarding the definition of slices will be discussed later with reference to Figure 6.

[0019] Therefore, the fetch module 212 can be configured to fetch graphic data relating to a specific part of a rendering image or frame, such as a slice, and other components, such as the processing unit 214, can be configured to perform one or more processing operations on such graphic data. As mentioned earlier, the processing operations performed by the processing unit 214 can be pixel transformation operations such as orientation changes and perspective changes. In this way, the processing unit 214 can perform one or more pixel-to-pixel mapping operations on the graphic data supplied by the fetch module 212. As will be described in more detail later, the transformation operations performed by the processing unit 214 can be identified by system components such as the command sequencer 240, at least in part, based on the commands stored in the VRAM 208 described above.

[0020] According to various embodiments, the processing unit 210 may also include fetch modules 222 and 228, and processing units 224 and 230, which may be configured to perform fetch and processing operations for specific processing operations related to a particular portion of an image or frame being rendered. More specifically, multiple fetch modules and operator modules may be implemented to form different processing pipelines for various identified pixel mapping operations in a particular portion of an image or frame being rendered. According to one embodiment, a particular slice of an image may contain three pixel mapping commands related to three objects contained in that slice. Fetch module 212 and processing unit 214 may handle processing operations for a first object in the slice. Fetch module 222 and processing unit 224 may handle processing operations for a second object in the slice. Furthermore, fetch module 228 and processing unit 230 may handle processing operations for a third object in the slice. In this way, various pixel mapping operations related to various objects within a single rendered image or frame can be divided into sub-operations, and such sub-operations can be handled in parallel by the parallel pipeline of the processing unit 210, either line by line or slice by slice.

[0021] In addition, the processing device 210 includes an internal rendering buffer 216 configured to store the results of the above-described operator modules. Thus, the internal rendering buffer 216 can combine the results into a data object representing the rendered result of the portion or slice currently being processed. As described above, the internal rendering buffer 216 can be included within the SRAM module included in the processing device 210. Therefore, by using the internal rendering buffer 216, an extra access to the VRAM 208 becomes unnecessary.

[0022] According to various embodiments, in addition to this, the processing device 210 includes an interface 218 configured to store the rendered graphic data in a storage location of the VRAM 208. Therefore, the result of the rendered line can be retrieved from the internal rendering buffer 216 and stored in a storage location of the VRAM 208. In this way, the result of the rendered line is stored and no extra VRAM access is utilized for intermediate results. According to various embodiments, the interface 218 is communicatively coupled to one or more other system components, such as components of the display 234. Therefore, according to various embodiments, the interface 218 is configured to provide direct communication with the display 234 and the display controller 236. If this is done, then the interface 218 does not write to the buffer of the VRAM 208. Instead, it directly transmits the data to one or more components of the display 234, such as the display controller 236.

[0023] As shown in Figure 2, the system 200 also includes a controller 242, which may include various components such as a command sequencer 240 and an arbiter 238. According to various embodiments, the command sequencer 240 is configured to retrieve command data from VRAM 208 and generate commands for the fetch module and operator module described above. More specifically, the command sequencer 240 is configured to segment the pixel mapping commands corresponding to pixel mapping operations into sub-operations specific to each part or slice of a single image or frame being rendered. As previously mentioned, the pixel mapping commands can be associated with objects contained within a single image or frame being rendered. According to various embodiments, the command sequencer 240 can be configured to generate multiple commands based on a specified number of parts and a specified number of objects. In this way, commands can be generated for each part or slice of an image and for each object within each part or slice.

[0024] System 200 further includes an arbiter 238 configured to manage the utilization of the fetch module and the operator module. More specifically, the arbiter 238 can identify the number of fetch modules and operator modules to be utilized based on the number of objects included in one rendered image or frame. The arbiter 238 can then assign specific fetch modules and operator modules to the operations associated with these objects. For example, if one rendered image contains three objects, the fetch module 212 and the processing unit 214 can be assigned to the first object, the fetch module 222 and the processing unit 224 can be assigned to the second object, and further the fetch module 228 and the processing unit 230 can be assigned to the third object. In this way, the arbiter 238 can dynamically allocate the resources of the processing device 210 to processing operations.

[0025] System 200 further includes a display 234 configured to display the result of the rendering processing operation. As described above, the display 234 can be a display device such as a liquid crystal display (LCD) screen. According to various embodiments, the display 234 includes various components configured to receive the rendered graphic data and display such rendered graphic data. For example, the display 234 can include a display controller 236 configured to generate a video signal that is ultimately displayed on the display device of the display 234. Thus, the display controller 236 can manage the operation of the display device based at least in part on the received and rendered graphic data.

[0026] Figure 3 shows a flowchart of one embodiment of a method for line-based rendering, implemented according to several embodiments. As will be described in more detail later, a method such as Method 300 can be configured to perform line-based rendering on graphic data that will ultimately be displayed on a display device. As previously mentioned, such line-by-line rendering can be used to perform such processing operations in a manner that reduces memory access and internal bandwidth usage, as well as the use of memory resources such as frame buffers.

[0027] Method 300 may include operation 302, during which one or more commands may be received. According to various embodiments, these commands may be received from one or more components of a source of graphic data, such as a software application. As previously stated, a software application may generate data to be displayed on a display device and may also generate requests or commands corresponding to such display data to be displayed. These commands may include the graphic data itself, which may include pixel information, one or more other graphic parameters such as image layer information or object information, as well as any other appropriate information such as size information and resolution information.

[0028] Method 300 can proceed to Operation 304, during which multiple subcommands can be generated. As previously described, one or more components of the controller can generate multiple subcommands based on the received command. More specifically, different sets of commands can be generated based on the number of parts or slices in the image or frame being rendered, and based on the number of objects and / or image layers contained in the image or frame being rendered. As previously described, the number of parts can be a specified number, or it can be determined based on one or more system parameters, for example, the size of the internal rendering buffer and the number of scanlines that can be stored in the internal rendering buffer. Furthermore, the number of objects and / or image layers can be determined based on data values ​​provided by a software application included in the command.

[0029] Method 300 can proceed to operation step 306, during which some of a plurality of subcommands can be supplied to a processing unit configured to perform graphic processing operations. Thus, these subcommands can be supplied to the processing unit, and several fetch operations can be performed using these subcommands to fetch graphic data to be rendered. According to various embodiments, the fetch operation can be for a specific portion or slice of an image being rendered. Therefore, only graphic data relating to the currently active slice or selected slice can be fetched.

[0030] Method 300 can proceed to Operation 308, during which one or more processing operations can be performed based at least partially on some of several subcommands. Thus, the processing pipeline can perform processing operations in parallel according to the operations specified by the subcommands. For example, a specific type of transformation can be specified in a subcommand and performed during Operation 308. Once completed, the results can be stored in the processing memory and written to a storage location in memory. Obviously, the processing operations can be repeated many times to process all parts or slices of the graphic data to be rendered.

[0031] Figure 4 shows a flowchart of another embodiment of a method for line-based rendering, implemented according to several embodiments. As will be described in more detail later, a method such as Method 400 can be configured to perform line-based rendering on graphic data that will ultimately be displayed on a display device. As will also be described in more detail later, such line-based rendering can be performed in the context of a system including a graphics processing unit and related components.

[0032] Method 400 may include Operation 402, during which a command may be received. As previously stated, this command may be received from one or more components of the source of graphic data, such as a software application. More specifically, the software application may generate data for display on a display device. Such data may represent a user interface, an image, a video frame, or any other suitable visual information or data object. The software application may generate a command related to such graphic data, which may include various rendering and display parameters. For example, this command may identify one or more aspects of the graphic data itself, such as a target display for the graphic data, a target application for the graphic data, and the size and resolution of a single image or frame to be rendered. As previously stated, this command may also include the graphic data itself, which may include pixel information, and may also include further graphic parameters, such as spatial or structural information. More specifically, this command may include further graphic parameters that identify an image layer or object information.

[0033] Method 400 can proceed to Operation 404, during which the received command can be converted into a native command. According to various embodiments, this command can be received from one or more components of a source of graphic data, such as the software application described above. According to various embodiments, this command can be converted from a format used by the software application to a format specific to the underlying hardware of one or more system components, such as a processing unit, which will be described in more detail later. Thus, such a conversion can be performed by a graphics driver, and the converted command can be sent to one or more components of the system. For example, the converted command can be stored in a storage location of a storage device, such as a VRAM module.

[0034] Method 400 can proceed to Operation 406, during which several rendering parameters can be determined. According to various embodiments, the rendering parameters may be one or more parameters that identify, in particular, how a command should be divided into subcommands. More specifically, the rendering parameters may define how a single command should be divided into multiple subcommands. As will be described in more detail later, such subcommands may be a set of commands specific to a particular pipeline of the graphics processing unit and specific to a particular portion or slice of graphics data.

[0035] According to various embodiments, rendering parameters may include parameters such as the number of parts or slices of graphic data to be rendered, and the number of objects or image layers in each part. According to one embodiment, the number of parts or slices can be a specified number, or can be determined based on one or more system parameters, for example, the size of the internal rendering buffer and the number of scanlines that can be stored in the internal rendering buffer. For example, one image may have a height of a specified number of pixels. A system component such as a controller can obtain the number of parts or slices to be used by dividing this number of pixels by a specified number. As mentioned above, the specified number can be set initially, or can be determined based on system parameters. According to one embodiment, one slice may have a height of eight lines. According to various embodiments, the number of objects or image layers contained in each part can be determined based on the graphic data itself. In this way, a system component such as a controller can query the graphic data to generate rendering parameters.

[0036] Method 400 can proceed to Operation 408, during which multiple subcommands can be generated based at least in part on multiple rendering parameters. As previously stated, one or more components of the controller can generate multiple subcommands based on a received command. More specifically, different command sets can be generated based on the number of parts or slices in the image or frame being rendered, and on the number of objects and / or image layers contained in the image or frame being rendered. Thus, for each identified part, the controller can generate a command set that identifies one or more processing operations for each object and / or image layer contained in that part. According to one embodiment, the controller can identify the number of objects contained in a slice and generate a subcommand set for that slice, in which case this set includes one subcommand for each part of each object. Moreover, as previously stated, the number of objects and / or image layers can be determined based on data values ​​contained in a received command, which can be initially identified by a software application.

[0037] Method 400 can proceed to Operation 410, during which some of several subcommands can be supplied to the graphics processing unit. Thus, some of the subcommands generated during Operation 408 can be supplied to the graphics processing unit as described above, and these subcommands can be used to perform multiple fetch operations to fetch the graphics data to be rendered. According to various embodiments, the fetch operation may be for a specific part or slice of an image being rendered. Thus, one object or image layer can be assigned to each pipeline used by the graphics processing unit. During Operation 410, each pipeline can perform one fetch operation for its individual object or image layer.

[0038] Method 400 can proceed to Operation 412, during which one or more processing operations can be performed based at least partially on some of the subcommands. Thus, the graphics processing pipeline can perform processing operations in parallel according to the operations specified in the subcommands. For example, each pipeline can perform one processing operation on its fetched data based on the processing operation specified by the subcommand. As previously mentioned, such a processing operation may be a pixel transformation involving a numerical operation in which one input pixel is mapped to one output pixel.

[0039] Method 400 can proceed to operation 414, during which the rendered graphic data can be stored in memory. Therefore, once the processing operation is complete for one slice, the processed data can be stored in an internal rendering buffer included in the graphics processing unit. Furthermore, the processed lines of the image contained in that part or slice can be sent to a different storage location on another storage device. More specifically, the processed data can be sent to a VRAM module and further stored in the line buffer of the VRAM module.

[0040] Method 400 can proceed to Operation 416, during which the rendered graphic data can be transmitted to the target display. Thus, the processed data can be transmitted from the VRAM module to the target display. According to one embodiment, the data can be received by a display controller, which is configured to merge layer information and ultimately generate a signal to be displayed on the target display device. The processed and rendered data can then be displayed on the target display, which may be a liquid crystal display, or the target display may include multiple display devices, as may apply to clustered displays. According to various embodiments, the rendered graphic data can be transmitted directly from the graphics processing unit to the target display. For this reason, according to various embodiments, one or more parts of Operation 414 can be bypassed. More specifically, the rendered graphic data does not need to be stored in VRAM, and instead can be transmitted directly from the graphics processing unit to the target display device.

[0041] Figure 5 shows a flowchart of yet another embodiment of a method for line-based rendering, implemented according to several embodiments. As will be discussed in more detail later, a method such as Method 500 can be configured to perform line-based rendering on graphic data that will ultimately be displayed on a display device. As will also be discussed in more detail later, different processing operations can be parallelized by different pipelines of the graphics processing units. In this way, the command used to perform the pixel mapping operation can be divided into multiple subcommands, and the execution of such subcommands can be parallelized line by line.

[0042] Method 500 may include Operation 502, during which a command may be received. As previously stated, this command may be received from one or more components of the source of graphic data, such as a software application. Thus, a software application may generate a command related to graphic data, which may include various rendering and display parameters. As previously stated, this command may identify one or more aspects of the graphic data itself, such as a target display for the graphic data, a target application for the graphic data, and the size and resolution of a single image or frame to be rendered. Moreover, this command may include the graphic data itself, which may include pixel information, and may also include further rendering parameters, such as spatial or structural information.

[0043] Method 500 can proceed to Operation 504, during which several rendering parameters can be determined. As previously mentioned, the rendering parameters can be one or more parameters that identify how a command should be divided into subcommands. More specifically, the rendering parameters can define how a single command should be divided into multiple subcommands. As will be discussed in more detail later, such subcommands can be a set of commands specific to a particular pipeline of the graphics processing unit and specific to a particular portion or slice of the graphics data.

[0044] Method 500 can proceed to Operation 506, during which multiple subcommands can be generated based at least partially on multiple rendering parameters. As previously stated, one or more components of the controller can generate multiple subcommands based on received commands. More specifically, different sets of commands can be generated based on the number of parts or slices in the image or frame being rendered, and on the number of objects and / or image layers contained in the image or frame being rendered. Thus, for each identified part, and for each object and / or image layer contained in that part, the controller can generate a set of commands that identify one or more processing operations.

[0045] Method 500 can proceed to Operation 508, during which some of the subcommands can be supplied to the graphics processing unit. Thus, some of the subcommands generated during Operation 506 can be supplied to the graphics processing unit as described above, and these subcommands can be used to perform multiple fetch operations to fetch the graphics data to be rendered. According to various embodiments, the fetch operation can be for a specific part or slice of an image being rendered. Thus, one object or image layer can be assigned to each pipeline used by the graphics processing unit. During Operation 508, each pipeline can perform one fetch operation for its individual object or image layer.

[0046] Method 500 can proceed to Operation 510, during which a first processing operation can be performed. According to various embodiments, the first processing operation can be assigned by the controller to a first pipeline of a graphics processing unit. As previously stated, the first pipeline may include a first processing unit configured to perform one or more pixel transformation operations, such as orientation or perspective changes. Thus, the first processing unit can perform a first pixel mapping operation, such as a resize operation. Furthermore, the pixel transformation can be applied to a first object or image layer of the currently selected slice.

[0047] Method 500 can proceed to operation 512, during which a second processing operation can be performed. According to various embodiments, the second processing operation is assigned by the controller to a second pipeline of a graphics processing unit. As previously mentioned, the second pipeline may include a second processing unit, which is also configured to perform one or more pixel transformation operations. Thus, the second processing unit can perform a second pixel mapping operation, such as reorientation. Moreover, the pixel transformation can be applied to a second object or image layer of the currently selected slice.

[0048] Method 500 can proceed to operation 514, during which a third processing operation can be performed. According to various embodiments, the third processing operation is assigned by the controller to a third pipeline of the graphics processing unit. As previously mentioned, the third pipeline may include a third processing unit, which is also configured to perform one or more pixel transformation operations. Thus, the third processing unit can perform a third pixel mapping operation, such as a perspective change. Moreover, the pixel transformation can be applied to a third object or image layer of the currently selected slice.

[0049] Therefore, as mentioned earlier, multiple different processing operations can be executed in parallel by different pipelines of the graphics processing unit, and the command that manages each pipeline can be a subcommand generated from the initial command received from the source of the graphics data. In this way, multiple different processing operations corresponding to different pixel mapping operations can be executed in parallel according to a "line by line" based method that can process a specified number of lines at once.

[0050] Method 500 can proceed to operation 516, during which the rendered graphic data can be stored in memory. Thus, once the processing operation is complete for one slice, the processed data can be stored in an internal rendering buffer included in the graphics processing unit. Furthermore, the processed lines of the image contained in that part or slice can be sent to a different storage location on another storage device. More specifically, the processed data can be sent to a VRAM module and further stored in the line buffer of the VRAM module.

[0051] Method 500 can proceed to operation 518, during which it can be determined whether further processing operations should be performed. According to some embodiments, such a decision can be made based on the currently active portion or slice or selected portion or slice and the total number of portions or slices. For example, a graphics processing unit can repeatedly step through all defined slices for a single image or frame to be rendered. Such progress can be monitored by a component such as a controller. For example, the controller can implement a state machine to track such progress. In this way, the controller can determine whether there are further slices of the image remaining and whether they should be processed. If it is determined that further processing operations should be performed, Method 500 can return to operation 508. If it is not determined that further processing operations should be performed, Method 500 can terminate.

[0052] Figure 6 shows one embodiment of an image processed by line-based rendering according to several embodiments. As previously mentioned, a single image, such as image 600, can contain multiple objects to be rendered. For example, image 600 can contain a first object in the first image layer 602, a second object in the second image layer 604, and a third object in the third image layer 606. According to various embodiments, pixel mapping operations can be identified, for example, by source, for each of the first image layer 602, the second image layer 604, and the third image layer 606.

[0053] Furthermore, image 600 can be divided into multiple parts or slices, such as a first part 608 and a second part 610. Although two parts are shown here, it is obvious that the entire image 600 can be segmented into such parts. As previously mentioned, pixel mapping operations and commands can be sequenced and assigned to different processing pipelines of the processing unit for each part. Thus, a command sequencer can retrieve commands for pixel mapping operations and generate a first command set for the first part 608, a second command set for the second part 610, and further command sets for any further parts. Each command set can identify a specific part, a processing operation, and the target data object and associated image layer on which this processing operation should be performed, such that it can be identified by a range of lines or pixels. As shown in Figure 6, the first part 608 may have two command sets corresponding to two objects in two image layers, while the second part 610 may have three command sets for three objects in three image layers.

[0054] Figure 7 shows one embodiment relating to the components of a processing unit configured according to several embodiments. Therefore, a system such as the system 700 described below can be used to implement the controller and / or processing unit components described above. According to various embodiments, system 700 includes a processor 701, a memory module 703, a storage device 705, an interface 711, and a bus 715 (e.g., a PCI bus or other interconnect fabric). System 700 can operate as various devices such as a graphics processing unit, or as any other rendering device described herein. Although one specific configuration is described, various alternative configurations are possible. The processor 701 can perform operations as described herein. Instructions for performing such operations can be embodied in memory 703 on one or more non-temporary computer-readable media or any other storage device. Various specially configured devices can also be used instead of, or in addition to, the processor 701. As previously mentioned with reference to Figures 1 and 2, interface 711 can be configured to send data values ​​to and receive data values ​​from other system components.

[0055] While the concepts described above have been explained in some detail to clarify understanding, it is obvious that some modifications and alterations can be made within the scope of the attached claims. It should be noted that there are numerous alternative methods for implementing the processes, systems, and apparatus. Therefore, this embodiment should be considered illustrative and not limiting.

Claims

1. Receiving a command that is related to graphic data and that identifies a plurality of pixel mapping operations to be performed on a plurality of data objects included in the graphic data; Determining, using one or more processors, a plurality of rendering parameters, the plurality of rendering parameters identifying a division of the graphic data into a plurality of portions and further identifying at least one pixel mapping operation for each of the plurality of portions; Generating, using the one or more processors, a plurality of sub-commands that identify processing operations for each of the plurality of portions of the graphic data, based at least in part on the plurality of rendering parameters and the command, the command being a per-object command, the plurality of sub-commands being configured to execute the per-object command in scanline order, the number of the plurality of sub-commands being determined based on the plurality of rendering parameters and the number of pipelines in a graphics processing unit; Performing, using the one or more processors, at least one processing operation for at least one portion based on at least a portion of the plurality of sub-commands; A method comprising the steps above.

2. The graphic data includes one image, and the plurality of data objects include a plurality of image layers. The method according to claim 1.

3. The plurality of portions include a plurality of slices of the image. The method according to claim 2.

4. Each slice of the plurality of slices is defined based on a predetermined number of scanlines. The method according to claim 3.

5. The method further comprises performing, using the one or more processors, a further processing operation for at least one portion based on at least a portion of the plurality of sub-commands. The method according to claim 1.

6. The at least one processing operation and the further processing operation are performed in parallel. The method according to claim 5.

7. The at least one processing operation and the further processing operation are each performed on a different data object. The method according to claim 6. **Claim 8** The at least one processing operation is a pixel conversion operation selected from the group consisting of orientation change, perspective change, and size change. The method according to claim 1. **Claim 9** The graphic data includes one video frame, and the plurality of data objects include a plurality of objects within one video. The method according to claim 1. **Claim 10** An apparatus comprising a controller and a graphics processing unit, The controller includes one or more processors, The one or more processors receive a command related to graphic data and identifying a plurality of pixel mapping operations to be performed on a plurality of data objects included in the graphic data, determine a plurality of rendering parameters, the plurality of rendering parameters identifying a division of the graphic data into a plurality of parts and further identifying at least one pixel mapping operation for each of the plurality of parts, generate a plurality of sub-commands for identifying processing operations for each data object included in each of the plurality of parts of the graphic data, based at least in part on the plurality of rendering parameters and the command, the command being an object-by-object command, the plurality of sub-commands being configured to execute the object-by-object commands in scanline order, the number of the plurality of sub-commands being determined based on the plurality of rendering parameters and the number of pipelines in the graphics processing unit, configured as The graphics processing unit includes one or more processors, and the one or more processors are configured to perform at least one processing operation on at least one part based on at least a portion of the plurality of sub-commands. Apparatus. **Claim 11** The graphic data includes one image, the plurality of data objects include a plurality of image layers, and the plurality of parts include a plurality of slices of the image. The apparatus according to claim 10.

12. The graphic processing unit is further configured to perform further processing operations on at least one part based on at least some of the plurality of sub-commands. The apparatus according to claim 10.

13. The at least one processing operation and the further processing operation are performed in parallel. The apparatus according to claim 12.

14. The at least one processing operation is a pixel conversion operation selected from the group consisting of orientation change, perspective change, and size change. The apparatus according to claim 10.

15. A system including a host processor and memory, a controller, a graphic processing unit, and a display device, wherein the host processor and memory are configured to execute a software application and a graphic driver, the controller includes one or more processors, and the one or more processors receive from the graphic driver a command for identifying a plurality of pixel mapping operations to be performed on a plurality of data objects included in graphic data, determine a plurality of rendering parameters, the plurality of rendering parameters identifying a division of the graphic data into a plurality of parts and further identifying at least one pixel mapping operation for each of the plurality of parts, generate a plurality of sub-commands for identifying processing operations for each data object included in each of the plurality of parts of the graphic data, based at least in part on the plurality of rendering parameters and the command, the command being an object-by-object command, the plurality of sub-commands being configured to execute the object-by-object commands in scan line order, and the number of the plurality of sub-commands being determined based on the plurality of rendering parameters and the number of pipelines in the graphic processing unit. configured as such. The graphics processing unit includes one or more processors, and the one or more processors are configured to perform at least one processing operation on at least one part based on at least a part of the plurality of sub-commands. The display device is configured to display the result of the at least one processing operation. System.

16. The graphic data includes one image, the plurality of data objects include a plurality of image layers, and the plurality of parts include a plurality of slices of the image. The system according to claim 15.

17. The graphics processing unit is further configured to perform a further processing operation on at least one part based on at least a part of the plurality of sub-commands. The system according to claim 15.

18. The received command is a converted command that has been converted by the graphics driver. The system according to claim 15.

19. The graphics processing unit is further configured to perform a further processing operation on at least one part based on at least a part of the plurality of sub-commands, and the at least one processing operation and the further processing operation are performed in parallel. The system according to claim 15.

20. The at least one processing operation is a pixel conversion operation selected from the group consisting of rotation, perspective change, and size change. The system according to claim 15.

Images