Patent Description:
Transparent objects provide a challenge in computer graphics rendering. The GPU should render all objects in parallel for maximum performance. However, transparent objects must be rendered sequentially because the order effects the resulting image. Order independent transparency (OIT) refers to a computer graphics rendering of transparent objects. One technique of OIT rendering involves storing rasterized data in a per pixel linked list (A-Buffer), instead of rendering directly to the display screen. The A-Buffer is then sorted and blended for display on the screen. The amount of memory for the A-Buffer (e.g., the size) must be known and allocated before rendering. Allocating too much memory to the A-Buffer limits performance by reducing the available memory for the rest of the rendering process. Therefore, it is desirable to only allocate a minimum required amount of memory.

One method to address A-buffer size when rendering transparent objects is to draw the scene, and then check the A-Buffer size against the scene to see if the size was large enough for the rendered objects. If the size was not large enough, additional memory is allocated to the A-Buffer and the scene is redrawn in a second pass. This process involves the GPU sending information to the CPU about how much data was written to the A-Buffer. This introduces a GPU-to-CPU sync point, causing the CPU to wait for the GPU to finish rendering the scene. By waiting for the GPU to finish rendering, frame time and performance may be negatively impacted. In addition, if the A-buffer was not large enough the A-buffer must be resized and the scene re-rendered, again negatively impacting performance.

Another method to address A-buffer size when rendering transparent objects is to size the A-Buffer by rendering the scene with an initial pass (i.e., a geometry pass). In the initial pass, object geometry and size are recorded in the A-Buffer, without storing or computing visual data (e.g., color, normals, etc.) or blending the objects. The GPU then computes the A-Buffer size and sends it to the CPU. The CPU then resizes the A-Buffer, if appropriate. Once the A-Buffer size has been changed, the GPU then fully renders the scene into the A-Buffer in a second pass.

Both methods of addressing buffer size when rendering transparent objects described above require an additional sync point, reducing the performance of the application. Therefore, it would be advantageous to provide a device, system, and method that addresses these issues. <CIT> describes a system and method for structuring an A-buffer.

A method is disclosed, in accordance with one or more embodiments of the present disclosure. In one illustrative embodiment, the method includes queuing, by a centralized processing unit (CPU), a first rendering command for a first plurality of objects. In another illustrative embodiment, the method includes causing a graphics processing unit (GPU) to store rasterized data of the first plurality of objects into a first A-Buffer, sort the first A-Buffer, and render a first frame based on the first A-Buffer. In another illustrative embodiment, the centralized processing unit is free to process other commands while the GPU is rendering the first frame. In another illustrative embodiment, the method includes allocating, by the CPU, a size of a second A-buffer based on the size of the first A-Buffer from the first frame. In another illustrative embodiment, the CPU receives the size of the first A-buffer from the GPU during the second frame and determines the size for the second A-buffer such that the GPU does not wait for the size of the second A-Buffer during the second frame. In another illustrative embodiment, the method includes queuing, by the CPU, a second rendering command for a second plurality of objects. In another illustrative embodiment, the method includes causing the GPU to store rasterized data of the second plurality of objects into a second list stored in the second A-buffer, store an identification of one or more objects of the second plurality of objects into a removed buffer (R-buffer) when the one or more objects are partially stored in the second A-Buffer, sort the second list, and render a second frame using the second sorted list; wherein one or more objects of the second plurality of objects are removed from the second A-Buffer prior to rendering the second frame. In another illustrative embodiment, the CPU is free to process one or more other commands while the GPU is rendering the second frame.

A system is disclosed, in accordance with one or more embodiments of the present disclosure. In one illustrative embodiment, the system includes a graphics processing unit (GPU) including Video Memory. In another illustrative embodiment, the system includes a centralized processing unit (CPU). In another illustrative embodiment, the system includes a display. In another illustrative embodiment, the system is configured to perform the method described above.

Implementations of the concepts disclosed herein may be better understood when consideration is given to the following detailed description thereof. In the drawings:.

A technique is described that may resize an A-Buffer to an appropriate size, without wasting memory or performance. Embodiments of the present disclosure are generally directed to a method of A-Buffer dynamic memory allocation (A-Buffer DMA) for the A-Buffer of a graphics processing unit (GPU). In this approach, the size of the A-buffer is estimated with the data from the previous frame. This data is previously available and can be retrieved by the CPU from a GPU buffer, avoiding a sync point. The CPU can then size the A-Buffer based on the previous data and render the scene. If the new scene is larger than the old scene, then the A-Buffer may not be large enough, and objects may appear partially drawn when blended to the screen. The method may also include removing partially stored objects from the A-Buffer prior to blending, thereby preventing partially drawn objects from being displayed in the frame.

Referring now to <FIG>, a system <NUM> is described in accordance with one or more embodiments of the present disclosure. The system <NUM> may include one or more components, such as, but not limited to, a GPU <NUM> (graphics processing unit), a CPU <NUM> (centralized processing unit), or a display <NUM>. In some instances, the GPU <NUM> and the CPU <NUM> are housed in a computing device <NUM>, although this is not intended to be a limitation of the present disclosure. The GPU <NUM> and the CPU <NUM> may be configured to display a sequence of frames <NUM> on the display <NUM>. The frames <NUM> may include objects <NUM>, such as transparent objects with an ordering based on depth values. The GPU <NUM> and the CPU <NUM> are configured to implement one or more techniques for rendering the objects <NUM> by an order independent transparency (OIT) technique. The objects <NUM> may be blended from pixel data stored in A-Buffer <NUM>.

The GPU <NUM> may include memory <NUM> allocated to store the A-Buffer <NUM>. The memory <NUM> may include any storage medium known in the art suitable for storing program instructions executable by the associated processor. For example, the memory medium may include a non-transitory memory medium. By way of another example, the memory medium may include, but is not limited to, a random-access memory (RAM) such as a video RAM (VRAM) and the like. It is further noted that memory medium may be housed in a common controller housing with the GPU. In embodiments, the memory medium may be located remotely with respect to the physical location of the GPU/CPU.

In embodiments, the memory <NUM> may be dynamically allocated to the A-Buffer <NUM> for each frame. In further embodiments, the memory <NUM> may also be allocated to store an R-Buffer <NUM>. Each of the A-Buffer <NUM> and the R-Buffer <NUM> may include a size which is allocated from memory <NUM>. The size of the A-Buffer <NUM> may be based on a number of factors, such as, but not limited to, the number of objects, the size of the objects, and an output resolution of the scene. As compared to the A-Buffer <NUM>, the size of the R-Buffer <NUM> may be relatively small.

A number of objects <NUM> (also referred to herein as primitives) may be defined in a three-dimensional space. The objects <NUM> may be generated during one or more steps of a graphics pipeline. The CPU <NUM> may queue one or more rendering commands to the GPU <NUM> to render the objects <NUM> in the frame <NUM>. The objects <NUM> may include various data, such as, but not limited to, color, opacity, depth value, gradients, and the like. The objects <NUM> may be representative of data associated with the application of the system <NUM>. For example, the objects <NUM> may be representative of various game data with transparent objects. By way of another example, the objects <NUM> may be representative of various flight simulator data, such as, but not limited to a heads-up display, a surrounding environment and the like, although this is not intended to be limiting. The GPU <NUM> may receive the rendering commands and render the objects <NUM>. In embodiments, the GPU <NUM> rasterizes the objects in parallel and/or rasterizes multiple pixels for each object in parallel. By rasterizing the objects, the GPU <NUM> may generate rasterized data which may then be stored into the A-Buffer <NUM>. The objects <NUM> are thus rendered into the A-Buffer <NUM>. The objects in the A-Buffer <NUM> may then be sorted and blended for generating the frame <NUM>. One or more objects <NUM> may be rasterized on the display <NUM> in one or more frames <NUM>. The GPU <NUM> may generate the frames <NUM> with any frame rate, such as, but not limited to, between <NUM> and <NUM> frames per second, or more.

The A-buffer <NUM> is a spot in memory <NUM>. The CPU <NUM> must tell the GPU <NUM> how much of the memory <NUM> to allocate to the A-buffer <NUM>. The A-buffer <NUM> may include any data structure, such as, but not limited to, an array. The A-buffer <NUM> may be a buffer that contains an array stored in the memory <NUM> of the GPU <NUM>. The array may include pixel data, depth data, color data, opacity data, and the like. For example, the A-Buffer <NUM> may include a list, such as a per-pixel linked list where the objects are rendered. The per-pixel linked list may include a number of linked lists which set forth pixels which are displayed at the same position on the display. When the objects are first rendered into the A-Buffer <NUM>, the objects may be unsorted or otherwise not in order. When blending the objects, the order of the objects in the A-Buffer <NUM> matters, due to the transparency. As depicted in <FIG>, an object 118a and an object 118b are rendered which each include a transparency value. In <FIG>, the object 118a is disposed in front of the object 118b and then blended, causing an overlapping region <NUM> to include a first color. In <FIG>, the object 118b is disposed in front of the object 118a and then blended, causing the overlapping region <NUM> to include a second color which is different than the first color. Thus, ordering the objects <NUM> correctly is important to ensure an accurate rendering of the objects <NUM>. After the GPU <NUM> has drawn all of the objects into the A-Buffer <NUM>, the GPU <NUM> may perform a post processing pass which includes sorting the objects. The A-Buffer <NUM> may be sorted based on depth data. The sort may include any sorting algorithm, such as, but not limited to, an insertion sort adapted for the GPU known as register sort. The A-Buffer <NUM> may then be blended. The blending process may include combining the data stored in the A-Buffer <NUM> to achieve an image to be displayed on the display <NUM>. As may be understood, the blending process may include any number of blending processes known in the art. The sorted and blended objects may then be rendered to the display <NUM>.

Minimizing the amount of the memory <NUM> used by the GPU <NUM> may be advantageous in allowing the GPU <NUM> to initialize additional threads. Communication between the CPU <NUM> and the GPU <NUM> may cause the GPU to stop working until receiving the communication from the CPU <NUM> and vice versa, which may also be referred to as a CPU-to-GPU or GPU-to-CPU synch point. For example, the CPU could wait for the GPU to finish rendering and then send sizing information to the CPU. This information may be transmitted from the GPU <NUM> to the CPU <NUM> by a peripheral component interconnect express (PCI-E) bus or another interface. The CPU <NUM> may receive the communication, process the communication, and transmit an additional communication to the GPU <NUM> for allocating the size of the A-Buffer. Therefore, it is desirable to reduce the time of messages between the GPU <NUM> and the CPU <NUM>.

In embodiments, the CPU <NUM> is configured to dynamically allocate memory for the A-Buffer <NUM>. The amount of the memory <NUM> allocated to the A-Buffer <NUM> for the GPU may be dynamic and based on data from a previous frame which is available to a centralized processing unit (CPU). The CPU <NUM> may get frame data regarding the previous frame from the GPU <NUM>. The CPU <NUM> does not wait for the GPU <NUM> while the GPU <NUM> is rendering the frames <NUM> and is free to perform any number of commands, thereby removing a synch point. The CPU <NUM> may then approximate a size of the next frame of the buffer. By dynamically allocating the memory, a GPU-to-CPU sync point is removed. Additionally, the transparent objects may be rendered in a single pass without the GPU requesting the CPU to increase the size of the A-Buffer and without re-rendering, thereby reducing any extra renderings by the GPU <NUM>. The ability to remove the GPU-to-CPU sync points may improve the performance of real time rendering applications (e.g., on the order of several milliseconds per frame <NUM>). Similarly, reducing the number of renderings may also improve the performance of real time rendering applications. Thus, A-Buffer Dynamic Memory allocation may remove performance issues that are encountered when sizing the A-Buffer <NUM> for order independent transparency.

In some instances, sizing the A-buffer <NUM> based on the previous frame may introduce one or more problems when rendering. For example, the new frame may need a larger A-buffer than the previous frame (e.g., drawing more objects in the new frame). The A-buffer <NUM> may thus be unable to hold all of the objects. The GPU <NUM> may know whether the object fits into the A-Buffer <NUM> based on a current size of the A-Buffer <NUM>, the size of objects currently stored in the A-buffer <NUM>, and the size of the new objects. However, the GPU <NUM> may not be able to directly allocate more memory to the A-Buffer <NUM>. Depending upon the size of objects being rendered, the size of the A-buffer <NUM> from the previous frame may be insufficient, causing an overflow of the objects from the memory such that one or more of the objects <NUM> may be partially stored in the A-Buffer <NUM>. If the A-buffer <NUM> is not large enough to hold all the objects being rendered, only a portion of the objects <NUM> may be stored in the memory and subsequently blended which may introduced artifacts to the frame <NUM>.

To address the partially stored objects in the A-buffer <NUM>, the GPU <NUM> may include an additional buffer stored in the memory <NUM>. The additional buffer may be referred to as an R-Buffer <NUM> (Removed Buffer). The R-Buffer <NUM> may be created to store object identifications (IDs) for the objects which are partially stored in the A-Buffer. When the GPU <NUM> draws an object that doesn't fit fully into the A-Buffer <NUM>, the object ID for the partially drawn or overflown object is added to the R-Buffer <NUM>. When the A-Buffer is sorted, the identifications of the overflown object may be compared against the R-Buffer and the object is then not rendered/drawn on the display. For instance, the GPU may render all objects to the A-Buffer. The GPU may then compare the object IDs stored in the R-Buffer to the object IDs stored in the A-Buffer and remove the overflown objects from the A-buffer based on the R-Buffer. The GPU may then sort and blend for proper rendering without displaying the overflown object in the current frame, thereby preventing partially drawn objects from occurring in the current frame. The GPU may tell the CPU to increase the amount of memory allocated to the A-Buffer for subsequent frames thereby preventing overflow of the objects in the next frame.

The R-buffer <NUM> may be a relatively small buffer, when compared to the A-Buffer <NUM>. If the overflown objects are large, then only a few of them will be partially drawn and the rest of them will be undrawn. On the other hand, if the objects are small, then only a few of them will be partially drawn and the rest of them will be fully drawn. Because of this there will only be a small number of partially drawn objects and the R-Buffer <NUM> does not need to be very large. The R-Buffer <NUM> may be sized to store any number of object IDs. In some instances, the number of objects IDs is selected based on the byte size of the object ID and the cache size of the memory <NUM>. The object ID may include a byte size of <NUM>-bytes. The cache size of the memory <NUM> may include between <NUM>-bytes and <NUM>-bytes, or more. In this regard, the R-Buffer <NUM> may store any number of object IDs, such as, but not limited to, between <NUM> object IDs and <NUM> object IDs having a byte size of <NUM>-bytes. Thus, the number of object IDs is selected, together with the byte ID size, to align with a cache of the GPU (e.g., between <NUM> and <NUM> bytes, or more).

Performing dynamic memory allocation of the A-Buffer <NUM> removes the performance issues associated with the A-Buffer at the expense of overflown objects. With the addition of the R-Buffer, the GPU <NUM> may prevent partially drawn objects from being displayed in the current frame at the expense of a R-buffer cache overhead and <NUM> frame of latency. However, neither of these draw backs are noticeable in practice and frame times are significantly improved.

Referring now to <FIG>, a method <NUM> is described in accordance with one or more embodiments of the present disclosure. The embodiments and the enabling technology described previously herein in the context of the system <NUM> should be interpreted to extend to the method <NUM>. As may be understood, the steps in the method <NUM> may be performed iteratively for each frame <NUM>. It is further contemplated that the method <NUM> is not limited to the system <NUM>.

In a step <NUM>, the CPU <NUM> may queue one or more objects <NUM> to be rendered in a frame (N-<NUM>) to the GPU <NUM>. As may be understood, the objects to be rendered may generally include any type of object. Although not depicted, the CPU <NUM> may have sized the A-Buffer for the frame (N-<NUM>) based on a previous frame.

In a step <NUM>, the GPU <NUM> may render the objects in the frame (N-<NUM>) by order independent transparency. While the GPU <NUM> is rendering the frame (N-<NUM>), the GPU <NUM> may determine the size of the A-Buffer needed for a next frame (N). If the A-buffer is not large enough at this time, then an R-Buffer is used to avoid artifacts. Otherwise, all objects fit within the A-buffer and that is all that is needed to pass the size for the frame (N).

In a step <NUM>, the GPU <NUM> may provide various information for the frame (N-<NUM>) to the CPU <NUM>. The size gets sent from the GPU <NUM> to the CPU <NUM> during frame (N-<NUM>). The CPU <NUM> doesn't use the information from frame (N-<NUM>) until the CPU <NUM> is on frame (N). For example, if the system is rendering at <NUM> frames per second, each frame may be spaced between <NUM> and <NUM> milliseconds apart. During the middle of frame (N-<NUM>), the GPU <NUM> renders the frame (N-<NUM>), determines an A-buffer size for frame (N-<NUM>), and passes the A-Buffer size to the CPU <NUM>. The CPU <NUM> doesn't need the size information until the beginning of frame (N) which may be up to <NUM> milliseconds later. The delay before needing the size information may be a sufficient amount of time for the GPU <NUM> to compute the size. The frame (N-<NUM>) has already been rendered and the size of the A-buffer is also known. The GPU <NUM> sends the size of the A-buffer to the CPU <NUM> as a message in the step <NUM>. The CPU <NUM> then stores the message for future use. The CPU <NUM> continues to queue commands to the GPU <NUM> until all commands have been issued for the frame (N-<NUM>). The CPU <NUM> may receive the size of the A-buffer during or after the time the GPU is rendering. For example, the CPU <NUM> may receive the size of the A-Buffer for the frame (N-<NUM>) during the frame (N). The CPU <NUM> may take the size information from the previous frame and store the information in memory to be accessed after the CPU <NUM> has finished queuing commands.

In a step <NUM>, the CPU <NUM> may allocate the size of the A-Buffer for frame (N). The size of memory allocated to the A-Buffer <NUM> may be dynamically performed by the CPU <NUM> based on data from the previous frame, such as, but not limited to, the size of the previous A-Buffer. The data from the previous frame may provide an approximation for the size of the current A-Buffer. The CPU <NUM> may not wait on the size of the A-buffer when starting a frame (N). Thus, the CPU <NUM> uses older information from the previous frame because the CPU <NUM> does not need to synch with the GPU <NUM>. The A-buffer is thus sized based on the previous frame. If the current size of the A-Buffer is less than the size obtained from frame (N-<NUM>), then the A-Buffer is resized. Otherwise, the A-Buffer does not need to be resized.

In a step <NUM>, the CPU <NUM> may queue one or more objects <NUM> to be rendered in a frame (N) to the GPU <NUM>. As may be understood, the objects to be rendered may generally include any type of object. The objects <NUM> may include additional objects from the previous frame, such that the A-Buffer for the frame (N) may be too small and one or more of the objects may be partially stored.

In a step <NUM>, the GPU <NUM> may render the objects in the frame (N) by order independent transparency. The step <NUM> may be further understood by reference to <FIG>, where, if the A-buffer is not large enough, the GPU <NUM> uses the R-Buffer <NUM> to remove partially stored objects and thereby prevent artifacts.

In a step <NUM>, the GPU <NUM> may provide various information for the frame (N) to the CPU <NUM> for sizing a next frame (N+<NUM>).

Referring now in particular to <FIG>, the step <NUM> of rendering the frame (N) is described, in accordance with one or more embodiments of the present disclosure. The steps <NUM> may include one or more optional steps of using the R-Buffer to prevent partially stored objects from being drawn.

In a step <NUM>, the GPU <NUM> may render the objects <NUM> into the A-Buffer <NUM>. The A-Buffer <NUM> includes the objects from the previous frame. The GPU <NUM> may then add the objects to the A-Buffer. The GPU <NUM> may know the current size of the A-Buffer <NUM> and the size of the new objects being rendered into the A-Buffer. In some instances, the A-Buffer does not include sufficient memory for storing the new objects, such that the objects are partially stored.

In an optional step <NUM>, the object IDs associated with the partially stored objects within the A-Buffer <NUM> are stored in the R-Buffer.

In a step <NUM>, the objects in the A-Buffer are sorted based on depth data. The number of objects to be sorted may be counted. The objects may then be sorted using any sorting technique known in the art, such as, but not limited to, an insertion sort adapted for the GPU <NUM> known as register sort.

In an optional step <NUM>, the object IDs stored in the R-Buffer <NUM> are used to remove the partially stored objects from the A-Buffer. For example, the partially stored objects may be removed prior to sorting. The A-Buffer may then be sorted. Various modifications may be made to the point at which the partially stored objects are removed from the A-Buffer. For example, the partially stored objects in the A-Buffer may be removed after sorting. However, removing the partially stored objects prior to sorting may be beneficial in reducing the number of objects to be sorted.

In a step <NUM>, the GPU <NUM> blends the sorted objects in the A-Buffer to generate a frame and renders the frame to the display <NUM>. The GPU <NUM> may blend the sorted objects by any method known in the art. By removing the partially stored objects from the A-Buffer in the step <NUM>, the partially stored objects may be prevented from being drawn in the step <NUM>, thereby introducing one frame of latency. When rendering a next frame, the GPU <NUM> may provide the information for the current frame to the CPU for increasing the size of the A-Buffer and causing the objects to be fully drawn.

The method <NUM> described may exhibit significant improvements over prior techniques for A-Buffer memory allocation. For example, the method <NUM> may exhibit between a four to six millisecond improvement in rendering each frame with order independent transparency. Such improvement may be primarily based on removing the GPU-to-CPU synch points. The improved time may come at an expense of a memory overhead for the R-Buffer and a one frame latency. The one frame latency may be a delay for seeing the partially stored objects (commonly, newly generated objects). The latency may provide a minimal impact as the frame rate increases (e.g., to <NUM> FPS or more), where the latency occupies a relatively shorter duration of each second. Where the step <NUM> is not performed, there may be no latency for drawing the partially stored objects. However, the partially stored objects may only be partially drawn on the frame which may introduce noticeable artifacts.

Referring generally to <FIG>, one or more examples of the frames <NUM> rendered by the display <NUM> are described. The frames are generated by dynamically allocating the A-Buffer <NUM>. As may be understood, the number of frames and the content of the frames may be dependent on a use case of the display <NUM> and are not intended to be limiting. The frames may generally include any number of transparent objects which are provided in any order. Such transparent objects may be a rasterized pixel representation based on primitives including any color, opacity, depth value, depth gradient, and the like. Furthermore, the transparent objects depicted are not intended to be limiting, but are merely provided for illustration.

Referring now to <FIG>, frames 302a, 302b, 302c are described. The frames <NUM> may be provided in sequence. The frame 302a may be a first frame, the frame 302b may be a second frame, and the frame 302c may be a third frame. The frames <NUM> may indicate rendering transparent objects on a display while dynamically allocating memory to an A-Buffer without the use of an R-Buffer or without removing partially stored transparent objects.

The frame 302a may include one or more transparent objects disposed at one or more depths. The ordering of the depth transparent objects and the transparency values for the objects may impact the frame to be rendered. For example, the frame 302a may include a transparent object <NUM> disposed at a first depth. The frame 302a may also include one or more transparent objects <NUM> disposed behind the transparent object <NUM>. The ordering of the objects may be based on depth data of the associated primitive. In some instances, the transparent objects <NUM> may be a background. The frame 302a may also include one or more non-transparent objects.

The frame 302b may follow the frame 302a in sequence as the frames are displayed. In the frame 302b, a transparent object <NUM> is newly generated based on a change in the environment. The transparent object <NUM> may be a new background or another object which may occupy a substantial portion of the A-Buffer. For example, the new background may occur as the display changes between one or more of a ground and a sky. Due to a size of the transparent object <NUM>, the transparent object <NUM> may exceed the storage capacity allocated to the A-Buffer <NUM> and only a portion of the transparent object <NUM> is stored. In this example, the GPU <NUM> may not remove the transparent objects which are partially stored in the A-Buffer <NUM> and may not include the R-Buffer <NUM>. The transparent object <NUM> which is partially stored may introduce artifacts <NUM> into the frame 302b. As depicted, the transparent object <NUM> was stored as a partial triangle with a number of the artifacts <NUM>. The artifacts <NUM> may be introduced based on the transparent object <NUM> and/or how the GPU stores the transparent object <NUM> in the A-Buffer, such that the artifacts <NUM> are not intended to be limiting.

The frame 302c may follow the frame 302b. Here, the A-buffer <NUM> has been allocated sufficient memory to store the entire portion of the transparent object <NUM>. The transparent object <NUM> now is fully stored in the A-buffer <NUM> and accurately displayed such that the artifacts <NUM> are removed. Undesirably, the artifacts <NUM> may create a flickering effect on the display as the frames 302a-302c are display. In some cases, the flickering effect is more noticeable than failing to display the transparent object <NUM> in the frame 302b.

Referring now to <FIG>, frames 402a, 402b, 402c rendered on the display <NUM> are described. The frames <NUM> may be provided in sequence. The frame 402a may be a first frame, the frame 402b may be a second frame, and the frame 402c may be a third frame. <FIG> may be similar to <FIG>, with the exception that the frames <NUM> may indicate rendering transparent objects on a display while dynamically allocating memory to an A-Buffer with the use of an R-Buffer for removing partially stored transparent objects. In frame 402b, the transparent object <NUM> has been partially stored in the A-buffer <NUM> and an identification (i.e., object ID) of the transparent object <NUM> has been stored in the R-Buffer <NUM>. The transparent object <NUM> is then removed from the A-Buffer <NUM> when rendering the frame 402b on the display, such that the transparent object <NUM> is not drawn. A size of the A-Buffer <NUM> is then increased such that the transparent object <NUM> is fully stored in the A-buffer <NUM> and is displayed in the frame 402c. Thus, the transparent object <NUM> may be displayed without artifacts, at a cost of a one-frame delay.

Referring now to <FIG>, an exemplary embodiment of the system <NUM> as a simulator is described, in accordance with one or more embodiments of the present disclosure. The system may be used to simulate an aircraft or another vehicle. For example, the simulator may be a flight simulator <NUM>. The flight simulator <NUM> may mimic one or more portions of an aircraft-in flight such as a view through a window of an environment together with various displays present within the aircraft. In some instances, the window, the displays, or another portion of the simulation include one or more transparent objects which are rendered by the various techniques described herein. The frames may be displayed on a display <NUM> (e.g., the display <NUM>), such as by an image projection or another technique by a digital light processing display or the like. An operator may then view the frames on the display <NUM> from a viewing platform as the operator executes various simulation maneuvers. In some instances, the display <NUM> may include a number of transparent objects which may benefit from the techniques described herein, such as, but not limited to, text, buttons, horizons, and other objects commonly displayed on a flight display. As may be understood, the configuration depicting the flight simulator <NUM> is not intended to be limiting but is merely provided for illustration of utilizing the system in flight simulation contexts. However, the embodiments and the enabling technology described in the context of dynamic memory allocation may be particularly beneficial in the context of flight simulator applications, where it is desirable to render frames in real time with order independent transparency as accurately as possible to mimic the conditions present on a flight deck.

Referring generally again to <FIG>. The GPU <NUM> described herein may use any graphics pipeline known in the art. Additionally, the GPU <NUM> and the CPU may include any interface known in the art, such as, but not limited to OpenGL, Direct3D, CUDA, and the like. The computing device <NUM> may similarly include any computing device, such as, but not limited to, a general-purpose computer, including any number of components known in the art, such as, but not limited to, a motherboard, a random-access memory, a memory drive (e.g., solid state drive, hard drive, etc.), a GPU, a CPU, one or more interfaces, a power supply, and the like.

Further, it is noted herein the display <NUM> may include any display device known in the art. For example, the display device may include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) based display, an organic light-emitting diode (OLED) based display, an electroluminescent display (ELD), a plasma display panel (PDP), a display light processing (DLP) display, or the like. Those skilled in the art should recognize that a variety of display devices may be suitable for implementation in the present invention and the particular choice of display device may depend on a variety of factors.

Claim 1:
A method comprising:
queuing, by a centralized processing unit, CPU (<NUM>), a first rendering command for a first plurality of objects;
causing a graphics processing unit, GPU (<NUM>), to store rasterized data of the first plurality of objects into a first A-Buffer, sort the first A-Buffer, and render a first frame based on the first A-Buffer; wherein the centralized processing unit is free to process other commands while the GPU (<NUM>) is rendering the first frame;
allocating, by the CPU (<NUM>), a size of a second A-buffer based on the size of the first A-Buffer from the first frame; wherein the CPU (<NUM>) receives the size of the first A-buffer from the GPU during the second frame and determines the size for the second A-buffer such that the GPU does not wait for the size of the second A-Buffer during the second frame;
queuing, by the CPU (<NUM>), a second rendering command for a second plurality of objects;
causing the GPU (<NUM>) to store rasterized data of the second plurality of objects into a second list stored in the second A-buffer, store an identification of one or more objects of the second plurality of objects into a removed buffer, R-buffer, when the one or more objects are partially stored in the second A-Buffer, sort the second list, and render a second frame using the second sorted list; wherein the CPU (<NUM>) is free to process one or more other commands while the GPU (<NUM>) is rendering the second frame; wherein the one or more objects of the second plurality of objects are removed from the second A-Buffer prior to rendering the second frame;
wherein the second plurality of objects are rendered into the second A-Buffer in a single pass without the GPU (<NUM>) requesting the CPU (<NUM>) to increase the size of the second A-Buffer and without re-rendering the one or more objects of the second plurality of objects.